The Kubernetescontrol planeis the set of components responsible for makingcluster-wide decisions(like scheduling) and detecting and responding to cluster events (like starting new Pods when they fail). In upstream Kubernetes architecture, the canonical control plane components includekube-apiserver,etcd,kube-scheduler, andkube-controller-manager, and—when running on a cloud provider—thecloud-controller-manager. That makes optionBthe correct answer:cloud-controller-manageris explicitly a control plane component that integrates Kubernetes with the underlying cloud.
The cloud-controller-manager runs controllers that talk to cloud APIs for infrastructure concerns such as node lifecycle, routes, and load balancers. For example, when you create a Service of type LoadBalancer, a controller in this component is responsible for provisioning a cloud load balancer and updating the Service status. This is clearly control-plane behavior: reconciling desired state into real infrastructure state.
Why the others are not control plane components (in the classic classification):kubeletis anode component(agent) responsible for running and managing Pods on a specific node.kube-proxyis also anode componentthat implements Service networking rules on nodes.CoreDNSis usually deployed as a cluster add-on for DNS-based service discovery; it’s critical, but it’s not a control plane component in the strict architectural list.
So, while many clusters run CoreDNS in kube-system, the Kubernetes component that is definitively “part of the control plane” among these choices iscloud-controller-manager (B).
=========
