최근 새로운 서비스 인프라 구축을 위해 EKS 환경을 만들어주다가 Pod IP가 부족해서 고생을 한 기억이 있다.
사내 EKS 구축 가이드를 열심히 안 본 탓도 있지만 VPC CNI를 제대로 이해하지 못한 것이 더 큰 문제였다.
이번 스터디를 통해 VPC CN에 대한 깊이 있는 이해를 해보면 좋을 것 같다.
VPC CNI의 IP 할당 방식 이해
AWS VPC CNI는 다른 CNI와 근본적으로 다르다. overlay 네트워크를 만들지 않고, Pod 에 실제 VPC IP를 직접 할당한다. 그래서 Pod IP로 VPC 내 어디서든 직접 라우팅이 가능하다.
Secondary IP, Prefix Delegation, Custom Networking
Secondary IP
VPC CNI의 기본 동작 방식이다.
ENI의 Secondary IP를 하나씩 Pod에 할당한다.
VPC CNI는 Pod 스케줄링에 대비에 IP를 미리 확보해두는 Warm Pool 개념을 사용한다.
- WARM_ENI_TARGET (기본값 1) : 여유 ENI를 몇 개 확보해둘지
- WARM_IP_TARGET : 여유 IP를 몇개 확보해둘지
- MINIMUM_IP_TARGET : 최소 확보 IP 수
문제는 IP 낭비이다. WARM_ENI_TARGET=1 이면 ENI 하나를 통째로 미리 붙이기 때문에, Pod가 1개만 떠 있어도 ENI 하나 분량의 IP가 예약된다. (ENI 하나 분량의 IP는 인스턴스의 종류 별로 다르다.)
소규모 클러스터에서는 체감이 안 되지만, 노드가 수백 대가 되면 서브넷 IP가 빠르게 고갈된다.
실습
Terraform 에서는 VPC CNI addon 의 환경변수 설정을 통해서 조정할 수 있다.
아래는 WARM_ENI_TARGET = 1 로 지정한 상태이다.

