EKS 노드에서 파드가 Too many pods 로 스케줄링되지 않는 것은 Kubernetes 의 제한이 아니라 Amazon VPC CNI 가 노드에 붙일 수 있는 ENI 수와 ENI 당 IP 수에서 나온 값이다. VPC CNI 는 파드마다 VPC 의 실제 IP 를 하나씩 배정하므로, 인스턴스 타입이 허용하는 IP 총량이 곧 파드 수 상한이 된다.
기본 모드에서 노드의 최대 파드 수는 다음과 같이 계산된다.
max_pods = (ENI 개수 × (ENI 당 IP 수 - 1)) + 2
- 1 은 ENI 자신의 기본 IP 이고 + 2 는 호스트 네트워크를 쓰는 파드(aws-node, kube-proxy) 몫이다. ENI 수와 ENI 당 IP 수는 인스턴스 타입마다 다르므로 작은 타입일수록 상한이 급격히 낮아진다. 현재 값은 노드에서 직접 본다.
kubectl get node <node> -o jsonpath='{.status.allocatable.pods}{"\n"}'
kubectl describe node <node> | grep -i 'Allocated resources' -A 8
접두사 위임(prefix delegation) 이 가장 효과가 크다. ENI 에 IP 를 하나씩 붙이는 대신 /28 접두사(IPv4 기준 16개)를 붙여 ENI 당 수용량을 크게 올린다. VPC CNI 애드온에서 켠다.
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
켠 뒤에는 kubelet 의 --max-pods 도 같이 올려야 실제로 반영된다. 관리형 노드 그룹이면 시작 템플릿의 부트스트랩 인자에 --use-max-pods false --kubelet-extra-args '--max-pods=<N>' 를 준다. 기존 노드에는 적용되지 않으므로 노드를 교체해야 한다. 서브넷에 /28 을 연속으로 잡을 여유가 없으면 접두사 할당이 실패하므로, 파편화된 작은 서브넷에서는 효과가 떨어진다.
인스턴스 타입 확대도 직접적인 방법이다. ENI 수와 ENI 당 IP 수가 함께 늘어난다. 다만 비용이 같이 오르고, 파드 하나가 쓰는 자원이 작다면 낭비가 크다.
커스텀 네트워킹으로 파드 전용 보조 CIDR(예: 100.64.0.0/16)을 붙이면 IP 고갈 자체를 피할 수 있다. 다만 ENIConfig 를 AZ 별로 만들어야 하고 노드 기본 ENI 는 파드에 쓰이지 않게 되어 상한 계산이 달라진다. 구성이 복잡하므로 IP 여유가 진짜 없을 때만 선택한다.
--max-pods 만 크게 올리고 접두사 위임을 켜지 않으면 스케줄러는 파드를 배치하지만 IP 가 없어 failed to assign an IP address to container 로 파드가 뜨지 않는다. 두 설정은 반드시 함께 간다.
파드 수를 늘리기 전에 그 노드의 CPU·메모리 여유를 먼저 본다. IP 상한이 풀려도 자원이 없으면 Insufficient cpu 로 바뀔 뿐이다.