通过helm delete release完全从Helm中删除发行版是可行的，但这不是可行的解决方案。

为什么Helm不能仅覆盖当前安装的内容？ 我们不是和Kubernetes生活在一个声明性的世界中吗？

刚得到同样的事情...对我来说，这是一个新问题。 删除资源将对其进行修复。
Kubernetes 1.7.7的v2.7.2版本。
很不错，之前...

我遇到了这个问题-这是由于我创建了一个PersistentVolume。 为了解决此问题，我删除了PV和PVC。 运行helm upgrade XXX XXX ，它可以正常工作。 由于PV确实存在，可能还应该研究一些东西。

我觉得这可能与PV不良有关...但是错误很容易引起误解！
还有一些来自分some的怪异日志...似乎它同时在两个版本上工作...

刚尝试使用2.7.1却没有运气...

[main] 2017/12/21 15:30:48 Starting Tiller v2.7.1（tls = false）
[main] 2017/12/21 15:30:48 GRPC监听：44134
[主要] 2017/12/21 15:30:48正在侦听的探针：44135
[main] 2017/12/21 15:30:48存储驱动程序是ConfigMap
[main] 2017/12/21 15:30:48每个版本的最大历史记录为0
[tiller] 2017/12/21 15:30:55为xxx准备更新
[存储] 2017/12/21 15:30:55从“ xxx”历史记录获取部署版本
[tiller] 2017/12/21 15:30:56将值从xxx（v65）复制到新版本。
[存储] 2017/12/21 15:30:56获得“ xxx”的最新修订
[存储] 2017/12/21 15:30:56获取“ xxx”的发布历史记录
[tiller] 2017/12/21 15:30:59使用值渲染helm-xxx图表
2017/12/21 15:30:59信息：清单“ helm-xxx / templates / scheduler-deploy.yaml”为空。 正在跳过。
2017/12/21 15:30:59信息：清单“ helm-xxx / templates / recomposer-deploy.yaml”为空。 正在跳过。
2017/12/21 15:31:00信息：清单“ helm-xxx / templates / recomposer-pvc.yaml”为空。 正在跳过。
2017/12/21 15:31:00信息：清单“ helm-xxx / templates / scheduler-pvc.yaml”为空。 正在跳过。
2017/12/21 15:31:00信息：清单“ helm-xxx / templates / scheduler-secret.yaml”为空。 正在跳过。
2017/12/21 15:31:00信息：清单“ helm-xxx / templates / recomposer-secret.yaml”为空。 正在跳过。
[tiller] 2017/12/21 15:31:09为xxx创建更新的版本
[存储] 2017/12/21 15:31:09创建发行版“ xxx.v80”
[tiller] 2017/12/21 15:31:09为xxx执行更新
[tiller] 2017/12/21 15:31:09执行xxx的0个升级前挂钩
[tiller] 2017/12/21 15:31:09完整的预升级xxx挂钩
[tiller] 2017/12/21 15:31:11为xxx准备更新
[存储] 2017/12/21 15:31:11从“ xxx”历史记录获取部署版本
[存储] 2017/12/21 15:31:11获得“ xxx”的最新修订
[存储] 2017/12/21 15:31:11获取“ xxx”的发布历史
[tiller] 2017/12/21 15:31:18使用值渲染helm-xxx图表
2017/12/21 15:31:18信息：清单“ helm-xxx / templates / scheduler-secret.yaml”为空。 正在跳过。
2017/12/21 15:31:18信息：清单“ helm-xxx / templates / scheduler-pvc.yaml”为空。 正在跳过。
2017/12/21 15:31:19信息：清单“ helm-xxx / templates / scheduler-deploy.yaml”为空。 正在跳过。
[kube] 2017/12/21 15:31:28从更新的清单中构建资源
[tiller] 2017/12/21 15:31:46为xxx创建更新的发行版
[存储] 2017/12/21 15:31:46创建发行版“ xxx.v81”
[tiller] 2017/12/21 15:31:47为xxx执行更新
[tiller] 2017/12/21 15:31:47执行xxx的0个升级前挂钩
[tiller] 2017/12/21 15:31:47完整的预升级xxx挂钩
[kube] 2017/12/21 15:31:49检查7种资源的变化
[kube] 2017/12/21 15:31:49看起来秘密“ xxx-helm-xxx-nginx-secret”没有变化
[kube] 2017/12/21 15:31:50看起来秘密“ xxx-application-secret”没有变化
[kube] 2017/12/21 15:31:50看起来秘密“ azure-secret”没有变化
[kube] 2017/12/21 15:31:51好像没有更改ConfigMap“ xxx-helm-xxx-nginx-config”
[kube] 2017/12/21 15:31:51看起来ConfigMap“ xxx-application-config”没有任何变化
[kube] 2017/12/21 15:31:51看起来服务“ xxx-application-svc”没有变化
[kube] 2017/12/21 15:31:51看起来StatefulSet“ xxx-application”没有任何变化
[tiller] 2017/12/21 15:31:51为xxx执行0个升级后挂钩
[tiller] 2017/12/21 15:31:51升级后xxx的钩子完整
[存储] 2017/12/21 15:31:51更新发行版“ xxx.v65”
[tiller] 2017/12/21 15:31:51 xxx更新版本的更新状态
[存储] 2017/12/21 15:31:51更新发行版“ xxx.v80”
[kube] 2017/12/21 15:31:57从更新的清单中构建资源
[kube] 2017/12/21 15:32:10检查11个资源是否有更改
[kube] 2017/12/21 15:32:10看起来秘密“ xxx-helm-xxx-nginx-secret”没有变化
[tiller] 2017/12/21 15:32:10警告：升级“ xxx”失败：找不到名称为“ xxx-recomposer-secret”的资源
[存储] 2017/12/21 15:32:10更新发行版“ xxx.v65”
[存储] 2017/12/21 15:32:10更新发行版“ xxx.v81”

