Kubernetes and IP Address Consumption

Every pod may need a VPC address

Managed Kubernetes services integrate pods with the VPC. On Amazon EKS, the default Amazon VPC CNI plugin gives each pod an IP address from the node's subnet, so pods are first-class VPC citizens: security tools, flow logs and peered networks see real pod IPs. The cost is address consumption. A node with dozens of pods uses dozens of IPs, and the plugin keeps spare addresses warm for fast pod start-up, so a /24 subnet can be exhausted by a modest cluster. Symptoms are pods stuck in ContainerCreating with IP-allocation errors. Mitigations include larger node subnets, adding a secondary VPC CIDR (often from 100.64.0.0/10) dedicated to pods (custom networking), tuning the warm-IP settings so fewer spare addresses are held, or using IPv6. Google Kubernetes Engine VPC-native clusters similarly allocate pods from a secondary range of the subnet. Other CNIs use an overlay network, where pods get addresses outside the VPC range and traffic is encapsulated, saving VPC IPs at the cost of visibility.

From subnet to pod

Pod addresses are carved down in four levels: the VPC, the node subnet, the node's network interfaces, and finally the individual pods.

Size the pod range first

When planning a Kubernetes VPC, estimate maximum nodes times maximum pods per node, add the warm pool, then double it. Pod IPs, not node IPs, usually decide the subnet size.

Quick check: Pods on an EKS cluster using the Amazon VPC CNI are stuck in ContainerCreating with IP allocation errors. What is the most likely cause?

• The cluster has no internet gateway
• The VPC DNS resolver is disabled
• The node subnets have run out of free IP addresses
• The load balancer is layer 4