Что такое QoS-классы Guaranteed, Burstable и BestEffort, и как они влияют на OOM-kill?
QoS-класс определяется соотношением requests и limits: Guaranteed — requests==limits, Burstable — частичное совпадение, BestEffort — ни то ни другое. При нехватке памяти OOM-killer сначала убивает BestEffort, затем Burstable, Guaranteed — в последнюю очередь.
QoS-классы в Kubernetes
Kubernetes автоматически присваивает каждому поду один из трёх классов Quality of Service (QoS) на основании того, как настроены resources.requests и resources.limits для всех контейнеров в поде.
Guaranteed
Под получает класс Guaranteed, если для каждого контейнера выполняется:
requests.cpu == limits.cpurequests.memory == limits.memory- Оба поля заданы и не равны нулю.
resources:
requests:
cpu: "500m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "256Mi"
Такие поды получают наивысший приоритет: ядра не throttle CPU, а OOM-killer трогает их последними.
Burstable
Класс Burstable присваивается, если хотя бы один контейнер имеет requests или limits, но условие Guaranteed не выполняется (limits > requests, или задано только одно из двух полей).
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
Под может потреблять ресурс сверх requests (до limits), пока они свободны. При конкуренции за CPU — дросселируется, при нехватке памяти — кандидат на OOM-kill после BestEffort.
BestEffort
Класс BestEffort получают поды, у которых ни один контейнер не имеет ни requests, ни limits:
resources: {}
Планировщик размещает такие поды на любом узле с любым количеством свободных ресурсов. Это первые кандидаты на вытеснение.
Механизм OOM-kill
При нехватке памяти на узле kubelet использует порядок вытеснения:
- BestEffort — убиваются первыми (oom_score_adj = 1000).
- Burstable — те, кто превысили свой
requests.memory. - Guaranteed — только если других кандидатов нет.
Конкретное значение oom_score_adj выставляется kubelet-ом. Посмотреть можно так:
cat /proc/$(pgrep -f myapp)/oom_score_adj
Проверить класс пода:
kubectl get pod mypod -o jsonpath='{.status.qosClass}'
Подводные камни
- Init-контейнеры учитываются. Если init-контейнер нарушает условие Guaranteed, под не получит этот класс, даже если основные контейнеры настроены правильно.
- Класс Guaranteed не защищает от eviction при нехватке диска или inodes. OOM-kill и eviction — разные механизмы.
- Limits без requests. Если задан только
limits, Kubernetes устанавливаетrequests == limitsавтоматически — под получит Guaranteed. Это неочевидное поведение. - CPU limits вызывают throttling, не kill. CPU throttling при Burstable-нагрузке часто незаметен в метриках, но увеличивает латентность.
- memory limit = OOM. Превышение лимита памяти немедленно убивает контейнер ядром ОС (SIGKILL), минуя graceful shutdown.
- Namespace ResourceQuota. Если в namespace задана квота, а под не имеет requests/limits — создание пода завершится ошибкой Forbidden.
- VPA сбрасывает класс. Vertical Pod Autoscaler изменяет requests/limits, что может переместить под из Guaranteed в Burstable.
Common mistakes
- Путать OOMKill и eviction
- Не знать критерии Guaranteed
- Считать BestEffort нормой для production
What the interviewer is testing
- Объясняет три QoS класса
- Знает eviction order
- Понимает memory limit behavior