[EKS] AWS VPC CNI?

01. AWS EKS 네트워킹

01-1. AWS VPC CNI란?

AWS VPC CNI(Container Network Interface)는 EKS의 파드(Pod)가 워커 노드(EC2)의 ENI를 직접 공유하지 않고, 노드에 부착된 ENI의 세컨더리 IP를 매핑받아 사용할 수 있도록 하는 네트워크 플러그인이다. 이를 통해 파드는 VPC 서브넷 내에서 자체 IP를 가진 리소스처럼 동작할 수 있다. VPC CNI 방식을 사용하는 이유는 파드가 VPC 네트워크의 보안 그룹, 라우팅, 로깅 기능을 그대로 적용받을 수 있고, 별도의 오버레이 네트워크나 NAT 없이 단순하고 고성능의 통신이 가능하기 때문이다.

✅ 1. VPC CNI 특징

• Pod가 VPC 서브넷에서 직접 IP를 받아, EC2와 동일한 네트워크 모델 사용
• 보안 그룹, 라우팅 테이블, VPC Flow Logs 등 VPC 네트워크 기능을 그대로 적용 가능
• Pod와 Node는 동일한 IP 대역 할당
• Github에서 유지관리 되는 오픈소스 프로젝트

01-2. AWS VPC CNI 아키텍처 및 통신 흐름

✅ 1. VPC CNI 설치 시 EKS 아키텍처

EKS에 AWS VPC CNI를 설치하면 각 노드에 “aws-node” DaemonSet이 생성된다. 이 DaemonSet은 L-IPAM(Local IP Address Manager)와 CNI 플러그인으로 구성되며, 2개의 컴포넌트는 gRPC로 통신해 파드에 IP를 할당하거나 회수한다. L-IPAM은 워커 노드의 인스턴스(EC2) 메타 데이터를 확인해 사용 가능한 ENI와 Secondary IP를 파악한다. 그리고 이를 기반으로 Warm Pool을 만든다. Warm Pool에는 미리 확보한 Secondary IP가 저장되어 있으며, 파드가 생성될 때마다 이 중 하나를 할당한다. 단, 할당 가능한 IP 수는 무제한이 아니고, 인스턴스 유형에 따라 제한된다.

 

또한, EC2 인스턴스에 연결되는 네트워크 인터페이스(ENI)는 여러개의 프라이빗 IP 주소를 가질 수 있다. 이 IP 주소는 Slot이라는 개념에 따라 할당되며, ENI당 Slot 개수는 인스턴스 유형에 따라 제한된다. 예를 들어 ENI 하나에 4개의 Slot이 있다고 가정하면, 해당 ENI는 최대 4개의 프라이빗 IP를 가질 수 있다. 이 때, 첫 번째 Slot은 Primary IP, 나머지 Slot에 Secondary IP가 할당된다. 이러한 Secondary IP들은 L-IPAM의 Warm Pool에서 관리되며, 파드 생성 시 할당된다.

✅ 2. AWS VPC CNI 파드 IP 할당 과정

API Server → kubelet → VPC CNI → gRPC → L-IPAM → Warm Pool → Secondary IP → Pod IP

API 서버가 kubelet에 신규 파드 생성 요청을 전달하면, kubelet은 이를 VPC CNI에 넘긴다. VPC CNI는 gRPC를 통해 L-IPAM에 IP 할당을 요청하고, L-IPAM은 Warm Pool에서 사용 가능한 IP를 선택해 ENI의 빈 Slot에 Secondary IP로 매핑한다. 이후 해당 IP가 파드에 할당된다. 여러 파드가 생성될 때도 동일한 방식으로 동작하며, 모든 ENI Slot이 사용 중일 경우에는 새로운 ENI를 생성해 파드에 할당한다.

✅ 3. AWS VPC CNI 통신 흐름

┌─────────────── Pod NS ───────────────┐
│  [Pod eth0 (veth0)]                  │  ← 파드 내부 NIC (veth pair 한쪽)
└───────────────┬──────────────────────┘
                │ veth pair
                ▼
┌────────────── Node(호스트) NS ──────────────┐
│  [host veth (예: eni1234)]                  │  ← 호스트쪽 veth 이름(관례상 eniXXXX로 보일 수 있음; AWS ENI 아님)
│        │                                     │
│        ▼                                     │
│  [가상 라우터: Linux L3 라우팅/iptables]     │  ← 별도 장비 아님(커널의 포워딩/라우팅 계층)
│        │                                     │
│        ▼                                     │
│  [ENI/eth0 (AWS ENI)]                        │  ← 노드에 붙은 실제 ENI(NIC)
│    - Primary IP = 노드 IP                    │
│    - Secondary IP들 = 파드 IP들               │
└───────────────┬──────────────────────────────┘
                │
                ▼
              [VPC]

