CNI

컨테이너 네트워킹 모델은 CNI의 근간을 이루는 추상화 계층이다. 이 모델은 컨테이너 런타임과 네트워크 플러그인 간의 상호작용을 정의하는 간단하면서도 강력한 명세이다. 핵심은 컨테이너가 네트워크 네임스페이스에 연결(ADD)되고 분리(DEL)되는 두 가지 기본 작업을 표준화하는 것이다. 이 모델은 네트워크 구성의 세부 사항을 플러그인에 위임함으로써, 쿠버네티스나 Mesos와 같은 다양한 컨테이너 오케스트레이션 시스템이 일관된 방식으로 네트워크를 관리할 수 있게 한다.

모델의 작동은 주로 JSON 형식의 설정 파일과 실행 가능한 플러그인 바이너리를 통해 이루어진다. 컨테이너 런타임은 컨테이너의 네트워크 네임스페이스 경로, 컨테이너 ID, 그리고 설정 파일을 특정 CNI 플러그인에 전달한다. 플러그인은 이 정보를 받아 실제 네트워크 인터페이스를 생성하고, IP 주소를 할당하며, 필요한 라우팅 규칙을 설정하는 책임을 진다. 작업이 완료되면 플러그인은 결과(예: 할당된 IP 주소)를 JSON 형식으로 런타임에 반환한다.

이 모델은 여러 네트워크를 컨테이너에 연결하는 체인(chain) 방식도 지원한다. 이를 통해 하나의 컨테이너가 메인 네트워크 인터페이스와 추가적인 네트워크 인터페이스 (예: 멀티테넌시 환경 또는 특수 목적 네트워크)를 가질 수 있다. 각 네트워크는 독립적인 플러그인에 의해 처리될 수 있으며, 설정 파일에 정의된 순서대로 실행된다.

컨테이너 네트워킹 모델의 가장 큰 장점은 복잡성을 추상화한다는 점이다. 네트워크 제공자(플러그인 개발자)는 표준 인터페이스만 준수하면 되고, 컨테이너 런타임 또는 오케스트레이터는 내부 네트워크 구현 방식에 관계없이 동일한 API를 사용할 수 있다. 이는 생태계의 혁신과 다양성을 촉진하는 데 기여했다.

CNI 플러그인 아키텍처는 네트워크 기능을 모듈화하고 표준화된 방식으로 제공하는 설계 철학을 기반으로 한다. 이 아키텍처의 핵심은 컨테이너 런타임이 특정 네트워크 공급업체에 종속되지 않고, 표준 JSON 설정 파일을 통해 선언된 네트워크를 다양한 플러그인에게 위임할 수 있게 하는 데 있다. 각 플러그인은 독립적인 실행 파일로 존재하며, CNI 사양에 정의된 간단한 ADD와 DEL 명령을 구현한다.

플러그인은 크게 메인 플러그인과 IPAM 플러그인으로 구분된다. 메인 플러그인은 가상 이더넷 장치 생성, 브리지 또는 오버레이 네트워크 연결 등 실제 네트워크 인터페이스 설정을 담당한다. 반면, IPAM(IP Address Management) 플러그인은 컨테이너에 할당할 IP 주소, 게이트웨이, 라우트 정보를 관리하는 특수한 플러그인이다. 이 분리는 네트워크 연결 로직과 IP 할당 로직을 독립적으로 발전시키고 조합할 수 있게 한다.

아키텍처의 유연성은 체인 실행을 통해 극대화된다. 하나의 컨테이너를 여러 네트워크에 연결해야 할 경우, CNI 설정 파일에 여러 플러그인을 순서대로 정의하여 체인으로 실행할 수 있다. 예를 들어, 먼저 브리지 플러그인이 컨테이너를 로컬 네트워크에 연결한 후, 포트맵 플러그인이 호스트 포트를 포워딩하는 방식이다. 이는 복잡한 네트워크 요구사항을 단순한 플러그인의 조합으로 해결할 수 있는 강력한 메커니즘을 제공한다.

이러한 모듈식 설계는 생태계의 활성화를 촉진한다. 누구나 표준 사양을 준수하는 플러그인을 개발하여 기존 컨테이너 오케스트레이션 시스템에 통합할 수 있다. 결과적으로 사용자는 특정 벤더에 잠기지 않고, 성능, 보안, 기능 요구사항에 가장 적합한 네트워킹 솔루션을 자유롭게 선택할 수 있다.

