Helm: 升级失败：找不到名称为“”的资源

我遇到了一个类似的问题，其中有一个带有捆绑依赖项的图表。 如果添加新的依赖项并运行helm upgrade则结果与所述相同。 资源已正确创建，但是helm返回错误。

因此，如果已安装： helm install -n my-release

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/

然后添加一个新图表作为依赖项：

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/
    new-dependency/

使用以下版本升级发行版时： helm upgrade my-release my-thing helm会产生以下错误：

Error: UPGRADE FAILED: No resource with the name new-dependency found.

@devth我无法在master上重现此问题。 您还在看到这个问题吗？ 您正在运行什么版本的头盔/翻土机？

谢谢！

@elementalvoid我也无法在master上重现新的依赖项错误。 您还在看到这个问题吗？ 您正在运行什么版本的头盔/翻土机？

谢谢你。

当时我使用的是alpha4 。使用alpha 5和

好的。 我现在将其关闭。 如果您再次遇到上述任何一个问题，请随时提出问题。

再次感谢。

@michelleN谢谢！ 抱歉，本周我没有时间尝试对master进行再现。 期待尽快升级！

将hostPath部署/卷规格移至PVC时，对我来说也是一样。
错误似乎是升级清单依赖于新清单（旧清单中的“缺失”？）时发生的。
版本：2.7.2

奇怪，我看到相同的行为，试图以新角色升级2.7.2版中的图表。 Tiller抱怨说，即使它确实创建了角色，也找不到该角色并导致部署失败。

我的情况是我有一个新资源，并且用新资源部署了新版本的Helm Chart。 部署失败，因为我胖了一些傻瓜。 好吧，新对象是在kubernetes中创建的。 我修复了Yaml，然后再次在图表上运行了升级，瞧，出现未找到资源的错误消息。 我必须进入kubernetes并删除由失败的部署创建的新资源（在我的情况下为角色和角色绑定）。 在那之后，查看当前对象是否存在的掌舵检查失败（https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/pkg/kube/client.go#L257）将不会成功，并且将创建资源再次。 好像是一个错误，可能应该在哪里为失败的图表添加新资源？

升级时出现类似错误：

$ helm upgrade --install bunny ./app --namespace=staging --reuse-values --debug
[debug] Created tunnel using local port: '53859'

[debug] SERVER: "127.0.0.1:53859"

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

Configmap已创建

$ k get configmap
NAME                 DATA      AGE
bunny-proxy-config   1         7m

我的配置图：

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  labels:
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

我们有同样的问题。

我删除了整个发行版，然后重新安装。 目前，它似乎正在工作。

$ helm del --purge bunny

我也有这个问题

客户端：＆version.Version {SemVer：“ v2.8.0”，GitCommit：“ 14af25f1de6832228539259b821949d20069a222”，GitTreeState：“ clean”}
服务器：＆version.Version {SemVer：“ v2.8.0”，GitCommit：“ 14af25f1de6832228539259b821949d20069a222”，GitTreeState：“ clean”}

这在我们使用头盔时经常发生，并且需要完整的--purge 。 那不是解决方案。

如果使用CI / CD，则不适用。
如果升级失败并且您使用滚动更新策略，将会发生什么。 我必须删除仍在工作的版本吗？

当出现“部署”问题或类似问题时，我也看到相同的问题，但是创建了秘密/ cm，但随后Helm失去了对它的跟踪，拒绝让您做很多事情。

我什至很少见到它发生在即使是不间断的发行中（即，它似乎已经通过），但是我还没有弄清楚是什么原因引起的。

在向现有头盔部署中添加资源时，我们还能够重现此问题（服务器v2.8.2）。 每次必须添加新资源时都必须删除部署并重新部署，这将是生产中的大问题。

在我们的例子中，我们向图表添加了一个configmap，而该图表无法通过以下方式升级：

错误：升级失败：没有名为““ 成立

注意：我们使用的是2.7.2；

我相信会发生这种情况，因为当舵手确定发生了什么变化时，它会在旧版本中寻找新的configmap资源，但找不到它。 请参阅https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276 -L280以获取此错误来源的代码。

升级失败的分iller日志：

[tiller] 2018/05/03 19:09:14 preparing update for staging-collector
[storage] 2018/05/03 19:09:14 getting deployed release from "staging-collector" history
[tiller] 2018/05/03 19:10:39 getting history for release staging-collector
[storage] 2018/05/03 19:10:39 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:41 preparing update for staging-collector
[storage] 2018/05/03 19:10:41 getting deployed release from "staging-collector" history
[storage] 2018/05/03 19:10:42 getting last revision of "staging-collector"
[storage] 2018/05/03 19:10:42 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:44 rendering collector chart using values
[tiller] 2018/05/03 19:10:44 creating updated release for staging-collector
[storage] 2018/05/03 19:10:44 creating release "staging-collector.v858"
[tiller] 2018/05/03 19:10:44 performing update for staging-collector
[tiller] 2018/05/03 19:10:44 executing 0 pre-upgrade hooks for staging-collector
[tiller] 2018/05/03 19:10:44 hooks complete for pre-upgrade staging-collector
[kube] 2018/05/03 19:10:44 building resources from updated manifest
[kube] 2018/05/03 19:10:44 checking 3 resources for changes
[tiller] 2018/05/03 19:10:44 warning: Upgrade "staging-collector" failed: no resource with the name "collector-config" found 
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v857"
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v858" 

当更改已部署服务的name标签时，也可能会发生其他问题。

我正在更改发行版中服务的名称，但无法通过以下方式升级：