EKS의 워커 노드는 ENI와 연결된 eth0 인터페이스를 통해 VPC 네트워크에 참여하며, ENI의 Primary IP가 노드 IP가 된다. 파드는 veth0 인터페이스를 통해 노드의 ENI와 1:1로 연결되고, AWS VPC CNI는 Warm Pool에서 가져온 IP를 ENI의 Secondary IP로 파드에 할당한다. 파드 간 통신은 VPC 대역 내에서 ENI를 거쳐 직접 이루어지므로 별도의 NAT 없이 전달된다.

✅ 4. Kubernetes Calico CNI 통신 흐름

┌─────────────── Pod NS ───────────────┐
│  [Pod eth0 (veth0)]                  │
└───────────────┬──────────────────────┘
                │ veth pair
                ▼
┌────────────── Node(호스트) NS ──────────────┐
│  [host veth (예: caliXXXX)]                 │  ← 호스트쪽 veth(이름만 cali…)
│        │                                     │
│  [가상 라우터: Linux L3 라우팅/iptables]     │
│        │                                     │
│  [VXLAN(dev: vxlan.calico) 또는 tunl0(IPIP)] │  ← 캡슐화 인터페이스(오버레이)
└───────────────┬──────────────────────────────┘
                │ 캡슐화 패킷
                ▼
           [Underlay 네트워크]
                │ 디캡슐화
                ▼
┌────────────── 상대 Node(호스트) NS ──────────┐
│  [VXLAN/tunl0] → [가상 라우터] → [host veth] │
└───────────────┬──────────────────────────────┘
                │ veth pair
                ▼
          [목표 Pod eth0 (veth0)]

3대의 워커 노드와 5개의 파드가 있다고 가정한다. 각 파드는 가상 인터페이스로 연결되고, 이는 가상 라우터를 통해 Linux Networking을 구성한다. Calico는 파드와 노드가 서로 다른 IP 대역을 사용하므로 기본적으로 직접 통신이 불가능하다. 따라서 VXLAN이나 IP-in-IP 같은 오버레이 네트워크를 사용해 패킷을 전달하며, 이 과정에서 기존 패킷 위에 추가적인 IP 헤더를 씌워 캡슐화한다.

01-3. AWS VPC CNI 구성의 최대 파드 개수

VPC CNI를 통해 파드를 생성할 경우, 워커 노드에 할당할 수 있는 최대 파드 개수는 인스턴스 유형에 따라 달라진다. 인스턴스 유형별로 최대 파드 개수가 달라지는 이유는, 유형에 따라 최대 할당할 수 있는 ENI 개수가 달라지고, 해당 ENI별 할당 Slot 개수가 달라지기 때문이다. 또한, 최대 파드 수를 계산하는 기준은 ENI Slot에 어떤 방식으로 IP를 할당하느냐에 따라 달라진다. AWS VPC CNI는 기본적으로 ENI Secondary Slot에 IP를 할당하고, 파드에 해당 IP를 직접 할당하는 구조다.

✅ 1. Secondary IPv4 Address

계산식 : Max Pods = ENI 수 * (ENI 당 지원하는 IPv4 수 - 1) + 2

• ENI 별로 첫 번째 IP는 Primary 주소로 파드에 할당 불가능
• 노드 별로 구성되는 aws-node와 kube-proxy 파드 2대를 포함하여 산정
  • 위 파드들은 노드의 Primary IP를 동일하게 사용, 수량 계산에서 제외

✅ 2. m5.large 기반 예시

1. 최대 ENI 수 : 3
2. ENI 당 Slot 수 : 10
3. Secondary IP를 ENI당 9개씩 할당 가능
   1. 3 * (10 - 1) + 2 = 29
   2. ENI(3개) * Secondary IP(9개) = 29개

✅ 3. IPv4 Prefix Delegation

계산식 : Max Pods = ENI 수 * (ENI 당 지원하는 IPv4 수 - 1) * 16

• 이러한 최대 파드 생성 제약을 완화하기 위해 21년 8월에 IP Prefix Delegation 방식이 추가
• 해당 방식은 ENI의 각 Slot에 하나의 IP를 할당하는 방식이 아닌, /28 크기의 IP Prefix 대역을 할당하는 구조
• IP Prefix Delegation 방식은 Nitro System 계열의 인스턴스만 사용 가능
• vCPU 30개 미만은 110개로 제한, vCPU 30개 이상은 250개 최대 파드 생성 가능
• kubectl 명령으로 IPv4 Prefix Delegation 활성화 필요

✅ 4. m5.large 기반 예시

1. 최대 ENI 수 : 3
2. ENI 당 Slot 수 : 10
3. /28 할당하면 16개의 IP 사용 가능
   1. 3 * (10 - 1) * 16 = 432
   2. ENI(3개) * Secondary IP(9개) * 사용가능 IP 개수(16) = 432

99. 참고 자료

[EKS] Amazon VPC CNI란? EKS에서의 VPC CNI

Amazon VPC CNI 아키텍처와 통신 흐름 | CloudNet@ - Amazon EKS 기본 강의