似乎在发布的同时感到困惑...

只是重新应用了相同的配置两次...

[tiller] 2017/12/21 15:50:46为xxx准备更新
[存储] 2017/12/21 15:50:46从“ xxx”历史记录获取部署版本
[存储] 2017/12/21 15:50:46获得“ xxx”的最新修订
[存储] 2017/12/21 15:50:46获取“ xxx”的发布历史记录
[tiller] 2017/12/21 15:50:50使用值渲染helm-xxx图表
2017/12/21 15:50:50信息：清单“ helm-xxx / templates / scheduler-pvc.yaml”为空。 正在跳过。
2017/12/21 15:50:50信息：清单“ helm-xxx / templates / recomposer-deploy.yaml”为空。 正在跳过。
2017/12/21 15:50:50信息：清单“ helm-xxx / templates / scheduler-secret.yaml”为空。 正在跳过。
2017/12/21 15:50:50信息：清单“ helm-xxx / templates / scheduler-deploy.yaml”为空。 正在跳过。
2017/12/21 15:50:50信息：清单“ helm-xxx / templates / recomposer-secret.yaml”为空。 正在跳过。
2017/12/21 15:50:50信息：清单“ helm-xxx / templates / recomposer-pvc.yaml”为空。 正在跳过。
[tiller] 2017/12/21 15:50:58为xxx创建更新的版本
[存储] 2017/12/21 15:50:58创建发行版“ xxx.v85”
[tiller] 2017/12/21 15:50:59为xxx执行更新
[tiller] 2017/12/21 15:50:59为xxx执行0个预升级钩子
[tiller] 2017/12/21 15:50:59完整的预升级xxx挂钩
[kube] 2017/12/21 15:51:13从更新的清单中构建资源
[kube] 2017/12/21 15:51:22检查7种资源的变化
[kube] 2017/12/21 15:51:22看起来秘密“ xxx-helm-xxx-nginx-secret”没有变化
[kube] 2017/12/21 15:51:23看起来秘密“ xxx-application-secret”没有变化
[kube] 2017/12/21 15:51:23看起来秘密“ azure-secret”没有变化
[kube] 2017/12/21 15:51:23看起来ConfigMap“ xxx-helm-xxx-nginx-config”没有任何变化
[kube] 2017/12/21 15:51:23看起来ConfigMap“ xxx-application-config”没有任何变化
[kube] 2017/12/21 15:51:24看起来服务“ xxx-application-svc”没有任何变化
[kube] 2017/12/21 15:51:24删除xxx中的“ xxx-recomposer-secret”
[kube] 2017/12/21 15:51:24无法删除“ xxx-recomposer-secret”，错误：找不到机密“ xxx-recomposer-secret”
[kube] 2017/12/21 15:51:24删除xxx中的“ xxx-recomposer-config” ...
[kube] 2017/12/21 15:51:24无法删除“ xxx-recomposer-config”，错误：找不到配置映射“ xxx-recomposer-config”
[kube] 2017/12/21 15:51:24在...中删除“ xxx-recomposer-pv”
[kube] 2017/12/21 15:51:24无法删除“ xxx-recomposer-pv”，错误：找不到持久卷“ xxx-recomposer-pv”
[kube] 2017/12/21 15:51:24删除xxx中的“ xxx-recomposer-pvc” ...
[kube] 2017/12/21 15:51:24无法删除“ xxx-recomposer-pvc”，错误：未找到持久卷声明“ xxx-recomposer-pvc”
[kube] 2017/12/21 15:51:24删除xxx中的“ xxx-recomposer” ...
[kube] 2017/12/21 15:51:24使用收割机删除“ xxx-recomposer”
[kube] 2017/12/21 15:51:24无法删除“ xxx-recomposer”，错误：未找到deployments.extensions“ xxx-recomposer”
[tiller] 2017/12/21 15:51:24为xxx执行0个升级后挂钩
[tiller] 2017/12/21 15:51:24升级后xxx的钩子完整
[存储] 2017/12/21 15:51:24更新发行版“ xxx.v68”
[tiller] 2017/12/21 15:51:24 xxx的更新版本的更新状态
[存储] 2017/12/21 15:51:24更新发行版“ xxx.v85”
[存储] 2017/12/21 15:51:25获得“ xxx”的最新修订
[存储] 2017/12/21 15:51:25获取“ xxx”的发布历史
[kube] 2017/12/21 15:51:38做秘密：“ xxx-helm-xxx-nginx-secret”
[kube] 2017/12/21 15:51:39获取对象的关系窗格：xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 2017/12/21 15:51:39做秘密：“ xxx-application-secret”
[kube] 2017/12/21 15:51:39获取对象的关系窗格：xxx / Secret / xxx-application-secret
[kube] 2017/12/21 15:51:39做秘密：“天蓝色的秘密”
[kube] 2017/12/21 15:51:39获取对象的关系荚：xxx /秘密/天蓝色秘密
[kube] 2017/12/21 15:51:39进行ConfigMap获取：“ xxx-helm-xxx-nginx-config”
[kube] 2017/12/21 15:51:39获取对象的关系窗格：xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 2017/12/21 15:51:39进行ConfigMap的获取：“ xxx-application-config”
[kube] 2017/12/21 15:51:39获取对象的关系容器：xxx / ConfigMap / xxx-application-config
[kube] 2017/12/21 15:51:39做服务：“ xxx-application-svc”
[kube] 2017/12/21 15:51:39获取对象的关系窗格：xxx / Service / xxx-application-svc
[kube] 2017/12/21 15:51:39做StatefulSet的获取：“ xxx-application”
[kube] 2017/12/21 15:51:39获取对象的关系吊舱：xxx / StatefulSet / xxx-application

可能与＃2941有关

在另一个线程中说，解决此问题的一种方法是删除越野车的configmaps ...目前似乎为我做的...

很好，花花公子。 在此之前，您必须从生产名称空间中删除关键内容。 碰巧的是，这恰好发生在我身上。 ：C

如果该版本有多个DEPLOYED状态，我们在升级版本时也会遇到该问题，必须通过删除相应的configmap对其进行修复。

同样的问题。 昨天一切都很好，我进行了多次升级。 今天，我刚刚添加了一个新的Yaml，其中service和deployment块用---分隔，并且升级失败。

有趣的是，Helm创建了service ，然后抱怨了这一点（并且没有进行部署）。
我注释掉了service然后使用deployment块进行了升级-它起作用了。 但是，Helm并未删除该服务-从yaml文件中删除该服务时，它应该具有该服务。

更新：我手动删除了service ，从yaml中取消了注释，然后运行了升级-这次它就像一个魅力！

我有这个确切的错误。 该问题似乎与具有多个API对象的模板有关，类似于@amritb看到的内容。 就我而言，我有一个模板，其中包含多个API对象，可以像下面这样来打开和关闭：

{{ if .Values.enabled }}
---
...

将其分解为自己的模板文件，并清理头盔创建并遗忘的孤立对象，这对我来说解决了这个问题。 如果每个模板之间的版本数在发行版之间发生变化，这听起来像是在掌舵如何获取先前的配置方面存在错误。

