Cilium 설치 후 가장 먼저 만나는 IP 할당 방식, 대체 정체가 뭘까? 🤔

안녕하세요! Kubernetes 네트워킹의 세계를 탐험하는 여러분, 반갑습니다. 🚀

요즘 가장 핫한 CNI(Container Network Interface)인 Cilium을 막 설치하셨나요? 혹은 설치를 고민하고 계신가요? Cilium의 강력한 eBPF 기반 성능과 기능에 매료되어 설치를 마쳤는데, 문득 이런 궁금증이 생길 수 있습니다.

"대체 내 파드(Pod)들은 IP 주소를 어떻게 할당받는 거지? Cilium이 알아서 다 해주는 건가?"

네, 맞습니다! Cilium이 알아서 다 해주죠. 하지만 그 '알아서' 해주는 방식에도 여러 가지가 있다는 사실! 그리고 Cilium은 가장 보편적이고 안정적인 방식을 기본값(Default)으로 채택하고 있습니다. 오늘은 바로 그 기본 방식의 정체를 파헤쳐 보고, 왜 다른 방식이 아닌 이 방식을 기본으로 선택했는지 그 속사정까지 낱낱이 알아보겠습니다.

---

🕵️‍♂️ 범인은 바로... Kubernetes Native IPAM!

Cilium을 별다른 설정 없이 Helm 등으로 설치했다면, 여러분의 클러스터는 Kubernetes Native IPAM 모드, 즉 ipam: kubernetes 모드로 동작하고 있을 확률이 99%입니다.

이게 무슨 의미일까요? 아주 간단하게 비유해 볼게요.

Kubernetes 클러스터라는 거대한 '신도시'가 있다고 상상해 보세요. 🏙️

신도시 계획 총괄 (Kubernetes Control Plane): 신도시를 계획하면서 각 동네(Node)마다 주민(Pod)들이 살 수 있는 주소 대역(PodCIDR)을 미리 할당해 줍니다. "A 동네는 10.1.1.0-255 번지까지 쓰세요", "B 동네는 10.1.2.0-255 번지까지 쓰세요" 하고 정해주는 거죠.

동네 관리소장 (Cilium Agent): 각 동네에 파견된 관리소장(Cilium Agent)은 총괄 본부에서 내려온 우리 동네 주소 대역을 확인합니다.

1. 입주 신청 (Pod 생성): 새로운 주민(Pod)이 A 동네에 이사 오면, A 동네 관리소장(Cilium)이 비어있는 번지(IP)인 '10.1.1.10'을 딱! 하고 부여해 줍니다.

즉, Cilium이 독자적으로 IP 대역을 관리하는 게 아니라, 이미 Kubernetes가 각 노드(Node)에 할당해 준 IP 대역(PodCIDR)을 그대로 가져와서 그 안에서 파드에게 IP를 나눠주는 방식입니다. Cilium은 Kubernetes가 차려놓은 밥상에 숟가락만 얹는, 아주 현명하고 효율적인 방법을 쓰는 셈이죠! 😄

그럼 직접 확인해 볼까요?

내 클러스터의 노드들이 어떤 IP 대역(PodCIDR)을 할당받았는지 직접 확인해 봅시다. 아래 명령어를 터미널에 입력해 보세요.

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

그러면 아래와 비슷한 결과를 볼 수 있습니다.

# 출력 결과 예시
master-node     10.244.0.0/24
worker-node-1   10.244.1.0/24
worker-node-2   10.244.2.0/24

보이시나요? Kubernetes의 kube-controller-manager가 각 노드에 /24 크기의 IP 대역을 사이좋게 나눠준 것을 확인할 수 있습니다.

worker-node-1에 파드가 생성되면, Cilium은 10.244.1.0/24 대역 안에서 놀고 있는 IP를 찾아 할당해 줍니다. 이 모든 정보는 CiliumNode라는 CRD(Custom Resource Definition)에 기록되고 관리되죠.

---

🤔 그럼 다른 방식들은 왜 기본값이 아닐까요?

Cilium은 kubernetes 모드 외에도 다양한 IPAM 방식을 지원합니다. 대표적인 경쟁자인 cluster-pool 모드를 통해 왜 kubernetes 모드가 기본값으로 채택되었는지 역으로 이해해 봅시다.

❌ Cluster Pool IPAM (ipam: cluster-pool)

이 방식은 Cilium이 자체적으로 거대한 IP 주소 풀(Pool)을 관리하는 방식입니다.

