3.9 Kubernetes Control Plane Reconciliation Flow

Kubernetes Control Plane Reconciliation Flow is the specific sequence of steps a single controller executes each time it processes one object, describing the internal control flow, from dequeuing a work item through observing current state, computing a diff, and issuing corrective action, distinct from the outward data flow of state propagating through the cluster.

Dequeue as the Starting Step

Pulling One Item at a Time

Reconciliation flow begins when a worker goroutine dequeues a single item from the controller's work queue, an item that is typically just a reference, such as a namespace and name, rather than the full object itself, deferring the cost of fetching current state to the next step.

Fetch Current State from the Informer Cache

Reading Locally, Not Remotely

Rather than querying the API server directly for the object's current state, the reconciliation flow reads from the controller's own informer cache, which already holds an up-to-date copy synchronized through the watch mechanism, keeping this step fast and independent of API server latency.

Compute the Desired Action

Comparing Spec Against Status

With current state in hand, the reconciliation flow compares the object's spec, representing what should be true, against its status and any related objects, representing what currently is true, computing whatever difference exists between the two.

Deriving a Concrete Set of Changes

This comparison step is architected to produce a concrete plan of action, such as "create two more Pods" or "update this object's status field," rather than a vague notion of misalignment, since the next step requires specific, executable operations.

Apply the Computed Action

Issuing Writes Back Through the API Server

The reconciliation flow's final active step issues the computed changes as API requests back through the API server, which itself commits them to etcd, completing one iteration of the loop.

Requeue on Partial or Failed Completion

If the applied action does not fully resolve the difference, or if the write itself fails, the reconciliation flow concludes by requeuing the same item, subject to whatever backoff policy is configured, ensuring the controller will retry rather than silently abandoning an unresolved reconciliation.

Why This Flow Is Repeated, Not Linear

A Loop, Not a Pipeline with a Defined End

Unlike a one-time data pipeline, this flow is architected to repeat indefinitely for the same object whenever new events arrive or whenever a periodic resync interval elapses, since the underlying assumption is that desired state may change again at any time, requiring the same observe-compare-act sequence to run afresh.

Reconciliation Flow Diagram