<p>helm upgrade --install 不再有效</p>

我以为我遇到了同样的问题，但结果我只是有一个旧的删除（但没有清除），释放挂起。 检查 helm list -a ，如果您的版本在那里，请 helm delete --purge releasename。 helm upgrade -i在 2.7.2 上为我成功工作。

这是修复有关升级处于不良状态的版本的问题的副作用。 https://github.com/kubernetes/helm/pull/3097是解决此问题的 PR。 这里是否存在我们未能捕捉到的边缘情况？

像@tcolgate提到的那样检查helm list -a ，也许还解释了如何重现它也有助于确定它是未捕获的边缘情况还是错误。

也有同样的问题，以及重复的版本名称：

$>helm ls -a|grep ingress
nginx-ingress               9           Thu Nov 30 11:33:06 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               11          Thu Nov 30 11:37:58 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               12          Thu Nov 30 11:38:50 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               8           Thu Nov 30 11:31:27 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               10          Thu Nov 30 11:33:53 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
$>helm diff nginx-ingress ./nginx-ingress
Error: "nginx-ingress" has no deployed releases

升级时，显示什么消息？

与上面的差异相同的错误，但安装会说它已经安装。

我的意思是在之前的升级尝试中最终处于 FAILED 状态。 我想知道我们如何进入所有版本都处于失败状态的情况。

哦，重复的发布名称部署？ 我不确定，我经常得到它。 有时它们都处于 DEPLOYED 状态，有时混合 FAILED 和 DEPLOYED。 我们使用持续更新每个 PR 合并的 CI/CD Jenkins 服务器，因此我们每天执行几次helm upgrade ，通常只有一个新的容器标签。 通常，在查看部署的内容时，重复项很烦人，这是我们第一次遇到它们的难题，通常我们不会像在这种情况下那样升级入口控制器。

我似乎得到了类似的结果，我在发布列表中看到了一些重复项：

$ helm ls
NAME                      REVISION    UPDATED                     STATUS      CHART                           NAMESPACE
.....
front-prod                180         Tue Dec  5 17:28:22 2017    DEPLOYED    front-1                         prod
front-prod                90          Wed Sep 13 14:36:06 2017    DEPLOYED    front-1                         prod 
...

它们似乎都处于 DEPLOYED 状态，但很可能是之前的升级在某个时候失败了，因为我已经多次遇到该错误。 我还在 K8S 1.7 上，所以还没有更新到 helm 2.7。

同样的问题，无法升级失败的部署

在这里使用 2.7.2 相同。 第一次尝试发布失败。 然后，当我尝试升级时 --install 我收到错误“错误：升级失败：“${RELEASE}”没有部署的版本”。

2.7.2 也有同样的问题， helm upgrade --install失败：

Error: UPGRADE FAILED: "APPNAME" has no deployed releases

如果使用helm del --purge APPNAME完全清除该版本，则后续的upgrade --install可以正常工作。

我遇到了同样的问题。 结合#3134 ，在没有一些脚本解决方法的情况下，没有自动幂等部署的选项。

@winjer只是尝试用 --purge 删除，对我来说它没有用，尽管错误改变了
/ # helm upgrade foo /charts/foo/ -i --wait
错误：升级失败：“foo”没有部署的版本
/ # helm delete --purge foo
释放“foo”已删除
/ # helm upgrade foo /charts/foo/ -i --wait
发布“foo”不存在。 现在安装它。
错误：发布 foo 失败：deployments.extensions“foo-foo-some-service-name”已经存在

@prein这是因为您的服务不是 helm 的“所有者”，但已存在于集群中。 你所经历的行为对我来说似乎是正确的。 部署无法成功，因为 helm 必须“取得”以前不拥有的 API 对象的所有权。

如果新清单实际上是正确的并且不满足集群中的任何其他资源，则能够升级 FAILED 版本确实有意义。

我也在一个名为content的版本中看到了这种行为：

helm upgrade --install --wait --timeout 300 -f ./helm/env/staging.yaml --set image.tag=xxx --namespace=content content ./helm/content
Error: UPGRADE FAILED: no resource with the name "content-content" found
helm list | grep content
content                         60          Mon Dec 25 06:02:38 2017    DEPLOYED    content-0.1.0                   content           
content                         12          Tue Oct 10 00:02:24 2017    DEPLOYED    content-0.1.0                   content           
content                         37          Tue Dec 12 00:42:42 2017    DEPLOYED    content-0.1.0                   content           
content                         4           Sun Oct  8 05:58:44 2017    DEPLOYED    k8s-0.1.0                       content           
content                         1           Sat Oct  7 22:29:24 2017    DEPLOYED    k8s-0.1.0                       content           
content                         61          Mon Jan  1 06:39:21 2018    FAILED      content-0.1.0                   content           
content                         62          Mon Jan  1 06:50:41 2018    FAILED      content-0.1.0                   content           
content                         63          Tue Jan  2 17:05:22 2018    FAILED      content-0.1.0                   content           

