Configure control planes

This page covers how to configure a cluster’s control plane: how many nodes to run, how to size them, where to place them, and how to change the count safely.

Choose 1, 3, or 5 control planes

Each control plane node runs an etcd member, and etcd accepts writes only while a majority of its members are reachable. That majority is the quorum:

		quorum = floor(members / 2) + 1
	

An even count never tolerates more failures than the odd number below it, which is why a control plane runs an odd number of nodes.

• One node has no redundancy: the Kubernetes API and etcd are down until the node recovers or is replaced. Use it only where control-plane downtime is acceptable, such as development, CI, and disposable clusters.
• Three nodes is the standard production baseline. It survives losing one node, lets Syself Autopilot replace one node at a time, and rides through rolling upgrades without taking the control plane offline. Use this unless you have a specific reason not to.
• Five nodes tolerates two simultaneous failures. It is worth the extra consensus overhead only for large clusters (many nodes or objects, high API churn) that need that margin.

Size the control plane nodes

Give each control plane node at least 4 vCPU and 8 GB of RAM. On Hetzner Cloud, cpx32 (4 vCPU, 8 GB) is the baseline for production. For clusters with more than 20 nodes, use cpx41 (16 GB) or larger. Set the machine type in the Cluster topology:

		spec:
  topology:
    controlPlane:
      class: hcloud
      replicas: 3
 
    variables:
      - name: controlPlaneMachineTypeHcloud
        value: cpx32
	

Control-plane load grows with the size and activity of the cluster: more nodes, pods, objects, and API traffic. Increase the control-plane server size as the cluster grows rather than adding replicas for compute. See Server types and sizing for detailed guidance.

These minimums apply equally to bare metal control planes. Select a HetznerBareMetalHost that provides at least 4 vCPU and 8 GB of RAM, and move to a more capable server as the cluster grows. For the full setup, see Bare metal control planes .

Place nodes across hosts, in one region

Three control plane nodes give no host-level redundancy if they share a physical host. On Hetzner Cloud, put them in a placement group so they land on separate hosts. If one host fails, only one member is lost and the other two keep quorum. See Use placement groups for configuration.

On bare metal, each control plane node already runs on its own physical server, so placement groups do not apply. See Bare metal control planes for the full setup.

Keep all control plane nodes in one Hetzner region. etcd is latency-sensitive, because every write needs agreement from a majority of members, and spreading members across distant regions raises that latency and makes network partitions more disruptive. Use separate physical hosts within the region for failure isolation.

Surviving a whole region going down is hard to solve in general. If your etcd is spread across three geo-redundant regions but your workload is not, you still face downtime. To cleanly separate regions, we recommend running separate Kubernetes clusters rather than stretching one etcd cluster across regions.

Change the count safely

Set spec.topology.controlPlane.replicas in the Cluster object to the number you want:

		apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: mycluster
spec:
  topology:
    controlPlane:
      class: hcloud
      replicas: 3
	

		apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: mycluster
spec:
  topology:
    controlPlane:
      class: hetznerbaremetal
      replicas: 3
      variables:
        overrides:
          - name: controlPlaneHostSelectorBareMetal
            value:
              matchLabels:
                role: controlplane
                cluster: mycluster
	

Pick an odd target count. Syself Autopilot applies the change one node at a time, waiting for each new member to join, for etcd to report it healthy, and for the control plane to be stable again before it moves to the next.

Bare metal control planes change the same way, drawing from your registered hosts rather than provisioning new servers on demand. Keep enough HetznerBareMetalHost resources available to satisfy the target count. The host selector in the example above picks those hosts by their labels. See Bare metal control planes for how to register and label them.

Related

• Create a cluster
• Self-healing and node replacement
• Plan maintenance and prechecks