<p>You can do this in three steps:</p>
<p><strong>1)Remove the Helm Releases without deleting resources</strong></p>
<p>This can be done by deleting the secrets in which the release is stored. Run:</p>
<pre><code>kubectl get secret | grep helm
</code></pre>
<p>Delete all secrets with the form <code>sh.helm.release.v1.myhelm-1572515128.v1</code> where myhelm is the name of your release.</p>
<p><strong>2)Reduce drift</strong></p>
<p>In Argo CD, look at the diff between your current cluster state and what is to be deployed by Argo CD. Except for annotations and labels related to Argo CD and Helm, decide if you want to keep or revert the difference, change your charts and values accordingly.</p>
<p><strong>3)Synchronize</strong></p>
<p>Finally, synchronize your application. Argo CD labels and annotations will appears. Il you use Helm packages there will still be Helm labels and/or annotations generated when Argo CD run the <code>helm template</code> command.</p>
<p>The potentially problematic part is that the Argo CD application name will be used as the release name of the Helm chart. You can change this by setting the source in the Argo CD application manifest as:</p>
<pre><code>source:
    path: elasticsearch/test
    repoURL: 'https://myrepo.com/helm-config.git'
    targetRevision: HEAD
    helm:
      releaseName: elasticsearch
</code></pre>

CC BY-SA 4.0
2024-06-08T05:29:40.290Z
2024-06-10T13:01:07.420Z
2024-06-10T13:01:07.420Z
Ortomala Lokni
<p>The process to create an ArgoCD application from an existing helm chart release without downtime is well documented e.g. <a href="https://github.com/argoproj/argo-cd/issues/10168" rel="nofollow noreferrer">here</a>:</p>
<blockquote>
<p>Just create an application, you can start with auto-sync turned off to see if it picks up on resources etc. The only thing Argo CD should want to do is add an annotation to resources.</p>
</blockquote>
<p>That said, even after ArgoCD takes over the existing deployments / services / etc, <code>helm ls</code> still lists the existing release even though it is not directly managed by <code>helm</code> anymore.</p>
<p>What is the recommended way to completely clean up helm for the migrated application, as if it had never been managed by it previously? More specifically:</p>
<ul>
<li>the helm releases (that are now managed by ArgoCD applications), so that they do not show up on <code>helm ls</code> anymore</li>
<li>kubernetes object labels and annotations originally added by helm</li>
</ul>
<p>A more philosophical question to ask is whether the clean up is even necessary. Are these leftover annotations harmless? The main reason I want to clean them up is to avoid / reduce confusion, so that other teammates do not mistakenly think the kubernetes resources are managed by helm.</p>
<p>E.g this is what they look like after ArgoCD &quot;adopts&quot; them:</p>
<pre><code>% kubectl describe svc &lt;my service&gt;
[...]
Labels:            app.kubernetes.io/managed-by=Helm
                   argocd.argoproj.io/instance=&lt;my application name&gt;
                   k8s-addon=ingress-nginx.addons.k8s.io
Annotations:       meta.helm.sh/release-name: &lt;my application name&gt;
                   meta.helm.sh/release-namespace: default
[...]
</code></pre>

<kubernetes><helm><kubernetes-helm><argocd>
Migrating from a Helm chart release to an ArgoCD Application
thiagowfx
# Migrating from a Helm chart release to an ArgoCD Application

(Asked by: username_0 on 2024-06-07)

The process to create an ArgoCD application from an existing helm chart release without downtime is well documented e.g. here:

Just create an application, you can start with auto-sync turned off to see if it picks up on resources etc. The only thing Argo CD should want to do is add an annotation to resources.

That said, even after ArgoCD takes over the existing deployments / services / etc, helm ls still lists the existing release even though it is not directly managed by helm anymore.
What is the recommended way to completely clean up helm for the migrated application, as if it had never been managed by it previously? More specifically:

the helm releases (that are now managed by ArgoCD applications), so that they do not show up on helm ls anymore
kubernetes object labels and annotations originally added by helm

A more philosophical question to ask is whether the clean up is even necessary. Are these leftover annotations harmless? The main reason I want to clean them up is to avoid / reduce confusion, so that other teammates do not mistakenly think the kubernetes resources are managed by helm.
E.g this is what they look like after ArgoCD "adopts" them:
% kubectl describe svc 
[...]
Labels:            app.kubernetes.io/managed-by=Helm
                   argocd.argoproj.io/instance=
                   k8s-addon=ingress-nginx.addons.k8s.io
Annotations:       meta.helm.sh/release-name: 
                   meta.helm.sh/release-namespace: default
[...]

**Tags:** kubernetes, helm, kubernetes-helm, argocd


---

## 1 answers

### Answer by username_1 on 2024-06-08. Score: 2 | Accepted answer

You can do this in three steps:
1)Remove the Helm Releases without deleting resources
This can be done by deleting the secrets in which the release is stored. Run:
kubectl get secret | grep helm

Delete all secrets with the form sh.helm.release.v1.myhelm-1572515128.v1 where myhelm is the name of your release.
2)Reduce drift
In Argo CD, look at the diff between your current cluster state and what is to be deployed by Argo CD. Except for annotations and labels related to Argo CD and Helm, decide if you want to keep or revert the difference, change your charts and values accordingly.
3)Synchronize
Finally, synchronize your application. Argo CD labels and annotations will appears. Il you use Helm packages there will still be Helm labels and/or annotations generated when Argo CD run the helm template command.
The potentially problematic part is that the Argo CD application name will be used as the release name of the Helm chart. You can change this by setting the source in the Argo CD application manifest as:
source:
    path: elasticsearch/test
    repoURL: 'https://myrepo.com/helm-config.git'
    targetRevision: HEAD
    helm:
      releaseName: elasticsearch


---

