beautifulsoups.dev
Published on

EKS IPv4 고갈 대응 - VPC CNI Prefix Delegation

Authors

EKS를 운영하다 보면 어느 순간부터 클러스터 전체 IPv4가 아니라, 특정 노드에서 Pod IP가 먼저 고갈되면서 스케일아웃이 멈추는 경험을 하게 됩니다. 증상은 대개 비슷합니다.

  • 노드에는 CPU/메모리 여유가 있는데 Pod가 Pending으로 남음
  • 이벤트에 Insufficient pods 또는 CNI 관련 IP 할당 실패 메시지
  • 노드를 더 늘려도 서브넷의 남은 IP가 줄어들기만 하고, Pod 증설이 기대만큼 안 됨

이 글에서는 원인을 AWS VPC CNI의 IP 할당 모델 관점에서 설명하고, 해결책으로 Prefix Delegation(PD) 을 활성화하는 방법을 실제 설정/검증/주의사항까지 한 번에 정리합니다.

관련해서 Pod 스케줄링 실패 원인을 폭넓게 점검하려면 K8s Pod가 Pending? 스케줄링 실패 12가지도 같이 보면 좋습니다.

왜 EKS에서 IPv4가 빨리 고갈될까

EKS 기본 네트워킹(기본적으로 AWS VPC CNI 사용)에서는 Pod마다 VPC 라우팅이 가능한 실제 VPC IPv4 주소(ENI의 Secondary IP) 를 할당합니다. 즉, Pod IP는 오버레이가 아니라 VPC의 “진짜” IP 풀을 소모합니다.

문제는 노드가 Pod에 IP를 주기 위해 다음을 수행한다는 점입니다.

  1. 노드(EC2)에 ENI를 붙임
  2. ENI에 Secondary IP를 여러 개 붙임
  3. Pod가 생성될 때마다 그 Secondary IP를 하나씩 소비

이 방식에서 IPv4 고갈이 빨라지는 대표적인 패턴은 다음과 같습니다.

  • 작은 서브넷(/24 등) 에 많은 노드를 넣고, 노드가 예비 IP를 선점하는 경우
  • WARM_IP_TARGET 같은 설정으로 미리 IP를 넉넉히 확보하도록 해 둔 경우
  • 서비스가 수평 확장/축소를 자주 하면서 IP 할당/반납이 빈번한데, 노드가 “따뜻한(warm)” IP를 계속 들고 있는 경우

결과적으로 “클러스터 전체” 관점에서는 IP가 남아 보이는데도, 노드 단위로는 할당 가능한 IP가 부족해져서 Pod가 뜨지 않는 상황이 나옵니다.

Prefix Delegation이 해결하는 것

Prefix Delegation(PD)은 AWS VPC CNI가 ENI에 개별 Secondary IP를 여러 개 붙이는 대신, IPv4 Prefix(예: /28) 블록을 ENI에 위임받아 Pod IP를 그 블록에서 할당하는 방식입니다.

핵심 효과는 다음과 같습니다.

  • ENI에 IP를 “점”으로 붙이던 것을 “블록”으로 받아와서 할당 효율이 좋아짐
  • 노드가 Pod 증가에 대응하기 위해 ENI/Secondary IP를 자주 조작하는 부담이 줄어 스케일링이 더 매끄러워짐
  • 동일 인스턴스 타입에서 Pod 수용량이 증가하는 경우가 많음(인스턴스별 ENI/IPv4 제한에 덜 묶임)

다만 PD는 “서브넷이 너무 작으면 마법처럼 해결”해주는 기능은 아닙니다. 여전히 Pod IP는 VPC IPv4를 쓰므로, 장기적으로는 서브넷 설계(/19, /20 등)나 멀티 서브넷 분산도 함께 고려해야 합니다.

적용 전 체크리스트

PD를 켜기 전에 아래를 확인하세요.

1) VPC CNI 버전

Prefix Delegation은 비교적 최신 VPC CNI에서 안정적으로 사용됩니다. 운영에서는 최소 최근 1~2년 내 버전을 권장합니다.

현재 버전 확인:

kubectl -n kube-system get ds aws-node -o jsonpath='{.spec.template.spec.containers[0].image}'

2) 노드/서브넷 구조

  • 노드가 여러 AZ에 걸쳐 있다면 각 AZ 서브넷의 여유 IP를 확인
  • 특정 AZ만 트래픽/스케줄링이 몰려 IP가 먼저 고갈되는지 확인

서브넷 여유 IP는 AWS 콘솔 또는 CLI에서 확인할 수 있습니다.

3) Pod 밀도와 인스턴스 타입 한계

Pod 수용량은 인스턴스 타입의 ENI 수/IPv4 제한, CNI 설정(예비 IP 정책), 보조 ENI 사용 여부 등에 영향을 받습니다. PD를 켜면 “대체로” 개선되지만, 인스턴스 타입 자체의 네트워크 한계가 너무 낮으면 기대만큼 늘지 않을 수 있습니다.

Prefix Delegation 활성화 방법

EKS에서 VPC CNI는 aws-node 데몬셋으로 배포됩니다. PD는 환경변수로 활성화합니다.

1) ENABLE_PREFIX_DELEGATION 설정

kubectl -n kube-system set env daemonset/aws-node ENABLE_PREFIX_DELEGATION=true

