How a Kubernetes Service reaches a Pod

Each step shows who acts, the exact call it makes, and where the result is stored. Numbered arrows in the diagram match the numbered lines in the step panel.

API request (HTTPS) API response Watch event (pushed down an open stream) etcd write (gRPC) Local, inside the node Network packet
Not involved in traffic
Outside the cluster
kubectlyour laptop or CI
Command-line client. Sends requests to the API server over HTTPS. It is not part of the cluster.
Control plane: not involved in traffic.
It only stores and serves records.
Control plane
Decides and records. Holds the desired state of the cluster. Never carries your application's traffic.
kube-apiservercontrol plane
The only door into the cluster. Checks every request, reads and writes etcd, and streams changes to everyone watching.
etcdcontrol plane database
Key-value store holding every object. Only the API server talks to it. A Service or an EndpointSlice is just a record here.
EndpointSlice controllerinside kube-controller-manager
A loop that watches Services and Pods through the API server, and keeps an EndpointSlice listing each Service's ready Pods.
Worker node
Does the work. Runs the Pods and moves the packets. Every node in the cluster runs the same agents.
kubelet + CNI pluginnode agent
kubelet starts this node's Pods through the container runtime and reports their status. The CNI plugin gives each Pod an IP.
kube-proxynode agent
Watches Services and EndpointSlices, and turns them into kernel NAT rules. It writes rules; it never touches packets.
frontend Poda client of the Service
An application Pod that calls backend-svc.
Linux kernelnetfilter + conntrack
Where packets are actually rewritten, using the rules kube-proxy loaded (iptables or nftables).
Pod Abackend
Pod Bbackend