Thursday, 26 February 2026

Kubernetes

 How Traffic Actually Moves Inside Kubernetes


There are only two directions traffic can move:
North–South → from outside the cluster into it
East–West → between services inside the cluster
Everything else is just implementation detail.

North–South: When a User Hits Your App
A request doesn’t magically “reach a pod.”
It passes through layers each with a very specific responsibility.
First, an Ingress or Gateway receives the request.

This is your traffic front door , it handles host rules, paths, TLS termination.
Then the request hits a Service.
The Service is not your app.

It’s a stable virtual endpoint that hides the fact that Pods come and go.
Behind the Service, kube-proxy programs routing rules (iptables/IPVS) so traffic is forwarded to one of the healthy Pods.

The Pod itself has a real IP assigned by the CNI plugin (like Calico or Cilium).
That CNI integrates with the Linux kernel networking stack and ensures packets actually move between nodes.
Underneath all of it?

Just standard Linux networking and your cloud/VPC infrastructure.
Nothing mystical.
Just layers doing one job each.

East–West: Service-to-Service Communication
Inside the cluster, things are cleaner.
When one service calls another:
DNS (CoreDNS) resolves the Service name
Traffic goes to the Service IP
kube-proxy forwards it to a backing Pod
CNI ensures packets can travel node-to-node
Kubernetes follows a flat network model:
Every Pod gets its own IP.
Every Pod can reach every other Pod (unless restricted by NetworkPolicy).

If you use a Service Mesh, you’re adding observability, mTLS, retries but the underlying routing model stays the same.

The Mental Model That Changes Everything
Think of Kubernetes networking as three stacked layers:
Abstraction layer → Ingress & Services
Routing layer → kube-proxy rules
Connectivity layer → CNI + Node networking

When something breaks, the issue is almost always in one of those three.
Once you see that separation clearly, debugging stops feeling random.

Kubernetes networking isn’t complicated.
It’s just layered and very opinionated.
Understand the flow once,
and the black box disappears.

If this made Kubernetes networking click for you, consider reposting so it clicks for someone else too.



No comments:

Post a Comment

Why do many Palo Alto engineers open a TAC case immediately… without checking anything first?

A production issue happens. Application team says “network issue.” Users say “firewall problem.” And within minutes someone says: “Let’s ope...