3.2 Kubernetes Control Plane Request Flow

Kubernetes Control Plane Request Flow is the specific step-by-step path a single request takes as it moves through the control plane, from the moment it arrives at the API server to the moment its effects, if any, propagate outward to controllers and nodes, tracing one concrete request rather than describing the control plane's components in the abstract.

Arrival and Identity Establishment

The Request Reaches the API Server First

Every request, regardless of its origin, whether a human operator's command, a controller's automated call, or a kubelet's status update, is architected to arrive first at the API server, which is the sole entry point through which any interaction with the control plane occurs.

Authentication Attaches an Identity

Immediately upon arrival, the request flow passes through authentication, which attaches a username and group membership to the request based on whatever credential it presented, without which no further stage can meaningfully evaluate the request.

Permission and Policy Evaluation

Authorization Checks the Identity Against RBAC

With an identity attached, the request flow proceeds to authorization, where the identity's username and groups are checked against applicable Role and ClusterRole bindings to determine whether the specific verb and resource combination is permitted.

Admission Applies Further Scrutiny

If authorized, the request flow proceeds through the admission chain, first through mutating plugins that may alter its content, then through validating plugins that make a final accept-or-reject determination based on cluster-specific policy.

Persistence and Acknowledgment

The Request Reaches etcd

Once fully admitted, the request flow reaches the storage layer, where the API server writes the resulting object state to etcd, receiving acknowledgment only once etcd's consensus protocol confirms the write has been durably committed.

The Client Receives a Response

Only after this durable commit does the request flow return a response to the original client, confirming that the change is now part of the cluster's authoritative state.

Propagation to Watchers

Change Events Flow Outward

Once persisted, the request flow does not end at the client response; the change is propagated outward as a watch event, delivered to every controller, scheduler, or other component that has an active watch on the affected resource type.

Reconciliation Begins Downstream

This propagation is what triggers downstream reconciliation: a newly created Pod specification flowing out to the scheduler for placement, or a newly updated Deployment flowing out to its controller for rollout processing, each acting independently upon receiving the same underlying change event.

Request Flow Diagram