Taints, Tolerations, and the Law of Affinity

Boundaries are mercy

Taints prevent accidental scheduling onto reserved nodes. Tolerations allow exceptions. Affinity expresses preference or requirement for co-location or separation.

Kubblai doctrine: boundaries are not hostility—they are the mechanism that preserves stability under growth.

Practical patterns

Use these patterns to keep your cluster legible.

• Dedicated node pools for stateful or latency-sensitive workloads.
• Taints for platform nodes; tolerations only for platform workloads.
• Anti-affinity or topology spread for replicas to avoid single-node failure.

Common failure modes

Placement rules fail in predictable ways. Experienced operators recognize the pattern quickly.

• Hard affinity + small clusters = permanent Pending during maintenance.
• Overly strict anti-affinity = inability to scale during incident response.
• Taints without clear ownership = ‘mysterious’ scheduling failures across teams.
• Topology constraints misaligned with labels = false sense of resilience.

Diagnostics discipline

When scheduling fails, Kubernetes will tell you why. Read the events; they contain the constraint evaluation narrative.

If you see ‘0/… nodes available’ and you don’t know which predicate is failing, you are operating without a map.

Stewardship

Placement rules are governance. They should be reviewed like policy: documented, versioned, and owned. Otherwise they calcify into folklore.

Treat the scheduler as a shared institution, not a personal tool.