IT 技書の森

Pod Disruption Budget

Kubernetes でメンテナンス時に同時に停止できる Pod 数を制限し、サービスの可用性を保証するリソース

Kubernetes可用性

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 を使うことで回避できる。

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

関連用語