Drift, pruning, and recovery

Three controls with different effects

Drift is a difference between live resources and the chosen desired revision. Self-healing can restore declared fields changed in the cluster. Pruning removes tracked resources that were removed from desired configuration. Neither is a database restore mechanism.

For the first Application, leave automated synchronization off. Practise a manual diff and sync. Enable self-healing later, after verifying the target namespace and which resources the Application owns. Keep pruning off until you have reviewed exactly which tracked object would be deleted.

Predict the controller's next action

“Git is the source of truth” becomes useful only when you can say which fields and objects it owns. Consider an Application whose committed ConfigMap has colour: blue:

Self-healing is relevant to a live edit when automated sync is configured to correct that drift. Pruning is about removing tracked objects, not merely restoring their field values. Keep those switches separate in your explanation.

For a paper rehearsal, list the two API Deployments and two Services owned by the lab Application, then separately list the databases, emulator and private runtime Secret. If a Git edit removes the Ledger Service, which resources are candidates for pruning? The Service is; the separately managed database is not made an Application resource merely because Ledger uses it. If the Application accidentally included the database, that ownership assumption would change, which is why you inspect the complete render.

Write the prediction before each live rehearsal below. Then compare the actual diff and operation result. The first experiment uses an annotation; the second uses a disposable ConfigMap. Both teach controller behavior without treating application data as disposable configuration.

A harmless drift experiment

Add a learning annotation to the Accounts Pod template through a temporary local edit. Inspect Argo CD's diff, then sync the committed value back. Both edits can create replacement Pods; inspect rollout events and rerun the transaction check. Do not use a password, PVC, or schema as your first drift experiment.

A manual kubectl rollout undo can be overwritten by GitOps reconciliation. A durable release reversal requires correcting Git's desired image and reconciling it. Database changes may not be backward-compatible with the old application; keeping an old image alone is not a complete rollback plan.

Deletion rehearsal

Create a disposable ConfigMap managed by the Application. Remove it from Git and compare behavior with pruning disabled and with an explicitly reviewed manual prune. Do not add databases to this rehearsal. Deleting an Application and deleting its managed resources are different operations; finalizers and cascade settings matter.

Checkpoint: for each change, write the owner, the intended revision, what the controller is allowed to alter, and the recovery step. If a render is empty or broken, resolve it before approving any resulting deletions.

Recovery answer: changing the live image alone may be temporary because the controller still has a different desired image. Correct the selected Git configuration, check schema compatibility, sync, and verify the saved transaction. An empty render is a reason to inspect inputs before deletion, not evidence that every existing resource should disappear. Carry this distinction into the release record in the next bite.

Sources

Automated sync, self-healing, and pruning↗, Application deletion↗.