본문 바로가기
CLOUD/AWS

AWS EKS NGINX Ingress Controller - hostNetwork에 따른 NLB 헬스체크 정상/비정상 분석

by Rainbound-IT 2025. 8. 6.
반응형

다음은 2~3일간 이론상 ingress 에서 동작해야하는 동작이 동작하지 않을때의 오류 해결입니다...

 

AWS EKS 환경에서 ingress-nginx를 Helm으로 배포하고, type: LoadBalancer와 NLB(Network Load Balancer)를 함께 사용하여 외부 트래픽을 수신하도록 구성했습니다. 이때 externalTrafficPolicy: Local을 설정하여 클라이언트 IP를 보존하는 설정을 적용했습니다.

하지만 이상한 현상이 발생했습니다:

Ingress Controller가 하나의 노드에만 배포되어 있음에도, NLB의 Target Group에서 두 노드 모두 헬스체크가 성공하는 현상 발생.

이는 이론적으로 맞지 않습니다. externalTrafficPolicy: Local이라면 Ingress Controller가 존재하는 노드만 Healthy로 표시되어야 정상입니다. 그렇다면 왜 이런 현상이 발생했을까요?


⚙️ 원인 분석 - hostNetwork = true

문제의 핵심은 Helm values 중 다음 설정이었습니다:

controller:
  hostNetwork: true
 

이 설정은 Ingress Controller 파드가 노드의 네트워크 네임스페이스를 공유하도록 만들어 줍니다. 그 결과:

  • 파드가 노드의 IP 주소와 포트를 그대로 사용
  • NLB가 헬스체크를 수행할 때, 해당 포트로 노드에 접속하면 파드가 없어도 노드가 직접 응답하는 것처럼 동작

즉, NLB 입장에서는 파드가 없어도 노드가 응답 중이므로 Healthy로 판단합니다.


✅ 해결 방법 - hostNetwork = false

위 문제를 해결하기 위해 다음과 같이 설정을 수정했습니다:

controller:
  hostNetwork: false
 

이 설정을 통해:

  • 파드는 자체 IP를 갖고 동작하며, 노드 IP와 포트를 공유하지 않음
  • NLB의 헬스체크가 파드까지 제대로 전달되지 않으면 Unhealthy로 표시됨
  • externalTrafficPolicy: Local 설정 시, 파드가 없는 노드는 헬스체크 실패 → 의도한 대로 동작

변경 후 결과:

  • hostNetwork = false + externalTrafficPolicy: Local
    → ❌ 파드가 없는 노드는 Unhealthy
    → ✅ 파드가 있는 노드는 Healthy
    → ✅ 의도한 대로 동작
  • hostNetwork = false + externalTrafficPolicy: Cluster
    → ✅ 모든 노드 Healthy (kube-proxy가 트래픽 전달함)

 실험 정리


 

설정 조합결과  비고
hostNetwork: true + externalTrafficPolicy: Local 모든 노드 Healthy ❌ 비정상. 노드가 직접 응답
hostNetwork: false + externalTrafficPolicy: Local 파드 없는 노드 Unhealthy ✅ 정상 동작
hostNetwork: false + externalTrafficPolicy: Cluster 모든 노드 Healthy ✅ 정상 동작
 

 실전 팁

  • 운영 환경에서는 hostNetwork: false를 명시적으로 설정하는 것을 권장합니다.
  • hostNetwork: true는 특별한 목적(노드 포트를 직접 써야 하는 경우)이 아니라면 사용을 지양하는 것이 좋습니다.
  • hostNetwork: true 상태에서 NLB의 TCP health check를 사용하면, 파드 상태와 무관하게 노드가 Healthy로 판단되어 문제가 숨겨질 수 있습니다.

 마무리

이번 경험을 통해 NGINX Ingress Controller를 배포할 때 단순히 externalTrafficPolicy만 고려해서는 충분하지 않다는 걸 확인했습니다. hostNetwork 설정은 health check 결과에 직접적인 영향을 줄 수 있으므로 반드시 확인해야 하는 중요한 요소입니다.


 혹시 비슷한 증상을 겪고 있다면, 다음을 점검해보세요:

  • Ingress Controller Helm values의 hostNetwork 값
  • NLB의 Target Group에서의 헬스체크 응답 방식
  • 파드가 어느 노드에 배포되어 있는지
  • externalTrafficPolicy 설정값

 

 

초기에 pod 단위로 lb 안붙일때 했던 설정값이 었는데 이게 기본값으로 들어가다보니 어디가 잘못되었는지 찾기가 너무 어려웟네요...

반응형

댓글