CNI 플러그인은 CNI 스펙을 구현하는 실행 가능한 바이너리 파일이다. 이 플러그인들은 컨테이너 런타임이 네트워크 네임스페이스를 생성한 후, 해당 네임스페이스 내에 실제 네트워크 인터페이스를 구성하고 IP 주소를 할당하며 필요한 라우팅 규칙을 설정하는 구체적인 작업을 담당한다. 각 플러그인은 네트워크 추가(ADD)와 네트워크 삭제(DEL)라는 두 가지 핵심 작업을 수행하도록 설계되었다.

플러그인은 그 기능과 역할에 따라 크게 메인 플러그인과 메타플러그인으로 분류된다. 메인 플러그인은 L2/L3 연결, IP 주소 관리(AM), IP 마스쿼레이딩 등 네트워크 연결 자체를 제공하는 역할을 한다. 반면, 메타플러그인은 단독으로 네트워크를 구성하지 않고, 여러 메인 플러그인을 조율하거나 체인으로 연결하여 복잡한 네트워킹 작업을 수행한다. 예를 들어, 하나의 컨테이너에 여러 네트워크 인터페이스를 추가하거나, 특정 플러그인의 실행 전후에 부가 작업을 수행하는 데 사용된다.

CNI 플러그인은 네트워크 구현 방식에 따라 다양한 종류가 존재하며, 각각 장단점이 뚜렷하다. 주요 유형은 다음과 같다.

이러한 플러그인들은 단독으로 사용되기도 하지만, CNI 설정 파일을 통해 여러 플러그인이 순차적으로 실행되는 체인 방식으로 구성될 수 있다. 이를 통해 네트워크 연결, 대역폭 제한, 방화벽 규칙 추가 등 다양한 기능을 조합하여 적용할 수 있다.

CNI 설정 파일은 JSON 형식으로 작성되며, 컨테이너가 속할 네트워크를 정의하는 역할을 한다. 이 파일은 일반적으로 /etc/cni/net.d/ 디렉터리나 쿠버네티스 클러스터에서 지정한 경로에 위치한다. 설정 파일은 사용할 CNI 플러그인의 종류와 해당 플러그인에 필요한 매개변수, 그리고 여러 네트워크를 연결하는 방법을 기술한다.

기본적인 설정 파일 구조는 다음과 같은 필드를 포함한다.

ipam(IP Address Management) 서브-설정은 네트워크 내에서 컨테이너에 IP 주소를 할당하는 방식을 정의한다. 여기에는 type(예: "host-local", "dhcp"), 사용할 서브넷(subnet), 게이트웨이(gateway), 라우트(routes) 등의 정보가 포함된다. 예를 들어, host-local IPAM을 사용하면 지정된 서브넷 범위 내에서 호스트별로 IP 주소 풀을 관리한다.

설정 파일은 단일 네트워크를 정의하는 기본 형태 외에도, plugins 필드를 사용하여 여러 CNI 플러그인을 순차적으로 실행하는 체인(chain) 구성을 지원한다. 이는 컨테이너에 네트워크 인터페이스를 추가하고, IP를 할당하며, 추가적인 라우팅이나 방화벽 규칙을 적용하는 등 복잡한 네트워크 설정을 모듈화하여 구현할 수 있게 한다. 각 플러그인의 실행 결과는 다음 플러그인으로 전달된다.

CNI는 컨테이너 런타임과 독립적으로 설계되었다. 이는 도커의 dockerd, containerd의 containerd, CRI-O 등 다양한 컨테이너 런타임과 통합되어 작동할 수 있음을 의미한다. 런타임은 컨테이너의 생명주기를 관리하는 주체로서, 컨테이너 생성 시점에 CNI를 호출하여 네트워크를 구성한다.

통합은 일반적으로 런타임의 설정을 통해 이루어진다. 예를 들어, 쿠버네티스의 kubelet은 CRI(Container Runtime Interface)를 통해 컨테이너 런타임과 통신하며, --cni-bin-dir 및 --cni-conf-dir과 같은 파라미터를 사용하여 CNI 플러그인의 위치와 설정 파일을 지정한다. 런타임은 컨테이너의 네임스페이스(특히 네트워크 네임스페이스) 경로와 컨테이너 ID를 CNI 플러그인에 전달한다.