添加另一个数据点：我似乎遇到了与@awwithro完全相同的问题。 我们使用jinja循环通过模板创建多个cronjob，并且当新的升级导致该循环填充其他cronjob时，我们遇到了该错误。 似乎也触发了＃2941（或者一个错误可能导致另一个错误），并且删除僵尸configmaps可以解决该问题。

即使不使用任何配置映射也只是陷入其中

一些可能会卡住的人的额外颜色：
在向我的发行版引入新的子图表和对象时，我遇到了这个问题。 通过检查要添加的每种对象类型并删除所有可能引起命名冲突的现有对象，我能够解决此问题。

这似乎与其他人的证据相符，即删除是解决当前问题的唯一方法😕

还在这个= \上运行

我还需要删除受影响的资源。 对生产环境不利= _（

我看到了一些我认为相似的东西。 在出现问题是一个helm upgrade确实从以前的部署不--reuse值。 如果我在命令行上指定的值与初始安装时指定的值相同，则helm upgrade可以工作。 Dunno（如果有帮助的话）（或其他任何人都可以确认）。

就像@amritb一样，在我手动删除了头盔最初失败的对象之后，它在下一次升级后成功了。 我没有遇到＃2941。

使用头盔2.8.0遇到相同的问题。 Kubernetes版本client=v1.8.6和server=v1.8.5-gke.0 。

$ helm upgrade bunny ./app --debug
[debug] Created tunnel using local port: '54274'

[debug] SERVER: "127.0.0.1:54274"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

但是configmap存在于$ kubectl get configmap 。 如果我手动删除configmap，它将起作用，但是下次它将再次失败。

这是配置图：

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  # namespace: {{ .Release.Namespace }} # I've tried adding and removing it
  labels: # labels are the same as labels from $ kubectl describe configmap bunny-proxy-config
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

我删除了发行版，然后再次重新安装。 另外，我正在使用api版本extensions/v1beta进行部署，我已更改为apiVersion: apps/v1beta2 ，我不知道这是否有所帮助。
目前，我还在本地运行tiller 。

现在看来一切正常。

这确实很容易重现，如果清单中有错误，则会发生这种情况。

就像我们有resource1和resource2一样，resource2首先依赖。 当我们升级发行版时，创建了resource1（例如PV和PVC），但是resource2失败。 在此之后，仅删除resource1会有所帮助，因为头盔始终会报告升级问题（找不到名称为...的PersistentVolume）

我们遇到了同样的问题（使我们获得资源的是秘密）。 删除新机密，然后重新部署以解决此问题。

请注意，由于失败，当我们执行helm list时，我们现在有11个不同的发行版，有10个FAILED发行版和1个DEPLOYED。 没想到的，对吧？ 与这里似乎相同的问题： https :

