KB: Kubernetes how to bypass Tolerations/Taints/Affinity

 

Note, by design it is "Scheduler" pods responsibility to place the pod in the correct Node. But if you manually specify the nodeName selector you are bypassing the "Scheduler" pod and that means you skipping the Tains/Tolerations and any affinity. Basically skipping the "Scheduler Logic" all together. 

if you manually specify the nodeName field in a Kubernetes Pod spec, you are bypassing:

  • Taints and tolerations

  • Node affinity

  • Scheduler logic entirely

Here's what happens:

  • When you set .spec.nodeName in a Pod or Deployment template, Kubernetes does not use the scheduler to determine where the pod should run.

  • The pod is directly assigned to that node.

  • As a result:

    • Tolerations are ignored – the pod is placed even if it doesn’t tolerate the node’s taints.

    • Affinity rules are ignored – because the scheduler isn’t consulted at all.

    • NodeSelector and affinity constraints are not evaluated – they are bypassed.

What can go wrong:

  • If the node is tainted in a way that would normally block the pod, it may still run (or crash) if you force it with nodeName.

  • If the pod doesn’t tolerate the node’s environment (e.g., storage, CPU arch), it may fail.

  • You might get scheduling issues or maintenance challenges later.

When is it used?

  • Advanced or static scheduling scenarios.

  • Testing/debugging.

  • DaemonSets internally do this logic per node.

Example:

apiVersion: v1
kind: Pod metadata: name: test-pod spec: nodeName: worker-node-1 containers: - name: nginx image: nginx

Summary:

Yes, nodeName skips scheduler
It ignores taints, tolerations, affinity, nodeSelector

Comments

Popular posts from this blog

KB: Azure ACA Container fails to start (no User Assigned or Delegated Managed Identity found for specified ClientId)

Electron Process Execution Failure with FSLogix

KB:RMM VS DEX (Remote Monitoring Management vs Digital Employee Experience)