How could I differ oldDeployment and newDeployment is the equal

[mingregister]

Suppose I have a controller, which used to control the deployment, such as the following yaml file.

apiVersion: myDeploymentCrontroller.com/v1beta1
kind: MyDeploymentCrontroller
metadata:
  name: myDeploymentCrontroller-sample
  namespace: default
spec:
  image: nginx:alpine
  ports:
    - port: 80

The above yaml file will create a deployment, named myDeploymentCrontroller-sample and with port: 80, image: nginx:alpine (let's call this version1)

After myDeploymentCrontroller created the deployment, somebody modify the deployment with the cmd: kubectl edit deploy myDeploymentCrontroller-sample (let's call this version2)

My question is how could I distinguish version2 and version1 is equal with myDeploymentCrontroller code, so that I can decide whether to call r.Client.Update() method to update the deployment.

[camilamacedo86]

Hi,

1. Reconciliation Triggers: When you use the Kubebuilder/controller-runtime framework to watch a resource, any change to that resource will trigger the reconciliation loop for the controller. This means if somebody modifies the Deployment using kubectl edit, your controller will automatically be notified and the reconciliation will start.

   err := ctrl.NewControllerManagedBy(mgr).
       For(&appsv1.Deployment{}).
       Complete(r)

2. Avoiding Diffing: Generally, controllers shouldn't worry about diffing the old and new versions of resources. The main idea behind Kubernetes controllers is to ensure the current state of the resource matches the desired state. So, your controller should always aim to make the Deployment align with the MyDeploymentController spec, irrespective of the changes made in-between.

3. Owner References: One of the best practices is to set the owner reference of the Deployment to the MyDeploymentController CR. This way, if the Deployment is edited or deleted, Kubernetes garbage collection mechanics can handle it accordingly. Here's a quick example of how you can set the owner reference:

   controllerutil.SetControllerReference(myDeploymentCrontrollerInstance, deployment, r.Scheme)

4. Final Thoughts: It's always essential to ensure the principle of idempotence. Your controller should be designed in such a way that multiple invocations with the same input should produce the same result. This way, even if someone edits the Deployment, your controller will always bring it back to the desired state specified in your custom resource.

In summary, you don't have to compare version1 and version2 manually. The reconciliation loop will ensure your resources' desired state is achieved. Just focus on the desired state, and let Kubernetes handle the rest!

I would either suggest you read the content of the PR https://github.com/kubernetes-sigs/kubebuilder/pull/3596/files I think it will make more clear how the things work.

I hope that answer your question.
So, I am closing this one.
However, if you need please feel free to re-open.