7-2. [Architecture]: Networking - Service Network

드디어 네트워킹 아키텍처의 마지막 퍼즐 조각인 서비스 네트워크(Service Network)와 이를 실질적으로 구현하는 프록시 모드(Proxy Mode)를 파헤칠 시간이다.

 

앞서 배운 파드 네트워크가 '실제 데이터가 흐르는 혈관'이라면, 서비스 네트워크는 그 흐름을 목적지로 정확히 굴절시키는 '교차로와 신호등'과 같다.

---

 

1. 서비스 네트워크의 핵심: 프록시 모드 (Proxy Mode)

서비스는 실제 파드로 트래픽을 전달하기 위해 가상의 IP(Cluster IP)를 사용하며, 이 연결의 실체는 당연히 엔드포인트(Endpoint) 오브젝트와 각 노드의 큐브 프록시(kube-proxy)에 의해 관리된다. 그리고 이전에 알아본 파드 네트워크 단(Pod Network Area)으로 넘어가 과정이 그대로 진행되어서 서비스 간 네트워크가 이루어지는 것이다.

 

서비스 프록시의 3가지 진화 단계

모드	작동 방식	특징 및 단점
Userspace	iptables가 트래픽을 kube-proxy 프로세스로 보내고, 여기서 다시 파드로 전달함	모든 트래픽이 프록시를 거쳐야 하므로 성능과 안정성이 낮아 현재는 거의 쓰이지 않음
iptables	kube-proxy가 직접 iptables에 매핑 정보를 등록하고, 커널 레벨에서 바로 변환함	쿠버네티스의 기본 모드이며, 유저스페이스 모드보다 성능과 안정성이 훨씬 뛰어남
IPVS	리눅스의 L4 로드 밸런서(ipvs)를 사용하여 IP 테이블과 같은 역할을 수행함	낮은 부하에서는 iptables와 비슷하지만, 고부하 상태에서 성능이 가장 우수함

 

---

 

 

2. 캘리코(Calico) 환경에서의 서비스 트래픽 흐름

캘리코 플러그인을 사용할 때, 서비스 타입에 따라 트래픽이 어떻게 흐르는지 상세히 살펴보자.

 

2-1. ClusterIP 타입 (내부 통신)

파드 D에서 파드 B의 서비스 IP(10.103.9.116)를 호출할 때의 과정이다.

1. NAT 호출: 파드 D가 서비스 IP로 트래픽을 보내면, 노드의 라우터 영역에 있는 NAT(iptables/IPVS) 기능이 이를 가로챈다.
2. IP 변환: NAT 영역에서 서비스 IP가 실제 목적지인 파드 B의 IP(20.111.156.7)로 변환된다.
3. 오버레이 캡슐화: 변환된 파드 IP는 이제 앞서 배운 파드 네트워크 단(Pod Network Area)으로 넘어가, 오버레이 네트워크(IPIP 등)를 통해 캡슐화되어 노드 간 이동을 시작한다.

2-2. NodePort 타입 (외부 접속)

외부 사용자가 특정 노드의 호스트 IP와 포트(예: 38080)로 접속할 때의 과정이다.

1. 포트 오픈: 모든 노드의 kube-proxy가 자신의 노드에 3만 번대의 노드 포트를 열어둔다.
2. 트래픽 유입: 외부 트래픽이 호스트 포트로 들어오면, 노드의 iptables가 이를 감지하여, 캘리코 네트워크 플러그인으로 전달한다.
3. NAT 및 배달: 캘리코 영역에서 다시 이전 과정(NAT 기능)을 통해 해당 서비스와 매칭되는 최종 파드 IP로 변환되며, 이후 파드 네트워크 영역을 통해 최종 목적지에 도달한다.

---

 

3. 요약: 서비스 네트워크 아키텍처의 정체

• 설정의 집합: 서비스는 물리적인 장치가 아니라 NAT 영역 내의 설정(iptables/IPVS rules)이다.
• API 서버의 제어: 서비스를 생성/삭제하면 API 서버가 이를 감지하고 전 노드의 kube-proxy에 명령하여 이 설정을 실시간으로 업데이트한다.
• 협업 구조: 서비스 네트워크(NAT 설정)가 길을 꺾어주면, 파드 네트워크(Calico/CNI)가 실제로 짐을 나르는 구조다.

 

 

 

 

💡 팁

 

• 네트워킹 트러블슈팅을 할 때 "핑(Ping)이 왜 안 가지?"라고 고민하기 전에,
  1. kubectl get endpoints로 서비스와 파드가 잘 묶여 있는지,
  2. 그리고 iptables -L -t nat 명령으로 규칙이 노드에 잘 박혀 있는지 확인하는 것이 시니어의 자세다.