how to distinguish the action when entering the reconcile() function?

[a85302543]

I want to know how to get the API action(( like patch create update...)) apply to any resource watched when triggering the reconcile() function.
I check the ctrl.Request struct, but it just have a simple NamespacedName type.
do kubebuilder support this ?

[camilamacedo86]

Hi @a85302543,

The k8s api raise events when a resource is created, edited and deleted. By Watching Resources we can re-trigger the reconcile to ensure a desired stated on the cluster.

You can define them in the function SetupWithManager that you can find in the controller.go. In the following example, we will be setting up controller Watches in a simplified way which has the controller Builder:

func (r *KindReconciler) SetupWithManager(mgr ctrl.Manager) error {
    return ctrl.NewControllerManagedBy(mgr).
        For(&cachev1alpha1.MyKind{}). // primary ( API defined in the Operator ) to be watched.
        Owns(&appsv1.Deployment{}). // secunary resources to be watched. 
        Complete(r)
}

When developing operators, it is essential for the controller’s reconciliation loop to be idempotent. By following the Operator pattern you will create Controllers which provide a reconcile function responsible for synchronizing resources until the desired state is reached on the cluster. Breaking this recommendation goes against the design principles of controller-runtime and may lead to unforeseen consequences such as resources becoming stuck and requiring manual intervention.

Reconcile()

The reconcile function is responsible for synchronizing the resources and their specifications according to the business logic implemented on them. In this way, it works like a loop, and it does not stop until all conditionals match its implementation. The following is pseudo-code with an example that clarifies it.

reconcile App {
 
   // Check if a Deployment for the app exists, if not create one
   // If has an error, then go to the beginning of the reconcile
   if err != nil {
       return reconcile.Result{}, err 
   } 
    
   // Check if a Service for the app exists, if not create one 
   // If has an error, then go to the beginning of the reconcile
   if err != nil {
       return reconcile.Result{}, err 
   }  
 
   // Looking for Database CR/CRD 
   // Check the Database Deployments Replicas size
   // If deployment.replicas size != cr.size, then update it
   // Then, go to the beginning of the reconcile
   if err != nil {
       return reconcile.Result{Requeue: true}, nil
   }  
   ...
    
   // If it is at the end of the loop, then:
   // All was done successfully and the reconcile can stop  
   return reconcile.Result{}, nil
 
}

The following are a few possible return options to restart the Reconcile:

• With the error: return ctrl.Result{}, err
• Without an error: return ctrl.Result{Requeue: true}, nil
• Therefore, to stop the Reconcile, use: return ctrl.Result{}, nil
• Reconcile again after X time: return ctrl.Result{RequeueAfter: nextRun.Sub(r.Now())}, nil

Note: For more details, check the Reconcile and its Result godoc.

You can check that after you create an API and its controller (kubebuilder create api --group cache --version v1 --kind Memcached --resource=true --controller=true) you will see a TODO in the reconcile where you will fill with your logic.

You can check an example of the Memcached Operator built by following the SDK tutorial (https://sdk.operatorframework.io/docs/building-operators/golang/tutorial/) here: operator-sdk/testdata/go/v3/memcached-operator/.

Building your own operator commonly involves extending the Kubernetes API itself. It is helpful to understand exactly how Custom Resource Definitions interact with the Kubernetes API. Also, the Kubebuilder documentation on Groups and Versions and Kinds may be helpful to better understand these concepts as they relate to operators.

💡Recommended

Avoid a design solution where more than one Kind is reconciled by the same controller
Having many Kinds (such as CRDs) which are all managed by the same controller usually goes against the design proposed by controller-runtime. Furthermore, this might hurt concepts such as encapsulation, the Single Responsibility Principle, and Cohesion. Damaging these concepts may cause unexpected side effects, and increase the difficulty of extending, reusing, or maintaining the operator.

Please, use the issues and the channels if you need additional help.

[a85302543]

thank and it helps，it seems that controller does not concern about the action and just adjust CR to desired status .

[Adembc]

What about ctrl.Result{}, err and ctrl.Result{Requeue: true}, err ? Are they the same?
@camilamacedo86

[camilamacedo86]

No they are not

ctrl.Result{}, err

It will trigger the reconciliation ONLY when an err is not nil

ctrl.Result{Requeue: true}, err

It will trigger the reconciliation always

[Adembc]

In case err is not nil are they same ?
@camilamacedo86

[camilamacedo86]

If err is not nill in both cases it will be requeued.
At the first one ctrl.Result{}, err requeue ONLY if the error is not nil in the second one ctrl.Result{Requeue: true}, err requeue always

[camilamacedo86]

Closing since it is answered.