Node labels, taints, and tolerations

Match exact node capabilities and restrict new placements without implicit eviction.

Node labels describe placement capabilities. Taints restrict admission to workloads with matching tolerations. Both affect candidate selection rather than granting access to the host.

Match labelsCopy link

A required selector matches every supplied key and value exactly. Keys and values are case-sensitive strings. An absent key does not match an empty-string value, and a display-name change does not change a selector.

Use administrator-managed capability labels for hardware requirements, such as disk.class=nvme. Workload owners must not be able to edit the node labels that satisfy their own placement restrictions. Project labels and node labels have different scopes even when they use the same key text.

Apply a taintCopy link

Open Node → Admission → Taints and add a key, optional value, and the supported effect NoSchedule. The effect prevents new placement unless the droplet has a matching toleration. It does not evict a guest already on the host.

To reserve node admission for licensed workloads, use this taint definition:

{
  "taints": [
    {
      "key": "workload.class",
      "value": "licensed",
      "effect": "NoSchedule"
    }
  ]
}

A NoExecute effect is unsupported and rejected; use an explicit drain when existing workloads must move. Adding a taint during a migration can make the pending destination ineligible before its placement commit.

Tolerate a restrictionCopy link

A toleration specifies a key, operator, effect, and optionally a value. Equal requires the same key and value. Exists requires the key regardless of value and rejects a supplied value. Omitted operator defaults to Equal; omitted effect defaults to NoSchedule.

A toleration permits a node. Pair it with a required selector when the workload must run on the dedicated pool rather than any untainted eligible node. An organization admission policy can prohibit broad Exists tolerations for protected hardware.

Edit a running workloadCopy link

Adding or removing a selector or toleration creates a configuration revision. Existing execution remains on its node until a migration, restart placement, or explicit reconciliation occurs. The console can report that the current placement no longer satisfies the desired policy.

A restart can fail after a selector change even though the guest previously ran successfully on that host. Resolve the actual rule or provide eligible capacity; repeatedly starting the guest does not relax required matching.

Remove obsolete labelsCopy link

Preview workloads and templates referencing a capability before removing it. A label change can eliminate every recovery destination for a pinned template without affecting its running guests.

Use Node API and Hardware policy API for conditional changes, and placement groups for constraints shared across guests.