CNI

• CNI는 Container Network Interface의 줄임말이다.

• 우리는 이전 시간에 다음과 같은 과정으로 서비스들이 통신할 수 있다고 배웠다.

1. 네트워크 네임스페이스 생성

2. 브릿지 네트워크/인터페이스 생성

3. VETH 페어 생성 (Pipe, Virtual Cable)

4. vEth를 네임스페이스에 부착

5. 다른 vEth를 브릿지에 부착

6. IP 주소 부여

7. 인터페이스 생성

8 NAT - IP 할성화

• 도커 역시 위와 동일한 방식으로 통신한다.

• 다른 컨테이너 서비스인 rkt, MESOS 등도 위와 완벽하게 동일한 방식으로 통신을 한다.

• 왜 이렇게 여러 솔루션들은 같은 방싱을 취하고 있을까?

• 2번부터 8번까지 우리는 Bridge라고 부른다.

• 네트워크 네임스페이스 생성 방식은 각각의 컨테이너 솔루션마다 다르지만 Bridge는 동일한 로직을 수행하며 이는 Container Runtime 환경에서 네트워크 이슈를 풀기 위한 Container Network Intterface, CNI가 있었기에 가능한 일이다.

• CNI는 컨테이너 런타임이나 플러그인을 위한 몇 가지 요소들을 정의한다.

Container Network Interface

• 컨테이너 런타임의 경우 반드시 각각의 컨테이너에 네트워크 네임스페이스를 명시해야하한다.

• 컨테이너가 붙을 네트워크를 명시해야한다.

• 컨테이너 런타임은 컨테이너가 추가, 삭제되면 네트워크 플러그인 (Bridge)를 호출한다.

• 네트워크 설정은 JSON 파일 형식으로 관리한다.

• 모든 컨테이너 런타임은 CNI를 구현해야만한다.

• 그러나 의외로 예외가 있는데, 그것은 바로 Docker다. 도커만 유일하게 CNI를 구현하고 있지 않다.

• 도커는 자신만의 CNM(Container Network Model)을 구현하는데, 이는 컨테이너 네트워킹에 초점이 맞춰진 CNI와 유사한 또 다른 표준이다.

• 그래서 다음과 같이 CNI에 정의된 네트워크를 명시해서 도커를 구동시킬 수 없다.

docekr run --network=cni-bridge nginx # 에러!
docker run --network=none nginx # 성공
bridge add 2e34dcf34 var/run/netns/2e34dcf34

• k8s 또한 도커 컨테이너를 사용할 때 네트워크를 none으로 주고 브릿지 명령어를 사용해 명시적으로 브릿지와 컨테이너를 연결하고 있다.