Topology Spread Constraints — Pod를 물리적으로 골고루 흩뿌린다
Kubernetes Ephemeral Containers 및 Pod Topology Spread Constraints 공식 문서 종합 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/workloads/pods/ephemeral-containers, concepts/scheduling-eviction/topology-spread-constraints) Kubernetes 공식문서 Pod Topology Spread Constraints
이 모듈을 다 읽으면
- maxSkew/topologyKey/whenUnsatisfiable 세 필드가 각각 무엇을 통제하는지 설명할 수 있다
- DoNotSchedule(hard)과 ScheduleAnyway(soft)의 차이를 설명할 수 있다
k8s-learn-05에서 다룬 스케줄러의 노드 선택 기준(requests)과 별개로, 그 배정된 Pod들이 물리적으로 얼마나 고르게 흩어져 있는지를 통제하는 Topology Spread Constraints를 정리한다.
세 핵심 필드 — 얼마나 균등할지, 무엇을 단위로 볼지, 못 지키면 어떻게 할지
topologyKey는 노드 라벨의 키를 지정한다 — 같은 라벨·값을 가진 노드들이 하나의 '토폴로지 도메인'으로 묶인다(예: kubernetes.io/hostname이면 노드 하나하나가 도메인, topology.kubernetes.io/zone이면 가용 영역 단위). maxSkew는 그 도메인들 사이에 Pod 개수가 얼마나 불균등해도 되는지의 최대 허용치다(0보다 커야 함) — 값이 1이면 가장 Pod가 많은 도메인과 가장 적은 도메인의 차이가 1개를 넘으면 안 된다는 뜻이다.
핵심 포인트
- topologyKey: 노드 라벨 키 — 같은 라벨값을 가진 노드들이 하나의 토폴로지 도메인(예: hostname=노드 단위, zone=가용영역 단위)
- maxSkew: 도메인 간 Pod 개수 불균형의 최대 허용치(0보다 커야 함) — maxSkew=1이면 가장 많은 도메인과 가장 적은 도메인의 차이가 1개 이하여야 함
whenUnsatisfiable — 못 지키면 아예 막을지, 최선을 다할지
whenUnsatisfiable은 이 균형 조건을 만족하는 노드가 없을 때의 동작을 정한다 — DoNotSchedule(하드 제약)은 조건을 만족 못 하면 스케줄링 자체를 거부한다. ScheduleAnyway(소프트 제약)는 조건을 완전히는 못 지키더라도, 그나마 더 균등해지는 쪽으로 배치를 시도하며 스케줄링을 강행한다. 대표적인 설정 조합은 maxSkew: 1, topologyKey: kubernetes.io/hostname, whenUnsatisfiable: DoNotSchedule로, 노드 단위로 Pod를 최대한 균등하게(불균형 1개 이하) 흩어놓아 한 노드 장애가 전체 가용성에 주는 타격을 줄이는 용도다.
핵심 포인트
- DoNotSchedule(hard): 조건 못 만족하면 스케줄링 자체를 거부 / ScheduleAnyway(soft): 완전히 못 지켜도 더 균등한 쪽으로 시도하며 강행
- 대표 조합(maxSkew:1, topologyKey:kubernetes.io/hostname, whenUnsatisfiable:DoNotSchedule): 노드 단위로 최대한 균등 분산 — 한 노드 장애의 가용성 타격 최소화