KubernetesMiddleTechnical

Что такое 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.cpu
  • requests.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 использует порядок вытеснения:

  1. BestEffort — убиваются первыми (oom_score_adj = 1000).
  2. Burstable — те, кто превысили свой requests.memory.
  3. 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

Sources

Related topics