[Cilium Study] 3주차 - 쿠버네티스 네트워킹 심층 분석

지난 스터디에서는 Hubble과 Grafana를 통해 클러스터의 네트워크 흐름과 시스템 상태를 관찰하는 방법을 알아보았습니다. 이제는 한 걸음 더 나아가, 그 내부에서 실제로 어떤 일들이 벌어지고 있는지 심층적으로 파헤쳐 볼 시간입니다. "파드들은 어떻게 IP 주소를 할당받을까?", "다른 노드에 있는 파드와는 어떻게 통신할까?", "클러스터 외부로는 어떻게 나갈까?"와 같은 근본적인 질문들에 답을 찾아보겠습니다.

이번 포스팅에서는 Cilium이 쿠버네티스 네트워킹의 핵심 요소들을 어떻게 처리하는지, 그 세부 동작 원리를 중심으로 정리해 보겠습니다.

---

1. IPAM: 파드에게 IP 주소를 나눠주는 방법

IPAM(IP Address Management)은 새로 생성되는 파드에 IP 주소를 할당하고 관리하는 중요한 메커니즘입니다. 어떤 파드가 어떤 IP를 가질지 결정하는 규칙인 셈이죠. Cilium은 여러 IPAM 모드를 제공하지만, 여기서는 대표적인 두 가지 모드를 중심으로 그 동작 방식과 특징을 자세히 살펴보겠습니다.

Kubernetes Host-Scope (기본값)

• 동작 방식: 이 모드는 쿠버네티스의 기본 동작 방식을 가장 충실히 따릅니다. 클러스터의 kube-controller-manager가 전체 Pod CIDR 대역(예: 10.244.0.0/16)을 각 노드에 맞게 작은 podCIDR(예: 10.244.0.0/24, 10.244.1.0/24)로 잘라서 분배합니다. 그러면 각 노드에 배포된 Cilium 에이전트는 자신이 속한 노드에 할당된 podCIDR 범위 내에서만 파드 IP를 할당하고 관리하는 역할을 맡습니다. 즉, IP 주소의 큰 그림은 쿠버네티스가 그리고, 세부적인 할당만 Cilium이 담당하는 구조입니다.
• 특징: 이 방식은 쿠버네티스 컨트롤 플레인의 kube-controller-manager가 --allocate-node-cidrs=true 옵션으로 실행되어야 한다는 전제 조건이 있습니다. 구조가 직관적이고 쿠버네티스 표준에 가깝다는 장점이 있습니다.

# 각 노드에 할당된 PodCIDR 확인
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'
# k8s-ctr   10.244.0.0/24
# k8s-w1    10.244.1.0/24

Cluster-Pool

• 동작 방식: 이 모드에서는 IP 주소 할당의 주체가 쿠버네티스 컨트롤 플레인이 아닌, Cilium 오퍼레이터로 변경됩니다. Cilium 오퍼레이터가 직접 전체 IP 주소 풀을 관리하며 각 노드에 필요한 podCIDR를 할당해 줍니다. 이렇게 할당된 정보는 쿠버네티스 v1.Node 리소스가 아닌, Cilium의 고유 리소스(CRD)인 v2.CiliumNode에 기록되어 관리됩니다.
• 특징: 쿠버네티스 컨트롤 플레인의 설정을 직접 변경하기 어려운 관리형 쿠버네티스(Managed Kubernetes)나 클라우드 환경에서 매우 유용합니다. 쿠버네티스 자체의 설정에 의존하지 않으므로, 더 유연하고 독립적인 IP 관리가 가능해집니다.

운영 중인 클러스터에서 IPAM 모드를 변경하는 것은 매우 신중해야 합니다. 모드 변경 시 기존에 실행 중이던 파드들의 IP가 변경되거나 통신이 단절될 수 있으므로, IPAM 모드는 클러스터 구축 시점에 아키텍처를 충분히 고려하여 결정하는 것이 바람직합니다.

