Pod IP Addresses in Kubernetes
Where a pod's address comes from, why every pod gets its own, why that address keeps changing, and what Kubernetes gives you so that nobody has to memorize it. A gentle guide for readers who are new to cluster networking.
Think of a large apartment complex where every flat has its own door number. Residents move in and out all the time, so a flat that belonged to one family last month may belong to a different one today. If you wanted to reach a particular family, you would not memorize door numbers. You would ask the reception desk, which always knows who lives where right now. In Kubernetes, pods are the flats, their IP addresses are the door numbers, and Services and DNS names are the reception desk. This post explains the door numbers first, then shows why the reception desk matters so much.
1What Is an IP Address, and Why Do Pods Need One?
Start with the basics, because everything else builds on them.
An address for every talker
An IP address is a number that identifies a device on a network, so other devices know where to send messages. Your phone has one, your laptop has one, and so does every server. Without addresses, data would have no destination, like letters with no house number.
Pods talk to each other constantly
A pod is the smallest unit Kubernetes runs, a small shared home for one or more containers. In a real application, dozens of pods talk to each other all day. A web pod asks a payment pod to charge a card. The payment pod asks a database pod to save a record. For any of these conversations to happen, each pod needs an address that the others can use.
Kubernetes solves this in a simple and bold way: every pod gets its very own IP address, the moment it is created.
A hotel gives every room its own number so the staff can deliver food to exactly the right door. Pod IP addresses are room numbers for containers.
flowchart LR
W["Web pod"] -->|"Uses pod address"| P["Payment pod"]
P -->|"Uses pod address"| D["Database pod"]
2The Kubernetes Networking Promise
Kubernetes sets a few clear rules about how pod networking must behave.
Kubernetes does not build the network itself, but it insists that whatever network you use follows a small set of rules. These rules are often called the Kubernetes network model.
Every pod has its own IP
No two pods share an address, and containers inside one pod share that pod’s single address.
Pods reach pods everywhere
A pod can talk to any other pod in the cluster directly, even on another machine, without address translation in between.
Nodes reach local pods
The agents running on a machine can talk to all pods on that same machine.
Same address seen by everyone
The address a pod believes it has is the same address others use to reach it, so nothing is hidden or rewritten.
Why this “flat network” is a gift
Older container systems often hid containers behind their host machine and mapped ports, which meant developers constantly juggled port numbers and conflicts. Kubernetes gives every pod a real, routable identity instead, which makes applications behave the way they did on ordinary servers. Each pod can use its normal port numbers, and the whole cluster feels like one large, flat network.
Imagine a campus where every student has a direct phone number, and any student can call any other without going through a switchboard operator. That is the flat pod network.
3Key Terms You Will Meet
Short definitions now save confusion later.
Pod IP
The address given to a pod. It is shared by all containers in that pod and lasts only as long as the pod does.
CIDR block
A compact way of writing a range of addresses. A block is like a whole street of house numbers reserved for one purpose.
Pod CIDR
The slice of addresses reserved for pods on one particular machine.
CNI plugin
The networking add-on that actually gives pods their addresses and connects them to the network. CNI stands for Container Network Interface.
Service
A stable address placed in front of a changing group of pods.
ClusterIP
The steady virtual address of a Service, reachable only from inside the cluster.
Node IP
The address of the machine itself, separate from any pod addresses on it.
Network namespace
A private network space with its own address and ports. Each pod gets one, which its containers share.
4Where Do Pod Addresses Come From?
Addresses are handed out from pools, and the pools are split up by machine.
When a cluster is created, its administrators choose a large range of addresses to be used for pods. Kubernetes then carves that big range into smaller pieces and gives one piece to each node. Every pod that lands on a node receives an address from that node’s piece.
graph TD
C["Cluster pod address range"] --> N1["Node 1 slice"]
C --> N2["Node 2 slice"]
C --> N3["Node 3 slice"]
N1 --> A1["Pod A"]
N1 --> A2["Pod B"]
N2 --> B1["Pod C"]
N2 --> B2["Pod D"]
N3 --> C1["Pod E"]
Why split by node?
Splitting the range means each node can hand out addresses on its own, quickly, without asking a central authority for every pod. It also means that the network can easily figure out where a pod is: if an address belongs to Node 2’s slice, the pod is on Node 2. Routing becomes a simple lookup.
A city gives each neighborhood its own block of house numbers. The local post office in each neighborhood assigns numbers from its own block, and any postman can tell the neighborhood just by looking at the number.
The size of each slice limits how many pods a node can host. Commonly, slices are sized to hold more addresses than the node’s recommended maximum number of pods, leaving room for pods coming and going.
5Who Actually Assigns the Address? The CNI Plugin
Kubernetes delegates the hands-on networking work to a plugin.
Kubernetes itself does not wire up the network. Instead it defines a standard interface, the Container Network Interface, and lets different networking plugins do the work. When a pod is about to start, the node’s agent, called the kubelet, asks the container runtime to create the pod’s network space. The runtime then calls the CNI plugin, which picks an address, attaches the pod to the network, and reports the result back.
The scheduler picks a node
A new pod is assigned to a machine based on available resources and rules.
The kubelet prepares the pod
The node’s agent sees the assignment and asks the runtime to create the pod sandbox, the shared space that holds the pod’s network identity.
The runtime calls the CNI plugin
The plugin is asked to set up networking for this new sandbox.
An address is allocated
The plugin takes a free address from the node’s slice, connects the pod to the node’s network and adds the routes needed for others to reach it.
The containers start
Application containers join the sandbox’s network space and share its address.
The address is published
The pod’s IP is recorded in its status so the rest of the cluster can see it.
sequenceDiagram
participant S as Scheduler
participant K as Kubelet
participant R as Container runtime
participant C as CNI plugin
participant A as API server
S->>A: Assign pod to node
K->>A: Sees new pod
K->>R: Create pod sandbox
R->>C: Set up networking
C-->>R: Address and routes ready
R-->>K: Sandbox ready
K->>R: Start containers
K->>A: Report pod IP in status
A new employee is hired by the manager, who is Kubernetes. The building’s facilities team, the CNI plugin, is the one who assigns the desk, the phone extension and the network socket. The manager only checks that it was done.
6Popular CNI Plugins and How They Differ
Different plugins make different trade-offs while obeying the same rules.
Overlay networks
The plugin wraps pod traffic inside another packet and sends it between machines, like putting a letter inside a larger envelope. It works almost anywhere, even on networks that know nothing about pods, but adds a little overhead. Flannel is a well-known simple example.
Routed networks
The plugin teaches the underlying network how to reach each node’s pod slice, so pod traffic travels as ordinary traffic with no wrapping. This is efficient and easy to observe. Calico is popular for this style and also offers strong network policy features.
Kernel-powered networking
Some plugins, such as Cilium, use modern Linux kernel features to handle routing, policy and observability very efficiently, often with detailed visibility into who talks to whom.
Cloud-native address models
Managed cloud offerings often use plugins that give pods addresses straight from the cloud’s own virtual network. Pods then look like first-class members of the wider network, which simplifies connections to other cloud services but means pod addresses consume space in that network.
The choice of plugin and address range is hard to change after a cluster is running. Pick a range large enough for future growth and one that does not overlap with other networks you may connect to.
7Containers Inside One Pod Share One Address
A pod has one IP, no matter how many containers it holds.
Behind the scenes, Kubernetes creates a tiny, nearly idle container whose job is simply to hold the pod’s network space open. Every other container in the pod then joins that space. This is why all the containers in a pod see the same address and the same ports.
Two consequences
They talk over localhost
Containers in one pod reach each other by using the name localhost and the right port. No external address is needed.
They cannot reuse ports
Two containers in the same pod cannot listen on the same port, since they share one network space.
Roommates in one flat share a single street address and a single doorbell. Visitors ring one bell, and the roommates talk to each other inside without going outside.
8The Big Catch: Pod IPs Are Temporary
This is the single most important fact about pod addresses.
A pod’s IP address lives exactly as long as the pod lives. When a pod is deleted, crashes and is replaced, or is moved during an update, the old address is released and the new pod gets a different one. The new pod may even land on a different machine, and so belong to a different slice of addresses.
Situations that change a pod’s address
Rolling update
New pods replace old ones, each with fresh addresses.
Pod crash and replacement
If a pod is removed and recreated by a controller, the replacement gets a new address.
Node failure
Pods lost with a machine are recreated elsewhere with new addresses.
Scaling
Scaling up adds pods with new addresses, and scaling down releases addresses that others may later reuse.
Writing a pod’s IP address into a configuration file, a database record or a firewall rule and expecting it to stay valid. It will eventually point to nothing, or worse, to a completely different pod.
Hotel guests get a room number that lasts only for their stay. Writing “Room 204” in your diary as the permanent address of a friend would send you to a stranger next month.
9The Solution: Services Give You a Stable Address
Because pod addresses keep changing, Kubernetes places a permanent front door in front of them.
A Service is a Kubernetes object that gives a group of pods one steady virtual address and name. Callers use the Service, and Kubernetes forwards each request to one of the healthy pods behind it. As pods come and go, the Service keeps track of the current members and updates the list automatically.
How a Service knows its pods
A Service uses labels, small name tags attached to pods, to decide which pods belong to it. Kubernetes continuously watches which pods carry the matching label and are ready, and keeps an up-to-date list of their current addresses. Callers never see the list.
graph LR
U["Caller pod"] --> S["Service with stable address"]
S --> P1["Pod 1 with changing IP"]
S --> P2["Pod 2 with changing IP"]
S --> P3["Pod 3 with changing IP"]
A company’s main helpline number stays the same for years, even as agents join, leave and change desks. Callers dial the helpline, and the phone system connects them to whoever is available right now.
The Service address is virtual
A Service’s ClusterIP is not attached to any single pod or machine. It comes from a separate range of addresses reserved for Services, and each node’s networking rules recognize it and redirect traffic to a real pod. A component on every node, called kube-proxy in many clusters, keeps these rules up to date, and some networking plugins handle the same job themselves.
10DNS: Names Instead of Numbers
People and programs remember names much better than numbers.
Kubernetes runs a built-in DNS service. DNS works like a phone book: you look up a name and get back a number. Every Service automatically receives a DNS name, so one pod can reach another simply by using the Service’s name. If the caller is in the same namespace, the short name is enough. For a Service in another namespace, the name includes the namespace as well.
A pod wants to call “payments”
It uses the Service name instead of any number.
DNS answers with the Service’s stable address
The cluster’s DNS looks up the name and replies with the ClusterIP.
The node forwards the request
Networking rules pick a healthy pod behind the Service and send the request to its current address.
The reply returns
The chosen pod answers and the caller never learns which address it was.
Always connect to other parts of your application through Service names. Treat pod IPs as an implementation detail that you look at only while debugging.
11Headless Services and Stable Identities
Sometimes you need to reach a specific pod, not just any pod.
Some applications, such as databases with a primary and replicas, need to talk to a particular member rather than whoever is available. For this, Kubernetes offers headless Services, which have no virtual address of their own. Instead, asking DNS for the Service returns the individual addresses of the pods behind it, letting the caller choose.
Combined with a workload type designed for stateful applications, each pod also receives a stable, predictable name, such as the first, second and third member. Even when a pod is recreated and receives a new IP address, its name stays the same, and DNS points that name to the new address. The name is permanent, while the number underneath is allowed to change.
| Way to reach a pod | Stable? | Best used for |
|---|---|---|
| Raw pod IP | No | Short-lived debugging only |
| Normal Service name | Yes | Stateless applications with interchangeable pods |
| Headless Service listing pods | Names stable, addresses can change | Clients that choose their own pod |
| Stable pod name from a stateful workload | Yes, by name | Databases and clustered software needing identity |
A hospital’s “Doctor Sharma” always has the same name badge and office label, even if the office is moved to a different floor. Patients ask for Doctor Sharma by name and the reception desk points them to the current room.
12Pod IP vs Service IP vs Node IP
Three kinds of addresses appear in every cluster, and beginners often mix them up.
| Address type | Belongs to | Lifetime | Reachable from |
|---|---|---|---|
| Pod IP | One pod | Same as the pod | Other pods and nodes in the cluster |
| Service ClusterIP | A group of pods behind a Service | Same as the Service | Inside the cluster only |
| Node IP | A machine | Long-lived | The wider network, depending on setup |
| External or load balancer address | A Service exposed outside | Same as the Service or its balancer | Outside the cluster, as configured |
flowchart TD
I["Internet user"] --> LB["Load balancer address"]
LB --> NP["Node address and port"]
NP --> SV["Service ClusterIP"]
SV --> PD["Pod IP"]
Think of a shopping mall. The mall’s street address is the node, the store’s name on the directory is the Service, and the specific cashier who serves you at the counter is the pod.
13Special Cases Worth Knowing
A few situations bend the usual rules.
Host networking
A pod can be told to use the machine’s own network instead of getting a private address. It then shares the node’s IP, and its ports compete with everything else on the machine. This is sometimes used for system components that must see the node’s network, but is best avoided for ordinary applications.
Dual-stack addresses
Pods can hold both an older IPv4 address and a newer IPv6 address at the same time. This lets applications talk over either style as needed, and it is increasingly common as networks add IPv6 support.
Pods that never get an address
A pod that is still waiting to be placed on a machine, or whose network setup has failed, has no address yet. Its status will show no IP until networking succeeds.
Address reuse
Once a pod is gone, its address may be handed to a completely different pod later. Rules or records that still mention the old address may then apply to the wrong workload.
Multiple network interfaces
With special add-ons, a pod can be given extra network connections for advanced uses such as telecom or high-speed data paths. The primary pod IP still follows the normal rules.
14Security: Open Doors by Default
The flat network is convenient, and that convenience needs limits.
By default, any pod can usually talk to any other pod, in any namespace. That is friendly for getting started, but risky in production, because a single compromised pod could then probe every other pod in the cluster. Kubernetes provides Network Policies to restrict this, though they only take effect if the chosen network plugin supports them.
Default deny
Start by blocking all traffic to a namespace, then allow only the conversations you truly need.
Label-based rules
Write rules based on labels, not IP addresses, so they keep working as pods come and go.
Namespace boundaries
Limit traffic between namespaces, such as keeping a test area from reaching production.
Encrypted traffic
Use mutual encryption between services, often through a service mesh, so that captured traffic is useless.
An office where every door is unlocked is convenient until a stranger walks in. Network Policies are badge readers on the doors, allowing only the right people into each room.
Writing security rules that name specific pod IP addresses. Since addresses change and get reused, such rules quietly become wrong. Use labels instead.
15Monitoring and Troubleshooting Addresses
When networking misbehaves, follow a calm checklist.
Signals to watch
Address pool usage
How many addresses are used out of each node’s slice, and out of the whole range.
Pods stuck starting
Pods that stay in a creating state often point to network setup problems.
DNS response time and errors
Slow or failing name lookups make applications look broken even when pods are healthy.
Dropped or refused connections
A rise often points to policy mistakes or overloaded networking components.
A friendly troubleshooting path
Does the pod have an address?
Check the pod’s status. No address means network setup has not finished or has failed.
Is the application listening?
The pod may have an address but the program inside may not be listening on the expected port.
Does the Service see the pod?
Check that the Service’s list of endpoints includes the pod. A missing pod usually means a label mismatch or a failing readiness check.
Does DNS resolve?
From another pod, confirm that the Service name resolves to the right address.
Are policies blocking it?
Review Network Policies in both the source and destination namespaces.
Is the node network healthy?
Look at the plugin’s own health and at the nodes for missing routes or overloaded components.
16Advantages and Trade-offs of the Pod-IP Model
Giving every pod a real address is elegant, and it has costs.
Advantages
- Simple mental model: every pod is a first-class network citizen
- No port juggling between applications on the same machine
- Easy migration of software written for ordinary servers
- Works cleanly with service discovery, load balancing and DNS
- Supports many plugins with different strengths
- Direct pod-to-pod communication without translation
Disadvantages / Trade-offs
- Addresses are temporary, so direct use causes fragile designs
- Large clusters need large, well-planned address ranges
- Address exhaustion can stop new pods from starting
- Open-by-default networking needs deliberate lockdown
- Debugging spans several layers: pod, service, DNS, policy and plugin
17Anti-Patterns to Avoid
Mistakes that show up in many real clusters.
Problem
Hard-coding pod IP addresses in application settings, scripts or documentation.
Why It’s Harmful
The address changes when the pod is replaced. The application then fails, or connects to an unrelated pod that inherited the old address.
Correct Approach
Connect through Service names and DNS, and use stable pod names from stateful workloads when identity matters.
Problem
Choosing a small pod address range to save space when creating the cluster.
Why It’s Harmful
Growth eventually exhausts the range, and enlarging it later can be difficult or require rebuilding the cluster.
Correct Approach
Plan a generous range that fits expected growth and avoids overlap with other networks you may connect to.
Problem
Using host networking for ordinary applications to skip networking setup.
Why It’s Harmful
Ports collide with other workloads on the node, isolation is weaker and portability suffers.
Correct Approach
Give applications normal pod networking and expose them through Services.
Problem
Leaving the network fully open between all pods in production.
Why It’s Harmful
One compromised pod can scan and attack the rest of the cluster.
Correct Approach
Adopt default-deny policies and allow only necessary traffic using labels.
18Real-World Situations
How pod addressing shows up in daily engineering.
A shopping site during a sale
The number of web pods jumps from a handful to dozens in minutes. New pods receive addresses instantly and the Service starts sending them traffic once ready. Nobody edits any configuration, because clients use the Service name.
A rolling release
A new version replaces the old one gradually. Every replaced pod gives up its address and a new pod takes a fresh one, yet callers never notice because the Service adjusts its list of members.
A clustered database
A database with three members uses stable pod names so replicas can find the primary by name. When one member restarts with a new address, DNS updates its name to point to the new one.
A large cloud cluster running out of addresses
A team using a plugin that draws pod addresses from the cloud network notices new pods stuck starting. The address range was too small for the growth. The fix involves adding address space or changing the plugin’s allocation settings, a costly lesson in early planning.
A security review
An audit discovers that any pod in the cluster can reach the payment database. The team adds label-based network policies so only the payment service’s pods may connect.
19Best Practices Checklist
A short list to keep beside you.
Never depend on pod IPs
Use Services and DNS names for every connection between parts of your application.
Plan address ranges early and generously
Include room for growth, avoid overlaps with other networks, and document the choices.
Choose a CNI plugin that matches your needs
Consider policy support, performance, visibility and how it fits your cloud or data center.
Use readiness checks
So Services only send traffic to pods that are truly ready to answer.
Lock down traffic with policies
Start from default deny and open only what is needed, using labels rather than addresses.
Monitor address usage and DNS health
Alert before pools run low and when name lookups slow down.
Use stable identities only where needed
Stateful workloads and headless Services are for applications that truly need them.
20Frequently Asked Questions
Yes, in the normal setup. The one exception is a pod using host networking, which shares the machine’s address.
No. All containers in a pod share the pod’s single IP address and port space.
If only a container inside the pod restarts, the pod and its address stay the same. If the pod itself is replaced, the new pod gets a new address.
Usually not. Pod addresses are meant for use inside the cluster. To reach applications from outside, use a Service exposed through a load balancer, an Ingress or a temporary forwarding tool for debugging.
The CNI networking plugin on the node picks a free address from the slice reserved for that node.
A pod IP belongs to one pod and disappears with it. A ClusterIP belongs to a Service, stays the same for the Service’s life and forwards to whichever pods are currently behind it.
Not at the same time within one cluster. An address can be reused later after the earlier pod is gone.
Common causes are a label mismatch, a failing readiness check, a wrong port setting, or a network policy blocking the traffic.
New pods cannot be given addresses and remain stuck while starting. The remedy is more address space, or freeing addresses used by unneeded pods.
For short-lived debugging, yes. For anything that must keep working, use a Service name or a stable pod name instead.
21Summary and Key Takeaways
In Kubernetes, every pod receives its own IP address from a slice of a cluster-wide range, assigned by a networking plugin as the pod starts. All containers in the pod share that address, and any pod can reach any other directly. Yet these addresses are temporary and change whenever pods are replaced, so Kubernetes provides Services, DNS names and stable pod identities to give applications dependable ways to find each other. Learn to think of pod IPs as name tags for the moment, and Services and names as the permanent addresses.
Key Takeaways
- One IP per pod — every pod gets a unique address, shared by all of its containers.
- A flat network — any pod can reach any other pod directly, without address translation.
- Assigned from node slices — the cluster range is divided among nodes, and the CNI plugin hands out addresses from each node’s slice.
- Pod IPs are temporary — they change on replacement, updates, failures and scaling, so never hard-code them.
- Services give stability — a ClusterIP and DNS name stay constant while the pods behind them come and go.
- Stable identity is available when needed — headless Services and stateful workloads keep names steady even as addresses change.
- Plan and protect — size address ranges generously, lock down traffic with label-based policies, and monitor address usage and DNS health.