앞서 우리는 쿠버네티스 네트워킹 모델의 핵심 요구사항 중 하나가 “모든 파드는 고유한 IP를 가진다”는 것이라고 배웠습니다. 그렇다면 이 마법 같은 일, 즉 각 파드에게 고유한 IP 주소를 할당하고, 파드들이 서로 통신할 수 있도록 네트워크 환경을 구성하는 작업은 과연 누가, 어떻게 수행하는 것일까요? 바로 이 질문에 대한 답의 중심에 컨테이너 네트워크 인터페이스(Container Network Interface, CNI)가 있습니다.

CNI는 쿠버네티스와 같은 컨테이너 오케스트레이션 시스템이 다양한 네트워크 구현체(이를 CNI 플러그인이라고 합니다)와 쉽게 통합되어 컨테이너(쿠버네티스에서는 파드)의 네트워크 인터페이스를 설정하고 관리할 수 있도록 하는 표준화된 명세(specification)이자 라이브러리 집합입니다. CNI는 Cloud Native Computing Foundation (CNCF)의 프로젝트 중 하나로, 쿠버네티스뿐만 아니라 Mesos, rkt, OpenShift 등 다른 컨테이너 관리 플랫폼에서도 널리 채택되어 사용되고 있습니다.

CNI의 핵심 아이디어는 단순함과 유연성입니다. 쿠버네티스 자체는 특정 네트워크 기술이나 벤더에 종속되지 않고, CNI라는 공통된 약속(인터페이스)을 통해 다양한 네트워크 솔루션들이 “플러그 앤 플레이” 방식으로 쿠버네티스 클러스터의 네트워킹을 책임질 수 있도록 하는 것입니다. 마치 USB 규격이 있어서 어떤 제조사의 마우스나 키보드든 컴퓨터에 쉽게 연결하여 사용할 수 있는 것과 유사하다고 생각할 수 있습니다.

이번 절에서는 이 CNI가 구체적으로 어떤 역할을 하며, 어떤 종류의 CNI 플러그인들이 있는지, 그리고 K3s나 Rancher Desktop과 같은 경량 쿠버네티스 배포판에서는 어떤 CNI가 기본적으로 사용되는지 등을 자세히 살펴보겠습니다. 이를 통해 쿠버네티스 네트워킹의 실제 구현 메커니즘에 대한 이해를 한층 더 높일 수 있을 것입니다.

쿠버네티스가 “모든 파드는 고유한 IP를 가진다” 그리고 “모든 파드는 NAT 없이 다른 모든 파드와 통신 가능하다”와 같은 혁신적인 네트워킹 모델을 실제로 구현할 수 있도록 하는 숨은 주역이 바로 CNI(Container Network Interface) 플러그인입니다. CNI 플러그인은 CNI 명세(specification)를 충실히 따르도록 개발된 실행 가능한 프로그램 또는 스크립트 형태로 존재합니다. 이들은 마치 쿠버네티스라는 거대한 운영체제의 네트워크 드라이버처럼 작동하여, 컨테이너 런타임(예: containerd, CRI-O 등 파드를 실제로 실행하고 관리하는 소프트웨어)이 파드의 네트워크를 설정하거나 해제해야 할 때마다 호출되어 필요한 작업을 수행합니다.

쿠버네티스 클러스터 환경에서는 각 노드에서 실행되는 kubelet(해당 노드의 파드 생명주기를 관리하는 핵심 에이전트)이 이 CNI 플러그인과의 상호작용을 주도합니다. 새로운 파드가 특정 노드에 스케줄링되어 생성되어야 할 때, 또는 기존 파드가 삭제되어 네트워크 자원을 해제해야 할 때, kubelet은 미리 클러스터에 설정된 CNI 플러그인을 호출하여 해당 파드와 관련된 모든 네트워크 구성 작업을 위임합니다. 이러한 위임 방식 덕분에 쿠버네티스 자체는 특정 네트워크 구현 방식에 얽매이지 않고, 다양한 네트워크 환경과 요구사항에 맞춰 최적의 CNI 플러그인을 선택하여 사용할 수 있는 유연성을 확보하게 됩니다.

