📖 Read-only preview — lessons, diagrams, and quizzes only. The hands-on labs, live grading, and progress tracking require running the real course locally against a Kubernetes cluster.Run it locally →

Module 2 · Lesson 2.2

Labels and Selectors

Labels: arbitrary key-value tags

A label is a key-value pair attached to any object — app: web, env: prod, tier: backend. Labels carry no built-in meaning to Kubernetes; they're just metadata you define. What makes them powerful is that almost every controller in the cluster — Services, Deployments, NetworkPolicies — finds which objects it's responsible for by querying labels, not by name or by owning a direct reference.

Selectors: how objects find each other

A label selector is a query over labels: app=web, or app=web,tier=frontend (AND semantics when comma-separated). A Service doesn't know your pods by name — it watches for any pod matching its selector and routes traffic to it. A Deployment's ReplicaSet does the same to know which pods it owns.

Selectors query labels, live

web-1
app=webtier=frontendenv=prod
web-2
app=webtier=frontendenv=prod
web-3
app=webtier=frontendenv=staging
web-canary
app=webtier=frontendenv=prodtrack=canary
db-1
app=dbtier=backendenv=prod
cache-1
app=cachetier=backendenv=prod
kubectl get pods -l app=web would return 4 of 6 pods.

This indirection is the single most common source of "it's just not working" bugs in real clusters: a Service with a selector that doesn't quite match any pod's labels (a typo, a missing label) results in a Service with zero endpoints — no error, no crash, just silent nothing. You fixed exactly this kind of mismatch in the lab for this lesson.

Diagnosing a crashing pod

You also hit CrashLoopBackOff in this lab — one of the most common states you'll see in real clusters. It means: the container starts, exits (crashes, or just finishes and nothing keeps it running), and Kubernetes keeps restarting it with increasing backoff delay. The fix always starts the same way:

  1. kubectl describe pod <name> — look at Last State, its Exit Code, and the Events at the bottom.
  2. kubectl logs <name> --previous — the crashed container's own output, often the real reason, before it disappears for good.

An exit code of 0 usually means "the process finished on purpose," which is a problem if that process was supposed to run forever (a web server, not a batch job). Nonzero exit codes point at an actual error — check the logs.

The infrastructure analogy

Think of labels as tags in a cloud provider's resource tagging system, and selectors as the filter you'd use in a dashboard or an Ansible inventory group — except here, the "dashboard" is live and continuously re-evaluated by controllers, not something a human refreshes.

🧪 Lab: lab-04-labels-and-selectors

Preview only

Goal

Use label selectors the way Kubernetes itself does internally, and fix two realistic problems: a crashing pod, and a pod that's "invisible" to a selector because of a missing label.

Tasks

  1. Apply the starting manifests: kubectl apply -f manifests/
  2. List everything with the app=api label: kubectl get pods -n lab-04-labels-and-selectors -l app=api --show-labels
  3. Now list with both labels: -l app=api,tier=backend. One pod from step 2 is missing from this list — that's your first bug. Add the missing label directly on the live object: kubectl label pod <name> -n lab-04-labels-and-selectors tier=backend
  4. Check pod status: kubectl get pods -n lab-04-labels-and-selectors. One pod is in CrashLoopBackOff. Investigate with: kubectl describe pod <name> -n lab-04-labels-and-selectors (check the "Last State" and "Reason") and kubectl logs <name> -n lab-04-labels-and-selectors --previous.
  5. The container's command exits immediately on purpose (see the comment in manifests/pods.yaml). Fix it: edit manifests/pods.yaml so that pod's command keeps it running like its siblings, then kubectl apply -f manifests/pods.yaml again.
  6. Confirm: kubectl get pods -n lab-04-labels-and-selectors -l app=api,tier=backend should now list all three pods, all Running.

Check

Run the check once all three api-* pods are Running and all carry both app=api and tier=backend.

This lab runs against a real local Kubernetes cluster with an automated grader — clone the repo and run make start to do it for real.

📝 Quiz

1. How does a Service decide which pods to send traffic to?

2. A Service's selector is `app=web`, but every pod you created has the label `app: webapp` (slightly different). What's the symptom?scenario

3. A pod shows `CrashLoopBackOff`. What's the right first command?

4. `kubectl describe pod` shows exit code 0 on a pod that's supposed to be a long-running web server, and it's in CrashLoopBackOff. What does exit code 0 tell you?scenario

5. Which of these are true about label selectors? (select all that apply)

Progress isn't saved in this preview — run the course locally to track completion and grade labs for real.