Cilium vs Calico, eBPF 시대에 우리가 다시 고른 CNI
CNI 교체는 사실 자주 할 일이 아니다. 한 번 들어가면 클러스터 수명 내내 같이 가는 컴포넌트라 잘못 고르면 두고두고 후회한다. 우리 팀은 작년 4분기에 Calico로 운영하던 프로덕션 클러스터 3개를 Cilium으로 옮겼고, 그 후 약 8개월을 양쪽 다 운영해봤다. 아직 일부 레거시 클러스터는 Calico를 그대로 두고 있어서 비교가 가능한 상황이다.
이번 KubeCon EU에서도 Cilium 세션이 절반은 되더라. CNCF 2025 연간 서베이에서 Cilium이 Calico랑 Flannel을 제치고 프로덕션 CNI 1위를 먹었다는 발표가 있었는데, 우리 팀이 옮길 때만 해도 그 정도까진 아니었다. 1년 사이에 분위기가 꽤 바뀐 셈이다.
왜 옮겼는가
솔직히 처음부터 옮길 생각은 없었다. Calico는 안정적이었고 BGP로 베어메탈 라우터에 광고 잘 됐고, NetworkPolicy도 잘 동작했다. 문제는 두 가지였다.
첫 번째는 iptables 룰 폭증. 노드 한 대당 서비스가 600개를 넘기면서 kube-proxy가 만든 iptables 체인이 수만 라인이 됐다. 노드 부팅 시 conntrack 동기화에만 2분씩 걸렸고, 새 서비스 하나 만들면 룰 갱신이 수 초 단위로 느려졌다. IPVS 모드로 바꿔도 근본적으로 비슷한 한계가 있었다.
두 번째는 관측성. Pod간 통신이 어디서 끊겼는지 확인하려면 결국 tcpdump를 까야 했다. NetworkPolicy가 drop한 패킷을 보려고 Calico Enterprise 견적을 받았는데 가격이 만만치 않았다. Hubble을 쓰면 무료로 비슷한 걸 얻을 수 있다는 점이 컸다.
운영해본 결과 - 좋은 점
kube-proxy를 버린 것
Cilium의 kube-proxy replacement 모드로 돌리면 iptables 체인 자체가 사라진다. 노드 부팅 시간이 평균 40초 단축됐고, 서비스 추가/삭제 지연이 거의 없어졌다. eBPF 맵으로 LB 룰을 관리하니까 O(1) 룩업이라는 얘긴데, 실제로 P99 레이턴시가 클러스터 평균 8% 정도 빨라졌다. 노드별 편차도 줄었고.
Hubble의 가시성
이건 진짜 게임체인저였다. 어떤 Pod이 어떤 Pod한테 어느 포트로 통신했는지, 그게 NetworkPolicy에 의해 허용됐는지 차단됐는지를 실시간으로 본다. 신규 마이크로서비스 배포할 때 NetworkPolicy를 먼저 deny-all로 깔고 Hubble로 실제 통신 패턴 관찰한 다음 allow 룰을 추가하는 방식으로 운영 패턴이 바뀌었다.
# 실시간으로 NetworkPolicy 위반 트래픽 보기
hubble observe --verdict DROPPED --since 5mGateway API 지원
Ingress-nginx EOL 얘기 나오면서 우리도 Gateway API로 옮기는 중인데, Cilium이 Gateway API 구현체를 자체적으로 제공한다. 별도 컨트롤러 깔 필요가 없어서 운영 부담이 줄었다. 다만 아직 일부 기능(특히 TCPRoute의 일부 옵션)은 매끄럽지 않다.
운영해본 결과 - 안 좋은 점
디버깅 난이도
eBPF는 빠른데, 뭔가 안 될 때 들여다보기가 어렵다. Calico 시절엔 iptables -L -n -t nat 한 번이면 룰이 보였는데, Cilium은 cilium bpf lb list, cilium endpoint get, cilium monitor 같은 걸 조합해야 한다. 처음 한 달은 팀 내 디버깅 가이드 만드는 데 시간을 꽤 썼다.
특히 IdentityID 개념이 헷갈린다. Pod 라벨이 바뀌면 Identity가 새로 발급되는데, 이게 NetworkPolicy 적용에 어떻게 영향을 주는지 직관적이지 않다. 한번은 라벨 한 글자 오타로 정책이 적용 안 됐는데, 이걸 알아내는 데 두 시간 걸렸다.
메모리 사용량
eBPF 맵을 위해 Cilium agent가 메모리를 꽤 먹는다. 서비스 수 600개 기준 노드당 agent 메모리가 1.2GB 정도. Calico는 같은 조건에서 400MB 수준이었다. 작은 노드에선 부담된다. 우리는 m5.4xlarge 이상만 써서 별 문제 없었지만, 엣지 클러스터에선 다시 생각해볼 수 있다.
업그레이드 리스크
Cilium은 마이너 버전 업그레이드할 때 종종 호환성 이슈가 있다. 1.14 → 1.15 갈 때 CRD 마이그레이션 때문에 한 차례 롤백한 적 있다. Calico는 이런 점에선 보수적이고 안정적이었다.
그럼 Calico는 끝났냐
전혀 아니다. 우리가 아직 Calico를 유지하는 클러스터들이 있는 이유가 있다.
작은 클러스터. 노드 20대 미만, 서비스 200개 미만이면 Calico가 더 가볍고 빠르게 뜬다. Cilium의 장점인 kube-proxy 제거가 이 규모에선 체감되지 않는다.
Windows 노드. Cilium은 여전히 Windows 컨테이너 지원이 약하다. 우리 팀에선 .NET 워크로드를 위해 윈도우 노드를 일부 운영하는데, 이건 Calico로 남겨뒀다.
BGP 라우터 통합이 까다로운 환경. Cilium도 BGP 지원하지만 Calico의 BGP가 훨씬 성숙하다. 데이터센터 ToR 스위치랑 풀 메쉬 BGP 피어링하는 상황에선 Calico가 안정적이다.
마이그레이션은 어떻게 했나
이건 누가 물어보면 답하기 곤란한데, 솔직히 우리는 다운타임을 허용하고 한 클러스터씩 새로 만들어서 워크로드를 옮기는 방식을 썼다. CNI를 in-place로 바꾸는 건 너무 위험하다고 판단했다.
순서는 대략:
- 새 클러스터를 Cilium으로 띄움
- ArgoCD로 워크로드 싱크
- 외부 LB의 백엔드 비중을 5%, 20%, 50%, 100% 로 점진적 이동
- Calico 클러스터 디커미션
NetworkPolicy YAML은 99% 그대로 호환됐다. 일부 Calico 전용 GlobalNetworkPolicy를 쓰던 부분만 CiliumClusterwideNetworkPolicy로 변환했다.
그래서 뭘 골라야 하나
뻔한 결론인데, 상황에 따라 다르다. 우리 팀 기준 분기점:
- 노드 50대 이상, 서비스 300개 이상이고 관측성이 필요하면 → Cilium
- 작은 클러스터, 안정성/단순함 우선이면 → Calico
- BGP 헤비, Windows 워크로드면 → Calico
신규 클러스터를 지금 새로 만든다면 우리는 Cilium을 고를 거다. 다만 운영 학습 곡선이 있다는 점은 미리 알고 시작해야 한다. eBPF가 마법은 아니다.
혹시 다른 환경에서 비슷한 결정 내려보신 분 있으면 댓글로 경험 공유해주시면 좋겠다. 특히 Calico에서 Cilium으로 in-place 마이그레이션 성공한 사례가 있다면 정말 궁금하다.