---

2. Routing: 파드 트래픽의 길을 찾는 방법

다른 노드에 있는 파드와 통신하기 위해서는 패킷이 올바른 목적지를 찾아갈 수 있도록 '길'을 알려주는 라우팅이 필수적입니다. Cilium은 크게 두 가지 라우팅 방식을 제공합니다.

Encapsulation (VXLAN, Geneve)

• 동작 방식: 노드 간에 전송되는 파드의 패킷을 VXLAN이나 Geneve 같은 터널링 프로토콜을 이용해 한 번 더 '포장(캡슐화)'해서 보냅니다. 이 포장된 패킷의 출발지와 목적지는 각 노드의 IP가 되며, 패킷을 수신한 노드는 포장을 풀어 내부의 원본 패킷을 목적지 파드로 전달합니다. 마치 택배 상자 안에 물건을 넣어 보내는 것과 같습니다.
• 장점: 클러스터 노드들을 연결하는 물리 네트워크(Underlay Network)가 파드들의 IP 대역을 전혀 알 필요가 없다는 점에서 구성이 매우 간단합니다. 노드 간에 IP 통신만 가능하다면 어떤 네트워크 환경에서든 손쉽게 적용할 수 있습니다.
• 단점: 패킷을 한 번 더 포장하는 과정에서 캡슐화 헤더(약 50바이트)가 추가됩니다. 이로 인해 한 번에 보낼 수 있는 실제 데이터의 크기(MTU)가 줄어드는 오버헤드가 발생하며, 이는 아주 높은 처리량이 요구되는 환경에서는 성능 저하의 요인이 될 수 있습니다.

Native-Routing

이미지 출처: https://docs.cilium.io/en/stable/network/concepts/routing/#encapsulation

• 동작 방식: 캡슐화라는 포장 과정 없이, 파드의 패킷을 노드에서 발생하는 일반 트래픽처럼 네트워크에 직접 전송합니다. 이 방식이 가능하려면, 물리 네트워크 장비들이 파드 IP 대역으로 가는 길을 알고 있어야 합니다. 즉, "10.244.1.0/24 대역으로 가려면 k8s-w1 노드로 보내라"와 같은 라우팅 정보가 네트워크 장비에 설정되어 있어야 합니다.
• 장점: 캡슐화 오버헤드가 전혀 없어 최고의 네트워크 성능을 제공합니다.
• 단점: 물리 네트워크에 대한 추가 설정이 필요하다는 점이 가장 큰 허들입니다. 모든 노드가 동일한 L2 네트워크에 있다면 Cilium의 auto-direct-node-routes: true 옵션으로 노드 간 라우팅을 자동으로 처리할 수 있지만, 그렇지 않은 복잡한 환경에서는 BGP와 같은 동적 라우팅 프로토콜을 연동해야 하므로 구성 난이도가 크게 올라갑니다.

이러한 특징 때문에, 구성의 복잡성을 피하고 싶은 온프레미스 환경에서는 VXLAN 기반의 캡슐화 모드를 사용하는 경우가 많습니다. 반면, 클라우드 환경에서는 클라우드 제공사가 제공하는 가상 네트워크(VPC)의 네이티브 라우팅 기능과 통합하여 최적의 성능을 내는 구성이 선호됩니다.

---

3. Masquerading: 클러스터 밖으로 나갈 때의 신분 위장

파드가 사용하는 10.244.x.x와 같은 내부 IP는 클러스터 외부에서는 인식할 수 없는 사설 IP입니다. 따라서 파드가 외부 인터넷(예: google.com)과 통신하려면, 자신의 사설 IP를 외부와 통신 가능한 공인 IP(주로 노드의 IP)로 '변환'해야 합니다. 이 과정을 Masquerading(마스커레이딩) 또는 SNAT(Source Network Address Translation)이라고 합니다.

eBPF-based (기본값)

