[Kubernetes] Cilium vs Calico 네트워킹 성능 실측 비교

목차

• Kubernetes CNI에서 Cilium과 Calico를 왜 따로 봐야 할까요
• Cilium vs Calico 핵심 차이 정리
• 비교 전에 먼저 정해야 할 질문
• 실전 비교 환경 구성: 같은 조건으로 맞추는 게 먼저입니다
• Benchmark 워크로드 만들기: iperf3와 정책 테스트를 같이 봐야 합니다
• 기본 테스트 Pod 배포
• Service 경유 테스트도 꼭 해보세요
• NetworkPolicy 적용 후도 따로 측정
• 제가 실제로 체크한 관찰 포인트
• ⚠️ 주의사항과 트러블슈팅: 여기서 많이 막힙니다
• 1. MTU 불일치
• 2. 같은 노드에만 스케줄링되는 문제
• 3. 정책 테스트인데 DNS를 빼먹는 문제
• 4. 관찰 도구가 없는 상태에서 디버깅 시작
• 검증과 결과 해석: 숫자보다 패턴을 보셔야 합니다
• 어떤 환경에 Cilium, 어떤 환경에 Calico가 맞을까요
• 정리와 다음 단계
• 자주 묻는 질문
• Cilium이 항상 Calico보다 빠른가요?
• Calico도 eBPF를 쓰나요?
• Kubernetes CNI 비교에서 제일 중요한 항목은 뭔가요?

[Kubernetes] Cilium vs Calico 네트워킹 성능 실측 비교

Cilium vs Calico 이야기는 Kubernetes CNI를 운영하는 분들이 한 번쯤 꼭 부딪히는 주제입니다. 클러스터가 작을 때는 둘 다 잘 돌아가는 것처럼 보이는데, 서비스(Service) 수가 늘고 네트워크 정책(NetworkPolicy, 네트워크 접근 제어)까지 얹기 시작하면 느낌이 꽤 달라지거든요. 저도 처음엔 '어차피 Pod to Pod 통신만 되면 되는 거 아닌가?' 싶었는데, 실제로 홈랩에서 반복해서 붙였다 떼어보니 성능 자체보다도 어떤 경로에서 병목이 생기는지, 운영 중에 어디서 시간을 잡아먹는지가 더 중요하더라고요.

이번 글은 특정 벤더 홍보가 아니라, Cilium vs Calico를 benchmark 관점에서 어떻게 비교해야 하는지, 그리고 제가 실제로 비교할 때 어떤 항목을 봤는지 정리한 글입니다. 숫자를 지어내서 화려하게 쓰는 대신, 실제로 재현 가능한 측정 방법과 해석 포인트 위주로 풀어보겠습니다. 혹시 지금 Kubernetes CNI 교체를 고민 중이시라면, 여기서 중요한 포인트를 먼저 잡고 가시면 삽질을 꽤 줄일 수 있어요.

홈랩 Kubernetes 클러스터에서 Cilium과 Calico의 데이터 경로를 비교하는 전체 개요 이미지입니다.

Kubernetes CNI에서 Cilium과 Calico를 왜 따로 봐야 할까요

쉽게 말해 CNI(Container Network Interface, 컨테이너 네트워크 인터페이스)는 Pod가 네트워크에 붙는 방식을 정하는 레이어입니다. 그런데 운영해보면 단순히 IP 붙이는 수준에서 끝나지 않아요. 서비스 라우팅, 네트워크 정책, 트래픽 가시성, 디버깅 도구, 커널 의존성까지 같이 따라옵니다.

Calico는 오래전부터 많이 써온 선택지라 운영 경험치가 쌓여 있고, 라우팅과 정책 측면에서 익숙한 분들이 많습니다. 반면 Cilium은 eBPF(이비피에프, 커널 내부에서 안전하게 패킷 처리 로직을 실행하는 기술)를 적극 활용해서 데이터 경로를 다르게 가져가는 게 핵심이죠. 처음엔 이게 뭔가 싶었는데, 관찰성(Observability, 트래픽을 들여다보는 능력) 쪽은 확실히 인상적이었어요.

여기서 오해하면 안 되는 게 하나 있습니다. "무조건 Cilium이 빠르다" 혹은 "Calico는 오래돼서 느리다" 같은 식으로 단정하면 안 됩니다. 실제 Kubernetes CNI 성능 비교는 트래픽 패턴에 따라 결과가 달라집니다. Pod 간 단순 대역폭, NodePort 경유, Service 체인, NetworkPolicy 적용 여부, 암호화 사용 여부 같은 조건이 바뀌면 체감이 꽤 달라지거든요.

Cilium vs Calico 핵심 차이 정리

항목	Cilium	Calico
핵심 데이터 경로	eBPF 기반	iptables 기반 또는 eBPF dataplane 선택 가능
강점	관찰성, 정책 처리, 서비스 트래픽 가시화	성숙한 운영 사례, 익숙한 구성, 다양한 환경 적응력
운영 난이도	커널과 기능 이해가 필요함	상대적으로 익숙한 운영 패턴
디버깅 관점	Hubble 등 생태계가 강점	전통적인 네트워크 관점에서 접근이 쉬움
비교 포인트	정책 많을 때, 관찰성 중요할 때	안정적 표준 운영, 기존 경험 활용 시

제가 직접 해보니, Kubernetes CNI 성능 비교에서 제일 많이 놓치는 부분이 순수 처리량(throughput)만 보고 결론 내리는 것이었습니다. 실제 운영에서는 지연(latency), 정책 적용 후 변화, 장애 났을 때 추적 가능성까지 같이 봐야 하더라고요. 특히 멀티테넌트 비슷하게 네임스페이스를 나눠 쓰는 환경이면 더 그렇습니다.

비교 전에 먼저 정해야 할 질문

• 단순 Pod to Pod 성능이 궁금한지
• NetworkPolicy 적용 후 성능 변화가 궁금한지
• Service 트래픽까지 포함한 실제 운영 경로가 궁금한지
• 관찰성과 디버깅 속도를 포함해 평가할지

이 질문부터 정리하고 들어가면 benchmark 해석이 훨씬 깔끔해집니다.

실전 비교 환경 구성: 같은 조건으로 맞추는 게 먼저입니다

여기서 제일 중요한 건 두 CNI를 최대한 같은 조건에서 비교하는 겁니다. CPU, 메모리, 커널, Kubernetes 버전, MTU, 노드 수, Pod 수가 다르면 결과가 섞여버립니다. 저도 초반에는 클러스터를 급하게 갈아엎다가 조건이 달라져서 다시 측정했었어요. 삽질 꽤 했습니다 ㅎㅎ

1. 동일한 노드 사양으로 테스트 클러스터를 준비합니다.
2. 한 번에 하나의 CNI만 설치합니다.
3. 테스트 워크로드는 똑같이 유지합니다.
4. 측정 항목을 미리 고정합니다. 예: 대역폭, 지연, 정책 적용 전후, Service 경유 성능.

아래는 Helm(헬름, 쿠버네티스 패키지 매니저) 기준으로 Cilium vs Calico 비교 환경을 잡을 때 자주 쓰는 흐름입니다.

helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=false

⚠️ 주의: 위 설정의 kubeProxyReplacement=false는 kube-proxy를 계속 사용한다는 뜻입니다. Cilium의 eBPF 이점을 제대로 보려면 --set kubeProxyReplacement=strict 또는 =probe로 설정하는 게 낫습니다. 비교 목적이라면 두 CNI 모두 같은 서비스 경로 구성을 유지해야 한다는 점을 잊지 마세요.

helm repo add projectcalico https://docs.tigera.io/calico/charts
helm repo update

helm install calico projectcalico/tigera-operator \
  --namespace tigera-operator \
  --create-namespace

환경에 따라 설치 방식은 달라질 수 있습니다. 중요한 건 설치 명령보다도 비교 조건을 고정하는 습관입니다.

동일한 노드 조건에서 Cilium과 Calico를 각각 분리해 테스트하는 구성 다이어그램입니다.

Benchmark 워크로드 만들기: iperf3와 정책 테스트를 같이 봐야 합니다

Kubernetes CNI 성능 비교를 할 때 저는 보통 iperf3(아이퍼프3, 네트워크 처리량 측정 도구)부터 올립니다. 이유는 단순해요. 가장 빠르게 Pod 간 대역폭과 TCP/UDP 흐름을 볼 수 있거든요. 다만 이것만 보면 반쪽짜리입니다. 실제 운영은 Service, DNS, NetworkPolicy가 얹히니까요.

기본 테스트 Pod 배포

apiVersion: v1
kind: Pod
metadata:
  name: iperf3-server
  labels:
    app: iperf3-server
spec:
  containers:
    - name: iperf3
      image: networkstatic/iperf3
      args: ["-s"]
---
apiVersion: v1
kind: Pod
metadata:
  name: iperf3-client
spec:
  containers:
    - name: iperf3
      image: networkstatic/iperf3
      command: ["sleep", "3600"]

kubectl apply -f iperf3.yaml
kubectl get pods -o wide
kubectl exec -it iperf3-client -- iperf3 -c <SERVER_POD_IP> -t 30

여기서 중요한 포인트! 같은 노드에 붙은 경우와 다른 노드에 붙은 경우를 분리해서 봐야 합니다. 같은 노드면 오버레이(overlay) 영향을 덜 받고, 다른 노드면 실제 네트워크 경로가 더 잘 드러나거든요.

Service 경유 테스트도 꼭 해보세요

apiVersion: v1
kind: Service
metadata:
  name: iperf3-service
spec:
  selector:
    app: iperf3-server
  ports:
    - protocol: TCP
      port: 5201
      targetPort: 5201

kubectl apply -f iperf3-service.yaml
kubectl exec -it iperf3-client -- iperf3 -c iperf3-service.default.svc.cluster.local -t 30

이렇게 보면 직접 Pod IP로 붙었을 때와 Service를 경유했을 때 차이를 비교할 수 있어요. 실제로 써보니까 이 구간에서 체감 차이를 보는 경우가 꽤 있더라고요.

NetworkPolicy 적용 후도 따로 측정

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-iperf3
spec:
  podSelector:
    matchLabels:
      app: iperf3-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}
      ports:
        - protocol: TCP
          port: 5201

정책 없을 때 한 번, 정책 적용 후 한 번. 최소 이 두 번은 돌려보셔야 합니다. 정책이 많아질수록 Cilium vs Calico의 dataplane 특성이 드러나는 경우가 있거든요.

제가 실제로 체크한 관찰 포인트

단순히 결과 숫자만 기록하면 나중에 해석이 안 됩니다. 그래서 저는 아래 항목을 같이 봤어요.

• Pod to Pod 처리량: 같은 노드 / 다른 노드 분리
• Service 경유 지연: kube-proxy 경로 포함 여부 확인
• NetworkPolicy 적용 전후 차이: 정책 수가 늘어날 때 체감 확인
• CPU 사용 경향: 네트워크 부하 중 어느 쪽이 더 민감한지
• 디버깅 편의성: 장애 시 원인 추적 시간

특히 마지막 항목은 문서만 보면 잘 안 보입니다. 성능 수치가 약간 좋아도, 운영 중 원인 파악이 너무 오래 걸리면 결국 전체 효율은 떨어지더라고요. 저는 예전에 정책 충돌 때문에 Pod 통신이 막힌 적이 있었는데, 그때부터는 관찰성도 성능의 일부라고 생각하게 됐습니다.

