이번 글에서는 K8s 내부 네트워킹의 심장부인 kube-proxy가 대규모 환경에서 어떤 한계에 부딪히는지 살펴보고, 이를 근본적으로 해결하는 eBPF 기반의 Cilium이 왜 차세대 K8s 네트워크 표준으로 떠오르고 있는지 알아봅니다.
1. kube-proxy와 iptables의 한계
K8s에서 Service로 트래픽을 보내면, 실제로는 각 노드에서 실행 중인 kube-proxy가 트래픽을 적절한 Pod로 전달합니다. 전통적으로 kube-proxy는 iptables 규칙을 사용합니다. 문제는 규모가 커지면 iptables 규칙이 선형으로 급증한다는 것입니다.
- Service 1,000개 × 각 Service당 Pod 10개 = iptables 규칙 수만 개
- 패킷 하나가 도착할 때마다 이 규칙들을 순차적으로(O(n)) 탐색
💡 실제 사례: 대규모 클러스터에서 Service 수가 5,000개를 넘어가면
iptables 규칙 업데이트에만 수 분이 소요되는 현상이 보고되었습니다.
2. eBPF: 리눅스 커널 안에서 동작하는 프로그래밍 가능한 네트워크
eBPF(extended Berkeley Packet Filter)는 리눅스 커널의 네트워크 스택 안에 사용자 정의 프로그램을 주입할 수 있는 기술입니다.
- iptables는 커널의 netfilter 훅에서 규칙 체인을 순차 평가하지만, eBPF는 네트워크 스택 훨씬 앞단(XDP/tc)에서 패킷을 가로채 처리
- O(n) 선형 탐색 대신 해시맵 기반 O(1) 조회로 성능이 Service 수에 영향을 받지 않음
- 패킷이 불필요한 네트워크 스택 계층을 건너뛸 수 있어 레이턴시 감소
물론 kube-proxy도 손 놓고 있었던 것은 아닙니다. iptables 외에 커널 해시테이블 기반의 IPVS 모드를 제공해 대규모 환경의 탐색 비용을 줄였고, 최근에는 nftables 모드도 추가됐습니다.
다만 어느 쪽이든 커널 네트워크 스택 전체를 타야 한다는 구조적 제약은 남습니다. eBPF는 바로 이 지점을 건드립니다.
3. Cilium: eBPF 위에 세운 K8s 네트워크 플랫폼
Cilium은 eBPF를 K8s 환경에서 쉽게 활용할 수 있도록 만든 CNI(Container Network Interface) 플러그인이자 종합 네트워크 플랫폼입니다.
Cilium이 제공하는 핵심 기능:
- kube-proxy 완전 대체: iptables 없이 eBPF만으로 Service 라우팅 처리
- L3/L4/L7 Network Policy: HTTP 경로나 gRPC 메서드 단위의 정교한 보안 정책
- 투명 암호화(WireGuard): Pod 간 트래픽을 애플리케이션 수정 없이 자동 암호화
- 사이드카 없는 서비스 메시: Istio처럼 각 Pod에 Envoy 사이드카를 붙이지 않고도 mTLS, 트래픽 관측 가능
- Hubble: 네트워크 플로우를 실시간으로 시각화하는 관측 도구
4. 요약: kube-proxy에서 Cilium으로의 전환
| 항목 | kube-proxy (iptables) | Cilium (eBPF) |
| 패킷 처리 | 커널 netfilter 규칙 체인 순차 탐색 | 커널 레벨 해시맵 O(1) |
| 대규모 성능 | Service 5,000+ 시 규칙 업데이트 병목 | Service 수에 무관한 일정 성능 |
| 암호화 | 별도 설정 필요 | WireGuard 내장 투명 암호화 |
| 관측성 | 제한적 | Hubble로 네트워크 플로우 실시간 시각화 |
현재 GKE는 Dataplane V2를 통해, AKS는 "Azure CNI Powered by Cilium" 옵션을 통해 Cilium 기반 네트워킹을 제공하는 등 주요 매니지드 K8s 서비스들이 eBPF 데이터플레인을 채택하기 시작했으며, CNCF 컨퍼런스에서도 eBPF/Cilium 관련 세션이 해마다 증가하는 추세입니다.