📋 요약
이 글에서는 Kubernetes 네트워킹의 핵심 구성요소인 CNI를 중심으로,
Calico eBPF 모드와 Cilium의 기술적 차이를 다룹니다.
두 CNI의 아키텍처 철학과 운영 특성을 비교함으로써,
클러스터 환경에 적합한 네트워킹 솔루션 선택의 기준을 정리합니다.
#CNI #eBPF #Calico #Cilium #Kubernetes
개요
지난해 kt cloud는 마스터 노드(Control Plane) 관리를 자동화하여 Cloud Native 환경의 운영 부담을 획기적으로 줄여주는 관리형 쿠버네티스 서비스, Managed KS를 선보였습니다.
Managed KS 클러스터의 네트워킹을 책임지는 핵심 엔진으로는 Calico CNI가 채택되어 운영 중인데요.
오늘은 이 Calico를 살펴보고, 최근 고성능 네트워킹의 대세로 떠오른 eBPF 모드의 Calico, 그리고 CNI 계의 강력한 대항마로 주목받는 Cilium을 기술적인 관점에서 깊이 있게 비교해 보고자 합니다.
CNI란?
쿠버네티스 같은 컨테이너 오케스트레이션 도구와 네트워크 플러그인 간의 표준 규격으로, 컨테이너 생성·삭제 시 네트워크 환경을 자동으로 설정해 주는 인터페이스입니다.
쉽게 말해, 호스트(Node)와 Pod 사이를 잇는 가상 케이블(veth pair)을 생성하고, 라우팅 테이블 작성, Pod IP 할당, Network Policy 구성 등 Pod가 클러스터 내외부와 실제로 "통신할 수 있는 물리적/논리적 통로"를 만드는 모든 과정을 책임집니다.
주요 CNI종류로는 Calico, Cilium, Flannel 등을 말할 수 있습니다.
Managed KS에서 CNI 옵션
![[비교분석] Calico vs Cilium : kubernetes에서 eBPF를 대하는 두 CNI 거인](https://blog.kakaocdn.net/dna/bhekKB/dJMcahKvVJ0/AAAAAAAAAAAAAAAAAAAAABUNjCyzr-Y-mG5GoZRiSdXqDC5OlLMFmcY0qNH95Oi1/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1774969199&allow_ip=&allow_referer=&signature=UzUhiddJkih59nI4HGiiaYPzqu0%3D)
현재 Managed KS 상품 화면에서 클러스터 구축 시, CNI로 선택할 수 있는 옵션은 Calico가 유일합니다.
그 이유는 kubernetes 최신 버전의 대표적인 CNI 이기 때문입니다. 특히 Calico를 Standard (표준) 모드로 설치하여 제공합니다.
Calico Standard 모드 기반 기술인 iptables 는 20년간 리눅스 네트워킹의 표준이었고, iptables-save, tcpdump, conntrack 같은 도구로 패킷의 흐름, 병목구간을 확인할 수 있는 여러 툴을 사용할 수 있어 많은 사랑을 받았었습니다.
하지만 수많은 규칙을 사용하는 환경에서는 성능 저하의 단점이 있어, 이를 보완한 eBPF 기반의 CNI가 등장하게 됩니다.
eBPF (Extended Berkeley Packet Filter) 란?
간략히 설명하면 eBPF는 리눅스 커널에서 프로그램을 실행하는 기술입니다.
- 원리: 패킷이 커널의 네트워크 스택을 통과할 때, iptables 같은 고정된 규칙 대신 사용자가 짠 고성능 프로그램을 즉시 실행합니다.
- 사용 이유: 기존 iptables 방식은 서비스(Service)가 많아질수록 규칙을 위에서부터 하나씩 검사해야 해서 느려집니다. eBPF는 Key-Value 방식의 BPF Map데이터를 사용해 수만 개의 서비스 중에서도 목적지를 단번에 찾아냅니다.
eBPF 기술에 대한 보다 자세한 내용은 이전 포스팅을 한번 읽어봐주세요 ~
eBPF 기반의 강력한 쿠버네티스 네트워킹: Cilium CNI 소개
[kt cloud Container개발팀 김도원 님] eBPF 기반의 강력한 쿠버네티스 네트워킹: Cilium CNI 소개 Cilium CNI 란?Cilium은 현대적인 클라우드 네이티브 환경을 위한 강력한 네트워킹 솔루션입니다. 2023
tech.ktcloud.com
Calico(eBPF모드) vs Cilium
그럼 본격적으로, eBPF 모드를 사용하는 두 CNI, Calico eBPF모드와 Cilium를 살펴보겠습니다.
![[비교분석] Calico vs Cilium : kubernetes에서 eBPF를 대하는 두 CNI 거인](https://blog.kakaocdn.net/dna/mxqZI/dJMcach7Rnc/AAAAAAAAAAAAAAAAAAAAAFSbsnV2dMnGwUshIW-_d7avQBUGoi38OvjgZfdr-Y7n/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1774969199&allow_ip=&allow_referer=&signature=dauxRPf0GpXrCC%2FQbAoXJHbsYto%3D)
1. 탄생 배경과 철학
두 CNI는 eBPF에 대한 다른 철학을 갖고 있습니다.
- Calico → eBPF Optional
- 전통적인 iptables와 BGP(Border Gateway Protocol)기반 라우팅의 강자입니다. → Standard 모드
- eBPF는 Calico가 지원하는 여러 데이터 플레인(Standard, VPP, eBPF) 중 하나로, 필요에 따라 선택적으로 사용할 수 있는 유연성이 장점입니다.
- Managed KS에서는 Calico를 Standard 모드로 설치하여 기본 CNI로 제공하고 있습니다.
- Cilium → eBPF Native
- 시작부터 eBPF를 위해 설계된 CNI로, 모든 네트워킹 로직이 eBPF를 전제로 설계되었습니다.
- iptables를 완전히 우회하며, 모든 네트워크 제어와 로드밸런싱을 커널 내 eBPF 프로그램으로 처리합니다.
- 모든 기능(보안, 라우팅, 관측)이 eBPF 바이트코드를 중심으로 유기적으로 연결되어 있습니다.
2. kube-proxy 대체
Managed KS에서 기본 설치되는 kube-proxy는 kubernetes에서 Service Cluster IP에 대하여 각 Pod IP를 endpoint로 관리하며, 로드밸런싱 역할을 합니다.
- Calico: 기존 kube-proxy ON/OFF 가능
- kube-proxy를 사용할수도, 안할수도 있는데, 이와 상관없이 eBPF 모드를 활성화할 수 있습니다.
- Calico의 핵심 에이전트인 Felix가 Kubernetes API 서버를 직접 watch합니다. Network Policy, Pod IP, EndpointSlice 와 같은 클러스터의 모든 변화를 실시간으로 BPF Map에 동기화합니다.
- 추가로 Typha 라는 중간 대리 에이전트를 사용하면, Kubernetes API Server ↔ Typha ↔ Felix 구조로 통신하여 Kubernetes API서버의 부하를 줄여줄 수 있습니다.
- Cilium: kube-proxy를 완전히 제거
- kube-proxy 기능을 완전히 내재화하여 제거하는 'Zero kube-proxy'를 지향합니다.
- 설정이 매우 깔끔하고 사이드카 없는 서비스 메시(Sidecarless Service Mesh) 구현에 유리합니다.
- Cilium은 Cilium Agent가 핵심 역할을 합니다. 새로운 Pod이 생성되거나 정책이 바뀔 때마다 해당 상황에 최적화된 C 코드를 eBPF 바이트코드로 컴파일하여 커널에 직접 주입합니다.
3. 트래픽 관측(Observability) 도구
각 CNI는 eBPF hook을 통과하는 트래픽을 관측할 수 있는 툴 관련하여 차이가 있습니다.
- Calico → Felix + 기타 오픈소스 조합
- Felix가 수집한 데이터를 바탕으로 Flow Logs 등을 제공합니다. 다만 추가로 시각화 도구로 기타 오픈소스가 필요합니다.
- Cilium → Hubble
- eBPF hook을 통해 L3부터 L7(HTTP, gRPC, Kafka 등)까지의 트래픽을 아주 깊게 들여다볼 수 있는 전용 시각화 도구인 Hubble을 제공합니다.
4. 각 CNI의 장점
- Calico(eBPF모드)의 장점
- 여러 데이터 플레인을 지원하므로 Standard 모드에서 eBPF 모드로 유연하게 교체할 수 있습니다.
- BGP(Border Gateway Protocol) 지원 능력이 독보적입니다.
- Cilium의 장점:
- eBPF Native CNI인 만큼 eBPF의 성능을 극대화 할수 있는 강력한 기능을 제공합니다.
- Identity-based security 방식을 사용하여 IP 주소가 아닌 'ID' 기반으로 정책을 관리합니다. Pod의 label을 분석해 특정 ID(예: role=frontend → ID: 101)를 부여하고, 이 정보를 BPF Map에 기록하여, 패킷이 나갈 때 IP 대신 이 ID를 기준으로 정책을 판별하게 만듭니다.
- 전용 시각화 도구 Hubble, Sidecarless 서비스 메시 등 부가 기능도 사용할 수 있습니다.
- eBPF 단점: 단점은 두 CNI 모두 eBPF기술에 대한 단점을 가진다고 볼 수 있습니다.
- 최신 커널(최소 v5.3, 권장 v5.10 이상)을 요구합니다. 오래된 OS 이미지를 사용하거나 특정 보안 솔루션이 커널 훅을 선점하고 있는 경우, 예상치 못한 커널 패닉(Kernel Panic)이나 네트워크 순단 현상이 발생할 위험이 있습니다.
- eBPF 전용 도구에 대한 엔지니어의 숙련도가 필요합니다.
한눈에 비교하기
| 비교 항목 | Calico (eBPF 모드) | Cilium |
| eBPF 의존도 | 선택 가능 (Optional) | 핵심 (Native) |
| 주요 강점 | BGP 기반 확장성, 하이브리드 클라우드 | L7 보안, 관측성(Hubble), Service Mesh |
| kube-proxy 대체 | 지원함 (성능 최적화 중심) | 매우 성숙함 (완전 대체 권장) |
| 보안 모델 | Workload-based (IP/Label 기반) | Identity-based (신원 기반) |
| 운영 난이도 | 중간 (기존 Calico 사용자는 비교적 익숙) | 높은 편 (eBPF 전용 도구 숙련도 필요) |
| 추천 환경 | 대규모 온프레미스 및 복합 클라우드 | 보안과 가시성이 중요한 최신 MSA |
결론
![[비교분석] Calico vs Cilium : kubernetes에서 eBPF를 대하는 두 CNI 거인](https://blog.kakaocdn.net/dna/loRcQ/dJMb99Z1KMB/AAAAAAAAAAAAAAAAAAAAAMeydrXxFtBgI-RWZFuLYORQDPvnYHTTRk0iIReRSXaP/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1774969199&allow_ip=&allow_referer=&signature=C4vnToextLXouWZqmTQ590zW1ow%3D)
eBPF는 고성능 클러스터 구축을 위한 매력적인 기술이지만, 운영의 편의성과 범용성 측면에서는 Calico Standard 모드가 여전히 강력한 표준입니다.
Legacy Managed KS가 표준 모드를 기본으로 제공하는 이유도 바로 이 '안정성'에 있습니다.
나아가 kt cloud는 더 강력한 네트워크 퍼포먼스를 원하는 고객의 니즈에 부응하고자, 차세대 인프라인 'NEXT Managed KS'에서 Cilium CNI 기반의 eBPF 모드를 표준으로 채택할 예정입니다.
한층 더 진화할 kt cloud의 클라우드 네이티브 여정에 많은 관심과 기대를 부탁드립니다.
❓ 자주 묻는 질문 (FAQ)
📚 관련/출처
'Tech Story > DevOps & Container' 카테고리의 다른 글
| [튜토리얼] kt cloud가 자원을 최적화하는 방법: 컨테이너 리소스 동적할당 구현기 (0) | 2026.01.22 |
|---|---|
| [실전가이드] OpenStack Helm 배포를 GitOps로 전환: FluxCD+Argo CD 아키텍처 설계와 운영 전략 (0) | 2026.01.14 |
| [가이드] kt cloud에서 사용하는 Umbrella Helm Chart 설계 전략 (1) | 2025.11.19 |
| [분석] ArgoCD 3.0이 선언한 GitOps 새로운 시대: 주요 업데이트 기능 완벽 해부 (0) | 2025.10.16 |
| [사례연구] kt cloud OpenStack GitOps 배포 전략: Genestack 기반 CI/CD 자동화 구축 과정 (2) | 2025.08.05 |