Services
A Service provides a stable virtual IP (ClusterIP) and DNS name for a set of pods selected by a label selector. It load-balances traffic across matching pods.
Service = a restaurant's phone number that never changes, even when chefs (pods) quit and new ones are hired. ClusterIP = the internal kitchen extension. NodePort = a side door. LoadBalancer = the valet entrance. The phone number (DNS) always works.
Service types: ClusterIP (internal-only VIP, default), NodePort (exposes on a port on every node, 30000-32767), LoadBalancer (provisions a cloud load balancer, builds on NodePort+ClusterIP), ExternalName (CNAME alias for an external hostname). DNS: service-name.namespace.svc.cluster.local. Endpoints (or EndpointSlices in modern K8s) are the list of pod IPs backing a service — updated by the endpoint controller as pods come and go.
kube-proxy watches Endpoints and programs iptables DNAT rules: traffic to ClusterIP:port gets DNAT'd to one of the pod IPs. In IPVS mode, uses Linux IP Virtual Server for O(1) routing vs O(n) iptables. Service without selector: you manage Endpoints manually — useful for external databases or cross-namespace routing. Headless service (clusterIP: None): DNS returns pod IPs directly, no VIP, no kube-proxy routing. Used with StatefulSets. Session affinity: sessionAffinity: ClientIP makes the same client IP always hit the same pod (5-minute sticky session). Topology-aware routing: prefer local zone pods for latency reduction.
Services give pods a stable identity. Pods are ephemeral with changing IPs — Services are stable. ClusterIP for internal service-to-service. NodePort/LoadBalancer for external traffic. The service selector uses labels — any pod with matching labels becomes an endpoint. The kube-proxy on each node programs iptables rules so traffic to the ClusterIP gets load-balanced to pod IPs. Services are the DNS record + stable VIP layer on top of ephemeral pods.
A Service doesn't automatically wait for pods to be ready. If a pod is in the Endpoints list but its readiness probe is failing, traffic still won't reach it — but only if you've defined a readiness probe. Without readiness probes, traffic goes to pods immediately on start, before they're ready.