Helm: 如果首次安装失败，“ helm upgrade --install”将不执行安装/升级

这是https://github.com/kubernetes/helm/pull/3097的设计所故意的

• https://github.com/kubernetes/helm/issues/2257
• https://github.com/kubernetes/helm/issues/2341
• https://github.com/kubernetes/helm/issues/2346
• https://github.com/kubernetes/helm/issues/2437
• https://github.com/kubernetes/helm/issues/3068

如果您的初始发行版最终处于失败状态，建议您通过helm delete --purge foo清除发行版，然后重试。 成功的初始发行版之后，所有后续失败的发行版均将被忽略，并且掌舵功能将与上一个已知的成功发行版有所不同。

话虽如此，如果尚未成功部署发行版，则不执行差异可能很有价值。 体验将与用户第一次运行helm install ，即不会有任何“当前”发行版可与之抗衡。 我会有点担心某些极端情况。 @adamreese您对此有任何意见吗？

建议的修补程序在自动化系统中似乎完全站不住脚。 我绝对不希望所有援引头盔的人都必须知道“如果第一个发行失败，请删除并重试”。 首先，我的大多数工具都不知道它是安装还是升级，或者是第一次还是第100次，它几乎总是在运行helm upgrade --install 。

我还想指出，我对原始PR https://github.com/kubernetes/helm/pull/3097#discussion_r151808599进行了评论。

在这种情况下，旧行为会更好。
我同意@chancez。 这使得upgrade --install在常见情况下不等幂。

@bacongobbler
如果我们担心由于钩子失败而导致发布失败并留下碎片，那么我会说这是图表中的设计问题。 （当挂钩是幂等时，挂钩会更好地工作）
用户可以自由构建围绕头盔的错误处理和非幂等行为。

我们还关注哪些其他极端情况？
似乎＃3097会照顾很多人👍

如果我可以使helm upgrade -i甚至在Failed版本失败的情况下至少有一定的参数组合，那么我的本地开发将变得更加顺畅。 我的用例是当我有一个包含许多发行版的脚本时，我知道我要启动一个本地开发环境。

这可能是类似于--replace标志helm install 。 需要注意的是--replace是仅有的两个标志之一helm install是在缺少helm upgrade ，另一个是--name-template 。

绝对要明确，是的，这将是一件好事。 在我们忙于其他工作的同时，有人想要破解吗？

你好，
我已经创建了PR https://github.com/kubernetes/helm/pull/3437 ，它可以解决此问题

我不确定为什么我们需要install和upgrade命令，我只使用upgrade --install命令，似乎很多人都这样做。 我只需要一个执行upgrade --install并且不会因失败的运行而跳闸的命令。 我们是否可以将upgrade --install重命名deploy ，使其真正等幂，并抛弃其他两个？

（我正在尝试使用新的变体，在2.8.0中出现此问题。自从2.7.2升级以来，如果我安装失败，则依次升级delete --purge和upgrade --install ，我仍然会收到Error: UPGRADE FAILED: "xyz" has no deployed releases错误。似乎--purge在2.8.0中没有完全有效，并且分er器处于list --all没有显示的卡住状态。然后转到install ，使耕作机回到可以再次执行通常的upgrade --install 。）

我同意@whereisaaron ，使用deploy命令更像kubectl apply ，我会很好的。 也使Helm的自动化变得更加容易，因为您不必检查某些shell脚本疯狂中是否存在发行版：)

也许解决方案是让头盔自动运行helm delete --purge ？
就像是：
1）用户执行helm upgrade --install
2）首次发布失败
3）用户对图表进行一些更改，然后再次执行helm upgrade --install
4）Helm尝试运行命令
5）它失败，并且恰好有一个先前的发布处于失败状态
6）头盔默默执行helm delete --purge
6）清除后，Helm自动重试helm upgrade --install并显示其输出

也许可以通过--force标志触发此行为，该标志在其他情况下已经具有类似的行为

想法很好，但我不认为我们应该永远删除释放台账未经用户明确要求删除这些数据。 Helm的运营商将想要了解为什么服务无法从先前失败的版本升级，或者通过从分类帐中收集该数据来推断失败的原因。

我在该线程的前面提供了

@rchernobelskiy也发生在我身上。 正是您所描述的。

部署新应用程序时，我可能每天都会遇到此问题。
真痛苦！

@gmanolache出于这个原因，我们仍在掌舵2.7.0。
我不清楚升级到使用--force标志是否安全：评论

如果您需要降级，这是一个很好的方法：降级到2.7.0

这个听起来有用的“ helm分类帐”诊断信息是什么，我们如何得到它？ ：微笑：

我担心以下内容可能会让人感到无聊，这实际上只是一个邀请，以指导您在部署失败时如何获取诊断信息。 因为这听起来真的像我在漏东西。 听起来好像失败状态应该对操作员有用吗？ 我再次浏览了头盔手册网站； “ helm get manifest”之类的东西会在失败的状态下工作以提取有用的诊断信息吗？

当我部署失败时，我的用户体验是您没有获得有用的信息。 Helm拒绝所有部分创建/剩余的资源，以使“ helm status”不显示任何内容。 您所能做的就是“回滚”或“删除--purge”（您不能只是“删除”，否则CI的“升级--install”将一直失败）。 失败状态似乎只能用来打破我们都渴望部署CI的“ upgrade --install”的幂等性。

在CI情况下使用“ --auto-rollback”选项是否合理，例如“ upgrade --install --auto-rollback”。 我通常宁愿回滚，必须下床处理失败的状态😆😴💤

这个听起来有用的“ helm分类帐”诊断信息是什么，我们如何得到它？ 😄

helm help history

谢谢@bacongobbler。 好的，我知道清单就是分类帐的含义。 如果您仍然有分类帐，则可以使用helm get manifest --revision 123来查看部署失败的内容？ 这对于保存当然是有用的。 如果我们rollback我们不会丢失该信息。

History prints historical revisions for a given release.

A default maximum of 256 revisions will be returned. Setting '--max'
configures the maximum length of the revision list returned.

The historical release set is printed as a formatted table, e.g:

    $ helm history angry-bird --max=4
    REVISION   UPDATED                      STATUS           CHART        DESCRIPTION
    1           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Initial install
    2           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Upgraded successfully
    3           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Rolled back to 2
    4           Mon Oct 3 10:15:13 2016     DEPLOYED        alpine-0.1.0  Upgraded successfully

如果我们有helm upgrade --install --auto-rollback那么失败部署的两个回滚都将记录在分类帐中，并可供操作员使用。 这对于防止CI部署进入难以解决的“失败”状态（在这种情况下，“ helm upgrade --install”停止工作）大有帮助。 CI部署失败通常是开发人员将错别字/错误注入到部署系统中。 使用'--auto-rollback'，他们可以检查保留在部署服务器日志中的helm命令错误消息，修复和部署更正的值。

我想即使没有'--auto-rollback'选项，我们也可以在helm update --install返回“ FAILED”错误的任何时候使用包装器自动运行helm rollback 。 也许可以检测到它的初始安装位置，在这种情况下，可以使用helm delete --purge代替。

也就是说，我们可以使用包装器脚本来确保CI'helm upgrade --install'的结果始终处于始终可以进行下一个CI'helm upgrade --install'的状态。 保留分类帐信息以用于任何失败的尝试（至少对于其初始安装有效的发行版）。

helm deploy =

• helm upgrade --install
• 如果失败，那么
  
  
  
  • 如果版本= 1
  
  
  • 然后helm delete --purge
  
  
  • 否则helm rollback
  
  

@whereisaaron这将是优雅👍

除了helm rollback要使用的helm history ${name} | tail -2 | head -1 | awk '{print $1}'类的东西以外，是否有一种简单的方法来获取最新的工作版本？

你好呀，

我正在使用Helm 2.12.2，但仍然存在问题，即在第一次部署失败时，Helm会失败。 这可能是回归吗？

我不确定这是否是回归，但实际上从未对其进行过“修复”。

@ RickS-C137我认为应该使用helm upgrade --install --force此问题，该问题将“删除”然后“安装-替换”失败的版本。

