3.8 Kubernetes Control Plane State Flow

Kubernetes Control Plane State Flow is the specific path by which a single piece of cluster state travels from its origin as a durable record in etcd, through the API server's caching layer, and out to every controller and scheduler that needs to observe it, describing the directionality and latency characteristics of this flow rather than the components themselves.

Origin: A Write Committed to etcd

The Only Point Where State Is Created

State flow begins at exactly one point: a write accepted and durably committed by etcd. No other location in the control plane is capable of originating new authoritative state; every other representation of that state elsewhere in the cluster is derived from this single origin.

First Hop: Into the API Server's Cache

Populating the Watch Cache

Once committed, the new state flows first into the API server's own in-memory watch cache, which is architected to hold a continuously updated copy of etcd's data specifically to serve subsequent reads and watch subscriptions without querying etcd directly for each one.

A Necessary Intermediate Stop

This intermediate stop exists because allowing every one of potentially many watchers to query etcd directly would place unsustainable load on it; the API server's cache absorbs that fan-out cost on etcd's behalf.

Second Hop: Out to Informer Caches

Distributed Copies Across Every Watching Component

From the API server's cache, state flows outward through the watch protocol to every component maintaining its own informer cache, be it a controller, the scheduler, or an external client, each independently receiving the same stream of change events and updating its own local copy accordingly.

Fan-Out Without Coordination Between Recipients

This hop is architected as a pure fan-out: the API server does not coordinate delivery order or timing between different recipients, meaning two different controllers may observe the same change at slightly different times relative to one another.

Terminal Hop: Into Reconciliation Decisions

State Flow Concludes in Action

The final hop in this flow is not a data transfer at all but a consequence: once a controller's informer cache reflects the new state, that controller's reconciliation loop is triggered, converting the flow of data into concrete actions taken against the cluster.

Latency Characteristics Along the Flow

Bounded but Non-Zero Propagation Delay

Because each hop involves independent caching and network transmission, the total time between a write committing in etcd and every downstream component acting on it is architected to be bounded but non-zero, meaning components must be designed to tolerate a degree of staleness in what they observe rather than assuming instantaneous propagation.

State Flow Path Diagram