High availability cluster setup in Kubernetes - Step-by-Step Execution

Process Flow - High availability cluster setup

Start: Plan HA Cluster

↓

Provision Multiple Master Nodes

↓

Configure etcd Cluster

↓

Set Up Load Balancer for Masters

↓

Join Worker Nodes to Cluster

↓

Verify Cluster Health & Failover

↓

End: HA Cluster Ready

This flow shows the main steps to set up a Kubernetes high availability cluster, from planning to verifying failover.

Execution Sample

Kubernetes

kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:6443" --upload-certs
kubeadm join LOAD_BALANCER_DNS:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash> --control-plane
kubectl get nodes
kubectl get pods -n kube-system

Commands to initialize HA control plane, join nodes, and check cluster status.

Process Table

Step	Action	Command/Config	Result/Output
1	Initialize first master node with control plane endpoint	kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:6443" --upload-certs	Master node initialized, certificates uploaded, control plane endpoint set
2	Join additional master nodes to control plane	kubeadm join LOAD_BALANCER_DNS:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash> --control-plane	Additional master nodes joined, etcd cluster formed
3	Set up external load balancer pointing to master nodes	Configure load balancer with masters' IPs on port 6443	Load balancer routes API requests to healthy masters
4	Join worker nodes to cluster	kubeadm join LOAD_BALANCER_DNS:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>	Worker nodes joined and ready
5	Verify nodes and pods status	kubectl get nodes kubectl get pods -n kube-system	All nodes Ready, system pods Running
6	Simulate master node failure	Shutdown one master node	Load balancer routes traffic to remaining masters, cluster remains functional
7	Exit	N/A	HA cluster operational with failover

💡 HA cluster setup completes when multiple masters are joined, load balancer routes traffic, and failover works

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 4	Final
Master Nodes	0	1 (initialized)	3 (joined control plane)	3	3 (all active)
Worker Nodes	0	0	0	2 (joined)	2 (all Ready)
Load Balancer	Not configured	Not configured	Configured with 3 masters	Configured	Configured and routing
Cluster Health	Not available	Healthy (single master)	Healthy (HA masters)	Healthy (masters + workers)	Healthy with failover

Key Moments - 3 Insights

Why do we need a load balancer in front of master nodes?

The load balancer distributes API requests to all healthy master nodes, ensuring availability if one master fails. See execution_table step 3 and 6 where load balancer setup and failover are shown.

What happens if a master node goes down?

The load balancer routes traffic to remaining masters, so the cluster stays functional without downtime. This is shown in execution_table step 6.

Why do worker nodes join using the load balancer DNS instead of a single master IP?

Using the load balancer DNS ensures workers can always reach an active master, even if one master fails. Refer to execution_table steps 2 and 4.

Visual Quiz - 3 Questions

Look at the execution table, at which step are additional master nodes joined to the control plane?

A Step 2

B Step 1

C Step 4

D Step 5

💡 Hint

Check the 'Action' column for 'Join additional master nodes' in execution_table.

According to variable_tracker, how many worker nodes are active after step 4?

A 0

B 1

C 2

D 3

💡 Hint

Look at the 'Worker Nodes' row under 'After Step 4' in variable_tracker.

If the load balancer was not configured, what would likely happen during master node failure?

A Cluster continues working without issues

B API requests fail because no failover routing exists

C Worker nodes automatically become masters

D New load balancer is created automatically

💡 Hint

Refer to key_moments about load balancer role and execution_table step 3 and 6.

Concept Snapshot

High Availability Cluster Setup in Kubernetes:
- Use multiple master nodes for control plane redundancy
- Configure an external load balancer to route API requests
- Join worker nodes via load balancer DNS
- Verify cluster health and failover by simulating master failure
- Ensures no single point of failure for control plane

Full Transcript

This visual execution shows how to set up a Kubernetes high availability cluster. First, you initialize the first master node with a control plane endpoint pointing to a load balancer. Then, you join additional master nodes to form an etcd cluster and control plane. Next, you configure an external load balancer to route API requests to all healthy masters. Worker nodes join the cluster using the load balancer DNS to ensure connectivity. Finally, you verify the cluster health by checking nodes and pods status. Simulating a master node failure shows that the load balancer routes traffic to remaining masters, keeping the cluster operational without downtime.

Practice

1. What is the main purpose of setting up a high availability (HA) cluster in Kubernetes?

easy

A. To prevent downtime by having multiple master nodes

B. To reduce the number of worker nodes

C. To speed up pod creation on a single node

D. To disable load balancing between nodes

Solution

1. Step 1: Understand HA cluster purpose

   High availability clusters are designed to avoid downtime by having multiple master nodes so if one fails, others take over.

