Atomic install rollback guarantees under API server contention

Answer

A failed helm install --atomic does not guarantee a clean cluster when the API server is under contention; the release may be left in failed (or pending-install) status with orphaned resources that survived the rollback attempt.

Confirmed facts

• Helm marks the release status as failed (or pending-install) when the install aborts.
• Helm then attempts to delete every resource created during the install; if any delete call fails due to API errors, those resources remain.
• The atomic flag does not retry the cleanup automatically.

Likely explanation

When API server throttling, network partitions, or admission‑webhook timeouts interrupt the deletion phase, Helm cannot finish the rollback. The release stays marked as failed, but the cluster may still contain ConfigMaps, Secrets, Services, etc., that belong to the aborted install.

Steps to verify and recover

1. Check the release status:

   helm get 

2. If status is failed or pending-install, list any remaining resources owned by that release:

   kubectl get all,configmaps,secrets,persistentvolumeclaims -l release= --all-namespaces

3. If the list is not empty, delete them manually or force a Helm uninstall:

   helm uninstall  --wait --timeout 5m

4. Confirm cleanup: run the same kubectl get command again; the output should be empty.
5. After verification, retry the helm install --atomic with optional exponential backoff.

Missing diagnostic detail

To decide whether a simple retry is sufficient, we need to know whether the API server errors are transient or persistent. If errors are ongoing, repeated retries will likely fail again and manual cleanup is required.