错误：升级失败：找不到名称为“ new-service-name”的服务

我愿意创建一个PR来解决此问题，但是我想知道打算或建议的处理方式。 即使是允许--force优先的CLI标志也很棒。

同意重要性。

当您不能简单地删除部署时，这个问题可能会很奇怪。

我发现我们的问题是由于部署失败。

Helm不会在部署失败后尝试清理，这意味着像上面我添加的新ConfigMap这样的东西会被创建，但是在“先前”部署中没有引用。 这意味着当下一次部署发生时，Helm会在k8s中找到资源，并期望在最新部署的版本中（或类似内容；我不确定，它使用什么确切的逻辑来查找“先前”版本）来引用该资源以检查哪些内容有变化。 它不在该发行版中，因此它找不到资源，并且失败。

当开发图表时，这主要是一个问题，因为部署失败会使k8处于无法正确跟踪的状态。 当我弄清楚这是怎么回事时，我知道我只需要从k8s中删除ConfigMap并再次尝试部署即可。

@krishicks是的，这是复制它的一种方法。 我注意到，部署失败+从未创建的资源（即无效的configmap）也会导致这种情况，从而导致无法恢复的状态

我们也正在打这个。 @krishicks和@jaredallard提到的是同一问题：

1. 我们的部署失败：
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. 随后的任何更改（包括对其他发行版的更改）都将失败，并显示警告，例如
   Error: UPGRADE FAILED: no Service with the name "…" found

我将尝试使用helm upgrade --timeout …标志来减轻第一个问题，但是对我们来说，失败的部署阻止了所有事情。 此外，使用helm rollback …不能解决此问题。

作为helm upgrade …自动运行在我们的用例中， --auto-rollback为标志helm upgrade将是非常有益的，它恢复失败的变化。

在向图表添加新资源时，对于v2.7.2我正在发生这种情况。
是否有关于何时解决此问题的估计？

此问题应通过＃4146修复。

编辑：见下文

因此，我发现了＃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

@bacongobbler并不总是有效。 在某些情况下，删除它确实可行，但在某些情况下仍然无法正常工作。

可以通过手动干预和删除资源来轻松解决此问题

@bacongobbler请理解，此资源可能是生产名称空间的Service或Deployment对象，这可能（并且已经）严重破坏了我们的服务保证。

是的我知道。 我只是在解释并观察该错误的行为，以便其他人知道所涉及的内容。 :)

只需在不同的群集上两次遇到此问题。 每次使用configmaps。 删除资源并不能解决问题，因此我们必须删除整个发行版。

同样在这里。 不仅Configmap，我还有一个带有ServiceAccount的映射。

PVC在这里。 :)

基本上，每种类型的优先对象都会受到此bug的影响。

是否有专人解决此问题？ 已经有公关了吗？ 我可以帮忙吗？

我已经不止一次地被这个问题困扰，因为这是一个容易进入自己的境地，但是显然没有简单的方法可以摆脱。 我认为我的情况中的“好”部分是即使有发行错误，资源也会被更新（不确定是让我高兴还是担心）

我认为掌舵应该要么禁止用户进入这种错误状态，要么正确处理它。
除了删除所有内容（仅适用于非生产用途）之外，对此是否有任何真正的解决方案？

如果其他人可以确定删除资源无法解决问题的另一种极端情况，那么这对于确定解决该特定问题的根本原因将非常有帮助。 可能有多个路径可能导致相同的错误。

@Draiken不，我们尝试了多种解决方案，但它们似乎都不合理

a）不要按预期执行升级，或者
b）引入新的错误

我在这里写下了这些解决方案

我们也不能阻止用户进入这种错误状态。 我们已经研究了解决方案，但它们又都引入了一系列不同的问题。 一旦安装处于不一致状态，就很难在没有人工干预的情况下对其进行“修复”。 😢

对我有用的解决方法是在发生故障之前立即执行helm rollback ... 。 然后，我使用helm install -n new-test-release .验证图表是否可以在新版本上使用。

一切正常后，我清理测试版本并针对旧版本运行helm upgrade ... ； 并且一切正常。 这是一个烦人的解决方法，但它似乎可以工作。

我不知道这是否有帮助，但是我只是在测试集群和生产集群上都遇到了这个问题。

我对头盔文件所做的更改非常简单：
我有1个现有部署，带有关联的服务和poddisruptionbudget，但保持不变。
我添加了第二个部署，它具有自己的服务和poddisruptionbudget。
我增加了图表版本号。

运行头盔时，我第一次遇到此错误：

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: Deployment.apps "blah-blah" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"blah-blah", "chart":"blah-3", "name":"blah", "release":"project"}: `selector` does not match template `labels`

当再次运行头盔时，我现在一次又一次地收到此错误：

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: no Service with the name "blah-blah" found

当我删除所有内容并重新部署时，舵图当然可以在测试中工作。 不过，这并不是产品的真正选择。

@veqryn我

编辑：如果有人有兴趣尝试它，我可以将其推送到公共docker仓库中，并提供有关如何使用它的快速摘要。

@jaredallard，我们很感兴趣。 谢谢！

我知道维护人员可能不会推荐它，但是它总比没有好。

@jaredallard我们不能推荐补丁，只是因为它不会对自己的（参考：https://github.com/helm/helm/pull/4223#issuecomment-397413568）

但是，这很有趣：

每当遇到此问题时，我基本上都会在＃4146中使用我的构建，然后再交换回主线。

如果我没看错，建议您已找到一种解决方法，

a）绕过错误
b）允许人们按原计划升级资源

