Pair Kubernetes tolerations with an actual placement rule

A toleration removes a scheduling obstacle; it does not select the intended node.

Source facts

Kubernetes taints repel Pods, while tolerations allow matching Pods past that restriction. A matching toleration does not guarantee placement because the scheduler evaluates other constraints. NoSchedule prevents new unmatched placement, while NoExecute can also remove already running Pods that lack a suitable toleration. Node affinity is a separate mechanism that attracts or requires placement on selected nodes.

Source: Kubernetes documentation — Taints and Tolerations.

Applicability

Review node admission and eviction through taints, tolerations and a separate affinity requirement.

DSE recommendation

DSE recommends documenting both sides of dedicated-node placement: which workloads may enter and which workloads must use those nodes. Review the exact taint effect rather than copying a toleration solely by key. Broad tolerations deserve particular scrutiny because they can bypass more exclusions than the application needs. Plan how existing Pods will behave before applying a NoExecute change. Keep infrastructure-maintenance tolerations separate from application-specific placement choices so an operational exception does not silently become permanent access to a node pool.

Verification

In a controlled node pool, test matching and nonmatching Pods against the chosen effect. Check placement events and, where approved, the behavior of an already running Pod. Confirm the separate affinity requirement selects the intended pool. Retain the exact toleration operator, value and effect beside the node’s taint. Ask a second reviewer to explain why the allowed Pod qualifies and why the rejected Pod does not, using the effective manifest.

Official reference

Kubernetes documentation — Taints and Tolerations. Reviewed October 20, 2026.