是否有相当于“argocd app wait”或“helm upgrade --wait”的 FluxCD？

Posted 2023-02-22

【中文标题】是否有相当于“argocd app wait”或“helm upgrade --wait”的 FluxCD？

【英文标题】：Is there a FluxCD equivalent to "argocd app wait" or "helm upgrade --wait"?

【发布时间】：2021-09-28 10:31:46

【问题描述】：

我执行以下操作来部署掌舵图（您可以复制并粘贴我的命令序列来重现此错误）。

$ flux --version
flux version 0.16.1

$ kubectl create ns traefik

$ flux create source helm traefik --url https://helm.traefik.io/traefik --namespace traefik

$ cat values-6666.yaml
ports:
  traefik:
    healthchecksPort: 6666   # !!! Deliberately wrong port number!!!

$ flux create helmrelease my-traefik --chart traefik --source HelmRepository/traefik --chart-version 9.18.2 --namespace traefik --values=./values-6666.yaml
✚ generating HelmRelease
► applying HelmRelease
✔ HelmRelease created
◎ waiting for HelmRelease reconciliation
✔ HelmRelease my-traefik is ready
✔ applied revision 9.18.2

所以 Flux 报告它是成功的，并且可以这样确认：

$ flux get helmrelease --namespace traefik
NAME        READY   MESSAGE                             REVISION    SUSPENDED
my-traefik  True    Release reconciliation succeeded    9.18.2      False

但实际上，如上所示，values-6666.yaml 包含一个故意错误的端口号 6666，用于 pod 的就绪探针（以及活性探针）：

$ kubectl -n traefik describe pod my-traefik-8488cc49b8-qf5zz
  ...
  Type     Reason    ... From     Message
  ----     ------    ... ----     -------
  Warning  Unhealthy ... kubelet  Liveness  probe failed: Get "http://172.31.61.133:6666/ping": dial tcp 172.31.61.133:6666: connect: connection refused
  Warning  Unhealthy ... kubelet  Readiness probe failed: Get "http://172.31.61.133:6666/ping": dial tcp 172.31.61.133:6666: connect: connection refused
  Warning  BackOff   ... kubelet  Back-off restarting failed container

我的目标是让 FluxCD 自动检测上述错误。但是，如上所示，FluxCD 认为它是成功的。

以下任一部署方法都会检测到该故障：

$ helm upgrade --wait ...

或

$ argocd app sync ... && argocd app wait ...

那么，FluxCD 中有没有类似的东西可以达到同样的效果？

================================================ ======================

附： Flux docs here 似乎暗示与 helm --wait 等效的已经是 FluxCD 中的默认行为。我上面的测试表明它不是。此外，在以下示例中，我将其显式设置为disableWait: false，但结果相同。

$ cat helmrelease.yaml
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: my-traefik
  namespace: traefik
spec:
  chart:
    spec:
      chart: traefik
      sourceRef:
        kind: HelmRepository
        name: traefik
      version: 9.18.2
  install:
    disableWait: false      # !!! Explicitly set this flag !!!
  interval: 1m0s
  values:
    ports:
      traefik:
        healthchecksPort: 6666

$ kubectl -n traefik create -f helmrelease.yaml
helmrelease.helm.toolkit.fluxcd.io/my-traefik created

  ## Again, Flux deems it a success:
$ flux get hr -n traefik
NAME        READY   MESSAGE                             REVISION    SUSPENDED
my-traefik  True    Release reconciliation succeeded    9.18.2      False

  ## Again, the pod actually failed:
$ kubectl -n traefik describe pod my-traefik-8488cc49b8-bmxnv
... // Same error as earlier

【参考方案1】：

FluxCD v2 默认使用 Helm 的 --wait 选项。 通常，您可以在 HelmRelease 对象中使用 CLI 的任何 Helm 参数： https://fluxcd.io/docs/components/helm/helmreleases/

我建议对您的 pod 进行适当的就绪探测。 Helm/FluxCDv2 将等待所有 pod 准备就绪。活性探针有不同的用途。 Kubelet 使用 liveness probes 来了解何时重新启动容器。通常它们对 Helm/Flux 不感兴趣。

如果您有复杂的应用程序生命周期，请查看Kubernetes Operators - (C) Jason Dobies，Joshua Wood。在 kstatus 和 kustomize 的帮助下，您可以让 Flux 等待您的自定义资源准备就绪。

【讨论】：

这与我在原始帖子中未显示的就绪探针相同。现在我已经修改了我的原始帖子以显示完整的命令序列（您可以复制并粘贴以重现错误）以及就绪探针的失败。

【参考方案2】：

Helm 认为具有一个副本和策略 rollingUpdate 且 maxUnavailable 为 1 的部署在已部署且有 1 个不可用 pod 时已准备就绪。如果您测试 Helm 本身，相信您会发现上游的 Helm CLI / Helm SDK 包中存在相同的行为。

（即使部署的唯一一个 pod 已进入 CrashLoopBackOff 并且准备就绪和活动性检查都失败了...... maxUnavailable 为 1 且副本数为 1，从技术上讲，部署不超过允许的不可用 pod 数量，所以它被认为是准备好了。）

这个问题最近在https://github.com/fluxcd/helm-controller/issues/355 再次提出，我在那里提供了更深入的反馈。

无论如何，至于这种行为的来源，这似乎/显然不是用户想要的（即使它似乎是用户特别要求的，这可能是值得商榷的）：

至于 Helm，这似乎与 GitHub 报告的问题相同：

helm install --wait does not wait for deployment pod readiness properly - (helm/helm#3173) 并在这里复活： helm upgrade --wait does not wait on newer versions - (helm/helm#10061)