通过执行2 helm upgrade s：一个带有补丁，另一个不带？ 这可以帮助我们更好地确定根本原因以及如何解决此错误。

@bacongobbler我必须重新访问它以100％验证这是行为。 我会更新此评论，或在发表评论后再发表。

我知道维护人员可能不会推荐它，但是它总比没有好。

另外，为澄清起见，我不打算在那儿扔阴影！ 现在回头看看它的措词有点不好，对不起

我仍然对为什么我的头盔第一次失败而感到困惑。
直到我第二次尝试应用它时，它都没有得到no X with the name Y错误。

@veqryn我在上面链接的问题中首先写了关于此问题的方式的文章。 请仔细阅读评论； 如果尚不清楚，我们很乐意帮助您更详细地阐明问题。

对于懒惰者： https :

我确实读过，我的理解是问题出在您身上，因为您更改了服务的名称。

但是，我的任何服务或任何资源都没有更改名称。

在重新阅读您的评论并与我的工作人员交谈之后，我们找出了导致错误的原因：
我碰到了舵图的版本。
我的部署和服务将该图表版本称为标签。
标签更改时，Kube / helm不喜欢它，这是导致原始错误的原因。

解决方案（对我而言）是使用helm还原到上一次成功的部署，然后还原图表版本更改，以便图表版本保持不变，然后成功。

这个（丑陋的）修复对我有用：

1. 我收到错误消息：

helm upgrade az-test-2-prom ./prometheus --namespace monitor --set cluster_name="az-test-2" -f values.yaml
Error: UPGRADE FAILED: no ConfigMap with the name "az-test-2-prom-prometheus-grafana-config" found

1.查找最近的DEPLOYED版本

export TEMPLATE='{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.labels.STATUS}}{{"\n"}}{{end}}'
kubectl -nkube-system get cm -l 'OWNER=TILLER' -ogo-template="$TEMPLATE"

az-test-2-prom.v1   SUPERSEDED
az-test-2-prom.v10  SUPERSEDED
az-test-2-prom.v11  SUPERSEDED
az-test-2-prom.v12  SUPERSEDED
az-test-2-prom.v13  SUPERSEDED
az-test-2-prom.v14  SUPERSEDED
az-test-2-prom.v15  SUPERSEDED
az-test-2-prom.v16  SUPERSEDED
az-test-2-prom.v17  DEPLOYED
az-test-2-prom.v18  FAILED
az-test-2-prom.v19  FAILED
az-test-2-prom.v2   SUPERSEDED
az-test-2-prom.v20  FAILED
az-test-2-prom.v21  FAILED
az-test-2-prom.v22  FAILED
az-test-2-prom.v23  FAILED
az-test-2-prom.v24  FAILED
az-test-2-prom.v25  FAILED
az-test-2-prom.v26  FAILED
az-test-2-prom.v27  FAILED
az-test-2-prom.v28  FAILED
az-test-2-prom.v29  FAILED
az-test-2-prom.v3   SUPERSEDED
az-test-2-prom.v30  FAILED
az-test-2-prom.v4   SUPERSEDED
az-test-2-prom.v5   FAILED
az-test-2-prom.v6   SUPERSEDED
az-test-2-prom.v7   SUPERSEDED
az-test-2-prom.v8   SUPERSEDED
az-test-2-prom.v9   FAILED



md5-6d9e4edff5e9111525fecb734bfec15a



for ii in {17..30}
> do
>   kubectl -nkube-system delete cm az-test-2-prom.v${ii}
> done



md5-cf6357e67a21fb9f80abb7b78b9e5b8e



kubectl -nkube-system patch cm az-test-2-prom.v16 -p '{"metadata": {"labels": {"STATUS": "DEPLOYED"}}}'

** 4.（重要）查找所有资源（例如，自上次部署（v16）以来添加的现有新资源）并将其删除，例如
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

运行helm upgrade ...并查看Happy Helming

正如@ kosta709所说，恢复到最后部署的版本，（手动）修复图表或当前状态（无论有什么问题）并进行新的升级通常是可行的。

Helm是一款很棒的软件，如果命令的结果不稳定，可以将其丢弃在某些自动工作流程（CI / CD）中。

是否可以选择以已知方式最终实施解决方案，以（尝试）解决这一众所周知的（并且有点烦人）的问题？ 谢谢。

因此，最近我也经常遇到这个问题，足以让我自己解决这个问题。 首先，我创建了一个变通方法（
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686），这基本上会使Tiller以现有资源为起点，而不是从旧清单中获取资源。 尽管我确实相信核心开发人员不希望将其合并，因为它包含硬编码的行为，但对我来说，它的工作就像一种魅力。

在相同的行为下可能隐藏了两个错误，至少有一次，当这个错误咬我时，我不得不删除很多（> 40）资源，其中包括已经存在超过20个成功发行版本的资源。 但是在99％的情况下，只需删除新创建的（但仍然未知）资源即可。

因此，我一直在思考如何以正确的方式解决它。 我在下面描述。 核心开发人员请在这里纠正我，如果您同意我的看法，请仔细考虑。 如果是，我愿意领导这项工作并提供PR进行修复。

通常，Helm似乎在“补丁”模式下运行：如果用户以某种方式修改了资源，而新发行版本更改了其他一些参数，Helm会在两个修订版本之间计算并应用补丁-我相信它正在试图保持用户变更的完整性。

可悲的是，这使我们面临三路合并问题，因为我们有从旧清单中获取的资源版本，从新清单中获取的另一个版本以及从当前使用的资源中获取的另一个版本。 当冲突发生时，掌舵显然不利于解决冲突。

