PDB для Application

Что нужно знать перед уроком

M1 урок 2 — множественные реплики Deployment. Этот короткий, но важный урок разбирает PodDisruptionBudget — защиту от одновременного вывода из строя всех реплик приложения при плановом обслуживании узлов.

Теория

Проблема: d8 k drain узла может положить все реплики разом

Плановое обслуживание узла кластера (обновление ОС, замена оборудования) требует drain — вытеснения всех подов с узла перед его выводом из эксплуатации. Без каких-либо ограничений Kubernetes может вытеснить все реплики одного Deployment одновременно, если они случайно оказались на одном и том же узле (или если несколько узлов обслуживаются одновременно) — что приводит к полному простою приложения именно в момент планового, штатного обслуживания инфраструктуры, а не аварии.

Минимальный пример PodDisruptionBudget

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: { { .Application.Instance.Name } }
  namespace: { { .Release.Namespace } }
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: { { .Application.Instance.Name } }

minAvailable: 1 гарантирует, что при любой добровольной эвакуации (voluntary disruption — drain, но не аварийный сбой узла, который PDB не контролирует) как минимум одна реплика с указанным selector останется доступной — Kubernetes API откажет в эвакуации следующей реплики, если это привело бы к нарушению этого условия, вынуждая администратора дождаться восстановления вытесненной реплики на другом узле, прежде чем продолжать drain.

Альтернативная форма — maxUnavailable (вместо minAvailable) — задаёт максимальное допустимое число одновременно недоступных реплик, что удобнее при большом числе реплик (например, maxUnavailable: 1 для Deployment с replicas: 10 эквивалентно minAvailable: 9, но не требует пересчёта при изменении общего числа реплик).

Почему это обязательно именно для приложений с несколькими репликами

Для Application с replicas: 1 PDB с minAvailable: 1 фактически заблокировал бы любую добровольную эвакуацию единственной реплики (поскольку эвакуация нарушила бы условие «минимум 1 доступна») — что противоречит самой цели планового обслуживания узлов. Для однорепличных приложений PDB либо не имеет смысла в этой форме, либо требует minAvailable: 0, что делает его бесполезным. PDB раскрывает свою ценность именно при replicas >= 2 — когда действительно возможно поддерживать доступность подмножества реплик во время эвакуации остальных.

Связь с чек-листом приёмки из M9

PDB — один из пунктов итогового чеклиста приёмки (M9 урок 7): пакет, предназначенный для production-эксплуатации с несколькими репликами, должен включать PDB как часть стандартного, ожидаемого набора ресурсов — наравне с probes, resources requests/limits и другими production-ready атрибутами.

Частые ошибки и подводные камни

• Добавлять PDB с minAvailable, равным общему числу реплик (или большим). Это полностью блокирует любую добровольную эвакуацию — drain узла зависнет, ожидая условия, которое никогда не будет выполнено без ручного вмешательства (временного увеличения числа реплик или удаления/изменения PDB).
• Забывать PDB для приложений с несколькими репликами вообще. Без PDB нет никакой гарантии распределения эвакуации по времени — при неудачном стечении обстоятельств (все реплики на одном узле, требующем обслуживания) приложение может полностью остановиться на время планового обслуживания.
• Путать PDB с гарантией защиты от аварийных сбоев. PDB контролирует только добровольные нарушения (voluntary disruptions, инициированные через Eviction API — drain, cordon+ручная эвакуация) — он не защищает от внезапного аварийного отказа узла (hardware failure), при котором под просто исчезает без возможности для Kubernetes спросить разрешения.

Практика в кластере

1
2

d8 k get pdb -n course-m10-umami
d8 k drain <node-name> --ignore-daemonsets --delete-emptydir-data --dry-run=server

Проверьте через dry-run drain, что PDB пакета Umami корректно блокирует избыточную одновременную эвакуацию его реплик.

Практика разработки

Добавьте PodDisruptionBudget в шаблоны пакета Umami (при replicas >= 2 в values.yaml), с minAvailable: 1, параметризовав селектор через .Application.Instance.Name, аналогично остальным ресурсам пакета.

Шпаргалка команд урока

1
2

d8 k get pdb -A
d8 k drain <node> --dry-run=server    # проверка влияния PDB перед реальной эвакуацией

Вопросы для самопроверки

Рекомендуемая литература

Официальная документация

• kubernetes.io — Pod Disruption Budget
• kubernetes.io — Configure Pod Disruption Budget

Статьи и блоги

• Deckhouse Prom++: оптимизация Prometheus — Flant на Habr.
• Deckhouse Prom++: как мы посадили Prometheus на RAM-диету — Flant на Habr.
• Kubernetes на базе Deckhouse: встроенный мониторинг и логирование — обзор возможностей DKP на Habr.

Книги

• Brendan Burns, David Oppenheimer. Designing Distributed Systems. 2018. ISBN 978-1491983645.
• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

Связанные материалы

• Предыдущий урок: M10.05 — VPA для Application.
• Следующий урок: M10.07 — Storage и данные.

✓ Урок пройден — все вопросы самопроверки отвечены верно