CNI 플러그인이 파드 네트워킹을 위해 수행하는 주요 역할들은 다음과 같이 구체적으로 정리할 수 있습니다.

1. 파드 네트워크 네임스페이스 설정 및 격리: CNI 플러그인은 가장 먼저 해당 파드만을 위한 격리된 네트워크 환경, 즉 리눅스 커널의 네트워크 네임스페이스(network namespace)를 준비하거나 이미 준비된 네임스페이스를 대상으로 작업을 시작합니다. 네트워크 네임스페이스는 각 파드가 자신만의 독립적인 네트워크 인터페이스, IP 주소, 라우팅 테이블, 방화벽 규칙 등을 가질 수 있도록 하는 핵심적인 커널 격리 기술입니다.
2. 가상 네트워크 인터페이스 생성 및 호스트 연결: 다음으로, CNI 플러그인은 이 파드의 네트워크 네임스페이스 내부에 가상 네트워크 인터페이스(예: eth0)를 생성합니다. 동시에 이 가상 인터페이스를 호스트 노드의 네트워크와 연결하는 작업을 수행하는데, 가장 널리 사용되는 방식은 가상 이더넷 페어(veth pair)를 이용하는 것입니다. veth pair는 마치 양 끝이 서로 다른 네트워크 네임스페이스에 존재하는 가상의 이더넷 케이블과 같아서, 한쪽 끝은 파드 내부에, 다른 쪽 끝은 호스트 노드의 루트 네트워크 네임스페이스에 위치하게 됩니다. 호스트 쪽에 있는 veth 끝단은 보통 CNI 플러그인이 관리하는 리눅스 브릿지(예: cni0)에 연결되어 다른 파드나 외부 네트워크와의 통로 역할을 합니다.
3. IP 주소 할당 및 구성 (IPAM 연동): CNI 플러그인은 IP 주소 관리(IP Address Management, IPAM) 로직을 통해 파드에게 할당할 고유한 IP 주소를 확보합니다. 이 IPAM 기능은 CNI 플러그인 자체에 내장되어 있을 수도 있고, host-local(각 노드에 미리 정의된 IP 대역에서 할당), dhcp(외부 DHCP 서버로부터 할당), 또는 클라우드 제공업체의 IPAM 서비스와 연동되는 별도의 IPAM 플러그인을 사용할 수도 있습니다. 할당받은 IP 주소, 서브넷 마스크, 게이트웨이 주소, 그리고 DNS 서버 정보 등은 파드 내의 가상 네트워크 인터페이스에 정확하게 설정됩니다.
4. 호스트 및 파드 라우팅 규칙 설정: CNI 플러그인은 파드가 클러스터 내의 다른 노드에 있는 파드와 통신하거나, 노드 자체 또는 클러스터 외부의 네트워크와 통신할 수 있도록 호스트 노드의 라우팅 테이블에 필요한 경로 정보를 추가합니다. 예를 들어, 특정 파드 IP 대역으로 향하는 트래픽은 해당 파드가 위치한 노드의 CNI 브릿지나 터널 인터페이스로 전달되도록 설정합니다. 또한, 파드 내부의 라우팅 테이블도 기본 게이트웨이 등을 올바르게 설정하여 외부로 향하는 트래픽이 적절히 처리되도록 합니다.
5. 네트워크 정책 적용 (선택적 고급 기능): Calico, Cilium, Weave Net과 같이 더 고급 기능을 제공하는 CNI 플러그인들은 쿠버네티스의 네트워크 폴리시(Network Policy) 리소스를 해석하여, iptables 규칙이나 eBPF 프로그램을 통해 파드 간의 네트워크 통신을 선택적으로 허용하거나 차단하는 보안 기능을 함께 제공합니다. 이는 마이크로서비스 환경에서 제로 트러스트 보안 모델을 구현하는 데 매우 중요한 역할을 합니다.
6. 기타 부가적인 네트워크 기능 제공: CNI 플러그인의 종류에 따라 오버레이 네트워크(Overlay Network) 구성, 네트워크 트래픽 암호화(예: IPsec), 서비스 로드 밸런싱과의 통합, 멀티캐스트 지원 등 다양한 추가적인 네트워크 기능을 제공하여 특정 요구사항을 충족시킬 수도 있습니다.

이처럼 CNI 플러그인은 쿠버네티스의 추상적인 네트워킹 모델(예: “IP-per-Pod”)을 실제 워커 노드에서 동작하는 구체적인 네트워크 패브릭(network fabric)으로 구현하는 매우 핵심적인 역할을 담당합니다. 시장에는 다양한 종류의 CNI 플러그인이 존재하며, 각각 서로 다른 기술 스택, 아키텍처, 그리고 장단점을 가지고 있어, 클러스터가 운영될 환경(온프레미스, 퍼블릭 클라우드, 엣지 등), 요구되는 네트워크 성능 수준, 보안 정책의 복잡성, 운영 편의성 등을 종합적으로 고려하여 가장 적절한 플러그인을 선택하는 것이 매우 중요합니다. 대표적으로 널리 사용되거나 주목받는 CNI 플러그인들의 특징은 다음과 같습니다.

• CoreOS(현재는 Red Hat의 일부)에서 개발한 CNI 플러그인으로, 단순성과 설정 용이성을 최우선으로 합니다. 주로 소규모 클러스터나 학습용 환경, 또는 복잡한 네트워크 정책이 필요 없는 단순한 파드 간 통신 요구사항을 가진 환경에 적합합니다.
• 가장 일반적인 동작 방식은 VXLAN(Virtual Extensible LAN) 터널링 기술을 사용하여 노드 간에 가상의 L2 오버레이 네트워크를 구축하는 것입니다. 이 가상 네트워크 위에 파드들이 배치되어 서로 통신하게 됩니다. VXLAN은 UDP 패킷으로 원래의 이더넷 프레임을 캡슐화하여 전송하므로, 기존 L3 네트워크 인프라 위에서도 L2 연결성을 제공할 수 있습니다. Flannel은 etcd나 쿠버네티스 API 서버를 백엔드 스토어로 사용하여 각 노드에 할당된 파드 IP 대역(CIDR) 정보와 서브넷 정보를 공유하고, 이를 바탕으로 라우팅 정보를 관리합니다.
• 장점으로는 쉬운 설치와 운영을 들 수 있지만, VXLAN 캡슐화 및 역캡슐화 과정에서 약간의 성능 오버헤드가 발생할 수 있습니다. 또한, Flannel 자체적으로는 쿠버네티스 네트워크 폴리시 기능을 제공하지 않기 때문에, 네트워크 보안이 중요한 환경에서는 Calico와 같은 다른 솔루션과 함께 사용(예: Canal 프로젝트)되거나 다른 CNI로 대체되기도 합니다.

• Tigera사에서 주도적으로 개발하고 있는 CNI 플러그인으로, 고성능, 고확장성, 그리고 강력한 네트워크 보안 기능을 특징으로 합니다. 대규모 프로덕션 환경에서 널리 채택되고 있습니다.
• Calico의 핵심 철학은 가능한 한 오버레이 네트워크를 사용하지 않고, 순수한 L3 라우팅을 기반으로 파드 네트워킹을 구현하는 것입니다 (물론, 필요에 따라 VXLAN이나 IP-in-IP와 같은 오버레이 모드도 지원합니다). 각 쿠버네티스 노드를 마치 하나의 라우터처럼 동작하도록 설정하고, BGP(Border Gateway Protocol) 라는 표준 라우팅 프로토콜을 사용하여 각 노드가 자신이 관리하는 파드 IP 대역에 대한 라우팅 정보를 클러스터 내의 다른 노드들과 동적으로 교환합니다. 이를 통해 패킷 캡슐화로 인한 오버헤드 없이 매우 높은 네트워크 성능을 달성할 수 있으며, 기존 데이터센터 네트워크와의 통합도 용이합니다.
• Calico의 가장 큰 강점 중 하나는 매우 강력하고 유연한 네트워크 폴리시(Network Policy) 엔진을 자체적으로 제공한다는 점입니다. iptables 규칙이나 최신 리눅스 커널의 eBPF 기술을 활용하여, 파드 간의 통신을 L3/L4 레벨에서 매우 세밀하게 제어하고, 다양한 보안 정책을 적용할 수 있습니다. 이는 제로 트러스트 보안 모델을 구현하려는 기업들에게 매우 매력적인 기능입니다.
• 초기 구성 시 BGP 설정 등이 Flannel에 비해 다소 복잡하게 느껴질 수 있지만, 일단 구성되고 나면 대규모 클러스터에서도 안정적이고 효율적인 네트워킹과 강력한 보안 기능을 제공합니다.

• Weaveworks사에서 개발한 CNI 플러그인으로, 사용 편의성, 다양한 기능 제공, 그리고 서비스 메시와의 통합을 목표로 합니다.
• 기본적으로는 VXLAN과 유사한 자체 캡슐화 프로토콜(Sleeve 모드)을 사용하는 오버레이 네트워크를 구성하여 파드 간 통신을 지원합니다. 하지만 캡슐화 없이 더 빠른 통신 성능을 원하는 사용자를 위해 암호화되지 않은 “fast datapath” 모드나, IPsec ESP(Encapsulating Security Payload) 프로토콜을 사용하여 네트워크 트래픽을 암호화하는 보안 강화 모드도 함께 제공합니다.
• Weave Net은 기본적인 파드 네트워킹 기능 외에도 쿠버네티스 네트워크 폴리시 지원, 내장된 간단한 서비스 디스커버리 기능, 멀티캐스트 트래픽 지원 등 다양한 부가 기능을 제공합니다. 또한, 직관적인 시각화 및 관리 도구인 Weave Scope와 함께 사용될 때 클러스터 네트워크 상태를 파악하고 문제를 해결하는 데 큰 도움을 줄 수 있습니다.
• 설정이 비교적 간편하고 다양한 기능을 제공하여 중소 규모의 클러스터나 개발 환경에서 유용하게 활용될 수 있습니다.

• 최근 클라우드 네이티브 생태계에서 가장 주목받고 있는 CNI 플러그인 중 하나로, 리눅스 커널의 혁신적인 기술인 **eBPF(extended Berkeley Packet Filter)**를 매우 적극적으로 활용하여 기존 CNI 솔루션들의 한계를 극복하고 고성능 네트워킹, 강력하고 유연한 보안(네트워크 폴리시, API 레벨 가시성), 그리고 서비스 메시 기능과의 깊이 있는 통합을 제공합니다.
• eBPF는 커널 코드를 직접 수정하거나 재컴파일하지 않고도, 사용자가 작성한 프로그램을 커널 내의 특정 이벤트(예: 네트워크 패킷 수신/송신, 시스템 콜 발생)에 연결하여 실행할 수 있게 해주는 매우 강력한 기술입니다. Cilium은 이 eBPF를 활용하여 커널 데이터 경로(datapath)에서 직접 네트워크 패킷을 효율적으로 처리하고, 보안 정책을 적용하며, 서비스 라우팅을 수행합니다. 이는 전통적인 iptables 기반의 네트워크 폴리시나 서비스 프록시 방식보다 훨씬 더 뛰어난 성능과 낮은 지연 시간을 제공하며, 훨씬 더 세밀하고 동적인 제어가 가능하게 합니다.
• Cilium은 오버레이 네트워크 모드(VXLAN, Geneve)와 직접 라우팅(네이티브 라우팅) 모드를 모두 지원하며, L3/L4 레벨의 네트워크 폴리시뿐만 아니라 HTTP, gRPC, Kafka와 같은 L7(애플리케이션 계층) 프로토콜까지 인지하여 API 호출 단위의 보안 정책을 적용하거나 트래픽 가시성을 확보하는 고급 기능을 제공합니다. 또한, Envoy 프록시와의 통합을 통해 서비스 메시 기능을 지원하기도 합니다.
• 고성능, 최신 보안 기능, 서비스 메시와의 긴밀한 통합 등을 원하는 현대적인 클라우드 네이티브 애플리케이션 환경에 매우 적합한 솔루션으로 평가받고 있습니다. 다만, eBPF 기능을 온전히 활용하기 위해서는 상대적으로 최신 버전의 리눅스 커널(보통 4.9 이상)이 필요하다는 전제 조건이 있을 수 있습니다.

위에 언급된 플러그인들 외에도, Antrea(VMware 주도, Open vSwitch 기반), Kube-router(BGP 및 LVS/IPVS 기반 라우팅 및 서비스 프록시), 그리고 각 주요 퍼블릭 클라우드 제공업체들이 자사의 클라우드 네트워킹 환경(예: AWS VPC, Azure VNet, Google Cloud VPC)과 최적으로 통합되도록 직접 개발하여 제공하는 CNI 플러그인들(예: AWS VPC CNI, Azure CNI, Google GKE CNI (GCE 라우팅 또는 VPC 네이티브 모드))도 널리 사용되고 있습니다. 이러한 클라우드 제공업체 CNI들은 해당 클라우드의 네이티브 기능(예: VPC 라우팅 규칙, 보안 그룹, 보조 IP 주소 할당)을 최대한 활용하여 파드 네트워킹을 구현하므로, 해당 클라우드 환경에서는 가장 자연스럽고 효율적인 선택이 될 수 있습니다.

참고 사항:

• 위 표는 각 CNI 플러그인의 일반적인 특징을 요약한 것이며, 특정 버전이나 설정에 따라 세부 사항은 달라질 수 있습니다.
• 성능은 실제 네트워크 환경, 하드웨어, 워크로드 특성에 따라 크게 달라질 수 있으므로, 실제 환경에서 벤치마킹하는 것이 중요합니다.
• 운영 복잡성은 팀의 기술 수준과 경험에 따라 주관적일 수 있습니다.
• 새로운 기능들이 지속적으로 추가되고 개선되고 있으므로, 각 CNI 플러그인의 최신 공식 문서를 항상 참조하는 것이 좋습니다.
• 클라우드 제공업체(AWS, Azure, GCP 등)는 자사 환경에 최적화된 자체 CNI 플러그인을 제공하며, 이들은 위 표에 언급된 오픈소스 CNI와는 다른 특징을 가질 수 있습니다.

결론적으로, 어떤 CNI 플러그인을 선택하느냐는 쿠버네티스 클러스터의 전반적인 네트워크 성능, 제공되는 기능의 범위(예: 네트워크 폴리시, 암호화), 보안 수준, 그리고 운영의 복잡성에 큰 영향을 미칩니다. 따라서 클러스터를 구축하거나 운영하는 관리자는 자신의 환경과 애플리케이션의 특성, 그리고 팀의 기술적 역량 등을 종합적으로 고려하여 가장 적합한 CNI 플러그인을 신중하게 선택하고 구성해야 합니다.

쿠버네티스의 강력한 기능과 유연성은 때로는 처음 접하는 사용자나 로컬 개발 환경을 신속하게 구축하려는 개발자에게는 다소 높은 진입 장벽으로 느껴질 수 있습니다. 특히, CNI(Container Network Interface) 플러그인을 직접 선택하고, 각 노드에 필요한 네트워크 구성을 처음부터 설정하는 작업은 상당한 전문 지식과 시간을 요구할 수 있습니다. 다행히도, 이러한 사용자의 부담을 덜어주고 쿠버네티스 경험을 훨씬 더 간편하게 만들어주는 K3s나 Rancher Desktop과 같은 경량 쿠버네티스 배포판들이 등장했습니다. 이들 도구는 기본적으로 CNI 플러그인을 내장하거나, 사용자가 복잡한 네트워크 설정 과정 없이도 즉시 쿠버네티스 클러스터를 시작하고 파드 네트워킹을 사용할 수 있도록 지원하는 데 중점을 두고 있습니다.