我认为正确的方法是选择更好的默认值（基本上合并我的分支会做得很长），或者为用户提供标志。 例如：

• --ignore-old-manifest=never （默认，当前行为）
• --ignore-old-manifest=create-only （适用于这种情况，当旧的清单没有资源的概念，但是资源已经存在时，我们可以将其作为新的基础，并在必要时对其进行修补）-我建议将其设为新默认。 这也将允许舵手开始拥有手动创建的资源的所有权。
• --ignore-old-manifest=always -仅出于完整性考虑，可能并非严格必要。 它将始终在当前资源和最新清单之间创建补丁，基本上删除所有用户修改。

当然，您可以重命名该标志以使用反向逻辑： --use-current-resources=never(currently default)/create-only/always或类似的东西。

稍后，可以从资源注释中获取此标志，例如：

annotations:
  helm.io/ignore-old-manifest: always

掌舵者可以识别每个资源并应用此策略。 我不确定舵手开发者是否想去那里；）

那么，您对此建议有何看法？

另请参阅问题＃3805，Helm开发人员正在考虑3路合并补丁。

同样的问题在这里。
尝试使用Google Cloud build设置CD / CI环境。
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

有趣的是，该部署存在：

kc get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
baobab           3         3         3            2           2d
baobab-ermis     1         1         1            1           23h
baobab-sidekiq   1         1         1            1           23h

这是我创建的第一张图表，我期望helm是解决在CI / CD环境中部署复杂应用程序的复杂性的解决方案。

掌舵人是否有能力在CI / CD管道中工作？

谢谢

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

我也遇到了这个问题，试图将头盔0.8.0升级到头盔1.0.0。

helm version --tls Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

升级图表需求时，我也一直在碰到这一点。 我看到Istio也遇到了这个错误，他们的安装文档使用helm template 。 这是解决此问题的方法吗？

查看https://github.com/helm/helm/issues/3805中的最新讨论

也有这个，最新的头盔2.10仍然会发生

现在是时候认真考虑这个问题了，距今已有2年了，许多人报告了相同的确切问题，这些问题使头盔无法在生产中使用，而当您的部署取决于头盔时，这确实是一个痛苦。

GitHub上的许多明星承担着巨大的责任

@ brendan-rius欢迎您提供代码来解决此问题或提出想法。 有关某些指针，请参见＃3805和＃4146。

@ brendan-rius，＃3805特别是有关此错误的最新讨论。 我强烈建议您对该线程进行阅读，以了解我们要面对的问题。

在此处重新发布我的评论，因为它比3向合并策略更与此问题相关：

如果三向合并对于Helm 2.yz中的新部署不可行，则何时将＃1193固定？ 该漏洞已经开放了将近两年，但没有针对Helm 2.0计划明确的解决方案。

在这一点上，我们对如何继续感到困惑。 我们已经讨论了该错误数周，并且通过引入新的错误或显着改变耕作机的升级行为，所有提议的解决方案都无法在所有情况下正常工作。

例如，本周早些时候，

1. 升级失败时，我们将自动回滚并删除在此发行版中创建的资源。

这具有很大的风险，因为升级失败后群集可能处于未知状态，因此Helm可能无法以干净的方式继续进行，从而可能导致应用程序停机。

1. 在升级过程中，如果我们正在创建一个新资源并且看到它已经存在，则可以将这些更改应用于现有资源，或者删除/重新创建它。

这非常危险，因为Helm可能会删除通过其他软件包或kubectl create安装的对象，而这两个用户都不想要。

到目前为止，最安全的选择是要求用户在发生这种冲突的情况下进行手动干预，下面将对此进行演示。

如果有人有建议/反馈/替代建议，我们很想听听您的想法。

@bacongobbler ，如果没有计划支持三向合并功能，则需要替代方法或解决方法。 否则，＃1193是一个非常痛苦的博克。

要重申该问题以及解决方法：

当安装新资源的升级失败时，发行版将进入FAILED状态并停止升级过程。 下次调用helm upgrade ，Helm将与上次DEPLOYED版本进行比较。 在上一个DEPLOYED版本中，该对象不存在，因此它尝试创建新资源，但是由于它已经存在而失败。 @arturictus指出，该错误消息完全具有误导性。

通过手动干预和删除错误报告为“未找到”的资源，可以轻松解决此问题。 遵循我在https://github.com/helm/helm/pull/4223#issuecomment -397413568演示的示例：

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
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

换句话说，删除在FAILED发布期间创建的资源可以解决此问题。

@bacongobbler首先，我要感谢您在过去几周中更详细地研究了此问题。 我不太确定问题是从Istio 0.8.0升级到Istio 1.0.0的到底是什么，或者它是否完全符合您的问题声明。 我的推测是，在发行前大约三天，某些以前不受管理的对象（即在安装后的作业中添加）已迁移为未安装在安装后的作业中。

在与具有大量Helm经验的Istio操作员社区交谈时，一些操作员告诉我们，Helm中不受管理的资源是个坏消息，并且经常导致升级失败。 如果Istio图表的实现存在一个缺陷，使它们与Helm 2.yz的升级不兼容，那么解决这些不兼容问题就非常好-因此，将来我们不会出现升级失败的情况。

我们愿意将0.8.0的1倍命中率升级到1.0.0。 如果不断升级，那就是另一个问题。

我在Istio上执行了bisect-升级工作一直持续到7月27日（在Istio 1.0.0发行版之前3天），发现此提交存在问题： https :

