Kubernetes Control Plane Components Explained

The Kubernetes Architecture: A High-Level View

At its core, a Kubernetes cluster is a distributed system composed of two main types of machines, or nodes:

1. Control Plane Nodes (formerly Master Nodes): These nodes run the components that collectively form the cluster's "brain." They make global decisions about the cluster (like scheduling applications) and are responsible for detecting and responding to cluster events.
2. Worker Nodes: These are the "muscles" of the cluster. They run the actual applications and workloads you deploy.

This separation of concerns between decision-making (control plane) and execution (worker nodes) is a fundamental design principle that enables Kubernetes to be so scalable and resilient.

To better visualize this, let's start with a short, introductory video.

Now that you have a high-level picture, let's explore each component of the control plane in detail.

The Control Plane Components

The control plane consists of four main services that can run on a single control plane node or be replicated across multiple nodes for high availability.

For a comprehensive overview, I recommend reading the following article. It provides an excellent deep dive into the architecture from a distributed systems perspective, which should align well with your platform engineering background.

Now, let's break down the components.

1. etcd: The Cluster's Source of Truth

Every Kubernetes cluster has an etcd instance. Think of it as the cluster's database or its memory.

• Role: etcd is a consistent and highly-available distributed key-value store used as Kubernetes' backing store for all cluster data.
• Responsibilities:
  • It stores the entire state of the cluster, including the configuration data (e.g., Pod definitions, Deployments, Services) and the runtime state (e.g., which Pod is running on which node, health status).
  • It ensures data consistency across the cluster. etcd uses the Raft consensus algorithm, which guarantees that all control plane nodes have a consistent view of the data, even if some nodes fail. This is crucial for making reliable decisions.

Given your experience with Kafka, you can think of etcd's role as being conceptually similar to the role ZooKeeper plays in managing broker metadata, topic configurations, and consumer offsets in older Kafka setups. It's the central, reliable source of truth for the distributed system.

2. kube-apiserver: The Gateway to the Cluster

The API Server is the front door to the control plane and, by extension, the entire cluster.

• Role: It exposes the Kubernetes API, acting as the central management point.
• Responsibilities:
  • Processes API Requests: Any time you use kubectl, or any other tool interacts with the cluster, it's talking to the API Server.
  • Authentication & Authorization: It validates who is making a request and whether they have permission to perform the requested action.
  • Validation: It validates the syntax and structure of the objects (like a Pod manifest) being created or updated.
  • Orchestration: It's the only component that communicates directly with etcd. All other components must go through the API Server to read or write the cluster state. This centralization ensures consistency and security.

The API Server is stateless, meaning it doesn't store data itself. This allows you to run multiple instances and put them behind a load balancer for high availability.

3. kube-scheduler: The Matchmaker

Once a request to create a Pod is accepted by the API Server and stored in etcd, the Pod exists in the cluster's "desired state," but it isn't running anywhere yet. That's where the Scheduler comes in.

• Role: To assign newly created Pods to a healthy Worker Node that can run them.
• Responsibilities:
  • It continuously "watches" the API Server for Pods that have been created but do not yet have a node assigned.
  • For each Pod, it performs a two-step process:
    1. Filtering: It finds a set of possible nodes that can run the Pod. This involves checking constraints like resource requirements (CPU, RAM), port availability, and whether the node has specific labels.
    2. Scoring: It ranks the suitable nodes based on a set of scoring rules (e.g., picking the node with the least-utilized resources) and picks the one with the highest score.
  • Finally, it informs the API Server of its decision, and the API Server updates the Pod's definition in etcd to include the assigned node's name.

It's important to note: the Scheduler only decides where the Pod should run; it doesn't actually run the Pod.

4. kube-controller-manager: The Reconciliation Engine

The Controller Manager is the component that works tirelessly to make the cluster's actual state match the desired state stored in etcd.

• Role: It runs various "controllers," each responsible for managing a specific aspect of the cluster.
• Responsibilities:
  • Each controller operates on a reconciliation loop (or control loop): it watches the API server for changes to resources it cares about, compares the desired state with the current state, and takes action to correct any discrepancies.
  • Examples of controllers include:
    • Node Controller: Responsible for noticing when nodes go down and taking appropriate action.
    • Replication Controller: Ensures that the specified number of Pod replicas are running at all times.
    • Deployment Controller: Manages rolling updates for applications.

This declarative, self-healing model is one of Kubernetes' most powerful features. You declare what you want (e.g., "I want 3 replicas of my web server"), and the controllers work to make it so. This aligns perfectly with the principles of Infrastructure as Code you're familiar with from using Terraform.

Conclusion

In this lesson, we've unpacked the "brain" of a Kubernetes cluster—the control plane. You now understand the distinct yet collaborative roles of its core components.

Key Takeaways:

• etcd: The distributed, consistent key-value store that acts as the single source of truth for all cluster data.
• API Server: The central gateway that validates and processes all administrative requests, acting as the sole entry point to the cluster's state.
• Scheduler: The intelligent matchmaker that decides which worker node is best suited to run a new Pod based on various constraints.
• Controller Manager: A collection of controllers that run reconciliation loops to continuously drive the cluster's actual state toward the desired state.

Understanding these components is the first and most crucial step in mastering Kubernetes. It provides the "why" behind the commands you'll be running and the YAML files you'll be writing.

In our next lesson, we will shift our focus to the worker nodes and examine the components that bring your applications to life: the kubelet, kube-proxy, and the container runtime.