1. 導入：なぜPDBが必要なのか
Kubernetesクラスタの運用において、ノードのアップグレードやパッチ適用による再起動は避けられません。しかし、インフラ担当者がノードを「drain（退避）」させる際、アプリケーションのPodがすべて終了してしまい、サービスが一時的に停止してしまうケースがあります。この課題を解決するのがPodDisruptionBudget (PDB) です。PDBを活用することで、メンテナンス中であっても「最低限これだけのレプリカ数は維持する」という制約をK8s側に強制でき、可用性を担保しながら安全にインフラ作業を進めることが可能になります。
2. 基礎知識：PDBの仕組み
PDBは「自発的な中断（Voluntary Disruptions）」に対してのみ作用します。具体的には、ノードのdrain操作や、Kubernetes APIによるPodの削除などが対象です。逆に、ノードの突然の電源断やネットワーク障害などの「非自発的な中断」は防ぐことができません。PDBを設定することで、指定したPodセレクタに合致するPodが、指定した数以下に減るような操作をAPIサーバが拒否するようになります。
3. 実装：PDBの定義方法
PDBを設定するには、`minAvailable`（最低稼働数）または `maxUnavailable`（許容する停止数）のいずれかを指定します。一般的に、ステートレスなアプリケーションでは `minAvailable` を指定して一定の負荷耐性を維持し、レプリカ数が多い場合は `maxUnavailable` を使って柔軟に調整することが推奨されます。
4. サンプルプログラム：PDBのマニフェスト例
以下のマニフェストは、`app: web-server` というラベルを持つPod群に対し、常に少なくとも2つのPodが稼働している状態を保証する設定例です。
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: web-server-pdb
spec:
# 常に最低2つのPodが稼働している必要があると指定
minAvailable: 2
# どのPodを対象にするかをラベルで指定
selector:
matchLabels:
app: web-server
5. 応用・注意点：現場での運用Tips
PDBを運用する際に注意すべき点は、「デッドロック」の回避です。例えば、全Pod数が2つしかないのに `minAvailable: 3` を設定してしまうと、ノードのdrain操作が永久に完了しなくなります。また、`maxUnavailable` を設定する際は、現在のレプリカ数と照らし合わせ、メンテナンスの許容時間と可用性のバランスを考慮しましょう。
また、PDBが正しく適用されているか確認するには、`kubectl get pdb` コマンドで `ALLOWED DISRUPTIONS` の値を確認してください。この値が0の場合は、現在これ以上Podを停止させると可用性が損なわれるため、インフラ作業を待機すべきであるというサインになります。計画的なメンテナンスをスムーズに進めるために、ぜひ本番環境のデプロイパイプラインにPDBの作成を組み込んでください。
コメント