Skip to main content

Server types and sizing

Inspect 1.36

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 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 ). 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 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⁠. Follow 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⁠. 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

How Syself Autopilot allocates CPU and memory on each node, sets pod limits, and protects node stability with eviction thresholds. All limits from one reference page.

Auditd rules

How the immutable auditd ruleset on Syself Linux records privileged activity, which compliance frameworks it supports evidence for, and how the audit log leaves the node.