[EKS + NLB 연동 시 Ingress Controller 구성 전략 비교]

✅ 방법 1. externalTrafficPolicy: Cluster 사용

🔧 개념

Kubernetes 서비스에서 externalTrafficPolicy 값을 Cluster로 설정하면,
요청을 받은 노드가 해당 요청을 클러스터 내부의 다른 노드로 프록시 전달합니다.

💡 장점

• Pod가 없는 노드도 헬스체크에 응답 가능
• 모든 노드를 Target Group에 연결해도 헬스체크 healthy 유지
• 구성 단순하고 Terraform 자동화에 매우 적합

⚠ 단점

• 클라이언트 IP가 Ingress Controller에 전달되지 않음
  → 대신 X-Forwarded-For 헤더로 IP를 복원할 수 있음

💬 실무 사용도

✅ 가장 많이 사용되는 방식
→ 자동화에 유리하고, 안정성 및 운영 편의성이 높아 실무에서 가장 일반적으로 채택됩니다.

---

✅ 방법 2. Pod가 있는 노드만 Target Group에 연결

🔧 개념

Ingress Controller Pod가 실제로 배치된 노드만 Target Group에 연결하여,
해당 노드에서만 헬스체크에 응답하도록 구성합니다.

💡 장점

• 클라이언트 IP 보존 가능 (externalTrafficPolicy: Local 사용 시)
• 보안/로깅이 중요한 환경에 적합

⚠ 단점

• Pod의 위치를 Terraform으로 동적으로 추적하기 어려움
• Pod가 재배치되면 수동 조치 필요

💬 실무 사용도

⚠ 제한적으로 사용
→ 보안이 민감하거나 고정 IP 기반 필터링이 필요한 서비스에서만 고려

---

✅ 방법 3. DaemonSet으로 Ingress Controller 배포

🔧 개념

Ingress Controller를 DaemonSet으로 배포하여, 모든 노드에 Pod가 항상 존재하도록 합니다.
→ 어떤 노드에서도 헬스체크 응답 가능

💡 장점

• 모든 노드에서 헬스체크 통과
• externalTrafficPolicy: Local + IP 보존도 가능

⚠ 단점

• 운영 복잡도 증가 (모든 노드에 Pod 상주)
• 리소스 낭비 가능성
• Helm 기본 배포 방식 아님

💬 실무 사용도

🔍 잘 사용되지 않음
→ 소규모 테스트나 특수한 요구사항이 있는 경우만 선택

---

✅ 결론: 실무 추천

구성 방식실무 선호도특징

방법 1: externalTrafficPolicy: Cluster	⭐⭐⭐⭐⭐ (가장 일반적)	안정성 + 자동화 친화적
방법 2: Pod 위치 기반 TG 구성	⭐⭐	보안 중심 환경에서 제한적 사용
방법 3: DaemonSet 배포	⭐	드문 선택, 테스트나 특수 구성에 사용

 

---

✨ 실전 팁

• 클라이언트 IP가 필요하다면: 방법 1 + X-Forwarded-For 헤더 복원 설정(real_ip_header)으로 대부분 해결 가능
• Terraform 자동화를 우선시한다면: 방법 1이 가장 실용적