이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

쿠버네티스는 매우 유연하고 확장 가능한 플랫폼이지만, 그 위에 애플리케이션들이 안정적으로 동작하고 서로 원활하게 통신하기 위해서는 몇 가지 기본적인 네트워킹 규칙이 반드시 지켜져야 합니다. 쿠버네티스는 특정 네트워크 구현 기술을 강제하지 않는 대신, 모든 쿠버네티스 클러스터가 만족해야 하는 근본적인 네트워킹 모델과 요구사항을 정의하고 있습니다. 이러한 요구사항들은 마치 잘 설계된 도시의 기본 도로 규칙과 같아서, 어떤 종류의 차량(애플리케이션)이든 이 규칙만 따르면 목적지까지 안전하고 효율적으로 도달할 수 있도록 보장합니다.

이러한 기본 모델을 이해하는 것은 쿠버네티스 네트워킹의 복잡성을 헤쳐나가는 데 있어 매우 중요합니다. 왜냐하면 이 모델이 바로 서비스(Service), 인그레스(Ingress) 등과 같은 상위 레벨의 네트워킹 추상화가 동작하는 기반이 되기 때문입니다. 만약 이 기본 전제가 충족되지 않는다면, 쿠버네티스의 많은 기능들이 예상대로 동작하지 않을 수 있습니다.

이제 쿠버네티스가 제시하는 핵심적인 네트워킹 요구사항 및 모델이 무엇인지 하나씩 자세히 살펴보겠습니다.

쿠버네티스 네트워킹 모델을 떠받치는 가장 근본적이면서도 핵심적인 원칙은 바로 클러스터 내에서 실행되는 모든 파드(Pod)가 자신만의 고유한 IP 주소를 가져야 한다는 것입니다. 이는 마치 현실 세계에서 우리 각자가 유일무이한 집 주소를 부여받는 것과 같습니다. 이 IP 주소는 파드라는 독립된 실행 환경의 ‘네트워크 신분증’ 역할을 하며, 파드 내부에 포함된 하나 또는 그 이상의 컨테이너들이 이 IP 주소를 공유하여 외부 세계, 즉 다른 파드나 노드와 통신하는 데 사용됩니다. 이 고유한 IP 덕분에 각 파드는 네트워크 상에서 명확히 식별될 수 있으며, 이는 복잡한 분산 시스템을 구성하는 데 있어 매우 중요한 기초가 됩니다.

전통적인 컨테이너 기술, 예를 들어 도커(Docker)의 초기 네트워킹 방식에서는 종종 컨테이너들이 실행되는 호스트 머신의 IP 주소를 공유하고, 각 컨테이너 서비스는 호스트의 특정 포트를 컨테이너 내부 포트와 매핑하는 방식(포트 매핑)을 통해 외부와 통신했습니다. 하지만 이러한 접근 방식은 몇 가지 본질적인 문제점을 안고 있었습니다. 가장 대표적인 것이 포트 충돌(port conflict) 문제입니다. 만약 하나의 호스트 머신에서 여러 컨테이너가 동일한 포트 번호(예: 웹 서비스의 기본 포트인 80번)를 사용하려고 하면, 어떤 컨테이너가 해당 포트를 선점해야 할지 결정하기 어렵고, 결국 동시에 서비스를 제공할 수 없게 됩니다. 또한, 애플리케이션 개발자 입장에서는 자신의 애플리케이션이 어떤 IP 주소와 포트 번호로 외부에 노출될지 미리 알기 어렵거나, 동적으로 할당되는 포트를 관리해야 하는 등 개발 및 운영상의 복잡성이 증가했습니다.

쿠버네티스는 이러한 전통적인 방식의 복잡성과 제약 사항을 해결하기 위해 혁신적인 “IP-per-Pod” 모델을 채택했습니다. 이 모델의 핵심은 각 파드에게 마치 독립적인 물리적 머신이나 가상 머신(VM)처럼 클러스터 네트워크 내에서 직접 라우팅 가능한 고유한 IP 주소를 할당하는 것입니다. 이 덕분에 개발자들은 더 이상 애플리케이션 코드 내에서 다른 서비스와의 포트 충돌을 걱정하거나, 복잡한 포트 매핑 설정을 고민할 필요가 없어졌습니다. 각 파드는 자신만의 독립된 네트워크 환경(네트워크 네임스페이스)을 가지므로, 파드 A의 컨테이너가 80번 포트에서 서비스를 제공하고, 동시에 파드 B의 컨테이너도 80번 포트에서 서비스를 제공하더라도 서로 다른 고유 IP 주소를 사용하기 때문에 아무런 충돌 없이 정상적으로 동작할 수 있습니다. 이는 마치 각 파드가 자신만의 네트워크 인터페이스 카드(NIC)를 가진 별개의 컴퓨터처럼 동작한다고 가정하고 애플리케이션을 설계하고 배포할 수 있게 해줍니다.

