DEV Community: ADITYA RAJ

Kubernetes Networking [Level-9: Kubernetes Networking Internals]

ADITYA RAJ — Mon, 24 Aug 2026 11:02:43 +0000

This is Level 9 of our Kubernetes networking series — and it's where everything we've learned finally converges into a single story. In earlier levels, we mostly viewed networking from the outside:

Pod → Service → Pod

Now we're going inside the Node, following one packet through the actual Linux kernel:

Network namespace
   ↓
veth
   ↓
Linux kernel
   ↓
routing
   ↓
iptables / eBPF / IPVS
   ↓
conntrack / NAT
   ↓
veth
   ↓
destination Pod

The goal of this article is simple: understand what actually happens to a packet inside a Kubernetes Node.

The Complete Picture, First
Network Namespaces, Revisited
The veth Pair
Why eth0 Is Confusing
Pod → Node: The Core Diagram
Linux Routing Inside the Pod
Routing Is a Decision, Not Magic
Same-Node Pod Communication
The Linux Bridge
What Happens When the Packet Reaches the Node
Direct Pod Traffic vs Service Traffic
Netfilter: Linux's Packet-Processing Framework
Where iptables Fits In
NAT, Revisited With a Real Example
Why NAT Needs State
conntrack: Connection Tracking
Why conntrack Matters in Production
A Simplified Linux Packet Path
There's No Single Universal Packet Path
Pod-to-Pod, Same Node
Pod-to-Pod, Different Nodes
Overlay Internals
Why Overlays Exist
Routing-Based Networking
Why BGP Sometimes Appears
CNI vs the Linux Kernel
eBPF in the Internal Path
NetworkPolicy in the Packet Path
Service + NetworkPolicy Together
Why Services Don't Have Network Interfaces
Node IP vs Pod IP vs Service IP
Why Pod IPs Aren't Directly Routable from the Internet
A Full External Traffic Example
The Complete Kubernetes Networking Stack
A Real Packet Journey, Start to Finish
Return Traffic
What Can Break
The Most Important Troubleshooting Principle
Direct Pod IP vs Service IP: The Best Diagnostic Test
Useful Linux Commands
Interview Traps Worth Knowing
The Entire Series So Far
Level 9 Checkpoint
The Most Important Lesson From This Article
What's Next: Production Troubleshooting

The Complete Picture, First

Let's set up a running example. A Frontend Pod (10.244.1.10) calls backend.default.svc.cluster.local. DNS resolves this to 10.96.120.50. The backend Pods are 10.244.1.20, 10.244.2.20, and 10.244.3.20.

The logical path looks simple:

Frontend Pod (10.244.1.10)
      ↓
Service IP (10.96.120.50)
      ↓
Service dataplane
      ↓
Backend Pod (10.244.2.20)

But physically, inside Linux, there's a lot more going on — and that's exactly what this article unpacks.

Network Namespaces, Revisited

A Pod gets its own network namespace — think of it as a completely separate networking world inside Linux, with its own interfaces, IP addresses, routes, and network state:

Pod network namespace
┌─────────────────────────┐
│ eth0                    │
│ 10.244.1.10             │
│ route table             │
└─────────────────────────┘

The Node itself lives in its own, separate network namespace:

Node network namespace
┌─────────────────────────┐
│ eth0                    │
│ cni interfaces          │
│ routes                  │
│ iptables/eBPF           │
└─────────────────────────┘

The key takeaway: Pod namespace ≠ Node namespace. They're isolated from each other by design.

The veth Pair

How do these two isolated worlds talk to each other? Commonly, through a veth pair — a virtual Ethernet cable:

Pod namespace                 Node namespace

┌──────────────┐             ┌──────────────┐
│    eth0      │=============│   vethXXXX   │
└──────────────┘             └──────────────┘
                    ↑
                 veth pair

One end lives inside the Pod's namespace; the other lives inside the Node's namespace.

Why eth0 Is Confusing

Inside the Pod, ip addr shows eth0 at 10.244.1.10. But on the Node itself, you generally won't find another interface also called eth0 representing that same Pod. Instead, the Node-side end typically has an implementation-specific name, like vethabc123:

Pod:  eth0
Node: vethabc123

These two differently-named ends form a single virtual Ethernet connection between the two namespaces.

Pod → Node: The Core Diagram

The simplest possible mental model, and one of the most important diagrams in all of Kubernetes networking:

Pod → eth0 → veth → Node

Linux Routing Inside the Pod

Once a packet is inside the Pod, with source = 10.244.1.10 and destination = 10.244.2.20, the Pod's network namespace needs to decide: where should this go? Linux answers that using its routing table, viewable with:

ip route

Conceptually:

Destination       Next hop
10.244.1.0/24      local
default            ...

The exact contents depend entirely on your CNI implementation.

Routing Is a Decision, Not Magic

Think of the routing table as a map:

Packet destination (10.244.2.20)
        ↓
Routing table
        ↓
Which route matches?
        ↓
Which interface/next hop?

The core principle: Linux always chooses the most specific matching route.

Same-Node Pod Communication

Suppose Pod A (10.244.1.10) and Pod B (10.244.1.20) are both on Node 1:

Pod A → eth0 → veth → Node networking → veth → eth0 → Pod B

There might be a Linux bridge, straightforward routing, eBPF processing, or something else entirely in the middle — it depends on the CNI. Don't memorize "every Kubernetes cluster uses a bridge" — that's simply false. The correct mental model is: the CNI/networking implementation provides a path between the Pod namespaces, using whatever mechanism it's designed around.

The Linux Bridge

A common Linux networking component is the bridge — think of it as a virtual Layer-2 switch:

             Linux bridge
          ┌───────────────┐
          └─┬─────┬─────┬─┘
            │     │     │
          veth   veth   veth
            │     │     │
          Pod A Pod B Pod C

A bridge can connect multiple interfaces at Layer 2. But again — not every CNI uses a Linux bridge as its main datapath. Some rely on routing, overlays, cloud-native networking, or eBPF instead.

What Happens When the Packet Reaches the Node

Suppose Pod A (10.244.1.10) sends a packet destined for 10.244.2.20. The packet exits through eth0 and arrives at the Node's networking stack — and this is exactly where Level 8 becomes relevant again. From here, the packet may pass through routing, iptables, IPVS, eBPF, conntrack, and/or NAT, depending on the implementation.

Direct Pod Traffic vs Service Traffic

It's worth comparing two very different packets side by side.

Direct Pod-to-Pod:

Pod A → Pod B
Destination: 10.244.2.20

Service traffic:

Pod A → Service → Pod B
Destination (initially): 10.96.120.50

The second path requires Service handling — the Service dataplane has to translate 10.96.120.50 → 10.244.2.20 before normal Pod-to-Pod delivery can even begin. This is exactly why Service traffic is more involved than plain Pod-to-Pod traffic.

Netfilter: Linux's Packet-Processing Framework

Now for a foundational Linux concept: Netfilter. Netfilter is Linux's framework of packet-processing hooks — tools and features like iptables, NAT, and conntrack all interact with this underlying infrastructure:

Packet
   ↓
Linux networking stack
   ↓
Netfilter hooks
   ↓
filter / NAT / connection tracking
   ↓
routing / forwarding

Modern systems may use nftables underneath familiar iptables tooling depending on the environment, but the conceptual Linux packet-processing framework — Netfilter — remains the important idea to hold onto.

Where iptables Fits In

From Level 8, we know: Service → iptables → backend. Now we can place it precisely within the kernel's processing pipeline:

Packet → Linux kernel → Netfilter → iptables rules → NAT / filtering / Service handling

Kubernetes programs networking rules directly into this pipeline on each Node.

NAT, Revisited With a Real Example

Let's revisit NAT concretely. A client sends SRC = 10.244.1.10, DST = 10.96.120.50:80. The Service dataplane selects a backend, say 10.244.2.20:80:

10.96.120.50:80
        ↓
      DNAT
        ↓
10.244.2.20:80

The destination changes — that's Destination NAT in action.

Why NAT Needs State

Now suppose Client → Service → Backend, and the response needs to travel Backend → Client. The kernel needs to remember the original translation to correctly map the response back. That's exactly what conntrack provides.

conntrack: Connection Tracking

conntrack is short for connection tracking — Linux's mechanism for maintaining state about active network connections. Given Client (10.244.1.10:50000) → Service (10.96.120.50:80) → Backend (10.244.2.20:80), the kernel tracks the relevant connection and NAT state:

Connection → conntrack → NAT state → return traffic handled correctly

Why conntrack Matters in Production

This is a major real-world troubleshooting topic. You can end up in situations where new connections start failing, or existing connections start behaving unexpectedly — both can trace back to connection tracking / NAT state. At scale, conntrack itself becomes a resource with real limits. Watch for: conntrack table exhaustion, dropped connections, NAT failures, and intermittent connectivity. We'll dig into these production failure modes much more deeply in Level 10.

A Simplified Linux Packet Path

For a packet entering a Node, a simplified path looks like:

Network interface
       ↓
Linux kernel
       ↓
packet processing
       ↓
routing decision
       ↓
forwarding / local delivery
       ↓
destination interface

For Kubernetes specifically, additional processing frequently includes iptables, conntrack, NAT, eBPF, NetworkPolicy enforcement, and Service load balancing — depending entirely on the networking implementation in use.

There's No Single Universal Packet Path

This point is critical enough to repeat explicitly: there is no single universal Kubernetes packet path. Clusters can use iptables, IPVS, eBPF, plain routing, overlays, cloud-native networking, or entirely different CNIs — and each combination produces a genuinely different path. The right approach is: learn the conceptual packet path first, then learn the implementation-specific path for your actual cluster. This is precisely how experienced engineers troubleshoot Kubernetes networking in the real world.

Pod-to-Pod, Same Node

The easiest case: Pod A (10.244.1.10) and Pod B (10.244.1.20) on the same Node.

┌────────── Pod A ──────────┐
│ eth0 (10.244.1.10)        │
└────────────┬──────────────┘
             │
           veth
             │
             ↓
       Node networking
             │
             ↓
           veth
             │
┌────────────┴──────────────┐
│ eth0 (10.244.1.20)        │
└────────── Pod B ──────────┘

The exact middle processing depends entirely on the CNI implementation.

Pod-to-Pod, Different Nodes

Now Pod A (10.244.1.10) is on Node 1 and Pod B (10.244.2.20) is on Node 2:

Pod A → veth → Node 1 → Node-to-Node network → Node 2 → veth → Pod B

The Node-to-Node portion can be implemented via routing, an overlay, a cloud provider's native network, or eBPF — again, entirely dependent on the CNI.

Overlay Internals

Suppose the CNI uses an overlay. The inner packet is Pod A → Pod B, and it gets wrapped inside an outer packet Node 1 → Node 2:

┌───────────────────────────────┐
│ Outer packet: Node1 → Node2   │
│                               │
│   ┌─────────────────────────┐ │
│   │ Inner packet:           │ │
│   │ Pod A → Pod B           │ │
│   └─────────────────────────┘ │
└───────────────────────────────┘

Node 2 strips off the outer wrapper and delivers the inner packet toward Pod B. That's the basic idea behind overlay networking, made concrete.

Why Overlays Exist

Imagine your physical network only knows about Node 1 (192.168.1.10) and Node 2 (192.168.1.20) — it has no idea about 10.244.1.10 or 10.244.2.20. The physical network doesn't need to know about every individual Pod route; instead, the overlay carries the Pod network inside the Node network — literally, a network running over another network.

Routing-Based Networking

An alternative to overlays: teach the physical network how to reach each Pod CIDR directly. Given Node 1 → 10.244.1.0/24 and Node 2 → 10.244.2.0/24, Node 1 can simply have a route: 10.244.2.0/24 → Node 2. Then:

Pod A → Node 1 → route → Node 2 → Pod B

No encapsulation required at all.

Why BGP Sometimes Appears

If many Nodes each own different Pod CIDRs, you need a way to distribute all those routes across the cluster. Some networking implementations use BGP (Border Gateway Protocol) for exactly this:

Node 1 (10.244.1.0/24) ↔ BGP ↔ Node 2 (10.244.2.0/24)

This is exactly why BGP comes up so often in discussions of Calico and Kubernetes networking.

CNI vs the Linux Kernel

An important distinction: the CNI/networking implementation doesn't replace Linux networking — it configures and uses it.

CNI → configure → Linux networking → interfaces / routes / kernel dataplane

For example: CNI → create veth → Linux kernel, or CNI → configure routes → Linux kernel, or CNI → load eBPF programs → Linux kernel. The CNI is the orchestrator; the kernel is what actually does the work.

eBPF in the Internal Path

Connecting Level 8 back to Level 9: with an eBPF-based CNI, packet processing might conceptually look like:

Pod → veth → Linux kernel → eBPF program → routing / policy / load balancing → destination

The exact hook points and processing path depend on the specific implementation. The core concept to hold onto: eBPF lets a networking implementation inject programmable packet-processing logic directly into the Linux kernel.

NetworkPolicy in the Packet Path

Suppose a NetworkPolicy states frontend → backend:8080 = ALLOW. The networking implementation has to enforce that somewhere along the path:

Packet → network dataplane → NetworkPolicy check → ALLOW → Backend

or, alternatively:

Packet → NetworkPolicy check → DENY → ✗

The exact enforcement point in the kernel depends on the implementation.

Service + NetworkPolicy Together

Now combine Service and NetworkPolicy. The Service selects backend Pods; NetworkPolicy applies restrictions to those Pods:

Frontend → Service IP → Service dataplane → Backend Pod → NetworkPolicy enforcement

The exact ordering within the kernel can vary by implementation — don't treat this as a strict, universal literal sequence. The important conceptual point: the Service selects and forwards toward backend Pods; NetworkPolicy controls what Pod traffic is actually allowed.

Why Services Don't Have Network Interfaces

An excellent interview question. You might assume the Service IP 10.96.120.50 must correspond to some eth0 somewhere — but that's usually the wrong way to think about it. A ClusterIP is a virtual IP implemented by the Service dataplane, not a physical interface:

ClusterIP (10.96.120.50) → virtual service → backend endpoints

It simply doesn't need to be — and usually isn't — a physical network interface anywhere.

Node IP vs Pod IP vs Service IP

By Level 9, you should be completely comfortable distinguishing:

Node IP    (192.168.1.10)  → physical/VM host networking
Pod IP     (10.244.1.10)   → workload networking
Service IP (10.96.120.50)  → virtual service endpoint

Three distinct layers, each solving a different problem.

Why Pod IPs Aren't Directly Routable from the Internet

A Pod's IP, like 10.244.1.10, is generally an internal cluster address — an internet router has no idea how to reach 10.244.1.0/24. That's exactly why external access normally has to go through a LoadBalancer, NodePort, Ingress, Gateway, NAT, or some form of cloud-native networking, depending on your architecture.

A Full External Traffic Example

Internet
    ↓
Public IP
    ↓
Load Balancer
    ↓
Node
    ↓
Service dataplane
    ↓
Pod

Zooming into the Node itself: Node → iptables/IPVS/eBPF → Pod. And zooming into the Pod: Pod namespace → eth0 → veth → Node. Now you can see exactly how all these layers connect into one continuous path.

The Complete Kubernetes Networking Stack

This is the single diagram worth remembering from this entire article:

                         INTERNET
                            |
                            ↓
                    LoadBalancer / Ingress
                            |
                            ↓
                         Node
                            |
                ┌───────────┴───────────┐
                │ Linux kernel          │
                │                       │
                │ Service dataplane     │
                │ iptables / IPVS /     │
                │ eBPF                  │
                │                       │
                │ conntrack / NAT       │
                │                       │
                │ routing               │
                └───────────┬───────────┘
                            |
                          veth
                            |
                     Pod namespace
                            |
                           eth0
                            |
                           Pod

And across Nodes: Pod → veth → Node 1 → Node-to-Node network → Node 2 → veth → Pod.

A Real Packet Journey, Start to Finish

Let's trace one complete, concrete example. We have Frontend Pod 10.244.1.10, Backend Service 10.96.120.50:80 (with port: 80, targetPort: 8080), and Backend Pod 10.244.2.20:8080. The frontend runs curl http://backend.

Step 1 — DNS: backend → 10.96.120.50.

Step 2 — TCP connection: the frontend creates a packet with SRC = 10.244.1.10:<ephemeral-port>, DST = 10.96.120.50:80.

Step 3 — Pod namespace routing: the packet leaves through the Pod's eth0 and crosses the veth pair.

Step 4 — Node kernel: the Node's networking stack now processes it — potentially involving routing, conntrack, the Service dataplane, NetworkPolicy, and NAT, depending on the implementation and packet path.

Step 5 — Service translation: the Service dataplane knows 10.96.120.50:80 should map to 10.244.2.20:8080, and performs that translation.

Step 6 — Route to backend: the networking layer determines how to actually reach 10.244.2.20 — if the backend lives on another Node, this involves Node 1 → Node network → Node 2.

Step 7 — Backend Node: Node 2 receives the packet, processes it through its own networking implementation, and delivers it: veth → Pod namespace → eth0 → backend application.

Return Traffic

The backend responds: Backend (10.244.2.20:8080) → Frontend (10.244.1.10:<port>). The Linux networking stack's NAT and connection-tracking state ensures the response correctly maps back through the original Service connection. Crucially, the frontend application never needs to know the backend Pod's real IP was 10.244.2.20 — it only ever knew it connected to backend:80. That abstraction is the entire point.

What Can Break

We're now firmly in production troubleshooting territory. This full packet journey can fail at many distinct points:

DNS → Service → EndpointSlice → Service dataplane → routing → CNI → NetworkPolicy → Pod → application

Possible failure modes include: DNS not resolving, a Service with no endpoints, a wrong targetPort, incorrect iptables/IPVS/eBPF state, a missing route, a broken veth, a Pod with no IP, a CNI failure, NetworkPolicy blocking traffic, conntrack problems, a Node-level firewall, a cloud network ACL or security group, or simply an application that isn't listening. This is exactly why Level 10 will feel much more approachable after this article.

The Most Important Troubleshooting Principle

Don't ask: "Kubernetes networking is broken — what command should I run?" Instead ask:

"At which hop did the packet actually stop?"

For example, if DNS works, the Service exists, the endpoint exists, and the Pod IP is directly reachable — but the Service IP specifically fails — that strongly points toward the Service dataplane, not CNI. Alternatively, if Pod IP → Pod IP fails outright, that points much more toward CNI, routing, or NetworkPolicy.

Direct Pod IP vs Service IP: The Best Diagnostic Test

This single comparison is one of the most valuable troubleshooting techniques in Kubernetes networking. Test Pod A → Pod B IP directly, then test Pod A → Service IP.

If the Pod IP works but the Service IP fails: the likely culprit is the Service, its EndpointSlice, or the Service dataplane (kube-proxy/eBPF).

If both the Pod IP and the Service IP fail: investigate lower layers instead — CNI, routing, veth, NetworkPolicy, or Node networking.

This simple two-step comparison narrows down the problem space dramatically before you touch a single low-level command.

Useful Linux Commands

Inside a Pod:

ip addr    # interfaces/IPs
ip route   # routes
ss -lntp   # listening TCP sockets

On a Node:

ip addr
ip route
ip link

These commands together help you understand exactly what interfaces, addresses, and routes actually exist at each layer.

Seeing veth Interfaces

On a Node, ip link may reveal interfaces belonging to Pod networking — often named veth... or something CNI-specific. Don't assume any particular naming pattern always maps to a specific CNI; interface naming is implementation-dependent.

Seeing Routes

ip route on a Node may show entries like 10.244.1.0/24 ... and 10.244.2.0/24 ..., telling Linux exactly where Pod traffic should be directed. Again, the actual routes present depend entirely on your CNI.

Seeing iptables

If your cluster uses an iptables-based dataplane:

iptables-save

This can reveal a large volume of Kubernetes-related networking state, including Kubernetes-specific chains. Don't worry about memorizing chain names yet — just understand conceptually that iptables rules → Service / NAT / filtering behavior.

Seeing IPVS

If your cluster uses IPVS:

ipvsadm -L

This may show virtual services and their backend destinations, conceptually:

10.96.120.50:80
       +--- 10.244.1.20:80
       +--- 10.244.2.20:80
       +--- 10.244.3.20:80

Seeing eBPF

If your cluster uses an eBPF-based implementation like Cilium, its own tooling can show endpoints, routes, service maps, policy state, and connectivity — the exact commands vary by implementation. The key Level 9 lesson here: don't inspect iptables just because you happen to know iptables — first determine which dataplane your cluster actually uses.

Interview Traps Worth Knowing

"Does every Kubernetes cluster use kube-proxy?"
No. Many clusters do, but alternative networking dataplanes can implement Kubernetes Service functionality without it — an eBPF-based implementation can provide full kube-proxy replacement.

"Does every CNI use a Linux bridge?"
No. Possible approaches include bridging, routing, overlays, cloud-native networking, and eBPF — the implementation determines the actual datapath.

"Is the Service IP configured on a Pod?"
No. A ClusterIP is a virtual Service address implemented by the Service dataplane; backend Pods each have their own separate, real IPs.

"Does the CNI forward Service traffic?"
The precise answer: CNI/networking provides Pod networking, while Kubernetes Service traffic is implemented by a separate Service dataplane — kube-proxy/iptables/IPVS, or an eBPF-based networking implementation. The exact packet path depends on the cluster. That's a far better answer than simply saying "CNI handles everything."