아래 표는 주요 컨테이너 런타임과의 CNI 통합 방식을 간략히 보여준다.

이러한 런타임 독립성 덕분에 CNI는 특정 플랫폼에 종속되지 않고 광범위한 클라우드 네이티브 생태계에서 표준 네트워킹 인터페이스로 자리 잡았다.

컨테이너 런타임(예: kubelet 또는 CRI-O)이 새로운 파드(Pod)를 생성할 때, 해당 파드의 네임스페이스(namespace)에 네트워크 인터페이스를 제공해야 합니다. 이때 런타임은 미리 정의된 경로(기본값 /opt/cni/bin)에서 CNI 플러그인 바이너리를 찾고, /etc/cni/net.d 디렉토리에 위치한 CNI 설정 파일(보통 JSON 형식)을 읽습니다. 설정 파일에는 사용할 플러그인의 이름(예: bridge), 플러그인에 전달할 파라미터(예: 사용할 IP 대역), 그리고 필요에 따라 체인으로 실행할 다른 플러그인 목록이 정의되어 있습니다.

런타임은 표준 입력(stdin)을 통해 JSON 형식의 네트워크 구성 데이터를 플러그인에 전달하면서 ADD 명령을 실행합니다. 전달되는 데이터에는 컨테이너 ID, 네트워크 네임스페이스의 경로, 생성할 인터페이스 이름 등이 포함됩니다. CNI 플러그인은 이 정보를 받아 지정된 작업을 수행합니다. 예를 들어, bridge 플러그인은 호스트에 가상 브리지를 생성하거나 기존 브리지에 연결하고, veth 페어(가상 이더넷 장치 쌍)를 만들어 한쪽 끝을 컨테이너 네임스페이스에, 다른 쪽 끝을 호스트 브리지에 연결합니다. 이후 IP 주소 관리(IPAM) 플러그인을 호출하여 컨테이너에 IP 주소를 할당하고 라우팅 정보를 설정합니다.

ADD 작업이 성공적으로 완료되면, CNI 플러그인은 표준 출력(stdout)을 통해 JSON 형식의 결과를 런타임에 반환합니다. 반환되는 정보에는 할당된 IP 주소, 인터페이스 이름, DNS 서버 주소 등이 포함되어, 런타임이 이를 기록하고 파드의 네트워크 상태를 인식할 수 있게 합니다. 이 과정은 파드의 각 컨테이너에 대해 순차적으로 수행될 수 있습니다.

이 작업의 실패는 다양한 원인으로 발생할 수 있습니다. IP 주소 풀이 고갈되었거나, 네트워크 네임스페이스 경로가 유효하지 않거나, 플러그인 바이너리에 실행 권한이 없는 경우 등입니다. 실패 시 플러그인은 오류 메시지를 표준 에러(stderr)에 출력하고 0이 아닌 종료 코드로 반환하여, 런타임이 파드 생성 실패를 알 수 있게 합니다.

컨테이너 런타임은 컨테이너가 종료될 때, 해당 컨테이너가 속한 네트워크 네임스페이스에서 컨테이너를 분리하고 네트워크 리소스를 정리해야 합니다. 이때 CNI는 DEL(또는 DELETE) 작업을 실행하여 이 과정을 표준화된 방식으로 처리합니다.

DEL 작업은 기본적으로 ADD 작업의 역순으로 진행됩니다. 런타임은 CNI 설정 파일과 컨테이너의 네트워크 네임스페이스 경로를 인자로 제공하며, 지정된 CNI 플러그인을 호출합니다. 플러그인은 해당 네임스페이스에 접근하여 자신이 ADD 작업 시에 구성했던 인터페이스를 제거하고, 할당했던 IP 주소를 해제하며, 설정한 라우팅 규칙 등을 삭제합니다. 예를 들어, 브리지 네트워크를 사용하는 플러그인은 컨테이너의 veth 쌍을 브리지에서 분리하고 네임스페이스 내에서 제거합니다.

이 작업의 성공은 컨테이너의 깨끗한 종료와 시스템 리소스의 효율적 관리에 필수적입니다. 리소스가 제대로 해제되지 않으면 IP 주소 고갈, 라우팅 테이블 오염, 또는 네트워크 인터페이스 누수와 같은 문제가 발생할 수 있습니다. DEL 작업은 ADD 작업과 동일한 플러그인과 설정으로 실행되어야 하며, 이를 통해 네트워크 상태를 정확히 원복할 수 있습니다.