我将不得不删除它才能继续部署，如果我能做些什么来帮助调试它，请告诉我。
（我认为我们应该重命名这个问题，因为它更多地是关于重复的？）
（我们也运行2.7.2 ）

我的集群上实际上有另一个重复版本，如果您有任何命令让我运行以帮助调试它？ 让我知道！

刚刚升级到分蘖 2.7.2，我们看到了同样的事情。 helm delete RELEASE_NAME后跟helm upgrade RELEASE_NAME .失败并显示Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases 。 upgrade是恢复已删除（但未清除）版本的预期方式，对吗？

看起来您可以通过回滚到已删除的版本来恢复发布。

看到与v2.7.2相同的问题，当没有以前成功部署的版本时失败

还看到此问题的两个潜在版本：

在 CI：

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: "api-feature-persistent-data" has no deployed releases

在我的本地机器上：

（在我的 OSX bash 和 gcloud/kubectl 容器中）

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: no PersistentVolumeClaim with the name "api-feature-persistent-data-db" found

对于我们的图表，警告是正常的。
错误很有趣，因为我们的一个子图表中有一个pvc.yaml 。

helm del --purge <release>确实缓解了这个问题。
这确实使我们的 CI 管道难以升级。

@adamreese这个问题的最终解决方案是什么？ 我们在 2.8 上，但仍然无法通过更改为helm list来升级以前的FAILED版本。

特别是，我们遇到了以下类型的问题：

• 部署一个版本，OK
• upgrade --install --wait ，但也许有一个小错误并且--wait没有成功（例如，活性探针永远不会弥补）
• 修复图表后， upgrade --install --wait失败， xxx has no deployed releases

删除/清除在这里是不可取的或不可接受的：发布可能有多个资源（pod、负载均衡器），它们不受一种不会上升的资源的影响。 在以前的 Helm 版本中， upgrade --install允许我们只修补破坏完整版本的更改，而不必删除所有资源。

Helm 始终是此处涉及的所有资源的所有者——该资源仅标记为FAILED因为--wait没有成功等待所有资源都处于良好状态。 我认为如果 Pod 启动太慢以及在许多类似情况下也会发生同样的情况。

@peay见#3353 进行后续讨论。

谢谢 - 这清除了它。 实际上意识到我们只是在我们没有成功发布时才开始使用它。 在这种情况下，清除是一个很好的解决方法。

如果安装失败，这种情况仍然会发生。
您需要清除并重试。

UPGRADE FAILED: "API" has no deployed releases
那么你需要手动清除
helm delete --purge API
它会起作用。

从 helm 2.9 开始，您还可以执行helm upgrade --install --force因此无需清除。 对于以前的版本：

helm delete API
helm install --replace --name API ./mychart

@bacongobbler我仍然对这种行为感到困惑。
有时间可以回答一下https://github.com/kubernetes/helm/pull/3597#issuecomment -382843932吗？

感谢您在这方面所做的工作。

当然。 我现在 AFK，但我可以在今晚晚些时候回答。 完全理解这种困惑，我会尽量回答你的问题。 在办公室为 KubeCon EU 准备其他东西真是太疯狂了。 :)

当我们在那里时，我愿意帮助解决这个问题和/或改进文档。
让我们一定见面：+1：

@bacongobbler这个地址是 #3353 并否定我作为 #4004 的一部分编写的一堆代码吗？

在我的情况下helm upgrade --install --force做了一个delete --purge ，然后安装。

这是预期的行为吗？ 因为这个，我几乎失去了两个月的工作。 force开始表示delete ？

^ 我与 kubecon 的人进行了一些对话，发现由于这种行为改变，相当多的团队被固定到 v2.7.0。

我同意upgrade install永远不应该是破坏性的，即使--force可能意味着什么。

@bacongobbler ，很抱歉，我们在 CPH 外出时无法见面。
更改行为以不允许升级失败版本的理由背后是否有文档？
旧的行为似乎比我们现在的行为更可取。

请参阅https://github.com/kubernetes/helm/issues/3353 中的第二条评论，了解我们为何必须进行更改的背景背景

我真的很想知道建议的前进道路是什么。 由于 #3353 中展示的问题，我们无法退出 #3097，因此我很想听听社区认为解决此问题的正确途径是什么。 我们可以退出#3597，但据我所知，没有好的解决方案可以解决helm upgrade --install问题。 ：失望的：

我知道我们正在努力为 Helm 3 重新设计应用逻辑，但这还有很长的路要走

感谢您链接@bacongobbler :)
您在这里的建议听起来是一个合理的方法：

在没有部署成功的版本时不执行差异可能很有价值。 体验将与用户第一次运行 helm install 时相同，因为没有“当前”版本可与之进行比较。 不过，我会有点担心某些边缘情况。 @adamreese你对这个有什么意见吗？

这将允许我们退出 #3597，因为将解决唯一的失败情况（没有区别）。
这使得upgrade --install再次成为非破坏性的并且更类似于kubectl apply 。

