Scaling a pool requires you to change replica count and re-apply. Syself Autopilot adds or removes machines to match. If you want the number to follow demand instead, see [Manual scaling vs the autoscaler](#manual-scaling-vs-the-autoscaler) below. ## Change replicas and apply Edit the pool's entry under `spec.topology.workers.machineDeployments`: ```yaml - class: workeramd64hcloud name: md-0 replicas: 3 replicas: 5 ``` Apply the `Cluster` resource (or let GitOps sync it) and watch: ```console $ kubectl get machines -w ``` ## What happens on scale-up Syself Autopilot creates new `Machine` objects (the Cluster API object that represents one server) up to the new count. On cloud, each provisions a fresh VM in a few minutes. On bare metal, each claims a **free host** from your inventory and installs onto it. A bare-metal worker node is ready in a few minutes. ### Machines stay pending when no host is free On bare metal, `replicas` set above the number of matching free hosts creates `Machine` objects that never reach their end state; they sit pending until a host is available. Set a bare-metal pool's `replicas` to the number of servers you have allocated for that cluster. Plan bare-metal servers per cluster, each server dedicated to one cluster, so a pool can always reach its target and the system does not sit in an unresolved state. ## What happens on scale-down Syself Autopilot removes the surplus machines, draining each first: Cordon The node is marked unschedulable. Drain Pods are evicted with a grace period, respecting PodDisruptionBudgets (limits on how many pods of an app may be down at once). The drain waits for pods to leave within their budget, then proceeds anyway so a stuck PodDisruptionBudget cannot block the scale-down forever. Remove On cloud, the VM is destroyed. On bare metal, the host is released back to the pool. This cordon-drain-replace sequence is the same one Syself Autopilot uses for automatic self-healing. For how to protect a workload with PodDisruptionBudgets during any drain, see [Self-healing and node replacement](/docs/hetzner/apalla/concepts/operations/self-healing-and-node-replacement). Syself Autopilot chooses which machine to remove. To remove a **specific** node instead, annotate its `Machine` object with `cluster.x-k8s.io/delete-machine` before you lower `replicas`. See [Remove a specific node](/docs/hetzner/apalla/servers-and-nodes/maintenance/remove-a-specific-node) for the full steps. ## Bare-metal scale-down returns the host Scaling a bare-metal pool down does not destroy the server. The `HetznerBareMetalHost` returns to your inventory and can be claimed again later. The root disk is wiped on the next install, but data disks are left alone unless you [wipe them](/docs/hetzner/apalla/servers-and-nodes/maintenance/wipe-a-disk). ## Manual scaling vs the autoscaler For steady capacity, set `replicas` by hand. For workloads that rise and fall, hand the pool to the cluster autoscaler: it watches for pending pods and changes the pool's replica count for you, within a minimum and maximum you set. See [Autoscale node pools](/docs/hetzner/apalla/servers-and-nodes/scale/autoscale-node-pools) for the setup. Once the autoscaler owns a pool, remove `replicas` from that pool in the `Cluster` object. Cluster API rejects a pool that has both. ## Capacity planning Capacity planning is more than a node count. Think about CPU and memory, the failure domain (how much you lose when one node or host goes down), and whether workloads should share nodes or stay separated. A useful default: grow to about **10 worker nodes** before you make the nodes bigger. At 10 nodes, losing one is 10% of the cluster, and you usually want 20 to 30% of capacity in reserve for bursts and for riding out a failure. Past 10 nodes, bigger machines often beat adding more small ones. The right shape depends on your workload, so treat this as a starting point. For what one node can actually run, see [Node resources and limits](/docs/hetzner/apalla/servers-and-nodes/pools/node-resources-and-limits). For the machine types, see [Server types and sizing](/docs/hetzner/apalla/servers-and-nodes/cloud/server-types-and-sizing). To match spend to load, see [Size a cluster for cost](/docs/hetzner/apalla/servers-and-nodes/fleet/size-a-cluster-for-cost). [Estimate costs before changing capacity](https://syself.com/pricing/calculator) — it's only an estimate for a cluster that already exists. ## Related - [Autoscale node pools](/docs/hetzner/apalla/servers-and-nodes/scale/autoscale-node-pools) - [Remove a specific node](/docs/hetzner/apalla/servers-and-nodes/maintenance/remove-a-specific-node) - [Server types and sizing](/docs/hetzner/apalla/servers-and-nodes/cloud/server-types-and-sizing) - [Size a cluster for cost](/docs/hetzner/apalla/servers-and-nodes/fleet/size-a-cluster-for-cost)