The Entire Series So Far

We can now connect all nine levels into one continuous story:

LEVEL 0 — Linux networking      → interfaces / routes / namespaces / NAT
LEVEL 1 — Pod networking        → Pod namespace / eth0 / veth
LEVEL 2 — Pod-to-Pod            → routing / node networking
LEVEL 3 — Services              → ClusterIP / endpoints
LEVEL 4 — DNS                   → Service name → ClusterIP
LEVEL 5 — Ingress / Gateway     → external HTTP/HTTPS → Service
LEVEL 6 — NetworkPolicy         → allowed network traffic
LEVEL 7 — CNI                   → Pod network implementation
LEVEL 8 — Service dataplane     → kube-proxy / iptables / IPVS / eBPF
LEVEL 9 — Internals             → Linux kernel packet path

Level 9 Checkpoint

1. What is a network namespace?
An isolated Linux networking environment with its own interfaces, addresses, routes, and network state.

2. What is a veth pair?
A pair of virtual Ethernet interfaces commonly used to connect a Pod's network namespace to the Node.

3. What is a Linux bridge?
A virtual Layer-2 switch that can connect multiple interfaces together.

4. Does every CNI use a bridge?
No.

5. What is routing?
The process of deciding where a packet should be sent, based on its destination address.

6. What is DNAT?
Changing a packet's destination address/port — the common Kubernetes example is Service IP → backend Pod IP.

7. What is SNAT?
Changing a packet's source address/port — a common example is Pod IP → Node IP when traffic leaves the cluster, depending on configuration.

8. What is conntrack?
Linux's connection tracking mechanism, which maintains state about network flows, including NAT state.

9. What is an overlay?
A virtual network carried on top of another underlying network — a Pod network riding over a Node network.

10. Why can BGP be used?
To distribute routing information, such as routes to individual Pod CIDRs, across Nodes.

11. Why doesn't every Kubernetes cluster have the same packet path?
Because networking implementations and dataplanes genuinely differ from cluster to cluster.

12. How should you troubleshoot?
Find the first hop where the packet actually stops.

The Most Important Lesson From This Article

Don't memorize: "packets always go through iptables → bridge → veth." That's far too simplistic and, frankly, often wrong. Instead, memorize the general shape:

Pod namespace
     ↓
Pod interface
     ↓
Node networking
     ↓
Service dataplane (if Service traffic)
     ↓
routing / NAT / policy / kernel dataplane
     ↓
destination network

Then always ask: "Which implementation is my cluster actually using?" That single question determines the real, concrete path your packets take.

What's Next: Production Troubleshooting

In Level 10, we stop learning isolated components and start diagnosing real failures: a Pod that can't reach another Pod, a Pod that can't reach a Service, a Service with no endpoints, DNS that works while curl still fails, an Ingress returning 502/504, a NetworkPolicy that accidentally broke DNS, traffic that only fails across Nodes, a single misbehaving Node, intermittent connection failures, conntrack exhaustion, MTU problems, and outright CNI failures. That's where this entire 0-to-9 journey turns into a genuinely practical troubleshooting methodology.

Conclusion

Kubernetes networking internals aren't actually magic — they're Linux networking primitives (namespaces, veth pairs, routing tables, Netfilter, conntrack) orchestrated by a CNI and a Service dataplane. The single biggest shift in this article is moving from "Pod talks to Pod" as an abstraction to actually tracing a packet through real kernel mechanisms: crossing a veth pair, hitting a routing decision, potentially getting DNAT'd by a Service dataplane, and having its connection state tracked by conntrack the entire way.

The most valuable habit from this entire article: when something breaks, don't guess at commands — ask "at which hop did the packet actually stop?" and use the Pod-IP-vs-Service-IP test to instantly narrow down whether you're dealing with a CNI-layer problem or a Service-layer problem.

Enjoyed this deep dive? Follow along for Level 10, where we turn this entire series into a hands-on production troubleshooting methodology. Drop your questions in the comments, and share this with a teammate who's still treating Kubernetes networking as an unexplainable black box. Let's finish building this Kubernetes networking roadmap together. 🚀

Kubernetes Networking [Level-8: kube-proxy / iptables / IPVS / eBPF]

ADITYA RAJ — Wed, 19 Aug 2026 12:02:50 +0000

This is Level 8 of our Kubernetes networking series, and it's where we finally go inside the Service dataplane. Back in Level 3, we learned that a client Pod talks to a Service's ClusterIP, which somehow routes traffic to a backend Pod:

Client Pod → Service (10.96.120.50:80) → Backend Pod (10.244.1.10:80)

We deliberately left one question unanswered until now: how does traffic sent to that Service IP actually end up at a real Pod? That's exactly what this article unpacks.

The Problem: A Service IP Isn't a Real Interface
The Basic Idea: A Service Dataplane
What Is kube-proxy?
kube-proxy's Job
kube-proxy Doesn't Create Pods
kube-proxy Runs on Every Node
The Classic Mental Model: iptables and DNAT
What Is DNAT?
Tracing the Packet Journey
The Full Picture: DNS to Pod
iptables in Kubernetes
Control Plane vs Dataplane
Why EndpointSlices Matter Here
Load Balancing Across Endpoints
Session Affinity
The Scaling Problem with iptables
IPVS: IP Virtual Server
iptables vs IPVS
An Important Modern Nuance
eBPF Enters the Picture
Why eBPF Is Interesting for Kubernetes
Cilium and eBPF
eBPF Can Replace Parts of kube-proxy
Don't Confuse kube-proxy Replacement with CNI
Three Generations to Remember
What kube-proxy Actually Watches
Why Services Survive Pod Churn
Where CNI Fits Into All of This
Service vs CNI vs kube-proxy: A Reference Table
Following One Complete Packet
What Is SNAT?
Why SNAT Is Needed
DNAT vs SNAT
Why Return Traffic Works
NodePort, Revisited
LoadBalancer, Revisited
A Layered Troubleshooting Model
A Production Troubleshooting Tree
What to Inspect on a Node
How Do I Know Which Dataplane I'm Using?
The Most Important Conceptual Separation
Interview Questions
Level 8 Mental Model
What's Next: Kubernetes Networking Internals

The Problem: A Service IP Isn't a Real Interface

Suppose we have a frontend Pod at 10.244.1.5, and a Service named backend with ClusterIP 10.96.120.50:80, backed by three Pods:

10.244.1.10:80
10.244.2.10:80
10.244.3.10:80

The frontend runs curl http://backend:80. DNS resolves backend → 10.96.120.50, so the outgoing packet looks like:

SOURCE:      10.244.1.5
DESTINATION: 10.96.120.50:80

Here's the strange part: 10.96.120.50 usually isn't a real, physical network interface attached to any Pod. So who transforms 10.96.120.50:80 into something like 10.244.2.10:80? That transformation is the job of the Service dataplane — and that's exactly what this article is about.

The Basic Idea: A Service Dataplane

Service (10.96.120.50:80)
       ↓
Service dataplane
       ↓
Backend Pod (10.244.2.10:80)

Historically, Kubernetes clusters implemented this using kube-proxy. Modern clusters can implement it very differently. The core concepts we need to understand across this article are: kube-proxy, iptables, IPVS, and eBPF.

What Is kube-proxy?

Despite its name, kube-proxy isn't simply a traditional HTTP proxy — that's a genuinely useful interview point to remember. kube-proxy is a component that helps implement Kubernetes Service networking on each Node:

Service
   ↓
kube-proxy / service dataplane
   ↓
backend Pods

It watches Kubernetes objects — specifically Services and EndpointSlices — and programs the Node's networking rules/dataplane to match what it observes.

kube-proxy's Job

Given a Service backend at 10.96.120.50:80 with EndpointSlice entries pointing to 10.244.1.10:80, 10.244.2.10:80, and 10.244.3.10:80, kube-proxy's conceptual job is simple:

"When traffic arrives for this Service IP and port, send it to one of these backend endpoints."

10.96.120.50:80
        ↓
 ┌──────┼──────┐
 ↓      ↓      ↓
Pod 1  Pod 2  Pod 3

kube-proxy Doesn't Create Pods

Another important distinction worth locking in:

Deployment        → creates/manages Pods
Service           → defines a stable endpoint
kube-proxy/dataplane → implements Service traffic forwarding

Three genuinely different responsibilities, each handled by a different component.

kube-proxy Runs on Every Node

kube-proxy typically runs as a DaemonSet, so every Node gets its own instance:

Node 1 → Pods + kube-proxy
Node 2 → Pods + kube-proxy
Node 3 → Pods + kube-proxy

Each Node needs the ability to handle Service traffic that arrives locally.

The Classic Mental Model: iptables and DNAT

Historically, kube-proxy commonly programmed iptables rules to do this work:

Pod
 ↓
Service IP
 ↓
iptables rules
 ↓
DNAT
 ↓
Pod IP

The key term here is DNAT.

What Is DNAT?

DNAT = Destination Network Address Translation. Suppose a packet starts out as:

SOURCE:      10.244.1.5
DESTINATION: 10.96.120.50:80

The Service dataplane can rewrite the destination:

SOURCE:      10.244.1.5
DESTINATION: 10.244.2.10:80

So 10.96.120.50 → 10.244.2.10 — that transformation is destination NAT in action.

Tracing the Packet Journey

Let's slow this down and walk through it explicitly.

Frontend: 10.244.1.5 — Service: 10.96.120.50:80 — Backend: 10.244.2.10:80

The frontend sends a packet: SRC = 10.244.1.5, DST = 10.96.120.50:80.
The Node's Service dataplane recognizes 10.96.120.50:80 and selects a backend, say 10.244.2.10:80.
The packet effectively becomes: SRC = 10.244.1.5, DST = 10.244.2.10:80.
From here, normal Pod networking (CNI, covered in Level 7) takes over and delivers it.

The Full Picture: DNS to Pod

Connecting this back to Level 4:

Pod
 ↓
DNS
 ↓
Service name
 ↓
ClusterIP
 ↓
Service dataplane
 ↓
Endpoint
 ↓
Pod IP
 ↓
CNI networking
 ↓
destination Pod

Or, with concrete values:

frontend (10.244.1.5)
   | "backend"
   ↓
DNS
   ↓
10.96.120.50
   ↓
Service dataplane
   ↓
10.244.2.10
   ↓
CNI
   ↓
backend Pod

iptables in Kubernetes

Linux has a built-in packet-filtering and NAT framework called iptables. Kubernetes can program iptables rules so that Service traffic gets redirected to the correct backend endpoint:

Packet
  ↓
iptables
  ↓
Service rule
  ↓
Backend selection
  ↓
DNAT
  ↓
Pod

Conceptually, given a Service at 10.96.120.50:80 with endpoints 10.244.1.10:80, 10.244.2.10:80, and 10.244.3.10:80, the Node might carry rules that resemble: "traffic to 10.96.120.50:80 → choose an endpoint → DNAT to one of the three addresses above." Real Kubernetes iptables rule sets are considerably more complex than this simplification — don't worry about memorizing actual chain names yet.

Control Plane vs Dataplane

It helps to think of Kubernetes networking in two layers:

Control plane decides what should happen: which Pods exist, which Services exist, which endpoints belong to a Service.

Dataplane actually handles packets.

Control plane → "Service backend Pods are A, B, C"
      ↓
Dataplane → "Send packets to A/B/C"

Why EndpointSlices Matter Here

Recall from Level 3: a Service like backend has an associated EndpointSlice listing its live backend IPs. The Service dataplane depends directly on this information:

Service + EndpointSlice → Service dataplane → forwarding rules

Without accurate, up-to-date EndpointSlice data, the dataplane has nothing correct to forward traffic to.

Load Balancing Across Endpoints

Given a Service with three backend Pods, a connection to the Service might land on any one of them:

Request 1 → Pod A
Request 2 → Pod C
Request 3 → Pod B
Request 4 → Pod A

The exact algorithm and distribution behavior depends on the dataplane implementation and configuration. The key idea to hold onto: the Service is a stable front door, while the dataplane is what actually selects a backend endpoint for each connection.

Session Affinity

Kubernetes Services can optionally enable session affinity, e.g.:

sessionAffinity: ClientIP

With this enabled, the same client tends to keep landing on the same backend Pod:

Client A → Pod A
Client A → Pod A
Client A → Pod A

Again, the precise implementation details depend on which dataplane your cluster is running.

The Scaling Problem with iptables

The classic kube-proxy → iptables → DNAT → Pod flow works well for many clusters. But there's a scaling consideration: compare 10 Services with 100 total endpoints to 10,000 Services with 100,000 total endpoints. The volume of networking rules involved can grow enormous. This is exactly the pressure that led to IPVS, and eventually to eBPF.

IPVS: IP Virtual Server

IPVS stands for IP Virtual Server — a Linux kernel technology purpose-built for high-performance load balancing:

Service IP (10.96.120.50:80)
       ↓
      IPVS
       ↓
 ┌───┼───┐
 ↓   ↓   ↓
Pod A Pod B Pod C

Instead of thinking in terms of a long chain of packet-filter rules, think of IPVS as a kernel-level virtual server / load-balancing mechanism purpose-built for exactly this job.

iptables vs IPVS

Simplified comparison:

iptables: packet → rules → rules → rules → backend

IPVS: packet → virtual service → backend selection

IPVS can offer more specialized load-balancing behavior, and historically was attractive for clusters with large numbers of Services thanks to its performance characteristics. That said, modern Kubernetes networking has moved beyond simply choosing between these two — eBPF-based dataplanes are increasingly significant.

An Important Modern Nuance

You may hear the claim: "IPVS is always faster than iptables." Don't treat that as an absolute rule. Real-world performance depends on cluster size, traffic patterns, kernel version, configuration, the specific dataplane implementation, and even the underlying hardware. The important conceptual difference to remember is simpler:

iptables → packet filtering/NAT rules
IPVS     → kernel virtual-server load balancing

eBPF Enters the Picture

Now we reach a genuinely important modern technology: eBPF. You don't need to master every detail yet — at a high level:

eBPF = programmable logic that can run inside the Linux kernel.

This lets networking systems perform operations directly in the kernel, rather than bouncing through separate userspace components or long rule chains.

Why eBPF Is Interesting for Kubernetes

The traditional path looks like:

Packet → iptables rules → NAT → routing

An eBPF-based networking implementation can inject custom packet-processing logic straight into the kernel:

Packet → eBPF program → routing / load balancing / policy → destination

This can avoid some of the overhead inherent in traditional networking paths and enables much more flexible dataplane behavior.

Cilium and eBPF

Cilium is one of the best-known Kubernetes networking implementations built on eBPF:

Kubernetes → Cilium → eBPF → Linux kernel → networking + load balancing + NetworkPolicy + observability

This is exactly why Cilium came up briefly back in Level 7 — and now the pieces should be clicking into place.

eBPF Can Replace Parts of kube-proxy

This is an important, genuinely modern Kubernetes concept. Some eBPF-based networking implementations can provide Service load balancing entirely on their own. Instead of:

Service → kube-proxy → iptables → Pod

you can have:

Service → eBPF dataplane → Pod

In such a setup, kube-proxy may not even be needed for Service handling at all. This is commonly referred to as "kube-proxy replacement," and Cilium is a well-known example of a system that offers it.

Don't Confuse kube-proxy Replacement with CNI

Keep these terms distinct in your head:

CNI                   = networking interface/ecosystem
Cilium                = a networking implementation
eBPF                  = a kernel technology
kube-proxy replacement = one specific capability/configuration

They're related, but not interchangeable. A cleaner way to see the relationship:

Cilium → uses eBPF → can implement Kubernetes networking → can provide Service load balancing → can replace kube-proxy

Three Generations to Remember

A simple learning model for Service traffic handling:

                    Service traffic

                       Service IP
                           |
            ┌──────────────┼──────────────┐
            ↓              ↓              ↓
         iptables         IPVS           eBPF
            ↓              ↓              ↓
        kernel rules   virtual server   kernel programs
            ↓              ↓              ↓
                         Pod

This isn't a strict historical replacement chain — real clusters can (and do) use any of these approaches — but it's a useful conceptual comparison to keep handy.

What kube-proxy Actually Watches

kube-proxy needs live information about Services and EndpointSlices. Whenever something changes — a Pod is added or removed, a Service is updated, an endpoint changes — the Service dataplane needs to be kept in sync:

EndpointSlice changes
        ↓
kube-proxy/dataplane notices
        ↓
forwarding state updated
        ↓
new traffic uses current endpoints

This is precisely how Kubernetes handles the constant churn of dynamic Pods without breaking client connectivity.

Why Services Survive Pod Churn

Suppose Service backend (10.96.120.50) initially has Pod A (10.244.1.10) and Pod B (10.244.2.10) as backends. Pod A dies, and a new Pod C (10.244.3.10) appears. The EndpointSlice updates:

OLD: A, B
NEW: B, C

But the Service IP itself never changes — it stays 10.96.120.50. The dataplane simply updates its internal backend information, and clients keep using backend without ever needing to know that a Pod was replaced underneath them. This is one of the single most powerful abstractions in all of Kubernetes.

Where CNI Fits Into All of This

Combining Level 7 and Level 8: CNI provides the underlying Pod network:

Pod → eth0 → veth → Node → Pod network

The Service dataplane provides Service-level forwarding:

Service IP → backend Pod

Together:

                    Kubernetes networking

Pod
 | CNI
 ↓
Pod network
 ↓
Service dataplane
 ↓
another Pod

The exact ordering within the Linux packet path can get more nuanced in practice, but this separation of responsibilities is the key mental model to carry forward.

Service vs CNI vs kube-proxy: A Reference Table

Component	Main Job
CNI/network implementation	Pod networking
IPAM	Pod IP allocation
Service	Stable virtual endpoint
EndpointSlice	Backend endpoint information
kube-proxy	Traditional Service dataplane implementation
iptables	Linux packet filtering/NAT framework
IPVS	Linux virtual-server load balancing
eBPF	Programmable kernel dataplane technology

Following One Complete Packet

Let's trace one full request end-to-end. We have frontend (10.244.1.5), Service backend (10.96.120.50:80), and a backend Pod (10.244.2.10:80). The frontend runs curl http://backend.

Step 1 — DNS: backend → 10.96.120.50.

Step 2 — Application sends packet: SRC = 10.244.1.5, DST = 10.96.120.50:80.

Step 3 — Service dataplane: either kube-proxy → iptables/IPVS, or an eBPF dataplane, takes over.

Step 4 — Destination translation/selection: 10.96.120.50:80 → 10.244.2.10:80.

Step 5 — Pod networking: CNI provides the actual route to 10.244.2.10.

Step 6 — Backend receives traffic: Frontend → Service → Service dataplane → Backend Pod.

What Is SNAT?

We've covered DNAT — now meet its counterpart: SNAT = Source Network Address Translation.

DNAT → destination changes
SNAT → source changes

For example, SRC = Pod IP, DST = external destination might become SRC = Node IP, DST = external destination. This matters specifically when Pods communicate outside the cluster.

Why SNAT Is Needed

Suppose Pod 10.244.1.10 tries to reach the internet. The external destination generally has no idea how to route return traffic back to 10.244.1.10 — that's a private, cluster-internal address. So the networking system may perform SNAT:

10.244.1.10
      ↓ SNAT
192.168.1.10  (Node IP)

Conceptually: Pod → SNAT → Node IP → Internet. The exact behavior depends on your specific cluster's networking architecture.

DNAT vs SNAT

Worth memorizing permanently:

DNAT — D = Destination
SNAT — S = Source

Example (Service → Pod): 10.96.120.50 → DNAT → 10.244.2.10

Example (Pod → outside): 10.244.1.10 → SNAT → Node IP

Why Return Traffic Works

This is where NAT/connection tracking becomes essential. Given Client (10.244.1.5) → Service (10.96.120.50) → Backend (10.244.2.10), the forward path goes Client → Service IP → DNAT → Backend. For the response to correctly find its way back, the networking stack tracks the connection state so return traffic can be translated appropriately in reverse:

Forward: Service → Backend
Return:  Backend → Client

This bookkeeping is handled through connection/NAT state tracking within the Linux networking stack (often referred to as "conntrack").

NodePort, Revisited

With a NodePort Service, given a Node IP of 192.168.1.10 and NodePort 30080, external traffic to 192.168.1.10:30080 can be forwarded toward the Service's backend Pods:

External client
      ↓
NodeIP:30080
      ↓
Service dataplane
      ↓
Backend Pod

The exact mechanics again depend on which dataplane your cluster is running.

LoadBalancer, Revisited

With type: LoadBalancer, the flow typically looks like:

Internet
   ↓
Cloud Load Balancer
   ↓
Node / Service
   ↓
Backend Pods

Both the cloud load balancer and the Kubernetes Service dataplane participate in the overall traffic path — which is exactly why troubleshooting external traffic often requires checking multiple distinct layers.

A Layered Troubleshooting Model

Now that we understand the full stack, we can build a much better troubleshooting model. If curl http://backend fails, don't immediately blame DNS. Break it down layer by layer:

1. DNS
   ↓
2. Service
   ↓
3. EndpointSlice
   ↓
4. Service dataplane
   ↓
5. Pod networking
   ↓
6. Application

Step 1 — DNS:

nslookup backend

Does it resolve to the expected Service IP? If backend → 10.96.120.50, DNS is probably fine.

