38

I have tried to run Helm for the first time. I am having deployment.yaml, service.yaml and ingress.yaml files alongwith values.yaml and chart.yaml.

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: abc
  namespace: xyz
  labels:
    app: abc
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: abc
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          ports:
            -
              containerPort: 8080

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: abc
  labels:
    app.kubernetes.io/managed-by: {{ .Release.Service }}
  namespace: xyz
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: {{ .Values.service.sslCert }}
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8080
    - name: http
      protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
  selector:
    app: abc

ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: "haproxy-ingress"
  namespace: xyz
  labels:
    app.kubernetes.io/managed-by: {{ .Release.Service }}
  annotations:
    kubernetes.io/ingress.class: alb

From what I can see I do not think I have missed putting app.kubernetes.io/managed-by but still, I keep getting an error:

rendered manifests contain a resource that already exists. Unable to
continue with install: Service "abc" in namespace "xyz" exists and
cannot be imported into the current release: invalid ownership
metadata; label validation error: missing key
"app.kubernetes.io/managed-by": must be set to "Helm"; annotation
validation error: missing key "meta.helm.sh/release-name": must be set
to "abc"; annotation validation error: missing key
"meta.helm.sh/release-namespace": must be set to "default"

It renders the file locally correctly.

helm list --all --all-namespaces returns nothing. Please help.

Rico
  • 58,485
  • 12
  • 111
  • 141
harry123
  • 760
  • 1
  • 7
  • 22
  • do you have a link to the helm chart you are using? – Rico Jul 18 '20 at 04:41
  • For those coming across this: https://jacky-jiang.medium.com/import-existing-resources-in-helm-3-e27db11fd467 may be useful! – btown Aug 25 '22 at 00:47

7 Answers7

37

You already have some resources, e.g. service abc in the given namespace, xyz that you're trying to install via a Helm chart.

Delete those and install them via helm install.

$ kubectl delete service -n <namespace> <service-name>
$ kubectl delete deployment -n <namespace> <deployment-name>
$ kubectl delete ingress -n <namespace> <ingress-name>

Once you have these resources deployed via Helm, you will be able to perform helm update to change properties.

Remove the "app.kubernetes.io/managed-by" label from your yaml's, this will be added by Helm.

Frederik Struck-Schøning
  • 12,981
  • 8
  • 59
  • 68
Kamol Hasan
  • 12,218
  • 1
  • 37
  • 46
  • 1
    `helm update` or `helm install`? Further, if I change the code and have the docker image, all I need to do is `helm upgrade -f values.yaml --set image.tag `? – harry123 Jul 18 '20 at 05:00
  • when you're deploying for the first time, `helm install`. For making changes to the existing chart, use `helm update`. For your case, clean up the resources and install it via helm again. – Kamol Hasan Jul 18 '20 at 05:04
  • 2
    It should be `helm upgrade` to deploy the helm templates. Add the `--install` option to run an install if a release by this name doesn't already exist. This applies to helm versions 3+. – alltej Apr 13 '21 at 16:15
27

The error below is quiet common:

 label validation error: missing key "app.kubernetes.io/managed-by":
 must be set to "Helm"; annotation validation error: missing key
 "meta.helm.sh/release-name": must be set to ..

So I'll provide a bit longer explanation and also a context to the topic.


What happend?

It seems that you tried to create resources that were already exist and created outside of Helm (probably with kubectl).

Why Helm throw the error?

Helm doesn't allow a resource to be owned by more than one deployment.

It is the responsibility of the chart creator to ensure that the chart produce unique resources only.

How can you solve this?

Option 1 - Follow the error message and add the meta.helm.sh annotations:

As can be describe in this PR: Adopt resources into release with correct instance and managed-by labels

Helm will no longer error when attempting to create a resource that already exists in the target cluster if the existing resource has the correct meta.helm.sh/release-name and meta.helm.sh/release-namespace annotations, and matches the label selector app.kubernetes.io/managed-by=Helm.
This facilitates zero-downtime migrations to Helm 3 for managing existing deployments, and allows Helm to "adopt" existing resources that it previously created.

(*) I think that the meta.helm.sh scope is a less common approach today.

Option 2 - Add the app.kubernetes.io/instance label:

As can be seen in different Helm chart providers (Bitnami, Nginx ingress controller, External-Dns for example) - the combination of the two labels:

app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/managed-by: {{ .Release.Service }}

(*) Notice: There are some CD tools like ArgoCD that automatically sets the app.kubernetes.io/instance label and uses it to determine which resources form the app.

Option 3 - Delete old resources.

It might be relevant in your specific case where the old resources might not be relevant anymore.


For those who need some context

What are those labels?