Calico는 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼을 위한 고성능 CNI 플러그인이다. 네트워크 연결성 제공과 동시에 세분화된 네트워크 보안 정책을 적용하는 데 특화되어 있다. 다른 많은 오버레이 네트워크 기반 솔루션과 달리, Calico는 표준 IP 라우팅 프로토콜과 리눅스 커널의 내장 네트워킹 기능을 활용하여 네트워크를 구성한다.

Calico의 핵심 아키텍처는 BGP 프로토콜을 사용한다. 각 노드에서 동작하는 Felix 에이전트는 라우팅 정보와 네트워크 정책을 관리하며, BGP 스피커 역할을 하는 BIRD는 이 라우팅 정보를 다른 노드들과 교환한다. 이를 통해 팟의 IP 주소가 클러스터 전체에 효율적으로 광고되고, 트래픽은 라우팅 테이블에 따라 최단 경로로 직접 전달된다. 이 방식은 네트워크 가상화 계층을 최소화하여 낮은 지연 시간과 높은 처리량을 제공한다.

네트워크 정책 구현은 Calico의 주요 강점이다. 쿠버네티스 네트워크 정책을 완벽히 지원할 뿐만 아니라, 더욱 풍부한 기능을 제공하는 Calico 네트워크 정책도 사용할 수 있다. 예를 들어, Calico 정책은 프로토콜, 포트, CIDR 블록뿐만 아니라 도메인 이름 기반의 규칙이나 로깅 규칙도 정의할 수 있다. 정책은 각 노드의 리눅스 커널의 iptables 또는 eBPF 데이터플레인에 프로그램되어 강제된다.

Calico는 IP-in-IP 터널링 또는 VXLAN을 사용한 오버레이 네트워크 모드도 지원하여, 기본 네트워크 인프라가 BGP를 지원하지 않는 환경에서도 배포할 수 있다. 또한 윈도우 노드 지원, 서비스 메시와의 통합, eBPF 데이터플레인 옵션 등 엔터프라이즈급 기능을 제공한다.

Flannel은 CoreOS에서 개발한 간단하고 가벼운 CNI 플러그인이다. 쿠버네티스와 같은 컨테이너 오케스트레이션 시스템에서 오버레이 네트워크를 구성하는 데 널리 사용된다. Flannel의 주요 목표는 클러스터 내 모든 포드가 고유한 IP 주소를 갖고 서로 통신할 수 있도록 하는 것이다. 이를 위해 각 호스트에 서브넷을 할당하고, 패킷 캡슐화 기술을 사용해 호스트 간 트래픽을 라우팅한다.

Flannel은 여러 백엔드(Backend)를 지원하여 다양한 네트워크 환경에 적응할 수 있다. 가장 일반적인 백엔드는 VXLAN이다. VXLAN은 이더넷 프레임을 UDP 패킷으로 캡슐화하여 물리적 네트워크 인프라 위에 가상의 레이어 2 네트워크를 생성한다. 다른 백엔드로는 호스트-게이트웨이(Host-gw), UDP, AWS VPC, 구글 클라우드 플랫폼 등이 있다. 각 백엔드는 성능, 복잡성, 지원 환경 측면에서 차이가 있다.

Flannel은 설정이 간단하고 관리가 용이하다는 장점이 있다. 기본 구성만으로도 빠르게 클러스터 네트워킹을 구축할 수 있다. 그러나 네트워크 정책을 기본적으로 제공하지 않아, 칼리코(Calico)나 실리움(Cilium) 같은 다른 CNI 플러그인과 연동해야 보안 기능을 활용할 수 있다. 또한, 대규모 클러스터에서의 성능과 멀티 테넌시 지원은 다른 고급 플러그인에 비해 제한적일 수 있다.

Cilium은 eBPF 기술을 기반으로 하는 고성능 CNI 플러그인이다. 기존의 iptables나 오버레이 네트워크에 의존하는 방식과 달리, 리눅스 커널 내부의 eBPF 가상 머신을 활용하여 네트워크 트래픽 처리, 보안 정책 적용, 가시성 확보를 커널 수준에서 직접 수행한다. 이는 OSI 모델의 3계층(네트워크 계층)과 4계층(전송 계층)을 넘어 7계층(애플리케이션 계층)의 프로토콜(예: HTTP, gRPC)을 인식하고 제어할 수 있는 능력을 부여한다.

