K8S Calico vs Cilium — 단순한 CNI 비교를 넘어, 네트워킹 철학의 충돌

K8S Calico vs Cilium

쿠버네티스 네트워크 플러그인(CNI) 중 가장 자주 비교되는 두 이름, Calico와 Cilium.
둘 다 Pod 간 통신을 책임지는 핵심 구성요소지만, 접근 방식은 완전히 다르다.
Calico는 전통적인 리눅스 네트워킹 — iptables와 BGP를 이용해 단순하고 예측 가능한 L3 네트워크를 만든다.
반면 Cilium은 eBPF를 기반으로 커널 수준에서 트래픽을 직접 제어하며, L7까지 관찰과 정책을 확장한다.

결국 이 비교는 “어떤 CNI가 더 빠르냐”가 아니라,
**“운영자가 어떤 방식으로 네트워크를 이해하고 관리하길 원하는가”**의 문제다.
Calico는 익숙함과 안정성을, Cilium은 가시성과 진화된 보안을 제공한다.

1. 두 프로젝트의 출발점부터 다르다

Calico는 *“리눅스 네트워킹의 본질을 건드리지 않는다”*는 철학으로 시작했다.
iptables와 BGP, 즉 기존 네트워크의 언어 위에서 쿠버네티스 네트워킹을 구현한다.
그 결과 — 단순하고 예측 가능한 L3 기반 CNI :
운영자는 시스템 내부에서 어떤 패킷이 어디로 가는지 쉽게 읽을 수 있다.

반면 Cilium은 완전히 다른 시각에서 태어났다.
리눅스 커널에 새로 추가된 eBPF (extended Berkeley Packet Filter) 를 적극 활용해,
패킷을 iptables로 전달하지 않고 커널 내부에서 직접 처리한다.
즉, Cilium은 eBPF hook 레벨에서 데이터 플레인을 제어하는 구조로,
기존 네트워크 계층을 ‘우회’하지 않고 커널 자체를 네트워크 엔진으로 확장한 셈이다.

2. 내부 구조 비교 — iptables vs eBPF

Calico는 iptables를 직접 다룬다.
따라서 규칙이 수천 개로 늘어나면 체감 성능이 떨어진다.
한편 Cilium은 eBPF map을 사용하므로, 네트워크 정책 수와 성능이 거의 비례하지 않는다.
이는 대규모 멀티테넌트 환경에서 특히 결정적이다.

3. 정책 모델의 근본적인 차이

Calico의 정책은 쿠버네티스 표준 NetworkPolicy를 그대로 따른다.
즉, L3/L4 수준에서의 통제 — IP, Port 중심이다.
Cilium은 여기서 한 단계 더 나아가 L7 정책을 지원한다.

예를 들어 “pod A는 pod B의 /api/v1/metrics 엔드포인트만 호출 가능” 같은 규칙이 가능하다.
이는 Cilium이 eBPF를 통해 HTTP 레이어까지 패킷을 해석하기 때문이다.
이건 단순히 “보안 정책이 더 정교하다” 수준이 아니라,
마이크로서비스 트래픽의 논리적 제어가 가능해진다는 의미다.

4. 실제 운영 환경에서 체감되는 차이점

• Cilium 설치 직후 Cilium에서는 pod 간 통신이 iptables trace에 나타나지 않는다.
  대신 같은 계층의 정보를 bpftool map show나 hubble observe 같은 도구로 확인한다.
  → 네트워크 분석 도구 체계 자체가 달라진다.
• Calico에서는 Cilium의 Hubble처럼 L7 트래픽 플로우를 시각화할 수 있는
  도구가 없다.
  대신 syslog 기반으로 Flow log를 모아야 한다.
• Calico는 커널 버전 의존성이 낮다.
  Cilium은 eBPF hook이 커널 버전에 따라 달라서, 최소 5.x 이상 커널이 필요하다.
• 정책 디버깅 난이도
  Calico → iptables -L -n -v로 어느 정도 눈에 보인다.
  Cilium → cilium monitor 나 hubble observe로 보는데, 훈련이 필요.

요약하자면,

Calico는 “리눅스 네트워킹을 잘 아는 운영자”에게 익숙하고,
Cilium은 “클라우드 네이티브 보안과 관찰성을 중시하는 팀”에게 맞다.

5. 실제 선택 가이드

운영자는 “무엇을 해결하려는가”에 따라 선택해야 한다.
단순히 Cilium이 새롭다고 무작정 도입하면, 학습 비용이 생각보다 크다.
그러나 일단 익숙해지면, Cilium은 네트워크가 아니라 플랫폼 레벨 보안/가시성 계층이 된다.

6. 결론 — CNI를 넘은 Cilium, 여전히 유효한 Calico

