What are the core components of the Kubernetes control plane?

The four control plane components

                     ┌─────────────────────────────────┐
                     │          Control Plane            │
                     │                                    │
  kubectl ────────▶  │   API Server ──▶ etcd              │
                     │       ▲                            │
                     │       │                            │
                     │   Scheduler   Controller Manager    │
                     └─────────────────────────────────┘
                              │ (schedules pods onto, and
                              │  monitors, worker nodes)
                              ▼
                     Worker Nodes (kubelet, kube-proxy, runtime)

API server (kube-apiserver)

The single front door to the cluster — every read and write, whether from kubectl, a controller, or another component, goes through it as a REST API. It validates requests, enforces authentication/authorization (see the RBAC question), and is the only component that talks directly to etcd. Because it's stateless itself (all real state lives in etcd), it can be horizontally scaled behind a load balancer for high availability.

etcd

A distributed, consistent key-value store that holds the entire cluster's state — every object definition, every current status, all of it. It's built on the Raft consensus algorithm, which is what gives it strong consistency guarantees even when run as a multi-node cluster for high availability. Losing etcd (without a backup) means losing the cluster's entire state — which is why etcd backup/restore is a critical, non-optional production practice (see the operations topic).

Scheduler (kube-scheduler)

Watches the API server for newly created Pods that don't yet have a node assigned, and decides which node each should run on — based on resource requests, affinity/anti-affinity rules, taints/tolerations, and other constraints (see the scheduling topic). The scheduler only decides placement; it's the kubelet on the chosen node that actually starts the container.

Controller manager (kube-controller-manager)

Runs a collection of controllers, each responsible for a reconciliation control loop for one type of object — the Deployment controller ensures the right number of Pods exist, the Node controller notices when a node stops responding, and so on. Conceptually, these are many independent loops, each continuously comparing desired state (from etcd, via the API server) against observed actual state, and taking action to close any gap.

Why this separation matters

Each component has one narrow job, and they only communicate through the API server (never directly with each other or with etcd, except the API server itself) — this decoupling is what lets each component be replaced, scaled, or restarted independently without the others needing to know or care, and is a large part of why Kubernetes itself is resilient to individual component failures.

Managed vs. self-hosted

Cloud-managed Kubernetes (EKS, GKE, AKS) runs and maintains the entire control plane for you — you never see or manage etcd, the API server, or the scheduler directly, only interact with the API server's endpoint. Self-hosting a cluster (via kubeadm or similar) means you're responsible for standing up, securing, scaling, and backing up all four of these components yourself.