A control plane node runs the components that manage a Kubernetes cluster. Worker nodes run application containers and report their status through the kubelet; communication with the control plane goes through the Kubernetes API. Both kinds of node run pods, but their responsibilities differ. section 1.4.1 section 2.1.2
Know the four core components before inspecting or troubleshooting a control plane node:
- kube-apiserver exposes the API and serves as the communication hub for cluster components. section 2.1.2
- kube-controller-manager runs controllers that reconcile current state with desired state, such as restoring a Deployment’s requested replica count. section 1.5
- kube-scheduler assigns pods to nodes, considering available resources and placement rules. section 1.5
- etcd stores cluster configuration data. section 2.1.2
The four core components run as system pods on the control plane node. Their YAML manifests reside in /etc/kubernetes/manifests, where the kubelet picks them up without scheduler placement. The kubelet itself runs as a Linux service on every node. Do not mistake every pod seen on the control plane for a core component: CoreDNS is a plugin, and kube-proxy runs on all nodes. A bootstrap taint prevents ordinary application pods from running on the control plane unless they tolerate it. section 2.1.2 section 2.4 section 9.3.1
kubectl get po -o wide -A --field-selector spec.nodeName=kind-control-planeRun this command in the illustrated kind cluster to list pods assigned to kind-control-plane across namespaces. Check which core system pods appear, then distinguish them from plugins. section 2.1.2
Recover a control plane after a failed upgrade
Start with kubectl -n kube-system get po to check the API server pod. If the API is unavailable, SSH to the control plane node and check systemctl status kubelet, then inspect /etc/kubernetes/manifests. Use crictl ps -a to find exited components and crictl logs <containerid> to identify the failure. In one scenario, the API server log shows a refused connection to an incorrect etcd IP; correcting its manifest and restarting kubelet brings the API server back. Verify API access with kubectl get ns. Continue checking other components: Pending application pods can point to a scheduler failure, whose logs may reveal an incorrect kubeconfig path. section 8.2.5 section 8.2.5
