I have all sorts of problems with Kubernetes/helm, but I'm really new to it and so I'm not sure what I'm doing at all, despite spending a day trying to work it out.
I have a pod that's in a CrashLoopBackOff situation as I entered an incorrect port number in the Dockerfile. When I do a kubectl -n dev get pods, I can see it in the crash loop. I tried to kill it with helm delete --purge emails but I get the error Error: unknown flag: --purge. I tried to edit the chart with kubectl edit pod emails -n dev, but I get an error saying that the field cannot be changed.
But I can't delete the pod, so I'm not quite sure where to go from here. I've tried without the --purge flag and I get the error Error: uninstall: Release not loaded: emails: release: not found. I get the same if I try helm uninstall emails or pretty much anything.
To get to the crux of the matter, I believe it's because there's been an upgrade to the helm client to version v3.1.0 but the pods were created with v2.11.0. But I don't know how to roll back the client to this version. I've downloaded it via curl -L https://git.io/get_helm.sh | bash -s -- --version v2.11.0 but I can't run helm init and so I'm still on v3.1.0
If I run helm list, I get an empty list. I have 16 running pods I can see through kubectl -n dev get pods but I don't seem to be able to do anything to any of them.
Is this likely to be because my helm client is the wrong version and, if so, how do I roll it back?
Thanks for any suggestions.
EricZ's answer hit the main points, but just to provide some context and recommend a couple of resources — first off, you can find the binaries for the current v2 release here. Just drop that in your path and everything should be as you left it with all your releases.
As mentioned, the problem is you're trying to query Helm v2 releases with a v3 client1. However, Helm v3 was designed to have a separate release "store", allowing a rolling migration of your workloads; this is why the v3 client doesn't "see" v2 releases, and vice versa (i.e. you could, for example, "convert" a v2 release to v3 in a test environment while the deployed one keeps running, verify that everything looks good, and then rollover traffic to the new release and remove the old one). While you're migrating, you'll probably want both versions in your PATH — I just aliased the v2 client to helm2, so e.g., helm2 list would show me all my v2 releases, and helm list the new migrated releases.
That being said — there's nothing preventing you from continuing to use Helm v2 as you have been. If you've already got a working cluster running with v2, it may be worth just sticking to that while you get more familiar with the Kubernetes fundamentals. I was at a meetup with one of the core maintainers of Helm last week, and it sounds like Helm v2 will still be supported for the next year or so; so you've got time. (In fact, they recommend taking the time to test your migrations on a development cluster for production-critical applications.)
When you're ready to migrate... I'd highly recommend checking out the Helm 2to3 plugin (an official plugin maintained by the core Helm team), which was designed to automate migrating v2 releases to v3 in an easy CLI interface. YMMV, but it's worked great for me. In short:
$ helm plugin install https://github.com/helm/helm-2to3
# Note: the following commands can be also be run with the `--dry-run`
# flag to preview their effects.
$ helm 2to3 move config
[...]
[Move Config/confirm] Are you sure you want to move the v2 configuration? [y/N]: y
2020/02/18 23:02:08
Helm v2 configuration will be moved to Helm v3 configuration.
[...]
$ helm 2to3 convert some-helm2-release
2020/02/19 00:30:35 Release "some-helm2-release" will be converted from Helm v2 to Helm v3.
2020/02/19 00:30:35 [Helm 3] Release "some-helm2-release" will be created.
[...]
Hope this helps!
1 Check out the documentation here on "changes since Helm 2" for the details. Worth noting in your case:
helm list -A.helm init in Helm v3 — since the v3 client doesn't rely on tiller anymore.helm delete --purge is now helm uninstall in v3; if you want the v2 functionality of persisting a "deleted" release, use the --keep-history flag.The problem is you mixed helm 2 and helm 3
The release was created by helm v2, so you need helm v2 to delete it, helm v3 won't be able to see releases created by helm v2.
You could do the following
- download helm v2, delete release (I normally have both helm 2/3 in one folder, rename helm v2 to helm2).
- Optional, you can delete tiller, , as helm v3 won't need tiller anymore. just make sure no other release deployed by helm v2
- update your helm chart to use correct port
- use helm v3 deploy your updated chart