Module 2

Control plane

Four small components decide everything: the API server, etcd, the scheduler and the controller manager. They never run your application; they only decide and record.

Why it matters. When the cluster misbehaves, the cause is almost always in how requests are admitted, how state is stored in etcd, or which controller is reconciling. Knowing the path makes debugging mechanical.

After this module you can answer

Why does every request go through one front door?
What happens to a request before it is stored?
Why does etcd need an odd number of members?
What is a reconciliation loop and who runs it?
How do the control plane components stay highly available?

What is inside

1API server: the front door

2Authn, authz, admission

3Webhooks

4etcd

5Raft and quorum

6etcd maintenance

7Reconciliation loops

8Leader election

9API server HA

10Extending the API

11Versions and health

12Module infographic

The control plane: the brain that decides and records

Module 2 is the architecture module. We follow a single request from your terminal into the cluster: the API server receives it, checks who you are and whether you may do it, lets policy modify or reject it, stores it in etcd, and then controllers notice the new desired state and act on it.

Keep one rule in mind: nothing but the API server reads or writes etcd. Every other component, from the scheduler to the kubelet, talks to the API server. That single decision explains the security model, the high-availability model and most of the failure modes in this module.

On managed clusters (GKE, EKS, AKS) the provider runs all of this for you across several zones, so you meet it as an endpoint URL. On kubeadm or Rancher clusters you operate it, including etcd backups and certificates. Both cases follow the same mechanics.