이러한 사용자 친화적인 접근 방식은 개발자들이 네트워킹의 복잡한 내부 구현에 신경 쓰기보다는, 애플리케이션 개발과 쿠버네티스의 핵심 개념 학습에 더 집중할 수 있도록 돕습니다. 이제 대표적인 경량 쿠버네티스 배포판인 K3s와 Rancher Desktop이 어떤 방식으로 CNI를 처리하는지 자세히 살펴보겠습니다.

• Rancher Labs(현재는 글로벌 오픈소스 기업인 SUSE의 일부)에서 개발하고 CNCF(Cloud Native Computing Foundation)로부터 공식 인증을 받은 경량 쿠버네티스 배포판인 K3s는, 그 이름에서 알 수 있듯이 쿠버네티스(흔히 k8s로 축약)의 핵심 기능을 유지하면서도 설치 크기와 리소스 사용량을 대폭 줄여(약 100MB 미만의 단일 바이너리로 제공) 엣지 컴퓨팅, IoT 디바이스, CI/CD 파이프라인, 그리고 개발 및 테스트 환경 등 다양한 시나리오에서 매우 빠르고 간편하게 쿠버네티스 클러스터를 구축할 수 있도록 설계되었습니다.
• K3s의 가장 큰 특징 중 하나는 “배터리 포함(batteries-included)” 철학입니다. 즉, 사용자가 쿠버네티스를 실행하기 위해 필요한 핵심 구성 요소들을 대부분 내장하고 있거나 기본값으로 제공합니다. CNI 플러그인 역시 이러한 철학에 따라, K3s는 기본적으로 Flannel(플란넬) CNI 플러그인을 내장하여 사용합니다. 따라서 사용자가 K3s 서버(마스터 노드)와 에이전트(워커 노드)를 설치하고 클러스터를 구성하면, 별도의 CNI 설치나 복잡한 네트워크 설정 과정 없이도 Flannel이 자동으로 각 노드에 배포되고 구성되어 파드 네트워킹이 즉시 활성화됩니다. Flannel은 앞서 설명했듯이 VXLAN(Virtual Extensible LAN) 터널링 기술을 주로 사용하여 노드 간에 가상의 L2 오버레이 네트워크를 구축하고, 이 위에 파드들이 배치되어 서로 통신할 수 있도록 합니다. Flannel의 이러한 단순성과 상대적으로 쉬운 설정은 K3s가 추구하는 경량성과 사용 편의성에 매우 잘 부합하는 선택이라고 할 수 있습니다.
• 물론, K3s는 유연성을 포기하지 않았습니다. 사용자는 필요에 따라 K3s를 설치할 때 –flannel-backend=none과 같은 옵션을 사용하여 기본 Flannel CNI를 비활성화하고, 이후에 자신이 선호하는 다른 CNI 플러그인(예: Calico, Cilium, Weave Net 등)을 수동으로 설치하여 사용할 수도 있습니다. 또한, Flannel의 백엔드 모드(VXLAN, host-gw 등)를 변경하거나 특정 설정을 커스터마이징할 수 있는 옵션도 제공합니다. 하지만 대부분의 일반적인 사용 사례, 특히 로컬 개발이나 테스트, 소규모 클러스터 운영 환경에서는 K3s가 기본으로 제공하는 Flannel CNI만으로도 충분히 안정적이고 효율적인 파드 네트워킹 환경을 경험할 수 있습니다.

