일반 서비스 (echo-service)와 Ingress Controller의 차이

 

 

ingress controller 를 nlb를 쓸때 자주 사용하는데 이게 주로 nginx 써드파티를 쓰다보니 자세한 설명이 자주 없더군요.

그래서 일반 service와 nginx controller를 한번 정리해보았습니다.

---

✅ 핵심 차이: 서비스 대상(엔드포인트) 의 구조가 다르기 때문

 

항목	일반 서비스 (echo-service)	Ingress Controller
서비스 대상 (selector)	일반 파드 (예: echo)	NGINX Ingress Controller 자체가 파드 대상
NodePort 요청 시 처리 방식	kube-proxy가 어디든 있는 echo 파드로 라우팅 가능	NodePort → Ingress Pod → 라우팅
외부 트래픽 최종 종착지	echo 파드	NGINX 컨트롤러가 프록시처럼 중간 처리
요청 처리 실패 가능성	낮음 (파드가 떠 있으면 라우팅됨)	NGINX 없으면 포트 열려 있어도 처리 실패 가능

 

---

🎯 왜 echo-service는 Cluster에서 모든 노드 Healthy?

1. kube-proxy 구조 (iptables/ipvs)

• NLB → 특정 노드 IP:NodePort
• kube-proxy가 로컬에 echo 파드가 없어도,
  → Cluster 모드면 클러스터 어디에 있는 echo 파드로 라우팅

즉, 요청 흐름:

 

NLB → Node A (echo 파드 없음) → kube-proxy → Node B (echo 파드 있음) → 응답 OK→ 따라서 모든 노드가 Healthy로 보임.

---

❗ 그런데 NGINX Ingress Controller는 왜 다르게 동작?

NGINX는:

1. NLB 트래픽을 받는 포트가 Ingress Controller Pod에만 열려 있음
2. kube-proxy는 NodePort → Ingress Controller Pod으로 전달하지만,
3. Ingress Controller Pod이 해당 노드에 존재하지 않으면, 요청을 처리할 수 없음

즉, 요청 흐름 실패:

NLB → Node B (Ingress Controller 없음) → NodePort 열려 있음 → kube-proxy: 라우팅 불가 (컨트롤러 Pod 없음) → Connection Refused

---

📌 그래서 구조적으로 다른 점은?

 

 

구조 요소	echo-service	nginx-ingress-controller
NodePort 응답자	echo 파드 (어디든 있음)	Ingress Controller Pod (특정 노드에만 있음)
kube-proxy 경유	가능 (echo 파드 위치만 알면 됨)	불가능 (Ingress Controller가 있어야 응답)
요청 처리 실패 가능성	낮음 (라우팅만 되면 됨)	높음 (프록시 역할 파드가 있어야만 처리 가능)

 

 

---

✅ 결론 요약

externalTrafficPolicy=Cluster에서 echo-service는 파드가 어느 노드든 상관없이 kube-proxy가 라우팅을 처리할 수 있지만,
Ingress Controller는 NodePort 포트를 실제로 열고 있는 Pod이 존재하지 않으면 처리 자체가 불가능하기 때문에 결과가 다르게 보입니다.

→ 그래서 echo-service는 모든 노드가 Healthy로 보이고,
→ NGINX Ingress Controller는 Pod이 있는 노드만 Healthy로 보이는 겁니다.