Control Plane

A control plane manages the configuration and coordination that determine how a system should operate. It may decide which version should run, where work should be placed, and how much capacity is allocated. The data plane performs the application work governed by those decisions.

Desired state and running state

Suppose a recommendation service should run model v8 on three workers. Recording that desired configuration and coordinating workers belongs to control. Using a running worker to score a customer's products belongs to the data plane. A controller may repeatedly compare desired and observed state and act when they differ — the same reconciliation pattern, applied to configuration rather than to records.

Kubernetes makes the split concrete. The API server exposes the cluster API, etcd stores its API data, the scheduler assigns unscheduled Pods to nodes, and controllers reconcile state through the API. On each node, the kubelet works with the container runtime to keep assigned Pods running; kube-proxy, where used, implements part of service networking. These responsibilities explain why failure of one control component need not immediately stop every running workload.

Read that list and the responsibilities separate cleanly: deciding where a pod should run is control, and handling application requests inside its containers is data-plane work. The kubelet sits between the two. Kubernetes lists it among the node components that run on every node, yet it acts on the Pod specifications assigned to its node to keep those Pods and their containers running. It manages the workload without processing application requests, so where a component runs and which role it plays are separate questions. This illustrates responsibilities; a platform does not need Kubernetes or separate physical machines to use the distinction. A scheduler plus a metadata store plus a worker agent is the same shape whether it is a Kubernetes cluster, a warehouse handing queries to compute clusters, or an orchestrator starting pipeline tasks.

A configuration is not an enforcement result

An access policy may be managed centrally, while the query service enforces it for each request. Updating the policy alone is insufficient if a running service continues using an obsolete decision.

A control-plane outage may stop scheduling and configuration changes while existing requests continue. Data-plane operations that require live control-plane configuration or identity checks can fail sooner; cached configuration can let other operations continue. Recovery from a later node failure or a demand increase may also depend on unavailable control functions. AWS describes this separation as a way to preserve static stability. Document the actual runtime dependencies and isolation boundaries. A shared control-plane outage may affect several tenants, but it does not prove simultaneous data-path failure for all of them. It becomes a cascading failure when reactions such as retries or failover amplify the disruption into additional failures.

References

• Kubernetes: Components
• AWS Well-Architected, Control plane and data plane