Step 2 — Service:

kubectl get svc backend

Check the ClusterIP, port, and targetPort.

Step 3 — EndpointSlice:

kubectl get endpointslices
kubectl describe svc backend

Ask directly: does the Service actually have backend endpoints? If you see Endpoints: <none>, don't waste time debugging iptables yet — the Service simply has no backends to send traffic to.

Step 4 — Pod:

kubectl get pods -o wide

Confirm the backend Pods are Running, Ready, and have assigned IPs.

Step 5 — Service dataplane: Ask whether the Service dataplane is correctly forwarding traffic — investigate kube-proxy, iptables, IPVS, or your eBPF/CNI dataplane as appropriate. This is exactly where Level 8 knowledge pays off.

Step 6 — CNI: If Service forwarding looks correct but the destination Pod still isn't reachable, investigate CNI, routing, the Pod's interface, Node connectivity, and NetworkPolicy.

A Production Troubleshooting Tree

                Request fails
                     |
                     ↓
                  DNS?
                 /     \
               NO       YES
               |         |
           Fix DNS     Service?
                         /   \
                       NO     YES
                       |       |
                  Fix Service  EndpointSlice?
                                /       \
                              NO         YES
                              |           |
                        Fix selectors   Dataplane?
                                         /     \
                                       NO       YES
                                       |         |
                                  kube-proxy/   CNI/
                                  eBPF/etc.    routing/
                                               policy

This structured approach beats randomly running commands and hoping something jumps out.

What to Inspect on a Node

For a traditional kube-proxy cluster using iptables, you can inspect:

iptables-save
# or
iptables -t nat -S

These outputs can be extremely large on real clusters — don't be surprised by the volume. For IPVS-based setups, if installed:

ipvsadm -L

For eBPF-based implementations, the relevant tooling depends heavily on the specific implementation — Cilium, for example, ships its own observability and status tooling. Don't run diagnostic commands blindly in production — first figure out which dataplane your cluster actually uses.

How Do I Know Which Dataplane I'm Using?

Start broad:

kubectl get pods -A

Look for names like kube-proxy, calico, cilium, flannel, or aws-node. Then:

kubectl get daemonsets -A

For example, seeing a kube-proxy DaemonSet suggests kube-proxy is deployed — but you should still inspect its configuration to determine whether it's actually running in iptables mode, IPVS mode, or something else entirely.

The Most Important Conceptual Separation

By now, you should be able to cleanly separate these layers in your head:

              Kubernetes networking

                 Service
                    |
                    ↓
             Service dataplane
          ┌─────────┼─────────┐
          ↓         ↓         ↓
      iptables     IPVS      eBPF
          \         |         /
           └────────┼────────┘
                    ↓
                 Pod IP
                    |
                    ↓
               CNI network
                    |
                    ↓
                  Pod

Interview Questions

Q1. What does kube-proxy do?
It traditionally implements Kubernetes Service networking on Nodes by programming a Service dataplane.

Q2. Is kube-proxy an HTTP proxy?
No — the name is genuinely misleading.

Q3. What is a ClusterIP?
A stable virtual IP associated with a Kubernetes Service.

Q4. How does a ClusterIP actually reach a Pod?
Through the Service dataplane — traditionally via iptables/IPVS, or through an alternative dataplane such as eBPF.

Q5. What is DNAT?
Destination Network Address Translation — conceptually, Service IP → Pod IP.

Q6. What is SNAT?
Source Network Address Translation — conceptually, Pod IP → Node IP in some outbound scenarios.

Q7. What is IPVS?
Linux IP Virtual Server — a kernel-level load-balancing mechanism.

Q8. What is eBPF?
A Linux kernel technology that allows programmable logic to run in kernel contexts, used by modern networking systems for routing, load balancing, security, and observability.

Q9. Can eBPF replace kube-proxy?
Yes — some implementations, such as Cilium, can provide full Kubernetes Service functionality without needing kube-proxy at all.

Q10. What does EndpointSlice provide?
Information about the current backend endpoints associated with a Service.

Q11. Is CNI the same as kube-proxy?
No. CNI/network implementation handles Pod networking; kube-proxy/service dataplane handles Service forwarding.

Q12. What happens if a Service has no EndpointSlices/endpoints?
The Service has no backend Pods to send traffic to — regardless of whether the Service dataplane itself is working correctly.

Level 8 Mental Model

If you take away only one diagram from this entire article, make it this one:

                  Service
              10.96.120.50:80
                      |
                      ↓
             Service dataplane
                      |
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       iptables      IPVS        eBPF
          └───────────┼───────────┘
                      ↓
                Pod endpoint
                10.244.2.10
                      |
                      ↓
                     CNI
                      |
                      ↓
                    Pod

And the responsibility of each layer:

CNI → "How do Pods communicate?"
Service → "What stable endpoint do clients use?"
EndpointSlice → "Which Pods are backends?"
kube-proxy / dataplane → "How do Service packets reach those backends?"
iptables / IPVS / eBPF → "How is that forwarding actually implemented?"

What's Next: Kubernetes Networking Internals

In Level 9, we'll connect everything into the actual Linux packet path — diving into network namespaces, veth pairs, bridges, routing tables, conntrack, NAT, the kube-proxy/CNI interaction, Node-to-Pod versus Pod-to-Pod traffic, and exactly what happens to a single packet as it moves through a Kubernetes Node.

Conclusion

The Service dataplane is where Kubernetes networking stops being abstract and becomes real packet manipulation. A ClusterIP is never a physical address a Pod actually owns — it's a rule, enforced by kube-proxy (or an eBPF-based alternative), that rewrites destinations via DNAT and tracks connections so return traffic finds its way home. Whether that enforcement happens through iptables rule chains, IPVS's kernel-level virtual server, or a fully custom eBPF dataplane, the underlying job is the same: turn a stable Service IP into real traffic to a real, currently-healthy Pod.

The biggest practical takeaway: when Service traffic breaks, work the layers in order — DNS, Service, EndpointSlice, dataplane, then CNI. An empty EndpointSlice will waste hours of your time if you jump straight to debugging iptables rules instead of checking it first.

Enjoyed this deep dive? Follow along for Level 9, where we trace a single packet's complete journey through the Linux networking stack inside a real Kubernetes Node. Drop your questions in the comments, and share this with a teammate who still thinks kube-proxy is a literal proxy server. Let's keep building this Kubernetes networking roadmap together. 🚀

Kubernetes Networking [Level-7: CNI]

ADITYA RAJ — Sat, 15 Aug 2026 18:16:07 +0000

This is Level 7 of our Kubernetes networking series — and one of the most important installments so far. Back in Level 1, we learned the shape of Pod networking:

Pod → Network Namespace → eth0 → veth → Node networking

But we deliberately left one big question unanswered the entire time: who actually creates all of this? The answer is CNI, and this article finally opens that box.

The Problem: Something Has to Wire the Pod's Network
What Is CNI?
Why We Need CNI
CNI Is Not One Particular Product
The Pod Creation Flow
What CNI Is Actually Responsible For
CNI and IPAM
Why Pod CIDR Matters
The veth Pair, Revisited
What Happens to the Pod's IP
Who Actually Owns the Pod's eth0?
CNI Handles Both Creation and Deletion
CNI's Place in the Kubernetes Stack
CNI vs Service
CNI vs DNS
CNI vs NetworkPolicy
Four Major Networking Approaches
Common CNI Implementations
A Closer Look: Calico, Flannel, and Cilium
Don't Get Lost in Terminology
What Happens When a Pod Starts
What Happens During Cross-Node Communication
What Happens When CNI Is Broken
A Kubernetes Networking Troubleshooting Ladder
Useful Commands for CNI Investigation
CNI and kubelet
Pod IP vs Service IP vs Node IP
The Big Picture
The Key Mental Model
Level 7 Checkpoint
What's Next: kube-proxy, iptables, IPVS, and eBPF

The Problem: Something Has to Wire the Pod's Network

Suppose Kubernetes creates a new Pod:

kubectl run nginx --image=nginx

That Pod needs a network namespace, an eth0 interface, an IP address, routes, and connectivity to every other Pod in the cluster. Kubernetes itself doesn't contain one built-in, universal implementation that directly wires all of this up. Instead, it delegates the job to a standardized mechanism: CNI — the Container Network Interface.

What Is CNI?

In the simplest terms:

CNI is a standard interface for configuring container networking.

Think of it as a contract between the container runtime and whatever networking implementation you've chosen:

Container runtime
       | "I need networking for this Pod"
       ↓
      CNI
       ↓
Network plugin
       ↓
Configure Pod network

The CNI specification defines the contract; CNI plugins are what actually do the networking work.

Why We Need CNI

Without any Pod networking, Pods are isolated islands:

Pod A       Pod B
  ❌          ❌

With a working CNI implementation in place, they can actually reach each other:

Pod A ─────────→ Pod B

Depending on the specific implementation, CNI/network plugins can provide: Pod IPs, Pod network interfaces, routing, general connectivity, and — in some cases — NetworkPolicy enforcement.

CNI Is Not One Particular Product

This is a crucial mental correction if you're new to this space: CNI is not the name of a single networking product. It's an interface, specification, and ecosystem. Multiple different implementations can all satisfy the CNI contract, including Calico, Cilium, Flannel, AWS VPC CNI, Azure CNI, and various GKE networking implementations.

Don't think: CNI = Calico. Instead think:

CNI
 ↓
standard interface
 ↓
different networking implementations

The Pod Creation Flow

Let's connect this to everything we've learned. When you run kubectl run nginx --image=nginx, the high-level flow looks like this:

kubectl
   ↓
API Server
   ↓
Scheduler
   ↓
Node selected
   ↓
Container runtime
   ↓
Network setup
   ↓
CNI
   ↓
Pod gets networking
   ↓
Container starts

Zooming into just the networking portion:

Pod
 ↓
Network namespace
 ↓
CNI invoked
 ↓
Create/configure network interface
 ↓
Assign IP
 ↓
Configure routes
 ↓
Connect Pod to node network
 ↓
Pod networking ready

What CNI Is Actually Responsible For

At a high level, CNI answers five key questions for every Pod:

1. What network should this Pod join? → the cluster's Pod network.

2. What IP should it receive? → e.g., 10.244.1.15.

3. How does the Pod connect to the Node? → commonly, a Pod's eth0 connects via a veth pair to the Node.

4. How can it reach other Pods? → the networking implementation configures the necessary connectivity.

5. Can traffic be restricted? → some (not all) implementations also enforce NetworkPolicy.

CNI and IPAM

Here's a term you'll see constantly: IPAM (IP Address Management). When a Pod needs an IP, IPAM is what allocates it:

Pod
 ↓
"I need an IP"
 ↓
IPAM
 ↓
10.244.1.15

IPAM allocates addresses from configured pools. For example, given a Pod network of 10.244.0.0/16, a networking implementation might divide it per Node:

Node 1 → 10.244.1.0/24
Node 2 → 10.244.2.0/24
Node 3 → 10.244.3.0/24

And from there:

Pod A → 10.244.1.10
Pod B → 10.244.1.11
Pod C → 10.244.2.10

These are illustrative example ranges, not universal defaults — actual ranges vary by cluster and CNI configuration.

Why Pod CIDR Matters

Recall from Level 2: Pod A (10.244.1.5) needs to reach Pod B (10.244.2.5) on a different Node. For that to work, the networking system needs to know that 10.244.2.0/24 lives on Node 2. This is exactly where the CNI/networking implementation earns its keep — establishing connectivity between these per-Node Pod networks.

The veth Pair, Revisited

We first saw veth pairs back in Level 0 and Level 1. Now let's understand why CNI specifically cares about them.

A Pod lives in its own isolated network namespace:

Pod network namespace
┌─────────────────────┐
│ eth0                │
│ 10.244.1.10         │
└─────────────────────┘

But it still needs to connect to the Node. A veth pair — a virtual Ethernet cable — is a common way to bridge that gap:

Pod namespace                    Node
┌──────────────┐                 ┌──────────────┐
│    eth0      │=================│   vethXXXX   │
│              │    veth pair    │              │
└──────────────┘                 └──────────────┘

One end lives inside the Pod's namespace; the other lives on the Node. The CNI/network implementation is typically what creates and configures this pairing.

What Happens to the Pod's IP

Inside a running Pod, ip addr might conceptually show:

eth0
    inet 10.244.1.10/24

And ip route will show routes that let the Pod communicate beyond its own local subnet. The exact routing table content depends entirely on which networking implementation configured it.

Who Actually Owns the Pod's eth0?

A genuinely useful interview question. The interface itself exists inside the Pod's network namespace, but the setup is performed by the container networking implementation, invoked through CNI. So don't say "the Pod creates eth0" — instead think:

Container runtime
       ↓
CNI/network plugin
       ↓
network namespace + interface + IP + routes

CNI Handles Both Creation and Deletion

CNI's job doesn't stop once a Pod is created:

CREATE POD
    ↓
CNI/network setup
    ↓
network exists

DELETE POD
    ↓
network cleanup
    ↓
IP released
    ↓
interfaces removed

This cleanup step matters a lot — without it, you could end up accumulating unused interfaces, unreleased IPs, and stale network state over time. The networking implementation is responsible for tidying all of this up.

CNI's Place in the Kubernetes Stack

Kubernetes
    | schedules/manages Pods
    ↓
Container runtime
    | runs containers
    ↓
CNI/network implementation
    | configures networking
    ↓
Pod network

Kubernetes handles orchestration (deciding what should run where). The networking implementation handles the actual mechanics of wiring that Pod onto the network.

CNI vs Service

An important distinction we can now draw crisply:

CNI     → Pod networking (connectivity)
Service → stable way to reach a group of Pods

For example:

Pod A (10.244.1.10) → CNI/networking → Pod B (10.244.2.10)

versus:

Client → Service IP → Backend Pod

Two entirely different jobs, working at two different layers.

CNI vs DNS

Also worth separating clearly:

DNS → backend.default.svc.cluster.local → Service IP  (name resolution)
CNI → Pod interface/IP/routes → network connectivity  (Pod networking)

DNS answers "what IP does this name map to?" CNI answers "how does a Pod actually get onto the network in the first place?"

CNI vs NetworkPolicy

We covered this distinction in Level 6, but it's worth reinforcing here:

NetworkPolicy       → "What traffic should be allowed?"
Network implementation → "How is Pod networking provided, and (if supported) how are policies enforced?"

Some networking implementations support NetworkPolicy enforcement and some don't — but either way, CNI ≠ NetworkPolicy. They're related but distinct concerns.

Four Major Networking Approaches

Now let's introduce the major strategies a CNI implementation can use to actually make Pod networking work.

Approach 1 — Routing

Nodes are taught direct routes to each other's Pod networks:

Node 1: Pod CIDR = 10.244.1.0/24
Node 2: Pod CIDR = 10.244.2.0/24

Node 1 simply knows 10.244.2.0/24 → Node 2, so traffic flows: Pod A → Node 1 → Node 2 → Pod B.

Approach 2 — Overlay

A virtual network is built on top of the physical network via encapsulation:

Pod packet
    ↓
encapsulate
    ↓
Node 1 → physical network → Node 2
    ↓
decapsulate
    ↓
Pod

Think of this as "a network inside another network" — the inner packet (Pod A → Pod B) rides inside an outer packet (Node 1 → Node 2). VXLAN is a common technology used to implement this approach.

Approach 3 — Cloud/VPC Networking

Cloud environments can integrate Pod networking directly with the cloud provider's native network:

Pod → cloud network → VPC/VNet → other resources

For example, AWS's VPC CNI uses actual AWS networking primitives rather than building a generic overlay on top. The exact implementation varies by cloud provider and configuration.

Approach 4 — eBPF-Based Networking

Some modern implementations use eBPF for both networking and policy enforcement:

Pod traffic
    ↓
Linux kernel
    ↓
eBPF programs
    ↓
routing / filtering / load balancing

Cilium is the major example here. We won't go deep into eBPF mechanics yet — that's reserved for Level 8. For now, just recognize that a CNI implementation could be built on eBPF.

Common CNI Implementations

Implementation	General Idea
Calico	Routing / policy, with multiple dataplane options
Cilium	eBPF-based networking and security
Flannel	Simple Pod networking, commonly overlay-based
AWS VPC CNI	Integrates Pods directly with AWS VPC networking
Azure networking implementations	Integrate Pods with Azure networking

Don't try to memorize every implementation detail right now. At this level, the important question to ask about each one is simply: what problem does it solve, and how?

A Closer Look: Calico, Flannel, and Cilium

Calico is widely used for both Pod networking and NetworkPolicy enforcement. It can use routing-based networking and supports multiple dataplane options:

Pod → Calico → network + policy

Flannel is known for providing relatively simple Kubernetes Pod networking:

Pod → Flannel → cluster network

A common Flannel setup uses an overlay like VXLAN — but don't treat "Flannel = VXLAN" as an absolute rule, since configurations can vary.

Cilium leans heavily on eBPF for networking, security, and observability:

Pod traffic → Linux kernel → eBPF → networking + security + observability

We'll compare these implementations in more depth once we reach Level 8.

Don't Get Lost in Terminology

You'll hear phrases like "CNI plugin," "CNI binary," "CNI configuration," "CNI network," and "CNI IPAM" thrown around. Don't let the terminology overwhelm you. At the learning level, this simplified mental model covers the fundamentals well:

             CNI
              |
      ┌───────┴────────┐
      ↓                ↓
Network setup        IPAM
      ↓                ↓
interface            IP
routes
connectivity

The real architecture can get more nuanced in production systems, but this model will serve you well as a foundation.

What Happens When a Pod Starts

Putting it all together — suppose Kubernetes schedules Pod A onto Node 1:

                Kubernetes
                    ↓
               Node 1
                    ↓
             Container runtime
                    ↓
            Create Pod namespace
                    ↓
                  CNI
                    |
          ┌─────────┼─────────┐
          ↓         ↓         ↓
        veth       IP       routes
          |         |         |
          └─────────┼─────────┘
                    ↓
               Pod eth0
                    ↓
              Pod networking

At the end of this sequence, Pod A has a working IP (say, 10.244.1.10) and is ready to communicate.

What Happens During Cross-Node Communication

Suppose Pod A (10.244.1.10 on Node 1) needs to reach Pod B (10.244.2.10 on Node 2). The networking implementation provides the actual path:

Pod A → eth0 → veth → Node 1 → networking implementation → Node 2 → veth → eth0 → Pod B

The exact middle section — routing, overlay, cloud networking, or eBPF — depends entirely on which CNI implementation you're running. This is precisely why the choice of CNI matters so much in real clusters.

What Happens When CNI Is Broken

This is where understanding CNI pays off during real troubleshooting. If you see symptoms like:

Pod → no IP
Pod → eth0 missing
Pod A ✗ Pod B

...you should immediately start thinking: could this be a CNI/networking problem? Common symptoms worth watching for include Pods stuck in ContainerCreating, Pods with no IP assigned, an unconfigured Pod network namespace, broken Pod-to-Pod connectivity, broken DNS connectivity, or NetworkPolicy simply not being enforced. Not every one of these symptoms is guaranteed to be a CNI issue, but CNI should always be high on your list of suspects.

A Kubernetes Networking Troubleshooting Ladder

We can now assemble a genuinely useful troubleshooting sequence, built from everything covered across this series:

Pod exists?
   ↓
Pod has IP?
   ↓
Pod has eth0?
   ↓
Pod has routes?
   ↓
Pod → Pod works?
   ↓
Service works?
   ↓
DNS works?
   ↓
NetworkPolicy works?

CNI sits right near the bottom of this stack:

CNI → Pod networking → Pod-to-Pod → Services → DNS → Ingress

If basic Pod networking is broken at the CNI layer, everything built on top of it can fail too — which is exactly why it's worth checking early rather than last.

Useful Commands for CNI Investigation

Start broad:

kubectl get pods -o wide

This shows you each Pod's IP and the Node it's running on. Then:

kubectl get nodes

Drill into a specific Pod:

kubectl exec -it <pod> -- ip addr
kubectl exec -it <pod> -- ip route

Check networking-related Pods across the whole cluster:

kubectl get pods -A

In many clusters, CNI components run as DaemonSets — typically one networking agent per Node:

kubectl get daemonsets -A

The exact namespace and deployment shape depend heavily on your specific Kubernetes distribution and chosen networking implementation.

Look for the CNI

A useful investigative habit:

kubectl get pods -A

Look for Pod names containing things like calico-node, cilium, kube-flannel, or aws-node. These names give you a strong clue about which networking implementation your cluster is running — though don't assume every cluster follows the same naming conventions.

CNI and kubelet

One more important relationship: the kubelet manages Pods on a given Node. When a Pod's networking needs to be configured, the container runtime and networking stack invoke the configured CNI mechanism:

kubelet
   ↓
container runtime
   ↓
CNI
   ↓
network plugin
   ↓
Pod network

The precise interaction between the runtime and CNI has evolved across different Kubernetes versions and container runtimes, but this remains the correct conceptual model to hold onto.

Pod IP vs Service IP vs Node IP

Let's clarify one more crucial distinction now that IPAM is fresh in mind. Given a Pod network of 10.244.0.0/16, IPAM might allocate:

Pod 1 → 10.244.1.10
Pod 2 → 10.244.1.11
Pod 3 → 10.244.2.10

When Pod 2 is deleted, 10.244.1.11 can eventually return to the available address pool, depending on the specific IPAM implementation. So: IPAM = who gets which Pod IP, and when it's reclaimed.

By now you should be able to clearly distinguish three different kinds of IPs:

Node IP    → identifies a Node       (e.g., 192.168.1.10)
Pod IP     → identifies a Pod        (e.g., 10.244.1.10)
Service IP → stable virtual endpoint (e.g., 10.96.120.50)

CNI is primarily concerned with the Pod IP layer — it has nothing to do with creating Service semantics, which is a separate mechanism entirely (covered in Level 3, and revisited more deeply in Level 8).

The Big Picture

We've now connected almost the entire series into a single diagram:

                    Kubernetes
                        ↓
                     Node
                        ↓
                 Container runtime
                        ↓
                       CNI
                        |
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
        veth            IP          routes
          \             |             /
           └────────────┼────────────┘
                        ↓
                       Pod
                        ↓
                     Pod IP
                        ↓
                 Pod-to-Pod network
                        ↓
                     Service
                        ↓
                       DNS
                        ↓
                Ingress / Gateway

And NetworkPolicy sits across the entire networking path as an overlay of rules:

Pod traffic → NetworkPolicy rules → network implementation → allow / restrict

The Key Mental Model

If you remember only one diagram from this entire article, make it this one:

                POD
                 | eth0
                 ↓
              veth pair
                 ↓
                NODE
                 ↓
         CNI / networking
                 |
       ┌─────────┼─────────┐
       ↓         ↓         ↓
      IP       routes    connectivity
       |         |         |
       └─────────┼─────────┘
                 ↓
             other Pods

And the single sentence to internalize:

CNI = "How do Pods get onto the network?"

Level 7 Checkpoint

1. What does CNI stand for?
Container Network Interface.

2. Is CNI a single product?
No — it's a standard/interface/ecosystem used by many different networking implementations.

3. What does CNI help configure?
At a high level: the Pod's network namespace, interface, IP address, routes, and connectivity — and, depending on the implementation, NetworkPolicy enforcement and other capabilities.

4. What is IPAM?
IP Address Management — the process of allocating IP addresses to Pods.

5. What commonly connects a Pod's namespace to the Node?
A veth pair is a common mechanism.

6. Is CNI the same as Service?
No. CNI provides Pod networking; Service provides stable access to a group of Pods.

7. Is CNI the same as NetworkPolicy?
No. NetworkPolicy defines what traffic should be allowed; the network implementation provides and (if supported) enforces that behavior.

8. Name some Kubernetes networking implementations.
Calico, Cilium, Flannel, AWS VPC CNI, among others.

9. What are the major networking approaches?
Conceptually: routing, overlay, cloud/VPC networking, and eBPF-based networking.

10. What happens if CNI networking is broken?
Symptoms can include Pods with no IP, Pods with no working interface, broken Pod-to-Pod connectivity, broken DNS connectivity, and cascading failures in higher-level networking.

What's Next: kube-proxy, iptables, IPVS, and eBPF

In Level 8, we'll finally open the black box behind the Service dataplane and answer:

A Service IP exists. How does it actually become a Pod IP?

We'll cover kube-proxy, iptables, IPVS, and eBPF — and how Service traffic is genuinely forwarded under the hood. This is where the whole networking picture starts becoming much more concrete.

Conclusion

CNI is the quiet, foundational layer that makes every other piece of Kubernetes networking possible. It's not a single product but a standardized contract — implemented by tools like Calico, Cilium, and Flannel — for giving every Pod a network namespace, an interface, an IP address, and a path to reach every other Pod in the cluster. Whether that connectivity is achieved through routing, overlays, cloud-native VPC integration, or eBPF depends entirely on which implementation you choose.

The most valuable habit to take away from this article: when something in Kubernetes networking breaks, don't jump straight to blaming Services or DNS. Walk the ladder from the bottom up — Pod IP, Pod interface, Pod-to-Pod connectivity — because a broken CNI layer can quietly break everything built on top of it.

Found this useful? Follow along for Level 8, where we finally crack open kube-proxy, iptables, IPVS, and eBPF to see exactly how a Service IP becomes real Pod traffic. Drop your questions in the comments, and share this with a teammate who still thinks "CNI" and "Calico" are the same thing. Let's keep building this Kubernetes networking roadmap together. 🚀

Kubernetes Networking [Level-6: Networking Policy]

ADITYA RAJ — Sat, 15 Aug 2026 12:38:07 +0000

This is Level 6 of our Kubernetes networking series. So far, we've learned that Kubernetes networking is, by default, remarkably open — any Pod can talk to any other Pod:

Pod A ─────────→ Pod B
Pod C ─────────→ Pod B
Pod D ─────────→ Pod B

That's great for connectivity, but terrible for security. In a real application, you almost never want everything talking to everything. This article covers the Kubernetes object designed specifically to fix that: NetworkPolicy.

The Problem: Too Much Trust
The Solution: NetworkPolicy
Two Directions: Ingress and Egress
An Easy Way to Remember Ingress vs Egress
A Simple Scenario
Your First NetworkPolicy
Reading the Policy Step by Step
The Policy Selects the Destination
What About the Database?
NetworkPolicy Doesn't Block Everything by Default
Default Deny
Why Default Deny Is Useful
Controlling Egress Traffic
An Egress Policy Example
Namespaces Matter More Than You Think
namespaceSelector
Combining podSelector and namespaceSelector
Three Key Selectors: podSelector, namespaceSelector, ipBlock
Restricting Ports
A Complete Multi-Tier Example
NetworkPolicy Is Not an Application Firewall
NetworkPolicy Doesn't Replace Authentication
Who Actually Enforces NetworkPolicy?
Two Common Misconceptions
Hands-On: Inspecting NetworkPolicies
Hands-On: Creating an Allow Policy
Hands-On: The Default-Deny Lab
A Production Mental Model
Troubleshooting NetworkPolicy
The Mental Model to Memorize
Level 6 Checkpoint
What's Next: CNI

The Problem: Too Much Trust

Imagine a typical three-tier application:

Internet → Frontend → Backend → Database

Ideally, we want a strict set of allowed paths:

Frontend → Backend       ✅
Backend  → Database      ✅
Frontend → Database      ❌
Database ← Internet      ❌

But by default, Kubernetes doesn't enforce any of this. Without restrictions, every one of these connections is technically possible:

frontend → backend       ✅
frontend → database      ✅
backend  → database      ✅
backend  → frontend      ✅
database → frontend      ✅
database → backend       ✅

That's usually far too permissive. A compromised frontend Pod could, in principle, connect directly to the database — bypassing the backend entirely. We need a way to explicitly say: this path is allowed, that one isn't.

The Solution: NetworkPolicy

A NetworkPolicy is a Kubernetes object that defines rules controlling network traffic to and from selected Pods. In one sentence:

NetworkPolicy = firewall-like rules for Pod traffic.

The mental model:

NetworkPolicy
     ↓
Which Pods?
     ↓
What traffic?
     ↓
Allow / restrict

Two Directions: Ingress and Egress

NetworkPolicy operates along two possible directions — and getting these terms straight is essential.

Ingress — traffic coming into a Pod:

Frontend
   | traffic
   ↓
Backend Pod
        ↑
     ingress

Egress — traffic leaving a Pod:

Backend Pod
    | traffic
    ↓
Database
   ↑
egress from Backend

An Easy Way to Remember Ingress vs Egress

Picture yourself standing inside a room:

INGRESS = people coming IN
EGRESS = people going OUT

For a Pod:

Traffic → Pod  = Ingress
Pod → Traffic  = Egress

A Simple Scenario

Suppose we have three Pods: frontend, backend, and database, each with a matching label:

frontend: app=frontend
backend:  app=backend
database: app=database

We want:

frontend → backend     ✅
backend  → database    ✅
frontend → database    ❌

A NetworkPolicy can express this as: "Backend Pods may receive traffic from Frontend Pods."

Your First NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend

  policyTypes:
    - Ingress

  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

Don't worry about memorizing this YAML yet — let's walk through exactly what it means.

Reading the Policy Step by Step

Which Pods does the policy apply to?

podSelector:
  matchLabels:
    app: backend

This means: apply this policy to Pods labeled app: backend.

backend Pod 1  ← selected
backend Pod 2  ← selected

frontend Pod   ← not selected
database Pod   ← not selected

What direction is being controlled?

policyTypes:
  - Ingress

This means: we're controlling traffic coming into the selected backend Pods.

Who is allowed in?

ingress:
  - from:
      - podSelector:
          matchLabels:
            app: frontend

This means: backend Pods can receive traffic from Pods labeled app: frontend.

So frontend → backend is allowed, but anything not explicitly listed (like database → backend) is not covered by this rule.

The Policy Selects the Destination

This point confuses a lot of beginners, so let's be explicit. The top-level podSelector defines where the policy applies — the destination:

podSelector:
  matchLabels:
    app: backend

The from block inside ingress defines who is allowed to reach it — the source:

from:
  - podSelector:
      matchLabels:
        app: frontend

Visually:

        NetworkPolicy
              |
              ↓
       ┌─────────────┐
       │   backend   │
       └──────▲──────┘
              |
           allowed
              |
       ┌──────┴──────┐
       │  frontend   │
       └─────────────┘

What About the Database?

Suppose we never wrote an explicit allow rule for frontend → database. Then, once the database Pods become subject to a NetworkPolicy, that path stays blocked:

frontend → backend     ✅
frontend → database    ❌

This is the beginning of micro-segmentation: instead of trusting the entire cluster ("everything can talk to everything"), you deliberately define a small, explicit set of allowed paths — Frontend → Backend, Backend → Database, and nothing else.

NetworkPolicy Doesn't Block Everything by Default

This is a critical concept: creating one NetworkPolicy does not mean "everything else in the cluster is now blocked." Whether a Pod becomes restricted depends on whether it's selected by a policy for the relevant direction:

Policy selects backend
       +
Ingress policy exists
       ↓
backend ingress becomes restricted

Once a Pod becomes "isolated" for a direction (ingress or egress), only the explicitly allowed traffic for that direction gets through. This naturally leads to the concept of default deny.

Default Deny

Suppose you want: "By default, nobody can send traffic to these Pods." You can express that with:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Here, podSelector: {} (an empty selector) means: select all Pods in this namespace. Combined with policyTypes: [Ingress] and no ingress rules at all, the effect is:

Any Pod
   |
   X
   ↓
Selected Pods

Nothing is allowed in, for any Pod in the namespace, until you add explicit allow rules.

Why Default Deny Is Useful

Imagine a production namespace with frontend, backend, database, and cache Pods. Instead of assuming everything is safe by default:

frontend → everything
backend  → everything
database → everything

...you start from DENY, and explicitly allow only what's actually required:

frontend → backend       ✅
backend  → database      ✅
backend  → cache         ✅
everything else          ❌

This "deny by default, allow by exception" approach is a widely used, well-established security strategy — and NetworkPolicy is how you implement it in Kubernetes.

Controlling Egress Traffic

So far we've focused on incoming traffic, but you can restrict outgoing traffic too. For example:

Backend → Database                    ✅ allowed
Backend → Random external destination ❌ blocked

You express this using:

policyTypes:
  - Egress

An Egress Policy Example

Suppose backend Pods should only be allowed to talk to database Pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-to-database
spec:
  podSelector:
    matchLabels:
      app: backend

  policyTypes:
    - Egress

  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database

Read it as: "Select backend Pods, and allow their outgoing traffic to database Pods."

backend
   | egress allowed
   ↓
database

Namespaces Matter More Than You Think

This is one of the most important — and most frequently misunderstood — NetworkPolicy concepts.

Suppose you have a frontend Pod (labeled app=frontend) in the frontend namespace, and a backend Pod (labeled app=backend) in the backend namespace. If you write:

podSelector:
  matchLabels:
    app: frontend

...does this mean "any frontend Pod in the entire cluster"? No. A plain podSelector in a NetworkPolicy only selects Pods within the same namespace as the policy itself. This is exactly why namespaceSelector exists.

namespaceSelector

Suppose you want: "Allow traffic from Pods in the frontend namespace." You'd write:

from:
  - namespaceSelector:
      matchLabels:
        name: frontend

frontend namespace
        | allowed
        ↓
backend namespace

Combining podSelector and namespaceSelector

You can combine both for much more precise targeting:

from:
  - namespaceSelector:
      matchLabels:
        name: frontend
    podSelector:
      matchLabels:
        app: frontend

This means: "Allow traffic from Pods labeled app: frontend, but only inside namespaces labeled name: frontend."

namespace
    +
pod label
    ↓
specific source Pods

Three Key Selectors: podSelector, namespaceSelector, ipBlock

podSelector — selects Pods based on labels:

podSelector:
  matchLabels:
    app: backend

namespaceSelector — selects namespaces based on labels:

namespaceSelector:
  matchLabels:
    team: payments

ipBlock — selects IP ranges:

ipBlock:
  cidr: 10.0.0.0/8

This is especially useful when communicating with systems outside Kubernetes entirely — for example, an external database at a fixed IP or CIDR range:

Pod
 | allowed
 ↓
10.20.0.0/16

Restricting Ports

NetworkPolicy can also restrict specific ports. Suppose backend only listens on TCP 8080:

ports:
  - protocol: TCP
    port: 8080

With this in place (assuming the relevant isolation applies):

frontend → backend:8080     ✅
frontend → backend:22       ❌

This is powerful because you're simultaneously controlling who can connect and on which port — a much finer-grained model than simple Pod-to-Pod allow/deny.

A Complete Multi-Tier Example

Suppose we have frontend, backend, and database Pods, each in their own namespace, and we want:

frontend → backend:8080     ✅
backend  → database:5432    ✅
frontend → database:5432    ❌

                 ┌───────────────┐
                 │   frontend    │
                 └───────┬───────┘
                         │
                       8080
                         ↓
                 ┌───────────────┐
                 │    backend    │
                 └───────┬───────┘
                         │
                       5432
                         ↓
                 ┌───────────────┐
                 │   database    │
                 └───────────────┘

frontend ────────────────X────────→ database

This is exactly the kind of layered security architecture NetworkPolicy is designed to express.

NetworkPolicy Is Not an Application Firewall

An important distinction: NetworkPolicy operates primarily at the network traffic level, not the application layer. It can say:

Allow frontend → backend:8080

But it generally has no concept of things like:

HTTP: GET /users
HTTP: POST /delete-account

For that kind of application-layer control, you'd need additional mechanisms like an Ingress/Gateway, an API gateway, a service mesh, or application-level authorization. In short: NetworkPolicy = network-level access control, not HTTP-aware access control.

NetworkPolicy Doesn't Replace Authentication

If frontend → backend is allowed by a NetworkPolicy, that does not mean "the frontend is authenticated." These are entirely separate security layers:

NetworkPolicy answers: can network traffic flow at all?
Authentication answers: who are you?
Authorization answers: are you allowed to perform this specific action?

Don't confuse network-level permission with identity or permission checks — you typically need all three layered together for real security.

Who Actually Enforces NetworkPolicy?

Here's a subtle but critical concept: a NetworkPolicy object only describes the desired rules — the actual networking implementation has to enforce them.

NetworkPolicy
      ↓
rules
      ↓
CNI/network dataplane
      ↓
enforcement

If your CNI plugin doesn't support NetworkPolicy enforcement, creating a NetworkPolicy object won't magically create a firewall — it'll just sit there, unenforced. This is one of many reasons the choice of CNI plugin matters, which we'll explore properly in Level 7.

For now, keep the division of responsibility simple:

NetworkPolicy → "What traffic should be allowed?"
CNI           → "How do I actually enforce that?"

Don't worry yet about whether enforcement happens via iptables, eBPF, or some other mechanism — those details come later.

Two Common Misconceptions

Misconception 1: "NetworkPolicy protects my whole cluster."
Not exactly — policies are namespace-scoped objects that select specific Pods. You need to design policies deliberately across every namespace and workload in your architecture; there's no single switch that secures everything at once.

Misconception 2: podSelector: {} means "no Pods."
Actually, the opposite is true — podSelector: {} means select all Pods in the policy's namespace. This is a very easy mistake to make, and it has real security implications if misunderstood.

Hands-On: Inspecting NetworkPolicies

Check what NetworkPolicies exist in your cluster:

kubectl get networkpolicy
# or the shorter alias:
kubectl get netpol

Inspect one in detail:

kubectl describe networkpolicy <name>

This shows you the Pod selector, policy types, ingress/egress rules, ports, and sources/destinations all in one place.

Hands-On: Creating an Allow Policy

Create two labeled Pods:

kubectl run frontend --image=nginx --labels=app=frontend
kubectl run backend --image=nginx --labels=app=backend

Verify their labels:

kubectl get pods --show-labels

frontend   app=frontend
backend    app=backend

Now apply a policy selecting backend:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

kubectl apply -f backend-policy.yaml

The conceptual result: frontend → backend is allowed, while other sources attempting to reach backend may be blocked, depending on your cluster's NetworkPolicy implementation and any other policies in effect.

Hands-On: The Default-Deny Lab

A great learning exercise is applying a namespace-wide default deny:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
    - Ingress

kubectl apply -f default-deny.yaml

Now every selected Pod is denied ingress traffic by default:

All selected Pods
      ↑
      |
   DENY by default

From here, you layer in specific allow policies as needed — the classic pattern:

DEFAULT DENY → ALLOW ONLY WHAT IS REQUIRED

A Production Mental Model

A realistic NetworkPolicy setup might enforce:

Internet → Frontend        allowed at edge
Frontend → Backend:8080    allowed
Backend  → Database:5432   allowed

Frontend → Database        blocked
Database → Frontend        blocked
Random Pod → Database      blocked

That's genuine network segmentation, built entirely out of Kubernetes-native objects.

Troubleshooting NetworkPolicy

Suppose your application suddenly can't connect to something it used to reach fine. Don't immediately assume the Service is broken — walk the chain methodically:

Application → DNS → Service → Pod → NetworkPolicy

If the Pod was reachable directly before a policy was applied, but not afterward, the NetworkPolicy is the likely suspect. Useful commands:

kubectl get networkpolicy
kubectl describe networkpolicy <name>
kubectl get pods --show-labels
kubectl get namespaces --show-labels

The single biggest troubleshooting mistake: the selector doesn't match the Pods you think it matches.

Selector Debugging

Suppose your policy says:

matchLabels:
  app: backend

But your actual Pod is labeled:

app=back-end

Policy selector: app=backend
                     ↓
                     X
Pod label:       app=back-end

No match — the policy simply isn't selecting the Pod you expected. Always verify with kubectl get pods --show-labels before assuming something deeper is wrong.

The Namespace Mistake

Suppose you have a frontend Pod in the frontend namespace and a backend Pod in the backend namespace, and you write only:

podSelector:
  matchLabels:
    app: frontend

Remember: a plain podSelector in a NetworkPolicy is always namespace-local. If you need to allow traffic across namespaces, you need namespaceSelector combined with podSelector.

The Mental Model to Memorize

NetworkPolicy
      |
      ↓
Which Pods?
      |
      ↓
Ingress / Egress?
      |
      ↓
From where / To where?
      |
      ↓
Which ports?
      |
      ↓
Allow traffic

Or, compressed even further:

WHO → WHERE → DIRECTION → PORT → ALLOW

A useful production security model to keep in your head:

              Internet
                  |
                  ↓
              Ingress
                  |
                  ↓
             Frontend
                  |
             NetworkPolicy
                  |
                  ↓
              Backend
                  |
             NetworkPolicy
                  |
                  ↓
             Database

Each boundary in your architecture can — and often should — have its own explicit rules.

Level 6 Checkpoint

1. What is NetworkPolicy?
A Kubernetes API for defining network traffic rules for selected Pods.

2. What is ingress?
Traffic coming into a Pod — A → Pod.

3. What is egress?
Traffic going out of a Pod — Pod → B.

4. What does podSelector do?
Selects Pods by labels, within the policy's own namespace.

5. What does namespaceSelector do?
Selects namespaces by labels.

6. What does ipBlock do?
Selects an IP/CIDR range, typically for traffic to/from outside the cluster.

7. What is default deny?
Start by denying all traffic, then explicitly allow only what's actually required.

8. Does NetworkPolicy itself implement packet filtering?
No — the underlying network implementation (CNI dataplane) must support and enforce it.

9. Does NetworkPolicy provide application authentication?
No. NetworkPolicy → network access, Authentication → identity, Authorization → permissions — three separate layers.

10. Does NetworkPolicy understand HTTP URLs?
Generally no — it's primarily network-level control, not application-aware.

What's Next: CNI

In Level 7, we'll finally answer a question we've deliberately postponed since Level 1:

When Kubernetes creates a Pod, who actually creates its eth0, its veth pair, its IP address, its routes, and its overall network connectivity?

We'll walk through CNI, CNI plugins, IPAM, veth pairs, bridges/routes/overlays, and popular real-world CNI implementations like Calico, Cilium, and Flannel, along with cloud-native CNIs — while still saving the deepest dataplane internals for Level 8.

Conclusion

NetworkPolicy is what turns Kubernetes networking from "everything can talk to everything" into a deliberately designed, segmented system. The core ideas are simple once they click: a policy selects a group of Pods, declares a direction (ingress and/or egress), and defines exactly who is allowed to communicate with them and on which ports. Layer in a default-deny policy per namespace, and you've built the foundation of real network security in Kubernetes.

