Kubernetes Services 101: From Creation to Traffic Flow
Enable kube‑proxy to use nftables for faster packet routing by setting `--proxy-mode=nftables` in kube‑proxy config.
Check kube‑proxy flags and switch to nftables mode if available to improve Service routing performance.
Summary
The article walks through the full lifecycle of a Kubernetes Service, from creation with `kubectl expose` to traffic routing. It explains that the API server allocates a ClusterIP, the EndpointSlice controller populates slices with pod IPs, kube‑proxy updates iptables (or nftables) to forward traffic, and CoreDNS resolves the service name to the ClusterIP. Five service types are covered: ClusterIP, NodePort, LoadBalancer, ExternalName, and Headless. The packet flow involves DNS resolution, PREROUTING, matching KUBE‑SERVICES chain, random backend selection, DNAT to pod IP, and source IP rewriting on reply. The article also notes that the Service object is metadata and the kernel does the actual packet forwarding.
Key changes
- API server allocates ClusterIP from --service-cluster-ip-range
- EndpointSlice controller populates slices with pod IPs and ports
- kube‑proxy updates iptables (or nftables) to forward traffic
- CoreDNS resolves service name to ClusterIP
- Five service types: ClusterIP, NodePort, LoadBalancer, ExternalName, Headless
- Packet flow: DNS → KUBE‑SERVICES → random backend → DNAT to pod IP
- Service object is metadata; kernel does packet forwarding
- IPVS mode deprecated; nftables recommended for modern clusters