[Kubernetes] Cilium CNI 성능 벤치마크: Calico, Flannel과 직접 비교

목차

• [Kubernetes] Cilium CNI 성능 벤치마크: Calico, Flannel과 직접 비교
• CNI란 뭐고 어떤 종류가 있을까?
• 실전 구현: 벤치마크 환경 준비와 테스트 방법
• ⚠️ 삽질 경험과 Cilium 트러블슈팅
• 검증 결과: Cilium CNI의 성능은 정말 압도적일까?
• 결론: Cilium은 미래의 CNI 표준이 될까?

[Kubernetes] Cilium CNI 성능 벤치마크: Calico, Flannel과 직접 비교

안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 Kubernetes(쿠버네티스) 환경에서 가장 중요한 요소 중 하나인 CNI(Container Network Interface, 컨테이너 네트워크 인터페이스) 솔루션들의 성능을 제가 직접 벤치마크해본 경험을 공유하려고 해요. 특히 요즘 핫한 Cilium(실리움)이 기존의 Calico(칼리코), Flannel(플라넬)과 비교해서 얼마나 뛰어난지 궁금했거든요.

인프라 엔지니어로 일하다 보면 '네트워크 성능이 왜 이렇게 느리지?' 하는 답답함을 겪을 때가 많습니다. 특히 마이크로서비스 아키텍처에서는 Pod(파드) 간의 통신이 엄청나게 빈번하게 일어나기 때문에, CNI의 선택이 전체 애플리케이션 성능에 결정적인 영향을 미치죠. 저도 홈랩에서 이것저것 실험해보면서 이 문제로 삽질을 좀 했거든요. 그래서 이번 기회에 주요 CNI 솔루션들을 직접 비교해보면서 그 차이를 피부로 느껴보고 싶었습니다.

CNI란 뭐고 어떤 종류가 있을까?

먼저 CNI가 뭔지 간단하게 짚고 넘어갈게요. CNI는 컨테이너 런타임과 네트워크 플러그인 간의 표준 인터페이스를 정의한 규약입니다. 쉽게 말해, Kubernetes Pod들이 어떻게 서로 통신하고 외부와 연결될지 결정하는 '네트워크 길잡이' 역할을 하는 거죠.

• Flannel (플라넬): 가장 단순하고 설치가 쉬운 CNI 중 하나입니다. 주로 Overlay Network(오버레이 네트워크) 방식인 VXLAN(Virtual Extensible LAN)을 사용해요. 설정이 간단해서 초보자들이나 소규모 클러스터에서 많이 선택하지만, 성능 오버헤드가 좀 있는 편입니다.
• Calico (칼리코): 네트워크 정책(Network Policy) 기능이 강력하고 성능도 준수해서 많은 프로덕션 환경에서 사용됩니다. IP-in-IP 터널링이나 BGP(Border Gateway Protocol) 라우팅 방식을 주로 쓰는데, 특히 BGP 모드에서는 오버헤드가 적어서 좋은 성능을 보여주죠. 보안 기능도 뛰어나고요.
• Cilium (실리움): 오늘 주인공이죠! eBPF(extended Berkeley Packet Filter, 확장된 버클리 패킷 필터)라는 기술을 기반으로 합니다. eBPF는 리눅스 커널 내부에서 프로그램을 실행할 수 있게 해주는 기술인데, 이걸 활용해서 Cilium은 컨테이너 네트워크 트래픽을 커널 레벨에서 직접 처리합니다. 이 덕분에 기존 CNI들이 가졌던 성능 오버헤드를 크게 줄이고, 더 세밀한 네트워크 정책과 가시성(Observability)을 제공할 수 있게 되는 거예요. 처음엔 이게 뭔가 싶었는데, 써보니 진짜 매력적이더라고요.

이 이미지는 Flannel, Calico, Cilium 각 CNI 솔루션의 네트워크 아키텍처를 시각적으로 비교하여, 데이터 플레인 처리 방식의 차이를 보여줍니다.

실전 구현: 벤치마크 환경 준비와 테스트 방법

자, 그럼 이제 제가 어떻게 벤치마크를 진행했는지 공유해볼게요. 홈랩에 Kubernetes 클러스터를 kubeadm으로 구성했고, 각 CNI를 순서대로 설치해가며 성능을 측정했습니다.

1. Cilium CNI 벤치마크를 위한 환경 준비

저는 3노드(마스터 1, 워커 2) Kubernetes 클러스터를 사용했습니다. 테스트의 공정성을 위해 각 CNI를 설치하기 전에는 항상 클러스터를 초기화하고 깨끗한 상태에서 시작했어요. 벤치마크 도구로는 네트워크 성능 측정에 널리 사용되는 netperf를 선택했습니다. TCP_STREAM(대역폭), TCP_RR(요청/응답 지연 시간) 두 가지 모드로 측정했어요.

# netperf 설치 (Ubuntu 기준)
sudo apt update
sudo apt install netperf -y

# 벤치마크용 Pod 배포 예시
kubectl apply -f - <

각 CNI를 설치한 후, netperf-server Pod를 배포하고 다른 Pod에서 netperf 클라이언트를 실행하여 서버 Pod로 트래픽을 보냈습니다. Pod-to-Pod 통신과 Pod-to-Service 통신 두 가지 시나리오를 모두 측정했어요.

2. Cilium 포함 각 CNI 설치 및 성능 측정

1. Flannel 설치 및 측정:

   
   kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
   # Pod Ready 확인 후 netperf 측정
   

2. Calico 설치 및 측정:

   
   kubectl apply -f https://docs.tigera.io/calico/latest/manifests/calico.yaml
   # Pod Ready 확인 후 netperf 측정
   

