Answers: <p>Yes this happens frequently when debugging helm releases. The problem happens when a previously failed release is preventing you from updating it. </p>
  
  <p>If you run <code>helm ls</code> you should see a release in state <code>FAILED</code>. You might have deleted it in which case it might show up with <code>helm ls -a</code>. Such a release cannot be upgraded using the normal approach of having helm compare the new yaml to the old yaml to detect what objects to change as it is a failed release.</p>
  
  <p>As this normally happens when trying to get something new running I typically <code>helm delete —purge</code> the failed release. That is slightly drastic though so you may want to try to do the upgrade adding <code>—force</code> </p>
  
  <p><a href="https://github.com/helm/helm/pull/2280" rel="nofollow noreferrer">https://github.com/helm/helm/pull/2280</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-04T14:39:06.763Z
Answers: see my update on my initial post, but following your suggestion, I still get the same error.
Answers: french_dev
Answers: CC BY-SA 4.0
Answers: 2019-08-29T07:21:03.797Z
Answers: I had the same issue. The problem was that the release had been deleted but not purged. `helm ls` didn't show it, but `helm ls -a` did. After running `helm delete --purge <release>`, I was able to install the release.
Answers: Thomas BDX
Answers: CC BY-SA 4.0
Answers: 2019-03-02T23:46:16.373Z
Answers: 2019-09-02T07:35:28.893Z
Answers: 2019-09-02T07:35:28.893Z
Answers: simbo1905
Answers: <p>This can happen with releases in <code>FAILED</code> state as mentioned by <a href="https://devops.stackexchange.com/users/10599/simbo1905">simbo1905</a> in her/his <a href="https://devops.stackexchange.com/a/6518/16821">answer</a>. </p>
  
  <p>Another case is if there's a previously deleted but not purged release with the same name. </p>
  
  <p>Doing another delete with the purge option on the release will free the name for reuse.</p>
  
  <pre><code>helm ls -a
  helm ls -a | grep -e NAME -e name_of_release
  helm delete --purge name_of_release
  </code></pre>
  
  <p>Note: This issue <a href="https://github.com/helm/helm/issues/972" rel="nofollow noreferrer">https://github.com/helm/helm/issues/972</a> suggests that there is a parameter to force reusing the same name, however it also suggests to not use in production (i.e. do not automate with <code>replace</code> unless you know what you're doing).</p>
  
  <pre><code>&gt; helm install --help
  [...]
      --replace    re-use the given name, even if that name is already used. This is unsafe in production
  [...]
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2019-08-29T08:11:51.490Z
Answers: 2019-08-29T08:11:51.490Z
Answers: Thomas BDX
Body: <p>Using helm for deploying chart on my Kubernetes cluster, since one day, I can't deploy a new one or upgrading one existed.</p>
  
  <p>Indeed, each time I am using helm I have an error message telling me that it is not possible to install or upgrade ressources.</p>
  
  <p>If I run <code>helm install --name foo . -f values.yaml --namespace foo-namespace</code> I have this output:</p>
  
  <blockquote>
    <p>Error: release foo failed: the server could not find the requested
    resource</p>
  </blockquote>
  
  <p>If I run <code>helm upgrade --install foo . -f values.yaml --namespace foo-namespace</code> or <code>helm upgrade foo . -f values.yaml --namespace foo-namespace</code> I have this error:</p>
  
  <blockquote>
    <p>Error: UPGRADE FAILED: "foo" has no deployed releases</p>
  </blockquote>
  
  <p>I don't really understand why.</p>
  
  <p>This is my helm version:</p>
  
  <pre><code>Client: &amp;version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
  Server: &amp;version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
  </code></pre>
  
  <p>On my kubernetes cluster I have tiller deployed with the same version, when I run <code>kubectl describe pods tiller-deploy-84b... -n kube-system</code>:</p>
  
  <pre><code>Name:               tiller-deploy-84b8...
  Namespace:          kube-system
  Priority:           0
  PriorityClassName:  &lt;none&gt;
  Node:               k8s-worker-1/167.114.249.216
  Start Time:         Tue, 26 Feb 2019 10:50:21 +0100
  Labels:             app=helm
                      name=tiller
                      pod-template-hash=84b...
  Annotations:        &lt;none&gt;
  Status:             Running
  IP:                 &lt;IP_NUMBER&gt;
  Controlled By:      ReplicaSet/tiller-deploy-84b8...
  Containers:
    tiller:
      Container ID:   docker://0302f9957d5d83db22...
      Image:          gcr.io/kubernetes-helm/tiller:v2.12.3
      Image ID:       docker-pullable://gcr.io/kubernetes-helm/tiller@sha256:cab750b402d24d...
      Ports:          44134/TCP, 44135/TCP
      Host Ports:     0/TCP, 0/TCP
      State:          Running
        Started:      Tue, 26 Feb 2019 10:50:28 +0100
      Ready:          True
      Restart Count:  0
      Liveness:       http-get http://:44135/liveness delay=1s timeout=1s period=10s #success=1 #failure=3
      Readiness:      http-get http://:44135/readiness delay=1s timeout=1s period=10s #success=1 #failure=3
      Environment:
        TILLER_NAMESPACE:    kube-system
        TILLER_HISTORY_MAX:  0
      Mounts:
        /var/run/secrets/kubernetes.io/serviceaccount from helm-token-... (ro)
  Conditions:
    Type              Status
    Initialized       True 
    Ready             True 
    ContainersReady   True 
    PodScheduled      True 
  Volumes:
    helm-token-...:
      Type:        Secret (a volume populated by a Secret)
      SecretName:  helm-token-...
      Optional:    false
  QoS Class:       BestEffort
  Node-Selectors:  &lt;none&gt;
  Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                   node.kubernetes.io/unreachable:NoExecute for 300s
  Events:
    Type    Reason     Age   From                   Message
    ----    ------     ----  ----                   -------
    Normal  Scheduled  26m   default-scheduler      Successfully assigned kube-system/tiller-deploy-84b86cbc59-kxjqv to worker-1
    Normal  Pulling    26m   kubelet, k8s-worker-1  pulling image "gcr.io/kubernetes-helm/tiller:v2.12.3"
    Normal  Pulled     26m   kubelet, k8s-worker-1  Successfully pulled image "gcr.io/kubernetes-helm/tiller:v2.12.3"
    Normal  Created    26m   kubelet, k8s-worker-1  Created container
    Normal  Started    26m   kubelet, k8s-worker-1  Started container
  </code></pre>
  
  <hr>
  
  <p>UPDATE</p>
  
  <p>Following answer suggestion, I have run these two commands <code>helm upgrade foo . -f values.yaml --namespace foo-namespace --force</code> | <code>helm upgrade --install foo . -f values.yaml --namespace foo-namespace --force</code> and I still get an error:</p>
  
  <pre><code>UPGRADE FAILED
  ROLLING BACK
  Error: failed to create resource: the server could not find the requested resource
  Error: UPGRADE FAILED: failed to create resource: the server could not find the requested resource
  </code></pre>
  
  <p>Notice that foo-namespace already exist. So the error don't come from the namespace name. Indeed, if I run <code>helm list</code>, I can see that the <strong>foo</strong> chart is in a <code>FAILED</code> status.</p>
  
  <p>Is someone have faced the same issue ?</p>
  
