Облачная платформаAdvanced

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

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

Сценарий

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

Запрос и ограничение

Для CPU и Memory значения Request и Limit следующие:

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

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

Например, если задать запрос памяти pod равным 1 GiB и его ограничение — 2 GiB, и pod будет запланирован на узле с 8 GiB памяти (при отсутствии других pod), pod может использовать более 1 GiB памяти при высокой нагрузке, но его использование памяти будет ограничено 2 GiB. Если процесс в контейнере попытается использовать более 2 GiB ресурсов, ядро системы попытается завершить процесс. В результате возникнет ошибка out of memory (OOM).
Note

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

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

В реальных сценариях рекомендуется соотношение Request к Limit около 1:1.5. Для некоторых чувствительных сервисов рекомендуется соотношение 1:1. Если Request слишком мал, а Limit слишком велик, ресурсы узла переиспользуются. Во время пиковых нагрузок память или CPU узла могут быть исчерпаны. В результате узел становится недоступным.
  • Квота CPU: ресурсы CPU измеряются в ядрах. Вы можете указывать количество CPU в десятичной нотации (например, 0.1) или в целой нотации миллиядер с суффиксом m (например, 100m). Обратите внимание, что 0.1 ядра эквивалентно 100m. Однако Kubernetes применяет минимальную гранулярность 1m. В конфигурациях YAML значения с точностью менее 1m (например, 100.1m) автоматически округляются вверх до ближайшего 1m (например, 101m) при создании ресурса.
    Table 1 Квоты CPU

    Параметр

    Описание

    CPU request

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

    CPU limit

    Максимальное количество ядер CPU, доступных для контейнера.

    Recommended configuration

    Фактическое количество доступных ядер CPU на узле ≥ Сумма ограничений CPU для всех контейнеров в pod ≥ Сумма запросов CPU для всех контейнеров в pod. Выполните kubectl describe node, чтобы просмотреть доступные ядра CPU. Подробности см. в Querying Node Allocatable Resources.
  • Квота памяти: единицей измерения ресурсов памяти по умолчанию является байт. Можно также использовать целое число с суффиксом единицы, например, 100 Mi. Обратите внимание, что единица чувствительна к регистру.
    Table 2 Description of memory quotas

    Parameter

    Description

    Memory request

    Минимальное количество памяти, требуемое контейнером. Ресурсы планируются для контейнера на основе этого значения. Контейнер может быть запланирован на узел только тогда, когда общая доступная память на узле больше или равна памяти, запрошенной контейнером.

    Memory Limit

    Максимальное количество памяти, доступное для контейнера. Когда использование памяти превышает настроенный лимит памяти, инстанс может быть перезапущен, что влияет на нормальную работу нагрузки.

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

    Фактическая доступная память на узле ≥ Сумма пределов памяти для всех контейнеров в pod ≥ Сумма запросов памяти для всех контейнеров в pod. Выполните kubectl describe node для просмотра доступной памяти. Подробнее см. Querying Node Allocatable Resources.
Note

Выделяемые ресурсы рассчитываются на основе значения запроса ресурса (Request), которое указывает верхний предел ресурсов, которые могут запрашиваться pod‑ами на этом узле, но не отражает фактические доступные ресурсы узла (подробности см. в Example of CPU and Memory Quota Usage). Формула расчёта выглядит следующим образом:
  • Allocatable CPU = Total CPU – Requested CPU of all pods – Reserved CPU for other resources
  • Allocatable memory = Total memory – Requested memory of all pods – Reserved memory for other resources

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

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

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.

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

Обычно узлы поддерживают локальное ephemeral storage, которое предоставляется локально смонтированными записываемыми устройствами или ОЗУ. EV не гарантирует долгосрочную доступность данных. Pods могут использовать локальные EV для буферизации данных и хранения журналов, либо монтировать тома emptyDir в контейнеры. Для получения подробной информации см. Local ephemeral storage.

Kubernetes позволяет указывать запрашиваемое значение и предельное значение ephemeral storage в конфигурациях контейнеров для управления локальным ephemeral storage. Для каждого контейнера в pod можно настроить следующие атрибуты:
  • spec.containers[].resources.limits.ephemeral-storage
  • spec.containers[].resources.requests.ephemeral-storage

В следующем примере pod содержит два контейнера. Запрошенное значение для каждого контейнера локального ephemeral storage равно 2 GiB, а значение предела — 4 GiB. Следовательно, запрошенное значение pod для локального ephemeral storage составляет 4 GiB, значение предела — 8 GiB, а том emptyDir использует 500 MiB локального ephemeral storage. После создания вы можете выполнить kubectl describe pod для просмотра конфигурации ephemeral-storage.

 
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: container-1
    image: <example_app_image>
     resources:   # Configure local ephemeral storage resources.
       requests: 
         ephemeral-storage: "2Gi" 
       limits: 
         ephemeral-storage: "4Gi" 
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: container-2
    image: <example_log_aggregator_image>
     resources:  # Configure local ephemeral storage resources.
       requests: 
         ephemeral-storage: "2Gi" 
       limits: 
         ephemeral-storage: "4Gi" 
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
       emptyDir:  # Configure an emptyDir volume.
         sizeLimit: 500Mi
Родительская тема: Configuring a Workload
Предыдущая статья
Настройка получения образа без секрета
Следующая статья
Настройка жизненного цикла Контейнера
Поддержка Юридические документы Политика конфиденциальности
© 2026 Cloud.ru