A label is a key=value attribute on a Kubernetes object. Labels identify objects for queries and selection; a label on a node does not change how that node operates. Nodes have default labels, and pods can have labels too. Inspect them with `kubectl get no --show-labels` or `kubectl get po -n kube-system --show-labels`. section 2.1.3
Schedule a pod using a node label
Run `kubectl label no kind-worker disktype=ssd`, then confirm the label with `kubectl get no --show-labels`. In the pod manifest, set `nodeSelector` to `disktype: ssd`. After creating the pod, run `kubectl get po -o wide` and check the NODE column. Unlike `nodeName`, a node selector can match a label applied to multiple nodes; a toleration alone does not select a node. section 4.1 section 4.1.1
Labels also matter when troubleshooting traffic to pods. If a Service cannot reach an application, inspect its selector with `kubectl get svc -o yaml` and compare it with `kubectl get po --show-labels`. Check the Service and application ports as well: a selector is not the only possible cause of failed connectivity. section 8.3.2
root@kind-control-plane:/# kubectl get po --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-6cdcf8f964-hdwzr 1/1 Running 0 20m app=nginx,pod- template-hash=6cdcf8f964
The pod listing displays `app=nginx` alongside another pod label, giving you values to compare with a Service selector. section 8.3.2
For scheduling practice, apply a node label, use it in a pod's node selector, and verify the assigned node. For Service troubleshooting, compare selector values with pod labels before changing either resource. section 4.1 section 8.3.2