该PR实质上从安装后作业中删除了对象注册。 我相信，但不确定，我们已经在Istio 1.0.0的3天启动中删除了所有安装后作业实例。

您可以就与升级有关的Istio特定Helm图表提供建议吗？ 将对象注册保留在安装后的工作之外是否会永久解决我们的升级问题？

我真的没有提供任何强有力的建议或建议来解决这个问题，因为在Helm方面有较新经验的人无法找到通用的解决方案（而且不是因为没有研究这个问题）。 我认为我不能做得更好。

干杯
-史蒂夫

更新了标题以更好地反映错误。

我们也受到该问题的影响。 我们使用最新的头盔2.10和GKE 10.6。
我什么时候可以解决？
我们对此问题有合理的解决方法吗？ 使用--purge选项删除整个部署非常糟糕。

请随时评论我的最新评论。 我们确实需要有关如何最好地进行此处的反馈。

此线程中已多次重复解决方法。 请阅读https://github.com/helm/helm/issues/1193#issuecomment -419555433。

我喜欢掌舵自动回滚功能（选项1 ）来解决此问题的想法。 我们知道最新的已部署Helm发行版正在运行，并且集群处于良好状态，因此应该可以安全地恢复到该集群。 如果在某些用例中有风险，则可以通过标记选择加入头盔升级。

这具有很大的风险，因为升级失败后群集可能处于未知状态，因此Helm可能无法以干净的方式继续进行，从而可能导致应用程序停机。

我认为许多掌舵用户会通过CD或CM工具以自动化方式使用掌舵，而将掌舵发布保持为FAILED状态则存在更大的风险。 发行失败的那些不完整的资源可能会意外影响其他资源，并可能导致停机。 例如，如果pod规范包含某个丢失的映像版本，而该映像版本以某种方式进入了生产环境，则您的工作负载将处于无法正常工作的ImagePullBackOff状态。 对于我们公司而言，情况甚至更糟，因为我们有一些本地客户可以通过我们的UI进行自我升级，如果失败，我们必须获得对其系统进行调试的权限。

即使不考虑它可以解决此问题的事实，自动回滚也将是一个有用的功能，并且将有助于确保Helm发布本质上更具事务性。 它使Helm从尽力而为的部署转向优先考虑稳定性和成功的部署。

@bacongobbler将以下方法用于新部署是否可行：

• 添加标志- -three-way-merge
• 仅允许在helm install使用该标志（新部署）
• 启用此标志后，升级将始终使用三向合并
• 现有的部署将没有迁移路径而陷入困境-人们目前正在使用的标准解决方法是helm delete --purge然后是helm reinstall因此这可能并不像它初次出现时那样令人讨厌。

这真的可以解决问题吗？

一些人正在考虑实施操作员以解决此Helm限制。 那将是一个严重的耻辱。 参见https://github.com/istio/istio/issues/8841#issue -361871147

干杯
-史蒂夫

回到@bacongobbler的早期评论：

1. 在升级过程中，如果我们正在创建一个新资源并且看到它已经存在，则可以将这些更改应用于现有资源，或者删除/重新创建它。
   这非常危险，因为Helm可能会删除通过其他软件包或通过kubectl create安装的对象，而这两个用户都不希望这样做。

我想知道我们是否可以通过启用新行为来减轻这种风险？ 在给定的名称空间中，我通常只使用Helm，我怀疑很多情况都是这样。 如果我可以给Helm安装/升级一个标志来告诉它，给定名称空间中不属于现有发行版的任何内容都可以删除/覆盖，那会有所帮助吗？

由于您还说过“通过其他软件包”，因此我认为您不希望Helm在执行发行时必须检查其他发行版，因此，我的建议仅适用于“每个名称一个发行版”模型。 为了回答该异议，我会说：如果您想在一个命名空间中管理多个包并仍然得到这种行为，请创建一个伞形图，其唯一目的是指定所需的图表依赖关系。 然后在部署该伞形图时使用新标志（“ --exclusive”？）。

显然，这并不能解决所有用例的问题，但也许可以解决这个问题。

@bacongobbler我可能离这里很远。 我在升级中面临类似的问题。 从解决这个问题有多困难来判断，我想知道是否需要重新考虑一些更根本的问题。 复杂性的部分原因似乎是由于Helm维护其自己的已知配置版本，而不是实际的真实来源kubernetes。 如果Helm仅保留以前已部署的Helm图表的副本以用于历史记录和回滚，但在升级过程中完全不使用它，那么该系统是否会更可靠？ 取而代之的是，Helm会从kubectl本身获取真相，然后始终要进行2向比较？

如果舵图表明它应该具有资源X，而kubectl看到了现有的资源X，则：

• 如果将现有资源标记为由Helm控制，则Helm执行所需的升级
• 如果现有的资源没有标记为通过头盔被控制，然后头盔失败用干净的错误信息（或某些命令行标志可用于--force升级并导致头盔采取现有资源X的所有权）。

如果helm图表说它应该有资源X，而根据kubectl却没有，那么Helm就会创建它。

如果kubectl报告其具有标记为由此舵图控制的资源Y，并且此舵图中没有资源Y，则舵将删除该资源。

在执行升级时，舵始终会忽略未被未标记为由此舵表控制的任何资源，除非在上述情况下，舵表说它需要资源X和X存在但没有被标记。

如果出于某种原因成功推出了Helm图表并失败了，并且只有一半的资源被推出，那么在回滚期间，Helm将使用先前成功部署中存储的配置文件并运行完全相同的算法，或执行其他操作相对于某些头盔命令行标志，它可能处于断开状态。 如果用户再次尝试升级，因为kubernetes被用作事实的来源，而不是最近一次成功的成功部署，那么它仍然应该是新掌舵图和系统现有状态之间的简单2向差异。

