externalTrafficPolicy: Cluster의 문제 발생 원인 (K8S 환경에서)

1. 기본 동작 (Cluster 모드) – K8S 적용

• Service.type: LoadBalancer + externalTrafficPolicy: Cluster → VIP로 들어온 트래픽은 클러스터 내 아무 노드로 들어갈 수 있음.
• 들어온 노드는 kube-proxy가 백엔드 파드가 있는 노드로 트래픽을 리다이렉트(SNAT 포함) 해줌.
• 이 과정에서 클라이언트 IP는 유실되지만, 파드가 어디 있든 간에 서비스 가용성은 유지됨.
• 어느 노드로 바인딩 될지는 사전에 알 수 없음
• 현재 설정 확인
  (default 배포일 경우 아래 명령어 / custom 배포일경우 해당 이름으로 확인) :
  kubectl get svc ingress-nginx-controller -n ingress-nginx -o yaml | grep externalTrafficPolicy

2. MetalLB L2에서 VIP 바인딩 구조

• MetalLB L2는 VIP를 하나의 노드 MAC에 바인딩합니다.
  (즉, 게이트웨이/스위치 ARP 캐시: VIP → Node-A MAC)
• 외부 트래픽은 무조건 **그 노드(Node-A)**로 들어오게 됨.
• Node-A에 파드가 있든 없든 관계없이, kube-proxy가 트래픽을 다시 Cluster 안에서 옮겨 줌.

3. 문제 발생 시나리오

1. 처음에 VIP가 Node-A에 바인딩됨 (VIP → Node-A MAC).
2. Ingress Controller 파드가 Node-B로 스케줄 이동.
   (externalTrafficPolicy: Cluster라서 정상이라면 Node-A → Node-B 리다이렉트 가능해야 함)
3. 하지만 MetalLB가 VIP 소유자를 Node-B로 바꾸면서 **gratuitous ARP(GARP)**를 뿌림.
   • 의도: VIP → Node-B MAC으로 갱신되게 하려는 것.
4. 문제는, 네트워크 장비(스위치/게이트웨이)가 기존 MAC(Node-A)을 계속 기억하거나 GARP를 무시하는 경우.
   • 이 경우 외부 트래픽은 여전히 Node-A로 향함.
5. 그런데 VIP 소유권이 Node-B로 넘어가면서 Node-A는 VIP를 더 이상 받지 않음.
   → 결국 트래픽은 블랙홀.

4. 왜 Cluster인데도 블랙홀이 생기는가?

• Cluster 모드라면 어느 노드에서든 받아서 리다이렉트해야 정상.
• 그런데 MetalLB L2 구조상 VIP는 오직 하나의 노드 MAC만 응답하기 때문에,
  VIP 소유권이 바뀐 순간 기존 노드는 더 이상 ARP 응답을 하지 않음.
• 그럼에도 불구하고 ARP 정보가 옛날 MAC(Node-A)을 바라보고 있으면,
  외부 트래픽은 Node-A로 향하지만 Node-A는 VIP를 무시 → 트래픽 유실.

👉 즉, 문제의 본질은 L2 모드의 ARP 테이블 갱신일 확률이 큼

: 이 경우 igress traffic policy를 local로 변경하고 변경하려는 노드에
ingress pod를 띄워도 문제 해결은 안됨.

5. 해결 포인트

• 네트워크 장비가 GARP를 신뢰하도록 설정 → 네트워크 장비에서 arp clear 필요
• BGP 모드 사용 → VIP를 여러 노드가 동시에 광고, ARP 의존 제거.
  네트워크 장비 핸들링 필요등 복잡해짐..애초에 k8s 초기 구축일 경우면 모르지만
  운영중인 k8s cluster에서 변경하려면 수많은 변수와 오버헤드 발생 가능성 커짐.
  (BGP 에 관해선 다른 글로 자세히 설명드릴 예정)

✅ 정리

• externalTrafficPolicy: Cluster는 기본값이라 안정성이 높아야 하지만,
• MetalLB L2에서는 VIP 소유 노드 교체 시 ARP 테이블 갱신 불가 현상이 생길 수 있음.
• 그래서 Cluster 모드임에도 불구하고 블랙홀이 발생하는 거고,
• 이건 애플리케이션 문제가 아니라 네트워크(L2/ARP) 특성에 기인한 장애일 확률이 큼

🛠 마지막 수정일: 2025.09.18