Labels, Selectors, and Namespaces¶
Overview¶
Use labels/selectors to group objects, separate workloads with namespaces, and understand ReplicaSets as the replication layer under Deployments.
Labels are queryable key/value metadata. Selectors bind Services and controllers to Pods. Namespaces partition names and often tenancy. Annotations hold non-identifying metadata (tooling, checksums).
This is a core tutorial in Module 3 · Kubernetes Objects of the REBASH Academy Kubernetes for Cloud & DevOps Engineers series — written for Cloud, DevOps, Platform, and SRE engineers.
Prerequisites¶
Learning Objectives¶
By the end of this tutorial, you will be able to:
- Apply and query labels
- Explain selector matching
- Create and use a namespace
- Relate ReplicaSet to Deployment
Architecture¶
This topic’s control points and relationships are shown below.
Theory¶
What it is¶
Kubernetes objects carry metadata. Labels are identifying key/value pairs you can query (app=api, tier=frontend). Selectors match those labels so Services and controllers know which Pods belong together. Namespaces partition names inside a cluster (soft multi-tenancy). Annotations hold non-identifying metadata for tools (checksums, build IDs). A ReplicaSet keeps a stable set of Pod replicas; Deployments own ReplicaSets for rolling updates.
Why it matters¶
Without consistent labels, Services point at nothing, NetworkPolicies cannot target apps, and kubectl get -l is useless. Namespaces keep team A from colliding with team B on object names and are the usual boundary for quotas and RBAC. Understanding ReplicaSets explains why deleting a Pod under a Deployment does not permanently shrink the app.
How it works (mental model)¶
- Controllers and Services declare
selector.matchLabels(or set-based selectors). - The API indexes Pods by labels; matching Pods become endpoints / managed replicas.
- Namespaces scope most namespaced resources;
default,kube-system, and custom app namespaces are typical. - Deployment creates a ReplicaSet with a pod template hash; scaling changes the ReplicaSet’s desired count; the ReplicaSet creates or deletes Pods.
Labels identify; annotations annotate. Do not put large config in labels — use ConfigMaps.
Key concepts / comparisons¶
| Mechanism | Purpose |
|---|---|
| Label | Queryable identity for grouping |
| Selector | Match labels (equality or set-based) |
| Annotation | Opaque metadata for tooling |
| Namespace | Name and policy boundary |
| ReplicaSet | Maintain N identical Pods |
| Equality selector | Set-based selector |
|---|---|
app=api | environment in (prod, staging) |
Common pitfalls¶
- Changing Deployment selector labels after creation — selectors are mostly immutable.
- Using spaces or upper-case inconsistently in label values; prefer simple DNS-safe keys.
- Putting secrets in annotations or labels — they are visible to many readers.
- Operating without
-nand wondering why “nothing exists”. - Treating namespaces as hard security isolation — you still need RBAC, NetworkPolicy, and quotas.
Hands-on Lab¶
Create a workspace for this tutorial.
Focus: Organise objects with namespaces, labels, and selectors
Step 1 – Create labelled resources¶
kubectl create namespace rebash-lab
kubectl -n rebash-lab run api --image=nginx:1.27-alpine --labels=tier=frontend,env=lab
kubectl -n rebash-lab run worker --image=busybox:1.36 --labels=tier=backend,env=lab --command -- sleep 3600
kubectl -n rebash-lab label pod api owner=rebash --overwrite
kubectl -n rebash-lab get pods --show-labels
Step 2 – Query with selectors and namespace scope¶
kubectl -n rebash-lab get pods -l tier=frontend
kubectl -n rebash-lab get pods -l 'env in (lab),tier!=frontend'
kubectl get ns rebash-lab -o yaml | head -n 20
kubectl -n rebash-lab get all
Final step – Cleanup note¶
kubectl delete namespace rebash-lab --ignore-not-found
# Workspace kept for notes; remove with: rm -rf "$(pwd)" when finished
Validation¶
- Lab commands run under
~/rebash-k8s/module-03-labels/ - You can explain each Theory section in your own words
- You used modern tooling where it applies to this topic
- You can describe one production failure mode for this topic
Code Walkthrough¶
Production practice for Labels, Selectors, and Namespaces always combines:
- Inspect before you change (status, plan, logs, dry-run)
- Prefer reversible, documented changes (Git, IaC, drop-ins, version pins)
- Capture evidence (command output, pipeline logs) for handovers
- Prefer current tools and APIs over legacy shortcuts
- Least privilege — escalate credentials only when required
Keep runbooks short enough to follow under pressure. Automate checks; keep humans for judgement.
Security Considerations¶
- Treat credentials and tokens for kubernetes as privileged — never commit them
- Prefer short-lived auth (OIDC, roles, SSO) over long-lived keys
- Validate blast radius before apply/deploy/delete operations
- Restrict who can approve production changes
- Collect audit logs; limit who can read sensitive traces
Common Mistakes¶
Changing Deployment selector labels after creation — selectors are mostly immutable.
Validate assumptions against the Theory section and official docs before changing production.
Using spaces or upper-case inconsistently in label values; prefer simple DNS-safe keys.
Lab shortcuts (open security groups, admin roles, skip approvals) must not ship unchanged.
Changing production without a rollback path
Always know how to revert (previous artefact, prior release, state rollback, DNS failback).
Best Practices¶
- Encode Labels, Selectors, and Namespaces changes as code and review them in pull requests
- Pin versions (images, modules, actions, provider plugins)
- Separate environments with clear promotion gates
- Alert on symptoms with runbooks attached
- Destroy lab resources; tag everything with owner and expiry where possible
Troubleshooting¶
| Symptom | Likely cause | Fix |
|---|---|---|
| Auth / permission denied | Wrong identity, policy, or scope | Check caller identity, roles, and least-privilege policies |
| Timeout / no route | Network, DNS, security group, or endpoint | Trace path, DNS, and allow-lists before retrying |
| Drift / unexpected plan | Manual change or wrong state/workspace | Reconcile desired vs actual; avoid click-ops on managed resources |
| Pipeline/job red | Flaky step, cache, or missing secret | Read failing step logs; bisect recent workflow/config changes |
| Cost spike | Idle load balancer, NAT, oversized compute | Inventory billable resources; stop/delete labs promptly |
Summary¶
Labels, Selectors, and Namespaces is essential for Cloud and DevOps engineers working with kubernetes. Practise the lab until the inspection and change path is muscle memory, then continue the track.
Interview Questions¶
- What is a Kubernetes namespace used for?
- How do labels differ from annotations?
- How do selectors use labels to group Pods for Services and Deployments?
- What security benefit do namespaces provide, and what do they not isolate by themselves?
- Give an example of a useful label taxonomy for multi-team clusters.
Sample answer — question 2
Labels are identifying metadata for selection; annotations hold non-identifying tool or descriptive data. Controllers and Services select on labels, not annotations.
Sample answer — question 4
Namespaces scope names and RBAC subjects, but they do not provide network or node isolation alone. Combine with NetworkPolicy, quotas, and Pod security controls for stronger tenancy.