You can choose from nodeSelector or node affinity.
nodeSelector provides a very simple way to constrain pods to nodes with particular labels. The affinity/anti-affinity feature, greatly expands the types of constraints you can express. The key enhancements are
- the language is more expressive (not just “AND or exact match”)
- you can indicate that the rule is “soft”/“preference” rather than a hard requirement, so if the scheduler can’t satisfy it, the pod will still be scheduled
- you can constrain against labels on other pods running on the node (or other topological domain), rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located
The affinity feature consists of two types of affinity, “node affinity” and “inter-pod affinity/anti-affinity”. Node affinity is like the existing
nodeSelector (but with the first two benefits listed above), while inter-pod affinity/anti-affinity constrains against pod labels rather than node labels, as described in the third item listed above, in addition to having the first and second properties listed above
node affinity is similar to
nodeSelector but it allows you to limit which nodes your pod can be scheduled on, based on labels on the node.
You can also look at taints and tolerations
You add a taint to a node using kubectl taint. For example,
kubectl taint nodes node1 key=value:NoSchedule
places a taint on node
node1. The taint has key
value, and taint effect
NoSchedule. This means that no pod will be able to schedule onto
node1 unless it has a matching toleration.
There is no point of quoting or rewriting the docs in the answer. I really do recommend you go over those and choose the one that better fits your example.