[CKA] 60. The Why and What of CNI

Date

2026/02/01

Container Network Interface

지난 글을 통해 Linux 네트워크 네임스페이스로 격리된 네트워크 공간을 만들고, veth pair로 가상 케이블을 연결하고, Linux Bridege로 가상 스위치를 만들어 필요하면 iptables로 NAT(MASQUERADE)까지 켜서 밖으로 나가는 길을 만드는 흐름을 공부했다.

문제는

•

Docker도 비슷한 방식으로 브리지 네트워크를 만들고(veth + bridge)

•

Rocket, Mesos, Kubernetes 같은 런타임도 결국 “비슷한 문제”를 풀고 있고

•

다들 비슷한 접근을 하면서도 각자 구현이 조금씩 다르다는 것이다

“똑같은 네트워킹 문제를 왜 런타임마다 반복해서 구현해야 할까?”에서 등장하게 된 것이 CNI이다.

네트워킹 부분만 표준화

컨테이너 Runtime이 컨테이너를 만들 때마다 해야 하는 네트워킹 작업은 꽤 정형화되어 있다.

Network Namespace 생성

bridge network/interface 생성

veth pairs(pipe, virtual cable) 생성

veth를 namespace에 붙이기

다른 veth를 bridge에 붙이기

IP 주소 할당

인터페이스 실행

필요하면 NAT/포트포워딩

네트워킹 부분인 2~8번 과정을 bridge라는 하나의 프로그램이나 스크립트로 처리한다면 명확해진다.

•

Runtime(Kubernetes/Rocket 등)은 컨테이너를 만들고

•

bridge 프로그램에게 컨테이너 ID + 네임스페이스를 넘겨

•

네트워킹 구성을 외주한다

런타임은 네트워크 구현에서 벗어날 수 있다. 하지만 여기서 질문이 생길 수 있다:

•

“이 bridge 프로그램은 어떤 인자를 받아야 하지?”

•

“런타임은 언제/어떻게 이 프로그램을 호출해야 하지?”

•

“출력은 어떤 형식이어야 서로 호환되지?”

즉, 프로그램(플러그인)의 인터페이스를 정해야 한다. 이것이 바로 CNI이다.

CNI = “플러그인 규격”

CNI는 한마디로 정의하자면 다음과 같다:

컨테이너 네트워크를 구성하는 프로그램(플러그인)을 어떻게 만들고, 런타임이 그 플러그인을 어떻게 호출해야 하는지 정의한 표준

여기서 핵심은 CNI는 네트워크 구현이 아니라 “규격”이라는 점이다

플러그인은 다양할 수 있고, 런타임 또한 다양할 수 있지만, 둘이 붙는 접점을 표준화하여 ‘어느 런타임이든 어느 플러그인이든’ 붙게 만드는 것이 목적이다.

CNI에서 역할 분리

컨테이너 런타임의 책임

CNI는 런타임에게 다음을 요구한다:

컨테이너마다 네트워크 네임스페이스를 만든다 
(Container Runtime must create network namespace)

컨테이너가 붙을 네트워크를 결정한다 
(Identify the network the container must attach to)

컨테이너 생성 시 플러그인을 ADD로 호출한다
(Container Runtime to invoke Network Plugin (bridge) when container is ADDed)

컨테이너 삭제 시 플러그인을 DEL로 호출한다
(Container Runtime to invoke Network Plugin (bridge) when container is DELeted)

플러그인 설정은 JSON 파일로 전달한다
(JSON format of the Network Configuration)

즉, 런타임은 컨테이너 라이프사이클과 호출 타이밍을 책임지고, 네트워크 세팅 자체는 플러그인에게 맡긴다.

플러그인의 책임

플러그인은 다음을 수행해야 한다:

ADD, DEL, CHECK 같은 표준 커맨드(인자)를 지원해야 한다

컨테이너 id/네트워크 네임스페이스 같은 매개변수를 허용해야 한다

파드에 IP 주소를 할당하고 컨테이너가 네트워크의 다른 컨테이너에 도달하는 데 필요한 모든 관련 경로를 최종적으로 처리해야 한다

결과를 정해진 형식으로 반환해야 한다

CNI 플러그인 생태계

CNI 표준을 따르는 플러그인은 다양하게 존재한다:

•

기본 제공/대표 플러그인: bridge, vlan, macvlan, host-local, dhcp 등

•

서드파티/벤더 플러그인: weave, flannel, cilium, calico, VMware NSX, Infoblox 등

Docker는 예외

Docker는 CNI를 기본으로 구현하지 않는다. Docker는 Docker만의 네트워킹 표준인 CNM(Container Network Model)이라는 모델을 사용한다.

따라서 네이티브로는 CNI 플러그인으로 네트워킹하지 못하며 직접 해결해야 한다.

docker run --network=cni-bridge nginx # 네이티브 불가능

# 가능
docker run --network=none nginx
bridge add 2e34dcf34 /var/run/netns/2e34dcf34
Bash
복사

위 코드와 같이 네트워크 구성 없이 Docker 컨테이너를 만든 다음 Bridge 플러그인을 수동으로 호출하면 CNI를 Docker에서 사용할 수 있다.

이 방식이 쿠버네티스가 Docker 컨테이너를 생성할 때 네트워크를 생성하는 방식이다.(Docker를 Runtime으로 사용하던 시절 기준)

정리

•

컨테이너 네트워킹은 결국 다 비슷한 문제를 푼다: netns + veth + bridge + ip/route (+ NAT)

•

런타임마다 이걸 반복 구현하는 건 비효율적이다

•

그래서 “네트워킹 구성”을 플러그인으로 분리하고, 런타임  플러그인 사이의 호출 규칙을 표준화한 게 CNI

•

CNI를 따르면 “어떤 런타임이든 어떤 플러그인이든” 호환 가능

•

Docker는 기본이 CNI가 아니라 CNM이지만, Kubernetes는 CNI 플러그인을 호출해서 Docker 컨테이너 네트워크를 구성하는 식으로 사용해왔다

이전 게시물

[CKA] 59. Network Namespace

다음 게시물

[CKA] 61. Cluster/Pod Networking