• 동작 방식: Cilium은 이 마스커레이딩 과정을 eBPF를 통해 커널 레벨에서 매우 효율적으로 처리합니다. 파드에서 외부로 나가는 패킷이 노드의 네트워크 인터페이스를 통과하는 순간, eBPF 프로그램이 패킷의 출발지 IP 주소를 노드의 IP 주소로 신속하게 바꿔치기합니다.
• 장점: 기존의 iptables 방식보다 훨씬 빠르고 확장성이 뛰어납니다. 서비스와 파드의 수가 늘어나도 성능 저하가 거의 없어 대규모 클러스터 환경에 매우 적합합니다.

iptables-based (레거시)

• 동작 방식: 전통적인 리눅스 방화벽 기능인 iptables의 SNAT 규칙을 사용하여 마스커레이딩을 수행합니다.
• 단점: 서비스 및 파드의 수가 많아질수록 관리해야 할 iptables 규칙의 수가 선형적으로 증가하며, 이는 커널에 부하를 주어 성능 저하의 원인이 될 수 있습니다.

참고로, ip-masq-agent와 같은 설정을 활용하면 마스커레이딩 동작을 더 세밀하게 제어할 수 있습니다. 예를 들어, 외부 인터넷으로 나가는 트래픽은 마스커레이딩을 적용하되, 사내망의 특정 IP 대역으로 향하는 트래픽은 예외 처리하여 파드의 IP 그대로 통신하게 만들 수 있습니다. 이를 통해 파드가 내부 시스템과 NAT 없이 직접 통신하는 유연한 구성이 가능해집니다.

---

4. CoreDNS: 클러스터의 길잡이

쿠버네티스에서 DNS는 파드들이 서로의 서비스를 이름으로 찾을 수 있게 해주는 핵심적인 서비스 디스커버리 메커니즘입니다. 파드는 my-svc.default.svc.cluster.local과 같은 정해진 도메인 이름으로 다른 서비스를 찾으며, 이 '이름 풀이'를 담당하는 것이 바로 CoreDNS입니다.

• Corefile: CoreDNS의 모든 동작은 Corefile이라는 설정 파일을 통해 정의됩니다. 이 파일에는 Kubernetes 플러그인을 통해 클러스터 내부 도메인(cluster.local)에 대한 요청을 어떻게 처리할지, 여기에 없는 외부 도메인에 대한 요청은 어떤 상위 DNS 서버로 전달(forward)할지 등이 명시되어 있습니다.
• NodeLocal DNSCache: 클러스터 규모가 커지고 DNS 질의가 많아지면, 중앙화된 CoreDNS 파드에 부하가 집중되거나 커널의 conntrack 테이블 고갈과 같은 이슈로 DNS 통신이 불안정해질 수 있습니다. 이를 방지하기 위해 각 노드에 DNS 캐싱 에이전트를 데몬셋 형태로 배포하는 NodeLocal DNSCache 아키텍처를 도입할 수 있습니다. 이를 통해 DNS 요청이 노드 내부에서 빠르게 처리되므로 성능과 안정성을 크게 향상시킬 수 있습니다.

결론

이번 포스팅을 통해 파드에 IP가 할당되고(IPAM), 다른 파드와 통신하며(Routing), 외부 세계와 연결되는(Masquerading) 과정의 내부 동작을 Cilium 관점에서 자세히 살펴보았습니다. 각 기능들이 어떤 옵션들을 가지고 있으며, 환경에 따라 어떤 장단점이 있는지 이해하는 것은 안정적이고 성능 좋은 클러스터를 구축하는 데 매우 중요한 밑거름이 됩니다.

특히 Cilium이 eBPF를 활용하여 기존의 iptables 기반 네트워킹이 가졌던 성능과 확장성의 한계를 어떻게 극복하는지 확인하는 과정은 eBPF의 강력함을 다시 한번 체감하는 계기가 되었습니다. 다음 스터디에서는 또 다른 네트워킹 주제로 더 깊이 들어가 보겠습니다.