Request участвует в выборе узла, limit ограничивает выполнение. Контейнер может расходовать больше запроса; лимит CPU и лимит памяти при этом применяются по-разному. Для планирования нужны обе величины и измеренное потребление.
Практический смысл
Почему это важно
По низкой текущей загрузке нельзя обещать место ещё одному приложению. Планировщик учитывает заявленные запросы, а каждый Pod должен помещаться на подходящем узле. Слишком большой запрос заставляет покупать лишнюю ёмкость, слишком маленький скрывает будущую конкуренцию за ресурсы.
Доказательная часть
Что подтверждено
Планировщик сравнивает запросы Pod с ресурсами, доступными для выделения на каждом подходящем узле. Текущий низкий расход CPU или памяти не отменяет уже учтённые запросы.
Граница применимости: Планирование CPU и памяти Kubernetes; дополнительные ограничения размещения также действуют.
Request не является измеренным расходом и не задаёт жёсткий потолок. При наличии ресурсов контейнер может использовать больше запроса в пределах применимых ограничений.
Граница применимости: Запросы CPU и памяти обычных контейнеров Kubernetes.
На двух узлах может оставаться по 3 ГиБ для новых запросов, но Pod с запросом 4 ГиБ не поместится ни на одном. Общие 6 ГиБ нельзя выдать одному Pod частями с разных серверов. При закупке проверяйте запас каждого подходящего узла.
Граница применимости: Размещение одного Pod с обычными контейнерами; другие требования уже выполнены, освобождение места не предполагается.
Запрос 500m CPU равен 0,5 CPU, а 1000m — 1 CPU. Это доли вычислительного ресурса Kubernetes, не мегагерцы; одинаковый запрос на разных поколениях серверов не обещает одинаковую скорость приложения.
Граница применимости: Единицы запросов CPU Kubernetes; производительность проверяется на целевой платформе.
В конфигурации памяти 1Gi означает 2 в степени 30 байт, а 1G — 10 в степени 9 байт. Регистр суффикса имеет значение: единицы нужно проверять вместе с числом.
Граница применимости: Единицы количества памяти в Kubernetes.
При расчёте по контейнерным requests запросы обычных одновременно работающих контейнеров складываются. Учитывать только основной контейнер и забыть вспомогательный — значит занизить требования Pod.
Граница применимости: Pod без заданных ресурсов уровня Pod, init-контейнеров и дополнительных накладных расходов. Особые правила вспомогательных контейнеров проверяются отдельно.
Если для ресурса задан limit, но request не указан и никакой механизм допуска не задал другой запрос, Kubernetes копирует limit в request. Поэтому проверяйте сохранённую конфигурацию, а не только исходный файл.
Граница применимости: Умолчание для запросов ресурсов Kubernetes при заданном ограничении.
В Linux запрос CPU участвует не только в выборе узла: по нему среда выполнения задаёт относительный вес контейнера при конкуренции за процессор. Вес не закрепляет ядро и не отменяет квоту CPU.
Граница применимости: Контейнерные запросы CPU Kubernetes при обычном распределении процессорного времени по весам в Linux; выделение эксклюзивных CPU рассматривается отдельно.
Вспомогательный контейнер в initContainers с restartPolicy=Always работает вместе с основными: его requests тоже входят в общую сумму. Во время инициализации к запросу очередного init-контейнера добавляют запросы уже запущенных вспомогательных контейнеров. Для каждого ресурса выбирают большее: максимум этих промежуточных сумм или сумму запросов всех длительно работающих контейнеров.
Граница применимости: Контейнерные requests CPU и памяти Pod с поддержкой вспомогательных init-контейнеров restartPolicy=Always; без заданных ресурсов уровня Pod. Дополнительные накладные расходы Pod прибавляются отдельно; порядок запуска init-контейнеров сохраняется.
Граница терминов
Не путать
Перед спецификацией
Что проверить
- Измерьте потребление приложения на целевой платформе под обычной и пиковой нагрузкой.
- Задайте CPU и память отдельно для всех контейнеров Pod.
- Проверьте единицы: доли CPU, ГиБ и десятичные гигабайты.
- Прочитайте фактически сохранённые requests и limits после применения умолчаний.
- Сравните запрос Pod с остатком ресурсов на каждом допустимом узле.
- Пересчитайте размещение после отказа узла и во время обновления.
- При Pending найдите причину в событиях планировщика, прежде чем увеличивать серверы.
- При конкуренции за CPU проверьте распределение времени по запросам отдельно от срабатывания квоты.
- Включите в расчёт вспомогательные контейнеры в initContainers с restartPolicy=Always: они продолжают работать вместе с основными.
Открытые основания
Первоисточники
Resource Management for Pods and Containers
Kubernetes · Kubernetes current documentation
Разделяет запросы и ограничения CPU и памяти: их учёт при размещении, распределение процессорного времени и применение пределов на узле.
Открыть первоисточникKubernetes Scheduler
Kubernetes · Kubernetes current documentation
Описывает отбор допустимых узлов, оценку вариантов и назначение узла для ещё не размещённого Pod.
Открыть первоисточникControl Group v2
The Linux Kernel documentation · Linux kernel latest documentation
Описывает иерархическое распределение ресурсов, контроллеры, ограничения, учёт потребления и пространство имён cgroup.
Открыть первоисточникSidecar Containers
Kubernetes · документация Kubernetes v1.37, страница открыта 6 сентября 2026 года
Открыт редактором 6 сентября 2026 года, заголовок документа сверен. Вспомогательные контейнеры в initContainers с restartPolicy=Always, совместная работа и учёт запросов ресурсов при инициализации и работе приложения.
Открыть первоисточник