Dynamic Informer

How dynamic informers work

A dynamic informer is the Kubernetes watch pattern controllers rely on to observe object changes as they happen. Rather than polling the API server for every state check, the informer keeps a local cache of cluster objects and streams updates into controller logic so reconciliation can react quickly and efficiently.

This model matters because Kubernetes is declarative: the desired state and actual state often diverge briefly, and the informer is part of the mechanism that narrows that gap. When it is healthy, controllers see resource adds, updates, and deletes with low latency and can converge the cluster toward the intended state.

Why informers are central to controller behavior

Informers are not just a performance optimisation. They shape correctness, because a controller usually decides what to do based on what its cache says the cluster looks like. That makes cache freshness, watch continuity, and event delivery semantics part of the controller’s security and reliability envelope.

If the informer lags, stops cleanly in the wrong place, or gets trapped in an error loop, the controller may continue acting on stale objects. In a security-sensitive workload, that can leave revoked permissions, deleted objects, or changed policies effectively invisible for longer than intended.

The same pattern also explains why controller design often includes resyncs, retry handling, and informer health checks. Those safeguards are there to reduce the risk that a temporary watch problem becomes an extended consistency gap.

Failure modes and stale-state consequences

The main failure mode is not usually total outage, but partial loss of truth. A watch can disconnect, an informer can fall behind, or reconciliation can keep using cached state after the real cluster has moved on. That creates a window where the controller’s decisions no longer match current reality.

In practice, stale state can lead to delayed cleanup, missed drift correction, or repeated attempts to reconcile an object that is already gone. In access-sensitive systems, those delays can be enough for unsafe configuration, overexposure, or unintended persistence to remain active.

Because the informer is a bridge between cluster events and control logic, its failure is often exploited indirectly, through the extra time it gives misconfigurations or malicious changes to remain effective before the controller catches up.

Operational characteristics to understand

A dynamic informer usually combines a watch stream with an indexed local store, which gives controllers fast reads and event-driven updates. That design scales better than constant polling, but it also means correctness depends on the watch path, reconnect logic, and cache synchronization staying reliable.

Near-real-time does not mean instant or perfect. There is always some delay between a cluster change and controller reaction, and that delay is acceptable only when the controller’s logic tolerates brief inconsistency. Where a workload needs immediate enforcement, teams should understand the timing assumptions built into the controller.

Risk and Threat Considerations

Dynamic informers create a correctness risk when controllers trust cached state longer than they should. If watch events are delayed, dropped, or repeatedly retried, stale cluster data can leave dangerous conditions in place long enough to be abused or to block needed remediation.

Failure mechanism: An informer outage, lag, or error loop breaks the normal event flow into reconciliation, so the controller keeps acting on outdated cache state while the live cluster has already changed.

Impact: The result can be delayed policy enforcement, missed deletion or revocation, and a larger window for misconfiguration or malicious persistence to remain effective.

Practitioner Guidance

What to watch for: Treat informer health as part of controller health, not as an implementation detail. When reconciliation starts to drift from expected cluster state, look first at watch continuity, cache freshness, and whether the controller is still processing updates normally.

Governance implication: Define who owns informer failure handling, resync behaviour, and stale-state tolerance in controller design reviews. The operational question is not whether informers are useful, but how much inconsistency the surrounding control logic can safely absorb.

Related resources from NHI Mgmt Group

• What is the difference between static and dynamic credentials?
• How do I migrate from static credentials to dynamic credentials?
• When should organizations transition from static to dynamic credentials?
• How should organisations govern non-human identities in dynamic environments?