Udemy CKA 강의 정리 204: Prerequisite - CNI

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이 강의에서는 컨테이너 네트워킹 인터페이스에 대해 알아봅니다. 지금까지 네트워크 네임스페이스가 작동하는 방식, 예를 들어 시스템 내에서 격리된 네트워크 네임스페이스 환경을 만드는 방법, 브리지 네트워크를 통해 여러 개의 네임스페이스를 연결하는 방법, 양쪽 끝에 가상 인터페이스가 있는 가상 케이블이나 파이프를 만드는 방법, 그리고 각 엔드 투 엔드 네임스페이스와 브리지를 연결하는 방법을 살펴 보았습니다. 또한 IP를 할당하고 IP를 불러오는 방법과 함께 마지막으로 외부 통신을 위해 NAT 또는 IP 위장을 사용하도록 설정합니다. 그런 다음 Docker가 브리지 네트워킹 옵션에 대해 어떻게 수행했는지 확인했습니다. 그것은 다른 이름 패턴을 사용한다는 것을 제외하고는 거의 같은 방식이었습니다. 다른 컨테이너 솔루션들도 같은 방식으로 네트워킹 문제를 해결합니다.

Rocket이나 Mesos Container와 같이 컨테이너와 함께 작동하고 Kubernetes와 같이 컨테이너 간의 네트워킹을 구성해야 하는 다른 솔루션들도 마찬가지입니다.

모두가 사소한 차이를 가지고 유사한 접근 방식을 연구하고 최종적으로 식별함으로써 동일한 네트워킹 문제를 해결하려고 한다면, 왜 동일한 솔루션을 여러 번 코딩하고 개발할까요? 모두가 따를 수 있는 단일 표준 접근 방식을 만들어 보는 것은 어떨까요? 그래서 우리는 이 모든 아이디어를 다른 솔루션에서 가져와 그것의 모든 네트워킹 부분을 하나의 프로그램이나 코드로 옮깁니다. 그리고 이것이 브리지 네트워크를 위한 것이기 때문에, 우리는 그것을 브리지라고 부릅니다.

그래서 우리는 컨테이너를 브리지 네트워크에 연결하기 위해 필요한 모든 작업을 수행하는 프로그램이나 스크립트를 만들었습니다. 예를 들어 Bridge라는 이름을 사용하여 이 프로그램을 실행하고 특정 네트워크 namespace에 이 컨테이너를 추가하도록 지정할 수 있습니다. Bridge 프로그램은 컨테이너 런타임 환경이 이러한 작업에서 벗어나도록 나머지 부분을 처리합니다. 예를 들어, Rocket 또는 Kubernetes가 새 컨테이너를 만들 때 Bridge Program을 호출하고 컨테이너 ID와 네임스페이스를 전달하여 해당 컨테이너에 대한 네트워킹을 구성합니다.

그렇다면 만약 여러분이 새로운 네트워킹 유형을 위해 그런 프로그램을 만들고 싶다면 어떨까요? 만약 당신이 그렇게 한다면, 그것은 어떤 arguments와 커맨드를 지원해야 합니까? 작성한 프로그램이 현재 실행 시간에 맞게 작동하는지 어떻게 확인합니까? Kubernetes나 Rocket과 같은 컨테이너 실행 시간이 당신의 프로그램을 정확하게 호출할 것이라는 것을 어떻게 압니까? 그것이 우리가 정의해야 할 몇 가지 기준이 필요한 부분입니다. 프로그램이 어떻게 보여야 하는지, 컨테이너 실행 시간이 어떻게 실행되는지 정의하는 표준으로, 모든 사용자가 단일 표준 세트를 준수하고 실행 시간에 걸쳐 작동하는 솔루션을 개발할 수 있습니다.

여기서 컨테이너 네트워크 인터페이스가 등장합니다. CNI는 컨테이너 런타임 환경에서 네트워킹 문제를 해결하기 위해 프로그램을 개발하는 방법을 정의하는 표준의 집합입니다. 프로그램을 플러그인이라고 합니다. 이 경우, 우리가 언급한 Bridge 프로그램은 CNI를 위한 플러그인이다. CNI는 플러그인이 어떻게 개발되어야 하는지, 컨테이너 실행 시간이 어떻게 그것들을 호출해야 하는지를 정의합니다.

CNI는 컨테이너 실행 시간 및 플러그인에 대한 일련의 책임을 정의합니다. 컨테이너 실행 시간의 경우, CNI는 각 컨테이너에 대한 네트워크 namespace을 생성하도록 지정합니다. 그런 다음 컨테이너가 연결되어야 하는 네트워크를 식별해야 하며, 컨테이너 런타임은 add 커맨드를 사용하여 컨테이너를 생성할 때 플러그인을 호출해야 하며, del 커맨드를 사용하여 컨테이너를 삭제할 때 플러그인을 호출해야 합니다. 또한 JSON 파일을 사용하여 컨테이너 런타임 환경에서 네트워크 플러그인을 구성하는 방법도 지정합니다. 플러그인 측에서는 플러그인이 추가, del 및 check 커맨드라인 arguments를 지원해야 하며 컨테이너 및 네트워크 네임스페이스와 같은 매개 변수를 허용해야 한다고 정의합니다. 플러그인은 컨테이너가 네트워크의 다른 컨테이너에 도달하는 데 필요한 파드 및 관련 경로에 IP 주소를 할당해야 합니다. 마지막에 결과를 특정 형식으로 지정해야 합니다. 컨테이너 가동 시간과 플러그인이 이러한 표준을 준수하는 한, 그들은 모두 함께 조화롭게 살 수 있습니다. 모든 실행 시간은 모든 플러그인을 사용하여 작업할 수 있어야 합니다.

CNI에는 Bridge, VLAN, IP VLAN, MAC VLAN, 윈도우즈용 플러그인 및 Host Local 및 DHCP와 같은 IPAM 플러그인과 같은 이미 지원되는 플러그인 집합이 함께 제공됩니다. 타사 조직에서 사용할 수 있는 다른 플러그인도 있습니다. 예를 들어 Weeve, Flannel, Cilium, VMware NSX, Calico, Infoblox 등이 있습니다. 이러한 모든 컨테이너 런타임은 CNI 표준을 구현하므로 이러한 플러그인 중 하나라도 작동할 수 있습니다.

하지만 이 목록에 없는 것이 하나 있습니다. 도커입니다. 도커는 CNI를 구현하지 않습니다. 도커는 CNM이라는 자체 표준을 가지고 있는데, CNI와 유사하지만 약간의 차이가 있는 컨테이너 네트워킹 문제를 해결하는 것을 목표로 하는 또 다른 표준인 컨테이너 네트워크 모델을 의미합니다.