Для чего нужен PodDisruptionBudget и как он взаимодействует с добровольными сбоями (voluntary disruptions)?

Короткий ответ

PodDisruptionBudget (PDB) ограничивает, сколько реплик приложения может быть одновременно недоступно из-за добровольных действий (эвакуация узла, обновление кластера, ручной kubectl drain), не затрагивая непредвиденные сбои вроде падения узла или OOMKilled, которые PDB предотвратить не может.

Как это работает подробнее

PDB задаёт minAvailable или maxUnavailable для набора Pod по селектору; при попытке добровольного выселения (через Eviction API, который используют kubectl drain и Cluster Autoscaler) Kubernetes проверяет, не нарушит ли это условие PDB, и если нарушит — операция блокируется до тех пор, пока ситуация не изменится (например, пока не поднимется замещающий под в другом месте).

Пример кода

manifest.yamlКопировать

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: web-pdb }
spec:
  minAvailable: 2
  selector: { matchLabels: { app: web } }

Что использовать на практике

• Практика. PDB критичен при плановом обслуживании узлов (patching, upgrade) в кластере — без него kubectl drain может единовременно вывести из строя все реплики критичного сервиса, если они случайно оказались на одном узле. PDB не защищает от аппаратного сбоя узла или от OOM — это принципиальное ограничение, которое нужно явно понимать при проектировании отказоустойчивости.

Подводные камни

• Риски. считать, что PDB гарантирует доступность при любом сбое, включая аварийные; выставлять minAvailable, равный общему числу реплик (например, minAvailable: 3 при 3 репликах), что полностью блокирует любую добровольную эвакуацию и мешает плановому обслуживанию кластера; не учитывать PDB при планировании upgrade узлов, из-за чего drain неожиданно "зависает".