这已经使头盔无法用于我们的常规生产部署：（（我们目前正在研究将--dry-run传递给头盔并将其通过管道传递到kubectl的操作...因为这似乎只影响一部分用户，不确定我们做错了什么:(

跟踪分logs日志后，我发现分er正在尝试同时更新旧版本：

[storage] 2018/02/14 18:25:40 updating release "s2osf.v10"
[storage] 2018/02/14 18:25:40 updating release "s2osf.v44"

删除s2osf.v10的旧configmap，然后进行升级。

Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

与@binoculars具有相同的问题：

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

造成UPGRADE FAILED: no Secret with the name "foobar" found怪异问题。
我什至尝试删除此机密，这反而在某些configmap上导致错误，并且在第3次运行时，它再次抱怨先前的机密。

从头盔2.7.x升级到2.8.1后可能触发了此事件。

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

如果您最后的选择是删除旧版本，那么可能会有一些破坏性较小的工作作为我的评论https://github.com/kubernetes/helm/issues/3513#issuecomment -366918019

基本上是在日志中找到旧版本，然后手动编辑configmap，直到分耕机存储已部署状态。 不应有DEPLOYED状态afaik的两个修订版。

找到了解决此问题的新方法。

kubectl -n kube-system edit cm name_of_your_release.v2 ，其中v2是helm list标记为FAILED的最新修订版本号。 您可能还需要编辑DEPLOYED版本之一，并将状态更改为SUPERSEDED，这样我们就不会同时拥有两个已部署的版本。

@zuzzas这就是我所说的。 也为我工作

@balboah的问题是，我们只有一个处于DEPLOYED状态的部署，但是如果它不是最新的（在大多数情况下，它们被标记为FAILED），它仍然会崩溃。 在大多数情况下，该问题似乎与处于DEPLOYED状态的两个或多个部署无关。

@zuzzas您在同一个名称空间中有多个发行版，还是只有一个？ 一次，我遇到了两个更新相同对象的发行版的问题，然后它们将彼此冲突。

如果只有一个，那么在部署版本之前您将遇到多少次故障？ 您如何验证仅部署了它？

我们认为此问题已通过＃3539解决（向前移动）。 如果我们碰巧错了，请重新打开。 :)

谢谢大家为此所做的工作！

请注意，此状态下的现有图表尚未解决。 您仍然需要删除处于DEPLOYED状态的旧发行版，以使事情再次生效。 @balboah只是阻止了您进入“标记为DEPLOYED的多个发行版”状态的情况。 :)

嗯，我仍然在Helm 2.8.2上遇到此问题（不是最新的，但我尝试使用2.9.0，它给出了相同的错误。）通常手动删除有问题的资源可以解决它，尽管通常它会级联成多个资源在成功升级之前，都需要删除所有内容。

我有一个带有嵌套依赖关系的大型舵图； 可能是这样吗？

我在clusterrolebinding中看到了同样的问题。 我将新资源添加到图表中，并且upgrade以及upgrade --install会因Error: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found而失败

我在使用ClusterRole遇到与@ramyala相同的问题。 ClusterRole存在，但是创建RoleBinding失败并显示该错误。

在Helm 2.9.1我遇到了相同的问题：

helm upgrade --install --namespace my-namespace my-stack stack
Error: UPGRADE FAILED: no ConfigMap with the name "my-stack-my-app" found

当我在群集上看到此ConfigMap时。

如果我在一个文件中有多个带有钩子的资源，则会遇到此问题

+1，这在2.9.1中再次发生。 请重新打开。

将其重新标记为错误。 我们不确定导致此回归的原因是什么，但是如果有人可以提供有关如何在2.9.1上重现此错误的步骤，将不胜感激。

@bacongobbler

当我尝试在掌舵图中部署新的Ingress时，我也看到了这一点。 我确实是Ingress的新手，但根据所有示例来看，这似乎是正确的，并且我已经做了几个月的helm / k8s其他工作。

我已经部署了舵图stable/nginx-ingress所以控制器存在。 该错误似乎表明它正在尝试查找我要创建的那个。 这是我正在运行的命令：

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helm ，其中deploy/helm包含我的图表清单。

Error: UPGRADE FAILED: no Ingress with the name "my-ingress" found