그렇다면 이처럼 각 파드에게 고유한 IP 주소를 할당하고, 파드 간 통신이 가능하도록 네트워크 환경을 구성하는 마법은 어떻게 일어나는 것일까요? 바로 이 지점에서 컨테이너 네트워크 인터페이스(Container Network Interface, CNI)의 역할이 매우 중요해집니다. CNI는 쿠버네티스가 특정 네트워크 구현 기술에 종속되지 않고, 다양한 네트워크 솔루션(CNI 플러그인)들과 유연하게 통합되어 파드 네트워킹을 구성할 수 있도록 하는 표준화된 인터페이스 명세(specification)입니다. 쿠버네티스 클러스터를 처음 구축할 때, 클러스터 관리자는 Flannel, Calico, Weave Net, Cilium 등과 같이 다양한 CNI 플러그인 중 하나를 선택하여 설치합니다. 일단 설치되면, 이 CNI 플러그인이 클러스터 내의 각 노드에서 다음과 같은 핵심적인 작업을 수행하여 “IP-per-Pod” 모델을 현실로 만듭니다.

1. 파드 네트워크 네임스페이스 생성 및 격리: 새로운 파드가 특정 노드에 스케줄링되면, 해당 노드의 kubelet (노드 에이전트)은 가장 먼저 파드를 위한 격리된 네트워크 환경, 즉 리눅스 네트워크 네임스페이스(network namespace)를 생성합니다. 네트워크 네임스페이스는 각 파드가 자신만의 독립적인 네트워크 스택(IP 주소, 라우팅 테이블, 방화벽 규칙 등)을 가질 수 있도록 하는 커널 수준의 격리 기술입니다.
2. 가상 네트워크 인터페이스 생성 및 연결: kubelet은 CNI 플러그인을 호출합니다. 호출된 CNI 플러그인은 먼저 파드의 네트워크 네임스페이스와 호스트 노드의 네트워크를 연결하기 위한 가상 네트워크 인터페이스를 생성합니다. 가장 일반적인 방식은 가상 이더넷 페어(virtual Ethernet pair, veth pair)를 사용하는 것입니다. veth pair는 마치 파이프처럼 양 끝단이 있는 가상 케이블로, 한쪽 끝은 파드의 네트워크 네임스페이스 내부에 위치하여 파드의 기본 네트워크 인터페이스(예: eth0)가 되고, 다른 쪽 끝은 호스트 노드의 루트 네트워크 네임스페이스에 남아 특정 네트워크 브리지(예: cni0 또는 docker0와 유사한 CNI 관리 브리지)에 연결됩니다.
3. 파드 IP 주소 할당 (IPAM 연동): CNI 플러그인은 IP 주소 관리(IP Address Management, IPAM) 기능을 담당하는 로직(때로는 별도의 IPAM 플러그인)을 통해 해당 파드에 할당할 고유 IP 주소를 가져옵니다. 이 IP 주소는 보통 각 노드별로 미리 할당된 파드 IP 대역(Pod CIDR)에서 동적으로 할당됩니다. 할당된 IP 주소와 서브넷 마스크, 게이트웨이 정보 등은 파드 내의 가상 네트워크 인터페이스(eth0)에 설정됩니다.
4. 라우팅 규칙 설정: CNI 플러그인은 호스트 노드의 라우팅 테이블을 적절히 업데이트하여, 다른 노드나 외부에서 이 파드의 IP 주소로 향하는 트래픽이 올바르게 해당 파드의 가상 네트워크 인터페이스로 전달될 수 있도록 합니다. 또한, 파드에서 외부로 나가는 트래픽(예: 다른 파드, 다른 노드, 또는 인터넷)도 적절한 경로를 통해 라우팅될 수 있도록 설정합니다. 만약 오버레이 네트워크(overlay network, 예: Flannel의 VXLAN 모드)를 사용하는 CNI 플러그인이라면, 노드 간 파드 통신을 위해 패킷 캡슐화(encapsulation) 및 터널링(tunneling)과 관련된 설정도 이 단계에서 이루어질 수 있습니다.

