Why does helm install fail with "exists and cannot be imported into the current release"?

## What the error is really saying Helm installs and upgrades by rendering the chart into a list of Kubernetes objects and writing each one to the API server. If an object with that group, kind, namespace and name already exists, the API server rejects the create with `AlreadyExists`. Helm does not treat that as fatal on its own. Instead it fetches the live object and asks one narrow question: **does this object already belong to the release I am applying?** That question is answered purely by metadata, never by comparing specs: - the label `app.kubernetes.io/managed-by` must have the exact value `Helm`; - the annotation `meta.helm.sh/release-name` must equal the name of the release; - the annotation `meta.helm.sh/release-namespace` must equal the namespace the release record lives in. All three must hold. When they do, Helm **adopts** the object: it updates it to the rendered spec, and from that revision on the object appears in the release's stored manifest like any other resource. When any one of them is missing or carries a different value, Helm stops and reports `invalid ownership metadata`, listing each key that failed and the value it wanted. ## Why Helm bothers A Helm release is a bookkeeping claim over a set of objects. The release record stores the manifest Helm believes it owns, and `helm uninstall` deletes exactly that set. If Helm silently took over any object whose name happened to match, three bad things follow. A chart could quietly overwrite a resource a person created by hand and tuned. Two releases could both believe they own one object, so uninstalling either would delete a resource the other still needs. And a typo in a release name would be indistinguishable from an intentional takeover. The ownership check makes taking over an existing object a deliberate act rather than an accident. Note that Helm writes this metadata itself on every object it creates as part of a release; a chart does not have to emit it for the mechanism to work. ## The usual causes 1. **Someone applied the object by hand first.** The most common case: a Service, Ingress or ConfigMap was created with `kubectl` months ago, and the chart now renders an object with the same name. 2. **Another release already owns it.** Two charts render the same object name into the same namespace, or a parent chart and a subchart both render it. Here the annotations exist but name the other release, and the message shows the current value rather than a missing key. 3. **The same release name in a different namespace.** The `release-namespace` annotation is the *release's* namespace, not the object's, so a cluster-scoped object such as a ClusterRole rendered by two same-named releases in different namespaces collides on that key alone. 4. **A leftover from a previous release.** An object kept back from an earlier uninstall still carries the old release's annotations, so reinstalling under a different release name now fails. ## How to resolve it The decision is not technical, it is a question of who should own the object from now on: - **Delete it** if it is disposable and the chart can recreate it cleanly. - **Adopt it** by giving the live object the ownership label and the two annotations, then upgrading — a surgical, per-object move that leaves the check guarding everything else. - **Claim it** with the flag that takes ownership as part of the install or upgrade, which skips the check for the whole run. - **Rename it in the chart** so there is no collision at all — usually right when the existing object genuinely belongs to another team. What does *not* fix it is force-replacing: the flags that delete-and-recreate objects, or that override apply conflicts, are about a different problem, and neither bypasses the ownership check. ## What state you are left in On install, Helm reports that the rendered manifests contain a resource that already exists and stops, so it does not create objects behind the failure. The release record is still written with a `failed` status, which is why re-running a plain `helm install` with the same name then complains that the name is already in use; `helm upgrade --install`, or uninstalling the failed release first, is the way forward. On upgrade, the release is marked failed and the previous revision remains the last deployed one.