Just remember the two biggest gotchas: podSelector is namespace-local unless combined with namespaceSelector, and NetworkPolicy is only as effective as the CNI plugin enforcing it. Get those two details right, and you'll avoid the vast majority of real-world NetworkPolicy debugging headaches.

Found this useful? Follow along for Level 7, where we finally dig into CNI itself — the component quietly responsible for everything we've built on top of it since Level 1. Drop your questions in the comments, and share this with a teammate who's still running a completely flat, unsegmented cluster network. Let's keep building this Kubernetes networking roadmap together. 🚀

Kubernetes Networking [Level-5: Ingress/Gateway]

ADITYA RAJ — Sat, 15 Aug 2026 12:06:46 +0000

This is Level 5 of our Kubernetes networking series. So far, we've built up a solid foundation:

LEVEL 1 — Pod networking
LEVEL 2 — Pod-to-Pod communication
LEVEL 3 — Service (a stable internal endpoint)
LEVEL 4 — DNS (service name → Service IP)

But we still have a glaring gap: how does a real user on the internet actually reach your Kubernetes application? That's exactly what this article covers — Ingress, Ingress Controllers, and the newer Gateway API.

The Problem: The Internet Can't Reach a ClusterIP
The Basic Solution: Ingress and Gateway API
What Is Ingress?
A Routing Example
Ingress Is Not the Actual Proxy
A Simple Analogy: Traffic Police
A Basic Ingress YAML Example
Breaking Down the Key Fields
Host-Based Routing
Path-Based Routing
Why Not Just Use a LoadBalancer Service for Everything?
The Complete Traffic Flow
Where Does DNS Fit In?
The Ingress Controller
A Typical Architecture
Ingress vs Service
Ingress vs LoadBalancer Service
HTTPS and TLS Termination
Why Terminate TLS at the Edge?
Referencing a TLS Certificate
Routing Multiple Domains
The Gateway API
GatewayClass, Gateway, and HTTPRoute
Ingress vs Gateway API
Important Distinctions: Ingress Is Not CNI or Service
Troubleshooting Ingress Layer by Layer
Common Ingress Mistakes
The Complete Kubernetes Networking Picture (Levels 1–5)
The Mental Model to Memorize
Level 5 Checkpoint
What's Next: NetworkPolicy

The Problem: The Internet Can't Reach a ClusterIP

Suppose you want users to reach your application at myapp.example.com. Inside your cluster, you have:

Service: frontend
ClusterIP: 10.96.20.10

frontend Service
       ├── Pod 1
       ├── Pod 2
       └── Pod 3

A user on the internet can't simply visit http://10.96.20.10 — that's a private Kubernetes Service IP, invisible outside the cluster. We need something sitting at the edge of the cluster to bridge that gap.

The Basic Solution: Ingress and Gateway API

Historically, Kubernetes solved this with Ingress. More recently, Kubernetes introduced a more expressive alternative: the Gateway API. At a high level, both follow the same shape:

Internet
   ↓
Ingress / Gateway
   ↓
Service
   ↓
Pods

That's the core mental model for this entire article.

What Is Ingress?

Ingress is a Kubernetes API object that describes how incoming HTTP/HTTPS traffic should be routed to Services. For example:

app.example.com → frontend Service
api.example.com → backend Service

Or path-based:

example.com/api → api Service
example.com/    → frontend Service

In short, Ingress lets you declaratively describe HTTP routing rules for your cluster.

A Routing Example

Suppose you have a frontend Service and a backend Service, and you want:

app.example.com      → frontend
app.example.com/api  → backend

You can express this entirely through an Ingress object:

                  Internet
                     |
                     ↓
              Ingress Layer
                 /       \
                ↓         ↓
        frontend Service  backend Service
               |              |
             Pods           Pods

Ingress Is Not the Actual Proxy

This is a critical point that trips up a lot of beginners: an Ingress object doesn't magically start receiving internet traffic on its own. It's just a set of rules. You need an Ingress Controller to actually enforce them — implementations include NGINX, HAProxy, Traefik, and various cloud-provider load balancer integrations.

Ingress            = rules/configuration
Ingress Controller = the component that actually implements those rules

A Simple Analogy: Traffic Police

Imagine a large building with a single main entrance from the street:

Internet → Main entrance

At the entrance, someone asks "where are you going?" If you say app.example.com, you're directed to the frontend. If you say api.example.com, you're directed to the backend.

The Ingress rules are the instructions written down. The Ingress Controller is the person actually standing there enforcing them.

A Basic Ingress YAML Example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend
                port:
                  number: 80

Read this as: "If the HTTP request is for app.example.com, send it to the frontend Service on port 80."

Breaking Down the Key Fields

host — which domain this rule matches:

host: app.example.com

path — which URL path this rule matches. For example, path: / with pathType: Prefix could match /, /login, /products, /about, and so on, depending on the exact path-matching configuration.

backend.service — where the matched traffic gets sent:

backend:
  service:
    name: frontend
    port:
      number: 80

So together: app.example.com → frontend Service → Pods.

Host-Based Routing

One of the most useful Ingress features is routing based on hostname. Suppose you have three domains:

app.example.com
api.example.com
admin.example.com

You can route each one to a different backend:

app.example.com   → frontend Service
api.example.com   → backend Service
admin.example.com → admin Service

A single entry point can serve many completely different applications this way.

Path-Based Routing

You can also route based on the URL path rather than the hostname:

example.com/       → frontend
example.com/api    → backend
example.com/admin  → admin

                    Ingress
                       |
          ┌────────────┼────────────┐
          ↓            ↓            ↓
         /            /api        /admin
          ↓            ↓            ↓
      frontend       backend      admin

This pattern is extremely common in real-world Kubernetes setups.

Why Not Just Use a LoadBalancer Service for Everything?

A fair question: "Why not just create a LoadBalancer Service for every application?" You technically can — but imagine you have 50 applications:

LoadBalancer 1 → App 1
LoadBalancer 2 → App 2
...
LoadBalancer 50 → App 50

That's a lot of external load balancers to manage (and often, a lot of cost). Instead, a single edge layer can route traffic to many applications at once:

                 Internet
                    ↓
             Load Balancer
                    ↓
              Ingress
             /    |    \
            ↓     ↓     ↓
         App1    App2    App3

One entry point, many destinations — far simpler to operate.

The Complete Traffic Flow

This is the most important diagram in this article. Suppose a user opens https://app.example.com:

User
 | HTTPS
 ↓
DNS
 | app.example.com → public IP
 ↓
Load Balancer
 ↓
Ingress Controller
 | host = app.example.com
 ↓
frontend Service
 ↓
Endpoint / Pod
 ↓
Application

Notice how many layers we've now connected across this entire series:

Internet → DNS → Load Balancer → Ingress → Service → Pod

Where Does DNS Fit In?

This is a different DNS context than the one we covered in Level 4 — it's worth being precise about the distinction.

External DNS (public internet):

app.example.com → 203.0.113.50 (public IP / load balancer)

Cluster DNS (internal, from Level 4):

frontend.default.svc.cluster.local → Service IP

Don't mix these two up — they're separate DNS systems solving separate problems, even though both are technically "DNS."

The Ingress Controller

If you create an Ingress object but nothing is actually watching and implementing it, the rules just sit there inert. You need a running Ingress Controller:

Ingress object
      ↓
Ingress Controller
      ↓
Actual traffic handling

The controller continuously watches Kubernetes API objects (Ingress resources) and configures its own proxy/load-balancing dataplane to match.

A Typical Architecture

                    Internet
                       |
                       ↓
                Cloud Load Balancer
                       |
                       ↓
              Ingress Controller
                       |
             ┌─────────┼─────────┐
             ↓         ↓         ↓
          Service A Service B Service C
             |         |         |
            Pods      Pods      Pods

The exact shape of this architecture varies depending on your cloud provider and cluster setup, but this general pattern is extremely common.

Ingress vs Service

An important distinction to internalize:

Service answers: "How do I reach this group of Pods?"

Service → Pods

Ingress answers: "How do external HTTP/HTTPS requests get routed to Services?"

Internet → Ingress → Service → Pods

In short: Service is an internal/application endpoint abstraction; Ingress is HTTP/HTTPS edge routing.

Ingress vs LoadBalancer Service

These two aren't competitors — they typically work together:

Internet
   ↓
Cloud Load Balancer
   ↓
Ingress Controller
   ↓
Service
   ↓
Pods

The cloud load balancer's job is simply to get traffic into the cluster. Once it arrives, the Ingress Controller decides where within the cluster that HTTP request should actually go.

HTTPS and TLS Termination

Ingress is commonly used to terminate TLS. When a user visits https://app.example.com, the encrypted connection reaches the Ingress layer first:

Client
   | HTTPS
   ↓
Ingress Controller
   | HTTP or HTTPS
   ↓
Service
   ↓
Pod

This process — decrypting HTTPS at the edge — is called TLS termination.

Why Terminate TLS at the Edge?

Terminating TLS at the Ingress layer centralizes several responsibilities in one place: certificate management, HTTPS handling, HTTP routing, redirects, and both host- and path-based routing. Your application can then simply receive plain HTTP internally, if that fits your security model.

That said, don't assume Ingress always means "HTTP behind the scenes" — you can also configure TLS to be re-encrypted or passed through all the way to the backend Pod, depending on your architecture and requirements.

Referencing a TLS Certificate

An Ingress can reference a Kubernetes TLS Secret directly:

tls:
  - hosts:
      - app.example.com
    secretName: app-tls

The referenced Secret holds the certificate and private key material the Ingress implementation uses:

Client
   | HTTPS
   ↓
Ingress
   | TLS termination
   ↓
Service

Routing Multiple Domains

Suppose you're running several distinct applications under different subdomains:

shop.example.com
api.example.com
admin.example.com

A single Ingress layer can route all of them:

                     Ingress
                       |
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
 shop.example.com api.example.com admin.example.com
        ↓              ↓              ↓
      shop           backend         admin
     Service         Service        Service

This is host-based routing at work again, just applied across an entire portfolio of applications.

The Gateway API

Now let's look at the newer Kubernetes networking API: the Gateway API. Think of it as an evolution of Ingress, not something unrelated:

Ingress     → older/simpler HTTP routing API
Gateway API → more expressive, extensible traffic-routing model

Gateway API introduces a small family of dedicated resources: GatewayClass, Gateway, and HTTPRoute.

GatewayClass, Gateway, and HTTPRoute

GatewayClass answers: "What kind of Gateway implementation are we using?" — essentially, which controller manages Gateways of this class.

Gateway represents the actual traffic entry point:

Internet → Gateway

It defines listeners, such as HTTP on port 80 or HTTPS on port 443.

HTTPRoute describes the routing rules themselves — for example:

app.example.com      → frontend Service
app.example.com/api  → backend Service

Chained together:

Gateway → HTTPRoute → Service → Pod

Ingress vs Gateway API

You don't need to memorize every field of either API right now — just understand the high-level difference:

	Ingress	Gateway API
Maturity	Older, widely adopted	Newer, more expressive API family
Scope	Mainly HTTP/HTTPS routing	Broader traffic-routing model
Structure	Simpler, single object	More structured (GatewayClass + Gateway + Routes)

A useful mental model:

Ingress:     "Here are my HTTP routing rules."
Gateway API: "Here is my traffic infrastructure, and here are the routes attached to it."

The Gateway API's basic resource relationship looks like this:

GatewayClass → Gateway → HTTPRoute → Service → Pods

You don't need to implement any of this from scratch right now — the goal here is understanding the traffic flow conceptually.

Important Distinctions: Ingress Is Not CNI or Service

Two easy things to conflate — worth separating clearly.

Ingress is not CNI:

CNI     → how Pods get network connectivity
Ingress → how external HTTP/HTTPS traffic is routed to Services

Ingress is not Service:

Service → stable endpoint → Pods
Ingress → external HTTP/HTTPS → Service

The full combined chain is:

Internet → Ingress → Service → Pod

Troubleshooting Ingress Layer by Layer

When https://app.example.com doesn't work, resist the urge to restart things randomly. Instead, work through the chain one layer at a time.

Layer 1 — External DNS: Does app.example.com resolve to the expected public IP?

nslookup app.example.com

Layer 2 — Load Balancer: Can the public IP actually reach your load balancer or entry point?

Layer 3 — Ingress Controller: Is it actually running?

kubectl get pods -A

Look specifically for your ingress controller's Pods.

Layer 4 — Ingress rules: Check the configuration itself.

kubectl get ingress
kubectl describe ingress <name>

Verify the host, path, backend Service, and TLS configuration all match what you expect.

Layer 5 — Service: Does the target Service actually exist?

kubectl get svc

Layer 6 — Endpoints: Does the Service have live backend endpoints?

kubectl get endpointslices

Layer 7 — Pod: Is the application actually listening on the expected port?

Service → Pod → Application

Put together, this gives you a reliable troubleshooting chain:

DNS → Load Balancer → Ingress Controller → Ingress/Gateway rule → Service → Endpoint → Pod → Application

Common Ingress Mistakes

Mistake 1 — Wrong hostname: The Ingress rule expects api.example.com, but the user requests app.example.com — no rule matches.

Mistake 2 — Wrong Service name: The Ingress points to backend-service, but the actual Service is named backend.

Mistake 3 — Wrong Service port: The Ingress specifies port 80, but the Service actually exposes a different port.

Mistake 4 — Service has no endpoints: The Service backend exists, but its selector doesn't match any running Pods — traffic reaches the Service and simply has nowhere to go.

Mistake 5 — External DNS points to the wrong place: app.example.com resolves to the wrong public IP entirely. In this case, your Kubernetes cluster can be perfectly healthy while users still can't reach the application — the problem never even makes it inside the cluster.

The Complete Kubernetes Networking Picture (Levels 1–5)

We can now connect everything we've covered across this series so far:

                           INTERNET
                              |
                              ↓
                         External DNS
                              |
                              ↓
                       Public IP / LB
                              |
                              ↓
                    Ingress / Gateway
                              |
                              ↓
                          Service
                              |
                              ↓
                         Pod IP
                              |
                              ↓
                       Pod networking
                              |
                              ↓
                         Application

And internally, on the Service side:

Service
   ↓
EndpointSlice
   ├── Pod A
   ├── Pod B
   └── Pod C

This is a genuine milestone — you now have a complete, end-to-end mental model from a browser tab all the way down to a running container.

The Mental Model to Memorize

Don't try to memorize every YAML field from this article. Instead, memorize the shape and the responsibility of each layer:

External DNS → Public endpoint → Ingress/Gateway → Service → EndpointSlice → Pod

DNS → "Where is it?"
Ingress/Gateway → "Which application should receive this request?"
Service → "Which Pods provide this application?"
EndpointSlice → "Which endpoints currently exist?"
Pod networking → "How does the packet actually reach the Pod?"

Level 5 Checkpoint

1. What problem does Ingress solve?
Routing external HTTP/HTTPS traffic to Kubernetes Services.

2. Is Ingress itself a proxy?
Not necessarily — the Ingress object defines rules; an Ingress Controller is what actually implements them.

3. What is host-based routing?
Routing based on hostname — e.g., app.example.com → frontend, api.example.com → backend.

4. What is path-based routing?
Routing based on URL path — e.g., example.com/ → frontend, example.com/api → backend.

5. What is TLS termination?
When the edge component (the Ingress Controller) receives HTTPS traffic and handles the TLS connection before forwarding the request onward.

6. Service vs Ingress?
Ingress → external HTTP/HTTPS → Service → Pods.

7. What is the Gateway API?
A newer, more expressive Kubernetes API family for configuring traffic infrastructure and the routes attached to it.

8. What are the key Gateway API resources?
At this level, remember GatewayClass, Gateway, and HTTPRoute.

What's Next: NetworkPolicy

In Level 6, we'll tackle a very different kind of question:

Pods can currently talk to each other freely. What if I don't want every Pod to be able to talk to every other Pod?

We'll cover allow/deny traffic rules, ingress vs egress policies, selectors, namespaces, CIDR-based rules, default-deny policies, and one crucial caveat: NetworkPolicy only works when your networking implementation actually supports and enforces it.

Conclusion

Ingress and the Gateway API are what finally connect the outside world to your Kubernetes Services. An Ingress (or Gateway) object is just a declaration of routing intent — host rules, path rules, TLS settings — while an Ingress Controller (or Gateway implementation) is the actual component that turns those rules into working traffic routing. Once you can trace a request all the way from external DNS through the load balancer, the Ingress Controller, the Service, and finally into a Pod, Kubernetes networking stops feeling like a black box.

The next time something breaks in production, don't guess — walk the chain layer by layer: DNS, load balancer, Ingress Controller, Ingress rule, Service, endpoints, Pod. That habit will save you far more time than randomly restarting components.

Enjoyed this deep dive? Follow along for Level 6, where we lock down Pod-to-Pod traffic using NetworkPolicy. Drop your questions in the comments, and share this with a teammate still confused about why their Ingress "isn't working" even though the Pods are healthy. Let's keep building this Kubernetes networking roadmap together. 🚀

Kubernetes Networking [Level-4: Services Discovery/DNS]

ADITYA RAJ — Sat, 15 Aug 2026 11:04:40 +0000

This is Level 4 of our Kubernetes networking series. In Level 3, we introduced the Service — a stable virtual IP that solves the problem of ever-changing Pod IPs. But that left one question unanswered:

How does an application find a Kubernetes Service without hardcoding its IP address?

Instead of applications relying on this:

Frontend → 10.96.120.50:80

we want something far more human-friendly:

Frontend → backend:80

That's exactly what Service Discovery solves, and in Kubernetes, it's built on top of DNS.

The Problem: Hardcoded IPs Are Fragile
What Is DNS?
Who Provides DNS in Kubernetes? CoreDNS
Where CoreDNS Actually Runs
How a Pod Knows Where DNS Is
The Complete DNS Flow
Why You Can Just Write "backend"
The Kubernetes Service DNS Name Format
Why Namespaces Matter for DNS
Cross-Namespace Service Access
A Full DNS Name Example
DNS Doesn't Directly Find the Pod
DNS and Service Are Different Jobs
Hands-On: Testing DNS Yourself
Using nslookup for Debugging
A Layered Debugging Sequence
When DNS Works But the App Still Fails
Headless Services
Normal Service vs Headless Service
What About Pod DNS?
Understanding Search Domains
The Complete Request, Step by Step
The Mental Model to Memorize
Interview Questions
Level 4 Checkpoint
What's Next: Ingress and Gateway API

The Problem: Hardcoded IPs Are Fragile

Recall our Service from Level 3:

Service: backend
ClusterIP: 10.96.120.50

We could technically configure the frontend to call http://10.96.120.50:80 directly — but that's brittle. What happens if the Service gets recreated and its ClusterIP changes? The application shouldn't have to care.

What we really want is to write:

http://backend:80

Kubernetes makes this possible using DNS.

What Is DNS?

At its core, DNS does one simple thing: it converts names into IP addresses. On the public internet, this looks like:

google.com → IP address

Kubernetes applies the exact same idea inside the cluster:

backend → 10.96.120.50

So the basic flow is:

Application
    | "backend"
    ↓
   DNS
    | "10.96.120.50"
    ↓
 Service

Who Provides DNS in Kubernetes? CoreDNS

Kubernetes clusters typically run CoreDNS — think of it as the cluster's built-in DNS server.

                 Kubernetes Cluster

Frontend Pod
     |
     | DNS query: "backend"
     ↓
 CoreDNS
     |
     | answer: 10.96.120.50
     ↓
 Service

You don't need to understand CoreDNS internals yet. For now, just remember: CoreDNS = the Kubernetes cluster's DNS server.

Where CoreDNS Actually Runs

CoreDNS itself runs as regular Pods inside your cluster. Check it out:

kubectl get pods -n kube-system

You'll typically see something like:

coredns-xxxxx
coredns-yyyyy

Interestingly, CoreDNS is itself exposed through a Kubernetes Service:

kubectl get svc -n kube-system

You'll likely see a Service named kube-dns — this name sticks around for historical reasons even when CoreDNS (not the older kube-dns implementation) is what's actually running behind it.

How a Pod Knows Where DNS Is

When Kubernetes creates a Pod, it automatically configures DNS settings inside it. You can inspect this yourself:

kubectl exec -it <pod-name> -- cat /etc/resolv.conf

You'll typically see something like:

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

The exact IP depends on your cluster, but the key line is:

nameserver <cluster-DNS-IP>

This tells the Pod: "Whenever you need to resolve a name, ask this DNS server."

The Complete DNS Flow

Suppose we have a Frontend Pod and a Service named backend with ClusterIP 10.96.120.50. The frontend runs:

curl http://backend

The application needs to answer: what does backend actually point to? Here's the full chain:

Application
     | DNS lookup: backend
     ↓
/etc/resolv.conf
     ↓
CoreDNS
     ↓
10.96.120.50
     ↓
Service
     ↓
Backend Pod

That entire sequence is Kubernetes Service Discovery in action.

Why You Can Just Write "backend"

This works thanks to Kubernetes DNS search domains. If your Pod lives in the default namespace and your Service is named backend, a query for just backend gets expanded automatically through the configured search domains:

backend
backend.default
backend.default.svc
backend.default.svc.cluster.local

Eventually, one of these resolves to the Service's full DNS name — which is why you rarely need to type the whole thing out.

The Kubernetes Service DNS Name Format

Every Kubernetes Service gets a predictable, standard DNS name:

<service>.<namespace>.svc.<cluster-domain>

The cluster domain is usually cluster.local. So a Service named backend in the default namespace becomes:

backend.default.svc.cluster.local

Breaking it down:

backend → the Service name
default → the namespace
svc → indicates this is a Service
cluster.local → the cluster's DNS domain

Put together, backend.default.svc.cluster.local unambiguously means "the Service backend in namespace default."

Why Namespaces Matter for DNS

Imagine two namespaces — default and production — both containing a Service named backend:

default:    backend
production: backend

So which one does a plain backend refer to? By default, a Pod resolves short names relative to its own namespace.

A Pod in default resolving backend effectively means backend.default.svc.cluster.local.
A Pod in production resolving backend effectively means backend.production.svc.cluster.local.

This is exactly why namespaces matter for Service discovery — they prevent naming collisions across teams and environments.

Cross-Namespace Service Access

Suppose a Frontend Pod living in the frontend namespace needs to talk to a Backend Service living in the backend namespace. You'd use:

backend.backend.svc.cluster.local

Notice the two different meanings of "backend" here — the first backend is the Service name, and the second backend is the namespace. Together they resolve to "the Service named backend, in the namespace named backend."

A Full DNS Name Example

Let's use a clearer example. Suppose:

Service:   payments
Namespace: production

Its full DNS name is:

payments.production.svc.cluster.local

A frontend could call it in a few different ways:

curl http://payments.production.svc.cluster.local
curl http://payments.production
curl http://payments   # only if the caller is already in the "production" namespace

The fully qualified name is always the safest and clearest option, especially across namespaces.

DNS Doesn't Directly Find the Pod

Here's a subtle but crucial point. When you resolve backend, DNS gives you the Service's ClusterIP — not a Pod IP:

backend → 10.96.120.50

From there, a completely separate mechanism takes over:

10.96.120.50
      ↓
Service dataplane
      ↓
Backend Pod

So the full picture is:

DNS → Service IP → Service routing → Pod

Don't confuse DNS resolution with Service traffic forwarding — they're two distinct steps handled by two distinct systems.

DNS and Service Are Different Jobs

This distinction is worth memorizing permanently:

DNS answers: "What IP belongs to this name?"

backend → 10.96.120.50

Service answers: "Where should traffic sent to this IP actually go?"

10.96.120.50 → Pod A / Pod B / Pod C

Chained together:

Name → DNS → Service IP → Service dataplane → Pod

Hands-On: Testing DNS Yourself

Let's verify all of this with a real Pod. Create a simple test Pod:

kubectl run test --image=busybox:1.36 --restart=Never -- sleep 3600

Check it's running:

kubectl get pod test

Shell into it:

kubectl exec -it test -- sh

Inside the Pod, inspect its DNS configuration:

cat /etc/resolv.conf

Then try resolving the built-in Kubernetes API Service:

nslookup kubernetes

You should get back a Service IP. If you created the backend Service from Level 3, try that too:

nslookup backend

Using nslookup for Debugging

nslookup is one of the most useful tools for troubleshooting DNS issues:

nslookup backend

Conceptually, this asks: "What is the IP of backend?" — and gets back an answer like 10.96.120.50. Once you have that answer, curl http://backend is really just using this same resolution behind the scenes.

A Layered Debugging Sequence

When curl http://backend fails, don't immediately blame "the network." Break the problem down layer by layer instead:

Step 1 — Does the Service exist?

kubectl get svc

Step 2 — Does the Service have live endpoints?

kubectl get endpointslices

Step 3 — Does DNS resolve the name?

nslookup backend

Step 4 — Does the resolved Service IP respond? Try connecting directly to the IP returned above.

Step 5 — Can the backend Pod itself be reached? Try connecting directly using the Pod's own IP.

This structured approach cleanly separates a DNS problem from a Service problem from a Pod networking problem — an extremely useful skill for real production debugging.

When DNS Works But the App Still Fails

Suppose nslookup backend correctly returns 10.96.120.50 — DNS is clearly working. But curl http://backend still fails. Where's the problem?

DNS       ✅
  ↓
Service   ❓
  ↓
Endpoint  ❓
  ↓
Pod       ❓

The key insight: DNS success does not mean application connectivity is working. It only confirms that name resolution succeeded — the actual request still has to travel through the Service dataplane and reach a healthy Pod.

Headless Services

Now for an important special case. Normally, a Service gets a ClusterIP:

backend → 10.96.120.50

But sometimes you don't want a virtual ClusterIP at all. For that, Kubernetes offers headless Services, created using clusterIP: None:

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  clusterIP: None
  selector:
    app: backend
  ports:
    - port: 80

With a headless Service, DNS behaves differently: instead of returning a single virtual IP, it returns the individual IPs of every matching Pod:

backend
   ↓
DNS
   ↓
10.244.1.5
10.244.2.7
10.244.2.9

This is especially useful for applications that need to know about individual backend instances directly — common examples include databases, distributed systems, and other stateful applications. We'll revisit this when we cover StatefulSets in a later part of the series.

Normal Service vs Headless Service

	Normal Service	Headless Service
ClusterIP	Yes	No
`clusterIP` field	Virtual IP	`None`
DNS resolves to	Service IP	Individual Pod endpoints
Typical use	Normal application access	Direct endpoint discovery

Mental picture — normal Service:

DNS → 10.96.x.x → Service → Pods

Headless Service:

DNS → Pod A, Pod B, Pod C (directly)

What About Pod DNS?

Kubernetes can also provide DNS names for individual Pods under certain configurations. However, for standard application-to-application communication:

Prefer using a Service over relying on individual Pod DNS names or IPs.

Why? Because Pods are inherently temporary:

Pod A (10.244.1.5) dies → Pod B (10.244.4.9) takes over

A Service hides all of that churn behind a stable name and IP — exactly the abstraction you want your applications depending on.

Understanding Search Domains

Revisit /etc/resolv.conf once more:

search default.svc.cluster.local svc.cluster.local cluster.local

This search line is what allows short names to "just work." A query for backend gets automatically expanded through each of these search domains until one of them resolves successfully. This is precisely why Kubernetes applications can conveniently write:

http://backend

instead of always spelling out the full:

http://backend.default.svc.cluster.local

The Complete Request, Step by Step

Let's trace one full request end-to-end. The frontend runs:

curl http://backend

Step 1 — Application asks DNS: "What is backend?"

Step 2 — Pod's DNS configuration: /etc/resolv.conf points the query at the cluster's DNS server.

Step 3 — CoreDNS resolves it: CoreDNS knows backend.default.svc.cluster.local maps to 10.96.120.50.

Step 4 — Application receives the IP: backend → 10.96.120.50.

Step 5 — Application sends traffic: to 10.96.120.50:80.

Step 6 — Service dataplane takes over: traffic gets forwarded to an appropriate backend Pod.

10.96.120.50 → Pod 1 / Pod 2 / Pod 3

Putting the whole picture together:

┌──────────────┐
│ Frontend Pod │
└──────┬───────┘
       │ "backend"
       ↓
┌──────────────┐
│   CoreDNS    │
└──────┬───────┘
       │ 10.96.120.50
       ↓
┌──────────────┐
│   Service    │
└──────┬───────┘
       │
   ┌───┼────┐
   ↓   ↓    ↓
 Pod1 Pod2 Pod3

The Mental Model to Memorize

This entire article boils down to one chain:

Application
    | "backend"
    ↓
   DNS
    | "10.96.120.50"
    ↓
 Service
    | selects backend
    ↓
 EndpointSlice
    ↓
  Pod

Or even more compactly:

NAME → DNS → SERVICE IP → POD

Interview Questions

Q1. What is CoreDNS?
The DNS server commonly used inside Kubernetes clusters.

Q2. Why do we need DNS in Kubernetes?
So applications can use stable, human-readable names instead of hardcoding IP addresses that can change.

Q3. What is the standard DNS format for a Service?
<service>.<namespace>.svc.<cluster-domain> — for example, backend.default.svc.cluster.local.

Q4. What does a Service name usually resolve to?
For a normal ClusterIP Service, its virtual ClusterIP.

Q5. Does DNS send traffic to the Pod?
No — DNS only resolves the name. The Service dataplane handles the actual traffic forwarding afterward.

Q6. What is a headless Service?
A Service configured with clusterIP: None. It skips the normal virtual ClusterIP and instead allows DNS-based discovery of individual Pod endpoints.

Q7. Where can you check a Pod's DNS configuration?
kubectl exec <pod> -- cat /etc/resolv.conf

Q8. How do you test DNS resolution from inside a Pod?
kubectl exec -it <pod> -- nslookup backend

Level 4 Checkpoint

By now, you should be comfortable explaining this entire chain:

backend
   ↓
CoreDNS
   ↓
10.96.120.50
   ↓
Service
   ↓
EndpointSlice
   ↓
Backend Pod

And you should be able to clearly state the difference:

DNS     = "name → IP"
Service = "stable IP → backend Pods"

What's Next: Ingress and Gateway API

In Level 5, we'll tackle the next natural question:

I have a Service inside Kubernetes. How does a user on the public internet reach my application using a domain like app.example.com?

We'll cover Ingress, Ingress Controllers, the Gateway API, host/path-based routing, TLS termination, and the full traffic flow from Internet → Load Balancer → Ingress/Gateway → Service → Pod — while still saving the low-level dataplane internals for Level 8.

Conclusion

Service Discovery is what makes Kubernetes applications feel effortless to configure: instead of chasing down ever-changing IP addresses, you just use a name like backend, and CoreDNS quietly resolves it to a stable Service IP behind the scenes. Understanding that DNS and Service routing are two separate, sequential steps — name resolution first, traffic forwarding second — is the key to debugging connectivity issues quickly and confidently.

The next time something doesn't connect, resist the urge to guess. Walk the layers: check the Service, check the EndpointSlice, check DNS with nslookup, then check the Pod itself. That habit alone will save you hours of confused troubleshooting.

Enjoyed this article? Follow along for Level 5, where we finally expose these Services to the outside world using Ingress and the Gateway API. Drop your questions in the comments, and share this with a teammate who's still typing raw ClusterIPs into their code. Let's keep building this Kubernetes networking roadmap together. 🚀

Kubernetes Networking [Level-3: Services]

ADITYA RAJ — Sat, 15 Aug 2026 10:35:02 +0000

This is Level 3 of our Kubernetes networking series. In Level 2, we traced how Pod-to-Pod communication actually works — and ended on a serious problem: Pod IPs are dynamic and temporary. An application can't reliably hardcode a Pod IP if that Pod might be replaced at any moment.

This article solves that exact problem by introducing one of the most important objects in Kubernetes: the Service.

The Problem: Pod IPs Aren't Reliable
The Solution: Service
The Core Mental Model
How a Service Finds Its Pods: Labels and Selectors
A Minimal Service Example
port vs targetPort
What a Service Actually Gives You: ClusterIP
Visualizing Service Selection
A Service Does Not Create Pods
Hands-On: Deploying Backend Pods
Hands-On: Creating the Service
Where Does the Traffic Actually Go?
A Service Isn't a Normal Server
EndpointSlices: Tracking Live Backends
What Happens When a Pod Dies
Kubernetes Service Types
Service vs Pod vs Deployment
Services Don't Mean DNS — Yet
The Complete Picture So Far
Hands-On Investigation
How Does the ClusterIP Actually Work?
Level 3 Checkpoint
What's Next: Service Discovery and DNS

The Problem: Pod IPs Aren't Reliable

Imagine three backend Pods:

backend-pod-1: 10.244.1.5
backend-pod-2: 10.244.2.8
backend-pod-3: 10.244.3.2

Your frontend wants to call the backend, so it could just call 10.244.1.5:8080 directly. But what happens when backend-pod-1 crashes? Kubernetes creates a replacement — say, backend-pod-4 at 10.244.4.9 — and the old IP is simply gone.

That means this is a fragile design:

Frontend → Pod IP

We need something more stable than a raw Pod IP.

The Solution: Service

Kubernetes solves this with a Service — think of it as a stable front door for a group of Pods.

                 Service
              10.96.0.10
                   |
        ┌──────────┼──────────┐
        ↓          ↓          ↓
      Pod 1      Pod 2      Pod 3
   10.244.1.5 10.244.2.8 10.244.3.2

The frontend never needs to know individual Pod IPs — it just talks to 10.96.0.10, and the Service takes care of routing traffic to an appropriate backend Pod.

The Core Mental Model

This is the single most important idea in this article:

Pod IP     → temporary
Service IP → stable

Pods can come and go freely. The Service gives applications a consistent, stable endpoint regardless of what's happening underneath.

How a Service Finds Its Pods: Labels and Selectors

A Service doesn't magically know which Pods belong to it — it uses labels and selectors.

Suppose your Pods are labeled:

labels:
  app: backend

Then your Service can declare:

selector:
  app: backend

Which effectively means: "Send traffic to any Pod labeled app: backend."

A Minimal Service Example

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

Don't worry about every field yet — focus on two things:

selector:
  app: backend

and:

port: 80
targetPort: 8080

port vs targetPort

This distinction trips up a lot of beginners, so let's be precise.

Suppose the Service listens on port: 80, but the Pod's container actually listens on 8080. The flow looks like this:

Client
  |
  | :80
  ↓
Service
  |
  | :8080
  ↓
Pod

In short:

port → the port exposed by the Service
targetPort → the port the traffic is forwarded to on the Pod

So this configuration:

ports:
  - port: 80
    targetPort: 8080

means: Service :80 forwards to Pod :8080.

What a Service Actually Gives You: ClusterIP

A standard Kubernetes Service is assigned a stable virtual IP called a ClusterIP. For example:

Service: backend
ClusterIP: 10.96.0.10

Frontend Pod
     |
     | 10.96.0.10:80
     ↓
  Service
     |
     ↓
Backend Pod

Important nuance: the Service IP isn't a network interface living inside some specific Pod. It's a virtual IP handled entirely by the Kubernetes networking dataplane — we'll unpack exactly how that works in Level 8.

Visualizing Service Selection

                 Service
              backend:80
              10.96.0.10
                   |
           selector: app=backend
                   |
        ┌──────────┼──────────┐
        ↓          ↓          ↓
      Pod A      Pod B      Pod C
    app=backend app=backend app=backend

Any Pod that doesn't match the selector is simply excluded:

                 Service
                    |
        ┌───────────┼───────────┐
        ↓           ↓           ↓
     backend      backend     backend
        ✓           ✓           ✓

     frontend
        ✗

A Service Does Not Create Pods

This is a very common point of confusion. A Service never creates or manages Pods.

Deployment → creates/manages Pods
Service    → provides stable networking to those Pods

Put another way:

Deployment says: "I need 3 backend Pods running."
Service says: "Give me a stable way to reach those backend Pods."

They solve two entirely different problems and are designed to work together.

Hands-On: Deploying Backend Pods

For real, learnable infrastructure, a Deployment is a much better way to create backend Pods than creating them manually:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80

Apply it:

kubectl apply -f backend.yaml

Check the results:

kubectl get pods -o wide

NAME                       IP
backend-xxxxx-aaa          10.244.1.5
backend-xxxxx-bbb          10.244.2.7
backend-xxxxx-ccc          10.244.2.9

Your actual Pod names and IPs will differ — that's expected.

Hands-On: Creating the Service

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 80

Apply it:

kubectl apply -f backend-service.yaml

Check it:

kubectl get svc

NAME      TYPE        CLUSTER-IP     PORT(S)
backend   ClusterIP   10.96.120.50   80/TCP

That 10.96.120.50 is your Service's ClusterIP.

Where Does the Traffic Actually Go?

Suppose the frontend sends a request to 10.96.120.50:80. The Service currently has three backend Pods:

10.244.1.5:80
10.244.2.7:80
10.244.2.9:80

Conceptually:

Frontend
   |
   | 10.96.120.50:80
   ↓
Service
   |
   ├────→ 10.244.1.5:80
   ├────→ 10.244.2.7:80
   └────→ 10.244.2.9:80

Traffic gets distributed among the currently available backend endpoints. We'll cover the exact packet-processing mechanism (kube-proxy, iptables, IPVS, eBPF) in Level 8.

A Service Isn't a Normal Server

It's tempting to imagine 10.96.120.50 as some machine sitting somewhere with its own network interface — but that's usually the wrong mental model. Think of it instead as:

Service = stable virtual endpoint + rules for reaching backend Pods

So 10.96.120.50 is a virtual Service IP, not a physical destination.

EndpointSlices: Tracking Live Backends

If a Service selects Pod A, Pod B, and Pod C, Kubernetes needs a way to track the actual current backend endpoints. Modern Kubernetes does this using EndpointSlices:

Service
   ↓
EndpointSlice
   ├── Pod A IP
   ├── Pod B IP
   └── Pod C IP

Check them with:

kubectl get endpointslices

kubectl describe endpointslice <name>

The Service gives you a stable identity; the EndpointSlice reflects the current, real-time set of backend Pods.

What Happens When a Pod Dies

Suppose the Service currently has Pod A, Pod B, and Pod C as backends, and Pod B crashes. Kubernetes detects this and removes it from the available backends:

Before:
Service
 ├── A
 ├── B
 └── C

After:
Service
 ├── A
 └── C

A replacement Pod (Pod D) may appear shortly after:

Service
 ├── A
 ├── C
 └── D

Crucially, the frontend doesn't need to change anything — it keeps using the Service name or ClusterIP (backend / 10.96.120.50) the entire time. This self-healing stability is the whole point of the Service abstraction.

Kubernetes Service Types

Kubernetes offers several Service types, each solving a different exposure problem.

ClusterIP

The default type — provides a stable internal endpoint used for communication within the cluster:

type: ClusterIP

Pod A → Service → Pod B

NodePort

Exposes the Service on a fixed port across every Node in the cluster:

type: NodePort

Client
   |
   ↓
Node IP :30080
   |
   ↓
Service
   |
   ↓
Pod

For example, if a Node's IP is 192.168.1.10 and the NodePort is 30080, you can reach the Service via 192.168.1.10:30080, and Kubernetes forwards that traffic to the backend Pods.

LoadBalancer

Common in cloud environments, this type provisions an external load balancer that routes into your Service:

type: LoadBalancer

Internet
    |
    ↓
Public IP
    |
    ↓
Load Balancer
    |
    ↓
Service
    |
    ├──→ Pod
    ├──→ Pod
    └──→ Pod

The exact provisioning mechanism depends on your cloud provider or Kubernetes environment.

ExternalName

A special type that doesn't select Pods at all — instead, it provides a DNS alias pointing to an external hostname:

type: ExternalName

Kubernetes Service name → external.example.com

This one is less central to networking fundamentals, but useful to know exists.

Quick Reference

Type	Basic Purpose
ClusterIP	Internal stable endpoint
NodePort	Expose through a Node port
LoadBalancer	External/cloud load balancer
ExternalName	DNS alias to an external service

For now, focus most of your attention on ClusterIP — everything else builds on the same underlying concept.

Service vs Pod vs Deployment

Two classic interview questions, answered cleanly.

Service vs Pod:

Pod     → runs the application, has a Pod IP
Service → stable networking endpoint, selects backend Pods

In short: Pod = workload, Service = networking abstraction.

Service vs Deployment:

Deployment → manages the desired number of Pods
Service    → provides stable access to those Pods

Deployment
    |
    ├── Pod A
    ├── Pod B
    └── Pod C
          ↑
          |
       Service

Services Don't Mean DNS — Yet

You might be wondering: "If I have a Service called backend, can I just use the name backend instead of its IP?"

Yes — eventually. But that's a separate mechanism (DNS), covered in the next article. At this level, focus purely on:

Service → stable virtual endpoint

In Level 4, we'll add the missing piece:

Service name → DNS → Service IP

Don't conflate the two just yet — understanding them separately will make DNS click much faster later.

The Complete Picture So Far

                    Kubernetes Cluster

        ┌─────────────────────────────────┐
        │          Service                │
        │       10.96.120.50:80           │
        │              │                  │
        │       ┌──────┼──────┐           │
        │       ↓      ↓      ↓           │
        │     Pod A  Pod B  Pod C         │
        │      │       │       │          │
        │   10.244.x 10.244.x 10.244.x    │
        └─────────────────────────────────┘

The application talks to the Service, never directly to individually changing Pod IPs.

Hands-On Investigation

Try tracing the full chain yourself:

kubectl get pods -o wide
kubectl get svc
kubectl describe svc backend

Look specifically for the Selector: field in the output — e.g., Selector: app=backend. Then check:

kubectl get endpointslices

You're now able to see the entire chain in action:

Service → Selector → EndpointSlice → Pod IPs

How Does the ClusterIP Actually Work?

At this point you might reasonably ask: "Okay, but HOW does 10.96.120.50 actually become 10.244.1.5?"

Great question — and the answer is that something running on every Kubernetes Node has to implement that traffic forwarding and load-balancing behavior. Historically, this has been the job of kube-proxy, using mechanisms like:

iptables
IPVS

Modern clusters can also implement this using eBPF. We're deliberately not diving into these internals yet — that's reserved for Level 8. For now, just remember the abstraction:

Service IP → Service dataplane → Backend Pod

Level 3 Checkpoint

1. Why do we need a Service?
→ Because Pod IPs are dynamic and temporary.

2. What does a Service provide?
→ A stable virtual endpoint/IP for accessing a group of Pods.

