Mastering IP Address Management in Kubernetes Clusters

IP Address Types in Kubernetes

Node IP : The IP of each physical or virtual node, usually taken from the host network interface; used for node‑to‑node communication and external network access. Visible via kubectl get nodes -o wide as INTERNAL‑IP.

Pod IP : Assigned to each Pod from the Pod CIDR; enables intra‑Pod communication and is managed by the CNI plugin. Not reachable from outside by default.

Cluster IP : A virtual IP (VIP) for a Service, allocated from the Service CIDR; used for internal service discovery and load balancing.

External IP / LoadBalancer IP : Exposes a Service outside the cluster; allocated by the cloud provider or manually assigned.

Core CIDR Planning

Pod CIDR : Defines the address pool for Pods. Configure via kube-controller-manager --cluster-cidr=<CIDR> or let the CNI plugin handle it. Planning tip: calculate max_nodes × max_pods_per_node (e.g., 100 nodes × 50 Pods = 5,000 IPs → use a /19 block). Avoid overlap with internal VPC ranges; common private ranges are 10.244.0.0/16, 192.168.0.0/16, 172.16.0.0/12.

Service Cluster CIDR : Supplies IPs for ClusterIP services. Set with kube-apiserver --service-cluster-ip-range=<CIDR>. Usually a /20 or /16 is sufficient, but must not overlap the Pod CIDR.

Node Network : Node IPs must be routable to both Pod and Service networks, typically configured by the CNI plugin through overlay networks or routing rules.

CNI Plugins and IPAM

Host‑local IPAM (e.g., Flannel default): Each node receives a fixed subnet (e.g., /24) from the Pod CIDR. Simple and efficient but requires careful subnet planning for scaling.

Centralized IPAM (e.g., Calico BGP/IPIP mode): Manages a global IP pool, allowing non‑contiguous allocations and easier multi‑cluster expansion.

Management Practices and Best Strategies

Reserve Space : Keep 20‑30% extra IPs for future growth (e.g., 5,000 needed → allocate 6,500+).

Use Large CIDR and Subnet Division : Allocate a large Pod CIDR (e.g., /16) and split into /24 per node for centralized control.

Monitor IP Usage :

Check node subnets:

kubectl get nodes -o custom-columns='NAME:.metadata.name,IP:.status.addresses[?(@.type=="InternalIP")].address,POD_CIDR:.spec.podCIDR'

View Pod IPs: kubectl get pods -o wide Inspect CNI IPAM status:

calicoctl ipam show --show-blocks

cilium status

Handle IP Exhaustion :

Root cause: overly small node subnets or high Pod density.

Solutions: expand the IP pool (dynamic CNI), enlarge node subnet (cautiously, may require node draining), or add new nodes (commonly with Cluster Autoscaler).

Service Network Management :

ClusterIP is auto‑managed; list with kubectl get svc.

Specify a fixed IP via spec.clusterIP within the Service CIDR and ensure it is free.

Troubleshooting Checklist

Pod Pending – Possible cause: node IP exhaustion or CNI failure. Diagnose with kubectl describe pod <pod> and verify node Pod CIDR.

Network Unreachable – Possible cause: firewall/security‑group blocks or CNI not running. Check system pods: kubectl get pods -n kube-system.

IP Conflict – Possible cause: overlapping Pod CIDR with internal/VPC networks. Verify CIDR configuration and ensure no overlap across clusters.

Additional Tips

For high‑density nodes, adjust node subnet masks or switch to centralized IPAM.

In multi‑cluster or hybrid‑cloud setups, guarantee non‑overlapping Pod CIDRs.

Visualize network topology with CNI tools or kubectl get pods -o wide to audit IP allocation.

Core Recommendation: Successful IP management starts with careful planning, followed by continuous monitoring and adherence to best practices, ensuring a stable and scalable cluster network.