説明
ノードのドレインなどで複数の Deployment Pod が自発的に退避すると、レプリカがあっても可用性が低下する場合があります。PodDisruptionBudget（PDB）は、Eviction API を使う操作の許容中断数を設定します。
PDB はノード障害や直接の Pod 削除を防がず、Deployment のローリング更新も制限しません。更新戦略と障害領域への分散は別途構成する必要があります。
想定される影響
- メンテナンス中に利用可能なレプリカが不足し、応答の遅延やサービス停止が発生する場合があります。
- 過度な制限は、ノードのドレインやメンテナンスを妨げる場合があります。
対処方法
- 同じ名前空間で実際の Deployment Pod を選択する PDB を定義し、
max_unavailableまたはmin_availableのいずれかを可用性要件に合わせて設定してください。 - readiness、レプリカ数、代替容量を確認してドレインをテストしてください。Deployment のローリング更新と Pod 分散配置も別途確認してください。
例
Pod template などを省略した既存の抜粋です。現在の API には kubernetes_pod_disruption_budget_v1 を使ってください。レプリカが三つの場合、max_unavailable 20% は切り上げにより一つの中断を許可します。
変更前
hcl
resource "kubernetes_deployment" "example" {
metadata {
name = "terraform-example"
labels = {
k8s-app = "prometheus"
}
}
spec {
replicas = 3
}
}
変更後
hcl
resource "kubernetes_deployment" "example" {
metadata {
name = "terraform-example"
labels = {
k8s-app = "prometheus"
}
}
spec {
replicas = 3
selector {
match_labels = {
k8s-app = "prometheus"
}
}
}
}
resource "kubernetes_pod_disruption_budget" "example" {
metadata {
name = "demo"
}
spec {
max_unavailable = "20%"
selector {
match_labels = {
k8s-app = "prometheus"
}
}
}
}
補足:
- 変更前: 三つのレプリカを指定し、PDB はありません。自発的な退避の許容範囲を確認する必要があります。
- 変更後: 実際の Pod ラベルが一致する場合に PDB が適用されます。すべての障害や直接削除に対して最低限の可用性を保証するものではありません。