Full lesson
Explore the full explanation, examples, and visuals at your own pace.
selector app=web
A Service finds its Pods by matching labels. Here, web-svc has the selector app equals web. web-1 and web-2 carry that label, so they receive traffic. api-1 is labeled app equals api, so the Service ignores it completely.
web-1 Pod and web-svc Service
The Pod carries a label, app equals web, set in its own manifest. The Service's selector asks for exactly that key and value, so spelling and case matter. Separately, port 80 on the Service forwards to port 8080 inside the container.
# Pod (labels set in its manifest)
metadata:
name: web-1
labels:
app: web
---
apiVersion: v1
kind: Service
metadata:
name: web-svc
spec:
selector:
app: web
ports:
- port: 80
targetPort: 8080Selector builds the endpoint list
Kubernetes watches Pods and compares their labels to the selector app equals web. Matching, Ready Pod IPs go into the EndpointSlice. Then kube-proxy sends traffic for port 80 to those IPs, here web-1 and web-2. A matching Pod that isn't Ready is left out.
New Pod web-3 joins automatically
Deploy web-3 with the label app equals web, and once it's Ready, its IP shows up in the EndpointSlice. You never touched web-svc. A Service isn't a fixed list of Pods. It's a live label query, and matching Pods get traffic.
A new Pod starts with label app web and becomes Ready. What does web-svc do with it?
A new Pod starts with label app web and becomes Ready. What does web-svc do with it?
- Adds it to endpoints and sends it traffic
- Ignores it until the Service is restarted
- Uses it only if web-1 created it
A new Pod starts with label app web and becomes Ready. What does web-svc do with it?
Adds it to endpoints and sends it traffic. The Service keeps re-evaluating its selector against current Pod labels. Any Ready Pod whose labels match is added to the endpoints automatically. Nothing needs restarting, and the Service does not care which Deployment or Pod created it.
- Adds it to endpoints and sends it traffic
- Ignores it until the Service is restarted
- Uses it only if web-1 created it
web-3 deployed with a typo
Now web-3 ships, but its label says w-b-e instead of web. The selector still asks for app equals web, so it doesn't match. Describe shows only the two original endpoints. The Pod itself runs happily. It just never receives traffic.
# web-3 manifest
metadata:
name: web-3
labels:
app: wbe # typo
$ kubectl describe svc web-svc
Selector: app=web
Endpoints: 10.1.0.11:8080,10.1.0.12:8080Two typos, two very different symptoms
Both typos are small, but they fail differently. A wrong Pod label drops one Pod, so web-svc keeps serving through web-1 and web-2 with less capacity. A wrong selector matches nothing, so endpoints are empty and every request fails. Neither throws a deploy error.
Debug: compare labels to the selector
Run kubectl get pods with show-labels and compare each label to the Service selector, app equals web. Web-3 says app equals wbe. Fix that in the manifest or Deployment template, reapply, then check that the endpoints grow to three.
$ kubectl get pods --show-labels
NAME READY STATUS LABELS
web-1 1/1 Running app=web
web-2 1/1 Running app=web
web-3 1/1 Running app=wbe
# fix the label in the source manifest, then reapplyNo match, no traffic
A Service is a live label query. Pods that match the selector and are Ready get traffic, and everything else is ignored. When requests go missing, check the endpoints first, then compare Pod labels to the selector.