Remove a specific node

By default, when you scale a worker pool down, Syself Autopilot picks which machine to remove. To remove a specific machine, annotate it first, then lower the replica count. You must do both: the annotation alone does nothing, because a machine is only removed when the replica count requires it.

Prerequisites#

• Access to the management cluster. See Access the management cluster .
• A kubeconfig for your workload cluster, to confirm the node is gone.

Step 1: Find the Machine#

A Machine object represents one node and its lifecycle in the management cluster.

Every management object, including a Machine, lives in a namespace. That namespace holds your organization's objects, and several clusters can share it, each with its own objects inside.

With the kubeconfig from the getting-started guide, your default namespace is already your organization namespace, so you can leave off -n. Otherwise find it with kubectl get cluster -A.

		$ kubectl get machines -n <cluster-namespace> -o wide
	

-o wide shows the node name and provider ID next to each machine (bare-metal nodes use an hrobot:// provider ID). Match the node name from your workload cluster (kubectl get nodes) to the machine name here.

Step 2: Annotate the Machine#

An annotation is a key-value tag on a Kubernetes object. This one marks the machine for deletion when the pool scales down:

		$ kubectl annotate machine <machine-name> -n <cluster-namespace> cluster.x-k8s.io/delete-machine=""
	

You can annotate several machines at once. If you lower the replica count by more machines than you annotated, Syself Autopilot deletes all the annotated ones first, then picks unannotated machines to reach the new count.

Step 3: Lower the replica count#

Edit the Cluster object and decrease replicas for the pool:

		$ kubectl edit cluster <cluster-name> -n <cluster-namespace>
	

Find the pool under spec.topology.workers.machineDeployments[] and decrease replicas:

		- class: workeramd64hcloud
  name: md-0
  replicas: 5
  replicas: 4
	

Bare-metal pools work the same way, decreasing replicas on the workeramd64baremetal entry. Syself Autopilot picks up the change and starts removing the annotated machine, the same way it would for an ordinary pool scale-down .

Control-plane nodes#

The delete-machine annotation is a general Cluster API pattern, not a worker-only one. It works on any Machine, including a control-plane node's. Annotate the control-plane Machine you want gone, then lower spec.topology.controlPlane.replicas instead of a worker pool's replicas. Syself Autopilot removes the annotated node on that scale-down and takes control-plane nodes one at a time, so etcd keeps its quorum. For the control-plane count itself, see High-availability control plane .

What happens during removal#

Syself Autopilot drains the machine before removing it:

See Self-healing and node replacement for protecting workloads during a drain with PodDisruptionBudgets.

Bare metal: the host returns to the pool#

Removing a bare-metal node does not destroy the server. Syself Autopilot releases the HetznerBareMetalHost back to the pool, where it can be claimed again. Only the OS install disk is ever touched: it is the disk you named by WWN, bound to the HetznerBareMetalHost, and a reprovision wipes and rewrites just that one. Every other disk keeps its data, intact and ready to use. Nothing extra is needed to preserve it. Because the data stays put, you can even move a server, disks and all, from one cluster to another. If you do want to clear a data disk, wipe it yourself in the rescue system; see Wipe a disk .