我们也看到了这个问题。 我们的复制步骤：

1. helm install可以成功安装部署的图表
2. 更新图表以在现有部署之外添加自定义资源
3. 更改部署podspec的映像以模仿部署失败
4. helm install新图表。 这将导致部署的滚动更新，而我们故意将其设置为失败。
5. 头盔安装应失败。 但是自定义资源应保留在k8s etcd中。 （使用kubectl ）
6. （此时，头盔处于不良状态）
7. 修复图表-将goot映像放入部署podspec中。
8. helm install 。 我们希望这能奏效，但事实并非如此。 报告“名称为___的无资源”。 名称是自定义资源的名称。
9. 恢复：使用kubectl删除剩余的自定义资源。 现在helm install可以使用了。

请注意，图表中新引入的自定义资源在helm install上的首次尝试必须无法进入此状态。

@ rbair23我们更早尝试过，但是没有用。 有一个Apply Working Group正在通过修复kubectl apply来

由于＃3275已关闭，其副本与之相同：我们遇到的情况与＃3275类似

已经有一个正在运行的作业my-long-running-job 。 我们正在尝试升级版本：

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: no Job with the name "my-long-running-job" found

该工作存在：

>kubectl -n=my-environment get jobs
NAME                                DESIRED   SUCCESSFUL   AGE
my-long-running-job                 1         0            16m

删除该作业：

>kubectl -n=my-environment delete job my-long-running-job
job.batch "my-long-running-job" deleted

解决该障碍：

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: timed out waiting for the condition

至少消息no Job with the name "my-long-running-job" found具有误导性，但是我的期望是，作业也会被更新。

在v2.9.1（当前发布的稳定版本）中仍然看到了这一点

我不同意退出升级是“非常危险的”。 我认为这样做是正确的解决方案。

Kubernetes是声明性的。 在尝试升级之前，快照一下集群的状态。
如果途中出现错误，请回滚到快照。
如果某人具有脚本挂钩，则在执行此操作时会使群集处于不良状态，那是他们自己的错。 （也许也可以通过回滚钩解决）

当然，如果升级前未进行升级且未首先提出升级文件，那就太好了。
例如，在尝试更改任何内容之前，应该可以检查由值或--set参数生成的依赖关系图中的错误。 诸如忘记更改版本号之类的事情也可以预先进行处理，以避免在无法使用时进行更改。

你好，

在以下方面存在相同的问题：

客户端：v2.10.0 + g9ad53aa
伺服器：v2.10.0 + g9ad53aa

删除serviceAccount，configMap和service是使Helm升级版本的唯一方法。

你好，

我们有与@dilumr描述的版本2.11.0相同的问题：

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Error: UPGRADE FAILED: no ConfigMap with the name "xxx" found

在v2.9.1上使用它。

我正在运行的图表升级正在私有图表上跳了几个主要版本，并且进行了许多更改，因此我不确定是什么触发了错误，但这是部署最初以FAILED状态结束的原因是我有一个--wait标志，并且超时。

我们最终在helm list进行了几个重复的FAILED部署，但是最后一个有效的部署是DEPLOYED 。 创建新部署会抛出No resource with the name x found 。

能够修复通过运行helm rollback的最后一个版本是在DEPLOYED状态上helm list 。 升级之后，该程序可以正常运行。

看看这个https://github.com/helm/helm/pull/4871。

像其他事物一样，当我的上一个部署失败时，这个错误似乎是最经常发生的（我不确定总是会发生），而该部署中的新资产却被安装了。

我了解从失败的Helm部署中卸载组件可能是棘手的和/或不希望的，但是在这种情况下理想的Helm行为是什么？

首先，如果要（重新）安装名称空间和其他资源，我认为Helm应该可以使用它。 Kubernetes的全部目的是“正确配置，让kube弄清楚如何使世界与配置相匹配”。
其次，我认为赫尔姆应该是全有还是全无。 如果部署失败，则群集应处于部署开始之前的状态。
如果有两个版本都希望创建名称空间X，则存在引用计数问题。 如果有一个要创建名称空间X的发行版，但它已经存在，则存在出处问题。 但是，头盔可以使用对象上的注释记录下来，并做正确的事情。

我也在最新的头盔2.12.0和kubernetes 1.10.11中遇到了这个问题，甚至回滚到最新的良好版本，因为@aguilarm建议不起作用，并且删除了头盔所抱怨的资源也无济于事，并且在升级之后如果命令失败，它将保留与实际部分重新创建相同的资源。 产品环境非常烦人...

我有2个集群，它们的环境非常相似，两个集群之间的主要区别是节点总数。 在一种情况下， helm delete --purge后跟新的helm install可行的，但在另一种情况下则没有，我还没有找到一种将其应用于最新模板更改的方法。

这有什么ETA吗？

我可以使用helm rollback解决此问题，并指定最新的修订版（失败的修订版）

今天有同样的问题
Error: UPGRADE FAILED: no Service with the name "xxx-api" found
kubectl get svc -n stage | grep xxx-api
xxx-api ClusterIP 172.20.149.229 <none> 8300/TCP 19h
helm rollback工作。

在进行头盔升级时，我们经常会遇到这种情况-这种情况发生在成功部署之后，而不仅仅是失败的部署。 我们无法掌控delete --purge，因为这些生产系统具有非平凡的组件，这些组件1）不可能不可用，并且2）从头开始完全恢复需要很长时间才能被接受。

