Helm Rollback Troubleshooting

# Basic rollback to previous revision helm rollback my-release # Rollback to specific revision helm rollback my-release 2 # Rollback with wait helm rollback my-release 2 --wait # Rollback with timeout helm rollback my-release 2 --timeout 10m # Rollback with dry-run helm rollback my-release 2 --dry-run # Rollback with force helm rollback my-release 2 --force # Rollback with cleanup on fail helm rollback my-release 2 --cleanup-on-fail # Rollback with no hooks helm rollback my-release 2 --no-hooks # Check rollback status helm status my-release # Verify rollback helm history my-release

# Check release status helm status my-release helm history my-release # Check for pending operations helm list --pending # Fix 1: Wait for operation to complete # Check if operation is still running # Fix 2: Force unlock by deleting release secret kubectl delete secret sh.helm.release.v1.my-release.v1 -n default # Fix 3: Rollback with --force helm rollback my-release 1 --force # Fix 4: Use --cleanup-on-fail helm rollback my-release 1 --cleanup-on-fail # Fix 5: Uninstall and reinstall (last resort) helm uninstall my-release --keep-history helm install my-release ./my-chart

# Check release history helm history my-release # Fix 1: Use a valid revision number helm history my-release helm rollback my-release 2 # Use valid revision # Fix 2: Check history limit helm get metadata my-release | grep history-max # Fix 3: Increase history limit during install/upgrade helm upgrade my-release ./my-chart --history-max 20 # Fix 4: Reinstall if history is lost helm uninstall my-release helm install my-release ./my-chart

# Check release history helm history my-release # Fix 1: Check for failed releases helm list --all helm list --failed # Fix 2: Force delete and reinstall helm uninstall my-release --keep-history helm install my-release ./my-chart # Fix 3: Use a different release name helm install my-release-2 ./my-chart # Fix 4: Restore from backup # Restore release secret from backup kubectl apply -f backup-release-secret.yaml

# Fix 1: Use --force to recreate resources helm rollback my-release 1 --force # Fix 2: Delete conflicting resources kubectl delete deployment my-app --ignore-not-found helm rollback my-release 1 # Fix 3: Use --cleanup-on-fail helm rollback my-release 1 --cleanup-on-fail # Fix 4: Manually rollback resources kubectl apply -f revision-1-manifests.yaml

# View release history helm history my-release # View with more details helm history my-release --max 10 # View history in YAML helm history my-release --output yaml # View history in JSON helm history my-release --output json # View specific revision helm get all my-release --revision 2 # View release status helm status my-release # View release values helm get values my-release --revision 2 # View release manifest helm get manifest my-release --revision 2 # Check history limit helm get metadata my-release | grep history-max # Increase history limit helm upgrade my-release ./my-chart --history-max 20

# Strategy 1: Standard Rollback # Revert to a previous revision helm history my-release helm rollback my-release 2 # Strategy 2: Force Rollback # Use when immutable fields are an issue helm rollback my-release 2 --force # Strategy 3: Cleanup and Rollback # Clean up failed resources before rollback helm rollback my-release 2 --cleanup-on-fail # Strategy 4: Manual Resource Recovery # Reapply manifests from a specific revision helm get manifest my-release --revision 2 > revision-2.yaml kubectl apply -f revision-2.yaml # Strategy 5: Restore from Backup # Restore release secret from backup kubectl apply -f backup-release-secret.yaml # Strategy 6: Uninstall and Reinstall # Last resort: clean install helm uninstall my-release --keep-history helm install my-release ./my-chart # Strategy 7: Use --atomic for Future Upgrades # Prevent needing rollback in the first place helm upgrade my-release ./my-chart --atomic # Strategy 8: Use ArgoCD for GitOps Rollback # Rollback via Git revert git revert HEAD git push # Strategy 9: Manual Rollback with kubectl # Apply previous manifests manually kubectl apply -f previous-deployment.yaml kubectl rollout status deployment/my-app # Strategy 10: Blue-Green Recovery # Switch traffic back to previous version kubectl patch service my-app -p '{"spec":{"selector":{"version":"blue"}}}'

# Prevention 1: Use --atomic for automatic rollback helm upgrade my-release ./my-chart --atomic # Prevention 2: Use --wait for resource readiness helm upgrade my-release ./my-chart --wait # Prevention 3: Use --timeout for sufficient time helm upgrade my-release ./my-chart --timeout 15m # Prevention 4: Test upgrades in staging first helm upgrade my-release ./my-chart --dry-run --debug # Prevention 5: Use --history-max for history retention helm upgrade my-release ./my-chart --history-max 20 # Prevention 6: Backup release secrets kubectl get secret sh.helm.release.v1.my-release.v1 -o yaml > backup.yaml # Prevention 7: Use GitOps for deployments # Rollback is just a Git revert # Prevention 8: Use canary deployments helm upgrade my-release ./my-chart --set canary.enabled=true # Prevention 9: Use blue-green deployments # Two environments for instant switching # Prevention 10: Monitor deployments kubectl rollout status deployment/my-app kubectl get pods -l app=my-app # Prevention 11: Use proper health checks # readinessProbe, livenessProbe # Prevention 12: Use resource limits # Prevent resource exhaustion # Prevention 13: Validate values before upgrade helm lint ./my-chart --strict # Prevention 14: Use values schema validation # values.schema.json # Prevention 15: Test with different value combinations helm template my-release ./my-chart -f values-prod.yaml