이처럼 CNI 플러그인은 kubelet과의 긴밀한 협력을 통해, 보이지 않는 곳에서 복잡한 네트워크 설정 작업들을 자동으로 수행하여 쿠버네티스의 “IP-per-Pod”라는 단순하고 강력한 네트워킹 모델을 실현합니다. CNI 표준 덕분에 쿠버네티스 생태계는 특정 네트워크 벤더나 기술에 얽매이지 않고, 다양한 환경(온프레미스, 클라우드)과 요구사항(성능, 보안, 기능)에 최적화된 수많은 네트워크 솔루션들을 유연하게 선택하고 활용할 수 있는 개방성을 갖추게 되었습니다. “모든 파드는 고유한 IP를 가진다”는 이 원칙은 쿠버네티스 네트워킹의 다른 모든 추상화된 개념들, 예를 들어 서비스(Service)나 네트워크 폴리시(Network Policy) 등이 올바르게 동작하기 위한 가장 기본적인 전제 조건이자 출발점이라고 할 수 있습니다.

쿠버네티스 네트워킹 모델이 추구하는 또 하나의 핵심적인 요구사항은 바로 클러스터 내에서 실행되는 모든 파드(Pod)가 특별한 주소 변환(Network Address Translation, NAT) 과정 없이 다른 모든 파드와 직접적으로 통신할 수 있어야 한다는 원칙입니다. 이는 마치 같은 도시 안에 있는 모든 집들이 서로의 정확한 주소만 알고 있다면, 중간에 다른 주소로 바꿔주는 중개자(NAT 게이트웨이) 없이도 직접 편지를 주고받거나 서로 방문할 수 있는 것과 같은 이상적인 통신 환경을 의미합니다. 즉, 파드 A가 파드 B에게 메시지를 보낼 때, 파드 A는 파드 B의 실제 IP 주소를 목적지로 하여 패킷을 전송하며, 이 패킷이 네트워크를 통과하는 동안 출발지나 목적지 IP 주소가 변경되지 않아야 합니다. 마찬가지로, 메시지를 수신한 파드 B는 패킷의 출발지 IP 주소를 보고 그것이 실제로 파드 A의 IP 주소임을 신뢰할 수 있어야 합니다.

이러한 ‘NAT 없는 파드 간 직접 통신’ 모델은 전통적인 가상 머신(VM) 환경이나 일부 초기 컨테이너 네트워킹 방식과는 뚜렷한 대조를 이룹니다. 이전 환경에서는 각 VM이나 컨테이너 그룹이 자신만의 격리된 사설 네트워크 대역을 가지고, 외부 네트워크(다른 VM 그룹이나 인터넷)와 통신할 때는 경계에 위치한 게이트웨이 장비를 통해 IP 주소를 공인 IP 주소로 변환하는 NAT 과정을 거치는 경우가 많았습니다. 이러한 NAT는 제한된 공인 IP 주소를 효율적으로 사용하거나 내부 네트워크 구조를 숨기는 데는 유용할 수 있지만, 동시에 여러 가지 복잡성과 문제점을 야기했습니다. 예를 들어, NAT는 통신 경로를 파악하기 어렵게 만들고, 애플리케이션이 자신이 외부로 통신할 때 사용되는 실제 IP 주소를 알 수 없게 만들며(이는 특정 프로토콜이나 서비스 등록 과정에서 문제를 일으킬 수 있습니다), 특히 패킷의 실제 출발지 IP 주소가 가려지기 때문에 소스 IP 주소를 기반으로 하는 정교한 보안 정책이나 접근 제어 규칙을 적용하기 어렵게 만드는 단점이 있었습니다.

쿠버네티스는 이러한 복잡성을 근본적으로 제거하고, 개발자와 운영자가 애플리케이션의 네트워크 통신을 보다 직관적이고 단순하게 이해하고 관리할 수 있도록 하기 위해, 클러스터 내의 모든 파드가 마치 하나의 거대하고 평평한(flat) 네트워크 공간에 존재하는 것처럼 동작하도록 하는 모델을 지향합니다. 이 모델에서는 다음과 같은 통신 흐름이 보장됩니다.

