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](/docs/hetzner/apalla/platform/setup/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. ```console $ kubectl get machines -n -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: ```console $ kubectl annotate machine -n cluster.x-k8s.io/delete-machine="" ``` > [!WARNING] > Annotate the `Machine` object only. Do **not** annotate `HCloudMachine` or `HetznerBareMetalMachine` objects. Syself Autopilot reads the annotation from `Machine`; annotating the provider objects has no effect. 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: ```console $ kubectl edit cluster -n ``` Find the pool under `spec.topology.workers.machineDeployments[]` and decrease `replicas`: ```yaml - 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](/docs/hetzner/apalla/servers-and-nodes/scale/scale-a-pool). ## 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 [Configure control planes](/docs/hetzner/apalla/servers-and-nodes/control-planes/configure-control-planes). ## What happens during removal The node is cordoned, drained, and removed the same way as in any scale-down, and a bare-metal host returns to the pool with its data disks intact. See [Scale a node pool](/docs/hetzner/apalla/servers-and-nodes/scale/scale-a-pool#bare-metal-scale-down-returns-the-host) for the details. ## Related - [Scale a node pool](/docs/hetzner/apalla/servers-and-nodes/scale/scale-a-pool) - [Wipe a disk before provisioning](/docs/hetzner/apalla/servers-and-nodes/maintenance/wipe-a-disk) - [Self-healing and node replacement](/docs/hetzner/apalla/concepts/operations/self-healing-and-node-replacement) - [Configure control planes](/docs/hetzner/apalla/servers-and-nodes/control-planes/configure-control-planes)