Session

From Node to Pod to Service: Inside Kubernetes IP Allocation

Every Pod, every Service, every Node in your cluster has an IP address. Three different components assigned them, using three different mechanisms — and here's the part that should worry you more than it does: nothing in Kubernetes checks those three address spaces against each other. Three allocators, zero cross-checking, and somehow it (mostly) works. This talk is about why, and about the day it doesn't.

I'll trace an IP address through all three domains, from first principles down to the etcd object:

Pod IPs — hierarchical, two-stage, bitmap-based. How NodeIpamController carves --cluster-cidr into one per-node block via --node-cidr-mask-size, writes it to spec.podCIDR, and hands off to the CNI's own IPAM. Then the fork that trips people up: overlay/bridge CNIs respect spec.podCIDR, while VPC-native plugins like AWS VPC CNI and Azure CNI bypass cluster IPAM entirely and pull straight from VPC subnets. I'll also flag where this is heading with the MultiCIDRRangeAllocator and ClusterCIDR API.

Service IPs — the part that just changed. The old in-memory bitmap allocator with its repair loop is gone; ClusterIPs are now backed by real ServiceCIDR and IPAddress API objects in etcd. The conflict-avoidance primitive is genuinely elegant — uniqueness enforced by etcd's atomic create on an object named after the IP itself, so two API servers physically cannot mint the same address. Plus the live demo everyone remembers: adding capacity with a kubectl apply, no restart.

Node IPs — the trick question. Kubernetes performs no allocation here at all. The address comes from your infrastructure; kubelet auto-detects or is told, and cloud-controller-manager reports it back. This is the one most talks get wrong.

We'll finish on the gap that bites in production: nobody validates these three domains for overlap. I'll show where that surfaces, why kubeadm's preflight check won't catch it, and how to reason about it before it pages you.

You'll leave able to answer "who assigned this IP, from what range, and how do I know it won't collide?" for every address in your cluster. Entirely open-source, vendor-neutral, straight to the source.

Ajitem Sahasrabuddhe

Staff DevOps Engineer, Automattic

Nagpur, India

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top