AWS EKS에서 NLB + ingress-nginx 구성 시 가장 많이 쓰는 방식은?

AWS EKS에서 ingress-nginx를 사용할 때 Network Load Balancer(NLB)를 함께 구성하는 경우가 많습니다. 이때 흔히 발생하는 문제가 하나 있습니다.

바로 노드가 오토스케일링 되면서 NLB Target Group에 Unhealthy 노드가 생기는 현상입니다. 이 글에서는 그 이유를 분석하고, 실무에서 가장 많이 사용되는 조합이 무엇인지 정리해보겠습니다.

---

💥 문제 상황 요약

• ingress-nginx는 기본적으로 Deployment 형태로 배포됩니다.
• NLB는 Kubernetes Service의 type: LoadBalancer를 통해 생성되며, 모든 노드의 NodePort를 대상으로 상태검사(Health Check) 를 수행합니다.
• 그런데 Ingress Controller Pod가 일부 노드에만 배포되어 있다면, NLB는 Pod가 없는 노드의 상태검사에 실패하여 unhealthy로 간주합니다.

이런 상황은 특히 노드가 오토스케일링되면서 더 자주 발생합니다.

---

🙅 기존 방식의 한계

1. externalTrafficPolicy: Local

• Pod가 존재하는 노드만 NLB의 Target Group에 등록됩니다.
• 클라이언트 IP를 유지할 수 있다는 장점이 있지만,
• 새 노드가 추가되고 Ingress Pod가 배포되지 않으면, 그 노드는 트래픽을 받아도 처리하지 못하는 문제가 발생합니다.

2. DaemonSet으로 Controller를 배포

• 모든 노드에 하나씩 배포되므로 위 문제는 해결되지만,
• ingress-nginx Helm chart는 Deployment에 최적화되어 있어 DaemonSet으로 변경하면 Helm 업그레이드가 어려워지고 일부 기능 제한이 발생합니다.

---

✅ 많이 쓰는 최적 조합

👉 Deployment + externalTrafficPolicy: Cluster + Proxy Protocol v2

이 조합은 다음과 같은 이유로 가장 많이 사용됩니다.

✅ externalTrafficPolicy: Cluster

• 모든 노드가 NLB의 Target Group에 등록됩니다.
• kube-proxy가 Ingress Controller Pod가 실제 존재하는 노드로 트래픽을 내부 라우팅합니다.
• 노드가 오토스케일링 되더라도 Unhealthy 상태 없이 트래픽 처리 가능.

✅ Proxy Protocol v2 활성화

• Cluster 모드를 사용할 경우, 기본적으로 클라이언트 IP가 사라지는데,
• NLB에서 Proxy Protocol v2를 활성화하면 ingress-nginx가 원본 IP를 복원할 수 있습니다.
• 실무에서는 보안 정책(IP 제어), 정확한 로그 수집, GeoIP 필터링 등을 위해 꼭 필요한 기능입니다.

✅ ingress-nginx는 Deployment 유지

• Helm chart와의 호환성 유지
• HPA 등과의 연동이 쉬움
• 업그레이드 및 커스터마이징에 유리

---

 예시 구성

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
spec:
  type: LoadBalancer
  externalTrafficPolicy: Cluster  # 핵심 설정

 

그리고 NLB에서는 Proxy Protocol v2를 다음과 같이 설정합니다.

• Target Group → Attributes → Proxy Protocol v2: Enabled
• ingress-nginx에는 Proxy Protocol을 파싱하도록 설정 필요:

controller:
  config:
    use-proxy-protocol: "true"

---

🧠 참고 링크

• ergton.com: NGINX ingress with NLB and proxy protocol v2 on EKS
• AWS Github Issue - Health Check 문제
• StackOverflow 실무 사례

---

🧾 마무리 정리

 

항목	내용
Controller 형태	Deployment (Helm 기반)
Traffic Policy	externalTrafficPolicy: Cluster
Pod 배치 전략	minReplicas + podAntiAffinity
Client IP 복원	NLB Proxy Protocol v2 + ingress-nginx 설정
오토스케일링 대응	kube-proxy 라우팅으로 트래픽 손실 방지

 

 

 

---

✅ 결론

EKS + NLB + ingress-nginx 구조에서는 단순히 Pod만 늘리는 것으로는 문제가 해결되지 않습니다.
Deployment + Cluster 모드 + Proxy Protocol v2 조합이 가장 현실적이고 안정적인 실무 구성입니다.