Setup kubernetes HA cluster in AWS using kubeadm —Part 1 — the what and why 🤔
Introduction
In this article I want to go over the what and why of the process of setting up a highly available kubernetes cluster on AWS and in the next article I will be going over the process of doing the same.
What is a highly available cluster in kubernetes?
A cluster generally refers to a group of something. In terms of kubernetes, a cluster means having a group of nodes connected to each other. Now if you have a group of nodes connected to each other then how do you control the cluster? How do you interact with the cluster? How do we know if something is wrong with the cluster? All these questions will come up and I will try to answer them in this article.
For now, let us understand more about the clusters that are created in kubernetes. They can be classified broadly into two types
- Single master cluster: In this cluster, we have only one master node and multiple worker nodes. This type of cluster can work just fine if you are working on some POC stuff but for the production environment, we need to move to our next type of cluster i.e. multi-master cluster. The diagram 1 below shows the simplified view of the single master kubernetes cluster.
- Multi-master cluster (HA cluster): In a multi-master cluster as you might have guessed we have multiple master nodes and multiple worker nodes. This setup ensures that even if one of the masters goes down we still have other master nodes to run the cluster. Refer the Diagram 2 for the simplified view.
Why do we need a highly available kubernetes cluster?
As we are moving towards deploying more and more applications in a microservice architecture, it is essential to ensure that we have no downtime i.e. the application should be available at all times. Having only one master in a kubernetes cluster can introduce a single point of failure and cause downtime for the applications deployed on that particular cluster. Hence to get rid of this issue we have moved to having multiple masters.
Now that you understand what is highly available kubernetes cluster and why we need them let’s try to understand some of the components that we will use to setup the HA cluster on AWS.
kubeadm — The cluster creator 😎
kubeadm is a tool that we can use to create a kubernetes cluster. While there are other tools out there in the market for this purpose; we will use kubeadm in this guide primarily because using kubeadm gives us a very basic and minimum-viable cluster to work with.
kubectl — The cluster manager 🫡
Ever wondered if we have multiple nodes in the cluster, how will we interact with the cluster? How will we deploy our application onto the cluster? How will we get to know what state our deployment is in? etc. Well to make our lives simple kubernetes has a tool that makes it very easy for us to manage the cluster — kubectl
kubectl can be used for managing the clusters, deploying our workloads onto the cluster as well as monitoring the state of our deployment, etc.
kubelet — The container manager
This component helps us to manage our deployments across the entire cluster. It is the one component that is also responsible for health checks of the workloads as well as the nodes. It gives the report to the master node at regular time intervals.
Container Runtime Interface (CRI)
A container runtime is a component that must be installed on all the nodes of the cluster. The container runtime is the piece of software responsible for running the containers. Below are the most popular container runtimes available.
- docker (Note: After kubernetes version, 1.23 kubernetes does not support docker as its container runtime.)
- cri-o
- cri-dockerd (A replacement of docker)
- containerd (This is becoming the global standard for running containers)
Please refer to individual websites for getting any one of these container runtimes installed according to your needs. In the next article, we will be using containerd for our setup.
Types of HA cluster in kubernetes
There are two different configurations (topology) in which we can create a highly available cluster. They have a difference only in their etcd configuration
- Stacked etcd topology: In this topology, the etcd is run on all the master nodes as static pods.
- External etcd topology: In this topology, as you might have guessed, we run the etcd on external nodes to avoid any failure in etcd even if master nodes go down.
For our ease, we will be using the stacked etcd topology in the next article.
Conclusion
That’s it folks this is all the stuff that you need to know before jumping into the hands-on for the cluster creation part 😃