3. Cilium 설치 및 성능 측정:

   
   helm repo add cilium https://helm.cilium.io/
   helm install cilium cilium/cilium --version 1.15.5 \
     --namespace kube-system \
     --set ipam.mode=kubernetes \
     --set tunnel=vxlan \
     --set egressGateway.enabled=true # 예시 설정
   # Pod Ready 확인 후 netperf 측정
   

⚠️ 주의사항: 각 CNI를 설치하기 전에 기존 CNI를 완전히 삭제하고 클러스터를 초기화하거나, CNI 관련 리소스를 제거해야 합니다. 그렇지 않으면 네트워크 충돌로 Pod들이 정상적으로 시작되지 않을 수 있거든요. 제가 처음엔 이걸 놓쳐서 Pod들이 Pending(대기) 상태에서 벗어나지 못하는 삽질을 좀 했습니다 ㅎㅎ.

이 이미지는 Kubernetes 클러스터에 Cilium CNI를 helm을 이용하여 설치하는 과정을 보여주는 터미널 스크린샷입니다.

⚠️ 삽질 경험과 Cilium 트러블슈팅

솔직히 말씀드리면, Cilium을 처음 설치할 때 좀 애먹었습니다. kubeadm으로 구성한 클러스터에서 Cilium Pod들이 CrashLoopBackOff(크래시 루프백 오프) 상태에 빠지더라고요. 확인해보니 커널 버전 문제와 eBPF 관련 의존성 설정이 제대로 안 된 경우였습니다. Cilium은 eBPF 기반이라 리눅스 커널 버전이 어느 정도 이상이어야 하고, 특정 커널 모듈이나 설정이 활성화되어 있어야 하거든요. 예를 들어, CONFIG_BPF_JIT 같은 커널 옵션이 활성화되어 있는지 확인해야 합니다.

이런 문제 때문에 Cilium 설치 전에 공식 문서를 꼼꼼히 읽어보고, cilium preflight check 같은 명령어로 환경을 미리 점검하는 게 정말 중요합니다. 덕분에 커널 컴파일 옵션까지 찾아보는 등 깊은 공부를 하게 됐네요. 역시 삽질은 최고의 공부 방법입니다!

검증 결과: Cilium CNI의 성능은 정말 압도적일까?

수많은 테스트와 삽질 끝에 얻은 결과는 예상대로였습니다. Cilium이 Calico, Flannel 대비 전반적으로 더 우수한 네트워크 성능을 보여줬거든요.

• Throughput (대역폭): 특히 대량의 데이터를 전송하는 TCP_STREAM 테스트에서 Cilium은 Calico나 Flannel보다 더 높은 처리량을 기록했습니다. eBPF 덕분에 커널 레벨에서 패킷을 직접 처리하면서 컨텍스트 스위칭(Context Switching) 오버헤드가 크게 줄어든 거 같아요.
• Latency (지연 시간): 요청-응답(TCP_RR) 테스트에서도 Cilium이 가장 낮은 지연 시간을 보여줬습니다. 이는 마이크로서비스 간의 빈번한 API 호출에 있어 정말 중요한 이점이거든요. 애플리케이션의 반응성이 훨씬 좋아지는 거죠.

물론, 테스트 환경이나 네트워크 구성에 따라 결과는 달라질 수 있습니다. 하지만 제 홈랩 환경에서는 Cilium의 성능 향상이 눈에 띄게 확인되었어요. 특히 Pod 간의 통신이 잦은 환경이라면 Cilium CNI의 도입을 진지하게 고려해볼 만하다고 생각합니다.

이 이미지는 Cilium, Calico, Flannel 각 CNI 솔루션의 네트워크 Throughput(대역폭)과 Latency(지연 시간) 벤치마크 결과를 보여주는 비교 그래프입니다.

결론: Cilium은 미래의 CNI 표준이 될까?

이번 벤치마크를 통해 Cilium의 강력한 성능을 직접 확인할 수 있었습니다. eBPF라는 혁신적인 기술을 기반으로 기존 CNI의 한계를 뛰어넘는 모습을 보여줬네요. 특히 고성능이 요구되는 환경이나 복잡한 네트워크 정책, 그리고 뛰어난 가시성이 필요한 곳이라면 Cilium은 정말 훌륭한 선택지가 될 겁니다.

하지만 Cilium이 만능은 아닙니다. eBPF에 대한 이해가 필요하고, 상대적으로 커널 의존성이 높아서 환경 구성에 더 신경 써야 할 부분이 있어요. 설치와 설정도 Calico나 Flannel보다는 복잡할 수 있다는 점도 고려해야 합니다.

결론적으로, 간단하고 빠른 배포가 우선이라면 Flannel, 안정적인 성능과 강력한 네트워크 정책이 필요하다면 Calico, 그리고 최고의 성능과 보안, 고급 가시성을 원한다면 Cilium을 고려해보시길 추천합니다. 저도 이제 프로덕션 환경에서 Cilium을 더 적극적으로 도입해볼까 고민 중입니다.

다음번엔 Cilium의 네트워크 정책(Network Policy) 기능과 서비스 메시(Service Mesh) 연동에 대해 더 자세히 다뤄볼 예정이니 기대해주세요! 긴 글 읽어주셔서 감사합니다.

이 이미지는 Flannel, Calico, Cilium 각 CNI 솔루션의 주요 특징, 장점, 단점 및 추천 사용 시나리오를 요약 비교한 인포그래픽입니다.

📚 함께 읽으면 좋은 글

• 쿠버네티스 Secret 관리 베스트 프랙티스: 민감 데이터 보안 강화 전략
• K3s와 AWX 통합 사례 연구: 경량 Kubernetes 자동화 워크플로우 구축
• Kubernetes Operator 활용 사례: 데이터베이스 관리 자동화로 운영 효율 높이기