Description
Uninstall of the interlink chart can get stuck in uninstalling state because the cleanup Job created during deletion tries to use a ServiceAccount that has already been deleted.
As a consequence:
helm uninstall never completes
- the release remains in
uninstalling
- a subsequent
helm install with the same release name fails with:
Error: INSTALLATION FAILED: cannot re-use a name that is still in use
Observed behavior
After uninstall, the release is still present in Helm history as and at the same time, the cleanup Job and related pods are still present:
job.batch/cleanup Running 0/1 18h
pod/virtual-node-wg-node-7b75f99457-fj7f9 0/2 Unknown 1 18h
pod/virtual-node-wg-node-cleanup-s4zrh 1/1 Running 0 18h
And the pod events show the root problem:
Warning FailedMount pod/virtual-node-wg-node-7b75f99457-fj7f9
MountVolume.SetUp failed for volume "kube-api-access-zz64r" :
failed to fetch token: serviceaccounts "virtual-node-wg" not found
Warning FailedMount pod/virtual-node-wg-node-cleanup-s4zrh
MountVolume.SetUp failed for volume "kube-api-access-dcrrh" :
failed to fetch token: serviceaccounts "virtual-node-wg" not found
Expected behavior
helm uninstall should complete successfully and fully remove the release, so that the same release name can be installed again without manual cleanup.
Actual behavior
The uninstall hook / cleanup Job remains stuck because it references a ServiceAccount that is no longer available. Helm keeps the release in uninstalling, so the release name remains reserved.
Workaround
Manual cleanup is required to unblock the release, for example:
kubectl delete job -n <namespace> <job>-cleanup
helm uninstall -n <namespace> <chart_name> --no-hooks
Description
Uninstall of the
interlinkchart can get stuck inuninstallingstate because the cleanup Job created during deletion tries to use a ServiceAccount that has already been deleted.As a consequence:
helm uninstallnever completesuninstallinghelm installwith the same release name fails with:Observed behavior
After uninstall, the release is still present in Helm history as and at the same time, the cleanup Job and related pods are still present:
And the pod events show the root problem:
Expected behavior
helm uninstallshould complete successfully and fully remove the release, so that the same release name can be installed again without manual cleanup.Actual behavior
The uninstall hook / cleanup Job remains stuck because it references a ServiceAccount that is no longer available. Helm keeps the release in
uninstalling, so the release name remains reserved.Workaround
Manual cleanup is required to unblock the release, for example: