KCNA - Kubernetes Fundamentals (44% of the exam) - Section 1.2
Describe the Kubernetes control plane and node components and the role each plays in reconciling cluster state.
kube-apiserver, etcd, kube-scheduler, kube-controller-manager and cloud-controller-manager on the control plane; kubelet, kube-proxy and the container runtime on each node. The reconciliation loop that drives actual state toward desired state is the single most-tested idea in this domain.
kube-apiserveretcdkube-schedulerkube-controller-managerkubeletkube-proxycontrol loop and reconciliation
Practice question for this objective
lock_openFree sampleKubernetes Fundamentalsmedium
In a Kubernetes cluster, several control plane components need to read and update cluster state, yet only one of them communicates directly with the datastore while every other component and every kubectl request is routed through it. Which component fills this central role as the front end of the control plane?
Akube-scheduler, which places Pods onto nodes and therefore mediates every change made to cluster state.
Bkube-controller-manager, which runs the reconciliation loops and so owns direct access to the datastore.
Cetcd, which stores cluster data and serves it straight to kubectl and to each node's kubelet.
Dkube-apiserver, which exposes the Kubernetes API and is the only component that reads from and writes to etcd.check_circle Correct
Identify the kube-apiserver as the control plane front end through which all components and clients access cluster state. The kube-apiserver validates and serves the Kubernetes API and is the sole component that persists objects to and reads them from etcd, so every other component and every client interacts with the cluster only by going through it.
Why A is wrong: Tempting because the scheduler is a genuine control plane component that changes state by binding Pods, but it is narrowly scoped to placement and reads and writes state through the API server rather than being the front end itself.
Why B is wrong: Tempting because controllers constantly drive state changes, but they observe and update objects through the API server and never open a connection to etcd directly.
Why C is wrong: Tempting because etcd does hold the data, but it is the passive backing store, not a front end, and clients such as kubectl and the kubelet never query it directly.
Why D is correct: Correct because the API server is the front end of the control plane: all clients and components talk to it, and it alone persists and retrieves objects from etcd, making it the single hub for cluster state.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
It applies the declared state exactly once when an object is created and then stops watching for any later changes
errorWhy it is wrong: Tempting because creation does trigger a controller, but treating it as a one-off apply ignores the loop that keeps watching and correcting drift over time.
The Container Network Interface (CNI), which standardises how network plugins configure Pod connectivity
errorWhy it is wrong: CNI is a real pluggable interface, which makes it tempting, but it standardises Pod networking rather than how the kubelet drives the container runtime.
kube-apiserver, the front end for the control plane
errorWhy it is wrong: Tempting because every read and write passes through the API server, but it is stateless and merely validates and serves requests; it stores nothing itself and delegates persistence to etcd.