Skip to main content
Brief recap: Pods are the smallest deployable units in Kubernetes and host your application containers. Pods are ephemeral — they can be created and terminated to match the desired cluster state. Because Pod IPs can change, we need a stable way for components (for example, a frontend and a backend) to discover and communicate with each other. Kubernetes Services provide that stable network identity. A Service exposes an IP and DNS name plus a routing policy that forwards traffic to one or more matching Pods. Instead of relying on individual Pod IPs, other components use the Service to reach the application instances. When you create a back-end Service, you typically configure a selector that matches labels on backend Pods. The Service then routes traffic to those Pods, maintaining a stable access point even as Pods are recreated.
A diagram of a Kubernetes cluster showing Backend and Frontend deployments with individual pods and IPs. A Backend Service (ClusterIP 10.96.0.12) is shown routing traffic to the backend pods.
Services match Pods using labels and selectors. Add labels to Pods (or their owning controllers like Deployments), and configure the Service selector to match those labels so the Service knows which endpoints receive traffic.

How Services select Pods

Services select Pods with label selectors. You typically label your Deployment (or Pod template) and then reference the same label set in the Service spec. This decouples service discovery from Pod lifecycle — traffic flows to whatever Pods currently match the selector. Example concepts:
  • Label on Pod/Deployment: app: backend
  • Service selector: app: backend
  • Service routes to all Pods whose labels match the selector

Common Service types

There are three common Service types you’ll encounter in Kubernetes:
A slide titled "Kubernetes Services" showing three illustrated service types: NodePort, ClusterIP, and LoadBalancer. Each box depicts a rectangular pod/service with blue dots indicating how traffic connects to the service (single external node for NodePort, internal access for ClusterIP, and multiple external points for LoadBalancer).
Be careful when exposing Services externally. NodePort and LoadBalancer make your application reachable outside the cluster — ensure proper authentication, network policies, and firewall rules are in place.

Example: labels + Service YAML

Below is a minimal example demonstrating a Deployment with labels and a ClusterIP Service that selects those Pods. Deployment (snippet):
ClusterIP Service (snippet):
Commands to inspect Services and endpoints:
  • kubectl get svc — list Services
  • kubectl describe svc backend-service — view Service details
  • kubectl get endpoints backend-service — view which Pod IPs the Service routes to

Further reading and references

That’s a concise overview of Kubernetes Services and how they provide stable network identities and routing to Pods.

Watch Video