ㅈㅇㅇ

좋은 포인트예요 👍 제가 간단히 ClusterIP / NodePort / LoadBalancer 각각이 kube-proxy 입장에서 어떻게 iptables (혹은 IPVS) 규칙으로 표현되는지 정리해드릴게요.

---

1. ClusterIP

서비스에 클러스터 내부 전용 가상 IP 부여.

iptables NAT 테이블에 아래와 같은 규칙이 생김:

-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp --dport 80 -j KUBE-SVC-XXXXX
-A KUBE-SVC-XXXXX -m statistic --mode random --probability 0.5 -j KUBE-SEP-AAAAA
-A KUBE-SVC-XXXXX -j KUBE-SEP-BBBBB
-A KUBE-SEP-AAAAA -s 10.244.0.5/32 -j DNAT --to-destination 10.244.0.5:8080
-A KUBE-SEP-BBBBB -s 10.244.0.6/32 -j DNAT --to-destination 10.244.0.6:8080

👉 즉, 10.96.0.1:80(ClusterIP:Port) → Pod IP:Port 로 DNAT 변환.

---

2. NodePort

모든 노드에 외부 접근 가능한 포트(예: 30080) 을 열어줌.

iptables 규칙:

-A KUBE-NODEPORTS -p tcp --dport 30080 -j KUBE-SVC-XXXXX

👉 클러스터 외부에서 NodeIP:30080 으로 접근 시, 위와 동일한 Pod 로드밸런싱 규칙(KUBE-SVC-XXXXX)을 타게 됨.

---

3. LoadBalancer

클라우드 환경일 경우 외부 L4 LB 가 붙음.
외부 LB IP → 내부적으로는 결국 NodePort 규칙을 사용.

즉, 클라우드 LB → NodeIP:30080 → iptables → Pod

---

4. ExternalName

kube-proxy iptables 규칙 없음 ❌
그냥 ClusterDNS에서 CNAME 레코드 리턴해서 외부 DNS 이름으로 직접 연결.

---

5. IPVS 모드

iptables 대신 Linux 커널 레벨의 IPVS 테이블 사용.
예시 (ipvsadm -Ln):

TCP  10.96.0.1:80 rr
  -> 10.244.0.5:8080 Masq  1  0  0
  -> 10.244.0.6:8080 Masq  1  0  0

👉 ClusterIP 10.96.0.1:80 로 들어오면 Round Robin(rr) 방식으로 Pod로 전달.

---

📌 정리하자면:

• ClusterIP → iptables/IPVS에서 Pod 로드밸런싱 규칙 생성
• NodePort → NodeIP 특정 포트(30000~32767)를 열어줌 → 내부는 ClusterIP와 동일 처리
• LoadBalancer → 클라우드 L4 LB가 NodePort를 타도록 설정
• ExternalName → kube-proxy 관여 X, DNS 레벨에서 처리

 

 

====

 

중간에 이런저런 것들이 너무 많다