1

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

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

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

PS 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
4

2 回答 2

1

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 报告的问题相同：

于 2021-11-11T14:01:36.877 回答
0

FluxCD v2 默认使用--waitHelm 选项。一般来说，您可以在 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 等待您的自定义资源准备就绪。

于 2021-08-06T12:37:58.573 回答