Skip to main content

Taints and tolerations

Inspect 1.36

Custom node taints are not a reliable placement tool on Syself Autopilot, so the supported pattern is a dedicated pool with a label instead. You cannot set a taint on a worker pool (the platform does not allow it), and a taint added by hand with kubectl taint is lost the moment the node is replaced, which happens on every upgrade and maintenance.

Warning

A kubectl taint on a node is silently erased on the next node replacement, and replacements are routine, not rare.

Why a custom taint does not survive 

A taint you add manually with kubectl taint lives only on that node. Nodes get replaced as part of a cluster upgrade, a health-check recovery, or a removal you trigger yourself. See for what triggers each. The replacement node comes up without your taint.

The built-in taints on the platform 

The platform forces a few taints by default:

  • The control-plane NoSchedule taint keeps your workloads off control-plane nodes. It is why your pods land only on workers. You would tolerate it only to run something on the control plane on purpose, which is rare and usually a mistake for tenant workloads.
  • A transient node.cloudprovider.kubernetes.io/uninitialized taint sits on a brand-new node for a few seconds while the platform wires it up, then clears itself.

You tolerate these only when a platform component must run everywhere. A logging or metrics DaemonSet uses tolerations: [{operator: Exists}] to land on control planes too. Your workloads most often have no reason to use them.

Reserve a pool for one workload 

A pool label plus a nodeSelector is the supported way to hold a class of hardware for one workload. See .