説明
複数の Deployment Pod が同じノードに配置されると、一つのノード障害がサービスの可用性に大きく影響する場合があります。レプリカ数を増やすだけでは高可用性は保証されません。
Pod anti-affinity や topology spread constraints で分散要件を指定できます。明示的な anti-affinity がないからといって、すべての Pod が必ず一つのノードに集中するわけではありません。
想定される影響
- 一つのノード障害で複数のレプリカが同時に影響を受ける場合があります。
- 配置条件が厳しすぎると、利用できるノードが不足した際に Pod を起動できない場合があります。
対処方法
- 可用性要件に合わせて
pod_anti_affinityまたは topology spread constraints を構成し、selector とノードの topology ラベルを確認してください。 - preferred ルールは分散を優先するだけで、保証はしません。required ルールの配置制約、ノード容量、実際の Pod 配置を確認してください。
例
必須のコンテナーや Deployment selector などを省略した配置設定の抜粋です。変更後の weight 100 も優先ルールであり、別々のノードへの配置を強制しません。
変更前
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
template {
metadata {
labels = {
k8s-app = "prometheus"
}
}
spec {
affinity {
pod_anti_affinity {
preferred_during_scheduling_ignored_during_execution {
weight = 100
pod_affinity_term {
label_selector {
match_labels = {
k8s-app = "prometheus"
}
}
topology_key = "kubernetes.io/hostname"
}
}
}
}
}
}
}
}
補足:
- 変更前: レプリカ数だけを指定し、明示的な anti-affinity はありません。実際の分散状態を確認する必要があります。
- 変更後: 同じアプリケーションラベルの Pod を異なる hostname に優先的に配置します。既存の Pod を自動で再配置するルールではありません。