Kubernetes Control Plane Boundaries

Kubernetes Control Plane Boundaries is the precise line separating what belongs formally to the control plane, kube-apiserver, etcd, kube-scheduler, kube-controller-manager, from what merely runs near it, communicates with it constantly, or is easily mistaken for part of it, addressing specifically where the control plane's own responsibility ends and an adjacent component's begins, distinct from the broader question of where Kubernetes as a whole ends and external infrastructure begins.

Control Plane vs. Data Plane

The Formal Dividing Line

The control plane's boundary with the data plane is defined precisely by decision versus execution: the control plane decides what should run and where; the kubelet, container runtime, kube-proxy, and CNI plugin, all data plane components, carry that decision out. A component that executes containers, however central to cluster operation, is formally outside the control plane regardless of how tightly it is coupled to it.

The Kubelet's Special Position

The kubelet formally sits exactly at this boundary without crossing it: it reads decisions made by the control plane and reports observations back to it, but it never itself decides where a Pod should run or whether a workload's replica count is correct, keeping it formally on the data-plane side of the line despite running the essential agent that makes control plane decisions actually take effect.

Control Plane vs. cloud-controller-manager

An Adjacent, Not Included, Process

Although cloud-controller-manager formally runs alongside kube-apiserver, etcd, kube-scheduler, and kube-controller-manager, and is frequently deployed on the same machines, its cloud-specific logic is formally treated as adjacent to the control plane's core rather than an inseparable part of it; a cluster can be fully control-plane-complete, and function correctly for on-premises or bare-metal workloads, without running cloud-controller-manager at all.

kubectl -n kube-system get pods -l k8s-app=cloud-controller-manager

Control Plane vs. Addons

Ordinary Workloads, Not Control Plane Members

DNS, metrics aggregation, dashboards, and similar cluster addons formally run as ordinary Kubernetes workloads, scheduled onto nodes like any application, and are therefore outside the control plane's boundary despite their infrastructure role and their conventional placement in the kube-system namespace alongside genuine control plane static Pods.

kubectl -n kube-system get pods -o wide | grep -v "kube-apiserver\|etcd\|kube-scheduler\|kube-controller-manager"

Distinguishing by Function, Not Namespace

Because both true control plane components and many addons commonly share the kube-system namespace, the boundary formally cannot be drawn by namespace membership alone; it must be drawn by function, whether the component participates in exposing the API, persisting state, scheduling, or reconciling core objects, versus whether it merely consumes the API like any other client.

Control Plane vs. Extension Mechanisms

Webhooks and Aggregated APIs as External Participants

Admission webhooks, authentication and authorization webhooks, and aggregated API servers formally participate in control plane request processing, they are consulted during authentication, authorization, or admission, but they remain formally outside the control plane's own boundary, since they run as independently deployed, independently operated processes the control plane merely calls out to.

Control Plane vs. Custom Controllers

Consumers of the Control Plane, Not Members of It

A custom controller managing a Custom Resource Definition, however essential to a cluster's actual operation, formally interacts with the control plane purely as an API client; it is not part of the control plane's own boundary regardless of how central its function is, distinguishing it sharply from kube-controller-manager's built-in loops, which are formally part of the control plane by virtue of being compiled into that specific binary.

kubectl get deployment codartium-operator -n codartium-system

Why Drawing These Boundaries Precisely Matters

Operational and Security Consequences

Correctly identifying the control plane's precise boundary determines which components require the elevated trust, certificates, and network access appropriate to the control plane's sole-gatekeeper role, and which merely need ordinary API client credentials; conflating an addon, a webhook, or a custom controller with the control plane itself risks either granting it privileges it does not need or failing to recognize that it, unlike the true control plane, can be restarted, rescheduled, or scaled without the same foundational consequences.

kubectl get pods -n kube-system -o custom-columns=NAME:.metadata.name,LABELS:.metadata.labels

Why These Distinctions Are Drawn This Way

Defining the control plane's boundary strictly by the specific decision-making, state-persisting, scheduling, and reconciling responsibilities of kube-apiserver, etcd, kube-scheduler, and kube-controller-manager, rather than by deployment location, namespace, or perceived importance, is what keeps the concept precise and useful: it is the boundary that determines exactly which components' failure represents a control-plane-level incident, and exactly which components, however important, are merely clients of it.