Порядок, в котором Kubernetes будет убивать поды в зависимости от QoS (Quality of Service)

Приоритет завершения подов (Pod Termination Order) в Kubernetes по QoS

В Kubernetes Quality of Service (QoS) — это классификация, определяющая, как система будет управлять ресурсами и завершать поды при нехватке памяти или CPU на узле. Класс QoS напрямую влияет на порядок, в котором kubelet будет завершать поды при возникновении давления на ресурсы узла (Node Pressure), особенно при нехватке памяти (Memory Pressure).

Kubernetes присваивает поду один из трех классов QoS, основываясь на запрошенных (requests) и ограниченных (limits) ресурсах CPU и памяти в его контейнерах:

Три класса QoS (от высшего к низшему приоритету завершения)

1. Guaranteed
2. Burstable
3. BestEffort

Порядок завершения подов при нехватке памяти: от низшего приоритета к высшему. Это означает, что система сначала попытается освободить ресурсы, завершив наименее важные с её точки зрения поды.

Детальное описание классов и логики завершения

1. BestEffort (Наименьший приоритет, завершаются первыми)

Поды, у которых ни один контейнер не имеет установленных запросов (requests) или лимитов (limits) на CPU и память.

• Приоритет завершения: Самый высокий (т.е. их убивают первыми).
• Логика: Эти поды не дают системе никаких гарантий по потреблению ресурсов. При давлении на память они являются наиболее предсказуемыми "кандидатами" на eviction, так как их завершение с наибольшей вероятностью освободит необходимую память, не нарушая SLA других workloads.

apiVersion: v1
kind: Pod
metadata:
  name: best-effort-pod
spec:
  containers:
  - name: nginx
    image: nginx
    # Никаких requests или limits

2. Burstable (Средний приоритет)

Поды, которые не являются ни Guaranteed, ни BestEffort. Обычно это поды, у которых хотя бы у одного контейнера установлен request, но limit либо не установлен, либо превышает request.

• Приоритет завершения: Средний (завершаются после BestEffort, но до Guaranteed).
• Логика: Эти поды имеют минимальные гарантии (requests), но могут использовать больше ресурсов (burst), когда они доступны. При нехватке памяти система сначала убьет BestEffort, а затем начнет выбирать среди Burstable подов. Внутри категории Burstable Kubernetes дополнительно ранжирует поды на основе приоритета потребления памяти относительно их запроса.

apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi" # Limit > Request
        cpu: "500m"

3. Guaranteed (Наибольший приоритет, завершаются последними)

Поды, у которых для каждого контейнера установлены равные значения request и limit для памяти и CPU, и эти значения ненулевые.

• Приоритет завершения: Самый низкий (т.е. их убивают в последнюю очередь).
• Логика: Эти поды имеют строгие, гарантированные лимиты и являются наиболее важными с точки зрения планировщика. Kubelet будет стараться сохранить их работоспособность любой ценой, пока есть другие кандидаты на eviction.

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "256Mi" # Limit == Request
        cpu: "500m"     # Limit == Request

Алгоритм выбора пода внутри одной категории QoS

Когда давление на память возникает и kubelet необходимо завершить поды, он использует следующий детализированный алгоритм:

1. Первичная сортировка по QoS: BestEffort -> Burstable -> Guaranteed.
2. Вторичная сортировка (внутри Burstable и BestEffort): Поды оцениваются по тому, насколько их фактическое потребление памяти превышает их запрос (memory request). Подам, которые потребляют больше всего памяти сверх своего запроса, присваивается более высокий приоритет завершения. Для BestEffort подов запрос считается равным 0.
3. Третичная сортировка: Если поды все еще равны, kubelet может использовать другие эвристики, например, сравнивать приоритет Pod (PriorityClass), но это уже выходит за рамки базовой политики QoS.

Практические выводы и пример

• Для критичных workload всегда используйте Guaranteed QoS. Это максимально защитит их от eviction.
• Для фоновых, некритичных задач можно использовать BestEffort. Это дешевле с точки зрения планирования и явно указывает системе на их низкий приоритет.
• Burstable — это баланс. Подходит для большинства приложений, которым нужна гарантия минимума, но которые могут использовать дополнительные ресурсы в пиковые моменты.

Пример сценария: На узле 4 пода: Pod-A (BestEffort), Pod-B (Burstable, потребляет намного больше memory, чем его request), Pod-C (Burstable, потребляет чуть больше request), Pod-D (Guaranteed). При нехватке памяти порядок завершения будет:

1. Pod-A (BestEffort, первый кандидат).
2. Pod-B (Burstable, самый "расточительный" относительно своего запроса).
3. Pod-C (Burstable, более скромный в потреблении).
4. Pod-D (Guaranteed, будет завершен только в самом крайнем случае).

Таким образом, QoS — это мощный механизм, который позволяет администраторам кластера косвенно управлять важностью workload через настройку запросов и лимитов ресурсов, обеспечивая более предсказуемое и стабильное поведение системы в условиях нехватки ресурсов.