Last Updated on June 29, 2024 by KnownSense
On the terminology front, we used to call Control Plane Nodes masters. However, Kubernetes now follows the guidelines of the inclusive naming initiative and is removing any potentially harmful language from the project. So, if you see old documents or references to Kubernetes masters, they are talking about control plane nodes.
Control plane nodes are the brain of Kubernetes. They must always be available, making high availability (HA) crucial. Deploying Kubernetes to production without an HA control plane is not recommended.
High Availability (HA) Configuration
- Odd Number of Nodes: For HA, use an odd number of control plane nodes to avoid split-brain scenarios. Typically, three nodes are sufficient, providing a balance between reliability and performance.
Why Odd Numbers Work Better
Quorum: Kubernetes requires a majority (quorum) of nodes to agree on decisions. With an odd number of nodes, one subgroup will always have a majority during a split.
Decision-Making: The subgroup with the majority can continue to operate and elect a new leader if necessary. The minority subgroup knows it does not have a quorum and refrains from making changes, preventing conflicting actions. - Five Nodes: Consider five nodes for increased resilience, but be cautious, as more than five can complicate cluster consensus.
- Avoid Even Numbers: Using an even number of control plane nodes in a Kubernetes cluster can lead to deadlock situations during network failures, commonly referred to as “split-brain” scenarios. A split-brain scenario occurs when a network partition divides the control plane nodes into two equal subgroups, each unable to communicate with the other.
Problem of split-brain: In a network partition, each subgroup of nodes knows that the cluster is split but cannot determine if it has the majority needed to make decisions. This uncertainty can lead to a deadlock, where no subgroup can safely proceed with changes, causing the cluster to enter a read-only state.
Active-Passive Model
Kubernetes uses an active-passive model where only one control plane node (the leader) makes active changes to the cluster at any time. The other nodes (followers) proxy connections to the leader. If the leader fails, a new one is elected automatically.
Running Control Plane Nodes
- Linux Machines: Control plane nodes can be any modern Linux machines, whether on bare metal servers or virtual instances in the cloud.
- Control Plane Services: Each control plane node runs all the necessary services, allowing any node to act as the leader.
Hosted Kubernetes Platforms
In hosted Kubernetes platforms like AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE), the control plane is managed by the cloud provider. This setup offers ease of use and high availability, though it comes at a cost.
Separation of Workloads
It’s generally a good practice to keep user applications off control plane nodes, especially in production environments. This separation helps maintain clean and simple designs and ensures control plane resources are dedicated to Kubernetes operations.
Control Plane Components
- API Server: The gateway to the cluster, handling all communications and exposing a RESTful API over a secure port. Users and applications interact with the cluster through the API server.
- Cluster Store (etcd): Stores the cluster’s configuration and state, including application states. It is critical for cluster operations and must be managed for performance and reliability.
- Controller Manager: Manages various controllers that maintain the desired state of the cluster, each responsible for different aspects (e.g., nodes, deployments, namespaces).
- Scheduler: Assigns tasks to nodes based on various constraints and resource management rules.
Workflow
Commands and queries enter the API server, are authenticated, and then processed. For example, deploying a new application involves writing the desired state to the cluster store and the scheduler distributing tasks to worker nodes. Controllers continuously monitor and reconcile the cluster’s state to match the desired state.
Conclusion
Control plane nodes are essential for Kubernetes operations, ensuring high availability, managing cluster states, and facilitating smooth operation. Hosted services provide a managed environment, simplifying deployment and management at a cost. Understanding and configuring control plane components and ensuring HA are critical for maintaining a robust Kubernetes cluster.