Taints and tolerations
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 Self-healing and node replacement 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
NoScheduletaint 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/uninitializedtaint 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 Reserve a pool for one workload .