안녕하세요! 쿠버네티스(Kubernetes) 클러스터를 운영하다 보면 한 번쯤 이런 궁금증을 가져보셨을 거예요.
"수많은 파드들이 어떻게 순식간에 IP 주소를 할당받고 서로 통신할 수 있는 거지?" 🤔 "특히 대규모 클러스터에서 이 많은 IP 주소는 누가, 어떻게 관리하는 걸까?"
이 마법 같은 일의 중심에는 CNI(Container Network Interface) 가 있고, 그중에서도 오늘은 가장 핫한 CNI 중 하나인 Cilium의 심장, IPAM에 대해 깊이 파헤쳐 보려고 합니다. 이 글을 끝까지 읽으신다면, 더 이상 파드의 IP 할당이 마법이 아닌, 잘 설계된 기술이라는 것을 이해하게 되실 거예요! 🚀

💡 IPAM, 일단 이름부터 알고 가자!
IPAM은 Internet Protocol Address Management의 약자입니다. 이름 그대로 '인터넷 프로토콜 주소 관리'를 의미하죠.
쉽게 비유하자면, 도서관에 들어가는 학생(Pod)들에게 사서(IPAM)가 비어있는 좌석 번호(IP 주소)를 하나씩 나눠주는 것과 같아요. 📚 학생들이 자리를 잡아야 공부를 시작할 수 있듯, 파드도 IP 주소를 할당받아야 비로소 다른 파드와 통신을 시작할 수 있습니다.
Cilium에서 IPAM은 바로 이 핵심적인 역할, 즉 클러스터 내의 모든 파드에게 고유한 IP 주소를 할당하고, 사용이 끝나면 회수하여 관리하는 기능을 전담합니다.
🌐 전체 그림: Cilium 네트워킹 속 IPAM의 위치
IPAM을 제대로 이해하려면 전체적인 맥락을 알아야 합니다. Cilium은 단순히 IP만 할당하는 도구가 아니에요. eBPF라는 강력한 기술을 사용해 네트워킹, 보안, 관측 가능성을 제공하는 솔루션이죠.
- 파드 생성 요청 ➡️ 사용자가 kubectl apply -f my-pod.yaml 명령을 실행합니다.
- 스케줄링 ➡️ 쿠버네티스 스케줄러가 파드를 가장 적절한 노드(Node)에 배치합니다.
- CNI 호출 ➡️ 해당 노드의 Kubelet이 Cilium CNI 플러그인을 호출하며 "이 파드에 네트워크를 설정해줘!"라고 요청합니다.
- IPAM의 활약 ✨ ➡️ 바로 이 단계에서 Cilium IPAM이 등장합니다! 노드에 미리 할당된 IP 대역에서 사용 가능한 IP 주소 하나를 꺼내 파드에 할당합니다.
- 네트워크 설정 완료 ➡️ Cilium은 할당된 IP와 eBPF를 이용해 파드의 네트워크 인터페이스를 설정하고, 필요한 네트워크 정책(보안 규칙)을 적용합니다.
- 파드 Running ✅ ➡️ 이제 파드는 IP 주소를 가지고 클러스터 내 다른 파드들과 통신할 준비를 마쳤습니다.
이처럼 IPAM은 파드가 생명(네트워크)을 얻는 가장 첫 단추를 끼우는 중요한 역할을 담당합니다.
🔧 Cilium IPAM은 어떻게 동작할까? (feat. IPAM Modes)
Cilium IPAM의 가장 큰 특징은 다양한 '모드(Mode)'를 제공하여 여러 환경에 최적화된 IP 관리 전략을 사용할 수 있다는 점입니다. 가장 대표적인 두 가지 모드를 살펴볼게요.
1. Cluster Pool (기본 모드)
가장 일반적으로 사용되는 기본 모드입니다. 클러스터 전체에서 사용할 커다란 IP 대역(cluster-pool-ipv4-cidr)을 미리 정의해두고, 각 노드에 작은 단위의 IP 대역(PodCIDR)을 할당하는 방식입니다.
동작 방식:
- Cilium Operator는 클러스터의 각 노드를 감시합니다.
- 새로운 노드가 클러스터에 참여하면, Operator는 해당 노드에 PodCIDR를 할당해줍니다. 예를 들어, 10.0.1.0/24는 node-1에, 10.0.2.0/24는 node-2에 할당하는 식이죠.
- 노드에 배포된 Cilium 에이전트는 자신에게 할당된 PodCIDR 내에서 파드가 생성될 때마다 IP를 하나씩 나눠줍니다.
이 방식은 노드별로 IP 대역이 격리되어 있어 IP 충돌 위험이 없고, 각 노드가 자체적으로 IP를 할당하므로 중앙 의존성 없이 매우 빠르고 효율적입니다. 👍
아래는 CiliumNode 리소스를 통해 실제 노드에 IP 대역이 어떻게 할당되었는지 확인하는 예시입니다.
# kubectl get ciliumnodes node-1 -o yaml
apiVersion: cilium.io/v2
kind: CiliumNode
metadata:
name: node-1
spec:
ipam:
# node-1에 할당된 IP 대역을 볼 수 있습니다.
pod-cidrs:
- 10.0.1.0/24
# 현재 사용 중인 IP 목록입니다.
pool:
10.0.1.132:
owner: app-pod-1
resource: pod
10.0.1.200:
owner: app-pod-2
resource: pod
status:
ipam:
# 사용 가능한 IP 개수
available: 252
# 사용 중인 IP 개수
used: 2
2. Cloud Provider 연동 모드 (AWS ENI, Azure IPAM 등)
AWS, GCP, Azure 같은 클라우드 환경에서는 더 똑똑한 방법이 있습니다. 바로 클라우드 제공사의 네트워킹 서비스를 직접 활용하는 것이죠! 예를 들어 AWS 환경에서는 ipam: eni 모드를 사용할 수 있습니다.
동작 방식 (AWS ENI 기준):
- Cilium은 노드의 EC2 인스턴스에 여분의 ENI(Elastic Network Interface) 를 추가로 연결합니다.
- 각 ENI에는 여러 개의 보조 Private IP 주소를 할당할 수 있습니다.
- 파드가 생성되면, Cilium은 별도의 오버레이 네트워크 없이 이 ENI에 할당된 IP 주소를 파드에 직접 할당합니다.
이 방식의 최대 장점은 클라우드 네이티브 성능을 100% 활용할 수 있다는 것입니다. 오버레이 캡슐화 과정이 없어 네트워크 지연 시간이 줄고, 클라우드의 VPC Flow Logs나 보안 그룹 같은 기능을 파드 레벨에서 그대로 활용할 수 있게 됩니다. ☁️
❌ 이건 IPAM이 아니에요! (자주 하는 오해)
IPAM의 역할을 명확히 하기 위해, IPAM이 아닌 것들을 짚어보는 것도 중요합니다.
- 서비스 디스커버리(Service Discovery) ❌
- IPAM은 파드에 10.0.1.132와 같은 실제 IP를 할당합니다. 하지만 우리는 보통 이 IP를 직접 사용하지 않고 my-service 같은 서비스 이름으로 파드에 접근하죠. 이처럼 서비스 이름을 IP 주소로 변환해주는 것은 CoreDNS와 쿠버네티스 Service의 역할입니다. IPAM은 주소록을 만드는 역할, 서비스 디스커버리는 그 주소록에서 이름을 찾아주는 역할이라고 할 수 있습니다. 🗺️
- 트래픽 라우팅 및 정책 적용(Routing & Policy) ❌
- IPAM이 파드에 IP를 '부여'했다면, A 파드에서 B 파드로 가는 데이터 패킷을 실제로 '전달'하고, "A는 B와 통신할 수 있지만 C와는 할 수 없다"와 같은 보안 정책을 '적용'하는 것은 Cilium의 eBPF 엔진이 담당합니다. IPAM은 주소를 주는 것까지가 역할이고, 실제 교통 통제는 eBPF가 하는 셈이죠. 🚦
- 외부 트래픽 관리(Ingress) ❌
- 클러스터 외부에서 들어오는 트래픽을 어떤 서비스로 보낼지 결정하는 것은 Ingress Controller나 Gateway API의 역할입니다. IPAM은 클러스터 내부의 IP 주소 관리에 집중합니다. 🚪
✨ 결론: 잘 관리된 IP가 곧 클러스터의 안정성!
지금까지 Cilium IPAM이 무엇이며, 어떻게 동작하고, 전체 네트워킹 파이프라인에서 어떤 역할을 하는지 살펴보았습니다.
파드에 IP 주소를 할당하는 것은 간단해 보이지만, 수백, 수천 개의 파드가 역동적으로 생성되고 사라지는 클라우드 네이티브 환경에서는 매우 복잡하고 중요한 문제입니다. Cilium IPAM은 이러한 복잡성을 해결하고, 다양한 환경에 맞는 최적의 IP 관리 전략을 제공함으로써 안정적이고, 확장 가능하며, 고성능의 쿠버네티스 네트워킹을 가능하게 하는 핵심 기술입니다.
이제 여러분의 파드가 IP 주소를 부여받는 과정을 보며, 그 뒤에서 묵묵히 일하는 Cilium IPAM의 노고를 떠올려보는 것은 어떨까요? 😉
'클라우드 > Cilium' 카테고리의 다른 글
| Cilium 설치 후 가장 먼저 만나는 IP 할당 방식, 대체 정체가 뭘까? 🤔 (0) | 2025.12.05 |
|---|---|
| [Cilium]내 쿠버네티스 클러스터를 지키는 숨은 경호원, 정체는? 🕵️♂️ (0) | 2025.12.05 |
| 쿠버네티스 통신 문제, 더 이상 헤매지 마세요! Hubble 아키텍처 완전 정복 🚀 (0) | 2025.12.04 |
| eBPF Map, 당신이 몰랐던 커널 데이터 통신 비법 🤫 (0) | 2025.12.04 |
| VPN, 아직도 IPsec 쓰세요? WireGuard가 '게임 체인저'인 진짜 이유 (0) | 2025.12.04 |