Argo CD Self-Heal, Sync Windows and Diffing

Illustration of an animated octopus in an orange lifebuoy and a fish in sunglasses on a raft, both stranded in rough sea waters, viewed between yacht railings under a gloomy sky. Illustration of an animated octopus in an orange lifebuoy and a fish in sunglasses on a raft, both stranded in rough sea waters, viewed between yacht railings under a gloomy sky.

In the previous lesson, we finally deployed our application with the help of Argo CD. But that was only the first deployment, out of many to come. In this lesson, we are going to figure out what happens when we change our Kubernetes configuration, either manually with kubectl or properly, with a Pull Request.

First, let’s see what happens if we go to the Terminal and execute kubectl edit deployments/pgadmin-production. I will change the number of replicas to be just 2 and save it. Now let me head over to Argo CD UI. We almost instantly see, that our application is out of sync. And if we check the diff, we will see that Argo wants to reset replicas back to 3.

Screenshot of a computer screen displaying a diff comparison in Argo CD user interface, showing a change in Kubernetes deployment YAML from 'replicas: 1' to 'replicas: 3'.

Notice that it does not automatically do it for us - we need to click on the Sync button manually. Or, we can also go to App Details, click on Edits, scroll down to Sync Policy section and Enable Auto-Sync. This is not enough, though. With only Auto-Sync enabled, Argo will only automatically apply changes that happened in the repository, but it will not roll back manual changes. To achieve this, we also need to enable Self Heal. Once enabled, Argo CD will get rid of my manual change, and set replicas back to 3, the value that we have in git.

Now let’s see how it works for the proper git-based change. I’ve prepared a pull request, that changes the number of prod replicas to 2. If I merge this Pull Request, Argo CD will instantly apply this change. This is great, but I actually want to see what exactly is going to change before merging this. To do this, I can run Argo CD CLI. There is an app diff command, which accepts new revision as an argument. Argo CD will use this revision to compare with the current state:

argocd app diff pgadmin --revision cargo-100-example

Unsurprisingly, it shows me that the number of replicas will change to be 2. Now, before I finally merge this, I would like to ensure that Argo CD deploys this change only at night. For this, I can use a feature called Sync Windows. For this, I need to go to the Project configuration, and click on Add Sync Window button.

Screenshot of a scheduling configuration interface in Argo CD with sections for minute, hour, day of the month, month, and day of the week, with dropdown selections and a checkbox for enabling manual sync.

I will select all hours between 9pm and 3am and only from Monday to Friday. I want this window to be valid for all applications, namespaces and clusters of this project. After I am done with creating it, let me merge my Pull Request. Now I will head over to the application page in the Argo CD. We can see that it’s out of sync, but due to the sync window, deployment is blocked.

Now I will go back to the window settings and select current time to be inside the window. Now the window is active, and if I go back to the application page, we will see that Argo CD applies the change.

Screenshot of an Argo CD application dashboard showing an application's details with topological view of deployment status including health and synchronization information.

That’s it for this lesson and, actually, that’s it for this lightning course! At this point, you know all the main components of Argo CD and how they are connected together. We’ve deployed an application, and learned how to re-deploy it, as well as how to reconcile our infrastructure with the state in Git.


Here' the same article in video form for your convenience: