CNCF(Cloud Native Computing Foundation)의 프로젝트 중 하나인 Container Network Interface는 컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준이다.

다양한 형태의 컨테이너 런타임과 오케스트레이터 사이의 네트워크 계층을 구현하는 방식이 다양하게 분리되어 각자만의 방식으로 발전하게 되는 것을 방지하고

공통된 인터페이스를 제공하기 만들어 졌고, 쿠버네티스에서는 Pod 간의 통신을 위해서 CNI 를 사용한다.

쿠버네티스 뿐만 아니라 Amazon ECS, Cloud Foundry 등 컨테이너 런타임을 포함하고 있는 다양한 플랫폼들은 CNI를 사용하고 있으며,

쿠버네티스는 기본적으로 'kubenet' 이라는 자체적인 CNI 플러그인을 제공하지만 네트워크 기능이 매우 제한적인 단점이 있다.

그 단점을 보완하기 위해, 3rd-party 플러그인을 사용하는데 그 종류에는 Flannel, Calico, Weavenet, NSX 등 다양한 종류의 3rd-party CNI 플러그인들이 존재한다.

CNI의 필요성

예를들어, 위 그림과 같이 컨테이너 기반으로 동작하는 애플리케이션에 Web UI 컨테이너, Login 컨테이너, 장바구니 Cart 컨테이너 이렇게 멀티 호스트로 구성하였을때

Web UI, Login, Cart 컨테이너는 서로 간에 당연히 통신이 되어야 한다.

UI 컨테이너(172.17.0.2) 에서 Login 컨테이너(172.17.0.2) 로 통신을 하기 위해 트래픽을 보낸다고 가정했을때

정상적인 통신 패턴이라면 UI 컨테이너는 veth0 인터페이스를 통해 docker0 라는 브릿지 인터페이스를 타고 NAT처리 되어 worker node #1의 물리 인터페이스인 ens160의 IP(10.200.155.22) 로 나간다.

그 후,  worker node #2 의 물리 인터페이스인 ens160 (10.200.155.23) 으로 들어와 docker0 브릿지 인터페이스를 통해 Login 컨테이너의 veth0으로 들어온다.

그러나 위 그림에서 보듯이, 두 컨테이너의 IP는 동일하기 때문에 UI 컨테이너에서 Login 컨테이너로 통신을 시도하면 자기 자신인 UI 컨테이너 로컬로 통신을 시도 할 것이고

위와 같은 멀티 호스트로 구성되어 있는 컨테이너 끼리 통신을 하기 위해서는 CNI가 반드시 설치되어 있어야한다.

CNI는 Calico, Weavenet, AWS CNI 등 매우 다양한 종류가 있다.

위 그림에서는 weave net이라고 하는 CNI가 브릿지 인터페이스를 만들고 컨테이너 네트워크 대역대를 나눠주며

라우팅 테이블까지 생성하여 UI 컨테이너가 Login, Cart 컨테이너로 통신하는데 전혀 문제 없도록 지원한다.

CNI에서 사용되는 네트워크 모델

CNI Provider는 VXLAN(Virtual Extensible Lan), IP-in-IP 과 같은 캡슐화된 네트워크 모델 또는 BGP (Border Gateway Protocol)와 같은 캡슐화 되지 않은 네트워크 모델을 사용하여 네트워크 패브릭을 구현한다.

CNI 3rd-Party 플러그인 종류 및 지원하는 기능

Provider	NetworkModel	RouteDistribution	NetworkPolicy	Mesh	ExternalDatastore	Encryption	Ingress/Egress Policies	CommercialSupport
Calico	Layer 3	Yes	Yes	Yes	Etcd	Yes	Yes	Yes
Canal	Layer 2vxlan	N/A	Yes	No	Etcd	No	Yes	No
Flannel	vxlan	No	No	No	None	No	No	No
kopeio-networking	Layer 2vxlan	N/A	No	No	None	Yes	No	No
kube-router	Layer 3	BGP	Yes	No	No	No	No	No
romana	Layer 3	OSPF	Yes	No	Etcd	No	Yes	Yes
Weave Net	Layer 2vxlan	N/A	Yes	Yes	No	Yes	Yes	Yes