Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?




In Kubernetes, any object can be identified using a label.

You can assign multiple labels per object, but you should avoid using too many labels, or too few; too many will get you confused and too few won’t give the real benefits of grouping, selecting, and searching.

Best practice is to assign labels to indicate:

  • Application/program ID using this pod

  • Owner (who manages this pod/application)

  • Stage (the pod/application in development/testing/production version)

  • Resource requirements (SSD, CPU, storage)

  • Location (preferred location/zone/data center to run this pod/application)

Okay, let’s assign labels for (stage: testing) and (zone: production) to two nodes, respectively, then try to launch a pod in a node that has the label (stage: testing):

Now let’s launch a basic Nginx pod tagged with stage: testing in the nodeSelector and confirm it will land on a node tagged with stage: testing. Kube-scheduler uses labels mentioned in the nodeSelector section of the pod YAML to select the node to launch the pod:


Kube-scheduler picks the node based on various factors like individual and collective resource requirements, hardware, software, or policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines.


You can assign a pod to a certain node without labels by adding the argument nodeName: nodeX under the spec in the YAML file where nodeX is the name of the node.