Kubernetes Control Plane Composition

Kubernetes Control Plane Composition is the specific inventory of processes that together make up a control plane, and the packaging choices, static Pods, systemd units, or fully managed services, through which those processes are actually run on the machines hosting them. Composition is distinct from architecture: architecture describes how these processes are arranged and replicated across machines, while composition describes exactly which binaries exist and how each one is packaged and started.

The Core Binaries

kube-apiserver

A single Go binary formally implementing the API server; every control plane, regardless of topology or packaging choice, includes at least one running instance of this binary, since no other component can substitute for its role of exposing the API.

etcd

A separate Go binary, not developed as part of the Kubernetes project itself but adopted as its default state store; some managed offerings substitute an alternative consistent store behind the same etcd-compatible API, but the great majority of clusters run etcd itself.

kube-scheduler

A Go binary implementing the scheduling framework; exactly one active instance per configured scheduler profile does the actual scheduling work at any moment, with additional instances, if present, held in standby via leader election.

kube-controller-manager

A Go binary bundling dozens of individual controller loops, Node Controller, ReplicaSet Controller, Endpoints Controller, and many others, into a single compiled process for deployment simplicity, rather than shipping each controller as a separately running binary.

cloud-controller-manager

A separate, optional Go binary, present only where cloud provider integration is configured, isolating cloud-specific control logic, node lifecycle, route configuration, load balancer provisioning, from the core, cloud-agnostic controller-manager binary.

control_plane_binaries:
  - kube-apiserver
  - etcd
  - kube-scheduler
  - kube-controller-manager
  - cloud-controller-manager   # optional

Packaging as Static Pods

The kubeadm Convention

A common packaging choice, used by kubeadm and many self-managed distributions, runs each control plane binary as a static Pod: a Pod definition placed directly in a fixed directory on the control plane machine, read and managed by the local kubelet without any involvement from the API server itself.

ls /etc/kubernetes/manifests/
cat /etc/kubernetes/manifests/kube-scheduler.yaml

Why Static Pods for the Control Plane

Static Pods resolve a bootstrapping dependency: the kubelet needs to start the API server before the API server exists to schedule anything through the ordinary Pod creation path; because static Pods are managed directly by the kubelet reading local files, they can be started without any running API server, breaking the circularity.

Alternative Packaging Choices

systemd Units

Some distributions instead run control plane binaries as ordinary systemd-managed services directly on the host, outside any container runtime, a packaging approach that predates widespread use of static Pods and remains common in certain bare-metal or highly customized deployments.

systemctl status kube-apiserver
journalctl -u kube-apiserver -f

Fully Managed Services

In managed Kubernetes offerings, the exact composition, which binaries, which versions, how they are packaged, is entirely determined and operated by the provider, invisible to the cluster's own users; the customer interacts only with the resulting API endpoint, with no local manifests or systemd units to inspect at all.

kubectl version

Version Composition and Skew

Independent Versioning

Each control plane binary formally carries its own version number, and Kubernetes defines a supported version skew policy governing how far apart these versions may drift, most notably that kube-apiserver must be at a version equal to or newer than kube-controller-manager, kube-scheduler, and kubelet, never older, to guarantee compatibility.

kubectl get --raw /version
kubectl -n kube-system get pods -o jsonpath='{.items[*].spec.containers[*].image}'

Certificates and Configuration Files as Part of Composition

The Supporting File Set

Beyond the binaries themselves, a control plane's composition formally includes a defined set of certificate files (for TLS serving and client authentication), a kubeconfig file for each component's own API access, and configuration files controlling each binary's startup flags, together forming the complete set of artifacts that must exist and be correctly configured for the control plane to function.

ls /etc/kubernetes/pki/
cat /etc/kubernetes/scheduler.conf

Why Composition Is Documented Separately from Architecture

Understanding exactly which binaries exist, how they are versioned relative to one another, and how they are packaged and started on a given machine is a distinct, practical concern from understanding how many replicas of each run and across which failure domains; composition answers "what is actually installed and running," a question that must be answered correctly regardless of which broader architectural topology, single-node, stacked HA, external etcd, a given cluster has chosen.