[Kubernetes] 쿠버네티스 네트워킹 이해하기 (2) - Service와 kube-proxy의 마법

🌐 쿠버네티스 네트워킹 기초 (2): Service는 어떻게 동작할까?

지난 포스팅에서 Pod끼리 통신하는 원리를 알아봤습니다. 하지만 큰 문제가 하나 있습니다. 바로 Pod은 언제든 죽고 다시 살아날 수 있으며, 그때마다 IP가 변한다는 점입니다. 😅

이렇게 변하는 Pod들을 하나의 고정된 주소로 묶어주는 존재가 바로 Service입니다. 오늘은 서비스가 어떻게 가상 IP를 유지하고 트래픽을 전달하는지 그 내부 원리를 파헤쳐 보겠습니다.

---

🧐 1. 왜 Service가 필요한가요?

쿠버네티스의 Pod은 영구적이지 않습니다. 에러가 나서 재시작되거나, 업데이트를 위해 교체되면 새로운 IP를 할당받습니다. 클라이언트가 매번 바뀌는 Pod의 IP를 추적하는 것은 불가능에 가깝죠.

• 해결책: 여러 개의 Pod 앞단에 고정된 가상 IP(Virtual IP)를 가진 Service를 둡니다.
• 역할: 클라이언트는 서비스의 VIP로만 요청을 보내고, 서비스는 뒤에 살아있는 Pod들에게 트래픽을 골고루 전달(Load Balancing)합니다. ⚖️

---

🛠️ 2. 서비스의 핵심 조력자: kube-proxy

서비스는 실제로 물리적인 랜카드나 인터페이스가 존재하는 장치가 아닙니다. 리눅스 커널 수준에서 돌아가는 가상의 규칙일 뿐입니다. 이 규칙을 실시간으로 관리하는 것이 바로 모든 노드에서 실행 중인 kube-proxy입니다.

kube-proxy는 크게 두 가지 방식으로 트래픽을 제어합니다.

2.1 iptables 모드 (기본 방식)

• 원리: 리눅스 커널의 네트워크 관리 도구인 iptables를 이용합니다.
• 동작: 서비스로 들어오는 패킷을 가로채서, 무작위로 선택된 Pod의 실제 IP로 목적지를 바꿉니다(DNAT).
• 특징: 설정이 복잡해질수록 성능이 약간 저하될 수 있지만, 가장 널리 쓰이는 표준 방식입니다.

2.2 IPVS 모드 (고성능 방식)

• 원리: 커널의 L4 로드밸런서인 IPVS를 이용합니다.
• 특징: iptables보다 훨씬 빠르고 더 다양한 로드밸런싱 알고리즘(Round Robin 등)을 지원합니다. 대규모 클러스터에서 권장됩니다. 🚀

---

🔄 3. 트래픽의 여정: ClusterIP 통신 과정

가장 기본인 ClusterIP 서비스로 요청이 전달되는 과정을 살펴봅시다.

1. 요청 시작: 클라이언트 Pod이 서비스의 가상 IP(10.96.0.1)로 패킷을 보냅니다.
2. 패킷 가로채기: 패킷이 노드의 네트워크를 통과할 때, 커널의 netfilter(iptables 규칙)가 이 패킷이 서비스 IP임을 알아채고 가로챕니다.
3. 목적지 변경(DNAT): 규칙에 따라 목적지 주소를 서비스 VIP에서 실제 살아있는 Pod 중 하나(예: 172.16.0.5)의 IP로 변경합니다.
4. 전달: 이제 패킷은 일반적인 Pod 대 Pod 통신 방식을 타고 목적지 Pod에 무사히 도착합니다. 🏁

---

🔍 4. 핵심 요약: 서비스 네트워킹의 진실

1. 서비스 IP는 가짜다: 서비스 IP(ClusterIP)는 핑(ping)이 가지 않는 가상의 주소입니다. 오직 TCP/UDP 통신만 iptables 규칙에 의해 변환됩니다.
2. kube-proxy가 지휘자다: API 서버를 감시하다가 서비스나 Pod에 변화가 생기면 즉시 모든 노드의 iptables 규칙을 업데이트합니다.
3. NAT의 연속: 우리가 서비스 주소로 통신하는 것은 사실 커널 수준에서 엄청난 속도로 주소를 갈아치우는 NAT 연산의 결과물입니다.