# How Kubernetes Control Plane Components Orchestrate Cluster State and Desired Configurations

> Discover how Kubernetes control plane components like kube-apiserver, etcd, kube-scheduler, and kube-controller-manager orchestrate cluster state and configurations. Learn about declarative and eventually-consistent systems.

- Repository: [Arie Bregman/devops-exercises](https://github.com/bregman-arie/devops-exercises)
- Tags: internals
- Published: 2026-02-28

---

**The Kubernetes control plane uses kube-apiserver as the central API gateway, etcd as the distributed data store, kube-controller-manager to enforce desired states through reconciliation loops, and kube-scheduler to assign Pods to optimal nodes, creating a declarative, eventually-consistent system that continuously converges actual cluster state toward user-defined configurations.**

The `bregman-arie/devops-exercises` repository provides comprehensive documentation and hands-on exercises demonstrating how **Kubernetes control plane components** maintain cluster consistency through declarative configuration management. Understanding this architecture is essential for troubleshooting cluster failures, optimizing workload placement, and passing certification exams like the CKA. The repository's [`topics/kubernetes/README.md`](https://github.com/bregman-arie/devops-exercises/blob/main/topics/kubernetes/README.md) file contains authoritative explanations of the internal workflows that keep distributed systems running smoothly.

## The Four Pillars of Control Plane Architecture

### kube-apiserver: The Central API Gateway

All cluster interactions—whether from `kubectl`, internal components, or external controllers—flow through **kube-apiserver**. According to [`topics/kubernetes/README.md`](https://github.com/bregman-arie/devops-exercises/blob/main/topics/kubernetes/README.md) (lines 39-41), this component authenticates users, validates request syntax and policy, and writes the resulting objects (such as Pod or Deployment manifests) into the persistent store. It serves as the sole entry point for the control plane, ensuring that all state changes pass through validation and authorization checks before persistence.

### etcd: The Distributed Source of Truth

**etcd** is a strongly-consistent, distributed key-value store that holds the complete cluster configuration, including objects, secrets, node information, and current controller states. As documented in [`topics/kubernetes/README.md`](https://github.com/bregman-arie/devops-exercises/blob/main/topics/kubernetes/README.md) (lines 45-57), every component that requires up-to-date data establishes watches on etcd through the API server. This design ensures that the entire system reacts to changes atomically, with etcd acting as the single source of truth for both desired configurations and observed cluster states.

### kube-controller-manager: Desired-State Enforcement

The **kube-controller-manager** runs a collection of specialized controllers—including ReplicationController, Deployment, Node, and Service controllers—that continuously reconcile cluster state. Each controller watches etcd for objects it owns, computes the difference between the declared `spec` and the current reality, and issues create, update, or delete operations to drive the system toward the desired configuration. For example, the Deployment controller automatically creates a ReplicaSet when it detects a new Deployment object, then monitors that ReplicaSet to ensure the correct number of Pods exist.

### kube-scheduler: Intelligent Workload Placement

When a newly created Pod lacks a `nodeName` assignment, **kube-scheduler** observes the unassigned workload through the API server. It evaluates resource requests, node selectors, taints and tolerations, and affinity/anti-affinity rules to select the optimal node. As detailed in [`topics/kubernetes/README.md`](https://github.com/bregman-arie/devops-exercises/blob/main/topics/kubernetes/README.md) (lines 2505-2511), the scheduler then binds the Pod to the chosen node and writes this binding back to etcd via the API server, making the decision visible to the kubelet on the target node.

## The Reconciliation Loop in Action

The control plane maintains cluster state through a continuous, eventually-consistent cycle:

1. **User or CI submits a manifest** to kube-apiserver, which validates the request and writes the object to etcd.

2. **Controllers observe the new object** through their watches, compute the required actions to reach the declared spec, and issue API calls to create subordinate resources (such as ReplicaSets or Pods).

3. **Scheduler detects unassigned Pods**, evaluates cluster topology and constraints, selects a suitable node, and writes the binding decision back to etcd.

4. **Kubelet on the target node** watches the API server, notices the assigned Pod, and instructs the container runtime to start the workload.

5. **Status updates** (Pod phase, node health, resource utilization) flow from kubelet to API server to etcd, allowing controllers to react to failures, evictions, or scaling requirements automatically.

This declarative model ensures that the cluster continuously converges on user-defined configurations without manual intervention.

## Practical Validation with devops-exercises

The repository provides concrete examples for observing these interactions. The file [`topics/kubernetes/exercises/kustomize_common_labels/deployment.yml`](https://github.com/bregman-arie/devops-exercises/blob/main/topics/kubernetes/exercises/kustomize_common_labels/deployment.yml) contains sample manifests that trigger the controller manager, while [`topics/kubernetes/exercises/taints_101/exercise.md`](https://github.com/bregman-arie/devops-exercises/blob/main/topics/kubernetes/exercises/taints_101/exercise.md) demonstrates how scheduler decisions respect node constraints.

Inspect control plane health and observe the orchestration workflow:

```bash

# Verify control plane component status

kubectl get componentstatuses

```

Create a Deployment to trigger the reconciliation chain:

```bash
cat > nginx-deploy.yaml <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
EOF
kubectl apply -f nginx-deploy.yaml

```

Monitor the scheduler assigning Pods to nodes:

```bash
kubectl get pods -w

```

Verify the controller manager created the ReplicaSet and observe event history:

```bash
kubectl describe deployment nginx-demo

```

The visual diagram in `topics/kubernetes/images/cluster_architecture_exercise.png` illustrates these relationships between master and worker nodes, while [`topics/kubernetes/CKA.md`](https://github.com/bregman-arie/devops-exercises/blob/main/topics/kubernetes/CKA.md) contains exam-style questions reinforcing these concepts.

## Summary

- **kube-apiserver** serves as the centralized API gateway and validation layer for all cluster operations, persisting validated objects to etcd.
- **etcd** provides the strongly-consistent, distributed storage layer that acts as the single source of truth for both configuration and runtime state.
- **kube-controller-manager** runs reconciliation loops that continuously compare desired state against actual state and execute corrective actions.
- **kube-scheduler** evaluates cluster topology and policy constraints to bind unassigned Pods to optimal nodes, recording decisions through the API server.
- The **declarative reconciliation model** ensures that the cluster automatically recovers from failures, scales workloads, and maintains desired configurations without manual intervention.

## Frequently Asked Questions

### What happens if kube-apiserver becomes unavailable?

If **kube-apiserver** fails, all cluster operations halt because it is the sole entry point for reading and writing state. Controllers, schedulers, and kubelets cannot update their watches or report status, effectively freezing the cluster's ability to reconcile new desired states or recover from failures, though existing workloads continue running on their current nodes.

### How does etcd maintain consistency across control plane nodes?

**etcd** uses the Raft consensus algorithm to replicate data across multiple control plane nodes, ensuring strong consistency and fault tolerance. As long as a majority of etcd nodes remain available, the cluster state remains readable and writable, protecting against split-brain scenarios and data corruption during network partitions.

### Can kube-scheduler be customized for specific workload requirements?

Yes, administrators can extend **kube-scheduler** through custom scheduling profiles, priority classes, and scheduler extender HTTP endpoints. The repository's [`topics/kubernetes/exercises/taints_101/exercise.md`](https://github.com/bregman-arie/devops-exercises/blob/main/topics/kubernetes/exercises/taints_101/exercise.md) demonstrates how to influence scheduling decisions using taints, tolerations, and node affinity rules without modifying the scheduler's core code.

### What is the difference between kube-controller-manager and cloud-controller-manager?

**kube-controller-manager** contains generic controllers applicable to any Kubernetes cluster (like Deployment and ReplicaSet controllers), while **cloud-controller-manager** hosts cloud-provider-specific controllers that integrate with underlying infrastructure APIs for load balancers, node routes, and storage volumes. This separation allows Kubernetes to remain cloud-agnostic while supporting provider-specific optimizations.