Limit не заменяет реалистичный request. Увеличение лимита не гарантирует место для нового Pod, а низкая фактическая загрузка не отменяет уже учтённые запросы планировщика.
Почему это важно
Одинаковое слово limit скрывает разные причины отказа. Узкий лимит CPU способен увеличить задержку, а нехватка памяти — прервать обработку. До покупки более мощного сервера проверьте срабатывание лимитов: установленная квота не вырастет вместе с оборудованием.
Что подтверждено
Kubelet передаёт ограничения среде выполнения. В обычной конфигурации Linux CPU ограничивается квотой времени, а ограничение памяти применяется реактивно и может вызвать завершение из-за нехватки памяти.
Граница применимости: CPU и память контейнеров Kubernetes в Linux; конкретные механизмы зависят от конфигурации узла.
Limit ограничивает выполнение, request участвует в размещении. Если запрос отсутствует, его иногда получают из лимита по правилам умолчаний; это не делает две величины одним понятием.
Граница применимости: Запросы, ограничения и умолчания ресурсов Kubernetes.
Достижение лимита CPU обычно заставляет контейнер ждать доступного процессорного времени, а не завершает его. Приложение может медленно отвечать даже при свободных CPU вне его квоты.
Граница применимости: Обычное ограничение CPU контейнера через периодическую квоту Linux.
Лимит памяти не работает как очередь на CPU: если освобождения памяти недостаточно, ядро может завершить процесс. Последующий перезапуск зависит от политики контейнера и не устраняет причину повторного превышения.
Граница применимости: Ограничения памяти Kubernetes в Linux и политика перезапуска контейнера.
Ограничение памяти не является обещанием, что измеренное потребление ни на мгновение не превысит число в конфигурации. Принудительное завершение — реакция на давление памяти, а не предварительное резервирование каждого байта.
Граница применимости: Реактивное применение лимита памяти Kubernetes в Linux.
Сумма лимитов памяти может превышать память узла, потому что размещение учитывает запросы. Одновременный рост нескольких контейнеров способен создать давление памяти; наличие индивидуальных лимитов не доказывает достаточный общий запас.
Граница применимости: Размещение по requests и применение limits в Kubernetes; суммарный расход проверяется под совместной нагрузкой.
Не путать
Limit — настройка Kubernetes, cgroup — один из механизмов ядра Linux, который её реализует. Для объяснения задержки или завершения нужны не только числа в конфигурации, но и события на узле.
Что проверить
- Проверьте отдельно request и limit каждого ресурса в сохранённой конфигурации.
- Сопоставьте ожидание квоты CPU с задержкой пользовательских запросов.
- При завершении процесса выясните, было ли событие OOM и какой предел сработал.
- Проверьте политику перезапуска и повторяется ли причина отказа.
- Испытайте одновременную пиковую нагрузку соседних контейнеров.
- Сравните суммарный расход памяти с доступными ресурсами узла, а не только с суммой лимитов.
- После смены оборудования повторите испытание с теми же квотами.
Первоисточники
Resource Management for Pods and Containers
Kubernetes · Kubernetes current documentation
Разделяет запросы и ограничения CPU и памяти: их учёт при размещении, распределение процессорного времени и применение пределов на узле.
Открыть первоисточникControl Group v2
The Linux Kernel documentation · Linux kernel latest documentation
Описывает иерархическое распределение ресурсов, контроллеры, ограничения, учёт потребления и пространство имён cgroup.
Открыть первоисточникPod Lifecycle
Kubernetes · Kubernetes current documentation
Описывает назначение узла, состояния Pod и контейнеров, перезапуски контейнеров и создание нового Pod с другим UID взамен прежнего.
Открыть первоисточник