# 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:**

<table data-header-hidden><thead><tr><th width="370"></th><th></th></tr></thead><tbody><tr><td>Master Nodes</td><td>Failures Tolerated</td></tr><tr><td>3</td><td>1</td></tr><tr><td>5</td><td>2</td></tr></tbody></table>

#### **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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.openg2p.org/operations/deployment/deployment-guide/kubernetes-master-nodes.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.