请参阅我上面发布的诊断和解决方法。 让我知道这是否适合您。

@bacongobbler感谢您的答复。 实际上，这也是我想出的解决方法，它现在已经足够了，但是我们每天通过CICD使用头盔升级的次数很多次，因此，这种升级经常令人头疼。 我不确定以上内容是否完整，因为命名的资源通常已经存在，是成功部署的一部分，并且在当前部署中不会更改-iirc几乎总是上次成功部署中的最新资源集虽然很有趣。

+1到@ajcann并感谢@bacongobbler
我处于完全相同的情况。
我们的CICD是自动化的，并且部署通常是由松弛机器人在较低环境下完成的。
当失败时，我必须手动执行头盔回滚并再次部署。
这个问题根本不是一致的，但很常见。
对我来说，它仅发生在到目前为止的图表/资源的第二次部署期间。
资源永远存在。

我们观察到同样的问题。 如果您有一个模板，则会发生这种情况：

• 在{{if $condition -}}语句中
• 或{{ range $index, $value := $array-}}

@jkroepke刚刚向我指出，PR＃5143为此提供了一个很好的解决方法。 在下一个次要版本中释放--atomic标志时，应该可以使用它在出现错误时自动清除或回滚。

@bacongobbler鉴于您已经参与了这一过程的大部分来回操作，是否有其他方法可以完全解决此问题，或者--atomic标志是否足够？

我认为@distorhead可能想看一看它是否也解决了他在https://github.com/helm/helm/pull/4871中提出的担忧假设您始终使用--atomic标志，看起来--atomic应该解决该问题。

我不认为有任何提议的解决方案可以解决您进入此特定状态时遇到的问题，但是我可能是错的。 如果此问题的缓解策略是

• 手动通过集群的实时状态并按照解决方法对其进行修复
• 升级到Helm 2.13.0并继续使用helm upgrade --atomic

然后我认为可以安全关闭了。

希望Helm 2.13.0不会那么遥远。
如果发行版中某处发生错误，则此错误会破坏CI。

原子无法解决问题

图表示例： https :

1. 签出主服务器，运行部署。

git clone https://github.com/distorhead/ex-helm-upgrade-failure
cd ex-helm-upgrade-failure
helm upgrade --atomic --install --namespace myns myrelease .

图表包含2个部署- myserver1和myserver2 ：

Release "myrelease" does not exist. Installing it now.
NAME:   myrelease
LAST DEPLOYED: Tue Feb  5 23:48:57 2019
NAMESPACE: myns
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Deployment
NAME       READY  UP-TO-DATE  AVAILABLE  AGE
myserver1  1/1    1           1          5s
myserver2  1/1    1           1          5s

1. 做出重大改变。 从图表中删除部署myserver1并使用用户错误修改部署myserver2 （例如，删除图像字段）：

git checkout break-atomic
git diff master

diff --git a/templates/deploy.yaml b/templates/deploy.yaml
index 198516e..64be153 100644
--- a/templates/deploy.yaml
+++ b/templates/deploy.yaml
@@ -1,21 +1,5 @@
 apiVersion: apps/v1beta1
 kind: Deployment
-metadata:
-  name: myserver1
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        service: myserver1
-    spec:
-      containers:
-      - name: main
-        command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04
----
-apiVersion: apps/v1beta1
-kind: Deployment
 metadata:
   name: myserver2
 spec:
@@ -28,4 +12,3 @@ spec:
       containers:
       - name: main
         command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04

1. 运行部署：

git checkout break-atomic
helm upgrade --atomic --install --namespace myns myrelease .

再次向我们的朋友问好：

UPGRADE FAILED
ROLLING BACK
Error: Deployment.apps "myserver2" is invalid: spec.template.spec.containers[0].image: Required value
Error: no Deployment with the name "myserver1" found

@bacongobbler @ thomastaylor312 @jkroepke

@distorhead在这种情况下，您的预期行为是什么？

关于回滚略有偏离，但无论如何。

对于那些想要使用回滚但又不希望在部署后由于某些原因而像--atomic那样立即回滚的人。 因为，例如，用户无法在失败后手动检查不良的群集状态，并且因为--wait标志不会导致Helm在正在部署的资源中记录有关失败的任何信息。 然后有一些方法：在升级之前，在下一次运行中回滚（更多信息，https：//github.com/helm/helm/issues/3149#issuecomment-462271103）

要重申该问题以及解决方法：

当安装新资源的升级失败时，发行版将进入FAILED状态并停止升级过程。 下次调用helm upgrade ，Helm将与上次DEPLOYED版本进行比较。 在上一个DEPLOYED版本中，该对象不存在，因此它尝试创建新资源，但是由于它已经存在而失败。 @arturictus指出，该错误消息完全具有误导性。

通过手动干预和删除错误报告为“未找到”的资源，可以轻松解决此问题。 按照我在＃4223中展示的示例

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
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

换句话说，删除在FAILED发布期间创建的资源可以解决此问题。

感谢您将此解决方法放在一起@bacongobbler-本质上，这也是我们作为一个过程而来的。 这里一个痛苦的问题是，在复杂的升级过程中，许多新资源-有时有几个依赖级别很深-可能会发现自己处于这种状态。 我还没有找到一种以自动方式完全枚举这些状态的方法，从而导致人们需要反复失败地升级到“搜索”所有相关资源的情况。 例如，最近新添加的依赖项本身对PostgreSQL图表具有依赖项。 为了解决此问题，有必要删除一个秘密，configmap，服务，部署和pvc-每个都发现很长的路要走。

