Cloud Container Engine

Настройка спецификаций контейнеров

Эта статья полезна?

Язык статьи: Русский

Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Сценарий

CCE позволяет задавать требования к ресурсам и ограничения, такие как CPU и RAM, для добавляемых контейнеров при создании нагрузки. Kubernetes также позволяет использовать YAML для задания требований к другим типам ресурсов.

Запрос и лимит

Для CPU и Память, значения Запрос и Лимит следующие:

Запрос: Система планирует pod на узел, который соответствует требованиям развертывания нагрузки на основе значения запроса.
Лимит: Система ограничивает ресурсы, используемые нагрузкой, на основе значения лимита.

Если узел имеет достаточные ресурсы, pod на этом узле может использовать больше ресурсов, чем запрошено, но не более установленного лимита.

Например, если задать запрос памяти pod‑а в 1 ГиБ и его лимит в 2 ГиБ, и pod будет запланирован на узел с 8 ГиБ памяти (без запущенных других pod‑ов), pod может использовать более 1 ГиБ памяти при высокой нагрузке, но его потребление памяти будет ограничено 2 ГиБ. Если процесс в контейнере пытается использовать более 2 ГиБ ресурсов, ядро системы пытается завершить процесс. В результате возникает ошибка нехватки памяти (OOM).

Note

При создании нагрузки рекомендуется установить верхние и нижние пределы ресурсов CPU и памяти. Если для нагрузки не заданы верхние и нижние пределы ресурсов, утечка ресурсов этой нагрузки сделает ресурсы недоступными для других нагрузок, развернутых на том же узле. Кроме того, нагрузки без верхних и нижних пределов ресурсов невозможно точно мониторить.

Конфигурация

В реальных сценариях рекомендуется соотношение Запрос к Лимит около 1:1,5. Для некоторых чувствительных сервисов рекомендуется соотношение 1:1. Если Запрос слишком мал и Лимит слишком велик, ресурсы узла переиспользуются. Во время пиковых нагрузок память или CPU узла могут быть исчерпаны. В результате узел становится недоступным.

Квота CPU: единица ресурсов CPU — ядро, которое может быть указано числом или целым числом с суффиксом (m). Например, 0,1 ядра в числовом выражении эквивалентно 100m в таком выражении. Однако Kubernetes не допускает ресурсы CPU с точностью менее 1m.

Таблица 1 Квоты CPU
Параметр	Описание
Запрос CPU	Минимальное количество ядер CPU, требуемое контейнером. Ресурсы планируются для контейнера на основе этого значения. Контейнер может быть запланирован на этот узел только тогда, когда общее доступное количество CPU на узле больше или равно количеству контейнеризованных CPU‑приложений.
Лимит CPU	Максимальное количество ядер CPU, доступных контейнеру.

Рекомендуемая конфигурация

Фактическое доступное количество CPU узла ≥ Сумма лимитов CPU всех контейнеров на текущем узле ≥ Сумма запросов CPU всех контейнеров на текущем узле. Фактическое доступное количество CPU узла можно просмотреть в консоли CCE (Управление ресурсами > Узлы > Выделяемый).

Квота памяти: единицей ресурсов памяти по умолчанию является байт. Можно также использовать целое число с суффиксом единицы, например, 100 Mi. Обратите внимание, что единица чувствительна к регистру.

Таблица 2 Описание квот памяти
Параметр	Описание
Запрос памяти	Минимальный объём памяти, требуемый контейнером. Ресурсы планируются для контейнера на основе этого значения. Контейнер может быть запланирован на узел только тогда, когда общее доступное количество памяти на узле больше или равно количеству контейнеризованных приложений памяти.
Лимит памяти	Максимальный объём памяти, доступный контейнеру. Когда использование памяти превышает настроенный лимит памяти, экземпляр может быть перезапущен, что влияет на нормальную работу нагрузки.

Рекомендуемая конфигурация

Фактическое доступное количество памяти узла ≥ Сумма лимитов памяти всех контейнеров на текущем узле ≥ Сумма запросов памяти всех контейнеров на текущем узле. Фактическое доступное количество памяти узла можно просмотреть в консоли CCE (Управление ресурсами > Узлы > Выделяемый).

Note

Выделяемые ресурсы рассчитываются на основе значения запроса ресурса (Запрос), который указывает верхний предел ресурсов, которые могут быть запрошены pod‑ами на этом узле, но не указывает фактические доступные ресурсы узла (подробности см. Пример использования квот CPU и памяти). Формула расчёта следующая:

Выделяемый CPU = Общий CPU – Запрошенный CPU всех pod‑ов – Зарезервированный CPU для других ресурсов
Выделяемая память = Общая память – Запрошенная память всех pod‑ов – Зарезервированная память для других ресурсов

Пример использования квот CPU и памяти

Предположим, что кластер содержит узел с 4 ядрами CPU и 8 ГиБ памяти. В кластере развернуты два 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 и памяти узла выглядит следующим образом:

Выделяемые CPU = 4 ядра – (1 ядро, запрошенное pod 1 + 2 ядра, запрошенное pod 2) = 1 ядро
Выделяемая память = 8 GiB – (1 GiB, запрошенный pod 1 + 2 GiB, запрошенный pod 2) = 5 GiB

В этом случае оставшиеся 1 ядро и 5 GiB могут быть использованы следующим новым pod.

Если pod 1 находится под высокой нагрузкой в пиковые часы, он будет использовать больше CPU и памяти в пределах лимита. Поэтому фактические выделяемые ресурсы меньше, чем 1 ядро и 5 GiB.

Квоты других ресурсов

Как правило, узлы поддерживают локальное временное хранилище, которое предоставляется локальными монтируемыми записываемыми устройствами или ОЗУ. EV не гарантирует долговременную доступность данных. Pods могут использовать локальные EV для буферизации данных и хранения журналов, либо монтировать тома emptyDir в контейнеры. Подробности см. Локальное временное хранилище.

Kubernetes позволяет указать запрошенное значение и лимит для временного хранилища в конфигурациях контейнеров, чтобы управлять локальным временным хранилищем. Для каждого контейнера в pod можно настроить следующие атрибуты:

spec.containers[].resources.limits.ephemeral-storage

spec.containers[].resources.requests.ephemeral-storage

В приведённом примере pod содержит два контейнера. Запрошенное значение локального временного хранилища для каждого контейнера составляет 2 GiB, а лимит — 4 GiB. Следовательно, запрошенное значение pod для локального временного хранилища равно 4 GiB, лимит — 8 GiB, а том emptyDir использует 500 MiB локального временного хранилища.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: container-1
    image: <example_app_image>
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: container-2
    image: <example_log_aggregator_image>
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir:
        sizeLimit: 500Mi

Родительская тема: Настройка нагрузки

Предыдущая статья

Использование сторонних образов

Следующая статья

Настройка параметров жизненного цикла контейнера

Эта статья полезна?

Поддержка Юридические документы