Kubernetes CPU & Memory Requests/Limits – объясняем по-человечески
В Kubernetes YAML разделы requests и limits задают минимальные и максимальные ресурсы пода, и их неверная настройка может вызвать троттлинг CPU, OOMKill и принудительное удаление пода с узла при высоких нагрузках. Грамотная конфигурация этих параметров необходима для корректного шедулинга подов и поддержания стабильности кластера. В статье автор использует сравнение Kubernetes с отелем для наглядного объяснения.
👩💻 Kubernetes можно представить как отель:
Под = гость отеля
Узел = здание отеля с ограниченным количеством ресурсов
⏺ Каждому «гостю» нужно указать:
1. Requests – минимальные ресурсы, необходимые для корректной работы
2. Limits – максимальные ресурсы, которые под может потреблять
⏺ Какая роль здесь отведена CPU?
• Request – гарантированное количество CPU, влияет на планирование, но не ограничивая максимум. Под может использовать больше CPU при наличии свободных ресурсов.
• Limit задаёт жёсткое ограничение на потребление CPU. Превышение лимита приводит к троттлингу.
Итак: request = минимальное количество электричества для работы 💡; limit = предел, который выдержит предохранитель ⚡️.
⏺ Как настроить requests/limits в Kubernetes
Шаг 1: Измеряем среднее и пиковое потребление CPU/памяти (kubectl top pod, Prometheus/Grafana).
Шаг 2: Requests = Среднее × 1.2 → гарантируем стабильную работу без троттлинга.
Шаг 3: Limits = Пик × 1.3–1.5 → оставляем запас, чтобы под не падал из-за OOM.
⏺ Что еще необходимо помнить при задании ресурсов приложению: QoS
Quality of Service (QoS) – это механизм, с помощью которого Kubernetes классифицирует Pods по уровню гарантии ресурсов на основе заданных requests и limits.
• Guaranteed Pods
Под получает строго равные значения request и limit для CPU и памяти. Kubernetes гарантирует, что Pod не будет уничтожен до тех пор, пока не превысит свои лимиты или не будут доступны приоритетные Pods.
• Burstable Pods
Могут использовать ресурсы сверх request при свободных ресурсах узла, но при давлении на узел они уничтожаются после Guaranteed и чаще получают OOMKill.
• BestEffort
Самый низкий уровень QoS: присваивается, если у Pod‑а нет ни requests, ни limits для CPU и памяти. Такие Pods используют остаточные ресурсов узла, и в случае дефицита именно они будут удалены первыми.
🚀 Понимание и правильная настройка параметров requests и limits позволяет избежать непредвиденных завершений подов и поддерживать стабильность работы кластера.
#k8s #requests #limits #cpu
В Kubernetes YAML разделы requests и limits задают минимальные и максимальные ресурсы пода, и их неверная настройка может вызвать троттлинг CPU, OOMKill и принудительное удаление пода с узла при высоких нагрузках. Грамотная конфигурация этих параметров необходима для корректного шедулинга подов и поддержания стабильности кластера. В статье автор использует сравнение Kubernetes с отелем для наглядного объяснения.
Под = гость отеля
Узел = здание отеля с ограниченным количеством ресурсов
1. Requests – минимальные ресурсы, необходимые для корректной работы
2. Limits – максимальные ресурсы, которые под может потреблять
• Request – гарантированное количество CPU, влияет на планирование, но не ограничивая максимум. Под может использовать больше CPU при наличии свободных ресурсов.
• Limit задаёт жёсткое ограничение на потребление CPU. Превышение лимита приводит к троттлингу.
Итак: request = минимальное количество электричества для работы 💡; limit = предел, который выдержит предохранитель ⚡️.
Шаг 1: Измеряем среднее и пиковое потребление CPU/памяти (kubectl top pod, Prometheus/Grafana).
Шаг 2: Requests = Среднее × 1.2 → гарантируем стабильную работу без троттлинга.
Шаг 3: Limits = Пик × 1.3–1.5 → оставляем запас, чтобы под не падал из-за OOM.
Quality of Service (QoS) – это механизм, с помощью которого Kubernetes классифицирует Pods по уровню гарантии ресурсов на основе заданных requests и limits.
• Guaranteed Pods
Под получает строго равные значения request и limit для CPU и памяти. Kubernetes гарантирует, что Pod не будет уничтожен до тех пор, пока не превысит свои лимиты или не будут доступны приоритетные Pods.
• Burstable Pods
Могут использовать ресурсы сверх request при свободных ресурсах узла, но при давлении на узел они уничтожаются после Guaranteed и чаще получают OOMKill.
• BestEffort
Самый низкий уровень QoS: присваивается, если у Pod‑а нет ни requests, ни limits для CPU и памяти. Такие Pods используют остаточные ресурсов узла, и в случае дефицита именно они будут удалены первыми.
#k8s #requests #limits #cpu
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍16🔥6❤5👎1