You configure the server type for each node pool by setting a topology variable on your `Cluster` object. The control plane and workers can use different types. ## How to set the server type Set the server type under `spec.topology.variables` on the `Cluster` object: ```yaml spec: topology: variables: - name: controlPlaneMachineTypeHcloud value: cpx32 - name: workerMachineTypeHcloud value: cpx32 ``` Both variables accept any valid Hetzner Cloud server type name. The default for both is `cpx32`. You can use a different type for each pool, and different worker pools can use different types by overriding the variable per pool. Only `amd64` servers are supported today. The `controlPlaneMachineArchHcloud` variable only accepts `amd64`. ## Defaults | Role | Default type | | ---------------------- | ------------ | | Control plane (HCloud) | `cpx32` | | Worker (HCloud) | `cpx32` | A `cpx32` gives you 4 vCPUs and 8 GB RAM. That is a reasonable starting point for a worker, but it leaves little headroom on the control plane for large clusters. For clusters with many nodes or high API load, use a larger type for the control plane. Bare-metal nodes (Hetzner Robot) do not use a type variable. You choose the hardware by ordering the right server from Hetzner Robot. See [Add bare-metal servers](/docs/hetzner/apalla/servers-and-nodes/provision/add-bare-metal-servers) for how to add them to your cluster. ## Choosing a type for the control plane The control plane runs `kube-apiserver`, `etcd`, and the scheduler. These processes are CPU and memory intensive when you have many nodes, many objects in the cluster, or high API request rates. Start with a type that gives the control plane at least 4 GB of RAM dedicated to the Kubernetes components. After the system processes, reserved memory, and etcd are accounted for, a `cpx32` (8 GB total) has roughly 4 to 5 GB left. For clusters with more than 20 nodes, consider `cpx41` (16 GB RAM) or larger. Control planes run with a `NoSchedule` taint, so your workload pods do not land on them. You do not need to size for workloads, only for the Kubernetes control-plane processes. ## Choosing a type for workers Workers run your application pods. The main inputs are: - **Pod density.** The cluster allows up to 220 pods per node (see [node resources and limits](/docs/hetzner/apalla/reference/node-resources-and-limits)). On a small server you usually run out of memory before you reach that pod count. So on small servers it is memory, not the pod count, that limits how many pods fit. - **Workload memory and CPU.** Add up the resource requests in your pods and compare them to the node's allocatable capacity. Some of each node's memory and CPU is set aside for the operating system and the Kubernetes agents (the `systemReserved` setting). The scheduler cannot place pods on that reserved part, so subtract it before you compare the node's capacity to your pods. - **Pod churn.** Nodes with very high pod turnover (many short-lived pods) benefit from more CPU. The container runtime and the kubelet use CPU on every pod start and stop. A `cpx32` (4 vCPU / 8 GB) is a common starting type for small to medium workloads. For workloads with higher memory requirements, `cpx41` (8 vCPU / 16 GB) or `cpx51` (16 vCPU / 32 GB) are typical next steps. ## GPU nodes GPU nodes run the same node image as every other node. When Syself detects a supported NVIDIA GPU on a node, it sets up the NVIDIA driver and the toolkit that exposes GPUs to containers, so pods can request the card. Detection matches the card against the NVIDIA models Hetzner ships in its GPU servers. Any other card is treated as a plain display adapter and gets no GPU support. To run GPU workloads, add Hetzner bare-metal GPU servers (the GEX line, or an auction server with a supported card) to a dedicated worker pool. There is no HCloud GPU server type and no type variable to set: Syself sets up the GPU from the hardware it finds. Request GPU resources in your pod spec with `nvidia.com/gpu`. See [run GPU workloads](/docs/hetzner/apalla/workloads/specialized/run-gpu-workloads) for the full setup. ## Bare-metal servers Bare-metal servers are the right choice for stateful applications and databases. You get fast local storage with no network in between, and the data disks survive when Syself reprovisions the server. Hetzner Cloud volumes are network storage, fine for testing and light workloads. For production databases, run them on bare-metal servers with local disks. Bare-metal nodes do not use a type variable. You choose the hardware by ordering the right server from [Hetzner Robot](https://robot.hetzner.com/). Follow [Add bare-metal servers](/docs/hetzner/apalla/servers-and-nodes/provision/add-bare-metal-servers) to register your servers, assign them to a cluster, and watch them join. ## How to change the type Change the `controlPlaneMachineTypeHcloud` or `workerMachineTypeHcloud` variable on the `Cluster` object. Syself triggers a rolling replacement: new nodes come up with the new type, old nodes are drained and deleted. The rollout drains each node and honours PodDisruptionBudgets for up to 180 seconds (`nodeDrainTimeoutSeconds: 180`); if a PodDisruptionBudget still blocks the drain after that, the node is removed anyway. A PodDisruptionBudget is a Kubernetes object that caps how many pods in a set can be unavailable at once. For bare-metal nodes, you cannot resize in place. Add a server of the new type to your Hetzner Robot account, label it for the cluster, then drain and remove the old server. > [!WARNING] > Changing the control-plane type triggers a rolling replacement of the control-plane nodes. etcd quorum (the minimum number of etcd members required to agree on changes) is maintained throughout if you have three replicas, but the process takes several minutes per node. ## Hetzner Cloud server type reference For the full and current list of available Hetzner Cloud server types, their vCPU counts, RAM, and pricing, see the [Hetzner Cloud pricing page](https://www.hetzner.com/cloud). The cluster stack accepts any valid type name from that list, so new types work as soon as Hetzner makes them available in your region. ## Related - [Node resources and limits](/docs/hetzner/apalla/reference/node-resources-and-limits) - [Cluster variables reference](/docs/hetzner/apalla/reference/cluster-variables) - [Manage HCloud servers](/docs/hetzner/apalla/servers-and-nodes/provision/add-cloud-servers) - [Add bare-metal servers](/docs/hetzner/apalla/servers-and-nodes/provision/add-bare-metal-servers) - [Run GPU workloads](/docs/hetzner/apalla/workloads/specialized/run-gpu-workloads) - [Bare metal and cloud](/docs/hetzner/apalla/concepts/internals/bare-metal-and-cloud)