Cilium vs Calico, 2026년에 새 클러스터를 만든다면

 

들어가며

3년 전쯤만 해도 "CNI는 그냥 Calico 깔자"가 답이었다. 안정적이고 자료 많고 문제 생기면 iptables 룰 뜯어보면 됐다. 그런데 최근 1년 사이에 분위기가 좀 바뀌었다. GKE Dataplane V2가 Cilium 기반이고, AKS도 "Azure CNI Powered by Cilium"을 권장 옵션으로 밀고 있다. EKS는 기본은 여전히 AWS VPC CNI지만 Cilium을 얹는 사례가 눈에 띄게 늘었다.

우리 팀도 작년 하반기에 새 클러스터 두 개를 띄우면서 Cilium으로 갈아탔다. 기존 클러스터는 Calico를 계속 쓰고 있어서, 1년 정도 두 개를 같이 운영하면서 느낀 걸 정리해본다. 결론부터 말하면 "신규는 Cilium, 기존은 굳이 안 옮긴다"이긴 한데, 이게 모든 팀에 적용되는 답은 아니다.

무엇이 다른가 (간단히)

근본적인 차이는 데이터플레인이다. Calico는 전통적인 Linux 네트워킹 스택, 즉 iptables(또는 IPVS) + netfilter 위에 얹어진다. Cilium은 eBPF로 커널에 직접 프로그램을 붙여서 패킷을 처리한다.

사실 요즘은 Calico도 eBPF 데이터플레인을 옵션으로 제공한다. 그래서 "eBPF냐 아니냐"보다는 "eBPF를 중심에 놓고 설계됐냐" 가 차이라고 보는 게 정확하다. Cilium은 처음부터 eBPF 위에서 모든 걸 했고, Hubble(관측성)과 Tetragon(런타임 보안)이 그 위에 자연스럽게 얹혀 있다. Calico의 eBPF는 좀 더 "전통적인 Calico 경험을 유지하면서 성능만 가져가자"는 느낌이다.

성능, 그게 정말 체감되나

벤치마크 자료들은 다들 Cilium이 P99 레이턴시 40~50% 낮고 처리량도 25% 정도 높다고 한다. 우리 환경에서도 비슷한 수치는 나왔다. Pod-to-service 트래픽에서 P99가 Calico 1.4ms 정도였다가 Cilium으로 옮긴 후 0.8~0.9ms로 떨어졌다.

근데 이게 실제로 체감이 되냐고 하면, 대부분의 워크로드에서는 아니다. 평범한 웹 API 서버나 일반적인 마이크로서비스 트래픽에서는 0.5ms 차이가 의미가 없다. 우리도 일반 서비스 클러스터에서는 Cilium으로 옮긴 직후 "어, 좀 빨라진 것 같은데?" 하는 느낌이 전혀 없었다.

체감되는 곳은 두 군데였다:

첫째, NetworkPolicy를 많이 쓰는 클러스터. iptables 룰이 정책 수에 비례해서 늘어나니까 정책이 수백 개 넘어가면 노드의 conntrack/iptables 갱신 시간이 눈에 띄게 길어진다. Cilium은 eBPF 해시 테이블 룩업이라 정책 개수에 거의 무관하게 O(1)이다. 우리 멀티테넌트 클러스터에서 정책이 1200개 정도 됐는데, Calico일 때는 정책 한 번 갱신할 때마다 노드 CPU가 잠깐 튀었다. Cilium으로 옮긴 후엔 그게 사라졌다.

둘째, 서비스 개수가 많은 클러스터. kube-proxy iptables 모드는 서비스마다 룰이 늘어나서 7000~8000개 넘어가면 룰 평가 시간이 보인다. Cilium은 kube-proxy를 대체할 수 있고(eBPF 기반 ClusterIP 처리), 이게 진짜 깔끔하다.

평범한 클러스터라면 이 차이가 안 보일 수 있다는 걸 강조하고 싶다. 마케팅 자료의 "40% 더 빠릅니다"는 사실이지만 그게 우리 비즈니스 메트릭에 영향 줄 일은 거의 없다.

관측성 — 여기는 진짜 차이가 크다

Hubble은 Cilium을 선택하는 가장 큰 이유 중 하나다. 별도 사이드카 없이 L3~L7 트래픽을 다 볼 수 있다.

예전에 "이 Pod가 어디로 트래픽을 보내고 있지?"를 알고 싶으면 tcpdump 뜨거나 conntrack 들여다보거나 했는데, Hubble은 그냥 hubble observe --from-pod default/foo 한 줄이면 된다. L7도 보인다. HTTP 메서드, 경로, 응답 코드까지. 우리가 ServiceMesh를 안 깐 상태로도 이걸 다 보는 건 처음이라 좀 신기했다.