仍然尝试在我尝试使用的Jenkins管道中解决此问题。
我正在尝试部署应用程序的新映像，因此不管部署是否已经存在，我都不会在乎。
我想运行一个命令来替换当前部署，或者如果不存在则直接安装它。
我试过helm install --replace我经常得到Error: a released named xyz is in use, cannot re-use a name that is still in use这显然杀死了我的管道，构建失败了。

@bacongobbler您如何看待https://github.com/helm/helm/issues/3353#issuecomment -385222233？

我看不到如果在初始发行版失败的情况下销毁并重新创建初始发行版会造成停机或数据丢失的情况。

我在我们的构建中实现了这一点：

if helm history --max 1 "$name" 2>/dev/null | grep FAILED | cut -f1 | grep -q 1; then
    helm delete --purge "$name"
fi

helm upgrade --install --wait "$release" chart/

当前使用helm，在不检查当前状态的情况下您不知道要使用哪个helm命令和选项组合。 对于给定的头盔命令，您不知道要获得什么，因为它取决于当前状态。 这不是声明性的理想状态梦☁️💤

在头盔3中，我们可能会弃用install / upgrade / --replace / --upgrade / --force并将它们全部替换为幂等的helm deploy要么达到所需状态，要么保持状态不变。 也许使用与上述类似的算法，如果helm deploy失败，则回滚（修订版> 1）或删除+清除（修订版= 1），以保持之前的状态。 失败的清单仍可以通过helm history/get 。 对于想要将部署保持在失败状态以进行调查的人员，甚至可以使用“-不回滚”选项

helm upgrade --install --force的选项越来越近了，除了不回滚和升级，它删除并替换了失败的版本（即使版本> 1），这使某些人对＃3208感到愤怒... 💥

目前，我们可以使用包装脚本或元工具（例如helmsman其功能列表部分使用helm但可以缓解此问题：

• 幂等性：只要所需的状态文件没有更改，您就可以多次执行Helmsman并获得相同的结果。 _ [...不管当前状态如何] _
• 从失败继续：如果由于特定的图表部署失败而导致部分部署，则修复头盔图表并再次执行Helmsman，而无需先回滚部分成功。

将它们全部替换为幂等头盔部署，该部署要么达到所需状态，要么保持状态不变

回想起来，这是一个惊人的显而易见的设计目标。

你好，
在我们的情况下，初始发行版并没有真正失败……只是安装超时后我们的应用程序没有完全启动，或者是其他一些固定的奇怪问题得以解决。 无论如何，该应用程序都可以正常运行，因此必须删除它对我们来说是个问题（我们附加了一些永久性存储，这些存储也将被删除！）。

当初始版本“显然失败”但实际上还可以时，是否有任何解决方法来部署图表？

那么结论是upgrade --force太强了，也就是说，有时候delete + replace + retry_upgrade对于升级失败不是正确的补救方法吗？

是否有单独的问题跟踪将install和upgrade合并到deploy命令中的想法？

并不是我知道@dcow。 helm upgrade --install命令的用例是什么？

https://github.com/helm/helm/issues/3353#issuecomment -362497951

我不确定为什么我们需要安装和升级命令，我只使用过升级--install命令，似乎很多人都这样做。 我只需要一个执行升级--install并且不会因失败的运行而跳闸的命令。 我们是否可以仅重命名upgrade --install进行部署，使其真正成为幂等，然后放弃其他两个？
...

和

https://github.com/helm/helm/issues/3353#issuecomment -469109854

当前使用helm，在不检查当前状态的情况下您不知道要使用哪个helm命令和选项组合。 对于给定的头盔命令，您不知道要获得什么，因为它取决于当前状态。 这不是声明性的理想状态梦云zzz微笑

在头盔3中，我们可能会弃用install / upgrade /-replace /-upgrade /-force，并将它们全部替换为幂等头盔部署，这些部署要么达到所需状态，要么保持状态不变。
...

我通常同意舵应该像kubectl apply并尝试实现所需的现实，而不是根据集群的状态运行不同类型的命令。 希望能够为一个专门的问题提供支持，或者存在一个问题，或者至少弄清楚解决方案是什么，因为deploy当前未实现，而我们正在使用3.2。

@dcow好吧，您要创建一个问题然后与您的提案一起吗？

@hickeyma完成了https://github.com/helm/helm/issues/8415！