Core control plane components

What's really being asked

This checks whether you can cleanly separate control plane responsibilities from node-level agents.

The full answer

The kube-apiserver is the front door of the cluster; it validates and serves the REST API and is the only component that reads and writes etcd, so everything goes through it. etcd is a distributed, strongly consistent key-value store that holds the entire cluster state, the single source of truth. The kube-scheduler watches for Pods with no assigned Node and selects a suitable Node based on resources and constraints. The kube-controller-manager runs the built-in controllers, each a reconciliation loop driving actual state toward desired state, such as the node, replicaset, and deployment controllers. The cloud-controller-manager separates cloud-provider-specific logic like load balancers and node lifecycle. Together these form the brain; the node side runs kubelet, kube-proxy, and a container runtime, which are not control plane components.

The mistakes people make

Including kubelet or kube-proxy as control plane components. Saying the scheduler talks directly to etcd. Forgetting etcd entirely. Conflating the controller-manager with the scheduler.

What usually comes next

Which component talks to etcd? What does the scheduler decide versus the kubelet? Why split out the cloud-controller-manager? How is the control plane made highly available?

A concrete example

You apply a Deployment: the request hits the kube-apiserver, which persists the object in etcd. The deployment and replicaset controllers in the controller-manager notice the desired replica count and create Pod objects. The scheduler sees the unscheduled Pods and binds each to a Node. Only then does the node's kubelet, outside the control plane, actually start the containers.