Shared labels and annotations share a common prefix: app.kubernetes.io.
Labels without a prefix are private to users. The shared prefix ensures that shared labels do not interfere with custom user labels.

In order to take full advantage of using these labels, they should be applied on every resource object.

The app.kubernetes.io/managed-by label is used to describe the tool being used to manage the operation of an application - for example: helm.

Read more on the Recommended Labels section.

Are they added by helm?

No.
First of all, as mentioned before, those labels are not specific to Helm and Helm itself never requires that a particular label be present.

From the other hand, Helm docs recommend to use the following Standard Labels. app.kubernetes.io/managed-by is one of them and should be set to {{ .Release.Service }} in order to find all resources managed by Helm.

So it is the role of the chart maintainer to add those labels.

What is the best way to add them?

Many Helm chart providers adds them to the _helpers.tpl file and let all resources include it:

labels: {{ include "my-chart.labels" . | nindent 4 }}
Rot-man
  • 18,045
  • 12
  • 118
  • 124
7

The trick here is to chase the error message. For example, in the below case the erro message points at something wrong with the 'service' in namespace 'xyz'

Unable to
continue with install: Service "abc" in namespace "xyz" exists and
cannot be imported into the current release: invalid ownership
metadata; label validation error: missing key
"app.kubernetes.io/managed-by": must be set to "Helm"; annotation
validation error: missing key "meta.helm.sh/release-name": must be set
to "abc"; annotation validation error: missing key
"meta.helm.sh/release-namespace": must be set to "default"

Simply delete the same service from the mentioned namespace with below:

kubectl -n xyz delete svc abc

And then try the installation/deployment again. It might so happen that similar issue may appear but for a different resource as shown in the below example:

Release "nok-sec-sip-tls-crd" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: Role "nok-sec-sip-tls-crd-role" in namespace "debu" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "nok-sec-sip-tls-crd": current value is "nok-sec-sip"

Again use the kubectl command and delete the resource mentioned in the error message. For example, in the above case the error resource should be deleted with the below command:

kubectl delete role nok-sec-sip-tls-crd-role -n debu
Deb
  • 587
  • 4
  • 12
1

I was getting this error because I was trying to upgrade the helm chart with wrong release name. So it conflicted with the existing resources in same namespace.

I was running this command with wrong releasename

helm upgrade --install --namespace <namespace> wrong-releasename <chart-folder>

and got the similar errors

Error: rendered manifests contain a resource that already exists. Unable to continue with install: ConfigMap \"cmname\" in namespace \"namespace\" exists and cannot be imported into the current release

invalid ownership metadata; label validation error: missing key \"app.kubernetes.io/managed-by\": must be set to \"Helm\"; annotation validation error: missing key \"meta.helm.sh/release-name\": must be set to \"wrong-releasename\"; annotation validation error: missing key \"meta.helm.sh/release-namespace\": must be set to \"namespace\"

I checked the existing helm releases in the same namespace and used the same name as the listed release name to upgrade my helmchart

helm ls -n <namespace>
helm upgrade --install --namespace <namespace> releasename <chart-folder>
  • Helm has many changes between it's versions. – Eitan Apr 01 '22 at 05:45
  • 1
    Helm has changes between its versions and not full compatible for the old versions. Try uninstall the charts and re-install it again. Dependencies is new section in chart, and there might be annotations, as you described, which are new or not exists any more, so you cannot upgrade helm and use your old charts. Helm install --debug --dry-run for checking the charts. If you really want to upgrade helm, lot of work shall be done. Good luck! – Eitan Apr 01 '22 at 05:51
0

Here's a faster and more thorough way to get rid of argo so it can be reinstalled :

helm list -A   # see argocd in namespace argocd
helm uninstall argocd -n argocd
kubectl delete namespace argocd

The last line gets rid of all secrets and other resources not cleaned up by uninstalling the helm chart, and was needed in my environment, otherwise, I got the same sorts of errors about duplicate resources you were seeing.

0

We use GitOps via Flux, and I was getting the same rendered manifests contain a resource that already exists error. For me the problem was I accidentally defined a resource with the same name in two different files, so it was trying to create it twice. I removed the duplicate resource definition from one of the files to fix it up.

deadlydog
  • 22,611
  • 14
  • 112
  • 118
0

For us, we had to delete ServiceAccount linked to the deployment as well to fix the issue.

$ kubectl delete service -n <namespace> <service-name>
$ kubectl delete deployment -n <namespace> <deployment-name>
$ kubectl delete ingress -n <namespace> <ingress-name>
$ kubectl delete serviceaccount -n <namespace> <ingress-name>
Baga
  • 1,354
  • 13
  • 24