Designing a target reconciliation loop
Now that we have defined our Operator's UI by designing a CRD to represent it in the cluster and itemized the Operand resources that it will manage, we can move on to the core logic of the Operator. This logic is nestled within the main reconciliation loop.
As described in earlier chapters, Operators function on the premise of reconciling the current state of the cluster with the desired state set by users. They do this by periodically checking what that current state is. These checks are usually triggered by certain events that are related to the Operand. For example, an Operator will monitor the Pods in its target Operand namespace and react to the creation or deletion of a Pod. It is up to the Operator developers to define which events are of interest to the Operator.
Level- versus edge-based event triggering
When an event triggers the Operator's reconciliation loop, the logic does not receive the context of the whole event...
