Что такое requests и limits в Kubernetes? Как они влияют на планирование подов, OOM и троттлинг?
Короткий ответ
- Requests — гарантия и основа для планирования на ноду
- Limits — жёсткий потолок потребления ресурса
- Превышение лимита памяти — OOMKilled контейнера
- Превышение лимита CPU — троттлинг, а не убийство
- QoS-классы: Guaranteed, Burstable, BestEffort — порядок вытеснения
- Без requests scheduler пакует ноды вслепую и начинается eviction
Requests управляют планированием и вытеснением, limits — потолком, и для памяти их несоблюдение заканчивается OOMKilled.
Как сказать вслух
пример ответаRequests — это сколько ресурсов под запрашивает гарантированно: именно по ним планировщик выбирает ноду. Limits — потолок: если контейнер превысит лимит по памяти, его убьёт OOM-killer, а по процессору он просто будет затроттлен. От сочетания requests и limits зависит QoS-класс пода, то есть кого ядро и kubelet вытеснят первым при нехватке ресурсов. Я всегда выставляю requests по реальному профилю потребления, иначе ноды переподписываются и начинаются каскадные вытеснения.
Подробный ответ
Основной ответ
Requests учитываются только при планировании: scheduler размещает под на ноду, где сумма requests не превышает allocatable, — фактическое потребление не проверяется. Limits транслируются в cgroups: по памяти это жёсткая граница, за которой контейнер получает OOMKilled (exit code 137); по CPU — квота CFS, превышение даёт троттлинг и рост латентности. QoS-классы: Guaranteed (requests равны limits по всем ресурсам), Burstable (requests меньше limits), BestEffort (ничего не задано) — в этом порядке, с конца, kubelet вытесняет поды при давлении на ноду. Типовые практики: обязательные requests по памяти и CPU, лимит по памяти равный request, лимит по CPU часто не ставят, чтобы избежать троттлинга; LimitRange и ResourceQuota — на уровне namespace.
Ключевые моменты
- Планирование по requests. Scheduler смотрит только на заявленные requests, поэтому заниженные значения ведут к переподписке нод.
- Память vs CPU. Память — несжимаемый ресурс (OOMKill), CPU — сжимаемый (троттлинг); отсюда разные стратегии лимитов.
- QoS и eviction. BestEffort-поды вытесняются первыми; критичным сервисам задают Guaranteed.
- Подбор значений. Опираться на фактические метрики потребления; VPA в режиме рекомендаций помогает калибровать.
Практический контекст
Это вопрос, по которому легко отличить человека с реальным опытом эксплуатации: за OOMKilled, CPU-троттлингом и вытеснениями стоят именно эти настройки. На практике разборы «сервис периодически перезапускается с кодом 137» или «латентность растёт под нагрузкой» почти всегда упираются в limits. Интервьюер ждёт не определения, а понимания последствий каждой комбинации.
Частые ошибки
- Считают, что при превышении CPU-лимита контейнер убивается
- Не знают, что планировщик смотрит на requests, а не на фактическое потребление
- Не могут объяснить QoS-классы и порядок вытеснения подов