Orchestration Core
Services & label selectors
Lesson 2 of 5
What you'll learn
- Know why Pods need a stable abstraction in front of them
- Distinguish ClusterIP, NodePort, and LoadBalancer service types
- Understand how label selectors — not names or IPs — bind a Service to its Pods
Pods are ephemeral: they come and go, each with a new IP. A Service gives you one stable virtual IP and DNS name in front of a continuously changing set of Pods. The key insight: a Service never references Pods by name or IP. It declares a selector, and any Pod whose labels match is a backend.
apiVersion: v1
kind: Service
metadata:
name: api
spec:
type: ClusterIP
selector:
app: api
tier: backend
ports:
- port: 80
targetPort: 8080
Service types
- ClusterIP (default): reachable only inside the cluster. The backbone of internal service-to-service traffic.
- NodePort: opens a static port on every node — usually a building block, not an endpoint you expose directly.
- LoadBalancer: provisions an external load balancer via your cloud provider, the typical way to expose a public service.
kubectl get endpoints api # the live set of Pod IPs the selector resolved to
Selectors are set membership
A selector is an AND across label key/value pairs. A Pod matches only if it carries every label in the selector; extra labels on the Pod are fine. This is why relabeling a Pod silently adds or removes it from a Service's pool — a powerful and occasionally surprising property.
Endpoints reveal the truth
If traffic isn't reaching a Pod, check kubectl get endpoints. An empty list almost always means the selector and the Pod labels disagree.
Run it. The matcher returns which Pods a Service targets: every selector label must be present and equal on the Pod.
How does a Service decide which Pods are its backends?
Saved on this device. Sign in to sync your progress everywhere.