Kubernetes Control Plane Request Flow

Understanding how Kubernetes control plane processes requests and manages cluster operations efficiently.

Kubernetes Control Plane Request Flow is the exact, ordered sequence a single API request travels through from the moment a client sends it to the moment its effect, if any, becomes visible to the rest of the cluster, tracing the request across process boundaries, from client to load balancer to a specific API server instance, through that instance's internal pipeline, into etcd, and back out again through the watch mechanism to every interested observer.

Client to API Server

Connection Establishment

A client, kubectl, a controller, a kubelet, formally opens a TLS connection to the cluster's API endpoint, which in a highly available deployment resolves to a load balancer that selects one of several API server replicas to actually handle the connection; the client itself has no visibility into or control over which replica is chosen.

client \to load balancer \to one API server replica

kubectl apply -f deployment.yaml

Inside a Single API Server Instance

Authentication

The receiving API server instance formally runs the request through its configured chain of authenticator plugins, client certificate, bearer token, OIDC, in order, stopping at the first one that successfully resolves an identity; failure of every configured authenticator results in immediate rejection before any further processing.

Authorization

With an identity resolved, the request formally passes to the configured authorization chain, typically RBAC, which evaluates whether that identity's bound Roles and ClusterRoles grant the specific verb being requested against the specific resource; a request denied here is rejected before reaching admission control.

Mutating Admission

An authorized request formally proceeds to mutating admission, where built-in mutating controllers and any registered mutating webhooks may modify the object, injecting defaults, labels, or sidecar containers, before the object continues further down the pipeline.

object \to authn \to authz \to mutating admission \to object′

Schema Validation

The (possibly mutated) object is formally validated against its registered OpenAPI schema, rejecting malformed structure or invalid field values before any validating admission logic, specific to policy rather than structure, is evaluated.

Validating Admission

The schema-valid object formally passes through validating admission, built-in validating controllers and registered validating webhooks, any one of which may reject the request outright with an explanatory message.

Persistence and Response

Write to etcd

Once every prior stage has passed, the API server formally serializes the object and writes it to etcd at the appropriate key, receiving confirmation of the write's commit before considering the operation successful, since an uncommitted write formally has not yet taken effect.

etcdctl get /registry/apps/deployments/codartium-team/codartium-api

Response to the Client

Only after the etcd write formally commits does the API server return a success response to the originating client, containing the persisted object, including any system-populated fields such as uid and resourceVersion, that were not present in the client's original request.

response sent \Leftarrow etcd write committed

Propagation to Watchers

Watch Cache Update

Independent of the response already sent to the originating client, the committing API server instance's own watch cache formally observes the new revision via its own etcd watch and updates its in-memory representation of the affected resource collection.

Fan-Out to All Watching Clients

The updated watch cache formally triggers an event delivered to every client, on that same API server instance, currently holding an open watch against the affected resource type, each receiving an ADDED or MODIFIED event carrying the new object state.

etcd commit \to watch cache update \to fan-out to watchers on this replica

Propagation Across Replicas

Clients watching through a different API server replica than the one that handled the original write formally learn of the change through that replica's own independent etcd watch, arriving at a consistent view slightly asynchronously relative to clients watching the replica that processed the write directly.

kubectl get deployments -n codartium-team --watch

Controllers Reacting to the Change

Reconciliation Triggered by the Watch Event

Any controller watching the affected resource type formally receives the same fan-out event as any other client, enqueuing the changed object's key for reconciliation; the controller's subsequent read-modify-write cycle against related objects (creating Pods for a new Deployment, for instance) re-enters this exact same request flow as an entirely new, independent sequence of requests.

kubectl get events --sort-by=.metadata.creationTimestamp -n codartium-team

Why Tracing the Full Flow Matters

Understanding this complete path, client through load balancing, through the internal pipeline of a single API server instance, into etcd, and back out through the watch mechanism to every interested party, is what makes it possible to reason correctly about latency, consistency, and failure behavior at any point in the system, since every visible effect in a Kubernetes cluster ultimately traces back to exactly this sequence having completed successfully.