When to use informers vs. an infinite reconcile loop when building an operator?

[SoerenHenning]

I recently asked the following question on Stack Overflow:

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?

I got a helpful answer saying that both should be used as it is done with kubernetes-sigs/controller-runtime.

Now, I'm curious what's the fabric8 maintainers' view on these things is.

[shawkins]

To reinforce the answer you got over there, the best place to start is on discussions about being edge and level driven - https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/ch01.html

In that view of the world there is level triggering (usually an interval) and edge triggering (an event). Level handling (a full reconcile) and edge handling (processing only what has changed). Edge handling is generally more complicated to implement - you have look at the difference in a resource and determine what changes to make on your primary or dependent resources. Level handling is easier / safer to implement - you simply update all desired state.

The most complex answer is that you don't need to stick to a single approach. You can choose to mix-match as needed:

• level triggering with level handling
• edge triggering with level handling
• edge triggering with edge handling
• edge triggering with edge handling, but also with level triggering / level handling depending upon the possibility of missing or mishandling an event.

Informers are capable of supporting all of these approaches. Alternatively you can certainly start with an infinite loop to implement the first one. It's generally associated with a reconciliation interval - for example every two minutes fully reconcile - and a relatively small number of primary resources. The motivation is that it could be a heavy-weight operation to fully reconcile - considering the state of a lot of dependent resources, status updates, etc. such that performing a reconciliation on every event is not desirable. You can of course still use informers even with this approach to maintain local caches of resource state.

You could also look at the the java-operator-sdk https://github.com/java-operator-sdk/java-operator-sdk - it effectively wraps an informer and provides a lot of functionality on which to build an operator but it's still up to you to choose how the events are processed.

[SoerenHenning]

Thank your very much for the detailed answer. It really helps a lot! I also appreciate the reference to Java Operator SDK. When looking at it last time it didn't seem to be that matured, but looks like there was lots of progress recently.