목차 (Agenda)

Kubernetes

쿠버네티스 네트워킹과 CNI — Calico·Cilium·Flannel 비교

쿠버네티스(Kubernetes)를 설치하고 나면 곧바로 네트워크라는 두 번째 관문이 나타납니다. 파드는 왜 저마다 IP를 갖는지, CNI 플러그인은 왜 꼭 설치해야 하는지, Calico와 Cilium과 Flannel 중 무엇을 골라야 하는지 — 이 질문들에 답하지 못하면 클러스터는 돌아가도 장애가 났을 때 손을 댈 수 없습니다. 이 글은 쿠버네티스 네트워킹 모델의 원칙부터 CNI(Conta…

2026년 08월 15일

Kubernetes 도입·운영, 전문가와 상담하세요

프로덕션 Kubernetes 도입부터 안정화까지 — Cloud Native Forum 전문가가 무료 상담으로 함께합니다.

Kubernetes 도입 문의하기 →

쿠버네티스 네트워킹 모델은 어떤 원칙 위에 서 있나?

쿠버네티스 네트워킹은 ‘모든 파드가 고유 IP를 갖고, NAT 없이 서로 직접 통신한다’는 평평한 네트워크 원칙 위에 서 있습니다.

쿠버네티스는 네트워크 구현 방식을 강제하지 않는 대신, 어떤 구현이든 지켜야 할 요구 사항을 못 박아 두었습니다(kubernetes.io — 클러스터 네트워킹). 실무 관점으로 풀면 네 가지 원칙입니다.

파드마다 고유한 IP가 있다 — 파드(Pod, 쿠버네티스의 최소 배포 단위)는 컨테이너 묶음이지만 네트워크 관점에서는 IP 하나를 가진 작은 호스트처럼 행동합니다. 파드 안의 컨테이너들이 이 IP와 포트 공간을 어떻게 나눠 쓰는지는 쿠버네티스 Pod 완벽 가이드에서 생명주기와 함께 다룹니다.
모든 파드는 NAT 없이 서로 통신할 수 있다 — 다른 노드에 있는 파드끼리도 주소 변환 없이 상대 IP로 직접 도달합니다.
노드의 에이전트는 그 노드의 파드와 통신할 수 있다 — kubelet 같은 노드 구성 요소가 파드 상태를 점검할 수 있어야 하기 때문입니다.
파드가 보는 자기 IP와 남이 보는 그 파드의 IP가 같다 — 컨테이너 안에서 확인한 주소가 바깥에서 부르는 주소와 일치합니다.

이 쿠버네티스 네트워킹 원칙 덕분에 애플리케이션은 가상 머신 시절의 코드 그대로, 포트 매핑 지옥 없이 클러스터에 올라올 수 있습니다.

쿠버네티스가 어렵게 느껴지는 이유도 여기에 있습니다. 컨테이너와 리눅스 개념만으로는 부족하고, 네트워크 기초 지식이 함께 요구되기 때문입니다.

그림 1. 쿠버네티스 학습에 요구되는 배경지식 — TCP/IP 기초가 한 축을 차지한다 (출처: Cloud Native Forum 쿠버네티스 소개 자료)

문제는 “이 평평한 쿠버네티스 네트워킹을 실제로 누가 어떻게 만들어 주느냐”입니다. 그 답이 CNI입니다.

CNI란 무엇인가?

CNI는 컨테이너에 네트워크 인터페이스를 붙이고 IP를 할당하는 방법을 정의한 표준 규격이자 플러그인 생태계입니다.

CNI(Container Network Interface)는 CNCF가 관리하는 오픈소스 표준으로, 컨테이너 런타임이 네트워크 플러그인을 호출하는 규격(스펙)과 기본 라이브러리를 정의합니다(containernetworking/cni).

쿠버네티스를 리눅스 커널에 빗대면 CNI의 자리가 분명해집니다. 커널이 네트워크 스택으로 하드웨어를 추상화하듯, 쿠버네티스는 CNI로 클러스터 네트워크, 곧 쿠버네티스 네트워킹을 추상화합니다.

그림 2. 리눅스 커널의 네트워크 스택 자리에 놓이는 것이 CNI다 (출처: Cloud Native Forum 쿠버네티스 소개 자료)

쿠버네티스에서 파드가 만들어질 때의 흐름은 이렇습니다. kubelet이 파드 생성을 지시하면, 컨테이너 런타임이 CNI 플러그인을 호출하고, 플러그인이 가상 네트워크 인터페이스를 만들어 파드에 꽂은 뒤 IP 대역(Pod CIDR)에서 주소를 할당하고 라우팅을 구성합니다. 파드가 삭제되면 같은 플러그인이 그 자원을 회수합니다.

요컨대 CNI 플러그인은 앞 절의 쿠버네티스 네트워킹 4원칙을 실제로 구현해 주는 부품입니다. 쿠버네티스 설치 직후 노드가 NotReady에 머무는 가장 흔한 이유가 CNI 미설치라는 점(쿠버네티스 설치 가이드 참고)도 여기서 나옵니다. 네트워크를 만들어 줄 부품이 없으니 파드를 받을 수 없는 상태인 것입니다. 규격이 표준화된 덕분에 같은 클러스터 코드 위에서 Flannel을 Calico로, Calico를 Cilium으로 교체하는 선택이 가능해졌습니다.

이 구조는 컨테이너 런타임 쪽에서 이미 한 번 검증된 방식이기도 합니다. 런타임을 갈아 끼울 수 있게 해 주는 CRI(Container Runtime Interface)와 네트워크를 갈아 끼울 수 있게 해 주는 CNI는 같은 설계 원리 위에 있습니다. 런타임 계층의 표준화가 실제로 무엇을 바꿨는지는 쿠버네티스 vs 도커에서 dockershim 제거 사례와 함께 정리했습니다.

Calico·Cilium·Flannel, 무엇이 어떻게 다른가?

Flannel은 단순한 오버레이 네트워크, Calico는 라우팅·네트워크 정책의 강자, Cilium은 eBPF 기반의 고성능·고관측성 플러그인입니다.

세 쿠버네티스 네트워킹 플러그인 모두 “파드 연결”이라는 기본기는 같지만, 구현 방식과 확장 기능에서 성격이 갈립니다. 이렇게 여러 구현체가 공존할 수 있는 이유는 CNI가 특정 벤더의 제품이 아니라 CNCF가 관리하는 중립 규격이기 때문입니다.

그림 3. CNI는 벤더 중립 표준이며 Calico·Flannel·Weave Net은 그 구현체다 (출처: Cloud Native Forum 쿠버네티스 소개 자료)

구분	Flannel	Calico	Cilium
핵심 방식	VXLAN 오버레이 중심	L3 라우팅(BGP) 중심	eBPF 데이터패스
네트워크 정책	미지원(별도 조합 필요)	지원(사실상 표준)	지원 + L7 정책
관측 도구	없음	제한적	Hubble 내장
학습 곡선	낮음	중간	중간~높음
어울리는 곳	학습·소규모 클러스터	정책 중심 운영 환경	대규모·고성능·보안 관측

Flannel 은 파드 트래픽을 캡슐화해 노드 사이로 실어 나르는 오버레이 네트워크(overlay network, 물리망 위에 논리망을 덧씌우는 방식)를 단순하게 제공합니다. 설정할 것이 적어 학습용으로 좋지만, 트래픽을 제어하는 네트워크 정책(NetworkPolicy) 기능이 없어 운영 환경에서는 다른 도구와 조합해야 합니다. 경량 배포판 k3s가 별도 설치 없이 바로 쓸 수 있는 것도 Flannel을 기본 동봉하기 때문인데, 이 기본 구성을 언제 교체해야 하는지는 k3s란? 경량 쿠버네티스의 구조와 배포판 선택 가이드에서 다룹니다.

Calico 는 각 노드를 라우터처럼 동작시키는 L3 라우팅 접근으로 캡슐화 오버헤드를 줄이고, 세밀한 네트워크 정책을 제공해 온프레미스와 클라우드를 가리지 않고 널리 채택돼 왔습니다. 네트워크 정책은 클러스터 보안의 기본기이기도 합니다. 파드 사이 통신을 기본 차단하고 필요한 경로만 여는 접근이 왜 표준 처방인지는 클라우드 네이티브 보안 — 4C 모델부터 DevSecOps까지에서 계층별로 정리했습니다.

Cilium 은 리눅스 커널의 eBPF 기술로 데이터패스를 처리하는 플러그인으로, 커널 안에서 패킷을 다뤄 성능을 높이고 L7(애플리케이션 계층) 수준의 정책과 관측 도구 Hubble까지 갖췄습니다(cilium.io). Cilium은 2023년 CNCF 졸업(Graduated) 프로젝트로 승격되며 성숙도를 공인받았습니다(CNCF — Cilium graduation 발표).

쿠버네티스 네트워킹 플러그인 선택 기준을 압축하면 이렇습니다. 실습·소규모라면 Flannel로 가볍게, 정책 관리가 중요한 일반 운영 환경이라면 Calico, 대규모 트래픽·성능·보안 관측이 관건이라면 Cilium이 유력한 후보입니다.

eBPF와 Cilium은 왜 부상했나 — 카카오 사례

iptables 기반 kube-proxy의 규모 한계를 커널 내 프로그래밍 기술 eBPF가 풀면서, Cilium이 대규모 클러스터의 표준 후보로 떠올랐습니다.

전통적으로 쿠버네티스의 서비스 트래픽 분배는 kube-proxy가 iptables 규칙으로 처리해 왔습니다. 문제는 규모입니다. 서비스와 파드가 수천, 수만 단위로 늘면 선형으로 탐색되는 규칙 목록이 병목이 됩니다. eBPF(extended Berkeley Packet Filter) 는 커널을 수정하지 않고도 커널 안에서 작은 프로그램을 실행하는 기술로, 해시맵 기반 조회로 이 병목을 구조적으로 우회합니다. Cilium은 이 eBPF로 kube-proxy 자체를 대체할 수 있습니다(cilium.io).

이 선택을 실제 규모로 증명한 국내 사례가 카카오입니다. 카카오는 온프레미스에서 7,000개 이상의 클러스터, 12만 대 이상의 노드를 운영하며 CNI로 Cilium을 채택했습니다(카카오 쿠버네티스 구축 사례). 도입 배경도 시사적입니다. 초기에는 kube-proxy와 Cilium, Nginx Ingress를 함께 쓰다 보니 장애가 나면 세 구성 요소를 동시에 분석해야 했고, eBPF 기반으로 데이터패스를 통일하자 성능과 함께 디버깅 단순성까지 얻었다는 것입니다. 대규모 쿠버네티스 네트워킹 운영에서는 “빠른가”만큼 “문제가 났을 때 들여다볼 수 있는가”가 CNI 선택 기준이 된다는 점을 보여 주는 사례입니다. 쿠버네티스 네트워킹의 CNI 도입이나 교체를 계획한다면 성능 수치와 함께 장애 분석 동선까지 점검해야 합니다. 같은 맥락의 대규모 운영 기록으로는 15명의 운영자로 4만 노드와 1,300개 클러스터를 다루는 LY 코퍼레이션 사례를 함께 읽어 볼 만합니다.

Service·Ingress·Gateway API는 어떤 관계인가?

쿠버네티스 네트워킹에서 CNI가 파드를 연결하는 바닥 배관이라면, Service는 클러스터 안의 고정 접속 창구, Ingress와 Gateway API는 바깥 세상과 만나는 정문입니다.

네트워킹을 공부하다 보면 계층이 섞여 혼란스러워지기 쉽습니다. 클러스터 구성 요소 지도 위에 올려 두면 각자의 자리가 보입니다.

그림 4. Data Plane에서 CNI 플러그인과 kube-proxy는 나란히 선 다른 부품이다 (출처: Cloud Native Forum 클라우드 네이티브 전환 자료)

역할별로 줄을 세우면 이렇게 정리됩니다.

CNI 플러그인 — 파드에 IP를 주고 파드끼리 통신하게 만드는 기반 계층입니다. 지금까지 다룬 내용입니다.
Service — 수시로 생겼다 사라지는 파드들 앞에 고정된 가상 IP와 DNS 이름을 세워 주는 클러스터 내부 로드밸런싱 장치입니다(kubernetes.io — Service).
Ingress — HTTP/HTTPS 트래픽을 호스트명·경로 기준으로 여러 Service에 나눠 주는 외부 노출 규칙입니다. 실제 동작은 Nginx 같은 Ingress 컨트롤러가 수행합니다(kubernetes.io — Ingress).
Gateway API — Ingress의 한계(제한된 표현력, 벤더별 어노테이션 난립)를 풀기 위해 설계된 차세대 표준으로, 2023년 10월 v1.0으로 정식(GA) 승격됐습니다(kubernetes.io 블로그 — Gateway API v1.0). 역할 분리(인프라 관리자와 애플리케이션 개발자)와 풍부한 라우팅 표현이 강점이며, 신규 설계라면 Ingress보다 Gateway API를 우선 검토할 만합니다.

트래픽이 흘러 들어오는 순서로 기억하면 쉽습니다. 외부 요청은 Gateway/Ingress라는 정문을 지나 Service라는 창구에 닿고, 마지막에 CNI가 깔아 둔 배관을 타고 파드에 도착합니다. 장애 분석도 이 순서를 거꾸로 따라가면 됩니다. “서비스가 안 열린다”는 증상 하나에도 원인은 Ingress 규칙, Service 셀렉터, CNI 계층 어디에나 있을 수 있으므로, 계층별 역할을 나눠 이해해 두면 장애 대응 시간이 크게 줄어듭니다.

정리하겠습니다. 쿠버네티스 네트워킹은 “모든 파드가 NAT 없이 통신한다”는 단순한 원칙에서 출발해, CNI 플러그인이라는 표준 부품으로 구현되고, Service·Ingress·Gateway API 계층으로 바깥 세상과 만납니다. 플러그인 선택은 규모와 요구 사항의 함수이며, 카카오 사례가 보여 주듯 대규모로 갈수록 성능과 함께 장애 분석의 단순함이 기준이 됩니다.

여기서 한 번 더 짚어 둘 것은, 플러그인을 고르는 자유 자체가 표준 인터페이스에서 나온다는 점입니다.

그림 5. CNI·CRI·CSI라는 표준 인터페이스가 벤더 종속 없이 구현체를 고를 자유를 만든다 (출처: Cloud Native Forum 쿠버네티스 소개 자료)

다음 단계로는 이 네트워크 위에서 실제 기업들이 클러스터를 어떻게 운영하는지, 카카오와 LY 코퍼레이션의 프로덕션 사례를 이어 읽으시길 권합니다.

자주 묻는 질문 — FAQ 정리

쿠버네티스 네트워킹에서 CNI란 무엇인가요?

컨테이너에 네트워크 인터페이스를 붙이고 IP를 할당·회수하는 방법을 정의한 CNCF 표준 규격입니다(containernetworking/cni). 쿠버네티스는 이 규격을 따르는 플러그인(Calico·Cilium·Flannel 등)에 파드 네트워크 구성을 맡깁니다.

쿠버네티스 네트워킹 CNI 플러그인을 설치하지 않으면 어떻게 되나요?

파드에 네트워크를 만들어 줄 구성 요소가 없어 노드가 NotReady 상태에 머물고 파드 스케줄링이 정상 동작하지 않습니다. 클러스터 구축 시 컨트롤 플레인 초기화 직후 CNI 설치가 필수 단계인 이유입니다.

쿠버네티스 네트워킹에 Calico와 Cilium 중 무엇을 골라야 하나요?

네트워크 정책 중심의 안정적 운영이 목표라면 Calico, 대규모 트래픽 성능과 L7 관측·보안까지 원한다면 eBPF 기반 Cilium이 유력합니다. 카카오는 12만 대 이상 노드 환경에서 성능과 디버깅 단순화를 이유로 Cilium을 선택했습니다(카카오 사례).

eBPF가 왜 쿠버네티스 네트워킹에서 중요한가요?

커널을 고치지 않고 커널 안에서 패킷 처리 프로그램을 실행하는 기술이라, iptables 규칙 수천 개를 선형 탐색하던 kube-proxy 방식의 규모 한계를 해시맵 조회로 우회할 수 있기 때문입니다. 대규모 클러스터일수록 효과가 커집니다.

쿠버네티스 네트워킹의 Ingress와 Gateway API는 무엇이 다른가요?

둘 다 외부 트래픽을 클러스터 안 서비스로 라우팅하는 표준이지만, Gateway API가 더 풍부한 라우팅 표현과 역할 분리 모델을 제공하는 차세대 규격입니다. 2023년 v1.0 정식 승격 이후 신규 설계에서는 Gateway API 우선 검토가 권장 흐름입니다(Gateway API v1.0 발표).

참고 리소스

공식 문서 · 표준

함께 읽기 (cncf.co.kr)

대규모 운영 사례 (cncf.co.kr)

쿠버네티스 eBook — 8장 서비스 디스커버리와 네트워크 (cncf.co.kr)

자료 다운로드 (cncf.co.kr)

더 깊이 들어가려면

쿠버네티스 네트워킹을 손으로 확인해 보고 싶다면 아래 경로로 이어가 보세요.

GitHub repo 방문 — containernetworking/cni 에서 CNI 표준 스펙과 레퍼런스 플러그인을 확인하세요.
CNCF Slack 참여 — slack.cncf.io 에서 Cilium·Calico 채널의 전 세계 실무자와 질문·토론을 나눌 수 있습니다.
CNCF Landscape 확인 — landscape.cncf.io 에서 네트워킹 카테고리의 프로젝트 지형을 한눈에 살펴보세요.