3. How does a Service find its Pods?
→ Using a selector, typically based on labels.

4. What is a ClusterIP?
→ The stable virtual IP of a Service, normally used for internal cluster access.

5. What is port?
→ The port exposed by the Service itself.

6. What is targetPort?
→ The port on the backend Pod/container that actually receives the traffic.

7. Does a Service create Pods?
→ No. A Deployment manages Pods; a Service provides networking to them.

8. What tracks the current backend endpoints?
→ EndpointSlices.

9. Does Pod-to-Pod communication require a Service?
→ No — Pods can always communicate directly via Pod IPs. A Service is useful when you don't want to depend on individual, changing Pod IPs.

What's Next: Service Discovery and DNS

In Level 4, we'll answer the natural follow-up question this article left open:

How does backend:80 magically turn into a Service IP like 10.96.120.50?

We'll cover CoreDNS, DNS records, Service names, namespaces, FQDNs, and Pod DNS — without jumping ahead into the Level 8 dataplane internals.

Conclusion

Services are the answer to one of the most fundamental problems in Kubernetes: Pods are ephemeral, but applications need something stable to talk to. By giving a group of Pods a single, unchanging virtual IP — and continuously tracking the live backend set via EndpointSlices — Kubernetes lets you scale, crash, and replace Pods freely without ever breaking the applications that depend on them.

The mental model to hold onto: Pods are workloads with temporary IPs; Services are stable networking abstractions in front of them. Everything else — ClusterIP, NodePort, LoadBalancer, selectors — is just a variation on that one idea.

Found this helpful? Follow along for Level 4, where we connect Service names to DNS and finally explain how backend resolves into a real IP address. Drop your questions below, and share this with a teammate who still isn't sure why Services and Deployments are two separate objects. Let's keep building this Kubernetes networking roadmap together. 🚀

Kubernetes Networking [Level-2: Pod-to-Pod Communication]

ADITYA RAJ — Sat, 15 Aug 2026 10:20:11 +0000

This is Level 2 of our Kubernetes networking series. In Level 0, we covered core Linux networking primitives, and in Level 1, we learned how a Pod gets its own network namespace, eth0 interface, and IP address.

Now it's time to answer one of the most important questions in Kubernetes networking:

How does Pod A actually communicate with Pod B?

We'll start with the simplest possible case and work our way up to a full hop-by-hop trace of cross-node Pod traffic — including routing, overlay networking, VXLAN, and BGP.

Our Scenario
The Kubernetes Networking Expectation
First Case: Same-Node Communication
How Pod A Knows Where to Send the Packet
Crossing the Node Boundary
The Node Routing Table
Who Creates These Routes?
Two Major Approaches: Routing vs Overlay
Overlay Networking: A Simple Analogy
Why We Need Encapsulation
VXLAN in a Nutshell
Routing Without an Overlay
Why BGP Shows Up Here
The Complete Cross-Node Packet Journey
Pod IP vs Node IP
Why You Can't Just Use Pod IPs on the Internet
Kubernetes Doesn't Mandate an Overlay
Same-Node vs Cross-Node: A Quick Reference
The Big Problem We've Just Created
What's Next: Kubernetes Services

Our Scenario

Let's set up a concrete example. We have two Pods:

Pod A
IP: 10.244.1.5
Node: node-1

Pod B
IP: 10.244.2.5
Node: node-2

Visually:

              Kubernetes Cluster

   Node 1                              Node 2
┌───────────────┐                  ┌───────────────┐
│ Pod A         │                  │ Pod B         │
│ 10.244.1.5    │                  │ 10.244.2.5    │
└───────┬───────┘                  └───────▲───────┘
        │                                  │
        └──────────── Network ─────────────┘

Pod A wants to send traffic to Pod B: 10.244.1.5 → 10.244.2.5.

The Kubernetes Networking Expectation

Kubernetes enforces an important networking model:

Every Pod should be able to communicate with every other Pod, without anyone needing to manually manage routes for each Pod.

Ideally, from the application's point of view:

Pod A (10.244.1.5) → HTTP → Pod B (10.244.2.5)

The application shouldn't need to know:

Is Pod B on Node 1 or Node 2?
Is the traffic going over VXLAN?
Is it using BGP?
Is it using eBPF?

All of that complexity belongs to the networking layer, not the application.

First Case: Same-Node Communication

Let's start with the easier scenario: both Pods live on the same Node.

Node 1
Pod A: 10.244.1.5
Pod B: 10.244.1.6

Conceptually, traffic flows like this:

Pod A
  ↓
eth0
  ↓
veth
  ↓
Node networking
  ↓
veth
  ↓
eth0
  ↓
Pod B

The exact implementation depends on the CNI plugin, but the core idea holds:

Pod A → Node networking → Pod B

How Pod A Knows Where to Send the Packet

Remember ip route from Level 0? Every Pod has its own routing table. For example:

default via 10.244.1.1 dev eth0
10.244.1.0/24 dev eth0

When Pod A wants to reach 10.244.1.6, Linux checks: do I have a route for this? Yes — it falls within 10.244.1.0/24. So Linux sends the packet out through eth0.

Crossing the Node Boundary

Now the interesting case: Pod A and Pod B are on different Nodes.

Pod A (10.244.1.5) on Node 1
              ↓
Pod B (10.244.2.5) on Node 2

Pod A sends a packet with:

Source:      10.244.1.5
Destination: 10.244.2.5

The packet leaves the Pod through eth0, crosses the veth pair, and lands on Node 1's networking stack. Now Node 1 has to answer a critical question:

Where is 10.244.2.5?

The Node Routing Table

Node 1 needs to know how to reach the Pod network living on Node 2. Conceptually, it might have a routing table like:

10.244.1.0/24 → local
10.244.2.0/24 → Node 2

In plain terms:

10.244.1.x → my local Pods
10.244.2.x → Pods on Node 2

So the flow becomes:

Pod A → Node 1 → Route → Node 2 → Pod B

This is the fundamental shape of all cross-node Pod traffic in Kubernetes.

Who Creates These Routes?

This is exactly where the CNI implementation becomes important. Different networking plugins solve this problem differently, using mechanisms such as:

Routing
Overlay networking
VXLAN
Geneve
BGP
Cloud-native routing
eBPF

We'll dig into specific CNI implementations properly in Level 7. For now, just remember: CNI's job is to make sure the network knows how to reach every Pod IP.

Two Major Approaches: Routing vs Overlay

There are two broad strategies Kubernetes networking implementations use to make cross-node Pod traffic work.

Approach 1 — Routing

The underlying physical (or cloud) network is taught how to reach each Pod network directly:

Pod A → Node 1 → Router → Node 2 → Pod B

Approach 2 — Overlay

The Pod's packet gets encapsulated inside another packet addressed between Nodes:

Original packet:
10.244.1.5 → 10.244.2.5

        ↓ encapsulation

Outer packet:
Node1-IP → Node2-IP
    |
    | carries
    ↓
10.244.1.5 → 10.244.2.5

We'll explore both approaches in more depth below.

Overlay Networking: A Simple Analogy

Imagine sending a letter between two buildings, but the postal system only understands building addresses — not individual recipients. So you put your letter (addressed to a specific person) inside an outer envelope addressed to the building itself:

Outer envelope: Node 1 → Node 2
Inside:         Pod A → Pod B

That's essentially what packet encapsulation does:

Outer packet
┌──────────────────────────────┐
│ Node 1 → Node 2              │
│                              │
│   Inner packet               │
│   Pod A → Pod B              │
└──────────────────────────────┘

Why We Need Encapsulation

Suppose the physical network only knows about Node IPs, like 192.168.1.10 and 192.168.1.20 — it has no idea what 10.244.1.5 or 10.244.2.5 even are. The physical network understands Nodes, not Pods.

So the trick is to communicate at the level the network does understand (Node to Node), while carrying the Pod-level conversation inside:

Node 1 (192.168.1.10) → Node 2 (192.168.1.20)
       carries
Pod A (10.244.1.5) → Pod B (10.244.2.5)

VXLAN in a Nutshell

VXLAN is one of the most common technologies used to implement overlay networking. You don't need to master every detail yet — just the high-level flow:

Pod packet (10.244.1.5 → 10.244.2.5)
       ↓
VXLAN encapsulation
       ↓
Node 1 → Node 2
       ↓
VXLAN decapsulation
       ↓
Pod B

Or more generally:

Pod → Overlay → Node → Network → Node → Overlay → Pod

Routing Without an Overlay

An alternative approach is to make the underlying network itself understand Pod networks directly — no encapsulation required.

Node 1 — Pod CIDR: 10.244.1.0/24
Node 2 — Pod CIDR: 10.244.2.0/24

If the network knows:

10.244.1.0/24 → Node 1
10.244.2.0/24 → Node 2

...then traffic can be routed directly, with no wrapping/unwrapping step:

Pod A → Node 1 → Router → Node 2 → Pod B

Why BGP Shows Up Here

You'll eventually run into BGP (Border Gateway Protocol) in Kubernetes networking discussions — don't let the name intimidate you. At a high level, BGP is simply a protocol for distributing routes across the network.

For example:

Node 1 announces: "10.244.1.0/24 is reachable through me"
Node 2 announces: "10.244.2.0/24 is reachable through me"

Once these routes propagate, the network can route Pod traffic directly — no overlay needed. Some CNI implementations use BGP specifically for this purpose.

The Complete Cross-Node Packet Journey

Let's trace a full request from Pod A (10.244.1.5) to Pod B (10.244.2.5) step by step.

Step 1 — Application: Pod A's application sends GET /api to 10.244.2.5:8080.

Step 2 — Pod network namespace: Linux sees source 10.244.1.5, destination 10.244.2.5.

Step 3 — Pod eth0: The packet leaves the Pod via eth0.

Step 4 — veth: The packet crosses the veth pair from the Pod namespace into the Node namespace.

Step 5 — Node routing: Node 1 asks "where is 10.244.2.5?" and finds that 10.244.2.0/24 → Node 2.

Step 6 — Cross-node network: Depending on the CNI implementation, this hop uses routing, an overlay, eBPF, or cloud-native networking.

Step 7 — Node 2: The packet arrives and Node 2 determines that 10.244.2.5 belongs to Pod B.

Step 8 — Pod B: The packet travels Node 2 → veth → Pod B network namespace → eth0 → application.

Putting it all together:

Pod A (10.244.1.5)
   ↓
eth0 → veth → Node 1
   ↓
Routing / Overlay / eBPF
   ↓
Node 2 → veth → eth0
   ↓
Pod B (10.244.2.5)

Pod IP vs Node IP

This distinction trips up a lot of people, so let's be explicit. Suppose:

Node 1: 192.168.1.10 → Pod A: 10.244.1.5
Node 2: 192.168.1.20 → Pod B: 10.244.2.5

These live in two entirely separate networks:

Node network: 192.168.1.0/24
Pod network:  10.244.0.0/16

A Pod's IP is not the same as, or derived from, its Node's IP. Keep this mental separation clear — it will save you a lot of confusion later.

Why You Can't Just Use Pod IPs on the Internet

A private Pod IP like 10.244.1.5 isn't reachable directly from the public internet. Instead, traffic typically flows like this:

Internet
   ↓
Load Balancer / Ingress
   ↓
Kubernetes
   ↓
Service
   ↓
Pod

This is precisely why Kubernetes has dedicated abstractions — Services, Ingress, and Gateway API — which we'll cover soon.

Kubernetes Doesn't Mandate an Overlay

Here's an important point, especially if you're prepping for interviews: it's a common misconception that "Kubernetes networking uses an overlay network." That's not universally true.

Kubernetes defines a networking model (every Pod can reach every other Pod by IP), but it doesn't dictate how that model is implemented:

Kubernetes networking model
           |
     ┌─────┼─────┐
     ↓     ↓     ↓
 Routing Overlay eBPF

The specific CNI plugin you choose determines the actual implementation.

Same-Node vs Cross-Node: A Quick Reference

Traffic	What Happens Conceptually
Pod → Pod, same Node	Node-local networking
Pod → Pod, different Nodes	Cross-node routing/overlay/dataplane
Pod → Internet	Node/network egress path
Internet → Pod	Usually LoadBalancer/Ingress/Gateway + Service
Pod → Service	Service dataplane selects a backend Pod

That last row is exactly the problem we tackle next.

The Big Problem We've Just Created

So far, Pod A → Pod B works fine. But there's a serious practical problem lurking here.

Suppose we have three backend Pods:

Backend Pod 1: 10.244.1.5
Backend Pod 2: 10.244.2.5
Backend Pod 3: 10.244.3.5

The frontend needs to call the backend — but which IP should it use? And what happens when Backend Pod 1 dies and Kubernetes replaces it with a brand-new Pod at a brand-new IP, say 10.244.4.8?

We clearly don't want applications hardcoding or tracking individual Pod IPs.

The Problem

Pod IPs are:

Dynamic
Temporary
Tied to individual Pod lifecycles

Applications shouldn't have to manage any of that.

The Solution

A Kubernetes Service — a stable abstraction sitting in front of a changing set of Pods:

Frontend
   ↓
Service
   ├──→ Pod 1
   ├──→ Pod 2
   └──→ Pod 3

What's Next: Kubernetes Services

In Level 3, we'll build up Services from first principles, starting with the exact question this article ends on:

Why can't I simply use a Pod IP?

From there, we'll progressively cover:

What is a Service?
       ↓
ClusterIP
       ↓
Selectors
       ↓
Endpoints / EndpointSlices
       ↓
How Service traffic actually reaches Pods
       ↓
Service types: NodePort, LoadBalancer, ExternalName

We'll then trace a complete request:

Frontend Pod → Service IP → Kubernetes dataplane → Backend Pod

That's where components like kube-proxy, iptables, IPVS, and eBPF will finally start making sense — though we'll save their deep internals for Level 8, right on schedule with the rest of this roadmap.

Conclusion

Pod-to-Pod communication is the connective tissue of Kubernetes networking. Same-node traffic is fairly straightforward — it stays within the Node's networking stack via veth pairs. Cross-node traffic is where things get interesting: the network needs a way to route or encapsulate Pod IPs that it may not natively understand, whether through direct routing, VXLAN-based overlays, or BGP-distributed routes.

The most important takeaway is this: Kubernetes defines what should happen (any Pod can reach any other Pod by IP), not how — that's the CNI plugin's job. And because Pod IPs are inherently unstable, we need a better abstraction for talking to a group of Pods reliably. That abstraction is the Service, and it's exactly where we're headed next.

Enjoyed this deep dive? Follow along for Level 3, where we build Kubernetes Services from the ground up and trace a real request from a frontend Pod all the way to a backend Pod. Drop your questions in the comments, and share this with a teammate still wondering why their Pod IP keeps changing. Let's keep demystifying Kubernetes networking together. 🚀

Kubernetes Networking [Level-1: Pod Networking]

ADITYA RAJ — Sat, 15 Aug 2026 06:30:00 +0000

This is Level 1 of our Kubernetes networking series. In Level 0, we built a foundation of core Linux networking concepts — IP addresses, ports, network namespaces, veth pairs, and bridges. Now it's time to connect that foundation directly to Kubernetes.

The central question for this article is deceptively simple:

When Kubernetes creates a Pod, how does that Pod actually get a network interface and an IP address?

By the end of this guide, you'll be able to trace the full journey — from kubectl run to a running Pod with a working eth0 — and understand exactly which component is responsible for each step.

The Problem Kubernetes Has
The Solution: CNI
Every Pod Gets Its Own Network Namespace
Inspecting the Pod's eth0
Where Does eth0 Connect? The veth Pair
Why We Need the veth Pair
Multiple Pods on One Node
Where Does the Pod IP Come From?
Understanding Pod CIDR
Node CIDR vs Pod CIDR
The Complete Pod Networking Stack
What Happens When a Pod Is Created
The Pause Container: Kubernetes' Hidden Detail
Multiple Containers, One Network Namespace
Port Collisions Inside a Pod
Pod-to-Pod Communication (Same Node)
Pods on Different Nodes
The Kubernetes Networking Model
What CNI Actually Does: A Preview
Hands-On: Inspecting a Real Pod
Level 1 Mental Model
Level 1 Checkpoint
What's Next: Pod-to-Pod Communication

The Problem Kubernetes Has

Picture a bare Kubernetes Node with no Pods running yet:

Node
┌─────────────────────────────────────┐
│        Kubernetes Node              │
│              ???                    │
└─────────────────────────────────────┘

Now Kubernetes wants to run a Pod:

Pod
┌─────────────────┐
│ nginx           │
│ eth0            │
│ 10.244.1.5      │
└─────────────────┘

Here's the catch: who creates eth0? Who assigns the Pod its IP, 10.244.1.5? And who connects that interface to the Node's network?

Linux doesn't do any of this automatically just because Kubernetes decided to create a Pod. We need a dedicated networking component to make it happen.

The Solution: CNI

This is where the Container Network Interface (CNI) comes in. Think of CNI as:

The component responsible for connecting a newly created Pod to the network.

Simplified, the flow looks like this:

Kubernetes
    | "I created a Pod."
    ↓
Container Runtime
    | "Pod needs networking."
    ↓
CNI
    ├── Create network namespace
    ├── Create veth pair
    ├── Put one side inside the Pod
    ├── Connect the other side to the Node
    ├── Assign an IP
    └── Configure routes

We'll go much deeper into CNI implementations later in this series (Level 7). For now, just remember its role: CNI is what gives Pods networking.

Every Pod Gets Its Own Network Namespace

Remember network namespaces from Level 0? A Kubernetes Pod gets its own network namespace, giving it an isolated networking environment:

Node
┌─────────────────────────────────────────┐
│   Pod Network Namespace                 │
│   ┌───────────────────────────────┐     │
│   │   eth0                        │     │
│   │   10.244.1.5                  │     │
│   └───────────────────────────────┘     │
└─────────────────────────────────────────┘

This isolation is exactly what allows dozens of Pods to run on the same Node without their networking colliding.

Inspecting the Pod's eth0

Inside a running Pod, running:

ip addr

typically shows something like:

1: lo
2: eth0@if123
    inet 10.244.1.5/24

The important takeaway: the Pod has its own network interface (eth0) and its own IP address (10.244.1.5).

Where Does eth0 Connect? The veth Pair

This is where our Level 0 knowledge pays off. A Pod's eth0 is typically connected to the Node using a veth pair — the same mechanism we covered earlier.

                 Kubernetes Node
┌─────────────────────────────────────────────┐
│  Pod namespace                              │
│  ┌────────────────────┐                     │
│  │ eth0               │                     │
│  │ 10.244.1.5         │                     │
│  └─────────┬──────────┘                     │
│            │                                │
│          veth                               │
│            ║                                │
│          veth                               │
│            │                                │
│            ↓                                │
│       Node network                          │
└─────────────────────────────────────────────┘

Think of it as a virtual cable: one end (eth0) lives inside the Pod, and the other end (veth) lives on the Node.

Why We Need the veth Pair

The Pod is isolated inside its own network namespace, which means it has no natural connection to the Node's namespace:

Pod namespace
     |
     | ???
     |
Node namespace

The veth pair bridges that gap:

Pod namespace
     |
   eth0
     |
   veth
     ║
   veth
     |
Node namespace

In short, the veth pair is the virtual cable that connects an isolated Pod to the rest of the Node's networking stack.

Multiple Pods on One Node

Now imagine three Pods running on the same Node:

Pod A → 10.244.1.5
Pod B → 10.244.1.6
Pod C → 10.244.1.7

Conceptually, the Node might look like this:

                    Node
┌────────────────────────────────────────────┐
│ Pod A (10.244.1.5)                         │
│    │                                       │
│   veth ───────────┐                        │
│                    ↓                       │
│                 Bridge                     │
│                    ↑                       │
│   veth ───────────┘                        │
│    │                                       │
│ Pod B (10.244.1.6)                         │
│                                            │
│ Pod C (10.244.1.7)                         │
└────────────────────────────────────────────┘

The exact implementation varies by CNI plugin, but the mental model stays consistent:

Pod → eth0 → veth → Node networking

Where Does the Pod IP Come From?

Who decided Pod A should get 10.244.1.5? The networking implementation allocates IPs from a defined address range.

For example, a cluster might use a Pod CIDR of 10.244.0.0/16, split into smaller ranges per Node:

Node 1: 10.244.1.0/24
Node 2: 10.244.2.0/24
Node 3: 10.244.3.0/24

So on Node 1:

Pod A → 10.244.1.5
Pod B → 10.244.1.6
Pod C → 10.244.1.7

This is just one example architecture — different CNIs and cluster configurations allocate ranges differently, so don't memorize these exact numbers.

Understanding Pod CIDR

A Pod CIDR is the IP address range allocated for all Pods in the cluster. For example, 10.244.0.0/16 represents a large address space reserved specifically for Pod IPs:

Cluster
└── Pod Network
       ├── 10.244.1.x
       ├── 10.244.2.x
       ├── 10.244.3.x
       └── ...

Again, actual ranges vary by cluster and CNI plugin — what matters is understanding the concept.

Node CIDR vs Pod CIDR

This distinction trips up a lot of beginners. Consider:

Node IP: 192.168.1.10
Pod IP:  10.244.1.5

These belong to entirely different networks:

Node Network: 192.168.1.0/24
       ↓
Pod Network:  10.244.0.0/16

