Stop 08 · Kubernetes & OrchestrationTopics · 4/12

Kubernetes Networking

In short

In Kubernetes, every pod gets its own IP and can reach every other pod, even on another node, with no port mapping. That picture explains most 'can't connect' bugs.

Every Pod gets its own IP address, and Kubernetes provides a flat network model where Pods can communicate across nodes — a different mental model from Docker's default single-host networking.

The mascot talks into a corridor intercom in a housing society, its wire running to another tower.

Think of it like this

The housing society intercom

In a big society, every flat has its own number and an intercom that can ring any other flat, even in another tower. You don't need to know the wiring. Pods are flats, the cluster network is the intercom, and DNS is the society directory.

Watch it happen

Pod to pod, through a Service

frontend pod

CoreDNS

Service api

api pod

api.shop.svc?

1/5The frontend asks the cluster DNS for the Service name. Inside the same namespace, just api works too.

The big ideas

What you need to know

Flat pod network

Every pod gets a unique IP. Pods talk to each other directly across nodes, with no NAT between them.

CNI plugins build it

Kubernetes defines the rules. A CNI plugin like Calico, Cilium or Flannel actually wires up the network.

DNS for everything

Every Service gets a name like api.shop.svc.cluster.local. Use names, never pod IPs.

Open by default

Any pod can reach any pod unless you add NetworkPolicies, and only if your CNI plugin supports them.

See it in code

Walk through the code

bash

1# Every pod gets its own IP2kubectl get pods -o wide3 4# Start a throwaway pod and test DNS + HTTP from inside the cluster5kubectl run tmp --rm -it --image=busybox:1.36 --restart=Never -- sh6nslookup web.default.svc.cluster.local7wget -qO- http://web

1/3The IP column shows each pod's own address. Pods on different nodes sit in different ranges.

Lines 6 and 7 run inside the busybox shell. This assumes the web Service from the Pods, Deployments & Services lesson exists in default.

Save yourself the pain

Common mistakes

Oops

Testing a Service from your laptop with curl and deciding it's broken.

Do this instead

ClusterIPs only work inside the cluster. Test from a pod, or use kubectl port-forward to reach it from your laptop.

Oops

Assuming pods in different namespaces can't talk to each other.

Do this instead

They can by default. Use NetworkPolicies to block traffic you don't want, such as dev pods reaching prod databases.

Your mission

Debug from inside

~20 min

Quick check

A pod on node-1 calls a pod on node-2 by its pod IP. What happens by default?

Go deeper

1Learn the basic Kubernetes networking model: every Pod gets a unique, routable IP.
2Practice using a Service's DNS name to reach another Pod, rather than a hardcoded IP.
3Understand this networking model is what makes Services and load balancing possible across a whole cluster.