Prefix Delegation
Secondary IP의 IP 고갈 문제를 완화하기 위해 나온 방식
IP를 하나씩 할당하는 대신 /28 Prefix (16개)를 ENI에 할당하고 그 안에서 Pod IP를 부여한다.
Secondary IP 모드: ENI에 IP 10개 할당 -> Pod 10개
Prefix Delegation: ENI에 /24 블록 16개 할당 -> Pod 최대 160개
실제로는 노드 IP / maxPods 등의 이유로 최대 Pod수가 위와 다를 수 있음
- /28 블록은 연속된 IP 16개를 확보해야 하므로, 서브넷이 단편화 되어 있으면 할당에 실패할 수 있다.
- 서브넷을 충분히 설계하거나, 신규 서브넷을 사용하는 것을 권장
- maxPods 설정을 인스턴스 한계에 맞게 조정해야 한다.
Secondary IP 모드와 Prefix Delegation 모드 모두, Pod는 노드와 같은 서브넷에서 IP를 받는다는 점은 동일하다.
이 한계를 넘기 위한 것이 Custom Networking 이다.
Custom Networking
앞서 설명한 두가지 모드는 노드와 같은 서브넷에서 IP를 받는다. 이 구조에서 2가지 문제가 발생할 수 있다.
- IP 고갈 문제 : 노드 IP와 Pod IP가 같은 서브넷을 공유하므로, Pod가 많아지면 서브넷 IP가 빠르게 소진된다.
Prefix Delegation으로 밀도를 높이면 더 빨리 고갈될 수 있다. - 보안 정책상 노드 네트워크와 Pod 네트워크에 서로 다른 Security group이나 서브넷 정책을 적용해야 하는 경우가 있다.
ENIConfig와 동작 방식
기본 모드:
Primary ENI (서브넷 A) → 노드 IP + Pod IP 모두
Custom Networking:
Primary ENI (서브넷 A) → 노드 IP만
Secondary ENI (서브넷 B) → Pod IP는 서브넷 B에서 할당
이 설정은 ENIConfig라는 CRD로 관리한다. 가용영역(AZ)별로 하나씩 만들어서, 해당 AZ의 노드에 붙을 Secondary ENI와 서브넷, Security Group을 지정한다.
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
name: ap-northeast-2a
spec:
subnet: subnet-0a1b2c3d # Pod용 서브넷
securityGroups:
- sg-0a1b2c3d # Pod용 Security Group
Custom Networking의 함정
(m5.large 기준 할당 가능한 ENI 수는 3개, ENI 당 IP 슬롯은 10개)
Custom Networking 에서는 Primary ENI의 Secondary IP 슬롯 9개는 버려진다. VPC CNI가 Primary ENI에서는 Pod IP할당을 하지 않고, ENIConfig에서 지정된 서브넷으로 생성한 Secondary ENI에서만 Pod IP를 할당하기 때문이다.
기본모드 :
최대 Pod = 3 * (10-1)= 27개
Custom Network :
최대 Pod = (3-1) * (10-1) = 18개
↑ Primary ENI 제외
할당가능한 IP 수 계산과 kubelet max_pods 수 계산은 다르다.
ENI 하나를 통째로 잃는 셈이라 오히려 인스턴스에 할당가능한 Pod IP의 수가 줄어든 것을 확인할 수 있다.
따라서 Custom Networking을 실무에서 사용할 때는 Prefix Delegation을 함께 켜서 Pod 밀도를 보완하는 것을 권장한다.
Prefix Delegation 을 함께 켰을 때
기본모드 :
최대 Pod = 3 * (10-1) * 16 = 432개
Custom Network :
최대 Pod = (3-1) * (10-1) * 16 = 288개
여전히 숫자는 적지만 충분한 Pod IP 갯수이기 때문에 문제는 없다.
Custom Networking + VPC Secondary CIDR 를 활용한 Pod 전용 대역 분리
Custom Networking 의 진가는 VPC에 Secondary CIDR를 추가해서 Pod 전용 대역으로 사용할 때 발휘된다.
VPC Primary CIDR : 10.1.0.0/16 → 노드, RDS, ALB 등
VPC Secondary CIDR : 100.64.0.0/16 → Pod 전용 대역
주로 RFC 6598(100.64.0.0/10) 을 활용한다. 이 대역은 Carrier-Grade NAT용으로 예약된 공유 주소 공간으로, 사내 Private IP (10.x.x.x, 172.16.x.x, 192.168.x.x) 와 겹치지 않아 멀티 VPC 환경에서 유리하다.
이 구성의 효과
- 노드 서브넷 IP 고갈 해소 : Pod 가 아무리 많아져도 노드 서브넷에 영향이 없음
- IP 대역 완전 분리 : 노드 IP (10.1.x.x) 만 보면 인프라, Pod IP(100.64.x.x)만 보면 워크로드라는 것을 즉시 구분 가능
- 대규모 Pod 수용 : Secondary CIDR를 /16으로 잡으면 약 65,000 개의 Pod 전용 IP 확보 가능
실습
Terraform 에서는 VPC CNI addon 환경변수 설정을 통해서 모드를 결정할 수 있다.
모든 실습은 worker node type이 t3.medium 이다. (아래에서 2번째)
t3.medium의 max network interfaces는 3, IP addresses per interface는 6 이다.


Secondary IP 모드

WARM_ENI_TARGET = 1로 지정한 상태이다.
이대로 worker node 생성을 진행하면 아래 처럼 private IPv4 address 2개, Secondary private IPv4 addresses 10개가 보인다.
각 ENI 에 붙는 고유 ip 2개 를 제외하고 ENI 별로 5개의 여유 IP가 확보되어 있다.

VPC CNI 설정 변경
WARM_ENI_TARGET=1 을 주석처리하고, WARM_IP_TARGET / MINIMUM_IP_TARGET 값을 지정해봤다.

위 옵션은 여유 IP는 5개를 유지하되 최소 10개의 IP는 확보하라는 뜻이다.
현재는 pod가 하나도 떠 있지 않거나 5개 이하로 떠 있으니까 저렇게 10개를 유지한다.
하지만, pod가 5개 이상이 되어서 여유 IP가 5개 이하로 떨어지면 11개, 12개 이렇게 최소 여유 IP가 5개가 될때까지 Secondary IP를 확보할 것이다.

Prefix Delegation
ENABLE_PREFIX_DELEGATION = true , WARM_PREFIX_TARGET = 1 로 설정했다.

실제 worker node 정보에 들어가면 그 전과는 다르게 Secondary IP addresses 에 1개의 IP만 보이고,
아래 ENI 세부정보에 가면 IPV4 Prefixes에 Primary ENI와 같은 서브넷에 있는 16개의 IP 블록(192.168.6.64/28) 이 있는 것을 볼 수 있다.


'DevOps > EKS' 카테고리의 다른 글
| [AEWS4기] EKS Cluster Endpoint Access (0) | 2026.03.18 |
|---|---|
| [AEWS4기] 실습환경 구성 (0) | 2026.03.18 |
| AWS EKS vs Vanilla k8s (0) | 2026.03.17 |