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 — 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. Since it's stateless itself, with all real state living 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. It's built on the Raft consensus algorithm, which gives it strong consistency even when run as a multi-node cluster for high availability. Losing etcd without a backup means losing the cluster's entire state. That's 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. It considers 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. Each is an independent loop, 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. It's 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 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.