是否有等同于 "argocd app wait" 或 "helm upgrade --wait" 的 FluxCD？

Question

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

$ 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的就绪探测（以及liveness探测）：

$ 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中有没有类似的东西可以达到同样的效果呢？

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

P.S。 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

Answer 1

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

我建议投资于 pods 的适当准备探测器。 Helm/FluxCDv2 将等待所有 pods 准备就绪。 Liveness 探针有不同的用途。 Kubelet 使用 liveness probes 来了解何时重启容器。通常他们对 Helm/Flux.

不感兴趣

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

Answer 2

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

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

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

无论如何，至于这种行为的来源seemingly/clearly 不是用户想要的（即使它看起来是用户所要求的，这可能是值得商榷的）：

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

是否有等同于 "argocd app wait" 或 "helm upgrade --wait" 的 FluxCD？

Is there a FluxCD equivalent to "argocd app wait" or "helm upgrade --wait"?

flux

kubernetes-helm

fluxcd