您可以编写类似于helm diff的插件，该插件将枚举在上一发行版中创建的模板。 您甚至可以直接从Helm消费pkg/kube 。 client.Update编写了一些用于掌舵资源跟踪/删除的业务逻辑，可以通过从Tiller中获取两个版本并反转比较顺序来重用这些逻辑。 target.Difference(original)应该为您提供自上一版本以来引入的所有资源的结果。

@bacongobbler您建议采用哪种解决方案来将应用程序作为版本A的一部分进行部署（例如，由多个应用程序组成的较大版本），然后将其从版本A拆分为自己的版本（反之亦然），而不会导致任何停机时间（删除资源的解决方法会导致一些停机时间）...尝试通过其他发行版更新资源会导致此Github问题所描述的错误。

听起来好像已经安装了这个新图表，并在成功部署之前就替换了旧图表。 升级失败--install同样。 如果图表错误，则不会安装。
只需在发生错误时回滚到以前的状态，或在成功后更新分er图。

这是我用来解决此问题的过程（到目前为止，它每次都能正常工作，没有任何事件……但还是要小心）：

1. 运行helm list并查找受影响图表的最新修订

   NAME        REVISION UPDATED                  STATUS  CHART              NAMESPACE
   fetlife-web 381      Thu Mar 15 19:46:00 2018 FAILED  fetlife-web-0.1.0  default
   

2. 从那里查找具有DEPLOYED状态的最新修订版
   kubectl -n kube-system edit cm fetlife-web.v381 kubectl -n kube-system edit cm fetlife-web.v380 kubectl -n kube-system edit cm fetlife-web.v379 kubectl -n kube-system edit cm fetlife-web.v378
3. 找到最后一个DEPLOYED版本后，将其状态从DEPLOYED更改SUPERSEDED并保存文件
4. 尝试再次执行helm upgrade ，如果成功，那就完成了！
5. 如果遇到这样的升级错误：
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   然后将最新修订的状态从FAILED为DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381
6. 尝试再次执行helm upgrade ，如果再次失败，只需翻转桌子...

@bacongobbler @michelleN
有什么原因使得很难改善此问题的错误消息？

我相信错误消息应该指出“存在冲突，因为资源不是由掌舵者创建的，需要手动干预”，而不是“未找到”。 只有对错误的这一小改动，才能大幅度改善用户体验。

@selslack我非常支持改进错误消息👍

@michelleN我已经准备好PR以更改错误文本：＃5460。

我遇到了这个问题，但我不确定如何解决。

我在这里尝试了@reneklacan列出的所有步骤： https :

不幸的是，这没有用。 解决此问题的唯一方法是删除生成错误消息的资源，然后再次helm upgrade ，这将成功。

但是，下一次掌舵升级将失败，并出现相同的错误，我必须再次删除资源并重新升级...这是不可持续的，也不是好事。

作为CI流程的一部分，我有两个使用Helm进行部署的环境：一个QA和一个生产环境。

质量检查环境存在相同的问题，因此我使用helm delete --purge ，然后使用helm upgrade -永久解决了该问题。

但是，我不能在生产环境中执行此操作-我不能只擦除它并重新升级，所以目前我一直坚持在每次部署之前删除资源。 我很幸运，这不是进口资源。

@zacharyw您目前正在No resource with the name ...或"fetlife-web" has no deployed releases ？

您是否可以分享其他任何有助于调试的信息？

也许输出kubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS= （代替YOUR_RELEASE_NAME ）

如果您不想通过可能不相关的数据（rene（at）klacan（dot）sk）向该问题发送垃圾邮件，请随时给我发送一封包含更多信息的电子邮件。

请参阅https://github.com/helm/helm/issues/1193#issuecomment -419555433了解可能的诊断和解决方法@zacharyw。

@reneklacan这是no resource with the name ...错误。 在我们的例子中，我们添加了一个入口，它似乎可以正常工作，但是随后的升级由于该错误而开始失败...即使该入口已经存在。

我最近发布的状态（删除有问题的入口并允许通过头盔升级重新创建后）的状态为DEPLOYED ：

STATUS=DEPLOYED
VERSION=197

但是，如果我尝试再次升级，它将失败。

@bacongobbler除非引起我的误会，否则我认为我已经在做此注释中的解决方法：删除资源并重新创建资源...问题是我必须每次都执行此操作。

@reneklacan在https://github.com/helm/helm/issues/1193#issuecomment -470208910救了我的命。

令人失望的是，Helm失败了。 在几乎任何环境中删除事物都不是理想的选择。

如果在出现这种错误时helm更新了它自己的数据库，然后重试，那将是很好的。

我相信启用--cleanup-on-fail标志后，这种错误情况就会消失。 通过＃4871和＃5143解决关闭问题。

如果还有其他问题没有这些标志出现，请重新打开一个新的问题。 谢谢！

该问题已解决，我想添加一条有关如何处理该问题的注释，而不必删除helm版本或正在运行的部署。

因此，我通过以下步骤重现了该问题：

1. 使用服务模板安装图表test-chart-failure 。
2. 添加带有服务模板的子图表，该服务模板的服务端口中包含字符串（例如“ test”）
3. 升级图表。 它将失败，并显示错误Service in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ...

通过在http://centosquestions.com/helm-how-to-delete-bad-deployment中应用建议，我可以在将端口更正为一个数字后升级，而无需运行helm delete ：

1. 用helm history test-chart-failure找到失败的修订
2. 使用kubectl delete cm -n kube-system test-chart-failure.v2删除了特定版本的配置图
3. 用更正后的图表执行了helm upgrade