Get reason, why reconciler was called (resource creation / update / deletion?)

[tim-hilt]

Hi there! I'm working on my first project using kubebuilder. The project is amazing and I really like what it's capable of doing. However, I still have trouble getting some basic things done.

For example, right now, I try to make sense of why a certain reconciler was called. Was it, because the resource was created, updated or deleted? I would like to do different things, when different events happen to my resources. Is there a way to find this out?

If not, is there some (common) workaround? I'm thankful for any information and help I'm getting and will happily provide further examples or information for my particular use-case.

If I have the following reconciler, I can work around this, however it feels too implicit and too hacky to me.

func (r *ServiceDescriptorReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    service := &batchv1.ServiceDescriptor{}
    if err := r.Get(context.TODO(), req.NamespacedName, service); err != nil && errors.IsNotFound(err) {
        fmt.Println("Resource was not found -> must have been deleted")
    else {
        fmt.Println("No errors found -> Resource must have been created or updated")
    }
}

Of course I know, that this might be thinking in the wrong direction, given my lacking experience with kubebuilder. So please tell me, if I hopped on the wrong ship there.

[DirectXMan12]

It's generally considered bad practice to do different actions on Create vs Update -- for example, an Update event could appear as a Create due to a re-list. Reconcile should generally observe current state & diff with desired state to figure out what to do.

For delete, you've got two options:

1. You can check for NotFound when you try to get the object as you note above. This is good if you just want to log or something.
2. If you need to consistently perform some action just before deletion (e.g. you want to decommission cloud resources, etc), you can use a finalizer, and look for deletion timestamps instead. This will mean an object cannot be fully deleted until your controller processes the deletion and removes the finalizer.

[tim-hilt]

To give some context: I'm storing each CR in a map resourceMap := make(map[namespacedName]resourceHash), where the resource-hash is calculated on every call to the reconciler. This way, I can reliably detect updates.

to comment on the delete-options:

I previously just checked if errors.IsNotFound(err), which was working the way I expected it to. However after taking another look inside of the kubebuilder-book, I found the way with the finalizer, which I've refactored the code to.

My application just sends some Kafka-messages, whenever the reconciler was called and checking the error instead of using the finalizer makes my code much cleaner. Is there a difference in robustness in option 2 over option 1? If not, I would just check the error and save a few LOC.

[camilamacedo86]

Hi @tim-hilt, I'd recommend you check out the files scaffolded by the new plugin deploy.image/v1-alpha, see: https://github.com/kubernetes-sigs/kubebuilder/blob/master/testdata/project-v3-with-deploy-image/controllers/busybox_controller.go as an example. So, you can check how the finalizer is implemented.

Also, if you see hall to improvements on the docs. Please, feel free to raise a PR against it. Your collaboration is very welcome.

[roopeshsn]

The link you've provided to busybox_controller.go is not working anymore. This might help: https://book.kubebuilder.io/reference/using-finalizers

[camilamacedo86]

Closing since it is answered.