What is the Kubernetes control plane?
The Kubernetes control plane is the part of a cluster that stores the desired state of every object and continuously works to make the real state match it. It runs five components: the API server, etcd, the scheduler, the controller manager and, on cloud infrastructure, the cloud controller manager. Worker nodes run your containers. The control plane decides what should run where.
What the control plane does
Every change to a cluster goes through the control plane. When you apply a Deployment with three replicas, the control plane records that intent, creates three Pods, picks a node for each one and keeps checking that three are running. If a node dies, the control plane notices the missing Pods and creates replacements on healthy nodes.
This loop of comparing desired state with actual state and correcting the difference is called reconciliation. It is the reason Kubernetes is described as declarative: you state the outcome, and the control plane works out the steps.
Control plane components
| Component | What it does |
|---|---|
kube-apiserver | Serves the Kubernetes API. Every client, including kubectl, the other control plane components and the kubelet on each node, talks to the cluster through it. |
etcd | A consistent key-value store that holds all cluster data. Only the API server reads and writes it directly. |
kube-scheduler | Assigns new Pods to nodes based on resource requests, affinity rules, taints and tolerations. |
kube-controller-manager | Runs the built-in controllers, such as the ones for nodes, Jobs and ReplicaSets, that perform reconciliation. |
cloud-controller-manager | Connects the cluster to a cloud provider’s API, for example to create load balancers or detect deleted virtual machines. |
Control plane vs worker nodes
Worker nodes run the kubelet, a container runtime and a network proxy. They execute Pods but make no cluster-wide decisions. The control plane makes those decisions but, in most production setups, runs no application workloads. Keeping the two apart protects the control plane from noisy workloads and lets each side scale independently.
What happens when the control plane fails
Running Pods keep running. The kubelet on each node keeps its containers alive without the control plane. What stops is everything that needs a decision: no new Pods get scheduled, Deployments cannot scale or roll out, failed Pods are not replaced on other nodes and kubectl requests fail. Autoscaling stops too, because both Pod and node autoscaling depend on control plane decisions. For a timeline of what keeps working, and how a full outage differs from a single site losing its link, see what happens to Kubernetes workloads when the control plane connection drops.
For that reason, production control planes run several replicas across failure domains. etcd needs a majority of its members to accept writes, so clusters use an odd number of members. Three members tolerate one failure. Five members tolerate two.
Who runs the control plane
With self-managed Kubernetes, your team installs, upgrades, backs up and monitors the control plane. With managed Kubernetes, the provider operates it and you work only with the API.
Cloudfleet Kubernetes Engine is a managed service: Cloudfleet runs an isolated control plane for every cluster, on a single availability zone for Basic clusters and replicated across availability zones with an uptime SLA for Pro and Enterprise clusters. See cluster types for the details.