설명
Deployment의 여러 파드가 같은 노드에 함께 배치되면 단일 노드 장애가 서비스 가용성에 큰 영향을 줄 수 있습니다. 복제 수만 늘린다고 고가용성이 확보되는 것은 아닙니다.
Pod anti-affinity나 topology spread constraints로 분산 요구를 표현할 수 있습니다. 명시적인 anti-affinity가 없다고 실제 파드가 반드시 한 노드에 몰리는 것은 아닙니다.
잠재적 영향
- 동일 노드 장애 시 여러 파드가 함께 영향을 받을 수 있습니다.
- 과도하게 엄격한 배치 조건은 가용 노드가 부족할 때 파드의 시작을 막을 수 있습니다.
해결 방법
- 가용성 요구에 맞춰
pod_anti_affinity또는 topology spread constraints를 구성하고 selector와 노드의 topology 라벨을 확인하세요. - preferred 규칙은 분산을 선호할 뿐 보장하지 않습니다. required 규칙의 스케줄링 제약과 노드 용량을 검토하고 실제 파드 배치를 확인하세요.
예시
필수 컨테이너와 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 없이 복제본 수만 지정합니다. 실제 분산 상태를 확인해야 합니다.
- 변경 후: 같은 앱 라벨의 파드를 서로 다른 hostname에 배치하도록 선호합니다. 기존 파드를 자동으로 재배치하는 규칙은 아닙니다.