yaml：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  labels:
    app: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: {{ $.Values.appDomain }}
    http:
      paths:
      - path: /*
        backend:
          serviceName: web-app
          servicePort: 80
      - path: /api/*
        backend:
          serviceName: api
          servicePort: 8080

更新
我从两条路径中都删除了/* ，并且在尝试升级/安装时不再出现错误。 也许那不是一个有效的语法

你好，
以下是在我的环境中引入此问题的步骤：

1. 我已经部署了头盔图并进行了多次升级。
2. 在图表中创建了新的CronJob对象，并再次进行了升级-cron作业已成功创建。
3. 所有下一次升级均失败，并报告以下错误：“错误：升级失败：找不到名称为“ cronjob-name”的CronJob”

当我添加一个不存在的秘密时，我也看到了这个问题。 我尝试添加“ db-credentials”
导致：

Error: UPGRADE FAILED: no Secret with the name "db-credentials" found

可能相关的修补程序：＃4146

如果遇到此错误的任何人都可以测试PR并查看它是否可以解决此问题，那么我们将能够确认它可能是k8s API中的回归，并继续进行该修复。 谢谢！

我无法100％确认这种情况是否总是会再现，但是我注意到这种情况通常在以下情况下发生：

1. 我升级了Helm图表，包括新资源
2. 该升级失败，但是该资源是作为失败升级的一部分创建的
3. 所有后续升级均失败

如果我对上次成功的部署执行了helm rollback ，然后尝试重新升级，则它似乎可以正常工作。

手动重现它似乎很容易，而无需故意尝试通过有害更改来升级图表（例如，修改不可变的Job对象）：

1. 取得一些图表并进行部署（但是省略一个资源，比如说一个服务）
2. 手动添加省略的资源（例如，使用“ kubectl create”），但使用与发行版相对应的名称
3. 将省略的资源重新添加到图表中，然后尝试对其进行升级，掌舵人应报告“升级失败：否名称成立”

步骤不同，但根本原因似乎相同。 如果我的假设是错误的，请纠正我，但是在我看来，上次DEPLOYED版本的修订版不包含有关特定资源的信息，这是因为该资源是在“ Helm”外部添加的（例如，手动），或者最新的升级失败在某个步骤上（例如，升级不可变的Job），同时部署其他对象，然后将其记录在FAILED修订版中（但在DEPLOYED修订版中仍然没有任何痕迹，这是期望的，否则将意味着更改历史记录） 。 在下一次运行时，Tiller的kube客户端会看到群集上的资源，这意味着它们应该已经部署并记录下来，它会检查最新的DEPLOYED版本（似乎根本没有联系FAILED版本），并且在那里看不到它们。因此它报告错误。

@bacongobbler我使用自定义分

make bootstrap build docker-build

您将必须将分er映像上载到您的仓库中，然后将分er重新安装到您的集群中。 我能够通过强制重设并重新安装而不会破坏当前发行版。

$GO_HOME/src/k8s.io/helm/bin/helm init -i gcr.io/my-repo/tiller:1 --service-account tiller

感谢@ramyala测试此修复程序！ 我将在明天的开发人员电话中提及它，看看是否有任何其他核心维护者看到补丁可能附带的任何极端情况。 如果没有，让我们合并。

因此，我发现了＃4146的一些错误，这使其不受欢迎。 我在这里报告了master，＃4146和＃4223之间的发现： https :

@adamreese和我设法确定了导致此特定错误的潜在错误，并针对每个拟议的PR进行了不同的场景和边缘案例。 如果其他人可以证实我的发现或发现其他极端情况，将不胜感激！

哦，还有我没有提到的事情：由于群集处于不一致状态，因此可以通过手动干预和删除错误报告为“未找到”的资源来轻松解决此问题。 遵循我在https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568演示的示例：

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

为了使所有内容保持一致，我将关闭＃1193的副本，因为两张票是相同的。 请报告那里的任何发现，以便我们所有人都能凭单出票。 谢谢！

警告：此信息是粗略的，我无法理解，但以防万一这对某人有用，我通过将服务选择器从以下位置更改来解决此问题：

selector:
    app: {{ template "mything.name" . }}

至

selector:
    app: mything

在这种情况下使用变量也许存在某种问题？

尝试helm delete RELEASE_NAME --purge
并再次安装。

我也遇到这个问题。 我尝试在图表中添加带有部署的子图表，该图表仅在首次使用helm upgrade chart chart-1.0.1.tgz进行升级时成功，之后，当我尝试helm upgrade chart chart-1.0.1.tgz时失败，并显示错误Error: UPGRADE FAILED: no Deployment with name "subchart-deployment" found

Client: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}

舵柄记录仪仅记录了相同的错误。 有人也经历过吗？

同样的问题。 昨天一切都很好，我进行了多次升级。 今天，我刚刚添加了一个新的Yaml，其中service和deployment块用---分隔，并且升级失败。

有趣的是，Helm创建了service ，然后抱怨了这一点（并且没有进行部署）。
我注释掉了service然后使用deployment块进行了升级-它起作用了。 但是，Helm并未删除该服务-从yaml文件中删除该服务时，它应该具有该服务。

更新：我手动删除了service ，从yaml中取消了注释，然后运行了升级-这次它就像一个魅力！

嗨，我也有这个问题，我解决不了，您能给我一些提示吗？

参见https://github.com/helm/helm/issues/1193#issuecomment -419555433。

只需确认我在目睹相同的问题，原因也如前所述。

添加了一个新机密，并在卷中对其进行了引用（无效的语法）。 升级失败，后续升级失败，并显示上述错误。

列出机密表明它已创建。 手动删除机密，升级成功完成。

一样，@ thedumbtechguy。 我经常碰到这个问题。 当Helm决定需要删除所有机密，配置映射，角色等时，这特别有趣。升级变成了一场无聊的游戏，参数列表不断增加到kubectl delete 。 我本该在几个月前完成这项si​​syphean任务，但现在为时已晚。 希望可以解决此问题以及数十个类似的问题！

我已经使用头盔一个星期了，已经面对了概述的所有问题
在这里https://medium.com/@7mind_dev/the -problems-with-helm-72a48c50cb45

很多需要在这里修复。

在2019年3月15日星期五，汤姆·戴维斯（Tom Davis） [email protected]写道：

一样， @thedumbtechguy https://github.com/thedumbtechguy 。 我碰到
这个问题是例行的。 当Helm决定需要
删除所有机密，配置映射，角色等。升级成为
wack-a-mole游戏，不断增加的kubectl参数列表
删除。 我本来应该在这sissisphean任务月份里全神贯注的
以前，但现在为时已晚。 当然希望这和数十个
类似的问题可以解决！

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/helm/helm/issues/3275#issuecomment-473464809或静音
线程
https://github.com/notifications/unsubscribe-auth/AA4XZU4KMQePtZKcir8S5kWulkbYg-8Uks5vXCNggaJpZM4RGz7W
。

我在Helm v2.10中也经历了同样的情况。 我已经部署了一个图表，向该图表添加了另一个configMap。 它报告说部署失败，因为找不到configMap“ blah”。 我做了

helm upgrade <NAME> chart --debug --dryrun 

为了验证configMap确实被渲染，它是。 检查群集中的configMaps，并在其中找到它。 删除了bla configMap，重新运行了升级，就可以了。

https://github.com/helm/helm/pull/5460应该更好地阐明以后的错误消息。

有道理。

$ helm upgrade linting-unicorn testrail                                                                                                                                                                                        
Error: UPGRADE FAILED: no ConfigMap with the name "linting-unicorn-testrail-php-config" found

保持良好的工作领导团队。

万一这对其他人来说很重要，以为我指出https://github.com/helm/helm/pull/4871应该解决这些问题。

请注意，它似乎仍未得到Helm团队的批准。 另外，还有一些关于自动删除资源的问题。 只是提及它，以防有人想从源代码构建它并尝试一下。

具有相同的问题，唯一的解决方法似乎是helm delete --purge release然后重新安装！

我遇到了同样的问题。 @fbcbarbosa看起来好像是2周前合并的。 希望它应该成为下一版本2.14.0的一部分。

具有相同的问题，唯一的解决方法似乎是helm delete --purge release然后重新安装！

破坏性较小的选项是对/ current /版本执行helm rollback （即，按0步）。 我不能保证成功，但是到目前为止，对于我们来说，它始终是成功的楔子。

是否有一个想法，如果它会在下一个版本中发布，并且在发布时会发布？

5460在2个月前被合并，这意味着它应该处于2.14.0的掌舵状态。

我通过以下方式解决了这个问题

1. 删除那些因“紧急升级”而抱怨的资源。 （它显示“未找到，但实际上可以找到”）。 不要删除整个发行版，否则，如果在生产中，您将被完全搞砸。
2. 重做头盔升级。 现在这次应该是“快乐头盔”出现了。 :)

当我们对伞状舵图的需求基于条件添加了configmap时，我们在PROD中遇到了这个问题。 对我们来说，解决问题的方法是

helm rollback <some revision that's acceptable>
helm upgrade <desired version>

对我们来说，简单回滚到当前修订版一直有效：

helm ls
helm rollback <NAME> <current REVISION>

@tobypeschel您知道您的修复程序如何工作吗？