是否有相当于"argocd应用程序等待“或”舵机升级--等等“的FluxCD？

Question

我执行了以下操作来部署一个舵图(您可以复制并粘贴我的命令序列来复制此错误)。

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

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

P.S. 通量文档似乎暗示，与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

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

(即使部署的唯一一个pod已经进入CrashLoopBackOff，准备状态和活性检查都失败了.在maxUnavailable为1和副本为1的情况下，技术上部署的不可用荚数不超过允许的数量，因此被认为已准备就绪。)

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

无论如何，对于这种行为的来源，这种行为似乎/显然不是用户想要的(即使这似乎是用户要求的具体内容，这可能是值得商榷的)：

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

• 舵机安装-等待不等待部署舱准备就绪-(舵机/舵机#3173)和复活在这里：
• 舵机升级-等待不等待更新版本- ( helm /helm#10061)

Answer 2

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

我建议对你的吊舱进行适当的准备性探测。舵机/FluxCDv2 2将等待所有的吊舱准备就绪。活性探针有不同的用途。Kubelet使用活性探针来知道何时重新启动容器。通常，它们对Helm/Flux不感兴趣。

如果您有一个复杂的应用程序生命周期，那么看看Kubernetes算子 - (C) Jason，Joshua。在kstatus和kustomize的帮助下，您可以让通量等待您的自定义重新源准备就绪。