istio: Helm delete does not clean the custom resource definitions
Helm:
Client: &version.Version{SemVer:"v2.10.0-rc.2", GitCommit:"56154102a2f25ebf679c791907fd355bb0377f05", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.10.0-rc.2", GitCommit:"56154102a2f25ebf679c791907fd355bb0377f05", GitTreeState:"clean"}
Istio: 1.0.0
Kubectl:
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-19T00:05:56Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-17T18:43:26Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Following a deletion of Istio 1.0.0 using helm delete --purge
I notice that it leaves the crds as residue and a reinstall causes the error,
Error: customresourcedefinitions.apiextensions.k8s.io "gateways.networking.istio.io" already exists
In Tiller logs, I can see,
[tiller] 2018/08/07 12:07:28 executing 55 post-delete hooks for is
[kube] 2018/08/07 12:07:28 building resources from manifest
[kube] 2018/08/07 12:07:28 creating 1 resource(s)
However, the resources remain,
k get customresourcedefinitions | grep istio
adapters.config.istio.io 1h
apikeys.config.istio.io 1h
attributemanifests.config.istio.io 1h
authorizations.config.istio.io 1h
bypasses.config.istio.io 1h
checknothings.config.istio.io 1h
circonuses.config.istio.io 1h
deniers.config.istio.io 1h
destinationrules.networking.istio.io 1h
edges.config.istio.io 1h
envoyfilters.networking.istio.io 1h
fluentds.config.istio.io 1h
gateways.networking.istio.io 1h
handlers.config.istio.io 1h
httpapispecbindings.config.istio.io 1h
httpapispecs.config.istio.io 1h
instances.config.istio.io 1h
....
Has anyone noticed this with Helm v2.10.0-rc.2
?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 12
- Comments: 37 (20 by maintainers)
Commits related to this issue
- This is a problem that Helm is going to solve going forward, but for now if you use the crd-install hook, then you can only install CRDs, and not update them at any point during a chart lifecycle. Al... — committed to markmandel/agones by markmandel 6 years ago
- This is a problem that Helm is going to solve going forward, but for now if you use the crd-install hook, then you can only install CRDs, and not update them at any point during a chart lifecycle. Al... — committed to markmandel/agones by markmandel 6 years ago
- Remove crd-install hook, as it break CRD updates This is a problem that Helm is going to solve going forward, but for now if you use the crd-install hook, then you can only install CRDs, and not upda... — committed to markmandel/agones by markmandel 6 years ago
- Remove crd-install hook, as it break CRD updates This is a problem that Helm is going to solve going forward, but for now if you use the crd-install hook, then you can only install CRDs, and not upda... — committed to googleforgames/agones by markmandel 6 years ago
That’s right. In
1.0.0
there CRDs were taken out of the Helm management into their own YAML file and we require the users (who install with Helm) to first install that CRDs yaml.Therefore, since they are unmanaged Helm won’t delete them. Similar to the installation the users are expected to delete them by executing
kubectl delete -f install/kubernetes/helm/istio/templates/crds.yaml -n istio-system
.And add this one
Since helm version > 2.10.0 does not require to install Istio’s CRDs on a separate command via kubectl apply, I think it’s fair to expect
helm delete istio --purge
should delete the CRDs without having to explicitly delete them.me, too. I just tested this with 2.10 and 1.0 of istio, same error. did this happen?
Heres a much simplified version of the above for the curious,
I am facing this issue even though I have done: helm del --purge istio kubectl delete -f .\install\kubernetes\istio-demo.yaml kubectl delete -f install/kubernetes/helm/istio/templates/crds.yaml -n istio-system
But, helm install install/kubernetes/helm/istio --name istio --namespace istio-system still gives me Error: release istio failed: customresourcedefinitions.apiextensions.k8s.io “deniers.config.istio.io” already exists
I am on Windows10. istio-1.1.0-snapshot.3 helm-v2.12.0-rc.1-windows-amd64
@nixgadget it works, thank you very much!
because i delete istio failed before(i must use internal hub’s kubectl image repository), i must cleanup the serviceaccount, clusterrole, clusterrolebinding of istio:
Upgrading to helm/tiller 2.12.1 resolved the issue for me as well.
Hey folks,
The Helm upstream recommends letting CRDs leak with the hook policy of
crd-install
. The reason the CRDs should leak is because the human operator should have full control over the deletion of the mesh configuration which is stored in the CRDs. As a result, I am marking this closed as it works as intended. For those folks that need to be able to clean up in their evaluations, there is the documentation here: https://istio.io/docs/setup/kubernetes/helm-install/#uninstallNote the last step:
Cheers -steve
@ymesika what you have stated which reflects in the Istio installation steps (https://istio.io/docs/setup/kubernetes/helm-install/#installation-steps),
is right for
Helm < 2.10.0
versions.What about versions
> 2.10.0
? I was under the impression that withHelm > 2.10.0
there is the possibility to inject crds withcrd-install
hooks and I can see that this is already enabled in Istio 1.0.0.I posted a question on Helm about this as well, https://github.com/helm/helm/issues/4440
upgrading to 2.12.1 and doing
helm reset --force
fixed the issue@CodeJjang Reverting to helm/tiller v2.11.0 (both as the client and in the cluster) resolved this for me – thanks! Is there an issue open in the helm issue tracker? If there is, I’m having a hard time finding it. As of now, the latest release (v2.12.0) of helm/tiller seems quite broken.
I had to install helm v2.11.0, run
helm reset --force
, delete any remaining CRDs, and then install istio via helm as per the docs.@nixgadget the upgrade issue is being worked here: https://github.com/istio/istio/issues/9884
Cheers -steve
Ok peeps, apologies for my silence so far on this thread. I have been sorting out a path for CRDs to work properly in a Helm upgrade scenario. That work is here: https://github.com/istio/istio/pull/10120
It is more important that Helm upgrade work than helm delete --purge work for the case of dangling CRDs. I have commented on several issues with Helm upstream, and the conclusion I am coming to is
crd-install
is not a priority for 2.y series. As Helm is being completely reworked in the 3.y.z series,crd-install
may longer be a solution.In summary,
crd-install
does not work in ahelm upgrade
scenario. It has many negative side effects depending on where you upgraded from and to usingcrd-install
which we are just finding out about now.Since most people on this issue tracker are using Helm 2.10+ with istio 1.0.z, I want to provide you a smooth upgrade experience. I am unclear if the CRDs can be removed in an automated way. They certainly can’t via
helm delete --purge
as they are unmanaged objects. The Helm community is well aware of this limitation and offers no solutions.in the meantime, I’d encourage folks to use the two-step installation/removal process. I believe this causes
crd-install
to be a noop.** Note **
The helm community has indicated the unmanaged resources in CRDs are a conscious choice so that people do not lose their custom resource information during a helm delete --purge. Instead, you have to work a little harder to remove it. This is logically sound, although clearly not ideal for many individuals - especially those doing evaluations.
use caution
If you are in eval, The solution from @AbrahamAlcaina works well enough https://github.com/istio/istio/issues/7688#issuecomment-440243447. Another solution is
kubectl delete -f install/kubernetes/helm/istio/templates/crds.yaml
. Note this will delete all of your existing custom resources, which you may not care about if in an evaluation but certainly care about if your in production.I’d highly recommend against this solution. This will make upgrades very difficult for you in the future.
template “istio.customJob” not defined, how to resolve it?
For anyone wanting to fix this until a permanent fix is being released,