Don't assume a Pod's IP belongs to the same subnet as its Node's IP — in most Kubernetes setups, it doesn't. This is one of the key ideas that unlocks the rest of Kubernetes networking.

The Complete Pod Networking Stack

Putting it all together:

                     Kubernetes Node
┌───────────────────────────────────────────────┐
│  Pod Network Namespace                        │
│  ┌───────────────────────────┐                │
│  │ Container                 │                │
│  │ Application               │                │
│  │     ↓                     │                │
│  │   eth0 (10.244.1.5)       │                │
│  └────────────┬──────────────┘                │
│               │                               │
│             veth                              │
│               ║                               │
│             veth                              │
│               │                               │
│               ↓                               │
│        Node networking                        │
│               │                               │
│               ↓                               │
│         Physical NIC                          │
└───────────────┼───────────────────────────────┘
                ↓
             Network

What Happens When a Pod Is Created

Let's walk through the sequence triggered by:

kubectl run nginx --image=nginx

Kubernetes receives the request.
The Pod gets scheduled onto a Node.
The container runtime prepares the Pod.
Networking gets configured:

Pod created
    ↓
Network namespace created
    ↓
CNI called
    ↓
veth pair created
    ↓
Pod gets eth0
    ↓
IP assigned
    ↓
Routes configured
    ↓
Pod networking ready
    ↓
Container starts

This sequence is one of the most important things to internalize in this article.

The Pause Container: Kubernetes' Hidden Detail

Here's a subtlety many tutorials skip: Kubernetes doesn't give every container its own network namespace — it gives every Pod one shared namespace, owned by a special pause container.

Pod
┌─────────────────────────────────┐
│  Pause container                │
│       └── Pod network namespace │
│                                 │
│  nginx container                │
│  sidecar container              │
└─────────────────────────────────┘

Every container in the Pod shares the Pod's:

network namespace
IP address
network interfaces
ports

Multiple Containers, One Network Namespace

Consider a Pod with three containers:

Pod
┌────────────────────────────────────┐
│  Container A                       │
│  Container B                       │
│  Container C                       │
│                                    │
│  Shared network namespace          │
│  eth0 → 10.244.1.5                 │
└────────────────────────────────────┘

All three containers share 10.244.1.5 and can talk to each other over localhost:

Container A → localhost:8080 → Container B

...provided Container B is actually listening on that port.

Port Collisions Inside a Pod

Because containers in a Pod share a network namespace, this can happen:

Container A → :8080
Container B → :8080   ❌

This is a real conflict — two processes can't simultaneously own 10.244.1.5:8080. This is a great example of why understanding raw Linux networking (from Level 0) directly explains real Kubernetes behavior.

Pod-to-Pod Communication (Same Node)

Now suppose Pod A (10.244.1.5) and Pod B (10.244.1.6) are on the same Node:

Pod A (10.244.1.5)
    ↓
  veth
    ↓
Node networking
    ↓
  veth
    ↓
Pod B (10.244.1.6)

The exact mechanism depends on the CNI plugin in use — we'll dig into specific implementations in Level 2 and Level 7.

Pods on Different Nodes

Here's where things get genuinely interesting. Consider two Pods on two different Nodes:

Node 1                         Node 2
Pod A: 10.244.1.5              Pod B: 10.244.2.5

Pod A wants to reach Pod B directly by IP:

┌──────────── Node 1 ────────────┐
│ Pod A (10.244.1.5)             │
└──────────────┬─────────────────┘
               │
               │ Network
               │
┌──────────────▼─────────────────┐
│ Node 2                         │
│ Pod B (10.244.2.5)             │
└────────────────────────────────┘

This raises a critical question: how does traffic from Pod A reach a Pod IP living on a completely different machine? That question is exactly where Level 2 of this series picks up.

The Kubernetes Networking Model

Kubernetes enforces an important networking guarantee:

Pod A → (direct Pod IP) → Pod B

Pods must be able to communicate across Nodes without the application needing to know or care which Node they're running on. The underlying networking implementation is responsible for making this transparent, typically using one of:

Overlay networking
Routing-based networking
Encapsulation (e.g., VXLAN)
Cloud-native networking
eBPF-based networking

We'll explore each of these approaches later in the series.

What CNI Actually Does: A Preview

By now you have a much clearer picture of what "CNI" really means. When a Pod is created, the CNI plugin handles:

CNI
 ├── Network namespace
 ├── veth pair
 ├── Pod interface
 ├── IP address
 ├── Routes
 └── Connectivity

Don't worry about specific CNI implementations yet — that's reserved for Level 7. For now: CNI is the mechanism that gives Pods networking.

Hands-On: Inspecting a Real Pod

Let's verify everything we've learned with real commands.

Create a Pod:

kubectl run nginx --image=nginx

Check its IP and Node:

kubectl get pod -o wide

NAME    READY   STATUS    IP            NODE
nginx   1/1     Running   10.244.1.5    node-1

You now have a direct mapping: Pod name → Pod IP → Node.

Check the interface inside the Pod:

kubectl exec -it nginx -- ip addr

lo
eth0@if...
    inet 10.244.1.5/...

This confirms the chain: Pod → network namespace → eth0 → Pod IP.

Check the Pod's routing table:

kubectl exec -it nginx -- ip route

default via ...
10.244.1.0/24 dev eth0

The exact output depends on your CNI plugin, but the key question the routing table answers is always the same: where does the Pod send traffic when it wants to reach something?

Note: At this point you might come across implementation-specific interfaces like docker0, cni0, flannel.1, vxlan.calico, cilium_host, or cilium_net. Don't let these confuse you — they're all specific implementations of the same abstraction: Pod → namespace → eth0 → veth → Node networking → CNI.

Level 1 Mental Model

You should now be able to visualize a Node running multiple Pods like this:

                    NODE
┌────────────────────────────────────────────┐
│  Pod A                                     │
│  ┌─────────────────────────────┐           │
│  │ Network Namespace           │           │
│  │ eth0 (10.244.1.5)           │           │
│  └─────────────┬───────────────┘           │
│                │                           │
│              veth                          │
│                ║                           │
│                ↓                           │
│         Node networking                    │
│                                            │
│  Pod B                                     │
│  ┌─────────────────────────────┐           │
│  │ Network Namespace           │           │
│  │ eth0 (10.244.1.6)           │           │
│  └─────────────┬───────────────┘           │
│                │                           │
│              veth                          │
│                ║                           │
│                ↓                           │
│         Node networking                    │
└────────────────────────────────────────────┘

The core chain to remember:

Pod → Network Namespace → eth0 → veth pair → Node networking → CNI

And two important corollaries:

Each Pod gets its own IP.
Containers within the same Pod share that Pod's network namespace, IP, and can talk to each other via localhost.

The fundamental communication model in Kubernetes is simply:

Pod A → Pod IP → Pod B

Level 1 Checkpoint

Before moving to Level 2, make sure these all make sense to you:

Q1. Who gives a Pod its networking?
→ The CNI (networking implementation).

Q2. Does a Pod have its own IP?
→ Yes.

Q3. Does each container in a Pod get its own IP?
→ No — containers in the same Pod share the Pod's network namespace and IP address.

Q4. What connects the Pod's network namespace to the Node?
→ Commonly, a veth pair.

Q5. Where does eth0 exist?
→ Inside the Pod's network namespace.

Q6. Why do we need CNI at all?
→ Kubernetes needs a networking implementation to create and configure Pod networking and provide connectivity between Pods.

What's Next: Pod-to-Pod Communication

In Level 2, we'll tackle the most important networking question in this series so far:

Pod A has 10.244.1.5. Pod B has 10.244.2.5. They're on different Nodes. How does a packet actually travel from A to B?

We'll trace the packet hop by hop:

Pod A → eth0 → veth → Node 1 → routing → CNI network → Node 2 → veth → Pod B

...and compare same-node versus cross-node Pod communication in detail.

Conclusion

Pod networking is where Kubernetes and Linux networking truly meet. Every Pod gets its own network namespace and eth0 interface, connected to the Node via a veth pair, with an IP address allocated from the cluster's Pod CIDR — all orchestrated by the CNI plugin. Containers within a Pod share that networking environment entirely, which is why they can talk to each other over localhost but must be careful about port collisions.

The best way to cement these concepts is to try it yourself: spin up a Pod, run kubectl get pod -o wide, then kubectl exec in and inspect ip addr and ip route. Seeing the abstraction match real output is what makes the model stick.

Found this useful? Follow along for Level 2, where we trace a packet's full hop-by-hop journey between Pods on different Nodes. Drop a comment with your questions, and share this with someone still mixing up Pod CIDR and Node CIDR — let's keep demystifying Kubernetes networking together. 🚀

Kubernetes Networking [Level-0: Linux Networking Basics for Kubernetes]

ADITYA RAJ — Sat, 15 Aug 2026 06:30:00 +0000

If you've ever opened a Kubernetes networking doc and seen words like CNI, veth, network namespace, bridge, iptables, or eBPF and felt completely lost — you're not alone. The truth is, none of these concepts are Kubernetes-specific. They're all built directly on top of Linux networking primitives.

This guide is "Level 0" of a Kubernetes networking series. Before we touch a single Kubernetes manifest, we're going to build a rock-solid mental model of how Linux moves packets around — because once you understand that, Kubernetes networking stops feeling like magic and starts feeling like Lego blocks snapping together.

What Problem Does Networking Solve?
IP Addresses: Identifying a Machine
Ports: Identifying an Application
Network Interfaces
Loopback and localhost
Network Namespaces
Why Namespaces Matter
veth Pairs: Virtual Network Cables
Linux Bridges: Virtual Switches
Routing Tables
Default Gateway
NAT: Network Address Translation
The Full Packet Journey
Essential Linux Networking Commands
Putting It All Together: A Mental Model
Level 0 Checkpoint
What's Next: Pod Networking

What Problem Does Networking Solve?

At its core, networking answers one simple question: how does data get from one machine to another?

Imagine two computers on a network:

Computer A                         Computer B
10.0.0.10                          10.0.0.20

   Application  ─────────────────→  Application

Application A wants to send data to Application B. Networking is the set of rules and mechanisms that make this possible — and everything in this article builds toward answering that question in increasingly precise ways.

IP Addresses: Identifying a Machine

An IP address identifies a network endpoint — think of it as a machine's postal address.

Person
  ↓
House address
  ↓
10.0.0.10

If you want to send traffic to a specific machine, you address it using its IP:

Destination = 10.0.0.10

Ports: Identifying an Application

A single machine usually runs many applications at once. So how does traffic know which application to reach? That's what ports are for.

10.0.0.10

22     → SSH
80     → HTTP
443    → HTTPS
8080   → Application
5432   → PostgreSQL

In short:

IP = which machine?
Port = which application on that machine?

For example, 10.0.0.10:8080 means: send traffic to machine 10.0.0.10, on port 8080.

Network Interfaces

A computer needs a "door" through which network traffic enters and leaves. That door is called a network interface.

On Linux, you can list interfaces with:

ip addr

You'll typically see names like lo, eth0, or on modern systems, ens5 or enp0s3. Don't worry about the naming conventions yet — just know that every interface is a gateway between an application and the outside network.

Application
     |
     ↓
Network stack
     |
     ↓
   eth0
     |
     ↓
   Network

Loopback and localhost

You'll frequently encounter this address:

127.0.0.1

This is the loopback address — it always means "this machine, talking to itself."

Application A
     |
     ↓
127.0.0.1
     |
     ↓
Same machine

For example:

curl http://127.0.0.1:8080

This tells your machine: connect to port 8080 on myself. The hostname localhost typically resolves to this same address.

Network Namespaces

Now we reach a concept that is critical for understanding Kubernetes: network namespaces.

Linux lets you create fully isolated networking environments on a single machine. Each one can have its own interfaces, IP addresses, routing table, and firewall rules.

Linux Machine

┌──────────────────────────────┐
│ Network Namespace A          │
│ IP: 10.0.0.10                │
└──────────────────────────────┘

You can spin up another, completely isolated from the first:

Linux Machine

┌──────────────────────────────┐
│ Namespace A                  │
│ IP: 10.0.0.10                │
│                              │
│ Namespace B                  │
│ IP: 10.0.0.20                │
└──────────────────────────────┘

This concept becomes essential once we talk about Kubernetes Pods — each Pod gets its own network namespace.

Why Namespaces Matter

Imagine two applications that both want to bind to port 8080 on the same machine:

Machine

Application A → :8080
Application B → :8080   ❌

Without isolation, this fails — two processes can't bind the same host IP/port combination.

But give each application its own network namespace, and the conflict disappears:

Namespace A → 10.0.0.10:8080
Namespace B → 10.0.0.20:8080

Both can happily use port 8080 because they live in separate network environments. This is the foundational idea behind containers — and by extension, Kubernetes Pods.

veth Pairs: Virtual Network Cables

Isolated namespaces are only useful if we can also connect them. Linux provides a mechanism called a veth pair for exactly this purpose.

Think of a veth pair as a virtual network cable with two ends — anything that goes in one end comes out the other.

Namespace A                    Host

   eth0
    |
  veth-A  ═══════════════  veth-B
                              |
                           Host network

One end lives inside a namespace; the other end lives on the host (or in another namespace). This is exactly how a container's network interface gets connected to the outside world.

Linux Bridges: Virtual Switches

Once you have multiple namespaces, you need a way to connect all of them together — not just in pairs. That's where a Linux bridge comes in.

             Linux Bridge
           ┌──────────────┐
           │    bridge    │
           └─┬────┬────┬──┘
             │    │    │
             ↓    ↓    ↓
            A     B    C

A helpful mental model: a bridge is essentially a virtual Layer-2 switch. Each namespace connects to the bridge via its own veth pair, and the bridge forwards traffic between them just like a physical switch would.

Routing Tables

Now suppose you have two separate networks:

Network A: 10.0.1.0/24
Network B: 10.0.2.0/24

A machine on Network A wants to reach 10.0.2.10. How does Linux decide where to send that packet? It consults its routing table.

You can inspect it with:

ip route

Example output:

10.0.1.0/24 dev eth0
10.0.2.0/24 via 10.0.1.1
default via 10.0.1.1

Read each line as: for this destination network, send traffic here.

Default Gateway

What if your machine wants to reach an address it has no specific route for — like 8.8.8.8? It falls back to the default route, also known as the default gateway.

default via 10.0.0.1

This simply means: "If I don't know where else to send this traffic, send it to 10.0.0.1."

Your machine (10.0.0.10)
     |
     ↓
Gateway (10.0.0.1)
     |
     ↓
Internet

NAT: Network Address Translation

Here's another crucial concept. Suppose your private network is 10.0.0.0/24, and your machine is 10.0.0.10. The public internet has no idea how to route traffic back to a private address like that directly.

To solve this, a router performs NAT (Network Address Translation) — rewriting private addresses into a public one (and remembering the mapping so return traffic gets routed correctly).

Private network
10.0.0.10
     |
     | NAT
     ↓
Public IP
     |
     ↓
Internet

For example:

10.0.0.10:50000  →  203.x.x.x:40000

NAT will come up again and again once we start discussing Kubernetes traffic flows like Pod → Internet, Node → Internet, and Service → Pod.

The Full Packet Journey

Let's connect all the dots. Suppose Application A (10.0.0.10) wants to talk to Application B (10.0.0.20). The simplified journey looks like this:

Application A
      ↓
Socket
      ↓
TCP/IP stack
      ↓
Routing decision
      ↓
Network interface
      ↓
Network
      ↓
Network interface
      ↓
TCP/IP stack
      ↓
Application B

This flow — socket, stack, routing decision, interface, network, and back again — is the foundation for everything else you'll learn about Kubernetes networking.

Essential Linux Networking Commands

You don't need to memorize hundreds of commands. These few will get you very far:

# See interfaces and IP addresses
ip addr        # or: ip a

# See the routing table
ip route

# See interfaces briefly
ip link

# Test basic connectivity
ping <IP>

# Test an application/service
curl http://<IP>:<PORT>

# See listening ports
ss -lntp

These commands will become your go-to Kubernetes networking debugging toolkit later on — get comfortable with them now.

Putting It All Together: A Mental Model

Keep this picture in your head as your baseline model of a single Linux machine:

                 Linux Machine
┌────────────────────────────────────────┐
│ Application                            │
│      ↓                                 │
│ Socket                                 │
│      ↓                                 │
│ Network Stack                          │
│      ↓                                 │
│ Routing Table                          │
│      ↓                                 │
│ Network Interface                      │
└──────┼─────────────────────────────────┘
       ↓
     Network
       ↓
   Other machine

Now layer in network namespaces:

Linux Machine
│
├── Network Namespace A → eth0
├── Network Namespace B → eth0
└── Host Network Namespace → eth0

Connect them with veth pairs:

Namespace A
    |
   eth0
    |
  veth
    ║
  veth
    |
  Host

And tie them together with a bridge:

   Namespace A       Namespace B
        |                 |
        └───────┬─────────┘
             ┌───────┐
             │Bridge │
             └───────┘
                 |
              Network

This exact combination — namespace + veth + bridge + routing — is what Kubernetes uses under the hood to give every Pod its own network identity.

Level 0 Checkpoint

Before moving on to Pod networking, make sure you can explain each of these in plain, simple language:

IP address
Port
Network interface
Loopback
Network namespace
veth pair
Linux bridge
Routing table
Default gateway
NAT

And most importantly, internalize this relationship:

Network Namespace + veth + bridge + routing → Network connectivity

If that equation makes sense to you, you're ready for the next level.

What's Next: Pod Networking

In the next part of this series (Level 1), we'll take everything covered here and answer the first real Kubernetes networking question:

When Kubernetes creates a Pod, where does the Pod's network actually come from?

We'll trace the full path:

kubectl run nginx
       ↓
Kubernetes creates Pod
       ↓
Network namespace
       ↓
veth pair
       ↓
Pod eth0
       ↓
Pod IP
       ↓
Node network

That's the exact point where Linux networking transforms into Kubernetes networking.

Conclusion

Kubernetes networking can feel intimidating, but it's really just a clever composition of well-known Linux primitives: IP addresses, ports, network namespaces, veth pairs, bridges, routing tables, and NAT. Once these concepts click, terms like CNI, iptables, and eBPF stop being buzzwords and start being tools you understand at a mechanical level.

Take the time to run the commands in this article on your own Linux machine (or a cheap VM) — ip addr, ip route, ss -lntp — and get a feel for what your own system's networking actually looks like. That hands-on intuition is what makes the next level, Pod networking, click into place effortlessly.

Enjoyed this breakdown? If you're following along with this Kubernetes networking series, drop a comment, follow for Level 1 on Pod Networking, and share this with a teammate who's still afraid of iptables. Let's demystify Kubernetes networking together, one Linux primitive at a time. 🚀

DEV Community: ADITYA RAJ

Kubernetes Networking [Level-9: Kubernetes Networking Internals]

Table of Contents

The Complete Picture, First

Network Namespaces, Revisited

The veth Pair

Why eth0 Is Confusing

Pod → Node: The Core Diagram

Linux Routing Inside the Pod

Routing Is a Decision, Not Magic

Same-Node Pod Communication

The Linux Bridge

What Happens When the Packet Reaches the Node

Direct Pod Traffic vs Service Traffic

Netfilter: Linux's Packet-Processing Framework

Where iptables Fits In

NAT, Revisited With a Real Example

Why NAT Needs State

conntrack: Connection Tracking

Why conntrack Matters in Production

A Simplified Linux Packet Path

There's No Single Universal Packet Path

Pod-to-Pod, Same Node

Pod-to-Pod, Different Nodes

Overlay Internals

Why Overlays Exist

Routing-Based Networking

Why BGP Sometimes Appears

CNI vs the Linux Kernel

eBPF in the Internal Path

NetworkPolicy in the Packet Path

Service + NetworkPolicy Together

Why Services Don't Have Network Interfaces

Node IP vs Pod IP vs Service IP

Why Pod IPs Aren't Directly Routable from the Internet

A Full External Traffic Example

The Complete Kubernetes Networking Stack

A Real Packet Journey, Start to Finish

Return Traffic

What Can Break

The Most Important Troubleshooting Principle

Direct Pod IP vs Service IP: The Best Diagnostic Test

Useful Linux Commands

Seeing veth Interfaces

Seeing Routes

Seeing iptables

Seeing IPVS

Seeing eBPF

Interview Traps Worth Knowing

The Entire Series So Far

Level 9 Checkpoint

The Most Important Lesson From This Article

What's Next: Production Troubleshooting

Conclusion

Kubernetes Networking [Level-8: kube-proxy / iptables / IPVS / eBPF]

Table of Contents

The Problem: A Service IP Isn't a Real Interface

The Basic Idea: A Service Dataplane

What Is kube-proxy?

kube-proxy's Job

kube-proxy Doesn't Create Pods

kube-proxy Runs on Every Node

The Classic Mental Model: iptables and DNAT

What Is DNAT?

Tracing the Packet Journey

The Full Picture: DNS to Pod

iptables in Kubernetes

Control Plane vs Dataplane

Why EndpointSlices Matter Here

Load Balancing Across Endpoints

Session Affinity

The Scaling Problem with iptables

IPVS: IP Virtual Server

iptables vs IPVS

An Important Modern Nuance

eBPF Enters the Picture

Why eBPF Is Interesting for Kubernetes

Cilium and eBPF

eBPF Can Replace Parts of kube-proxy

Don't Confuse kube-proxy Replacement with CNI