Kubernetes Operators: Informers vs. reconcile loop

1/3/2022

I recently got started with building a Kubernetes operator. I'm using the Fabric8 Java Kubernetes Client but I think my question is more general and also applies to other programming languages and libraries.

When reading through blog posts, documentation or textbooks explaining the operator pattern, I found there seem to be two options to design an operator:

  1. Using an infinite reconcile loop, in which all corresponding Kubernetes objects are retrieved from the API and then some action is performed.
  2. Using informers, which are called whenever an observed Kubernetes resource changes.

However, I don't find any source discussion which option should be used in which case. Are there any best practices?

-- Sören Henning
fabric8
kubernetes
kubernetes-custom-resources
kubernetes-operator

1 Answer

1/3/2022

You should use both.

When using informers, it's possible that the handler gets the events out of order or even not at all. The former means the handler needs to define and reconcile state - this approach is referred to as level-based, as opposed to edge-based. The latter means reconciliation needs to be triggered on a regular interval to account for that possibility.

The way controller-runtime does things, reconciliation is triggered by cluster events (using informers behind the scenes) related to the resources watched by the controller and on a timer. Also, by design, the event is not passed to the reconciler so that it is forced to define and act on a state.

-- Galletti_Lance
Source: StackOverflow