DEV Community: ADITYA RAJ

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-6: Networking Policy]

Table of Contents

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

Selector Debugging

The Namespace Mistake

The Mental Model to Memorize

Level 6 Checkpoint

What's Next: CNI

Conclusion

Kubernetes Networking [Level-5: Ingress/Gateway]

Table of Contents

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

Conclusion

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

Table of Contents

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