• 파드 A가 파드 B와 통신 시: 파드 A는 파드 B의 고유한 파드 IP 주소를 목적지로 설정하여 네트워크 패킷을 전송합니다. 이 패킷은 클러스터 네트워크를 통해 파드 B에게 직접 전달되며, 이 과정에서 IP 주소 변환은 발생하지 않습니다.
• 출발지 IP 주소 보존: 파드 B가 수신한 패킷의 출발지 IP 주소는 파드 A의 실제 파드 IP 주소와 동일합니다. 이를 통해 파드 B는 요청을 보낸 상대를 정확히 식별할 수 있습니다.

이러한 “NAT 없는 파드 간 통신” 모델은 쿠버네티스 환경에서 다음과 같은 매우 중요한 장점들을 제공합니다.

1. 개발 및 운영의 단순성: 개발자들은 더 이상 애플리케이션 코드 내에서 복잡한 NAT 규칙이나 동적인 포트 포워딩을 고려할 필요가 없습니다. 마치 동일한 로컬 네트워크(LAN) 내의 물리적인 서버들이 서로 IP 주소를 통해 직접 통신하는 것처럼, 파드 간 통신 로직을 단순하고 명확하게 구현할 수 있습니다. 이는 특히 마이크로서비스 아키텍처와 같이 다수의 작은 서비스들이 서로 빈번하게 상호작용해야 하는 환경에서 개발 생산성을 크게 향상시킵니다.
2. 애플리케이션 이식성 향상: 애플리케이션을 로컬 개발 환경(예: Minikube, kind)에서 실제 운영 환경의 쿠버네티스 클러스터로 이전하거나, 서로 다른 클라우드 제공업체의 쿠버네티스 서비스 간에 마이그레이션할 때, 네트워크 구성 변경으로 인한 애플리케이션 수정의 필요성이 크게 줄어듭니다. 파드 IP가 직접 라우팅 가능한 환경은 애플리케이션의 이식성을 높여줍니다.
3. 서비스 디스커버리의 효율성 증대: 쿠버네티스의 서비스 디스커버리 메커니즘(예: CoreDNS를 통한 클러스터 내부 DNS)은 일반적으로 서비스의 이름에 해당하는 파드들의 실제 IP 주소 목록을 반환합니다. NAT가 없는 환경에서는 클라이언트(다른 파드)가 이 IP 주소들을 직접 사용하여 해당 서비스의 파드들에게 요청을 보낼 수 있으므로, 서비스 디스커버리 과정이 훨씬 간단하고 효율적으로 이루어집니다.
4. 정교한 소스 IP 기반 정책 적용 가능: 네트워크 보안 정책(Network Policy)이나 방화벽 규칙을 설정할 때, 패킷의 실제 출발지 IP 주소가 변조되지 않고 그대로 전달되기 때문에, 특정 파드나 파드 그룹으로부터의 접근을 허용하거나 차단하는 등의 소스 IP 기반 보안 정책을 보다 정확하고 신뢰성 있게 적용할 수 있습니다. 이는 제로 트러스트(Zero Trust) 네트워크 보안 모델을 구현하는 데 중요한 기반이 됩니다.

이러한 이상적인 플랫 네트워크 모델을 현실로 만들기 위해, 앞서 언급된 CNI(Container Network Interface) 플러그인들은 다양한 네트워킹 기술들을 활용합니다. 예를 들어,

• 오버레이 네트워크(Overlay Network): Flannel (VXLAN 모드), Weave Net, Canal (Flannel + Calico) 등은 각 노드 간에 가상 터널(예: VXLAN, IP-in-IP)을 생성하여, 노드 물리 네트워크 위에 논리적인 파드 네트워크를 구축합니다. 이를 통해 서로 다른 노드에 있는 파드들이라도 마치 동일한 L2 네트워크에 있는 것처럼 직접 통신할 수 있게 됩니다.
• L3 라우팅 기반 네트워크: Calico (BGP 모드), kube-router 등은 각 노드를 라우터로 간주하고 BGP(Border Gateway Protocol)와 같은 라우팅 프로토콜을 사용하여 파드 IP 대역에 대한 라우팅 정보를 클러스터 내의 다른 노드들과 교환합니다. 이를 통해 파드 간 통신 시 별도의 캡슐화 없이 직접 라우팅이 가능해져 성능상 이점을 가질 수 있습니다.
• 클라우드 제공업체 통합 CNI: AWS VPC CNI, Azure CNI, Google GKE CNI 등은 클라우드 플랫폼이 제공하는 기본 네트워킹 기능(예: VPC 라우팅, 보조 IP 할당)과 직접 통합되어 파드 네트워킹을 구현합니다. 이 경우 파드 IP는 클라우드 VPC 네트워크 내에서 직접 라우팅 가능한 IP 주소가 됩니다.

