<p>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.</p>

<p>I have a pod that's in a CrashLoopBackOff situation as I entered an incorrect port number in the Dockerfile. When I do a <code>kubectl -n dev get pods</code>, I can see it in the crash loop. I tried to kill it with <code>helm delete --purge emails</code> but I get the error <code>Error: unknown flag: --purge</code>. I tried to edit the chart with <code>kubectl edit pod emails -n dev</code>, but I get an error saying that the field cannot be changed.</p>

<p>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 <code>Error: uninstall: Release not loaded: emails: release: not found</code>. I get the same if I try <code>helm uninstall emails</code> or pretty much anything.</p>

<p>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 <code>curl -L https://git.io/get_helm.sh | bash -s -- --version v2.11.0</code> but I can't run <code>helm init</code> and so I'm still on v3.1.0</p>

<p>If I run <code>helm list</code>, I get an empty list. I have 16 running pods I can see through <code>kubectl -n dev get pods</code> but I don't seem to be able to do anything to any of them.</p>

<p>Is this likely to be because my helm client is the wrong version and, if so, how do I roll it back?</p>

<p>Thanks for any suggestions.</p>

<p>EricZ's answer hit the main points, but just to provide some context and recommend a couple of resources — first off, <strong>you can find the binaries for the current v2 release <a href="https://github.com/helm/helm/releases/tag/v2.16.1" rel="nofollow noreferrer">here</a></strong>. Just drop that in your path and everything should be as you left it with all your releases.</p>

<p>As mentioned, the problem is you're trying to query Helm v2 releases with a v3 client<sup>1</sup>. However, Helm v3 was <em>designed</em> 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 <code>PATH</code> — I just <code>alias</code>ed the v2 client to <code>helm2</code>, so e.g., <code>helm2 list</code> would show me all my v2 releases, and <code>helm list</code> the new migrated releases.</p>

<p>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 <em>recommend</em> taking the time to test your migrations on a development cluster for production-critical applications.)</p>

<hr>

<p>When you're ready to migrate... <strong>I'd highly recommend checking out the <a href="https://github.com/helm/helm-2to3" rel="nofollow noreferrer">Helm <code>2to3</code> plugin</a></strong> (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:</p>

<pre class="lang-sh prettyprint-override"><code>$ 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.
[...]
</code></pre>

<p>Hope this helps!</p>

<hr>

<p><sup>1</sup> Check out the documentation <a href="https://helm.sh/docs/faq/#changes-since-helm-2" rel="nofollow noreferrer">here</a> on "changes since Helm 2" for the details. Worth noting in your case:</p>

<ul>
<li>Releases are now scoped to the namespace they're deployed in; to see all releases, use <code>helm list -A</code>.</li>
<li>No need to <code>helm init</code> in Helm v3 — since the v3 client doesn't rely on <code>tiller</code> anymore.</li>
<li>As you noticed — <code>helm delete --purge</code> is now <code>helm uninstall</code> in v3; if you want the v2 functionality of persisting a "deleted" release, use the <code>--keep-history</code> flag.</li>
</ul>