Cilium의 핵심 기능은 다음과 같다.

Cilium은 복잡한 네트워크 보안 요구사항과 높은 성능이 필요한 환경, 특히 마이크로서비스와 서비스 메시 아키텍처에서 두각을 나타낸다. Hubble이라는 관찰 가능성 도구를 내장하여 네트워크 흐름과 보안 이벤트에 대한 심층적인 가시성을 제공한다. 또한, 클러스터 메시 기능을 통해 여러 쿠버네티스 클러스터 간의 네트워킹과 정책 관리를 단일화할 수 있다.

Weave Net은 CNI 플러그인 중 하나로, 오버레이 네트워크를 생성하여 쿠버네티스 클러스터 내 포드 간 통신을 가능하게 한다. 각 노드에 배포되는 Weave Router라는 에이전트가 VXLAN과 같은 캡슐화 프로토콜을 사용해 네트워크 트래픽을 터널링한다. 이 방식은 물리적 네트워크 인프라와 독립적으로 가상 네트워크를 구성할 수 있게 해준다.

설치와 구성이 비교적 간단한 것이 특징이다. 단일 명령어로 전체 클러스터에 배포할 수 있으며, 별도의 외부 키-값 저장소나 구성 데이터베이스가 필요하지 않다. 네트워크 토폴로지와 라우팅 정보는 각 Weave Router 에이전트 간의 피어 투 피어(peer-to-peer) 프로토콜을 통해 자동으로 관리된다.

성능 측면에서는 초기 버전이 사용자 공간에서 동작해 오버헤드가 있었으나, 이후 커널의 'fastdatapath' 모드를 도입하여 네트워크 처리 성능을 크게 향상시켰다. 또한 네트워크 정책을 시행할 수 있으며, 쿠버네티스의 NetworkPolicy 리소스와 통합되어 포드 간 트래픽 흐름을 제어할 수 있다.

CNI는 컨테이너 런타임과 네트워크 플러그인 사이에 명확한 계약을 정의하여 표준화된 인터페이스를 제공한다. 이는 다양한 컨테이너 오케스트레이션 시스템, 특히 쿠버네티스에서 네트워킹 솔루션을 일관되게 관리하고 통합할 수 있는 기반이 된다. 표준 인터페이스가 존재하기 전에는 각 컨테이너 런타임이 고유한 방식으로 네트워크를 구성해야 했으며, 이는 호환성 문제와 관리의 복잡성을 초래했다.

CNI 표준은 네트워크를 추가(ADD)하거나 삭제(DEL)하는 기본 작업을 JSON 형식의 설정 파일과 간단한 실행 파일(플러그인)을 통해 수행하도록 규정한다. 이로 인해 어떠한 CNI 호환 플러그인이든 동일한 방식으로 컨테이너의 네트워크 네임스페이스에 인터페이스를 생성하고, IP 주소를 할당하며, 필요한 라우팅을 설정할 수 있다. 결과적으로 Calico, Flannel, Cilium과 같은 서로 다른 구현체를 런타임이나 오케스트레이터 변경 없이 교체하거나 함께 사용하는 것이 가능해진다.

이러한 표준화의 가장 큰 이점은 생태계의 활성화와 벤더 종속의 감소이다. 사용자는 특정 클라우드 공급자나 플랫폼에 종속되지 않고 자신의 요구사항(예: 성능, 보안, 기능)에 가장 적합한 네트워킹 솔루션을 자유롭게 선택할 수 있다. 또한, CNI 명세는 비교적 단순하고 경량화되어 있어 새로운 네트워크 플러그인을 개발하는 진입 장벽을 낮추었다.

CNI의 표준화된 인터페이스는 네트워크 솔루션에 대한 높은 유연성을 제공합니다. 사용자는 애플리케이션 요구사항, 보안 정책, 인프라 환경에 맞춰 다양한 CNI 플러그인을 선택하거나 자체적으로 개발하여 통합할 수 있습니다. 이는 특정 벤더나 기술에 종속되지 않는 개방형 생태계를 가능하게 합니다. 예를 들어, 단순한 오버레이 네트워크가 필요한 경우 Flannel을, 고성능과 세밀한 네트워크 정책이 필요하면 Cilium이나 Calico를 선택하는 식으로 유연한 구성이 가능합니다.

