Helm Atomic Upgrades and External State Persistence

Helm Release Management and External State

The --atomic flag in Helm automates recovery by triggering a rollback if a release fails to reach a ready state within the specified --timeout period. This ensures the Kubernetes cluster returns to the last known stable revision of the chart and values.

However, Helm manages the state of Kubernetes objects but does not have native visibility into external state changes, such as database schema migrations executed via init containers or Job hooks during the upgrade process.

When an atomic rollback occurs, the deployment reverts to the previous image and configuration, but the external data modifications remain applied. This creates a potential mismatch between the deployed application version and the current state of the backend data.

• How does Helm handle the lifecycle of Job hooks during an automatic rollback?
• Is there a documented mechanism to trigger a compensating transaction or a data-level rollback when --atomic reverts the application layer?