What is the Kubernetes control plane and what are its core components?

Detailed Answer

The Kubernetes control plane is the collection of processes that govern the entire cluster. It makes global decisions about scheduling, detects and responds to cluster events (such as starting a new pod when a Deployment's replica count is unsatisfied), and serves as the single source of truth for cluster state. In production, control plane components typically run on dedicated nodes (historically called "master nodes") for reliability and security.

Core Components

kube-apiserver is the front door to the cluster. Every interaction, whether from kubectl, the Kubernetes dashboard, or internal components, passes through the API server as RESTful HTTP requests. It validates and processes API objects, persists them to etcd, and serves as the hub through which all other components communicate.

etcd is a distributed, consistent key-value store that holds the entire cluster state. Every object you create, every ConfigMap, every Secret, and every node registration lives in etcd. It uses the Raft consensus algorithm to ensure data consistency across replicas.

kube-scheduler watches for newly created pods that have no node assigned and selects an appropriate node for them to run on. It evaluates resource requirements, affinity/anti-affinity rules, taints and tolerations, and other constraints to make placement decisions.

kube-controller-manager runs a collection of controller loops that watch the current state of the cluster via the API server and work to move it toward the desired state. Examples include the ReplicaSet controller, the Deployment controller, the Node controller, and the Job controller.

cloud-controller-manager is an optional component that integrates with the underlying cloud provider's API. It handles cloud-specific logic such as managing load balancers, routes, and node lifecycle in environments like AWS, GCP, or Azure.

How the Components Interact

The typical flow looks like this:

1. A user runs kubectl apply -f deployment.yaml.
2. The kube-apiserver validates the manifest and persists the Deployment object to etcd.
3. The kube-controller-manager (specifically the Deployment controller) notices the new Deployment, creates a ReplicaSet, and the ReplicaSet controller creates Pod objects.
4. The kube-scheduler detects unscheduled pods and assigns each to a suitable node.
5. The kubelet on each assigned node pulls the container image and starts the pod.

Inspecting Control Plane Components

On a kubeadm-based cluster, control plane components run as static pods in the kube-system namespace:

# List control plane pods
kubectl get pods -n kube-system -l tier=control-plane

# Check API server health
kubectl get --raw='/healthz'

# View component statuses (deprecated but still functional)
kubectl get componentstatuses

You can also inspect the static pod manifests directly on a control plane node:

ls /etc/kubernetes/manifests/
# kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml  etcd.yaml

Each manifest defines the container image, command-line flags, volume mounts for certificates, and resource requests for that component:

# Excerpt from /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
  labels:
    component: kube-apiserver
    tier: control-plane
spec:
  containers:
  - name: kube-apiserver
    image: registry.k8s.io/kube-apiserver:v1.30.0
    command:
    - kube-apiserver
    - --advertise-address=10.0.0.10
    - --etcd-servers=https://127.0.0.1:2379
    - --service-cluster-ip-range=10.96.0.0/12
    - --authorization-mode=Node,RBAC
    - --enable-admission-plugins=NodeRestriction

Production Considerations

In a production environment, you should run at least three control plane nodes to provide high availability. etcd requires an odd number of members (3 or 5) to maintain quorum. The API server is stateless and can be load-balanced, while the scheduler and controller manager use leader election to ensure only one active instance processes work at a time.

Monitoring the control plane is critical. Key metrics to watch include API server request latency, etcd fsync duration, scheduler binding latency, and controller work queue depth. Tools like Prometheus with the kube-state-metrics exporter provide visibility into these metrics.