KCNA — Control Plane Components
Control Plane Components
The Control Plane is the brain of a Kubernetes cluster. It makes all the decisions: where to schedule pods, how to respond to failures, and how to maintain the desired state.
Control Plane Overview
┌───────────────── Control Plane (Master Node) ─────────────────┐
│ │
│ ┌────────────────┐ ┌─────────────────────────┐ │
│ │ kube-apiserver│◄──────►│ etcd │ │
│ │ (Front Door) │ │ (State Store) │ │
│ └───────┬────────┘ └─────────────────────────┘ │
│ │ │
│ ┌────┴────────────────────────┐ │
│ │ │ │
│ ┌──▼──────────────┐ ┌──────────▼──────────┐ │
│ │ kube-scheduler │ │ kube-controller- │ │
│ │ (Pod Placer) │ │ manager (Watcher) │ │
│ └─────────────────┘ └─────────────────────┘ │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ cloud-controller-manager │ (Cloud only) │
│ │ (Cloud Integration) │ │
│ └─────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘
The Four Core Components
1. kube-apiserver
The API server is the front door to the Kubernetes cluster. Every interaction with the cluster goes through it.
| Aspect | Details |
|---|---|
| What it does | Exposes the Kubernetes API; validates and processes all REST requests |
| Who talks to it | kubectl, kubelet, kube-scheduler, kube-controller-manager, external tools |
| Key behavior | It’s the only component that communicates directly with etcd |
| Scaling | Can run multiple instances for high availability |
Communication flow:
kubectl → kube-apiserver → etcd (stores data)
→ scheduler (notifies: "new pod needs scheduling")
→ controller-manager (notifies: "state changed")
Exam tip: If someone asks “Which component do all other components communicate with?” — the answer is always kube-apiserver.
2. etcd
etcd is a distributed key-value store that holds the entire state of the Kubernetes cluster.
| Aspect | Details |
|---|---|
| What it stores | All cluster data: pods, services, deployments, secrets, configs, node info |
| What it is | A consistent, highly available key-value store |
| Key behavior | Only kube-apiserver reads from and writes to etcd directly |
| Failure impact | If etcd fails, the cluster loses its state — no new scheduling, no updates |
| Backup | etcd should be backed up regularly — it’s the most critical data in the cluster |
What etcd does NOT do:
- Does NOT make decisions
- Does NOT schedule pods
- Does NOT communicate with kubelets
- Does NOT run containers
It simply stores data and makes it available to the API server.
3. kube-scheduler
The scheduler decides which worker node a new pod should run on.
| Aspect | Details |
|---|---|
| What it does | Watches for newly created pods with no assigned node and selects a node for them |
| How it decides | Considers: resource requirements, node capacity, affinity/anti-affinity rules, taints/tolerations |
| Key behavior | It does NOT run pods — it only assigns them to nodes. kubelet on the node actually runs the pod. |
| Two-step process | 1. Filtering — eliminate nodes that can’t run the pod. 2. Scoring — rank remaining nodes and pick the best. |
Scheduling flow:
New Pod created (no node assigned)
→ kube-scheduler detects this via API server
→ Filters: "Which nodes CAN run this pod?"
→ Scores: "Which of those nodes is BEST?"
→ Assigns pod to the chosen node
→ kubelet on that node pulls the image and starts the container
4. kube-controller-manager
The controller manager runs controller processes that watch the cluster state and make corrections.
| Aspect | Details |
|---|---|
| What it does | Runs multiple controllers as a single process |
| Key behavior | Each controller watches for specific state changes and acts to reconcile desired vs. actual state |
| Think of it as | A group of “watchers” that keep everything running correctly |
Important controllers:
| Controller | What It Watches | What It Does |
|---|---|---|
| Node Controller | Node health | Detects when nodes go down; marks them NotReady |
| Replication Controller | Pod count | Ensures the correct number of pod replicas are running |
| Endpoints Controller | Services and Pods | Populates endpoint objects (links Services to Pods) |
| Service Account Controller | Namespaces | Creates default service accounts for new namespaces |
| Job Controller | Job objects | Creates pods to run tasks to completion |
Reconciliation loop:
Desired state: 3 replicas
Actual state: 2 replicas (1 crashed)
Controller: "Mismatch detected → create 1 more pod"
Cloud Controller Manager (Optional Component)
The cloud-controller-manager handles cloud-specific logic. It only exists when Kubernetes runs on a cloud provider.
| Aspect | Details |
|---|---|
| What it does | Integrates with cloud provider APIs |
| When it exists | Only in cloud environments (EKS, GKE, AKS) |
| What it manages | Cloud load balancers, cloud node lifecycle, cloud routes |
Exam note: Know that it exists and separates cloud logic from core K8s logic. You don’t need deep knowledge of its internals.
How Components Work Together
Let’s trace what happens when you run kubectl apply -f deployment.yaml:
| Step | Component | Action |
|---|---|---|
| 1 | kubectl | Sends the YAML to the API server |
| 2 | kube-apiserver | Validates the request, stores the Deployment in etcd |
| 3 | kube-controller-manager | Detects the new Deployment, creates ReplicaSet, then creates Pods |
| 4 | kube-scheduler | Detects unscheduled Pods, assigns them to worker nodes |
| 5 | kubelet (on worker) | Gets the assignment, pulls container image, starts the container |
| 6 | kube-apiserver | Updates pod status in etcd as “Running” |
Quick Comparison Table
| Component | Role | Analogy |
|---|---|---|
| kube-apiserver | Gateway for all communication | Reception desk |
| etcd | Stores all cluster state | Filing cabinet |
| kube-scheduler | Assigns pods to nodes | Job placement office |
| kube-controller-manager | Watches and corrects state | Quality control team |
| cloud-controller-manager | Cloud-specific integration | Cloud vendor liaison |
Key Takeaways for the Exam
- kube-apiserver is the single entry point — all components and users communicate through it
- etcd stores the entire cluster state — losing it means losing the cluster
- kube-scheduler only decides WHERE pods run — it doesn’t start them
- kube-controller-manager runs reconciliation loops that fix state drift
- Only the API server talks to etcd directly
- The cloud-controller-manager only exists in cloud environments
What’s Next?
Now let’s look at the other side — the worker nodes where your applications actually run.