Tags: <docker><kubernetes><deployment><continuous-deployment><helm>
Title: Helm install or upgrade release failed on Kubernetes cluster: the server could not find the requested resource or UPGRADE FAILED: no deployed releases
UserDisplayName: french_dev
ThreadText: # Helm install or upgrade release failed on Kubernetes cluster: the server could not find the requested resource or UPGRADE FAILED: no deployed releases
  
  (Asked by: username_0 on 2019-02-26)
  
  Using helm for deploying chart on my Kubernetes cluster, since one day, I can't deploy a new one or upgrading one existed.
  
  Indeed, each time I am using helm I have an error message telling me that it is not possible to install or upgrade ressources.
  
  If I run `helm install --name foo . -f values.yaml --namespace foo-namespace` I have this output:
  
  > Error: release foo failed: the server could not find the requested
  > resource
  
  If I run `helm upgrade --install foo . -f values.yaml --namespace foo-namespace` or `helm upgrade foo . -f values.yaml --namespace foo-namespace` I have this error:
  
  > Error: UPGRADE FAILED: "foo" has no deployed releases
  
  I don't really understand why.
  
  This is my helm version:
  
  ```
  Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
  Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
  
  ```
  
  On my kubernetes cluster I have tiller deployed with the same version, when I run `kubectl describe pods tiller-deploy-84b... -n kube-system`:
  
  ```
  Name:               tiller-deploy-84b8...
  Namespace:          kube-system
  Priority:           0
  PriorityClassName:  <none>
  Node:               k8s-worker-1/167.114.249.216
  Start Time:         Tue, 26 Feb 2019 10:50:21 +0100
  Labels:             app=helm
                      name=tiller
                      pod-template-hash=84b...
  Annotations:        <none>
  Status:             Running
  IP:                 <IP_NUMBER>
  Controlled By:      ReplicaSet/tiller-deploy-84b8...
  Containers:
    tiller:
      Container ID:   docker://0302f9957d5d83db22...
      Image:          gcr.io/kubernetes-helm/tiller:v2.12.3
      Image ID:       docker-pullable://gcr.io/kubernetes-helm/tiller@sha256:cab750b402d24d...
      Ports:          44134/TCP, 44135/TCP
      Host Ports:     0/TCP, 0/TCP
      State:          Running
        Started:      Tue, 26 Feb 2019 10:50:28 +0100
      Ready:          True
      Restart Count:  0
      Liveness:       http-get http://:44135/liveness delay=1s timeout=1s period=10s #success=1 #failure=3
      Readiness:      http-get http://:44135/readiness delay=1s timeout=1s period=10s #success=1 #failure=3
      Environment:
        TILLER_NAMESPACE:    kube-system
        TILLER_HISTORY_MAX:  0
      Mounts:
        /var/run/secrets/kubernetes.io/serviceaccount from helm-token-... (ro)
  Conditions:
    Type              Status
    Initialized       True 
    Ready             True 
    ContainersReady   True 
    PodScheduled      True 
  Volumes:
    helm-token-...:
      Type:        Secret (a volume populated by a Secret)
      SecretName:  helm-token-...
      Optional:    false
  QoS Class:       BestEffort
  Node-Selectors:  <none>
  Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                   node.kubernetes.io/unreachable:NoExecute for 300s
  Events:
    Type    Reason     Age   From                   Message
    ----    ------     ----  ----                   -------
    Normal  Scheduled  26m   default-scheduler      Successfully assigned kube-system/tiller-deploy-84b86cbc59-kxjqv to worker-1
    Normal  Pulling    26m   kubelet, k8s-worker-1  pulling image "gcr.io/kubernetes-helm/tiller:v2.12.3"
    Normal  Pulled     26m   kubelet, k8s-worker-1  Successfully pulled image "gcr.io/kubernetes-helm/tiller:v2.12.3"
    Normal  Created    26m   kubelet, k8s-worker-1  Created container
    Normal  Started    26m   kubelet, k8s-worker-1  Started container
  
  ```
  
  ---
  
  UPDATE
  
  Following answer suggestion, I have run these two commands `helm upgrade foo . -f values.yaml --namespace foo-namespace --force` | `helm upgrade --install foo . -f values.yaml --namespace foo-namespace --force` and I still get an error:
  
  ```
  UPGRADE FAILED
  ROLLING BACK
  Error: failed to create resource: the server could not find the requested resource
  Error: UPGRADE FAILED: failed to create resource: the server could not find the requested resource
  
  ```
  
  Notice that foo-namespace already exist. So the error don't come from the namespace name. Indeed, if I run `helm list`, I can see that the **foo** chart is in a `FAILED` status.
  
  Is someone have faced the same issue ?
  
  **Tags:** docker, kubernetes, deployment, continuous-deployment, helm
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2019-03-02. Score: 3
  
  Yes this happens frequently when debugging helm releases. The problem happens when a previously failed release is preventing you from updating it.
  
  If you run `helm ls` you should see a release in state `FAILED`. You might have deleted it in which case it might show up with `helm ls -a`. Such a release cannot be upgraded using the normal approach of having helm compare the new yaml to the old yaml to detect what objects to change as it is a failed release.
  
  As this normally happens when trying to get something new running I typically `helm delete —purge` the failed release. That is slightly drastic though so you may want to try to do the upgrade adding `—force`
  
  <https://github.com/helm/helm/pull/2280>
  
  > **Comments:**
  > **username_0**: see my update on my initial post, but following your suggestion, I still get the same error.  
  > **username_2**: I had the same issue. The problem was that the release had been deleted but not purged. `helm ls` didn't show it, but `helm ls -a` did. After running `helm delete --purge <release>`, I was able to install the release.  
  
  ---
  
  ### Answer by username_2 on 2019-08-29. Score: 1
  
  This can happen with releases in `FAILED` state as mentioned by [username_1](https://devops.stackexchange.com/users/10599/username_1) in her/his [answer](https://devops.stackexchange.com/a/6518/16821).
  
  Another case is if there's a previously deleted but not purged release with the same name.
  
  Doing another delete with the purge option on the release will free the name for reuse.
  
  ```
  helm ls -a
  helm ls -a | grep -e NAME -e name_of_release
  helm delete --purge name_of_release
  
  ```
  
  Note: This issue <https://github.com/helm/helm/issues/972> suggests that there is a parameter to force reusing the same name, however it also suggests to not use in production (i.e. do not automate with `replace` unless you know what you're doing).
  
  ```
  > helm install --help
  [...]
      --replace    re-use the given name, even if that name is already used. This is unsafe in production
  [...]
  
  ```
  
  
  ---
  
  