또한 CNI의 플러그인 아키텍처는 뛰어난 확장성의 기반이 됩니다. 기본적인 IP 주소 할당 및 라우팅 기능을 넘어, 네트워크 정책 시행, 서비스 메시 통합, 로드 밸런싱, 암호화와 같은 고급 네트워킹 기능을 플러그인 형태로 추가할 수 있습니다. 이는 컨테이너 오케스트레이션 플랫폼의 코어를 변경하지 않고도 네트워킹 스택을 진화시킬 수 있음을 의미합니다.

이러한 유연성과 확장성은 다양한 클라우드 환경과 온프레미스 인프라를 아우르는 하이브리드 클라우드 및 멀티 클라우드 전략에 적합합니다. 서로 다른 환경에서도 동일한 CNI 인터페이스를 통해 일관된 네트워크 관리 모델을 적용할 수 있어, 운영의 복잡성을 줄이고 이식성을 높이는 데 기여합니다.

CNI는 특정 컨테이너 런타임에 종속되지 않는 설계 원칙을 가지고 있다. 이는 CNI가 도커, containerd, CRI-O 등 다양한 컨테이너 런타임과 호환되어 작동할 수 있음을 의미한다. 런타임은 단지 CNI 사양에 정의된 표준 인터페이스를 통해 네트워크 플러그인을 호출하기만 하면 되며, 플러그인의 내부 구현 방식을 알 필요가 없다.

이러한 독립성은 쿠버네티스 생태계에서 특히 중요한 장점으로 작용한다. 쿠버네티스는 kubelet을 통해 다양한 컨테이너 런타임을 지원하는데, CNI는 이러한 런타임의 다양성 아래에서도 일관된 네트워킹 솔루션을 제공할 수 있다. 사용자는 애플리케이션 워크로드나 클러스터 요구사항에 맞게 컨테이너 런타임을 선택하거나 변경할 수 있으며, 네트워킹 계층은 CNI 플러그인을 통해 별도로 관리된다.

결과적으로 CNI의 런타임 독립성은 다음과 같은 이점을 제공한다.

이 설계는 OCI 표준과 함께 컨테이너 기술의 모듈화와 전문 분업화 경향을 잘 반영한다.

쿠버네티스는 컨테이너 오케스트레이션 플랫폼으로, 파드라는 기본 배포 단위를 사용한다. 쿠버네티스는 네트워킹을 자체적으로 구현하지 않고, CNI 사양을 통해 외부 플러그인에 네트워크 구성 작업을 위임한다. 이는 네트워크 계층을 추상화하여 다양한 네트워크 솔루션을 유연하게 통합할 수 있게 한다.

쿠버네티스 클러스터에서 CNI는 kubelet에 의해 관리된다. kubelet은 각 노드에서 실행되는 에이전트로, 파드의 생명주기를 담당한다. 파드가 생성될 때 kubelet은 미리 정의된 경로(기본값 /etc/cni/net.d)에서 CNI 설정 파일을 읽고, 지정된 CNI 플러그인 바이너리(기본값 /opt/cni/bin)를 실행하여 파드에 네트워크 인터페이스를 할당하고 연결한다. 이 과정은 파드의 인프라 컨테이너(예: pause 컨테이너)의 네트워크 네임스페이스 내에서 이루어진다.

쿠버네티스와 CNI의 통합은 네트워크 정책 관리에도 영향을 미친다. 쿠버네티스는 네트워크 정책을 정의하는 NetworkPolicy 리소스 API를 제공하지만, 이 정책을 실제로 강제(enforce)하는 것은 CNI 플러그인의 역할이다. 예를 들어, Calico나 Cilium과 같은 CNI 플러그인은 NetworkPolicy 오브젝트를 감지하고, 해당 규칙을 리눅스 커널의 iptables나 eBPF 프로그램으로 변환하여 트래픽을 필터링한다.

이러한 통합 구조 덕분에 쿠버네티스 사용자는 클러스터 요구사항(성능, 보안, 기능)에 맞는 CNI 플러그인을 선택할 수 있으며, 네트워크 인프라의 변경 없이도 플러그인을 교체하거나 업그레이드하는 것이 가능해진다.

