Pod Disruption Budget

Pod Disruption Budget とは

Pod Disruption Budget (PDB) は、Kubernetes でノードのメンテナンスやクラスターアップグレードなどの自発的な中断 (Voluntary Disruption) 時に、同時に停止できる Pod 数を制限するリソースである。PDB がなければ、kubectl drain で全 Pod が一斉に退避し、サービスが完全に停止する可能性がある。

Kubernetes 1.4 で beta として導入され、1.21 で policy/v1 として GA になった。本番環境で Kubernetes を運用するなら、ステートレスな API サーバーであっても PDB の設定は必須と考えてよい。

基本的な設定

基本的な設定の例を示す。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
  namespace: production
spec:
  minAvailable: 2        # 最低 2 つの Pod が常に稼働
  selector:
    matchLabels:
      app: api

この設定により、app: api ラベルを持つ Pod のうち、常に最低 2 つが稼働していることが保証される。3 Pod 中 1 Pod のドレインは許可されるが、2 Pod 目のドレインは 1 Pod 目が復帰するまでブロックされる。

minAvailable と maxUnavailable の使い分け

PDB には 2 つの指定方法がある。両方を同時に指定することはできない。

設定	意味	5 Pod の場合	適するケース
minAvailable: 3	最低 3 Pod が稼働	同時に 2 Pod まで停止可	最低稼働数が明確な場合
maxUnavailable: 1	最大 1 Pod が停止	同時に 1 Pod まで停止可	ローリング更新と合わせる場合
minAvailable: "80%"	80% が稼働	同時に 1 Pod まで停止可	Pod 数が動的に変わる場合

実務では maxUnavailable: 1 が最も使いやすい。Pod 数が HPA (Horizontal Pod Autoscaler) で動的に変わる環境でも、「同時に 1 つまで」という制約が直感的に機能する。一方、minAvailable を絶対数で指定すると、スケールダウン時に PDB が邪魔をして Pod を削除できなくなるケースがある。

Voluntary Disruption と Involuntary Disruption

PDB が保護するのは Voluntary Disruption (自発的な中断) のみだ。

種類	例	PDB で保護
Voluntary	kubectl drain、クラスターアップグレード、Cluster Autoscaler のスケールダウン	される
Involuntary	ノードのハードウェア障害、カーネルパニック、OOM Kill	されない

ノードが突然クラッシュした場合、PDB は関与しない。Involuntary Disruption への対策は、Pod Anti-Affinity で Pod を複数ノードに分散させることだ。

PDB がないとどうなるか

PDB を設定していないと、kubectl drain がすべての Pod を同時に退避させる。3 台のノードに 3 Pod が分散していても、2 ノードが同時にドレインされると 2/3 の Pod が停止し、サービスが劣化する。

EKS のマネージドノードグループのアップグレードでは、ノードが順次ドレインされる。PDB がなければ、アップグレード中にサービスが断続的にダウンする。

実務での設定指針

ステートレスな API サーバー

spec:
  maxUnavailable: 1

1 Pod ずつ停止し、新しいノードで起動してから次の Pod を停止する。レプリカ数が 3 以上であれば、常に 2 Pod 以上が稼働する。

StatefulSet (データベース、キャッシュ)

spec:
  minAvailable: 2

クォーラムを維持するため、過半数の Pod が常に稼働していることを保証する。3 ノードの etcd クラスターなら minAvailable: 2 で、1 ノードずつのメンテナンスが可能になる。

バッチ処理 / CronJob

PDB なしでも可。中断されてもリトライで対応できる設計にする。ただし、長時間実行のバッチで中断コストが高い場合は PDB を設定する。

よくある落とし穴

minAvailable をレプリカ数と同じにする

minAvailable: 3 でレプリカ数も 3 の場合、1 Pod も停止できなくなる。kubectl drain が永遠にブロックされ、ノードのメンテナンスが不可能になる。必ずレプリカ数より小さい値を設定する。

HPA との競合

minAvailable を絶対数で指定し、HPA がスケールダウンしようとすると、PDB が Pod の削除をブロックする。パーセンテージ指定 (minAvailable: "80%") か maxUnavailable を使うことで回避できる。

より深く学ぶには関連書籍が役立つ。