Request участвует в выборе узла, limit ограничивает выполнение. Контейнер может расходовать больше запроса; лимит CPU и лимит памяти при этом применяются по-разному. Для планирования нужны обе величины и измеренное потребление.
Контейнеры и оркестрация
Запрос ресурсов Kubernetes
Определение
Запрос ресурсов, или request, — заявленная потребность в ресурсе, например CPU или памяти, которую Kubernetes учитывает при размещении Pod. В Linux запрос CPU также влияет на долю процессорного времени при конкуренции. Фактическое потребление и верхний предел limit — другие величины.
Также ищут: Kubernetes request · запрос ресурса Pod · CPU memory request · Resource request
Зачем это знать
По низкой текущей загрузке нельзя обещать место ещё одному приложению. Планировщик учитывает заявленные запросы, а каждый Pod должен помещаться на подходящем узле. Слишком большой запрос заставляет покупать лишнюю ёмкость, слишком маленький скрывает будущую конкуренцию за ресурсы.
Связи из словаря
Карта понятия
Запрос ресурсов Kubernetes
Сравнить
Связано
Доказательная часть
Что подтверждено
Планировщик сравнивает запросы 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: они продолжают работать вместе с основными.
Открытые основания
Первоисточники
- Kubernetes Scheduler
Описывает отбор допустимых узлов, оценку вариантов и назначение узла для ещё не размещённого Pod.
- Control Group v2
Описывает иерархическое распределение ресурсов, контроллеры, ограничения, учёт потребления и пространство имён cgroup.
Утверждения: 08
- Sidecar Containers
Открыт редактором 6 сентября 2026 года, заголовок документа сверен. Вспомогательные контейнеры в initContainers с restartPolicy=Always, совместная работа и учёт запросов ресурсов при инициализации и работе приложения.
Утверждения: 09