어떤 CNI 플러그인과 기술을 사용하든지 간에, 쿠버네티스가 요구하는 최종 목표는 명확합니다. 바로 클러스터 내의 모든 파드가 서로의 실제 파드 IP 주소를 통해 어떠한 주소 변환 과정도 거치지 않고 직접적으로 통신할 수 있는 환경을 제공하는 것입니다. 이 원칙은 마이크로서비스 아키텍처가 지배적인 오늘날의 클라우드 네이티브 애플리케이션 환경에서, 수많은 작은 서비스들이 서로 빠르고 안정적으로 데이터를 주고받으며 협력하여 거대한 시스템을 이루는 데 있어 핵심적인 역할을 수행합니다.

쿠버네티스 네트워킹 모델을 구성하는 세 번째 핵심 기둥은 클러스터 내의 모든 노드(Node)가 특별한 주소 변환(Network Address Translation, NAT) 과정 없이 모든 파드(Pod)와 직접적으로 통신할 수 있어야 하며, 역으로 모든 파드 또한 모든 노드와 NAT 없이 직접 통신할 수 있어야 한다는 양방향 통신 보장 원칙입니다. 이는 마치 도시의 모든 건물(파드)들이 시청, 경찰서, 소방서와 같은 주요 공공시설(노드)과 아무런 중개 없이 직접적으로 정보를 주고받거나 서비스를 요청할 수 있고, 반대로 이러한 공공시설들 또한 각 건물에 필요한 정보를 전달하거나 지원을 제공할 수 있는 원활한 소통 체계를 갖추는 것과 유사합니다. 즉, 노드와 파드는 서로에게 투명하게 네트워크적으로 접근 가능해야 합니다.

이 중요한 요구사항은 다음과 같은 두 가지 명확한 통신 흐름을 모두 포함하며, 양방향 모두에서 IP 주소 변환이 발생해서는 안 됩니다.

