Introduction

Welcome back! Now that we’ve explored how individual containers communicate using Docker, it’s time to look at what happens when you run hundreds of them—across multiple machines.

This is where Kubernetes networking comes in.

In Docker, networking was mostly about bridging containers on the same machine. Kubernetes multiplies the challenge—containers (now in pods) are distributed across nodes, yet they still need to discover, connect, and exchange data reliably.

So why does this matter?

Because in any real-world Kubernetes cluster, networking isn’t just about sending packets—it’s about making distributed systems work. If pods can’t find each other, your apps won’t scale, your services won’t recover, and your architecture falls apart.

By the end of this article, you’ll be able to:

• Learn how pods communicate across nodes in a Kubernetes cluster
• Understand Kubernetes’ flat network model and what it enables
• See how overlay networks make seamless, scalable communication possible

Let’s lift the hood on Kubernetes networking—and see how it enables containers to talk like they’re next door, even when they’re worlds apart.

Kubernetes Networking Fundamentals

To understand Kubernetes networking, we first have to recognise something important:
It breaks the mold of traditional networking in fundamental ways.

In traditional environments, each application runs on a server with a fixed IP address. You know where things live. The infrastructure is relatively stable—and so is the network.

But Kubernetes introduces a new set of rules.

Applications now run in containers, inside Pods, on a fleet of dynamic nodes. These workloads are constantly starting, stopping, shifting locations—even scaling up and down on the fly. That changes everything.

It raises questions like:

• How can containers communicate reliably when they may move across machines?
• How is IP address management handled when hundreds of pods are created and destroyed every hour?
• What happens to connectivity when a container is destroyed and recreated during a rolling update?

These are not edge cases—they’re the default behaviours of Kubernetes.

And yet, somehow, it works.
Kubernetes makes all this possible through a unified, elegant networking model—starting with its most fundamental unit: the Pod.

Let’s begin there.

What is Kubernetes Pod Networking?

In Kubernetes, the core unit of deployment isn’t the container—it’s the pod.

A pod is a wrapper around one or more tightly coupled containers that need to run together on the same node. These containers share the same lifecycle, the same IP address, and the same localhost. This simple but powerful abstraction forms the foundation of everything Kubernetes does with networking.

Remember those hundreds of containers scattered across multiple machines? Kubernetes simplifies that chaos by grouping them into pods—manageable units that bring structure to scheduling, networking, and communication.

Let’s Visualise It

The diagram below shows four pods running across two nodes in a cluster. Some pods, like Pod 1 and Pod 3, have a single container. Others, like Pod 2 and Pod 4, contain multiple containers working together.

Each pod—regardless of how many containers it contains—gets:

• Its own IP address
• Its own localhost
• Its own network namespace

This design allows Kubernetes to treat pods like tiny virtual machines, each with its own identity and network boundary—even when they’re running on the same physical host.

How Networking Works Inside a Pod

When multiple containers live inside the same pod, they share:

• The same network namespace
• The same IP address
• The same port space

That means they can talk to each other using localhost:<port>, just like processes on the same machine.

🧠 Think of a pod like a shared apartment: each container is a roommate with its own job, but they all use the same Wi-Fi and enter through the same front door (the IP). Communication between them is instant and local.

This shared setup makes internal coordination easy—there’s no network wiring or configuration needed. They’re already connected.

What Comes Next

This design — grouping containers into pods — is Kubernetes’ first big unlock for container communication.
By letting containers share the same network space, it simplifies how tightly-coupled processes work together.

In the next section, we’ll take a closer look at how this works in practice:
How do containers inside the same pod actually communicate with each other?
Spoiler: it’s not networking as you know it—it’s even simpler.

How Do Containers Communicate in Kubernetes?

As we said in the previous section, when containers run inside the same pod, they don’t just share resources—they share the same network namespace.

This shared environment is Kubernetes’ first major networking feature—and it’s what enables seamless communication inside a pod.

