7. [Architecture]: Networking

쿠버네티스 네트워킹은 사실상 클러스터라는 거대한 유기체의 '혈관 시스템'과 같다. 이번 파트는 내용이 방대하고 복잡하지만, 인프라의 핵심인 만큼 아주 상세하고 꼼꼼하게 짚어서 살펴보아야한다.

 

이 분야는 기술이 방대하고 복잡하지만, 전반적인 아키텍처의 흐름만 정확히 잡아도 실무에서 길을 잃지 않는다.

 

---

 

 

1. 파드 네트워크 (Pod Networking): "실제 데이터가 흐르는 통로"

 

파드 네트워크는 클러스터 설치 시 설정한 Pod Network CIDR (예: 20.96.0.0/12) 대역 내에서 운영된다.

• 컨테이너 간 통신 (Intra-Pod)
  • 파드가 생성되면, 고유 IP를 가진 인터페이스(eth0)가 생긴다.
  • 파드 내부의 여러 컨테이너는 이 네트워크 네임스페이스를 공유하며, 서로 localhost를 통해 자유롭게 통신한다.
• 파드 간 통신 (Inter-Pod) 및 CNI
  • 노드 간 파드 통신은 CNI(Container Network Interface) 기반 네트워크 플러그인(Network Plugin)에 의해 이루어진다.
    • 큐브넷(kubenet): 기본 제공되지만 기능이 제한적이라 잘 쓰이지 않는다.
    • 캘리코(Calico): 이번 강의의 핵심 플러그인으로, 동일 노드뿐 아니라 외부 네트워크를 통한 타 노드 파드 간의 통신까지 담당한다.
  •  즉, 이 네트워크 플러그인이 하는 역할은 같은 노드 위의 파드들 간의 통신과 그리고 외부 네트워크를 통한 타 노드 위에 있는 파드들 간의 통신을 담당하는 것이다.

---

2. 서비스 네트워크 (Service Networking): "가상의 논리 관리 영역"

서비스는 실제 파드로 트래픽을 안내하는 이정표 역할을 하며, Service Network CIDR (예: 10.96.0.0/12) 대역을 사용한다.

• 서비스 IP와 DNS: 서비스가 생성되면 고유 IP가 부여되고, kube-dns(CoreDNS)에 서비스 이름과 IP 정보가 자동으로 등록된다.
• kube-proxy와 NAT 영역
  • kube-proxy는 각 노드에 파드 형태로 존재하며, API 서버로부터 서비스-파드 매핑 정보를 받아 노드에 적용한다.
  • NAT 기능: 서비스 IP를 실제 파드 IP로 바꾸는 핵심 기술이다. kube-proxy가 iptables나 IPVS를 어떻게 활용하느냐에 따라 프록시 모드가 결정된다.
• 서비스의 실체: 서비스 오브젝트는 물리적 실체가 아니라, NAT 영역 내의 설정값 그 자체다. 서비스를 삭제하면 이 설정이 지워지면서 통로가 폐쇄된다.

---

3. 아키텍처 핵심: Pause 컨테이너의 비밀

• 네트워크의 뿌리: 파드가 생성될 때, 파드 안에 Pause 컨테이너가 가장 먼저 실행되어 네트워크 네임스페이스를 생성하고 유지한다.
• 공유의 중심: 이후 생성되는 실제 애플리케이션 컨테이너들이 이 Pause 컨테이너의 네트워크를 같이 쓰게 함으로써, 파드 내 모든 컨테이너가 동일한 IP를 공유하게 만든다.

---

 

4. 한눈에 보는 네트워크 비교

구분 파드 네트워크 (Pod Network) 서비스 네트워크 (Service Network)

구분	파드 네트워크 (Pod Network)	서비스 네트워크 (Service Network)
IP 대역 (예시)	20.96.0.0/12	10.96.0.0/12
실체	실제 인터페이스 및 파드 IP	가상의 가상 IP (Cluster IP)
관리 주체	CNI 플러그인 (Calico 등)	kube-proxy (iptables/IPVS)
핵심 역할	실제 데이터 패킷 전송	트래픽 라우팅 및 부하 분산

 

 

💡꼬리 질문

Q: 만약 특정 노드에서 kube-proxy 파드가 장애로 죽어버린다면, 해당 노드에 있는 파드들이 '서비스 이름'을 통해 다른 파드와 통신하는 것이 가능할까? NAT 영역에는 어떤 변화가 생길까?

 

 

결론: 서비스 IP를 파드 IP로 바꾸는 '이정표'가 업데이트되지 않아 통신 장애가 발생한다.

1. 설정 고착: kube-proxy가 죽으면 새로운 서비스 생성이나 기존 서비스의 변경 사항(파드 IP 변경 등)이 노드에 반영되지 않는다.
2. NAT 불능: 트래픽이 서비스 IP로 들어와도 이를 파드 IP로 변환해줄 NAT 규칙이 없거나 잘못되어 패킷이 길을 잃게 된다.
3. 관리: 그래서 kube-proxy는 데몬셋(DaemonSet)으로 관리되어 모든 노드에서 항상 가동 상태를 유지해야 한다.