掌舵错误：发布需要回滚才能升级

Question

在我的集群中，我使用weave flux 和他们的flux-helm-operator 以gittops 方式管理我的集群。

但是，当我在 Flux git 存储库中对图表进行更改时，我经常遇到以下错误消息：

ts=2019-09-25T11:54:37.604506452Z caller=chartsync.go:328 component=chartsync
warning="unable to proceed with release" 
resource=mychart:helmrelease/mychart release=mychart
err="release requires a rollback before it can be upgraded (FAILED)"

我不确定它在 helm 中是什么意思，但无论如何，我不应该运行任何 helm 命令，因为版本是由 Flux 管理的，所以我想知道在生产中处理此错误的正确方法是什么

（除了删除版本并等待通量重新创建它）

一个解释清楚的答案将被非常接受，谢谢。

Answer 1

让我们深入了解helm-operator的代码

警告unable to proceed with release 出现在GetUpgradableRelease 之后

    // GetUpgradableRelease returns a release if the current state of it
    // allows an upgrade, a descriptive error if it is not allowed, or
    // nil if the release does not exist.

如果发布状态为Status_FAILED，则返回错误release requires a rollback before it can be upgraded（参见release.go#89）

UNHEALTHY状态块释放

作为flux 开发人员mentioned in #2265，没有办法滚动到UNHEALTHY 状态。

这不是错误，但我可以看到您的期望来自哪里。

Flux 只会将健康的版本向前推进，这样做的原因之一是确保我们不会陷入失败循环，因此--force 标志不打算用于强制升级不健康的版本资源（您应该为此使用rollback feature），但开发它是为了可以使用例如升级图表向后不兼容的更改（例如，不可变字段的更改需要先删除资源，请参阅#1760）。

结论：forceUpgrade 很受尊重，但不能用于强制升级处于UNHEALTHY 状态的版本。

Rollback

按照作者的建议，您应该使用rollback 功能

Helm 操作员所做的发布有时可能会失败，可以通过在 HelmRelease 资源上将 .spec.rollback.enable 设置为 true 来自动回滚失败的发布。

Note: a successful rollback of a Helm chart containing a StatefulSet resource is known to be tricky, and one of the main reasons automated rollbacks are not enabled by default for all HelmReleases. Verify a manual rollback of your Helm chart does not cause any problems before enabling it.

启用后，Helm 操作员将检测到错误升级并执行回滚，除非检测到值和/或图表发生变化，否则不会尝试新升级。

apiVersion: flux.weave.works/v1beta1
kind: HelmRelease
# metadata: ...
spec:
  # Listed values are the defaults.
  rollback:
    # If set, will perform rollbacks for this release.
    enable: false
    # If set, will force resource update through delete/recreate if
    # needed.
    force: false
    # Prevent hooks from running during rollback.
    disableHooks: false
    # Time in seconds to wait for any individual Kubernetes operation.
    timeout: 300
    # If set, will wait until all Pods, PVCs, Services, and minimum
    # number of Pods of a Deployment are in a ready state before
    # marking the release as successful. It will wait for as long
    # as the set timeout.
    wait: false