Understanding the Kubernetes Control Plane: A Deep Dive with Examples

The Kubernetes control plane is the central nervous system of a Kubernetes cluster. It manages the cluster’s state, schedules workloads, and ensures applications run as intended. In this blog, we’ll break down the control plane’s components, explain how they interact, and provide practical examples to illustrate their roles.

What is the Kubernetes Control Plane?

The control plane is a collection of components responsible for maintaining the cluster’s desired state. It makes global decisions about the cluster (e.g., scheduling workloads) and responds to cluster events (e.g., scaling applications). The control plane runs on master nodes in traditional setups, though modern distributions often abstract this for simplicity.

Key Components of the Control Plane:

1. kube-apiserver: The cluster’s front-end API.

2. etcd: A distributed key-value store for cluster data.

3. kube-scheduler: Assigns Pods to nodes.

4. kube-controller-manager: Runs core control loops (e.g., node health, replication).

5. cloud-controller-manager: Manages cloud provider integrations (optional).

1. kube-apiserver: The Cluster Gateway

The API Server is the only component that directly interacts with etcd. It exposes the Kubernetes API, which users and tools like kubectl use to manage the cluster.

Example: Creating a Deployment via the API Server

When you run kubectl apply -f deployment.yaml, here’s what happens:

1. kubectl sends the request to the API Server.

2. The API Server validates the request and writes the deployment’s desired state to etcd.

3. The control plane components (e.g., controllers) act on this new state.

    

Sample deployment.yaml:

2. etcd: The Cluster’s Brain

etcd is a distributed, consistent key-value store that holds the cluster’s configuration and state. All components derive their work from etcd’s data.

Example: Viewing etcd Data

While direct interaction with etcd is rare, administrators might use etcdctl for debugging:

Output (simplified):

3. kube-scheduler: The Workload Assigner

The scheduler decides which node should run a Pod based on resource requirements, policies, and node availability.

Example: Scheduling a Pod

1. When a Pod is created (e.g., via a Deployment), the scheduler:

   • Filters nodes that can’t run the Pod (e.g., insufficient CPU).

   • Scores remaining nodes to pick the optimal one.

2. The scheduler binds the Pod to the chosen node by updating etcd.

    

Manual Scheduling (Advanced):

You can bypass the scheduler by specifying nodeName in a Pod spec:

4. kube-controller-manager: The Cluster’s Autopilot

The controller manager runs control loops that watch the cluster’s state and drive it toward the desired state.

Key Controllers:

• Deployment Controller: Ensures the correct number of Pod replicas are running.

• Node Controller: Monitors node status and handles failures.

• ReplicaSet Controller: Maintains Pod replicas (managed by Deployments).

   

Example: Scaling a Deployment

1. Update replicas: 3 to replicas: 5 in your deployment.yaml.

2. The Deployment Controller detects the change and creates 2 new Pods.

3. The ReplicaSet Controller ensures these Pods stay running.

5. cloud-controller-manager: Cloud Integration

This component interacts with cloud provider APIs to manage resources like load balancers, storage volumes, and nodes.

Example: Creating a Cloud Load Balancer

When you create a Service of type LoadBalancer:

The cloud-controller-manager:

1. Talks to the cloud provider (e.g., AWS, GCP).

2. Provisions a load balancer with a public IP.

3. Updates the Service’s status with the IP.

Interaction Between Components: A Step-by-Step Flow

Let’s tie it all together with a real-world example:

1. User Action: kubectl apply -f deployment.yaml.

2. API Server: Validates the request and stores the Deployment in etcd.

3. Deployment Controller (in controller-manager):

   • Detects a new Deployment.

   • Creates a ReplicaSet to manage Pods.

4. ReplicaSet Controller:

   • Seeks to run 3 Pods (per replicas: 3).

   • Creates Pod objects in etcd (but no node assignment yet).

5. Scheduler:

   • Finds unscheduled Pods.

   • Assigns each Pod to a node and updates etcd.

6. kubelet (on worker nodes):

   • Sees Pods assigned to its node.

   • Starts the containers via the container runtime (e.g., Docker).

High Availability (HA) and Best Practices

To ensure reliability, run the control plane in HA mode:

1. etcd Cluster: Use 3+ nodes with distributed consensus.

2. Multiple API Servers: Balance traffic across instances.

3. Leader Election: Schedulers and controller-managers coordinate to avoid conflicts.