Kubernetes Master Nodes

This document provides essential guidelines for deploying a Kubernetes cluster, emphasizing the importance of having an odd number of master nodes for high availability. It explains fault tolerance, risks of even-numbered masters, and best practices for production environments. Additionally, it covers the feasibility of having a single master and worker node, highlighting its limitations for production use.

Understanding Kubernetes Master Node Count: Odd vs. Even

In a Kubernetes cluster, master nodes (control plane nodes) manage cluster state, schedule workloads, and ensure high availability.

Why Should Master Nodes Be in an Odd Number?

Kubernetes relies on etcd, a distributed key-value store, for cluster state management. etcd requires a quorum (majority vote) for leader election and decision-making.

  • Having an odd number of master nodes prevents split-brain scenarios and ensures the cluster continues operating even if some nodes fail.

  • For high availability, at least three master nodes are recommended.

Fault Tolerance Formula:

Master Nodes

Failures Tolerated

3

1

5

2

What Happens with an Even Number of Masters?

  • If the number of master nodes is even (e.g., 2 or 4), it increases the risk of a split-brain situation, where etcd cannot reach a majority, making the cluster unstable or unavailable.

  • Two masters are not recommended, as losing one results in quorum loss, preventing decision-making.

Minimum Requirements for a Kubernetes Cluster

  • A high-availability (HA) cluster should have at least 3 master nodes.

  • Each master node runs etcd, the API server, scheduler, and controllers.

  • If using 3 master nodes, at least 3 worker nodes are recommended, though master nodes can schedule workloads in small setups.

Best Practices for Deploying Master Nodes

  • Single Master (1 Node) – Suitable for non-production/testing (no HA).

  • Three Masters (3 Nodes) – Recommended for small to medium HA clusters.

  • Five Masters (5+ Nodes) – Used for large-scale enterprise deployments.

Is It OK to Have One Master and One Worker?

Yes, but it is not recommended for production.

✅ When is it OK?

  • Development/Testing – For local development or testing purposes.

  • Lightweight Workloads – When applications are not critical and do not require high availability.

🚨 Why is it NOT Recommended for Production?

  • No High Availability (HA) – If the master node fails, the cluster becomes completely unavailable.

  • Single Point of Failure – The worker node relies on the master for scheduling, so if the master crashes, new workloads cannot be assigned.

  • No Redundancy – etcd (which stores the cluster state) has no backup, increasing the risk of data loss.

🔹 Recommended Minimum for Production

  • 1 Master, 2+ Workers – Still not HA but better than a single worker.

  • 3 Masters, 2+ Workers – Ensures high availability and fault tolerance.

Last updated

Was this helpful?