Kubernetes Service: A Stable Address for Ephemeral Pods

Why it exists

Pods in Kubernetes are ephemeral; they can be created, destroyed, and rescheduled at any moment, each time getting a new IP address. Relying on direct Pod IPs for communication is brittle and destined to fail. A Service solves this by providing a stable abstraction layer.

The mental model

A Kubernetes Service is like a company's main phone number. You don't call individual employees (Pods) directly because they might be at a different desk, on vacation, or have left the company (restarted with a new IP). Instead, you call the stable main number (the Service), and a receptionist (kube-proxy) automatically routes your call to an available employee in the correct department (a healthy Pod matching the label selector).

How it works

You define a Service in a YAML file, specifying a 'selector' that targets a set of Pods based on their labels (e.g., 'app: my-api'). Kubernetes assigns a persistent virtual IP address, called the ClusterIP, to this Service. On every node in the cluster, a process called kube-proxy watches for these Services. When traffic is sent to a Service's ClusterIP, kube-proxy intercepts it and forwards it to the real IP address of one of the healthy backend Pods. This forwarding is a form of load balancing. The most common Service types are ClusterIP (internal only), NodePort (exposes on each node's IP), and LoadBalancer (uses a cloud provider's external load balancer).

When to use it

Use a Service whenever you need a stable endpoint for a set of replica Pods, such as for a backend API, a database, or a web frontend. It is the standard way to enable service discovery and load balancing within a Kubernetes cluster. Use the LoadBalancer or NodePort types to expose your application to external traffic.

When not to use it

Avoid using a Service for workloads that don't need a stable network endpoint, like one-off batch jobs. For complex HTTP routing based on hostnames or URL paths (e.g., api.example.com/users vs api.example.com/orders), an Ingress controller is the correct tool. An Ingress manages L7 traffic and routes it to different backend Services, which handle L4 distribution to Pods.

One canonical example

A Deployment is running three replicas of a stateless web server, all labeled with 'app: web-frontend'. You create a Service of type ClusterIP with a selector for 'app: web-frontend'. Now, any other Pod in the cluster can reliably send requests to the web servers by using the Service's DNS name (e.g., 'web-frontend-svc'), without ever knowing the individual, changing IPs of the three server Pods.