Calico는 여전히 훌륭하다.
대규모 트래픽 처리, BGP 기반 라우팅 통합, 단순한 구성…
운영자가 제어권을 잃지 않으면서 안정적인 네트워크를 유지할 수 있다.

Cilium은 다른 길을 걷는다.
이는 단순히 CNI가 아니라, eBPF로 OS 레벨에서 트래픽을 관찰·제어·보호하는 플랫폼이다.
네트워크를 “패킷”이 아니라 “의도(Intent)” 단위로 다루게 하는 철학이다.

7. 동작 Flow 비교

Calico Data Plane & Policy Enforcement (BGP Routing Mode)

Calico는 환경에 따라 IP-in-IP, VXLAN, 또는 BGP 모드로 동작할 수 있으며,
본 예시는 BGP 기반 구조를 기준으로 설명한다.

Calico는 리눅스의 iptables를 기반으로 Pod 간 통신을 제어한다.
패킷이 어떻게 흐르고 정책이 어떻게 적용되는지 한 번 살펴보자.

1. Traffic Originates (트래픽 시작)
   Pod에서 트래픽이 발생하면, 해당 패킷은 veth 인터페이스를 통해 리눅스 커널로 전달된다.
2. Policy Lookup & Filtering (정책 조회 및 필터링)
   커널 내부의 iptables 규칙이 적용되며,
   Calico의 Felix 프로세스가 이 규칙을 지속적으로 관리한다.
   어떤 Pod가 누구와 통신할 수 있는지, 어떤 포트를 허용할지 등의 정책이 여기서 판단된다.
3. Forwarded Traffic (트래픽 전달)
   정책을 통과한 패킷은 커널의 라우팅 테이블을 거쳐 목적지 노드로 전달된다.
   Calico는 BGP를 사용해 각 노드 간 라우팅 정보를 교환하고,
   BGP Daemon이 이 정보를 기반으로 패킷의 다음 홉(next hop)을 결정한다.
4. Node-to-Node Communication (노드 간 통신)
   이렇게 라우팅된 트래픽은 목적지 노드의 커널로 전달되어,
   다시 iptables 규칙을 거친 뒤 최종 Pod에 도착한다.

요약하자면 Calico의 네트워크 경로는
Pod → Linux Kernel(iptables 정책 적용) → BGP 기반 라우팅 → 다른 Node → 대상 Pod의 순서로 진행된다.

모든 트래픽은 iptables 규칙 체인을 순차적으로 통과하기 때문에
규칙 수가 많아질수록 커널이 처리해야 할 비교 연산도 늘어난다.
즉, 단순하지만 명확한 L3 기반 구조가 Calico의 가장 큰 특징이다.

Cilium Data Plane & Policy Enforcement with eBPF

Cilium은 iptables를 사용하지 않는다.
대신 리눅스 커널의 eBPF (extended Berkeley Packet Filter) 기능을 활용해
트래픽을 커널 공간에서 직접 처리한다.
즉, 패킷이 유저 공간을 오가지 않고 커널 내부에서 곧바로 정책이 적용되고 전달된다.

1. Traffic Originates (트래픽 시작)
   Pod에서 트래픽이 발생하면 패킷은 veth 인터페이스를 통해 커널로 들어간다.
2. Policy Lookup & Filtering (정책 조회 및 필터링)
   커널 내부의 eBPF 프로그램이 네트워크 정책을 확인한다.
   이 정책은 Cilium Agent가 커널에 로드한 eBPF 맵(Map)과 훅(Hook)을 통해 관리된다.
   따라서 iptables 규칙을 순차적으로 탐색하지 않아도 된다.
   (정책 검색은 O(1) 해시맵 접근으로 처리된다.)
3. Forwarded Traffic (트래픽 전달)
   정책을 통과한 패킷은 eBPF 데이터 플레인에서 직접 처리되어
   목적지 노드로 전달된다.
   이때 노드 간 연결은 VXLAN, Geneve, 또는 Direct Routing 방식으로 구성될 수 있다.
4. Node-to-Node Connectivity (노드 간 연결)
   각 노드는 커널 내부 eBPF 프로그램을 통해 패킷을 라우팅하며,
   Cilium Agent와 Operator가 이를 동적으로 제어한다.
   별도의 BGP 데몬 없이도 노드 간 라우팅과 정책이 일관되게 유지된다.

요약하자면 Cilium의 네트워크 경로는
Pod → eBPF(Network Policy Enforcement) → eBPF(Data Plane) → Node → 대상 Pod
으로 이어진다.

모든 처리가 커널 레벨에서 이루어지기 때문에
유저 공간 컨텍스트 전환이 없고,
정책 조회 속도는 O(1), 정책 변경 반영은 실시간으로 이루어진다.
또한 Hubble을 통해 L7 수준의 트래픽 흐름까지 시각화할 수 있다는 점이 Calico와의 가장 큰 차이다.

🛠 마지막 수정일: 2025.11.13