Kubernetes 네트워킹의 진화: CNI부터 Cilium까지, 그리고 eBPF가 바꾼 풍경
네트워킹, 쿠버네티스가 의도적으로 해결하지 않은 문제
쿠버네티스를 처음 접했을 때 가장 신기했던 것 중 하나가 네트워킹이었습니다. Pod들이 자연스럽게 IP를 받아서 서로 통신하고, Service가 알아서 로드밸런싱을 해주거든요. 그런데 깊이 들여다보면 쿠버네티스 자체는 실제로 네트워킹을 구현하지 않습니다.
쿠버네티스가 Pod을 스케줄링할 때의 가정은 매우 단순합니다:
"이 Pod는 IP 주소를 받아야 하고, 다른 모든 것과 통신할 수 있어야 한다"
그리고 쿠버네티스가 직접 하지 않는 일들:
- Linux 네트워크 네임스페이스 생성
- 라우팅 테이블 구성
- VXLAN 같은 오버레이 구축
- iptables 규칙 프로그래밍
- IP 주소 할당 관리
이 모든 책임을 다른 누군가에게 맡겼는데, 그게 바로 Container Network Interface입니다.
Container Network Interface, 쿠버네티스 네트워킹의 플러그인 시스템
Container Network Interface는 사양이자 플러그인 생태계입니다. 쿠버네티스와 실제 네트워킹 시스템 사이의 약속을 정의하죠:
- 쿠버네티스: "이 Pod에 네트워킹 좀 설정해줘"
- CNI 플러그인: 실제 구성 작업 수행
- 플러그인: "완료했어, 네트워킹 정보는 이거야"
런타임에서는 간단한 라이프사이클로 동작합니다:
- ADD: 새 Pod을 위한 네트워킹 생성
- DELETE: Pod 종료 시 네트워킹 제거
- CHECK: 네트워크 상태 확인
kubelet이 Pod을 생성하면 Container Network Interface 바이너리를 실행하고, 플러그인은 이런 일들을 합니다:
- IP 주소 할당 (IPAM)
- 가상 이더넷 쌍(veth) 생성
- 인터페이스를 Pod 네임스페이스에 배치
- 라우팅 및 정책 규칙 구성
Container Network Interface가 없으면 쿠버네티스 네트워킹은 완전히 실패합니다. Pod들은 IP를 받지 못하고, Service는 트래픽을 라우팅할 수 없거든요.
쿠버네티스는 왜 플러그인 모델을 선택했을까
초기 쿠버네티스 시대에는 네트워킹 업체들이 각자의 솔루션을 홍보했습니다. 클라우드 제공업체는 네이티브 통합을 원했고, 가상화 업체는 SDN 스택을 밀었으며, 오픈소스 커뮤니티는 오버레이를 구축했죠.
승자를 선택하는 대신 구현보다 인터페이스를 표준화했습니다. 이 결정이 가져온 장기적 이점들:
1. 휴대성
애플리케이션이 환경 간에 이동할 수 있습니다:
- 로컬 클러스터 (간단한 오버레이)
- 관리형 클라우드 (제공업체 네트워크 연결)
- 베어메탈 (고성능 라우팅)
2. 공급업체 중립성
네트워킹 혁신이 쿠버네티스 핵심 개발 외부에서 발생할 수 있습니다. 새로운 기술이 쿠버네티스 자체를 재설계하지 않고도 등장할 수 있거든요.
3. 지속적인 진화
Container Network Interface 사양이 기본 IP 할당에서 대역폭 제어, 다중 네트워크 연결, 네이티브 커널 가속 같은 고급 기능으로 꾸준히 확장되었습니다.
전통적인 Container Network Interface의 한계와 iptables의 벽
Flannel 같은 기존 Container Network Interface 구현을 보면, 서로 다른 노드의 Pod 간 트래픽은 이렇게 처리됩니다:
- Container Network Interface 플러그인이 노드 서브넷에서 IP 할당
- veth 쌍이 Pod을 호스트 네트워크에 연결
- 라우팅 및 포워딩 규칙 설치
- 교차 노드 트래픽을 터널(보통 VXLAN)에 캡슐화
Pod A가 Pod B로 트래픽을 보낼 때:
- 패킷이 가상 인터페이스를 통해 Pod 종료
- 노드가 VXLAN 패킷 안에 캡슐화
- UDP를 통해 목적지 노드로 이동
- 목적지에서 탈캡슐화하여 대상 Pod으로 전달
소규모에서는 잘 작동하지만, 전통적인 Container Network Interface는 라우팅 결정, 로드밸런싱, 정책 시행을 iptables에 의존합니다. 클러스터가 커질수록:
- 수백 개 Pod → 수백 개 규칙
- 수천 개 Pod → 수천 개 규칙
- 대형 클러스터 → 측정 가능한 패킷 지연과 CPU 오버헤드
패킷이 커널 내부의 긴 규칙 체인을 순회해야 한다는 아키텍처적 병목이 문제였죠.
Cilium과 eBPF: 네트워킹의 패러다임 전환
Cilium은 Container Network Interface를 대체하지 않습니다. Container Network Interface 사양을 구현하죠. 차이는 네트워킹을 수행하는 방식에 있습니다.
iptables 대신 Cilium은 extended Berkeley Packet Filter를 활용합니다. Linux 커널에 직접 내장된 프로그래머블 프레임워크거든요.
핵심 차이점
- iptables: 긴 순차 규칙 체인을 평가
- extended Berkeley Packet Filter: 전략적 커널 훅에서 컴파일된 프로그램을 즉시 실행
extended Berkeley Packet Filter 프로그램은 패킷 처리의 여러 단계에 연결됩니다:
- 패킷이 네트워크 스택에 도달하기 전
- 인그레스/이그레스 처리 중
- 애플리케이션별 소켓 수준
Cilium은 이를 활용해 구현합니다:
- 라우팅
- 서비스 로드밸런싱
- 네트워크 정책
- 관찰가능성
수천 개 규칙을 순회하는 대신, 패킷이 O(1) 조회로 최적화된 커널 맵을 참조합니다.
Cilium 아키텍처 내부
모든 쿠버네티스 노드가 Cilium 에이전트를 DaemonSet으로 실행하며, 다섯 가지 핵심 역할을 수행합니다:
| 역할 | 설명 |
|---|---|
| Container Network Interface 서버 | kubelet의 ADD/DELETE 호출에 응답 |
| IP 주소 관리 | 클러스터/클라우드 통합으로 Pod 주소 할당 |
| extended Berkeley Packet Filter 매니저 | 컴파일된 프로그램을 커널 훅에 로드 |
| Kubernetes Watcher | 클러스터 상태를 extended Berkeley Packet Filter 맵으로 동기화 |
| Hubble | 네트워크 플로우 실시간 가시성 제공 |
수천 개 규칙을 반복 프로그래밍하는 대신, Cilium은 쿠버네티스 상태를 커널 데이터 구조에 지속적으로 동기화합니다.
전통적인 Container Network Interface가 정적 라우터처럼 동작한다면, Cilium은 Linux 커널 내부에서 실행되는 프로그래머블 네트워크 OS에 가까워요.
실제 트래픽 플로우의 변화
Pod 간 통신
Pod을 떠나는 트래픽이 extended Berkeley Packet Filter 정책 프로그램으로 평가되어, iptables 체인을 거치지 않고 목적지로 직접 라우팅됩니다. 지연시간이 마이크로초 수준으로 감소하죠.
쿠버네티스 서비스 로드밸런싱
Pod이 Service IP에 접근하면 Cilium이 커널 공간에서 직접 로드밸런싱을 수행합니다. kube-proxy도, NAT 체인도, 규칙 폭발도 없습니다.
Layer-7 보안 정책
Cilium은 IP 주소뿐 아니라 애플리케이션 동작 기반 정책을 강제할 수 있습니다:
- 특정 도메인에만 HTTPS 트래픽 허용
- 알 수 없는 외부 목적지 거부
- HTTP 경로 수준 제어 적용
관찰가능성: 숨겨진 강점
기존 쿠버네티스 디버깅은 패킷 캡처와 추측을 포함했습니다. Cilium은 Hubble로 실시간 플로우 텔레메트리를 공개합니다:
- 어떤 Pod이 어느 Service와 통신했는가
- 정책이 트래픽을 허용했는지 거부했는지
- DNS 및 HTTP 가시성
- 히스토리컬 플로우 추적
네트워크가 왜 실패했는지 묻는 대신, 네트워크 동작을 직접 관찰할 수 있게 되었습니다.
프로덕션 도입 체크리스트
프로덕션에서 Cilium 도입 전 확인사항:
- 충분한 extended Berkeley Packet Filter 지원을 가진 Linux 커널 버전
- 최신 Cilium 릴리스
- kube-proxy 교체 활성화
- Hubble을 통한 관찰가능성
- 적절한 라우팅 또는 BGP 통합
운영적으로는 오히려 복잡성이 감소하는 경우가 많습니다. 네트워킹, 로드밸런싱, 보안이 하나의 플랫폼으로 통합되거든요.
마무리하며
쿠버네티스가 네트워킹 승자 선택을 의도적으로 피한 덕분에, Container Network Interface를 통해 혁신이 번성할 수 있었습니다. 수년간 오버레이 터널과 iptables 규칙에 의존했던 네트워킹이, 이제는 프로그래머블 커널 로직으로 구현되는 단계로 진화했죠.
Cilium이 주목받는 이유는 단순합니다. 현대 커널 기능이 마침내 네트워킹을 쿠버네티스가 항상 약속했던 속도와 확장성으로 동작시킬 수 있게 되었거든요.
2026년 현재, 많은 팀이 Cilium으로 마이그레이션하고 있는 것도 이런 맥락에서 이해할 수 있을 것 같습니다.