다시 신도시 비유로 돌아가 볼까요? 🏙️

신도시 계획 총괄(Kubernetes)은 이제 동네별 주소 대역을 할당하지 않습니다. 대신 Cilium이라는 전문 부동산 개발업자가 "이 신도시 IP는 전부 내가 관리할게! 10.10.0.0/16 대역은 다 내꺼야!"라고 선언합니다. 그리고 각 동네(Node)에 필요한 만큼 조금씩 IP 대역을 떼어주는(Delegation) 방식이죠.

장점:

• 클라우드 환경이 아니거나, Kubernetes의 PodCIDR 할당 기능에 의존하고 싶지 않을 때 유용합니다.
• IP 대역을 더 유연하고 세밀하게 제어할 수 있습니다.

단점 (그리고 기본값이 아닌 이유):

• 추가 설정이 필요합니다! 😭 사용자가 직접 Cilium 설정 파일에 전체 클러스터가 사용할 IP 대역(clusterPoolIPv4PodCIDRList)을 명시해 줘야 합니다.

# Helm values.yaml 예시
ipam:
  mode: cluster-pool
  operator:
    clusterPoolIPv4PodCIDRList: ["10.10.0.0/16"]

• 기본값의 철학은 "가장 쉽고, 직관적이며, 추가 설정 없이(zero-config) 잘 동작하는 것"입니다. cluster-pool 방식은 이 철학에 어긋나죠. Kubernetes의 기본 기능을 최대한 활용하는 것이 더 'Kubernetes-native' 답고, 사용자에게 편리함을 주기 때문에 kubernetes 모드가 기본값으로 선택된 것입니다.

☁️ 클라우드 전용 IPAM (AWS ENI, Azure IPAM 등)

AWS, GCP, Azure 같은 클라우드 환경에서는 해당 클라우드가 제공하는 네이티브 네트워킹 기능을 활용하여 IP를 할당하는 모드도 있습니다. 예를 들어, AWS ENI 모드는 파드에 EC2의 보조 IP를 직접 할당하여 엄청난 성능을 낼 수 있습니다.

기본값이 아닌 이유:

• 이유는 명확합니다. 이 방식들은 특정 클라우드 플랫폼에 종속적입니다. 🔗
• Cilium의 기본값은 어떤 환경(온프레미스, 모든 클라우드, 로컬 개발 환경 등)에서도 보편적으로 동작해야 합니다. 따라서 범용성이 가장 뛰어난 kubernetes 모드가 기본값의 자리를 차지하고 있습니다.

---

🖼️ 큰 그림으로 이해하기: 왜 이게 중요할까?

개별 IPAM 모드를 아는 것도 중요하지만, Cilium이 왜 이런 선택지를 제공하는지 전체적인 맥락을 이해하는 것이 핵심입니다.

IPAM 모드	핵심 아이디어	장점	단점/특징
Kubernetes (기본)	"Kubernetes를 믿고 따르자!"	설치 즉시 동작, 추가 설정 불필요, 가장 표준적	Kubernetes의 PodCIDR 할당 능력에 의존
Cluster Pool	"IP 관리는 Cilium이 직접 할게!"	유연한 IP 대역 관리, K8s 의존성 탈피	사용자가 직접 IP 대역을 설정해야 하는 번거로움
Cloud-Specific	"이 클라우드에선 이 방법이 최고야!"	클라우드 네이티브 성능 극대화	특정 클라우드에 종속됨, 범용성 부족

결국 Cilium의 기본 전략은 "단순함과 통합"입니다. Kubernetes 생태계의 일원으로서 가장 자연스럽게 녹아드는 방식을 기본으로 제공하고, 더 특별한 요구사항이 있는 고급 사용자들을 위해 다른 강력한 옵션들을 열어두는 것이죠.

✨ 정리하며

오늘은 Cilium이 파드에게 IP 주소를 할당하는 기본 방식인 Kubernetes Native IPAM에 대해 깊이 있게 알아보았습니다. 이제 여러분은 Cilium을 설치한 후 여러분의 파드 IP가 어디서 왔는지, 왜 하필 그 방식이 기본으로 채택되었는지 자신 있게 설명할 수 있을 겁니다.

대부분의 경우 이 기본 설정은 아주 훌륭하게 동작합니다. 하지만 여러분의 클러스터 환경이 특별한 요구사항을 가지고 있다면, 오늘 함께 살펴본 다른 IPAM 옵션들을 검토해 보는 것도 멋진 다음 단계가 될 것입니다!