Container Networking: Pod to Service

The scenario

Frontend-Pod (10.244.0.10) runs on one node's pod network, 10.244.0.0/24. API-Pod-1 (10.244.1.10) and API-Pod-2 (10.244.1.11) run on another node's pod network, 10.244.1.0/24, and serve an API on TCP 8080. The API Service has the virtual IP 10.96.0.20 and exposes port 8080. In this lab that Service is a load balancer device, API-Service: for each connection to 10.96.0.20:8080 it picks a pod, rewrites the destination to it and the source to its own pod-side address, 10.244.1.1. A live lab picks the pod at random for each connection; the simulator always shows API-Pod-1. Cluster-Router stands in for the pod network that carries traffic between nodes, and uses static routes only (OSPF is off).

What you will work out

Understand pod addresses, Service virtual IPs and the part kube-proxy plays, and why a Service keeps sending traffic to a broken pod unless readiness checks remove it.

Why this matters

Running 'kubectl expose deployment' creates exactly this kind of Service, and most traffic inside a cluster goes through one. When a call to a Service fails, the checks follow this lab: is the client using the port the Service declares, does the Service have ready pods behind it ('kubectl get endpointslices'), and is the process in each pod really listening? Knowing that the ClusterIP is a rewrite rule rather than a machine also explains why pinging a ClusterIP often gets no answer even when the Service works.

Running it

Container Networking: Pod to Service opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.