2. Step 2: Compare options

   Options B, C, and D do not relate to preventing downtime or multiple masters.

3. Final Answer:

   To prevent downtime by having multiple master nodes -> Option A

4. Quick Check:

   HA cluster = multiple masters for uptime [OK]

Hint: HA means multiple masters to avoid downtime [OK]

Common Mistakes:

• Thinking HA reduces worker nodes
• Confusing HA with pod scaling
• Ignoring the role of multiple masters

2. Which of the following is the correct syntax to initialize a Kubernetes HA cluster using kubeadm with a config file named ha-config.yaml?

easy

A. kubeadm create cluster ha-config.yaml

B. kubeadm start --config=ha-config.yaml

C. kubeadm init --config ha-config.yaml

D. kubeadm init ha-config.yaml

Solution

1. Step 1: Recall kubeadm init syntax

   The correct command to initialize a cluster with a config file is kubeadm init --config filename.

2. Step 2: Check options

   kubeadm init --config ha-config.yaml matches the correct syntax. Options A, B, and D use incorrect commands or missing flags.

3. Final Answer:

   kubeadm init --config ha-config.yaml -> Option C

4. Quick Check:

   kubeadm init + --config = correct syntax [OK]

Hint: Use 'kubeadm init --config filename' to start HA cluster [OK]

Common Mistakes:

• Using 'start' instead of 'init'
• Omitting '--config' flag
• Passing config file without flag

3. Given the following HA cluster setup snippet in ha-config.yaml:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
controlPlaneEndpoint: "lb.example.com:6443"
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs

What does the controlPlaneEndpoint specify in this configuration?

medium

A. The IP address of the worker node

B. The port for kubelet communication

C. The DNS name of the pod network

D. The load balancer address for master nodes

Solution

1. Step 1: Understand controlPlaneEndpoint role

   This field defines the address (usually a load balancer) that routes traffic to the master nodes in an HA setup.

2. Step 2: Analyze options

   The load balancer address for master nodes correctly identifies it as the load balancer address. Other options do not relate to controlPlaneEndpoint.

3. Final Answer:

   The load balancer address for master nodes -> Option D

4. Quick Check:

   controlPlaneEndpoint = load balancer address [OK]

Hint: controlPlaneEndpoint points to the HA load balancer [OK]

Common Mistakes:

• Confusing it with worker node IP
• Thinking it is pod network DNS
• Mixing it with kubelet port

4. You tried to join a new master node to your HA cluster using this command:

kubeadm join lb.example.com:6443 --token abcdef.0123456789abcdef --discovery-token-ca-cert-hash sha256:12345

But it failed with an error about missing --control-plane flag. What is the correct fix?

medium

A. Remove the token from the command

B. Add the --control-plane flag to the join command

C. Use kubeadm init instead of join

D. Change the port number to 8080

Solution

1. Step 1: Identify the error cause

   Joining a master node requires the --control-plane flag to indicate it is a control plane node.

2. Step 2: Apply the fix

   Add --control-plane to the join command to fix the error.

3. Final Answer:

   Add the --control-plane flag to the join command -> Option B

4. Quick Check:

   Joining master needs --control-plane flag [OK]

Hint: Joining master nodes requires --control-plane flag [OK]

Common Mistakes:

• Removing token breaks authentication
• Using init instead of join for adding nodes
• Changing port to wrong value

5. You want to set up a Kubernetes HA cluster with 3 master nodes behind a load balancer. Which of the following steps is the correct order to achieve this?

hard

A. Set up load balancer -> Initialize first master with kubeadm and config -> Join other masters with --control-plane -> Join worker nodes

B. Initialize all masters separately -> Set up load balancer -> Join worker nodes

C. Join worker nodes -> Initialize first master -> Set up load balancer -> Join other masters

D. Set up load balancer -> Join worker nodes -> Initialize all masters

Solution

1. Step 1: Set up load balancer first

   The load balancer must be ready to route traffic to masters before initializing the cluster.

2. Step 2: Initialize first master with kubeadm and config

   This creates the cluster control plane and configures the controlPlaneEndpoint.

3. Step 3: Join other masters with --control-plane flag

   Other masters join as control plane nodes to form HA.

4. Step 4: Join worker nodes

   Finally, worker nodes join the cluster to run workloads.

5. Final Answer:

   Set up load balancer -> Initialize first master with kubeadm and config -> Join other masters with --control-plane -> Join worker nodes -> Option A

6. Quick Check:

   Load balancer first, then masters, then workers [OK]

Hint: Load balancer first, then init masters, then join workers [OK]

Common Mistakes:

• Initializing all masters before load balancer
• Joining workers before masters
• Skipping --control-plane flag on masters