## Introduction

We strongly recommend that you deploy your control plane in a highly available configuration. Providing redundancy and fault tolerance minimizes downtime in the event of node failures or sudden workload spikes.

For production clusters, the recommended amount of control plane nodes is 5, but if you have a small cluster, you might be good with only 3. You shouldn't use just 1 control plane for anything more than a disposable test cluster.

With only two nodes, if one node fails or becomes unreachable, the cluster loses quorum, which can lead to a split-brain scenario where each node believes it's the leader. Below you can find a table showing the number of control planes your cluster can tolerate the failure of.

| Amount of Control Plane Nodes | Maximum Nodes that can go down |
| ----------------------------- | ------------------------------ |
| 1                             | 0                              |
| 2                             | 0                              |
| 3                             | 1                              |
| 4                             | 1                              |
| 5                             | 2                              |

Because of this, you should always aim to use an odd amount of control plane nodes to properly achieve an increase in availability.

## Making Your Cluster Highly Available

You can edit your Cluster resource in the management cluster, or the `cluster.yaml` file in your GitOps repository, and change the `spec.topology.controlplane.replicas` to set the amount of control plane nodes you want. In the example below, we set it to 5.

```yaml
/// cluster.yaml
apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: mycluster
spec:
  clusterNetwork:
    services:
      cidrBlocks: ['10.128.0.0/12']
    pods:
      cidrBlocks: ['192.168.0.0/16']
    serviceDomain: 'cluster.local'
  topology:
    classRef:
      name: hetzner-apalla-1-35-v3
    version: v1.35.6
    controlPlane:
      replicas: 5
...
```