변경 확인:

kubectl -n kube-system describe ds aws-node | sed -n '/Environment:/,/Mounts:/p'

2) 예비(웜) 리소스 정책 재점검

PD를 켠 뒤에도 웜 정책이 과하면 IP를 많이 쥐고 있을 수 있습니다. 환경에 따라 다음을 조정합니다.

  • WARM_IP_TARGET: 노드가 미리 확보해둘 IP 개수
  • MINIMUM_IP_TARGET: 최소 확보 IP 개수
  • (PD 사용 시) WARM_PREFIX_TARGET: 미리 확보해둘 Prefix 개수

예를 들어 Prefix를 1개만 웜으로 유지하고 싶다면:

kubectl -n kube-system set env daemonset/aws-node WARM_PREFIX_TARGET=1

기존에 WARM_IP_TARGET을 크게 잡아 둔 클러스터라면, PD 전환 후에는 WARM_PREFIX_TARGET 중심으로 정책을 재설계하는 편이 운영 예측성이 좋습니다.

3) 롤링 업데이트 확인

aws-node는 데몬셋이라 노드마다 순차적으로 재시작됩니다.

kubectl -n kube-system rollout status ds/aws-node

적용 후 검증: 정말 IP 고갈이 줄었는지

1) CNI 로그에서 Prefix 관련 메시지 확인

노드의 aws-node(또는 aws-vpc-cni) 로그에서 prefix 할당 관련 로그가 보이는지 확인합니다.

kubectl -n kube-system logs ds/aws-node -c aws-node --tail=200

환경/버전에 따라 메시지는 다르지만, prefix 할당/사용 관련 키워드가 확인되어야 합니다.

2) 노드에서 할당 가능한 Pod 수 변화 확인

가장 현실적인 검증은 “같은 인스턴스 타입에서 Pod를 더 많이 올릴 수 있는지”입니다.

  • 테스트 네임스페이스에서 더미 Deployment를 늘려 스케줄링 한계점 비교
  • 스케줄링 실패 이벤트가 Insufficient pods에서 사라지는지 확인

이벤트 확인:

kubectl get events -A --sort-by=.lastTimestamp | tail -n 50

3) 서브넷 남은 IP 감소 속도 관찰

PD를 켠 뒤에는 노드가 IP를 선점하는 패턴이 바뀌어, 서브넷의 Available IP 감소 속도가 완만해지는지 관찰하는 것이 좋습니다.

자주 겪는 문제와 운영 팁

1) Pod는 여전히 Pending인데 PD를 켰는데도 개선이 없다

PD는 만능이 아닙니다. 아래를 함께 점검하세요.

  • 실제 원인이 IP가 아니라 CPU/메모리/스토리지/노드 셀렉터/taint일 수 있음
  • 특정 AZ만 포화(서브넷 IP 부족)인데 스케줄러가 그 AZ로만 보내는 구성일 수 있음
  • maxPods 제한(부트스트랩에서 지정) 때문에 Pod를 더 못 올리는 경우

스케줄링 원인 분석은 위에서 소개한 Pending 체크리스트 글이 도움이 됩니다.

2) 작은 서브넷은 결국 한계가 온다

PD는 “노드 단위 IP 할당”의 비효율을 줄여주지만, Pod IP가 VPC IPv4를 쓰는 구조 자체는 그대로입니다. 장기적으로는 다음 중 하나가 필요합니다.

  • 더 큰 CIDR의 서브넷으로 확장/추가
  • AZ별로 서브넷을 추가해 분산
  • (요구사항에 따라) IPv6 기반으로 전환 검토

3) 변경은 점진적으로, 관측 지표를 잡고 진행

운영 클러스터에서는 다음을 권장합니다.

  • 비업무 시간대에 적용
  • 적용 전후로 Pending 비율, 노드당 Pod 수, 서브넷 Available IP, Pod 생성 지연 등을 비교
  • 문제 발생 시 aws-node 롤백(환경변수 원복) 절차 마련

EKS에서 네트워킹 문제는 종종 kube-proxy/iptables 이슈와 함께 관측되기도 합니다. 만약 노드 네트워크 레벨에서 CrashLoopBackOff나 iptables 오류가 섞여 보인다면 EKS kube-proxy CrashLoopBackOff iptables 오류 해결도 참고하세요.

결론

EKS에서 IPv4 고갈은 “VPC 전체 IP가 부족”해서라기보다, VPC CNI의 노드 단위 IP 선점/할당 방식 때문에 먼저 터지는 경우가 많습니다. Prefix Delegation은 이 병목을 완화해 노드당 Pod 수용량을 늘리고, IP 할당 동작을 더 효율적으로 만들어 줍니다.

정리하면 다음 순서로 접근하는 것이 안전합니다.

  1. 현재 CNI 버전/서브넷 여유 IP/스케줄링 이벤트로 원인 확정
  2. ENABLE_PREFIX_DELEGATION=true 적용
  3. WARM_PREFIX_TARGET 등 웜 정책을 환경에 맞게 재조정
  4. 적용 전후 지표로 효과 검증

이 과정을 거치면 “노드 리소스는 남는데 Pod가 안 뜨는” 전형적인 IPv4 고갈 증상을 상당 부분 줄일 수 있습니다.

Discuss on Twitter • View on GitHub