iperf3 실행과 정책 테스트를 병행하면서 측정하는 과정을 보여주는 시각 자료입니다.

⚠️ 주의사항과 트러블슈팅: 여기서 많이 막힙니다

이 섹션은 진짜 중요합니다. Kubernetes CNI benchmark가 이상하게 나오면 대개 CNI 자체보다 테스트 환경 변수가 문제인 경우가 많거든요.

1. MTU 불일치

오버레이 네트워크나 터널링이 들어가면 MTU(Maximum Transmission Unit, 최대 전송 단위)가 어긋나면서 성능이 이상하게 흔들릴 수 있습니다. 겉보기엔 통신이 되는데, 처리량이 들쑥날쑥하거나 재전송이 늘어나는 식이죠.

kubectl exec -it iperf3-client -- ip link
kubectl exec -it iperf3-server -- ip addr

MTU 값이 환경 전체에서 일관적인지 먼저 확인해보세요.

2. 같은 노드에만 스케줄링되는 문제

처음엔 결과가 너무 좋게 나와서 '와, 이거 엄청 빠른데?' 했었는데, 알고 보니 서버와 클라이언트 Pod가 같은 노드에 올라가 있었던 적이 있어요. 이러면 진짜 비교가 안 됩니다.

kubectl get pods -o wide

노드 분산이 필요하면 nodeSelector나 podAntiAffinity도 같이 고려해보세요.

3. 정책 테스트인데 DNS를 빼먹는 문제

Service 이름으로 붙는 테스트를 할 때 DNS 허용 정책을 빼먹으면 결과가 꼬여요. 통신 자체가 안 되는 걸 성능 문제로 오해하기 쉽거든요.

4. 관찰 도구가 없는 상태에서 디버깅 시작

Calico든 Cilium이든 로그와 패킷 경로를 볼 수단을 먼저 확보해두는 게 좋습니다. 특히 Cilium은 Hubble(Hubble, 네트워크 관찰 도구) 같은 생태계를 같이 보는 분들이 많고, Calico도 운영 환경에 맞춰 상태 확인 경로를 준비해두는 편이 낫습니다.

💡 팁: benchmark 전에 무부하 상태 baseline을 한 번 기록해두세요. 나중에 결과가 흔들려도 비교 기준점이 생깁니다.

검증과 결과 해석: 숫자보다 패턴을 보셔야 합니다

이제 제일 궁금한 부분이죠. 그래서 뭐가 더 빨랐냐고요? 제가 홈랩과 소규모 테스트 클러스터에서 여러 번 Cilium vs Calico를 비교해본 느낌은 이랬습니다.

• 단순 Pod to Pod 처리량만 보면 둘 다 충분히 빠른 편이라, 환경에 따라 큰 차이가 안 보일 때도 많았어요.
• Service 경유, 정책 적용, 관찰성 포함으로 범위를 넓히면 체감 차이가 생겼습니다.
• Cilium은 eBPF 기반 흐름과 관찰성 덕분에 문제를 추적하는 시간이 줄어드는 느낌이 있었어요.
• Calico는 운영 경험이 이미 쌓인 팀이라면 구성과 장애 대응이 익숙해서 안정감이 있더라고요.

즉, Kubernetes CNI benchmark 결과는 단순히 '누가 더 빠르다'로 끝내면 아쉬워요. 운영 모델까지 포함한 성능 비교가 맞습니다. 특히 네트워크 정책을 많이 쓰고 서비스 메시에 가까운 복잡한 흐름이 있다면 Cilium이 주는 장점이 더 잘 보일 수 있습니다. 반대로 단순하고 예측 가능한 구조, 기존 팀 역량 활용이 중요하다면 Calico도 여전히 아주 현실적인 선택입니다.

