Pod Disruption Budget (PDB)

概要

Pod Disruption Budget (PDB) は、Kubernetesクラスターにおいて、アプリケーションの可用性を維持するために、同時に停止してもよいPodの数（または維持すべきPodの数）を制限するリソースです。

ノードのアップグレードやドレイン（排出）などの自発的な中断 (Voluntary Disruptions) が発生した際に、サービスが完全に停止してしまうことを防ぐために使用されます。

なぜPDBが必要なのか

Kubernetesでは、Podが停止する要因として以下の2種類があります。

非自発的な中断 (Involuntary Disruptions)
- ハードウェア障害
- カーネルパニック
- ノードのネットワーク断
- OOM (Out Of Memory) による強制終了
自発的な中断 (Voluntary Disruptions)
- クラスター管理者によるノードのドレイン (kubectl drain)
- クラスターのアップグレード
- オートスケーリングによるノードの縮小

PDBは、主に 2. 自発的な中断 に対して機能します。管理者がメンテナンス作業を行う際、PDBが設定されていれば、Kubernetesはアプリケーションの可用性要件（最低限必要なPod数など）を守りながら、安全にPodを退避させることができます。

PDBの設定パラメータ

PDBでは主に以下の2つのパラメータのいずれかを使用して制限を定義します。

1. `minAvailable` (最小利用可能数)

自発的な中断が発生している間、最低限維持しなければならない Podの数を指定します。

整数値: 絶対数（例: 2）
パーセンテージ: レプリカ数に対する割合（例: 50%）

2. `maxUnavailable` (最大利用不可数)

自発的な中断が発生している間、同時に停止してもよい Podの最大数を指定します。

整数値: 絶対数（例: 1）
パーセンテージ: レプリカ数に対する割合（例: 25%）

提示

一般的に、ステートレスなWebアプリケーションなどでは maxUnavailable を使用し、クォーラム（定足数）が必要なステートフルなアプリケーション（データベースなど）では minAvailable を使用することが推奨されます。

設定例

例1: 常に最低2つのPodを維持する (`minAvailable`)

レプリカ数が3のDeploymentに対して、常に2つ以上のPodが稼働している状態を保証します。

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

例2: 同時に1つまでしか停止させない (`maxUnavailable`)

レプリカ数が変動する場合でも、一度に停止するPodを1つだけに制限します。ローリングアップデートのような挙動をメンテナンス時にも期待する場合に有効です。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb-max-unavailable
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app

AKSにおけるデフォルト設定

AKSクラスターにおけるPDBのデフォルト動作は以下の通りです。

ユーザーワークロード

ユーザーがデプロイするアプリケーション（DeploymentやStatefulSetなど）に対しては、デフォルトでPDBは設定されません。 PDBを明示的に作成しない場合、ノードのアップグレードやドレイン時に、そのノード上のすべてのPodが同時に退避（Eviction）される可能性があります。これにより、一時的なサービス断が発生するリスクがあるため、本番環境ではPDBの設定が強く推奨されます。

システムコンポーネント

AKSが管理する一部のシステムコンポーネント（kube-system 名前空間のリソースなど）には、デフォルトでPDBが設定されています。

CoreDNS: coredns などの重要なシステムPodには、通常 minAvailable: 1 などのPDBが設定されており、クラスターのDNS解決機能が維持されるようになっています。
Konnectivity Agent: これらも同様に可用性が保護されています。

AKSにおける考慮事項

Azure Kubernetes Service (AKS) を使用する場合、以下のシナリオでPDBが重要になります。

AKSクラスターのアップグレード: ノードイメージの更新やKubernetesバージョンのアップグレード時、AKSはノードを順番にドレインして再起動します。PDBを設定しておくことで、このプロセス中にサービスダウンが発生するのを防げます。
クラスターオートスケーラー: ノードのスケールイン（削除）が発生する際、PDBが尊重されます。

注意点

PDBの競合に注意: minAvailable をレプリカ数と同じ値（例: レプリカ数3で minAvailable: 3）に設定すると、Podを1つも停止できなくなり、ノードのドレインやアップグレードがブロックされてしまいます。必ず1つ以上のPodが停止できる余地を残してください。
Deploymentとのラベル一致: PDBの selector は、対象となるDeploymentやStatefulSetのラベルと正確に一致させる必要があります。
単一Podの構成: レプリカ数が1のアプリケーションに対してPDBを設定する場合、maxUnavailable: 0 や minAvailable: 100% を設定すると、そのPodは自発的に停止できなくなります。高可用性が必要な場合は、まずレプリカ数を2以上にすることを検討してください。

まとめ

Pod Disruption Budgetは、Kubernetes運用において「システムの安定性」と「運用の柔軟性（メンテナンス）」のバランスを取るための重要な機能です。本番環境で稼働する重要なワークロードには、必ず適切なPDBを設定することを推奨します。

概要​

なぜPDBが必要なのか​

PDBの設定パラメータ​

1. minAvailable (最小利用可能数)​

2. maxUnavailable (最大利用不可数)​

設定例​

例1: 常に最低2つのPodを維持する (minAvailable)​

例2: 同時に1つまでしか停止させない (maxUnavailable)​

AKSにおけるデフォルト設定​

ユーザーワークロード​

システムコンポーネント​

AKSにおける考慮事項​

注意点​

まとめ​

概要