Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsUse node affinity to attract or require a Pod on nodes with matching labels; use taints and tolerations to repel Pods from nodes unless they are permitted past the taint. A toleration is not a placement instruction. If you need to reserve a node group for selected workloads, combine a taint with a node label and required node affinity.
What each mechanism does
Node affinity selects from the Pod side
Node affinity is a rule on the Pod that matches node labels. With a required rule, the Pod cannot schedule unless a node matches. With a preferred rule, the scheduler favors matching nodes but may choose another eligible node. The official Kubernetes guide, Assigning Pods to Nodes, describes these options and the simpler nodeSelector alternative.
As an Amazon Associate I earn from qualifying purchases.
nodeSelector is suitable for straightforward label matching; node affinity supports more expressive required and preferred rules. If a Pod specifies both nodeSelector and node affinity, it must satisfy both.
Taints repel from the node side
A taint is applied to a node. A Pod that lacks a matching toleration can be blocked or discouraged from scheduling there, depending on the taint effect. A toleration lets the Pod pass that taint filter; it does not tell the scheduler to choose that node. The scheduler still evaluates the Pod’s other constraints and the node’s available resources. Kubernetes explains the matching and filtering behavior in Taints and Tolerations.
#1 Best Overall
Choose based on the placement outcome you need
| Need | Use | What it does |
|---|---|---|
| The Pod must run on nodes with a required property, such as a hardware or zone label | Required node affinity | Prevents scheduling unless a node matches. |
| The Pod should prefer a node group but may run elsewhere | Preferred node affinity | Influences node selection without making the preference mandatory. |
| Keep ordinary workloads away from a node group | A taint on those nodes | Blocks or discourages Pods without matching tolerations, according to the effect. |
| Permit selected workloads past a taint | A matching toleration on those Pods | Removes the matching taint as a barrier; it does not select the node. |
| Reserve nodes for a workload group | Taint plus label and required node affinity | Repels unrelated Pods and constrains intended Pods to the labeled node group. |
| Evict running workloads that do not tolerate a node condition | NoExecute taint |
Affects existing as well as new Pods; toleration settings determine whether and how long a Pod remains. |
Understand the scheduling and eviction effects
Affinity: required versus preferred
requiredDuringSchedulingIgnoredDuringExecutionis a hard scheduling requirement: if no eligible node has matching labels, the Pod cannot be scheduled.preferredDuringSchedulingIgnoredDuringExecutionis a preference: the scheduler tries to favor matching nodes but can choose another eligible node.IgnoredDuringExecutionmeans a later change to a node’s labels does not, by itself, evict a Pod that has already been scheduled there.
Taints: NoSchedule, PreferNoSchedule, and NoExecute
NoScheduleblocks new Pods that lack a matching toleration. It does not evict Pods already running on the node.PreferNoScheduleasks the scheduler to avoid placing non-tolerating Pods on the node when possible; it is a soft preference, not a guarantee.NoExecuteaffects both new and running Pods. A Pod without a matching toleration is not admitted and a running Pod can be evicted. A matching toleration withtolerationSecondscan delay eviction for the configured interval.
When a node has multiple taints, tolerations are considered against them as filters. Matching tolerations remove the corresponding taints from consideration; any remaining taint can still affect scheduling or eviction according to its effect. The Kubernetes API reference, Toleration v1, documents toleration fields and effects.
Reserve a node group for selected workloads
Neither half of the policy is enough by itself when the goal is to dedicate nodes. A taint repels workloads without the right toleration, but tolerating it does not direct the intended workload to those nodes. Required affinity selects the labeled nodes, but by itself does not repel unrelated Pods that have other ways to qualify for them.
- Label the intended nodes with a key and value that identify the group.
- Taint those nodes so workloads without the specific matching toleration are blocked or discouraged, using the effect that fits your policy.
- Add the matching toleration only to the intended workloads so they can pass that taint.
- Add required node affinity to those workloads using the node label, so they are constrained to the intended group.
This combines exclusion (the taint) with selection (the affinity), the dedicated-node pattern described in the Kubernetes node assignment guidance.
Check security-sensitive isolation separately
For security or regulatory isolation, an ordinary mutable node label alone should not be treated as a security boundary. Kubernetes recommends using labels that the kubelet cannot modify and configuring the Node authorizer and NodeRestriction admission plugin as documented in its node assignment guidance. The label and access-control setup must support the trust boundary you intend to enforce.
Rank #3
Troubleshoot a Pod that remains pending
A toleration only clears a matching taint barrier; it does not prove that any node is a valid destination. Check the full set of scheduling conditions:
- Do the candidate nodes have the labels required by the Pod’s node affinity or
nodeSelector? - Does each taint have a matching toleration with the needed key, value, operator, and effect?
- Are there other taints left unmatched that still affect placement?
- Do candidate nodes have capacity for the Pod’s resource requests?
- Do the Pod’s other scheduling constraints allow any candidate node?
Actual placement also depends on the Kubernetes version and scheduler configuration in use; verify behavior against the cluster you operate.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