• 마찬가지로 SUSE에서 제공하는 오픈소스 데스크탑 애플리케이션인 Rancher Desktop은 Windows, macOS, Linux 운영체제 환경에서 사용자가 클릭 몇 번만으로 로컬 쿠버네티스 개발 환경과 컨테이너 관리 도구를 손쉽게 구축하고 사용할 수 있도록 지원합니다. Docker Desktop의 대안으로도 많이 고려되며, 특히 쿠버네티스 버전 선택의 유연성과 다양한 컨테이너 런타임(containerd, dockerd/moby) 지원이 장점입니다.
• Rancher Desktop은 사용자가 쿠버네티스를 실행하기 위한 내부 엔진(백엔드)으로 k3s 엔진 또는 moby/dockerd 엔진 중 하나를 선택할 수 있도록 합니다. 이 선택에 따라 내부적으로 사용되는 CNI 플러그인 및 네트워크 구성 방식이 달라질 수 있습니다.
  • k3s 엔진을 사용하는 경우: Rancher Desktop은 내부적으로 경량 리눅스 가상 머신(VM)을 실행하고, 이 VM 내에서 K3s를 구동하여 쿠버네티스 클러스터를 제공합니다. 이 경우, K3s의 기본 동작 방식과 마찬가지로 Flannel CNI 플러그인이 주로 사용되어 파드 네트워킹을 담당할 가능성이 매우 높습니다. 사용자는 별도의 CNI 설정 없이도 Rancher Desktop이 제공하는 가상화된 환경 내에서 K3s 클러스터의 파드들이 서로 원활하게 통신하는 것을 경험할 수 있습니다.
  • moby/dockerd 엔진을 사용하는 경우 (이전 Docker Desktop의 쿠버네티스 기능과 유사한 방식): 이 경우에는 Docker 자체의 네트워킹 방식과 유사하게 구성될 수 있으며, 내부적으로는 Docker Desktop이 과거에 사용했던 자체적인 CNI 구현이나, 또는 Calico와 같은 특정 CNI 플러그인이 통합되어 사용될 수 있습니다. Rancher Desktop의 버전 업데이트나 사용자의 설정(예: 네트워킹 스택 선택 옵션이 있다면)에 따라 기본 CNI는 변경될 수 있으므로, 특정 버전에 대한 정확한 정보는 공식 문서를 참조하는 것이 가장 좋습니다.
• Rancher Desktop의 핵심 가치는 사용자 편의성에 있습니다. 어떤 내부 엔진이나 CNI 플러그인을 사용하든, 최종 사용자에게는 복잡한 네트워크 설정을 감추고 “바로 사용 가능한(out-of-the-box)” 로컬 쿠버네티스 환경을 제공하는 데 초점을 맞추고 있습니다. 이를 통해 개발자들은 자신의 애플리케이션을 컨테이너화하고 쿠버네티스 환경에서 테스트하는 데 필요한 시간과 노력을 크게 줄일 수 있습니다.

이처럼 K3s나 Rancher Desktop과 같은 사용자 친화적인 쿠버네티스 배포판들은 CNI 플러그인의 복잡한 선택과 설정을 추상화하고, 대부분의 사용자에게 적합한 기본값을 제공함으로써 쿠버네티스 학습 곡선을 완만하게 만들고 개발 생산성을 향상시키는 데 크게 기여합니다. 물론, 실제 프로덕션 환경이나 특수한 네트워크 요구사항이 있는 경우에는 기본 CNI 설정에서 벗어나 더 고급 기능을 제공하거나 특정 환경에 최적화된 CNI 플러그인을 직접 선택하고 구성해야 할 필요성이 생길 수 있습니다. 하지만 로컬 개발, 테스트, 학습, 또는 소규모 프로젝트 운영과 같은 많은 시나리오에서는 이러한 도구들이 제공하는 기본 CNI 기능만으로도 충분히 만족스러운 쿠버네티스 네트워킹 경험을 얻을 수 있습니다. 이는 쿠버네티스라는 강력한 기술을 더 많은 개발자와 운영자가 쉽게 접하고 활용할 수 있도록 하는 중요한 역할을 합니다.