CCE позволяет задавать требования к ресурсам и ограничения, такие как CPU и ОЗУ, для добавляемых контейнеров во время создания нагрузки. Kubernetes также позволяет использовать YAML для задания требований к другим типам ресурсов.
Для CPU и Память, значения Запрос и Ограничение следующие:
Если узел имеет достаточные ресурсы, pod на этом узле может использовать больше ресурсов, чем запрошено, но не более установленного предела.
Например, если вы задаете запрос памяти pod равным 1 GiB и лимит 2 GiB, и pod размещается на узле с 8 GiB памяти (без запущенных других pod), pod может использовать более 1 GiB памяти при высокой нагрузке, но использование памяти будет ограничено 2 GiB. Если процесс в контейнере пытается использовать более 2 GiB ресурсов, ядро системы пытается завершить процесс. В результате возникает ошибка out of memory (OOM).
При создании нагрузки рекомендуется установить верхние и нижние пределы ресурсов CPU и памяти. Если верхние и нижние пределы ресурсов не заданы для нагрузки, утечка ресурсов этой нагрузки сделает ресурсы недоступными для других нагрузок, развернутых на том же узле. Кроме того, нагрузки без верхних и нижних пределов ресурсов невозможно точно мониторить.
В реальных сценариях рекомендуется соотношение Запрос к Лимит около 1:1.5. Для некоторых чувствительных сервисов рекомендуется соотношение 1:1. Если Запрос слишком мал и Лимит слишком велик, ресурсы узла перегружены. Во время пиковых нагрузок память или CPU узла могут быть исчерпаны. В результате узел недоступен.
Параметр | Описание |
|---|---|
Запрос CPU | Минимальное количество ядер CPU, необходимых контейнеру. Ресурсы для контейнера планируются на основе этого значения. Контейнер может быть размещён на этом узле только тогда, когда общее доступное CPU на узле больше или равно количеству контейнерных приложений CPU. |
Лимит CPU | Максимальное количество ядер CPU, доступных для контейнера. |
Рекомендуемая конфигурация
Фактическое доступное CPU узла ≥ Сумма ограничений CPU всех контейнеров на текущем узле ≥ Сумма запросов CPU всех контейнеров на текущем узле. Вы можете просмотреть фактические доступные CPU узла в консоли CCE (Управление ресурсами > Узлы > Выделяемый).
Параметр | Описание |
|---|---|
Запрос памяти | Минимальный объём памяти, требуемый контейнером. Ресурсы планируются для контейнера на основе этого значения. Контейнер может быть запланирован на этом узле только тогда, когда общая доступная память на узле больше или равна количеству приложений с контейнеризированной памятью. |
Ограничение памяти | Максимальный объём памяти, доступный контейнеру. Когда использование памяти превышает настроенное ограничение памяти, экземпляр может быть перезапущен, что влияет на нормальное использование нагрузки. |
Рекомендуемая конфигурация
Фактическая доступная память узла ≥ Сумма ограничений памяти всех контейнеров на текущем узле ≥ Сумма запросов памяти всех контейнеров на текущем узле. Вы можете просмотреть фактическую доступную память узла в консоли CCE (Управление ресурсами > Узлы > Выделяемый).
Выделяемые ресурсы рассчитываются на основе значения запроса ресурсов (Запрос), что указывает на верхний предел ресурсов, которые могут запрашиваться pod'ами на этом узле, но не указывает фактически доступные ресурсы узла (подробности см. Пример использования квоты CPU и памяти). Формула расчета следующая:
Предположим, что кластер содержит узел с 4 CPU ядрами и 8 GiB памяти. В кластере развернуты два pod'а (pod 1 и pod 2). Pod 1 переиспользует ресурсы (то есть Лимит > Запрос). Спецификации двух pod'ов следующие.
Pod | Запрос CPU | Лимит CPU | Запрос памяти | Лимит памяти |
|---|---|---|---|---|
Pod 1 | 1 ядро | 2 ядра | 1 GiB | 4 GiB |
Pod 2 | 2 ядра | 2 ядра | 2 GiB | 2 GiB |
CPU и использование памяти узла выглядят следующим образом:
В этом случае оставшиеся 1 ядро и 5 GiB могут быть использованы следующим новым pod.
Если pod 1 находится под высокой нагрузкой в пиковые часы, он будет использовать больше CPU и памяти в пределах лимита. Следовательно, фактические доступные ресурсы меньше, чем 1 ядро и 5 GiB.
Обычно узлы поддерживают локальные временное хранилище, которое предоставляется локально подключёнными устройствами записи или ОЗУ. EV не гарантирует долгосрочную доступность данных. Pods могут использовать локальные EVs для буферизации данных и сохранения логов, либо монтировать тома emptyDir в контейнеры. Подробности см. Локальное временное хранилище.
Kubernetes позволяет указать запрашиваемое значение и предельное значение временного хранилища в конфигурациях контейнеров для управления локальным временным хранилищем. Следующие атрибуты могут быть сконфигурированы для каждого контейнера в 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