直观地说，这就是我希望upgrade --force做的事情：不要执行差异和补丁操作，而只是应用完整的模板，而忽略当前的内容。 我真的想不出任何技术原因为什么这不可能，但我也不熟悉 Helm 的内部工作原理。
它仍然可能是一个危险的操作，但任何使用--force标志的人通常都会通过强制更新来预期一定的风险。 虽然我认为人们不希望这会删除并重新创建您的部署，并可能导致停机。

我已经阅读了所有讨论，但我仍然不清楚如何使用幂等的upgrade --install命令（或命令序列）。

使用当前的稳定版本，我如何在自动化脚本中实现这一点？ 我需要能够在不使用delete --purge情况下以非交互方式进行部署，即使之前的尝试失败了。

至于未来的计划，这是我最初期望upgrade --install ：

• 如果之前没有安装，则安装
• 升级之前成功的安装
• 替换之前失败的安装
• 如果安装失败，旧资源应该仍然存在，尽可能不停机
• 没有破坏性操作（例如上面提到的自动delete --purge ）

在我个人看来，这种行为不需要额外的标志。 这就是包管理器通常的行为方式。 除非我误解了要求，否则我认为不需要--force标志，例如。

是否有任何更新？ 在现有安装上可靠地运行升级而不必在出现故障时运行清除的正确方法是什么？

@MythicManiac FWIW：
由于这种行为，我仍然将我们的团队固定在 v2.7.0 上。
当他们应该在此版本中使用helm upgrade --install ，我们似乎对资源升级和删除没有任何问题。

我们也有这个问题。 非常烦人，因为 helm has no deployed releases需要删除 K8s 服务和相关的 AWS ELB。 包管理器很棒，但这个问题会导致生产停机，这是不好的。

作为一个非常hacky的解决方法，如果源部署的问题是
可解析（例如，预先存在的服务。），回滚到原始服务
失败的发布可以工作。

2018 年 10 月 5 日星期五，Eugene Glotov， notifications @github.com 写道：

我们也有这个问题。 很烦我要删除K8s
服务和相关的 AWS ELB，因为 helm 没有部署的版本。 这
包管理器很棒，但这个问题会导致生产停机
不好。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/helm/helm/issues/3208#issuecomment-427436187或静音
线程
https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz
.

@tcolgate ，谢谢！ 我刚刚用您的解决方法解决了另一个问题 (https://github.com/helm/helm/issues/2426#issuecomment-427388715)，并将在下周在现有资源上部署新图表时尝试测试它是否存在 ELB .

回滚到最初的失败版本是可行的。

@tcolgate ，我刚刚测试过，不，它在第一次部署的情况下不起作用。

$ helm upgrade --wait --timeout 900 --install myproject charts/myproject/myproject-1.1.1.tgz
14:53:18 Release "myproject" does not exist. Installing it now.
14:53:18 Error: release myproject failed: deployments.apps "myproject" already exists

$ helm list
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
myproject       1           Mon Oct  8 11:53:18 2018    FAILED      myproject-1.1.1                 default

$ helm rollback myproject 1
Error: "myproject" has no deployed releases

我很好奇，如果 Helm 无法在现有资源上部署图表，那么为什么helm delete会导致完全删除这些资源？

@thomastaylor312 ，我们在https://github.com/helm/helm/issues/2426~ （上：我找到了 2426 的真正根本原因）。 你认为他们应该重新开放吗？

我在Error: UPGRADE FAILED: "xxx-service" has no deployed releases之后找到了这个线程
虽然它是从头盔 ls -a 可见的。

我决定看看这是否是一个问题，因为 --set 值不正确，并且 --debug --dry-run --force 实际上仍然删除了我正在运行的 pod ......我的期望是空运行操作永远不会修改集群资源。

不过它确实有效，并且可以在之后重新部署该服务，但我们遇到了停机时间。

我的期望是试运行操作永远不会修改集群资源。

这是一个公平的期望——我们应该让那......不会发生

我相信这是在https://github.com/helm/helm/pull/4402中修补的，但如果有人要检查会很好。 对于那个很抱歉！

升级到 2.11.0 后同样的问题

交叉岗位：
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

为什么这是关闭的？ 我们现在有适当的方法来处理这个问题吗？

@gerbsen ，当前版本的 Helm 没有办法解决这个问题，这是非破坏性的。
我们仍然将 Helm 2.7.0 用于我组织中的所有内容。 这是一个非常旧的版本，有其他错误，但没有这个问题。

只是让helm upgrade --install --force做了一个delete --purge并在没有告诉我的情况下销毁了我的 pvc/pv（关于回收）。 有几个失败的版本，所以它处于在 kubernetes 中运行的状态，但是 helm 认为没有正在运行的版本。 根本不是好时光。

@notque在两次丢失所有 grafana 仪表板之后我已经开始在进行任何类型的升级之前进行备份，这种风险消除了使用 helm 的所有好处

对于那些寻求帮助的人，在将 helm 升级到 v.2.15.2 后问题就消失了

仍然在2.16.0上看到这个问题

为什么还是关门了？ 2.16.1 仍受影响

@nick4fake我认为它是https://github.com/helm/helm/issues/5595的副本