1. 노드에서 파드로의 직접 통신 (Node-to-Pod Communication without NAT):쿠버네티스 클러스터를 구성하는 각 노드(물리적 서버 또는 가상 머신)에서 실행되는 시스템 수준의 프로세스나 관리 에이전트(예: kubelet, 모니터링 에이전트, 로그 수집기 등)가, 자신이 속한 노드 또는 클러스터 내의 다른 노드에서 실행 중인 특정 파드의 고유한 IP 주소를 사용하여 직접적으로 네트워크 통신을 할 수 있어야 합니다. 예를 들어, kubelet은 자신이 관리하는 파드들의 상태를 주기적으로 점검(liveness/readiness probe)하거나, 파드로부터 로그를 수집해야 합니다. 또한, Prometheus와 같은 모니터링 시스템의 Node Exporter(데몬셋으로 배포된 경우)는 각 노드에서 실행되면서, 해당 노드에서 실행 중인 다른 애플리케이션 파드들의 특정 포트(예: 메트릭 노출 포트)로 접근하여 성능 지표를 수집할 수 있어야 합니다. 이러한 통신 과정에서 노드가 파드의 IP 주소로 패킷을 보낼 때, 어떠한 형태의 IP 주소 변환(SNAT 또는 DNAT)도 발생해서는 안 됩니다. 즉, 파드가 수신하는 패킷의 출발지 IP는 실제 노드의 IP 주소여야 합니다.
2. 파드에서 노드로의 직접 통신 (Pod-to-Node Communication without NAT):반대로, 파드 내에서 실행되는 애플리케이션 컨테이너가 클러스터 내의 특정 노드의 IP 주소(해당 노드 자체에 할당된 IP 주소)를 목적지로 하여 해당 노드에서 실행 중인 시스템 서비스나 다른 파드(만약 노드 IP를 통해 접근 가능한 서비스가 있다면)와 직접적으로 네트워크 통신을 할 수 있어야 합니다. 예를 들어, 파드 내 애플리케이션이 자신이 실행되고 있는 노드의 kubelet API 엔드포인트(보통 https://<노드IP>:10250)에 접근하여 특정 정보를 조회하거나, 데몬셋으로 배포된 Node Exporter와 같이 노드 IP와 특정 포트로 접근 가능한 시스템 에이전트와 통신해야 하는 경우가 있을 수 있습니다. 이러한 통신 과정에서도 파드가 노드의 IP 주소로 패킷을 보낼 때 NAT가 발생해서는 안 되며, 노드가 수신하는 패킷의 출발지 IP는 실제 파드의 IP 주소여야 합니다.

이처럼 “NAT 없는 노드-파드 간 양방향 직접 통신” 모델은 쿠버네티스 클러스터의 효율적이고 안정적인 운영을 위해 다음과 같은 중요한 이점들을 제공합니다.

• 시스템 관리의 용이성 및 투명성 향상: kubelet과 같은 쿠버네티스의 핵심 시스템 컴포넌트들이 파드의 상태를 직접 확인하고, 로그를 수집하며, 명령을 전달하는 등의 관리 작업을 훨씬 더 쉽고 직관적으로 수행할 수 있게 됩니다. IP 주소 변환으로 인한 복잡성이 없으므로 통신 경로 추적 및 문제 해결도 용이해집니다.
• CNI 플러그인 구현의 유연성 및 단순성 증대: 다양한 CNI(Container Network Interface) 플러그인들이 노드와 파드 간의 라우팅 경로를 설정할 때, 복잡한 NAT 규칙을 구성하고 관리할 필요가 없어지므로 CNI 플러그인의 구현이 상대적으로 단순해질 수 있고, 네트워크 성능 저하 요소를 줄일 수 있습니다. 이는 CNI 생태계의 다양성과 혁신을 촉진하는 데 기여합니다.
• 서비스 메쉬 및 고급 네트워킹 솔루션과의 원활한 통합: Istio, Linkerd, Cilium과 같은 서비스 메쉬 솔루션이나 고급 네트워킹 및 보안 솔루션들은 종종 파드 간 통신뿐만 아니라 파드와 노드 간의 통신 트래픽도 가로채고(intercept), 관찰하며(observe), 제어하는(control) 기능을 제공합니다. NAT가 없는 투명한 네트워크 환경은 이러한 솔루션들이 프록시(proxy)를 주입하거나 eBPF(extended Berkeley Packet Filter)와 같은 커널 수준의 기술을 활용하여 네트워크 트래픽을 효과적으로 관리하고 정책을 적용하는 것을 훨씬 더 용이하게 만듭니다.
• 호스트 네트워킹(Host Networking)과의 일관성: 일부 특수한 경우, 파드는 hostNetwork: true 설정을 통해 호스트 노드의 네트워크 네임스페이스를 직접 사용할 수 있습니다. 이러한 파드들은 노드 IP를 직접 사용하게 되는데, 일반적인 파드 네트워킹 모델에서도 노드와 파드 간 직접 통신이 가능하다는 점은 이러한 특수한 경우와의 네트워크 동작 방식의 일관성을 유지하는 데 도움이 됩니다.

이러한 중요한 요구사항 역시, 다른 기본 네트워킹 원칙들과 마찬가지로, 클러스터에 설치된 CNI 플러그인에 의해 실제로 구현됩니다. CNI 플러그인은 각 노드의 운영체제 수준에서 라우팅 테이블, 브릿지 인터페이스, 가상 이더넷 페어 등을 적절히 설정하고 관리함으로써, 노드가 특정 파드 IP 대역으로 향하는 트래픽을 해당 파드가 위치한 네트워크 인터페이스로 올바르게 전달할 수 있도록 보장합니다. 또한, 파드에서 특정 노드의 IP 주소로 향하는 트래픽 역시 별도의 변환 과정 없이 해당 노드로 직접 도달할 수 있도록 네트워크 경로를 구성합니다. 예를 들어, 노드의 기본 네트워크 인터페이스와 파드 네트워크를 연결하는 브릿지(cni0 등)를 사용하고, 이 브릿지를 통해 노드와 파드 간의 L2/L3 통신이 가능하도록 설정하거나, 필요한 경우 특정 라우팅 규칙을 추가하여 통신을 가능하게 합니다.

결론적으로, 쿠버네티스가 제시하는 이 세 가지 기본 네트워킹 요구사항들 – (1) 모든 파드는 고유 IP를 가진다, (2) 모든 파드는 NAT 없이 다른 모든 파드와 통신 가능하다, (3) 모든 노드는 NAT 없이 모든 파드와 (그리고 그 반대도) 통신 가능하다 – 은 쿠버네티스 클러스터 내에서 마치 하나의 거대하고 평평한 네트워크가 존재하는 것처럼 애플리케이션들이 서로 자유롭게 소통할 수 있는 이상적인 환경을 만드는 것을 목표로 합니다.