Pod Anti-Affinity와 Topology Spread Constraints

둘의 역할 비교

기능	목적	사용 예	제어 방식
Pod Anti-Affinity	특정 파드와 같은 노드에 배치되지 않도록 제한	같은 앱의 파드를 노드에 1개씩만 배치	제한적 (제한 위주)
Topology Spread Constraints	파드들을 지정된 범위(노드, 존 등)에 균등하게 분산	파드들을 가능한 한 모든 노드/존에 퍼뜨리기	분산 중심 (정책 기반)

왜 함께 쓰는가?

예시: 고가용성이 중요한 웹 애플리케이션

목표:

•

동일한 앱의 파드가 한 노드/존에 몰리지 않게

•

장애가 발생해도 다른 노드/존에서 서비스 유지 가능

사용하는 방식

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: myapp
        topologyKey: "kubernetes.io/hostname" # 노드 단위 분산
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: myapp
YAML
복사

결과

•

Pod Anti-Affinity: 동일 노드에는 같은 앱 파드를 두지 않음 → 노드 단위 격리

•

Topology Spread: 전체 가용 영역(zone) 간에 파드를 고르게 분산 → 장애 도메인 간 격리

주의할 점

•

둘 다 너무 강하게 설정하면 → 파드가 Pending 상태에 빠질 수 있음

(특히 클러스터 리소스가 부족하거나 노드 수가 적은 경우)

•

그럴 땐 preferred / ScheduleAnyway로 완화 필요

실전 적용 시 권장 전략

전략	설정
노드 간 분산	Pod Anti-Affinity + topologyKey: kubernetes.io/hostname
Zone 간 분산	TopologySpreadConstraints + topologyKey: topology.kubernetes.io/zone
완화된 조건	TopologySpreadConstraints with ScheduleAnyway, AntiAffinity with preferred

결론

 Pod Anti-Affinity는 강제적인 노드 분산

Topology Spread Constraints는 정책 기반의 범용 분산

둘은 같은 목적(분산 배치)을 추구하지만, 역할과 제어 방식이 달라 보완적으로 함께 사용하는 경우가 많습니다.

특히 대규모 서비스, StatefulSet, ReplicaSet 등에서 많이 활용됩니다.