쿠버네티스 네트워크 정책(NetworkPolicy)은 파드 간의 네트워크 트래픽을 제어하는 규칙 집합이다. 이 정책은 CNI 플러그인에 의해 실제 네트워크 수준에서 강제 적용된다. 모든 CNI 플러그인이 네트워크 정책을 지원하는 것은 아니며, 지원 여부와 구현 방식은 플러그인마다 다르다.

네트워크 정책은 YAML 매니페스트로 정의되며, 정책이 적용될 파드 셀렉터, 허용되는 인그레스(수신) 및 이그레스(송신) 규칙을 명시한다. 예를 들어, 특정 네임스페이스의 레이블이 'app=web'인 파드로부터의 트래픽만 허용하는 인그레스 규칙을 정의할 수 있다. CNI 플러그인은 쿠버네티스 API 서버를 감시하여 이러한 정책 오브젝트의 생성, 수정, 삭제를 감지한다. 변경 사항이 발생하면 플러그인은 해당 정책을 해석하여 자신이 관리하는 네트워크 인프라에 맞는 구체적인 규칙(예: 리눅스 iptables 규칙, eBPF 프로그램, 가상 스위치 ACL 등)으로 변환하고 적용한다.

네트워크 정책의 효과적인 구현을 위해서는 기본적으로 모든 트래픽을 거부하는 '기본 거부(Default Deny)' 정책을 설정한 후, 필요한 통신만 명시적으로 허용하는 화이트리스트 방식을 채택하는 것이 보안 모범 사례이다. 또한, 네트워크 정책은 네임스페이스 단위로 적용될 수 있어 다중 테넌트 환경에서의 논리적 격리를 강화하는 데 기여한다.

플러그인 선택은 클러스터의 요구 사항, 환경, 운영 복잡도에 따라 결정된다. 주요 고려 사항으로는 네트워킹 모델(예: 오버레이 네트워크 대 레이어 3 라우팅), 성능, 보안 기능, 운영 및 관리의 용이성, 커뮤니티 지원 및 상용 지원 옵션이 포함된다.

다음 표는 일반적인 선택 기준을 비교한 것이다.

최종 선택은 종종 상충 관계를 고려한 타협의 결과이다. 예를 들어, 최고의 성능을 원한다면 운영 복잡도가 증가할 수 있고, 가장 사용하기 쉬운 솔루션은 고급 기능이 부족할 수 있다. 개념 증명(PoC)을 통해 실제 워크로드 환경에서 여러 후보 플러그인의 성능과 동작을 테스트하는 것이 권장된다.

성능 비교 시 고려해야 할 핵심 요소는 네트워크 처리량, 지연 시간, 리소스 사용량, 그리고 확장성이다. 각 CNI 플러그인은 구현 방식에 따라 이러한 요소에 서로 다른 영향을 미친다.

데이터 플레인 성능은 네트워크 처리량과 지연 시간에 직접적인 영향을 준다. 오버레이 네트워크를 사용하는 플러그인(예: Flannel의 VXLAN 모드, Weave Net)은 일반적으로 언더레이 네트워크나 L3 라우팅 방식을 사용하는 플러그인(예: Calico의 BGP 모드, Cilium)보다 더 높은 CPU 오버헤드와 약간의 지연 시간 증가를 보인다. 이는 패킷 캡슐화 및 디캡슐화 과정에서 발생한다. 반면, eBPF 기반의 Cilium과 같은 플러그인은 커널 우회를 통해 네트워크 처리 성능을 크게 향상시킬 수 있다.

리소스 효율성과 운영 복잡성도 중요한 비교 기준이다. 다음 표는 주요 성능 비교 요소를 정리한 것이다.

최종 선택은 애플리케이션의 요구사항에 따라 결정된다. 높은 처리량과 낮은 지연 시간이 중요한 환경에서는 언더레이 네트워크나 eBPF 기반 솔루션을 우선 검토한다. 반면, 설치와 관리의 용이성이 더 중요하고 네트워크 성능 요구사항이 보통 수준인 경우 오버레이 네트워크 방식의 플러그인이 적합할 수 있다. 항상 특정 환경에서의 벤치마크 테스트를 통해 실제 성능 데이터를 확인하는 것이 바람직하다.