In the diagram above, Pod 2 contained two containers.
Both containers use localhost to talk to each other, and they share the IP address 10.10.1.20.
From a networking perspective, it’s as if they’re just two processes running on the same machine.

This allows them to communicate seemlessly—fast, clean, and without complex configuration.

Let’s look at a real-world example. Imagine you’re building a web application with built-in logging:

• One container runs the web server on port 80
• Another runs a logging sidecar on port 8081

The web server simply sends logs to localhost:8081, and the logging container receives them instantly.

Because communication happens over localhost, there’s no NAT, no routing, and no network stack overhead.
It’s just simple, direct inter-process communication—which makes it incredibly fast and reliable.

But there’s a trade-off.

Containers in the same pod can’t bind to the same port.
If the logging sidecar is using port 8081, no other container in that pod can use it.
This means sidecars and co-located services need to coordinate their port usage carefully.

This kind of setup works perfectly for tightly coupled containers that need to work side by side.
But in a real Kubernetes cluster, containers often need to talk outside their pod—to other applications, services, and environments.

That’s where things start to get more interesting—and where Kubernetes’ broader networking model takes over.

In the next section, we’ll explore pod-to-pod communication across the cluster.

Understanding Pod-to-Pod Communication in Kubernetes

So far, we’ve seen how containers inside a pod talk using localhost.
But in a real-world application, pods don’t operate in isolation—they need to communicate with other pods across the cluster.
This is where Kubernetes’ networking model really starts to shine.

In Kubernetes, every pod gets its own unique IP address—one that’s routable across the entire cluster.
There’s no need for port mapping, NAT, or complex network setup. It’s direct, it’s seamless, and it’s consistent.

Let’s Walk Through the Diagram

In the diagram above, each pod is assigned a unique IP:

• Pod 1 → 10.10.1.10
• Pod 2 → 10.10.1.20
• Pod 3 → 10.10.1.30

These IPs work across all nodes in the cluster. It doesn’t matter if Pod 2 is on one machine and Pod 3 is on another—they can still talk directly.

🔴 The red dotted arrows show Pod 2 communicating with Pod 3.
⚫ The black arrows represent how each pod connects to an overlay network, which bridges the virtual pod network with the underlying physical infrastructure.

Architectural win:
There’s no need to map ports, create tunnels, or manually expose containers.
Every pod acts like it’s on the same flat network—even if it’s on the other side of the data centre.

What About Pod Restarts?

Pod IPs are ephemeral.
If a pod restarts, it often comes back with a new IP address.

That might sound like a deal-breaker—but Kubernetes handles it beautifully using internal DNS.

For example:
Instead of calling 10.10.1.30 directly, another pod can simply use a DNS name like:

1

orderservice.default.svc.cluster.local

Kubernetes keeps that name up to date behind the scenes.
Your application code doesn’t care if the pod restarts—the name always points to the right IP.

We’ll dive deeper into how DNS and Services work in a future article. For now, just know: Kubernetes makes discovery effortless.

Key Takeaways

• Each pod has its own unique IP address
  Routable across the entire cluster—no NAT, no port mapping required.

• Pods can communicate directly across nodes
  The overlay network makes location irrelevant.

• Pod IPs are temporary, but Kubernetes provides stable names
  DNS ensures reliable communication, even when pods restart or scale.

All of this is made possible by one of Kubernetes’ boldest design choices:
the flat network model.

Let’s take a closer look at what that means—and why it changes everything.

The Kubernetes Flat Network Model Explained

Up until now, we’ve looked at pod-to-pod communication in Kubernetes. But what makes this seamless connectivity possible isn’t magic—it’s a bold design philosophy called the flat network model.

Kubernetes doesn’t just connect pods—it redefines how we think about networking in distributed systems. Traditional infrastructure relies on fixed hosts, complex routing rules, and address translations. Kubernetes throws those assumptions out the window.

Traditional Networking: A Rerouting Maze

In a typical data centre, if one application wants to talk to another on a different machine, that communication passes through multiple layers—routing tables, NAT rules, firewall rules, sometimes even VPNs.
It’s like sending a package that needs to be relabelled and rerouted through several post offices before reaching its destination. Functional, yes. But slow, brittle, and complex.

Kubernetes: One Big Virtual Switch

Kubernetes takes a radically simpler approach: every pod gets its own unique IP address, and every pod can reach every other pod directly, regardless of the node it’s running on.
There’s no NAT, no port remapping, no routing gymnastics. From a pod’s point of view, every other pod looks like it’s on the same LAN.

Let’s look at this visually:

In the diagram above, all pods—whether they’re on Node 1 or Node 2—receive IP addresses in the same range (10.10.1.x).
Pod 1 is 10.10.1.10, Pod 2 is 10.10.1.20, Pod 3 is 10.10.1.30.
The red arrows show how Pod 2 talks to Pod 3 directly across the overlay network, while the black arrows represent the underlying physical network.
It doesn’t matter where the pods are physically located—the network appears flat, unified, and fully connected.

Why This Model Matters

Scalable by Default

Kubernetes’ flat network model is built for growth.
Add new nodes? No problem—pods on new nodes automatically join the same network.
Move pods around the cluster? Their communication stays the same.
The network doesn’t just tolerate scaling—it embraces it.

Developer-Friendly Simplicity

Your applications don’t need to care about which node a peer is running on.
No manual route configuration. No port mapping. No host awareness.
Just use a pod’s IP—or more commonly, its service name—and Kubernetes handles the rest.

Think of it like a giant LAN party: every pod, no matter where it’s hosted, feels like it’s plugged into the same switch.

One More Complexity Eliminated: NAT

Because Kubernetes traffic flows directly between pods—with no middlemen—it removes the need for Network Address Translation (NAT) altogether.

That’s a huge win.
Let’s take a closer look at how Kubernetes eliminates NAT, and why that makes your infrastructure more predictable and resilient.

How Kubernetes Eliminates Network Address Translation (NAT)

NAT is everywhere. It’s how your home network connects to the internet. But in Kubernetes, NAT isn’t just unnecessary—it’s a liability.

Let’s start by looking at how NAT works in the real world, and why Kubernetes deliberately avoids it.

NAT in the Real World: A Quick Recap

Imagine your home network. Your phone, laptop, and smart TV each have a private IP like 192.168.1.x. These IPs work only inside your home. When one of these devices connects to the internet, your router rewrites the source IP into your home’s public IP. That’s Network Address Translation.

This works well because:

• It conserves scarce public IP addresses
• It allows multiple devices to share a single outward-facing IP
• Every household can reuse the same private IP range (192.168.0.0/16)
• Devices in the same house can talk to each other directly

This is why NAT is a great solution—for homes.

Why NAT Breaks Down in Kubernetes

Now imagine applying that model inside a Kubernetes cluster.

Let’s say your frontend pod needs to talk to an order processing pod:

• The frontend pod would need its IP translated every time it sends traffic
• You’d need NAT tables across every node to track all the mappings
• If a pod moves or restarts, the NAT rules break
• And if something goes wrong, debugging becomes a nightmare—you’re chasing phantom IPs

In a dynamic, fast-moving system like Kubernetes, NAT adds overhead, complexity, and fragility.

Kubernetes Says: No More NAT

Kubernetes takes a cleaner, bolder approach:

• Every pod gets a real IP address, valid across the entire cluster
• Pods can talk directly—no port mapping, no address rewriting
• No NAT tables to maintain
• No hidden translation state
• No additional routing complexity

This isn’t just a technical detail—it’s a strategic design choice.

By eliminating NAT, Kubernetes networking becomes:

• Simple: No rewriting or side tables
• Predictable: IP addresses mean what they say
• Powerful: Communication works, even as pods move or scale

Key Takeaway
Kubernetes eliminates NAT by assigning each pod a routable IP.
Traffic flows directly between pods—no translation, no tracking, no traps.
Just clean, first-class networking.

But Wait—How Does That Work?

You might be wondering: if pods are spread across different machines, possibly even different networks, how can this direct communication still happen?

The answer lies in a clever abstraction: overlay networks.

And behind those networks is one of Kubernetes’ most important technologies—
the Container Network Interface (CNI).

Let’s take a closer look at how it works.

What is the Container Network Interface (CNI)?

So far, we’ve seen how Kubernetes should work: direct pod-to-pod communication, no NAT, and a unified flat network model. But here’s the catch—Kubernetes doesn’t implement any of that itself.

Instead, it delegates the responsibility of networking to something called the Container Network Interface, or CNI.

Think of CNI as a standardised contract. When Kubernetes needs to create a pod, it calls on a CNI plugin to handle the networking—assigning IPs, configuring routing, and plugging the pod into the cluster network.

This design follows a principle at the heart of Kubernetes architecture: separation of concerns.
Kubernetes orchestrates containers. CNI orchestrates networking.
Each focuses on its role, and together, they scale.

Why This Matters

By using a standard interface like CNI, Kubernetes stays flexible:

• Networking experts can build powerful, pluggable solutions
• Users can choose the network that fits their use case
• Kubernetes doesn’t reinvent the wheel—it leverages existing expertise

This modularity gives you freedom and consistency at the same time.

Popular CNI Plugins

There are many CNI plugins out there, each with its strengths. Some of the most widely used include:

• Calico – Policy-driven networking with strong security enforcement
• Flannel – Lightweight and simple overlay networking, great for smaller clusters
• Cilium – High-performance networking powered by eBPF, with deep observability and modern security

Each of these plugins implements the same CNI contract, meaning they can all plug into Kubernetes clusters the same way—regardless of how different their internal designs are.

How CNI Plugins Enable Pod Networking

When you deploy a pod, here’s what happens under the hood:

1. Kubernetes schedules the pod onto a node
2. The CNI plugin assigns it a unique IP
3. The plugin connects the pod to the cluster’s overlay network
4. It updates the routing so the pod can send and receive traffic across nodes
5. The pod becomes fully reachable within the cluster, just like any other

And the best part? This entire sequence happens automatically.

CNI in Action

Every time a pod is created, Kubernetes triggers the CNI plugin behind the scenes.
The plugin:

• Assigns the pod an IP address
• Connects it to the virtual network
• Ensures it can talk to other pods, no matter where they run

You don’t write this code. You just install the right plugin when setting up your cluster, and Kubernetes takes it from there.

What’s Next: Overlay Networks

But how does this work when pods live on different machines—or even different networks?

That’s where overlay networks come in—an elegant solution that allows pods to communicate as if they’re on the same subnet, even when they’re not.

In the next section, we’ll explore how overlay networks help create that illusion—and make Kubernetes networking as seamless as it feels.

Understanding Overlay Networks in Kubernetes

Kubernetes networking creates a powerful illusion: that all your pods are on the same network—even if they’re running on opposite sides of the planet.

They send data directly, reliably, and without needing to know where the other pod physically lives.

This illusion is made possible by one of Kubernetes’ most elegant innovations: the overlay network.

Visualising the Overlay

Let’s look at the diagram above.
At a glance, you’ll see:

• Pods with IPs like 10.10.1.10, 10.10.1.20, 10.10.1.30
• Spread across Node1 and Node2
• Connected via red dotted arrows that represent traffic flowing through the overlay
• And beneath that, black arrows representing the physical network underneath

Even though Node1 might be in New York and Node2 in London, Kubernetes makes them feel like next-door neighbours.

Overlay Network Analogy: Tunnels Under a City

Think of an overlay network like a system of high-speed tunnels beneath a city.

Above ground, buildings (nodes) are far apart, divided by roads, infrastructure, and even entire regions.
But underground, those tunnels connect buildings directly—bypassing all surface complexity.

People (packets) can move through them as if the buildings were side-by-side.
From inside the tunnel, it feels like everything is local—even if it’s not.

Real-World Example: Shipping Data Across the World

In our e-commerce application:

• The frontend pod on Node1 (New York) prepares a data packet for the order processing pod on Node2 (London)
• The local CNI plugin wraps this packet inside another—like placing a letter into a bigger envelope
• The outer envelope is addressed to the destination node in London
• The packet travels through the physical network (the global “postal” system)
• When it arrives, the CNI plugin on Node2 unwraps the outer envelope and delivers the original packet
• To the order processing pod, it looks like it came from right next door

The illusion is complete.
The frontend pod sent traffic to a global destination—and the receiving pod had no idea it travelled so far.

IP Encapsulation: The Technical Magic

This clever trick is called IP encapsulation—a well-known networking technique where one IP packet is wrapped inside another.

Here’s how it plays out:

1. A pod sends data → it first goes to the CNI plugin
2. The plugin wraps the original IP packet (source = frontend pod, dest = order pod) inside a second packet addressed to the destination node
3. The outer packet traverses the physical network
4. The destination plugin unwraps the outer layer and delivers the original packet

The reply follows the same process in reverse.
No matter where the pods run, they act like they’re on the same subnet.

The Role of the CNI Plugin: Silent Orchestrator

This entire overlay mechanism is powered by your CNI plugin.
It doesn’t just assign IPs.

It:

• Builds dynamic tunnels between nodes
• Wraps and unwraps every packet with IP encapsulation
• Routes traffic through the physical infrastructure
• Maintains the illusion of a single, flat network

The black arrows in our diagram show pods handing traffic off to their local CNI plugin.
That’s where the real magic happens.

Why Overlay Networks Matter

Thanks to overlay networks:

• The flat network model becomes real, even across geographies
• Pod-to-pod communication works across any node, anywhere
• NAT is eliminated—pods use their real IPs, not translated ones
• CNI handles the complexity, so you don’t have to

Overlay networks are what allow Kubernetes networking to scale from a single machine to a global multi-cloud cluster—with no changes to your pod definitions.

They abstract away the mess of physical routing, and give you a clean, consistent, developer-friendly experience.

With that, we’ve covered the final building block of Kubernetes networking.

Let’s step back and reflect on what we’ve learned in the Conclusion.

Conclusion: From Complexity to Clarity

You’ve just navigated one of the most complex parts of Kubernetes—and come out the other side with clarity.
What once seemed like magic is now something you can explain, visualise, and reason through.

We began with a fundamental challenge:

How do you connect thousands of ephemeral containers running across a fleet of machines, without chaos?

Kubernetes answers that question through five powerful design choices:

• Pods group containers into a shared networking space
• Flat network model makes every pod directly reachable, no port mapping required
• NAT-free architecture removes translation overhead and debugging pain
• CNI plugins handle IP assignment, routing, and encapsulation behind the scenes
• Overlay networks turn global clusters into what feels like a single, local network

But what makes this truly remarkable isn’t just the technology—it’s the system thinking behind it.

Kubernetes networking is a masterclass in simplicity through composition.
Each layer—Pods, CNI, overlays, the NAT-free model—does one job well.
And together, they absorb complexity so your applications don’t have to.

Complexity isn’t avoided.
It’s abstracted, composed, and orchestrated into something seamless.

That’s the beauty of infrastructure done right.

But connectivity alone isn’t enough. In real-world systems, we don’t just want everything to talk—we want control over who can talk to whom.

That’s where Kubernetes Network Policies come in.

In the next article, we’ll explore how to:

• Define access rules at the pod level
• Secure internal traffic flows
• Build clusters that are not just connected—but protected

Until then, remember:

Great infrastructure doesn’t just connect.
It communicates with purpose.