requests — сколько ресурсов зарезервировать: по ним планировщик выбирает узел. limits — потолок: превышение памяти → контейнер убивают (OOMKilled, код 137), превышение CPU → троттлинг (процесс притормаживают, но не убивают). Requests слишком малы — узлы переполнены и поды мешают друг другу; слишком велики — кластер простаивает.
А ещё Для JVM размер кучи задают долей от лимита (MaxRAMPercentage), а не жёстким -Xmx
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Как работает CPU-лимит. Лимит реализован квотой CFS: за период 100 мс контейнер может использовать limit × 100 мс процессорного времени. Многопоточное приложение с лимитом 1 CPU, запустив 8 потоков, исчерпает квоту за 12,5 мс и будет стоять до конца периода — задержки p99 растут. Метрика: container_cpu_cfs_throttled_periods_total.
Память. Превысить лимит нельзя: cgroup вызывает OOM, kubelet перезапускает контейнер. Учитывается вся память процесса: куча, метаспейс, стеки потоков, буферы вне кучи, page cache частично.
QoS:
| класс | условие | выселяется |
|---|---|---|
| Guaranteed | requests = limits для всех ресурсов | последним |
| Burstable | requests заданы, меньше limits | в середине |
| BestEffort | ничего не задано | первым |
Подбор значений: по фактическому потреблению за неделю (p95 + запас), Vertical Pod Autoscaler в режиме рекомендаций, LimitRange и ResourceQuota на namespace.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto