Get started

Demystifying High Availability in Kubernetes Using Kubeadm

Jan 17 · 6 min read

Introduction

The rise of containers has reshaped the way we develop, deploy and maintain the software. Containers allow us to package the different services that constitute an application into separate containers, and to deploy those containers across a set of virtual and physical machines. This gives rise to container orchestration tool to automate the deployment, management, scaling and availability of a container-based application. Kubernetes allows deployment and management container-based applications at scale.

One of the main advantages of Kubernetes is how it brings greater reliability and stability to the container-based distributed application, through the use of dynamic scheduling of containers. But, how do you make sure Kubernetes itself stays up when a component or its master node goes down?

Why we need Kubernetes High Availability(HA)?

Kubernetes High-Availability is about setting up Kubernetes, along with its supporting components in a way that there is no single point of failure. A single master cluster can easily fail, while a multi-master cluster uses multiple master nodes, each of which has access to same worker nodes. In a single master cluster the important component like API server, controller manager lies only on the single master node and if it fails you cannot create more services, pods etc. However, in case of Kubernetes HA environment, these important components are replicated on multiple masters(usually three masters) and if any of the masters fail, the other masters keep the cluster up and running.

Advantages of multi-master

In a single master setup, the master node manages the etcd database, API server, controller manager and scheduler, along with the worker nodes. However, if that single master node fails, all the worker node fail as well and entire cluster will be lost.

In a multi-master setup, by contrast, multi-master provides high availability for a single cluster and improves network performance because all the masters behave like a unified data center.

A multi-master setup protects against a wide range of failure modes, from a loss of single worker node to the failure of the master node’s etcd service. By providing redundancy, a multi-master cluster serves a highly available system for your end users.

Steps to achieve Kubernetes HA

Before moving to steps to achieve high-availability, let us understand what we are trying to achieve through a diagram:

(Image Source: Kubernetes Official Documentation)

Master Node: Each master node in a multi-master environment run its’ own copy of Kube API server. This can be used for load balancing among the master nodes. Master node also runs its copy of the etcd database, which stores all the data of cluster. In addition to API server and etcd database, the master node also runs k8s controller manager, which handles replication and scheduler, which schedules pods to nodes.

Worker Node: Like single master in the multi-master cluster also the worker runs their own component mainly orchestrating pods in the Kubernetes cluster. We need 3 machines which satisfy the Kubernetes master requirement and 3 machines which satisfy the Kubernetes worker requirement.

For each master, that has been provisioned, follow the installation guide to install kubeadm and its dependencies. In this blog, we will use k8s 1.10.4 to implement HA.

Note: Please note that cgroup driver for docker and kubelet differs in some version of k8s, make sure you change cgroup driver to cgroupfs for docker and kubelet. If cgroup driver for kubelet and docker differs then the master doesn’t come up when rebooted.

Setup etcd cluster

Install cfssl and cfssljson

2. Generate certificates on master-0

3. Create config.json file in /etc/kubernetes/pki/etcd folder with following content:

4. Create ca-csr.json file in /etc/kubernetes/pki/etcd folder with following content.

5. Create client.json file in /etc/kubernetes/pki/etcd folder with following content.

6. Create a directory /etc/kubernetes/pki/etcd on master-1 and master-2 and copy all the generated certificates into it.

7. On all masters, now generate peer and etcd certs in /etc/kubernetes/pki/etcd. To generate them, we need the previous CA certificates on all masters.

This will replace the default configuration with your machine’s hostname and IP address, so in case if you encounter any problem just check the hostname and IP address are correct and rerun cfssl command.

8. On all masters, Install etcd and set it’s environment file

9. Now, we will create a 3 node etcd cluster on all 3 master nodes. Starting etcd service on all three nodes as systemd. Create a file /etc/systemd/system/etcd.service on all masters

10. Ensure that you will replace the following placeholder with

<host_name> : Replace as the master’s hostname
<host_private_ip>: Replace as the current host private IP
<master0_private_ip>: Replace as the master-0 private IP
<master1_private_ip>: Replace as the master-1 private IP
<master2_private_ip>: Replace as the master-2 private IP

11. Start the etcd service on all three master nodes and check the etcd cluster health:

This will show the cluster healthy and connected to all three nodes.

Setup load balancer

There are multiple cloud provider solutions for load balancing like AWS elastic load balancer, GCE load balancing etc. There might not be a physical load balancer available, we can setup a virtual IP load balancer to healthy node master. We are using keepalived for load balancing, install keepalived on all master nodes

$ yum install keepalived -y

Create the following configuration file /etc/keepalived/keepalived.conf on all master nodes:

state is either MASTER (on the first master nodes) or BACKUP (the other master nodes).
Interface is generally the primary interface, in my case it is eth0
Priority should be higher for master node e.g 101 and lower for others e.g 100
Virtual_ip should contain the virtual ip of master nodes

Install the following health check script to /etc/keepalived/check_apiserver.sh on all master nodes:

$ systemctl restart keepalived

Setup three master node cluster

Run kubeadm init on master0:

Create config.yaml file with following content.

Please ensure that the following placeholders are replaced:

<master-private-ip> with the private IPv4 of the master server on which config file resides.
<master0-ip-address>, <master1-ip-address> and <master-2-ip-address> with the IP addresses of your three master nodes
<podCIDR> with your Pod CIDR. Please read the CNI network section of the docs for more information. Some CNI providers do not require a value to be set. I am using weave-net as pod network, hence podCIDR will be 10.32.0.0/12
<load-balancer-ip> with the virtual IP set up in the load balancer in the previous section.

$ kubeadm init --config=config.yaml

10. Run kubeadm init on master1 and master2:

First of all copy /etc/kubernetes/pki/ca.crt, /etc/kubernetes/pki/ca.key, /etc/kubernetes/pki/sa.key, /etc/kubernetes/pki/sa.pub to master1’s and master2’s /etc/kubernetes/pki folder.

Note: Copying this files is crucial, otherwise the other two master nodes won’t go into the ready state.

Copy the config file config.yaml from master0 to master1 and master2. We need to change <master-private-ip> to current master host’s private IP.

$ kubeadm init --config=config.yaml

11. Now you can install pod network on all three masters to bring them in the ready state. I am using weave-net pod network, to apply weave-net run:

export kubever=$(kubectl version | base64 | tr -d '\n') kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"

12. By default, k8s doesn’t schedule any workload on the master, so if you want to schedule workload on master node as well, taint all the master nodes using the command:

$ kubectl taint nodes --all node-role.kubernetes.io/master-

13. Now that we have functional master nodes, we can join some worker nodes:

Use the join string you got at the end of kubeadm init command

$ kubeadm join 10.0.1.234:6443 --token llb1kx.azsbunpbg13tgc8k --discovery-token-ca-cert-hash sha256:1ad2a436ce0c277d0c5bd3826091e72badbd8417ffdbbd4f6584a2de588bf522

High Availability in action

The kubernetes HA cluster will look like:

After failing over one master node the Kubernetes cluster is still accessible.

Even after one node failed, all the important components are up and running. The cluster is still accessible and you can create more pods, deployment services etc.

Conclusion

High availability is an important part of reliability engineering, focused on making system reliable and avoid any single point of failure of the complete system. At first glance, its implementation might seem quite complex, but HA brings tremendous advantages to the system that requires increased stability and reliability. Using a highly available cluster is one of the most important aspects of building a solid infrastructure.

*****************************************************************

This post was originally published on Velotio Blog.

Velotio Technologies is an outsourced software product development partner for technology startups and enterprises. We specialize in enterprise B2B and SaaS product development with a focus on artificial intelligence and machine learning, DevOps, and test engineering.

Interested in learning more about us? We would love to connect with you on ourWebsite, LinkedIn or Twitter.

*****************************************************************