쿠버네티스 네트워킹 기초와 CNI 선택 기준 정리

클러스터를 처음 만들고 나면 다음으로 막히는 지점이 네트워킹입니다. 파드끼리는 어떻게 통신하는지, CNI가 정확히 뭘 하는 건지 몰라서 일단 아무 플러그인이나 설치하고 넘어가는 경우가 많습니다. 이번 글에서는 쿠버네티스 네트워킹의 기본 개념과, 실제로 CNI를 고를 때 어떤 기준으로 판단해야 하는지 정리합니다.

핵심만 먼저 말하면, CNI는 파드 간 통신과 네트워크 정책을 담당하는 플러그인이고 2026년 기준으로는 Cilium이 신규 클러스터에서 가장 많이 채택되는 선택지입니다. 다만 BGP 인프라나 윈도우 워크로드가 있다면 Calico가 여전히 유효한 선택입니다.

쿠버네티스 네트워킹 기본 개념

쿠버네티스는 모든 파드가 고유한 IP를 가지고, NAT 없이 서로 직접 통신할 수 있어야 한다는 원칙을 전제로 합니다. 이 원칙 자체는 단순하지만, 실제로 이걸 구현하는 방식은 CNI 플러그인마다 완전히 다릅니다. 오버레이 네트워크를 쓰는 방식도 있고, BGP로 라우팅을 직접 처리하는 방식도 있고, 최근에는 커널 레벨에서 패킷을 처리하는 eBPF 기반 방식도 자리잡았습니다.

실무에서 보면 이 개념을 모른 채 CNI만 먼저 설치하고 나서, 나중에 성능 문제나 정책 문제로 다시 갈아엎는 경우가 꽤 있습니다. CNI 선택은 한번 내려지면 바꾸기 어려운 결정이라, 처음부터 원리를 이해하고 고르는 게 시행착오를 줄이는 길입니다.

파드 간 통신 흐름과 CNI 플러그인의 역할
파드 간 통신 흐름과 CNI 플러그인의 역할

CNI가 하는 일

CNI(Container Network Interface)는 표준 인터페이스이고, 이 표준 덕분에 다양한 네트워킹 솔루션 중에서 선택할 수 있습니다. 하지만 선택지가 많다는 건 그만큼 고민도 커진다는 뜻입니다. 어떤 CNI를 선택하느냐는 클러스터의 성능, 확장성, 보안 수준을 결정하는 근본적인 아키텍처 결정 중 하나입니다.

이건 직접 겪어보면 체감되는데, 단순히 파드 통신만 되면 끝이 아닙니다. 네트워크 정책(NetworkPolicy)으로 트래픽을 통제하고, 문제가 생겼을 때 관측 가능한 도구가 있는지도 CNI 선택에 큰 영향을 줍니다.

실무 팁 — CNI를 고를 때 처리량 벤치마크만 보고 결정하지 마세요. 팀이 BGP 피어링이나 eBPF 디버깅에 익숙한지, 아니면 전통적인 iptables 방식이 더 편한지도 함께 고려해야 실제 운영에서 덜 헤맵니다.

터미널에서 kubectl 명령어로 NetworkPolicy 리소스를 적용하고 파드 간 트래픽을 제한하는 화면
터미널에서 kubectl 명령어로 NetworkPolicy 리소스를 적용하고 파드 간 트래픽을 제한하는 화면

주요 CNI 옵션 이해하기

Cilium은 처음부터 eBPF를 기반으로 설계된 CNI입니다. Cilium은 커널에서 eBPF를 사용하고, Calico는 iptables(eBPF 옵션 포함)를 사용한다는 게 근본적인 차이입니다. 벤치마크에서는 Cilium의 P99 레이턴시가 0.8ms로, Calico의 1.4ms보다 낮게 측정되는 경우가 많습니다.

