Kubernetes Control Plane Components

The Big Picture: Control Plane Architecture

At a high level, a Kubernetes cluster consists of two main parts:

1. The Control Plane: Makes all the global decisions about the cluster (e.g., scheduling applications, detecting and responding to events).
2. The Worker Nodes: The machines that run your actual containerized applications.

Today, our entire focus is on the control plane. Think of it as the management headquarters. The components of the control plane work together to maintain the cluster in a desired state, which you, the administrator, define.

A fundamental rule in Kubernetes architecture is that all communication flows through the API Server. No component talks directly to another; they all use the API Server as a central hub. This design is crucial for consistency, security, and extensibility.

The following diagram provides a great visual overview of this architecture, placing the kube-apiserver at the very center of all interactions.

Now, let's break down each of these components in detail.

1. kube-apiserver: The Gateway and Gatekeeper

The kube-apiserver is the heart of the control plane. It exposes the Kubernetes API, making it the front end for all cluster operations. Whether you're using kubectl from your command line, or another component is operating within the cluster, every request to query or modify the cluster's state goes through the API Server.

The API Server is responsible for three critical steps for every incoming request:

1. Authentication: Who are you? It validates the identity of the user or component making the request.
2. Authorization: What can you do? It checks if the authenticated identity has permission to perform the requested action (e.g., create a Pod, delete a Service). This is typically handled by Role-Based Access Control (RBAC), which we will cover in a later module.
3. Admission Control: Is this request valid and allowed? After a request is authenticated and authorized, special plugins called Admission Controllers can intercept it to validate or even modify it before it's persisted. For example, a LimitRanger admission controller ensures a Pod's resource requests don't exceed namespace quotas.

To get a deep, technical understanding of these functions, watch the following segment of the video "Kubernetes Architecture In-Depth". It provides an excellent breakdown of the API server's role, including the communication protocols used within the cluster.

Key Takeaway: The kube-apiserver is the only component that talks to etcd. It validates and processes all requests, then persists the resulting state of the Kubernetes object into the etcd database.

CKA Scenario: If the kube-apiserver fails, you cannot modify the cluster state (e.g., deploy new apps, scale existing ones). The cluster effectively becomes "read-only," though existing workloads will continue to run.

2. etcd: The Source of Truth

etcd is a consistent and highly-available distributed key-value store used as Kubernetes' backing store for all cluster data. It stores the complete state of the cluster at any given point in time, including configuration data, specifications, and the status of running objects.

Think of it as the cluster's "brain" or single source of truth.

• Distributed and Consistent: etcd is designed to be run as a cluster (ideally with an odd number of members, like 3, 5, or 7) to ensure high availability and prevent "split-brain" scenarios. It uses the Raft consensus algorithm to ensure that all members of the etcd cluster agree on the state of the data. As a DevOps engineer, you're likely familiar with the challenges of maintaining state in a distributed system; Raft is the solution etcd employs to solve this.
• Stores State, Doesn't Act: etcd simply stores data. It does not interpret or act on it. Its job is to provide a reliable place for the kube-apiserver to persist state and for other components to watch for changes.

The next segment from the same video explains etcd and the Raft algorithm in detail.

CKA Scenario: The health of etcd is paramount. Corrupt etcd data or loss of quorum in the etcd cluster means the entire Kubernetes control plane goes down. This is why backing up and knowing how to restore etcd is a critical skill for a Kubernetes administrator.

3. kube-scheduler: The Matchmaker

The kube-scheduler has one specific and vital job: it assigns newly created Pods to a suitable Worker Node. It doesn't run the Pod; it only decides which node should run it.

The scheduler continuously watches the API Server for Pods that have no node assigned (spec.nodeName is empty). For each such Pod, it performs a two-step process:

1. Filtering: It finds the set of feasible nodes where the Pod could run. It filters out any nodes that don't meet the Pod's requirements (e.g., insufficient CPU or memory, nodes with taints the Pod doesn't tolerate).
2. Scoring: It ranks the remaining feasible nodes based on a set of priority functions to find the best one. These functions might prioritize nodes with fewer running Pods, or nodes that already have the required container image cached.

Once the scheduler selects a node, it updates the Pod object via the API Server, setting the spec.nodeName field. The kubelet on that specific node then takes over to actually run the Pod.

CKA Scenario: If a Pod is stuck in the Pending state, it's often a scheduling issue. Running kubectl describe pod <pod-name> will show events from the scheduler explaining why it couldn't find a suitable node (e.g., "insufficient cpu").

4. kube-controller-manager: The Watchdog

The kube-controller-manager is a daemon that runs multiple, independent control loops. In Kubernetes, a controller's job is to watch the state of the cluster and make changes to drive the current state towards the desired state.

This concept of a reconciliation loop (observe -> compare -> act) is fundamental to Kubernetes' self-healing nature.

The kube-controller-manager is a single binary that contains many controllers, including:

• Node Controller: Responsible for noticing when nodes go down and marking them as unhealthy.
• Replication Controller / ReplicaSet Controller: Ensures the correct number of Pods are running for a given ReplicaSet. If a Pod dies, this controller creates a new one.
• Deployment Controller: Manages Deployments and orchestrates rolling updates by creating new ReplicaSets.
• Job Controller: Watches for Job objects and ensures the Pods to run those batch tasks are created.

Each controller watches a specific resource through the API Server. When it detects a mismatch between the desired state (e.g., "I should have 3 replicas") and the current state (e.g., "I only have 2"), it takes action by making calls to the API Server (e.g., "create one more Pod").

Putting It All Together

To solidify your understanding, let's trace the lifecycle of creating a Pod. For this, the following article provides a crisp, clear summary of each component's role and a step-by-step walkthrough of a Pod's creation.

Conclusion

Congratulations on completing your first lesson! You've taken a big step towards understanding how Kubernetes works under the hood.

Here are the key takeaways:

• The Control Plane is the decision-making center of the Kubernetes cluster.
• kube-apiserver: The central hub for all communication. It authenticates, authorizes, and validates all requests before persisting them to etcd.
• etcd: The reliable, distributed key-value store that serves as the cluster's single source of truth.
• kube-scheduler: The matchmaker that finds the best node for a Pod based on its requirements and node availability.
• kube-controller-manager: The engine that runs reconciliation loops, constantly working to make the cluster's current state match the desired state you define.

In our next lesson, we will shift our focus from the "brain" to the "muscle" of the cluster: the Worker Node components. You'll learn about kubelet, kube-proxy, and the container runtime, which are the agents responsible for actually running and networking your containers.