Two Pods were easy to keep straight. The Monster Market will soon have dozens, next to other teams' things, in environments with the same names. Kubernetes gives you two tools for that: one that separates, one that groups.

Namespaces: rooms in the house

A NamespaceNamespaceA named partition of the cluster. Most objects live in exactly one. is a named partition of the cluster. Names only need to be unique inside their namespace, so web in shop and web in shop-staging can coexist. Permissions and quotas are usually attached per namespace too.

kubectl create ns shop
kubectl get namespaces

Most commands look at exactly one namespace: default, unless you say otherwise.

kubectl get pods -n shop
kubectl get pods -A

-n picks a namespace; -A (short for --all-namespaces) looks everywhere. When a Pod "disappears", nine times out of ten you are looking in the wrong room.

Labels: sticky notes with structure

A label is a key=value pair in an object's metadata.labels. Labels do not change what the object does. They exist so that other things can find it.

kubectl label pod web app=web tier=frontend
kubectl get pods --show-labels

Common keys by convention: app, tier, env, team, version. Pick a scheme and stick to it; a cluster's labels are its index.

To change an existing label you need --overwrite; to remove one, suffix the key with a minus:

kubectl label pod web tier=backend --overwrite
kubectl label pod web tier-

Selectors: asking by label

A selector is a question written in labels. -l answers it:

kubectl get pods -l tier=backend
kubectl get pods -l app=web,tier=frontend
kubectl get pods -l 'tier!=frontend' -A

Comma means AND. Selectors are not just a filter for your eyes: in the next nodes you will meet objects that select Pods to manage or send traffic to. If the labels are wrong, those objects quietly match nothing.

namespace shop
  ├─ web   app=web  tier=frontend  ◀── -l tier=frontend
  ├─ api   app=api  tier=backend   ◀┐
  └─ db    app=db   tier=backend   ◀┴─ -l tier=backend