Kubernetes networking for traditional network engineers

If you come from routing and switching, Kubernetes networking looks alien at first: addresses that appear and disappear, load balancing with no appliance, policy expressed as API objects. Underneath, it is still packets on links. This is a translation.

Pods have addresses, but you rarely route to them

Every pod gets an IP from the CNI plugin. If your CNI is flat (for example, a routed or overlay design that presents pods on a large internal network), pods are reachable directly. If it is not, they may only be reachable through the node or a service proxy.

The instinct to treat pod IPs like persistent endpoint addresses is the first thing to unlearn. Pod IPs are ephemeral and tied to the pod lifecycle. Anything durable is addressed through a Service.

Services are a stable name in front of ephemeral endpoints

A Service is a virtual IP (ClusterIP) with a set of endpoints. The kube-proxy (or an eBPF dataplane) programs the dataplane so traffic to the Service IP is load-balanced to the current endpoints. From a network engineer’s perspective, it is a distributed load balancer implemented on every node, with its member list maintained by the control plane.

That explains two behaviours that surprise people:

• the Service IP does not exist on any interface — it is a programmed forward;
• when pods move, the endpoints change and the dataplane follows, with no change to the address clients use.

A packet’s journey

Roughly, assuming an external client reaching an application:

1. The client hits an external IP or hostname.
2. Ingress (via an ingress controller) or a LoadBalancer/NodePort service terminates or forwards the connection.
3. The ingress controller routes to a Service.
4. The Service forwards to a pod endpoint.
5. The CNI delivers the packet to the pod’s namespace.

Each hop is programmable, observable and, importantly, software. That is the biggest cultural shift: the network inside the cluster is defined by APIs and controllers, not by a change window.

Where traditional skills still matter

• MTU and encapsulation. Overlay CNIs add headers; get the MTU wrong and you get mysterious, intermittent failures. This is exactly the kind of problem routing engineers already know how to reason about.
• Routing and reachability. Pod CIDRs, node peering, BGP-based CNIs, service advertisement — all familiar territory.
• Failure domains. Node and zone topology affect where pods land and how traffic flows.
• Performance and loss. The same laws apply. Lossless, latency-sensitive workloads (think GPU or storage) need the same care you would apply anywhere else.

The practical mental model

Keep it simple:

• Pod IP = ephemeral endpoint.
• Service = stable, virtual, load-balanced name.
• Ingress/LoadBalancer = the edge into the cluster.
• CNI = the plumbing that makes pod-to-pod reality.
• Controllers = the “routing protocol” that keeps it all converged.

You do not need to abandon your networking instincts. You need to map them onto a control plane that reconfigures the dataplane continuously, and to accept that the “devices” are now software you operate through an API.