High availability cluster setup in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Kubernetes Control Plane High Availability

Which component is not typically replicated to achieve high availability in a Kubernetes control plane setup?

A Controller Manager

B kubelet

C API Server

D etcd

💡 Hint

Think about which component runs on worker nodes rather than control plane nodes.

The kubelet runs on worker nodes and is not part of the control plane replication. The API Server, etcd, and Controller Manager are control plane components that are replicated for high availability.

💻 Command Output

intermediate

Check etcd Cluster Health in HA Setup

You run the command etcdctl endpoint health on a 3-node etcd cluster. What output indicates all nodes are healthy?

Kubernetes

etcdctl endpoint health

A endpoint https://10.0.0.1:2379 is healthy: successfully committed proposal

B endpoint https://10.0.0.1:2379 is unhealthy: failed to connect

C error: no endpoints found

D endpoint https://10.0.0.1:2379 is healthy: failed to commit proposal

💡 Hint

Healthy means the node successfully processes requests.

The message 'successfully committed proposal' means the etcd node is healthy and responding correctly.

❓ Configuration

advanced

Load Balancer Configuration for HA Kubernetes API Servers

Which load balancer configuration snippet correctly balances traffic to three Kubernetes API servers on port 6443?

A

frontend kubernetes-frontend
  bind *:6443
  default_backend kubernetes-backend
backend kubernetes-backend
  server master1 10.0.0.1:6443
  server master2 10.0.0.2:6443
  server master3 10.0.0.3:6443

B

frontend kubernetes-frontend
  bind *:6443
  default_backend kubernetes-backend
backend kubernetes-backend
  server master1 10.0.0.1:8080 check
  server master2 10.0.0.2:8080 check
  server master3 10.0.0.3:8080 check

C

frontend kubernetes-frontend
  bind *:6443
  default_backend kubernetes-backend
backend kubernetes-backend
  server master1 10.0.0.1:6443 check
  server master2 10.0.0.2:6443 check
  server master3 10.0.0.3:6443 check

D

frontend kubernetes-frontend
  bind *:6443
  default_backend kubernetes-backend
backend kubernetes-backend
  server master1 10.0.0.1:6443 check
  server master2 10.0.0.2:6443
  server master3 10.0.0.3:6443 check

💡 Hint

Health checks help detect unhealthy API servers.

Option C includes health checks on all servers, which is essential for load balancers to route traffic only to healthy API servers.

❓ Troubleshoot

advanced

Diagnosing Kubernetes API Server Failover Issue

In a 3-master HA Kubernetes cluster, the API server on master2 is down. The load balancer still sends traffic to master2, causing failures. What is the most likely cause?

A The load balancer does not have health checks configured for master2

B etcd cluster is unhealthy

C kubelet on master2 is not running

D Controller Manager is not running on master2

💡 Hint

Focus on how the load balancer detects server health.

If the load balancer lacks health checks, it will continue sending traffic to a down API server, causing failures.

🔀 Workflow

expert

Steps to Add a New Master Node to an Existing HA Kubernetes Cluster

What is the correct order of steps to add a new master node to an existing high availability Kubernetes cluster?

A 2,1,3,4

B 1,3,2,4

C 1,2,4,3

D 1,2,3,4

💡 Hint

Think about the dependencies: components must be installed before joining clusters, and load balancer updated last.

First install components, then join etcd, then join control plane, finally update load balancer to route traffic to the new master.