18 Kubernetes Services and Discovery
Kubernetes Services and Discovery enables consistent communication between containers through abstracted network endpoints and automated service discovery mechanisms.
Kubernetes Services and Discovery is the layer of Kubernetes networking that provides stable, discoverable endpoints for groups of Pods whose individual IP addresses are inherently ephemeral, allowing applications to communicate reliably with one another without needing to track which specific Pods are currently running.
The Problem of Ephemeral Pods
Pods Are Not Stable Endpoints
Pods are created and destroyed constantly as part of normal operation, whether through rolling updates, scaling, or failure recovery, and each replacement Pod typically receives a new IP address, making direct Pod-to-Pod addressing unreliable for anything beyond transient use.
A Stable Abstraction Layer
A Service solves this by providing a stable virtual IP address and DNS name that remains constant regardless of which Pods are currently backing it, decoupling clients from the specific, ever-changing set of Pod IPs.
How a Service Works
Label Selectors
A Service uses a label selector to determine its current set of backing Pods, continuously reevaluating this selector against the cluster so its membership updates automatically as matching Pods are created or destroyed.
Endpoints
The set of Pod IPs currently matching a Service's selector is tracked in an associated Endpoints or EndpointSlice object, which is kept up to date by a controller and used by kube-proxy to implement traffic routing.
Service Types
ClusterIP
ClusterIP, the default Service type, exposes the Service on an internal virtual IP address reachable only from within the cluster, suitable for communication between internal components.
NodePort
NodePort exposes the Service on a static port on every node's IP address, allowing external traffic to reach the Service by connecting to any node on that port, which is often used in simpler or on-premises setups.
LoadBalancer
LoadBalancer provisions an external load balancer, typically through integration with a cloud provider, that routes external traffic to the Service, building on top of NodePort and ClusterIP functionality.
Headless Services
A headless Service, created by explicitly omitting a cluster IP, does not load balance traffic itself but instead returns the individual IP addresses of all matching Pods directly through DNS, which is used when clients need to address specific Pods rather than an undifferentiated pool.
DNS-Based Discovery
Cluster DNS
Kubernetes runs an internal DNS service that automatically creates DNS records for every Service, allowing applications to reach a Service using a predictable hostname rather than needing to know its virtual IP address in advance.
Fully Qualified Names
A Service's DNS name typically includes its name and namespace, allowing Pods in one namespace to reach a Service in another namespace using its fully qualified name, while same-namespace communication can use the shorter, unqualified name.
Ingress and External Access
Beyond Basic Service Exposure
While Services handle basic traffic routing, Ingress resources provide a higher-level abstraction for exposing HTTP and HTTPS routes from outside the cluster, supporting host and path-based routing rules and centralized TLS termination across multiple Services.