Что такое Pod Disruption Budget?

Что такое Pod Disruption Budget (PDB)?

Pod Disruption Budget (PDB) — это объект Kubernetes, который позволяет администраторам контролировать допустимый уровень добровольных сбоев (voluntary disruptions) для приложений, работающих в виде набора подов. PDB не защищает от недобровольных сбоев (involuntary disruptions), таких как сбои узлов или аппаратные отказы. Его основная цель — обеспечить высокую доступность (HA) приложения во время плановых операций обслуживания инфраструктуры, таких как обновление узлов, масштабирование кластера вниз или изменения конфигурации.

Ключевые аспекты Pod Disruption Budget

Основная функция: PDB гарантирует, что во время добровольных нарушений работы (например, дренирование узла при обновлении) определенное количество подов приложения останется доступным или, наоборот, будет разрешено остановить определенное количество подов.

Параметры PDB:

• .spec.minAvailable: Определяет минимальное количество подов (или процент от общего числа), которые должны оставаться доступными во время нарушения. Это "защитная" стратегия.
• .spec.maxUnavailable: Определяет максимальное количество подов (или процент), которые могут быть недоступны одновременно. Это более агрессивная стратегия, часто используемая для развертываний.

Важно: Задается только один из этих параметров. Они взаимоисключающие.

Примеры PDB в YAML

Пример 1: Гарантия минимальной доступности

Допустим, у нас есть развертывание с 10 подами, и мы хотим гарантировать, что как минимум 8 из них всегда будут работать.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 8 # Абсолютное число
  selector:
    matchLabels:
      app: my-critical-app

Или в процентном выражении:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb-percent
spec:
  minAvailable: 80% # Процент от общего числа подов, соответствующих селектору
  selector:
    matchLabels:
      app: my-critical-app

Пример 2: Ограничение максимальной недоступности

Для StatefulSet из 3 подов мы можем разрешить остановку только одного пода за раз.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zookeeper-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: zookeeper

Как это работает на практике?

1. Планирование операции: Когда администратор или автоматизированный инструмент (например, kubectl drain) инициирует операцию, вызывающую добровольный сбой (например, вывод узла из эксплуатации), система Kubernetes проверяет PDB, соответствующие подам на этом узле.
2. Проверка условий: Система вычисляет, можно ли "выселить" (evict) поды с узла, не нарушив условия minAvailable или maxUnavailable, заданные в PDB.
3. Контролируемая эвакуация: Если эвакуация пода нарушит PDB, операция блокируется. Пода не удаляют до тех пор, пока оператор вручную не изменит PDB или пока другие поды не будут перезапущены и станут готовыми, чтобы снова выполнить условие PDB.
4. Поочередное вытеснение: В результате гарантируется, что поды приложения выводятся из эксплуатации не все сразу, а по одному или небольшими контролируемыми группами, что минимизирует влияние на конечных пользователей.

Важные соображения и best practices

• Селекторы должны совпадать с лейблами вашего рабочего ресурса (Deployment, StatefulSet). Это связывает PDB с конкретным приложением.
• PDB не создает поды. Он только контролирует, сколько из существующих подов можно удалить. Для поддержания доступности вам по-прежнему необходимы механизмы восстановления, такие как ReplicaSet или StatefulSet controller.
• Используйте PDB для критически важных приложений, где важна непрерывность работы. Для нефункциональных подов (например, jobs, одноразовых задач) он обычно не нужен.
• Правильный выбор стратегии:

    *   `minAvailable`: Хорош для stateful-приложений (базы данных, очереди), где важно сохранить кворум или большинство реплик.
    *   `maxUnavailable`: Чаще используется для stateless-приложений (веб-серверы, API), развернутых через Deployment, так как позволяет быстрее проводить обновления узлов.

• PDB не является панацеей. Он не защищает от сбоев узлов, сетевых проблем или ошибок в самом приложении. Это лишь один из инструментов в стратегии обеспечения отказоустойчивости, наряду с readiness/liveness пробами, репликацией и распределением подов по узлам (anti-affinity).

Итог: Pod Disruption Budget — это мощный механизм управления доступностью, который позволяет инженерам декларативно задавать правила для плановых операций технического обслуживания Kubernetes-кластера, обеспечивая предсказуемое и безопасное поведение развернутых приложений. Его внедрение является стандартной практикой для production-сред, где требуется соблюдение SLA по доступности.