Ilmu Komputer & AI editorial
Fleet-Scale Pod Deployment with VPC-Native Networking in Managed Kubernetes
The core problem
Managed Kubernetes pod deployment is frequently framed as a binary choice between VPC-native networking and overlay networking. Public Amazon EKS documentation describes prefix-mode capacity and configuration, while prior CNI studies primarily measure steady-state throughput and latency rather than the dynamics of large-scale pod placement. This paper addresses that gap with an operational measurement study of fleet-scale pod deployment across three VPC-native modes on Amazon EKS: individual secondary-IP allocation, ENI preallocation, and IPv4 prefix delegation. Cilium and Calico serve as overlay baselines.
The central question is how address provisioning interacts with the pod-creation critical path. The authors compare representative mode-specific warm-pool settings, so the reported results describe combined operating points rather than isolated CNI behavior. The workload is deliberately large: 400 nodes and 80,000 pods, a scale at which per-pod provisioning overhead compounds into minutes or hours of deployment time. The taxonomy of the work spans Architecture and Network, with implications for capacity planning in managed Kubernetes environments.
Innovation
At 400 nodes, the tested three-address secondary-IP warm pool required **7,403 seconds** to place 80,000 pods. With the tested ENI-preallocation and prefix-delegation settings, the same workload completed in approximately **495 seconds**, moving address provisioning off the pod-creation critical path.
In the reported 400-node runs, prefix delegation achieved approximately **162 pods/s**, within the same observed range as the fastest overlay baseline and the ENI-preallocation runs. Prefix delegation also required fewer successful EC2 provisioning calls per pod than individual-IP allocation because it allocates addresses in /28 blocks.
The capacity comparison is stark. With 30 slots per interface, prefix delegation yields 29 prefixes and up to 464 potential pod addresses, versus approximately 30 IPv4 slots per ENI for individual-IP allocation. The speedup from the secondary-IP warm pool to the preallocation/prefix modes is roughly:
Prefix delegation additionally has lower documented network-address usage and retains direct VPC reachability and flow-log visibility.
Why it matters
The results indicate that the dominant cost in fleet-scale pod deployment is not steady-state throughput but address provisioning on the pod-creation critical path. The three-address secondary-IP warm pool exhausted its pre-provisioned addresses early in the 80,000-pod workload, forcing synchronous EC2 provisioning calls that serialized placement. ENI preallocation and prefix delegation avoid this by acquiring capacity ahead of demand.
The /28 block allocation is the structural reason prefix delegation matches the fastest baselines while using fewer EC2 provisioning calls. Each /28 consumes one IPv4 slot but yields 16 addresses, so a single interface can carry up to 464 pod addresses. This amortizes provisioning overhead across many pods.
The trade-off is that /28 allocations require contiguous subnet space. Operators must plan subnet CIDR ranges with sufficient contiguous capacity, which may be constrained in dense or fragmented VPC layouts. Prefix delegation also retains direct VPC reachability and flow-log visibility, preserving operational observability that overlay networks can complicate.
The following diagram summarizes the decision flow across the tested modes:
Because the study compares representative mode-specific warm-pool settings, the results describe combined operating points rather than isolated CNI behavior. Practitioners should treat the 495-second and 162 pods/s figures as configuration-dependent rather than universal constants.
Who should read this
Opening member contentโฆ