CCE позволяет задавать запросы ресурсов и ограничения, такие как CPU и RAM, для добавляемых контейнеров при создании рабочей нагрузки. Kubernetes также позволяет использовать YAML для задания требований к другим типам ресурсов.
Для CPU и Memory значения Request и Limit следующие:
Если у узла достаточно ресурсов, pod на этом узле может использовать больше ресурсов, чем запрошено, но не более ограничения.
Например, если вы задаете запрос памяти pod равным 1 GiB, а его ограничение — 2 GiB, и pod планируется на узел с 8 GiB памяти (при отсутствии других pod), pod может использовать более 1 GiB памяти при высокой нагрузке, но его использование памяти будет ограничено 2 GiB. Если процесс в контейнере пытается использовать более 2 GiB ресурсов, ядро системы пытается завершить процесс. В результате возникает ошибка out of memory (OOM).
При создании рабочей нагрузки рекомендуется задавать верхние и нижние ограничения ресурсов CPU и memory. Если верхние и нижние ограничения ресурсов не заданы для рабочей нагрузки, утечка ресурсов этой нагрузки сделает ресурсы недоступными для других нагрузок, развернутых на том же узле. Кроме того, нагрузки без верхних и нижних ограничений ресурсов нельзя точно мониторить.
В реальных сценариях рекомендуется соотношение Request к Limit около 1:1.5. Для некоторых чувствительных сервисов рекомендуется соотношение 1:1. Если Request слишком мал, а Limit слишком велик, ресурсы узла переиспользуются. Во время пиковых нагрузок память или CPU узла могут быть исчерпаны. В результате узел становится недоступным.
Параметр | Description |
|---|---|
CPU request | Минимальное количество ядер CPU, требуемое контейнером. Ресурсы планируются для контейнера на основе этого значения. Контейнер может быть запланирован на узел только тогда, когда общее количество ядер CPU, доступных для выделения на узле, больше или равно количеству ядер CPU, запрошенных контейнером. |
CPU limit | Максимальное количество ядер CPU, доступных для контейнера. |
Recommended configuration
Фактическое доступное количество CPU узла ≥ Сумма ограничений CPU всех контейнеров на текущем узле ≥ Сумма запросов CPU всех контейнеров на текущем узле. Вы можете просмотреть фактическое доступное количество CPU узла в консоли CCE (Resource Management > Nodes > Allocatable).
Parameter | Description |
|---|---|
Memory request | Минимальный объём памяти, требуемый контейнером. Ресурсы планируются для контейнера на основе этого значения. Контейнер может быть запланирован на узел только тогда, когда общий доступный объём памяти на узле больше или равен объёму памяти, запрошенному контейнером. |
Memory Limit | Максимальный объём памяти, доступный для контейнера. Когда использование памяти превышает настроенный лимит памяти, инстанс может быть перезапущен, что влияет на нормальную работу нагрузки. |
Рекомендуемая конфигурация
Фактическая доступная память узла ≥ Сумма пределов памяти всех контейнеров на текущем узле ≥ Сумма запросов памяти всех контейнеров на текущем узле. Вы можете просмотреть фактическую доступную память узла в консоли CCE (Resource Management > Nodes > Allocatable).
Распределяемые ресурсы рассчитываются на основе значения запроса ресурса (Request), которое указывает верхний предел ресурсов, которые могут запрашиваться pod‑ами на этом узле, но не указывает фактическую доступную память узла (для подробностей см. Example of CPU and Memory Quota Usage). Формула расчёта выглядит следующим образом:
Предположим, что кластер содержит узел с 4 ядрами CPU и 8 GiB памяти. На кластере развернуты два pod‑а (pod 1 и pod 2). Pod 1 переподписывает ресурсы (то есть Limit > Request). Спецификации двух pod‑ов приведены ниже.
Pod | CPU Request | CPU Limit | Memory Request | Memory Limit |
|---|---|---|---|---|
Pod 1 | 1 core | 2 cores | 1 GiB | 4 GiB |
Pod 2 | 2 cores | 2 cores | 2 GiB | 2 GiB |
Использование CPU и памяти узла выглядит следующим образом:
В этом случае оставшийся 1 core и 5 GiB могут быть использованы следующим новым pod.
Если pod 1 находится под высокой нагрузкой в пиковые часы, он будет использовать больше CPU и памяти в пределах лимита. Поэтому фактические доступные ресурсы меньше, чем 1 core и 5 GiB.
Обычно узлы поддерживают локальное ephemeral storage, которое предоставляется локально смонтированными записываемыми устройствами или RAM. EV не гарантирует долгосрочную доступность данных. Pods могут использовать локальные EV для буферизации данных и хранения журналов, либо монтировать тома emptyDir в контейнеры. Подробности см. в Local ephemeral storage.
Kubernetes позволяет указать запрашиваемое значение и предельное значение ephemeral storage в конфигурациях контейнеров для управления локальным ephemeral storage. Для каждого контейнера в pod можно настроить следующие атрибуты:
В следующем примере pod содержит два контейнера. Запрошенное значение для каждого контейнера локального эфемерного хранилища составляет 2 GiB, а значение предела — 4 GiB. Поэтому запрошенное значение pod для локального эфемерного хранилища составляет 4 GiB, значение предела — 8 GiB, и том emptyDir использует 500 MiB локального эфемерного хранилища.
apiVersion: v1kind: Podmetadata:name: frontendspec:containers:- name: container-1image: <example_app_image>resources:requests:ephemeral-storage: "2Gi"limits:ephemeral-storage: "4Gi"volumeMounts:- name: ephemeralmountPath: "/tmp"- name: container-2image: <example_log_aggregator_image>resources:requests:ephemeral-storage: "2Gi"limits:ephemeral-storage: "4Gi"volumeMounts:- name: ephemeralmountPath: "/tmp"volumes:- name: ephemeralemptyDir:sizeLimit: 500Mi