Calico에도 Calico Enterprise/Cloud로 가면 비슷한 기능이 있긴 한데, OSS 영역에서는 비교가 안 된다. 단순히 Pod 간 통신을 디버깅하는 일상 작업이 훨씬 빨라진다.

L7 정책과 사이드카리스 메시

NetworkPolicy의 L4 한계는 다들 알 거다. "frontend가 backend의 8080으로 갈 수 있다"까지는 되는데 "backend의 GET /api/users는 되지만 DELETE /api/users는 안 된다"는 못 한다. Cilium은 CiliumNetworkPolicy로 L7까지 강제할 수 있다.

여기서 Service Mesh 얘기로 자연스럽게 넘어가는데, 우리는 Istio를 한참 쓰다가 Cilium Service Mesh로 갈아탔다. 사이드카 없는 메시. Envoy를 노드에서 한 번만 띄우는 구조다. 메모리/CPU 오버헤드가 사이드카 대비 80% 정도 줄었다. mTLS도 SPIFFE 기반으로 잘 된다.

다만, 모든 Istio 기능을 다 대체하지는 못한다. 복잡한 트래픽 시프팅, 카나리, 외부 인증 통합 같은 건 여전히 Istio가 강하다. 우리도 메인 클러스터 한 곳은 Istio를 유지하고 있다.

Cilium의 약점들

마냥 좋다고 쓰면 거짓말이다. 1년 운영하면서 겪은 불편한 점들:

디버깅이 어렵다. iptables는 그냥 iptables -L -t nat으로 룰을 다 볼 수 있고, 어디서 패킷이 막혔는지 추적이 쉽다. eBPF 프로그램은 커널 안에서 돌아가서 일반적인 Linux 툴로는 안 보인다. cilium monitor, bpftool, cilium-dbg 같은 Cilium 전용 툴을 익혀야 한다. 처음 한 달은 진짜 답답했다.

업그레이드가 신중해야 한다. Cilium은 활발히 개발 중이라 버전 사이에 동작이 미묘하게 바뀌는 경우가 있다. 1.14에서 1.15로 올릴 때 IPv6 관련 동작이 바뀌어서 일부 워크로드가 영향받았다. 릴리스 노트를 진짜 꼼꼼히 봐야 한다.

Windows 노드 지원이 없다. 윈도우 노드를 섞어 쓸 계획이 있다면 Cilium은 아직 답이 아니다. Calico는 Windows를 지원한다. 우리는 다행히 리눅스 only라서 문제가 안 됐다.

커널 버전 의존성. eBPF 기능을 제대로 쓰려면 비교적 최신 커널이 필요하다. 5.10 이상은 돼야 안정적이고, 5.15 이상을 권장한다. 노드 OS가 오래된 환경이라면 OS 업데이트 계획을 먼저 세워야 한다.

Calico를 계속 쓰는 게 합리적인 경우

우리가 기존 Calico 클러스터를 안 옮기는 이유와도 통한다:

• 클러스터가 잘 돌고 있고, NetworkPolicy 개수가 많지 않다 (수십 개 수준)
• L7 정책이 굳이 필요 없다 (L4로 충분)
• 팀 내 Calico 운영 노하우가 쌓여있다
• Windows 노드를 쓰거나 쓸 가능성이 있다
• 커널이나 OS를 최신으로 유지하기 어려운 환경이다

마이그레이션은 절대 공짜가 아니다. CNI 교체는 클러스터 재구성에 가깝다. 우리도 신규 클러스터에서만 Cilium을 쓰고, 기존 건 안 건드리기로 한 게 이 비용 때문이다.

그래서 결론

처음 클러스터를 만든다면 Cilium을 추천한다. 클라우드 매니지드 서비스(GKE, AKS)에서 점점 디폴트가 되어가고 있고, 관측성과 L7 정책 같은 기능이 일상 운영에서 진짜 도움이 된다.

이미 Calico로 잘 돌아가는 클러스터가 있다면, 굳이 옮기지 마라. "지금 잘 돌아가는 시스템을 바꾸지 마라"는 격언은 CNI에도 적용된다.

그리고 둘 다 잘 모르는 상태에서 결정해야 한다면, Cilium의 학습 곡선이 조금 더 가파르다는 것만 기억해두자. 디버깅 툴이 익숙하지 않을 때의 답답함은 무시 못 한다.

다음에는 Cilium Service Mesh로 Istio 사이드카 메시에서 옮긴 경험을 좀 더 자세히 써보려고 한다. 그쪽이 의외로 함정이 좀 있다.