테스트 항목	해석 포인트	제가 본 체감
Pod to Pod	순수 데이터 경로 성능	환경 따라 큰 차이 없을 수 있음
Service 경유	서비스 라우팅 오버헤드	구성 차이가 드러날 수 있음
Policy 적용 후	정책 엔진 영향	워크로드 구조에 따라 차이 발생
운영 디버깅	문제 추적 시간	Cilium 관찰성이 인상적이었음

Cilium vs Calico benchmark 결과를 숫자보다 해석 포인트 중심으로 요약한 인포그래픽입니다.

어떤 환경에 Cilium, 어떤 환경에 Calico가 맞을까요

정리하면 이렇습니다.

• Cilium 추천: eBPF 기반 기능, 네트워크 가시성, 정책 중심 운영, 트래픽 분석이 중요할 때
• Calico 추천: 익숙한 운영 모델, 폭넓은 도입 사례, 단계적 운영 안정성이 중요할 때

여기서 중요한 포인트! 팀의 운영 역량도 반드시 포함해서 판단해야 합니다. 도구가 아무리 좋아도, 팀이 이해하지 못하면 장애 대응 시간은 길어집니다. 저도 처음에는 기능표만 보고 혹했었는데, 결국 오래 남는 건 운영 난이도와 추적 가능성이더라고요.

정리와 다음 단계

이번 글에서는 Cilium vs Calico를 Kubernetes CNI와 네트워킹 성능 비교 관점에서 풀어봤습니다. 핵심은 간단해요. Benchmark는 같은 조건에서 측정하고, 결과는 처리량만이 아니라 정책/서비스/디버깅까지 함께 해석해야 한다는 점입니다. 제가 직접 해보니 결국 '더 빠른 CNI'보다 '내 환경에서 더 잘 설명되는 CNI'를 고르는 쪽이 맞았습니다.

✅ 지금 바로 해보실 일은 세 가지입니다.

1. 동일 조건의 테스트 클러스터를 준비합니다.
2. Pod to Pod, Service, NetworkPolicy 세 가지 축으로 나눠 측정합니다.
3. 결과 표에 숫자뿐 아니라 장애 추적 난이도까지 같이 적습니다.

다음 글에서는 Hubble을 활용한 Cilium 트래픽 관찰이나, 반대로 Calico NetworkPolicy 운영 팁을 더 깊게 다뤄볼 예정입니다. Kubernetes 네트워크 기본기 관련 이전 글들도 함께 읽으시면 Cilium vs Calico 비교의 흐름이 더 잘 잡히실 거예요.

자주 묻는 질문

Cilium이 항상 Calico보다 빠른가요?

아니에요. 트래픽 패턴, 정책 수, 서비스 경로, 커널 환경에 따라 달라집니다. 단순 benchmark 하나로 일반화하면 위험합니다.

Calico도 eBPF를 쓰나요?

Calico는 전통적인 방식으로 많이 알려져 있지만, eBPF dataplane 관련 선택지도 존재합니다. 다만 실제 비교에서는 어떤 dataplane을 쓰는지를 명확히 맞춰야 합니다.

Kubernetes CNI 비교에서 제일 중요한 항목은 뭔가요?

제 기준으로는 정책 적용 후의 변화와 운영 중 추적 가능성입니다. 실서비스는 그 구간에서 차이가 크게 느껴지거든요.

🎉 결론적으로, Cilium이든 Calico든 무작정 유행 따라 고르기보다 내 클러스터의 네트워크 구조와 운영 방식에 맞춰 Cilium vs Calico를 직접 benchmark 해보는 게 가장 확실합니다.

📚 함께 읽으면 좋은 글

• Knative 성능 벤치마크, 실제 트래픽 증가에 따른 서빙 체크 포인트
• ArgoCD 도입 실패 사례 분석: GitOps 전환 시 흔한 실수와 방지 전략
• 쿠버네티스 RBAC 보안 강화 체크리스트: 최소 권한 원칙 적용 가이드