🚀 Kubernetes Service Networking 완벽 가이드

---

🔥 Pod Networking vs Service Networking

구분	Pod Networking	Service Networking
대상	Pod ↔ Pod	Client ↔ Service (Pod 묶음)
연결 방식	Pod IP 직접 연결	Service IP를 통한 프록시 연결
관리 주체	CNI (Weave, Calico 등)	kube-proxy
목적	Pod 간 통신	안정적이고 동적인 접근 제공

---

🎯 Service가 필요한 이유

• Pod는 수명 주기가 짧음 → 삭제/재생성 시 IP가 변경됨
• 특정 Pod를 직접 IP로 접근하면 불안정
  → Service가 중간 프록시 역할

---

🏗️ Service 동작 메커니즘

✅ Service 생성 시

• Kubernetes가 Service Cluster IP Range 내에서 **가상 IP (ClusterIP)**를 할당
• kube-proxy가 각 노드에서 iptables / IPVS 룰을 생성하여 포워딩 설정

✅ Service는 실체가 없는 Virtual Object

• Pod처럼 Network Namespace나 Interface가 없음
• 단순히 kube-proxy가 관리하는 IP + Port 포워딩 룰에 불과

---

🔗 Service IP 할당 구조

• --service-cluster-ip-range 플래그로 정의
  예) 10.96.0.0/12

• Pod CIDR과 절대 겹치면 안 됨
  예) Pod CIDR 10.244.0.0/16 ↔ Service CIDR 10.96.0.0/12

---

🧠 Service 종류

Type	설명	접근 범위
ClusterIP (기본)	클러스터 내부 IP 할당	클러스터 내부 전용
NodePort	각 노드의 특정 포트 오픈	클러스터 외부 가능
LoadBalancer	클라우드 로드밸런서 연동	외부 접근
ExternalName	클러스터 외부 DNS 이름 매핑	외부 접근

---

🔥 kube-proxy 동작 방식

✅ kube-proxy는 하는 일

• Kube API Server의 Service 정보를 watch
• 각 Node에 iptables 또는 IPVS 룰을 생성
• Service IP → Pod IP 로 포워딩

✅ 프록시 모드 종류

Mode	특징	성능
iptables (기본)	DNAT 룰 기반	중간
ipvs	커널 레벨 L4 로드밸런싱	가장 빠름
userspace	레거시 방식	느림

→ 대부분의 최신 클러스터는 ipvs 사용 권장

---

🔍 iptables 룰 예시 (ClusterIP)

▶️ 구성

• Pod IP: 10.244.1.2
• Service IP: 10.103.132.104 (DB 서비스)

▶️ iptables DNAT 룰

-A KUBE-SERVICES -d 10.103.132.104/32 \
-p tcp -m tcp --dport 3306 \
-j KUBE-SVC-XXXXX

-A KUBE-SVC-XXXXX \
-j KUBE-SEP-YYYYY

-A KUBE-SEP-YYYYY \
-d 10.244.1.2/32 \
-j DNAT --to-destination 10.244.1.2:3306

✔️ 해석:
→ 10.103.132.104:3306 로 들어오는 트래픽을 → 10.244.1.2:3306으로 포워딩

---

🌐 NodePort 동작 구조

• NodePort 서비스 생성 시 각 Node의 지정된 포트(30000~32767)를 엶
• 외부 → NodeIP\:NodePort → Service IP → Pod IP 로 트래픽 전달

iptables 예시:

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

---

🚥 Service IP Range 설정 확인

ps -ef | grep kube-apiserver | grep service-cluster-ip-range

→ 출력 예시:

--service-cluster-ip-range=10.96.0.0/12

---

🛠️ 트러블슈팅 포인트

• Service IP로 Ping 안 됨 → 정상
  (iptables는 L4 레벨에서만 동작)

• NodePort 포트 열려있지 않음 → kube-proxy 상태 확인

• IP 겹침 → Pod CIDR ↔ Service CIDR 충돌 여부 점검

• 서비스 접속 불가 →

  • kubectl get endpoints로 Pod가 정상 연결되었는지 확인

---

🔥 결론

• Service는 실체가 아닌 kube-proxy의 포워딩 룰 집합
• ClusterIP는 내부 통신용, NodePort는 외부 노출
• kube-proxy는 iptables/IPVS를 통해 Service IP → Pod IP로 포워딩
• Pod CIDR과 Service CIDR은 절대 겹치면 안 된다