Calico는 오랫동안 검증된 CNI로, 쿠버네티스 기본 NetworkPolicy를 넘어 글로벌 정책, 정책 순서 지정, deny 규칙 같은 풍부한 보안 기능을 제공합니다. 다만 프로덕션에서 Calico를 제대로 쓰려면 BGP 피어링에 대한 이해가 필요하고, 네트워크가 BGP를 지원하지 않으면 IP-in-IP 캡슐화 모드를 써야 합니다. 학습 곡선이 있는 편입니다.

초보자와 실무자의 판단 기준은 여기서 갈립니다. 초보자는 “설치가 쉬운가”를 먼저 보지만, 실무자는 향후 정책 관리와 관측성까지 고려해서 CNI를 정합니다. 2026년 기준 구글 클라우드(GKE Dataplane V2)와 마이크로소프트 애저(Azure CNI Powered by Cilium) 모두 Cilium을 권장 옵션으로 제공하고 있어, 관리형 쿠버네티스를 쓰고 있다면 이미 Cilium 기반일 가능성도 있습니다.

Hubble 관측 도구로 Cilium 기반 클러스터의 실시간 트래픽 흐름을 시각화해서 확인하는 화면
Hubble 관측 도구로 Cilium 기반 클러스터의 실시간 트래픽 흐름을 시각화해서 확인하는 화면

CNI 비교표

구분CiliumCalicoFlannel
기반 기술eBPF 네이티브iptables (eBPF 옵션)단순 오버레이
네트워크 정책L7 정책, HTTP/gRPC 지원글로벌 정책, 정교한 규칙기본 정책 미지원 수준
학습 난이도eBPF 이해 필요BGP 피어링 이해 필요낮음, 설정 단순
적합한 상황고성능, 마이크로서비스 밀집 환경BGP 인프라, 윈도우 워크로드단순 오버레이만 필요한 소규모 환경

흔히 하는 오해

❌ “CNI는 다 비슷하니 아무거나 설치해도 상관없다” → ⭕ 실제로는 성능, 정책 기능, 운영 방식이 CNI마다 크게 다르고, Calico eBPF 모드와 Cilium은 아키텍처 철학과 운영 특성 자체가 다르기 때문에 클러스터 요구사항에 맞춰 신중하게 골라야 합니다.

❌ “성능이 가장 빠른 CNI를 고르면 무조건 정답이다” → ⭕ Cilium이 처리량에서 약 25% 높은 성능을 보이는 경우가 많지만, 팀의 운영 역량이나 기존 인프라와의 호환성을 무시하면 오히려 운영 부담이 커질 수 있습니다. 성능은 여러 판단 기준 중 하나일 뿐입니다.

Cilium과 Calico의 처리량 및 레이턴시 벤치마크 그래프를 나란히 비교하는 화면
Cilium과 Calico의 처리량 및 레이턴시 벤치마크 그래프를 나란히 비교하는 화면

CNI 선택 전 체크리스트

  • 팀이 eBPF와 BGP 중 어느 쪽에 더 익숙한지 확인
  • L7 네트워크 정책(HTTP, gRPC 등)이 필요한지 확인
  • 기존 인프라에 BGP 라우팅이나 윈도우 워크로드가 있는지 확인
  • 관리형 쿠버네티스라면 기본 CNI가 무엇인지 먼저 확인
  • 관측 도구(Hubble 등)가 필요한 수준인지 판단

지금 클러스터에 어떤 CNI가 설치되어 있는지 kubectl get pods -n kube-system으로 먼저 확인해보시길 권합니다. 관리형 쿠버네티스라면 이미 Cilium이나 Calico가 기본으로 깔려 있는 경우가 많습니다.

CNI를 선택하거나 마이그레이션하면서 겪었던 어려움이 있으신가요? 어떤 기준으로 최종 결정하셨는지 댓글로 공유해주시면 다른 분들께도 도움이 됩니다.

함께 보면 좋은 글: 쿠버네티스 클러스터 처음 구축할 때 알아야 할 개념 정리, 쿠버네티스 클러스터 업그레이드 시 고려해야 할 사항 정리

본 포스팅은 정보 전달 목적이며, 실제 적용 시 발생하는 책임은 사용자에게 있습니다.

댓글 남기기