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 repair. A reservation that silently disappears on the next node roll is worse than none, so reserve dedicated nodes with a pool and a label rather than a taint.

> [!WARNING]
> A `kubectl taint` on a node is silently erased on the next node replacement, and replacements are routine, not rare. Do not build a reservation on one.

## The built-in taints you will meet

You never set a taint here, but two are already at work and worth knowing:

- 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 own workloads have no reason to.

## Reserve a node the supported way

To hold a class of hardware such as a GPU, a bare-metal box, or a client's dedicated capacity for one workload, steer with a pool label instead of a taint:

<Steps>

1. Put the dedicated servers in their own [worker pool](/docs/hetzner/apalla/servers-and-nodes/pools/node-pools-overview) and set a label in the pool's `metadata`. A pool label persists across node replacement; a `kubectl` label does not.
2. Point the workload at that pool with a `nodeSelector` or [node affinity](/docs/hetzner/apalla/workloads/placement/affinity-and-anti-affinity) on the label.
3. Do not deploy anything else that selects the pool. You control what runs there.

</Steps>

```yaml
# The dedicated workload targets the pool's label
spec:
  nodeSelector:
    autopilot.syself.com/gpu: "true"
```

## What this does and does not give you

A label reliably pulls the **wanted** pod onto the dedicated nodes, and it survives node replacement. What it cannot do, and it is the one thing a taint would have done, is repel a pod that carries no selector: an unmarked general pod can still land on a dedicated node.

Two things keep that from hurting. You decide what gets deployed where. And special hardware is claimed through its own resource, not the node. A GPU node claims it via an [`nvidia.com/gpu` request](/docs/hetzner/apalla/workloads/specialized/run-gpu-workloads), a secure-runtime pod via its [runtime class](/docs/hetzner/apalla/workloads/secure/run-in-the-secure-runtime), so a stray pod sharing a dedicated node's CPU cannot consume the capacity you were protecting.

For a hard, enforced guarantee that nothing else can schedule onto a set of nodes, contact Syself. For the servers-side view of why pool taints are not exposed, see [Apply taints](/docs/hetzner/apalla/servers-and-nodes/scheduling/apply-taints).