How Kubernetes Informers Power Real‑Time, Low‑Cost Cluster Event Handling

1. Why Kubernetes Needs Informers

Directly calling client-go methods like clientset.Get() forces every request to hit the API Server, causing three problems: each call contacts the API Server, the API Server experiences huge load, and controllers cannot react in real time, resorting to slow polling.

A typical cluster may have tens of thousands of Pods, hundreds of Controllers, dozens of Operators, and thousands of events per second, making direct API Server access infeasible.

To solve this, Kubernetes introduces the Informer—a specialized event‑transport component that maintains a local cache, reuses a single Watch for many Controllers, and distributes events concurrently.

2. The Real Event Flow from API Server to Your Code

🌐 API Server
   ↓
   👁️ Reflector（creates Watch, watches add/delete/update）
   ↓
   📦 DeltaFIFO（event queue）
   ↓
   🪞 SharedInformer（local cache + event dispatch）
   ↓
   📚 Indexer / Store（in‑memory database）
   ↓
   🔔 ResourceEventHandler（Add / Update / Delete callbacks）
   ↓
   📖 Lister（fast queries from local cache）

This pipeline turns Controllers from passive pollers into event‑driven components, shifts data access from API Server calls to local cache queries, boosts cluster throughput by an order of magnitude, and dramatically reduces API Server pressure.

3. Deep Dive into the Go Implementation

The following code shows a typical Informer setup used in Controllers:

factory := informers.NewSharedInformerFactory(clientset, 0)
podInformer := factory.Core().V1().Pods().Informer()

podInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{
    AddFunc: func(obj interface{}) {
        fmt.Println("[Add]", obj.(*v1.Pod).Name)
    },
})

factory.Start(stopCh)
factory.WaitForCacheSync(stopCh)

Key steps:

NewSharedInformerFactory creates a lazy‑init manager that only constructs an Informer when a resource is first requested, allowing all Pod, Service, Node Informers to share the same Watch and minimizing API Server connections.

Core().V1().Pods().Informer() either creates a new Pod Informer or reuses an existing one.

The Informer internally builds a Reflector , DeltaFIFO , Indexer , and an event processor.

AddEventHandler registers callbacks ( AddFunc, UpdateFunc, DeleteFunc) that serve as the true entry point for handling events.

Start(stopCh) launches the Reflector (starts the Watch), the DeltaFIFO queue, and the processor that dispatches events to the registered handlers.

WaitForCacheSync(stopCh) blocks until the local cache is synchronized, ensuring that Listers can safely read data before the controller begins reconciliation.

4. Why the Indexer (Local Cache) Is So Powerful

The Indexer acts as a tiny in‑memory database with O(1) reads, supports secondary indexes (e.g., nodeName, namespace, UID), allows concurrent access by many Controllers, and generates zero load on the API Server.

Example Lister usage that reads from the cache without contacting the API Server:

pods, _ := lister.Pods("default").List(labels.Everything())

5. How Informer + Lister Enable High‑Performance Controllers

Combined, they provide:

Informer → maintains the cache.

Lister → reads data from the cache.

WorkQueue → orders event processing.

Reconcile → performs the state‑tuning loop.

These three components form Kubernetes' core control loop: event‑driven, cache‑read, and idempotent reconciliation.

6. Summary

Informers are more than listeners; they are engineered, high‑performance caching systems.

SharedInformers enable many consumers to reuse a single Watch, reducing cost.

DeltaFIFO guarantees strict FIFO ordering of events.

Indexer + Lister constitute a local in‑memory database.

Reflector bridges the API Server and the cache.

Events flow from handlers to WorkQueue to Reconcile.

Understanding Informers is essential to grasping the fundamental design that makes Kubernetes scalable and responsive.