Creating Highly Available Clusters with kubeadm [page]deterministic

setup

This page explains two different approaches to setting up a highly available Kubernetes cluster using kubeadm:

With stacked control plane nodes. This approach requires less infrastructure. The etcd members and control plane nodes are co-located.
With an external etcd cluster. This approach requires more infrastructure. The control plane nodes and etcd members are separated.

Before proceeding, you should carefully consider which approach best meets the needs of your applications and environment. [Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/) outlines the advantages and disadvantages of each.

If you encounter issues with setting up the HA cluster, please report these in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new).

See also the [upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).

> Caution: This page does not address running your cluster on a cloud provider. In a cloud environment, neither approach documented here works with Service objects of type LoadBalancer, or with dynamic PersistentVolumes.

The prerequisites depend on which topology you have selected for your cluster's control plane:

You need:

Three or more machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the control-plane nodes. Having an odd number of control plane nodes can help with leader selection in the case of machine or zone failure. - including a , already set up and working
Three or more machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers - including a container runtime, already set up and working
Full network connectivity between all machines in the cluster (public or private network)
Superuser privileges on all machines using `sudo` - You can use a different tool; this guide uses `sudo` in the examples.
SSH access from one device to all nodes in the system
`kubeadm` and `kubelet` already installed on all machines.

_See [Stacked etcd topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/#stacked-etcd-topology) for context._

You need:

Three or more machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the control-plane nodes. Having an odd number of control plane nodes can help with leader selection in the case of machine or zone failure. - including a , already set up and working
Three or more machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers - including a container runtime, already set up and working
Full network connectivity between all machines in the cluster (public or private network)
Superuser privileges on all machines using `sudo` - You can use a different tool; this guide uses `sudo` in the examples.
SSH access from one device to all nodes in the system
`kubeadm` and `kubelet` already installed on all machines.

And you also need:

Three or more additional machines, that will become etcd cluster members. Having an odd number of members in the etcd cluster is a requirement for achieving optimal voting quorum. - These machines again need to have `kubeadm` and `kubelet` installed. - These machines also require a container runtime, that is already set up and working.

_See [External etcd topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/#external-etcd-topology) for context._

### Container images

Each host should have access read and fetch images from the Kubernetes container image registry, `registry.k8s.io`. If you want to deploy a highly-available cluster where the hosts do not have access to pull images, this is possible. Y …(trimmed)