A Service gives a stable address to a changing set of pods. Its type decides how that address is reachable: only inside the cluster, on every node’s port, through a cloud load balancer, or as direct pod endpoints.
Before you start
You should be comfortable with pods and selectors. This article covers the four common Service types.
Step-by-step walkthrough
Step 1: ClusterIP is the internal default
A ClusterIP Service gets a virtual IP reachable only inside the cluster, and kube-proxy load-balances to the selected pods. It is what most services use for service-to-service calls, and it needs no external address.
Step 2: NodePort and LoadBalancer expose it externally
NodePort opens a port on every node that forwards to the Service, which is useful in clusters without a cloud integration. LoadBalancer provisions a cloud load balancer with an external IP that forwards to the Service, which is the usual production path but costs one load balancer per Service.
Step 3: Use headless for direct pod addressing
A Service with clusterIP: None is headless: DNS returns the pod IPs directly instead of a virtual IP, so clients can address individual pods. StatefulSets use this so each replica has a stable DNS name.
Worked scenario
The Service exposes port 80 to pods on 8080 inside the cluster.
apiVersion: v1
kind: Service
metadata:
name: api
spec:
type: ClusterIP
selector:
app: api
ports:
- port: 80
targetPort: 8080Walk through the example
Clients inside the cluster reach api:80, and the Service forwards to port 8080 on pods labeled app: api. Changing the pod set does not change the address, which decouples callers from pod churn. Switching type to LoadBalancer would additionally provision an external IP.
Common mistake
Creating a LoadBalancer for every internal service, which multiplies cloud load balancers and cost; use one ingress or gateway in front instead. Another is using NodePort in production and then hitting firewall and port-range issues.
Verify the behavior
Confirm a ClusterIP Service is reachable only from inside by resolving it from a pod. Check that a LoadBalancer Service receives an external IP. For a headless Service, resolve the name and confirm it returns pod IPs.
Interview exercise
When do you need a headless Service?
Answer and reasoning
When clients must address individual pods rather than a load-balanced virtual IP, such as a database cluster where each replica has a role, or a StatefulSet whose members discover each other by stable names. A headless Service returns pod IPs directly through DNS, which the pods then use to connect to specific peers.
Continue learning
Compare selectors in Service selectors and routing in Ingress routing. Read the Kubernetes Service documentation and try the Kubernetes interview questions.