Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

GitOps pruning: preview deletions as a separate release action

Last updated: 7 Oct 20266 min read
tutorial
AdvancedBy AITrove Editorial

A bad source path, failed render, renamed resource, or empty target set can make a controller propose a large deletion. The safe review unit is a before-and-after inventory of tracked objects with explicit disposition for persistent data, namespaces, controllers, and shared dependencies. Application deletion and resource pruning may follow different policies, so test both. A protection annotation or disabled-prune setting is a temporary control, not a substitute for understanding who now owns the object.

Operational decision

A warehouse service retires an old worker Deployment but retains its PVC and audit ConfigMap. The release job compares the controller's current resource inventory with the rendered target and lists the three potential removals. The Deployment is approved for deletion after consumers reach zero and queued work is transferred. The PVC remains protected until a restore drill verifies the data export, and the audit ConfigMap moves to a separate owner. In a disposable cluster, change the source path to an empty directory and verify the controller blocks or flags mass pruning; do not enable an allow-empty exception merely to silence the alert. Test whether deleting the parent Application or Kustomization would remove or orphan its resources, and verify what happens to dependents after Kubernetes garbage collection. A resource stuck behind a finalizer requires a separate investigation, not manual finalizer removal as a first response. Record deletion authorization by resource identity, expected owner after change, and a post-sync inventory; a green application status does not prove retained data survived.

Output
Warehouse prune review
Current inventory: Deployment, PVC, audit ConfigMap
Target inventory: PVC, audit ConfigMap under new owner
Delete: Deployment after queue drain
Retain: PVC until restore acceptance
Transfer: audit ConfigMap before old owner deletion
Abort: empty render or unexpected deletion set
Post-check: retained object UIDs and data accessible

Cost and verification

A diff over C current and T target identities is O(C + T) with hashed keys; the expensive part is validating data retention and dependency impact. Keeping obsolete objects indefinitely consumes storage and increases confusion, while automatic deletion without review can make recovery impossible. Measure unexpected prune candidates, protected-resource age, orphaned objects, and post-sync data checks. Require stricter approval for irreversible state than for a stateless Deployment.

Common Mistakes

  • Do not assume an empty render means the service was intentionally removed.
  • Do not rely on a prune exception without a future owner or expiry.
  • Do not remove a finalizer before identifying what cleanup it protects.

Connected lessons

Practice and check

devops
gitops
Storage details