Alauda Container Platform
简体中文

故障排查

目录

我删除/损坏了我的仓库，无法删除我的应用怎么办？

如果 Argo CD 无法生成清单，则无法删除应用。您需要执行以下操作之一：

  1. 恢复/修复您的仓库。
  2. 使用 --cascade=false 删除应用，然后手动删除资源。

为什么我的应用在成功同步后仍然显示为 OutOfSync？

请参阅差异比较文档了解资源可能处于 OutOfSync 状态的原因，以及如何配置 Argo CD 在预期存在差异时忽略字段。

为什么我的应用卡在 Progressing 状态？

Argo CD 为多种标准 Kubernetes 类型提供健康状态。Ingress、StatefulSet 和 SealedSecret 类型存在已知问题，可能导致健康检查返回 Progressing 状态而非 Healthy。

  • 当 status.loadBalancer.ingress 列表非空且至少包含一个 hostname 或 IP 值时，Ingress 被视为健康。一些 ingress 控制器（如 contour、traefik）不会更新 status.loadBalancer.ingress 字段，导致 Ingress 永远卡在 Progressing 状态。

  • 当 status.updatedReplicas 字段的值与 spec.replicas 字段匹配时，StatefulSet 被视为健康。由于 Kubernetes 的 bug kubernetes#68573，status.updatedReplicas 可能未被填充。除非您使用包含修复 kubernetes#67570 的 Kubernetes 版本，否则 StatefulSet 可能会一直处于 Progressing 状态。

  • 您的 StatefulSet 或 DaemonSet 使用了 OnDelete 策略而非 RollingUpdate 策略。

  • 关于 SealedSecret，请参阅为什么类型为 SealedSecret 的资源卡在 Progressing 状态？

作为解决方案，Argo CD 允许提供健康检查自定义，以覆盖默认行为。

如果您使用 Traefik 作为 Ingress，可以通过更新 Traefik 配置，使用 publishedservice 发布 loadBalancer IP，从而解决此问题。

providers:
  kubernetesIngress:
    publishedService:
      enabled: true

如何禁用管理员用户？

在 argocd-cm ConfigMap 中添加 admin.enabled: "false"。

Argo CD 无法在无网络访问的情况下部署基于 Helm Chart 的应用，如何解决？

如果 Helm Chart 依赖于外部仓库中的依赖项，Argo CD 可能无法生成 Helm Chart 清单。为解决此问题，确保 requirements.yaml 仅使用内部可用的 Helm 仓库。即使 Chart 仅使用内部仓库的依赖，Helm 仍可能尝试刷新 stable 仓库。作为解决方案，可在 argocd-cm 配置映射中覆盖 stable 仓库的 URL：

data:
  repositories: |
    - type: helm
      url: http://<internal-helm-repo-host>:8080
      name: stable

使用 Argo CD 创建 Helm 应用后，为什么无法通过 helm ls 和其他 Helm 命令查看？

部署 Helm 应用时，Argo CD 仅将 Helm 用作模板机制。它执行 helm template，然后将生成的清单部署到集群，而不是执行 helm install。这意味着您无法使用任何 Helm 命令查看或验证应用。应用完全由 Argo CD 管理。请注意，Argo CD 原生支持一些 Helm 可能缺失的功能（如历史记录和回滚命令）。

此设计使 Argo CD 对所有清单生成器保持中立。

我配置了集群 secret，但在 CLI/UI 中看不到，如何解决？

检查集群 secret 是否带有标签 argocd.argoproj.io/secret-type: cluster。如果 secret 有该标签但集群仍不可见，可能是权限问题。尝试使用 admin 用户列出集群（例如：argocd login --username admin && argocd cluster list）。

为什么我的应用即使同步后仍然 Out Of Sync？

某些工具可能会与 Argo CD 产生冲突，添加 app.kubernetes.io/instance 标签，例如使用 Kustomize 的 common labels 功能。

Argo CD 会自动设置 app.kubernetes.io/instance 标签，并用它来确定哪些资源属于应用。如果其他工具也设置该标签，会导致混淆。您可以通过在 argocd-cm 中设置 application.instanceLabelKey 来更改此标签。建议使用 argocd.argoproj.io/instance。

INFO

更改此设置后，您的应用将变为 Out Of Sync，需要重新同步。

Argo CD 多久检查一次我的 Git 或 Helm 仓库的更改？

默认轮询间隔为 3 分钟（180 秒），并带有可配置的抖动。您可以通过更新 argocd-cm 配置映射中的 timeout.reconciliation 和 timeout.reconciliation.jitter 来更改此设置。如果有 Git 变更，Argo CD 仅会更新启用 auto-sync 设置的应用。如果将其设置为 0，则 Argo CD 将停止自动轮询 Git 仓库，您只能使用其他方法，如 webhooks 和/或 manual syncs 来创建应用。

如何解决 invalid cookie，超过最大长度 4093 的问题？

Argo CD 使用 JWT 作为认证令牌。您可能属于多个组，导致超过了 cookie 设置的 4KB 限制。您可以通过打开“开发者工具 -> 网络”获取组列表：

  1. 点击登录 Argo CD 监控面板，如何获取 Argo CD 访问信息
  2. 找到对 <argocd_instance>/auth/callback?code=<random_string> 的调用

在 jwt.io 解码令牌。这样您可以查看团队列表，并将自己从不需要的团队中移除。

为什么使用 CLI 时出现 rpc error: code = Unavailable desc = transport is closing？

可能您处于不支持 HTTP 2 的代理后面？尝试使用 --grpc-web 参数：

argocd ... --grpc-web

为什么类型为 SealedSecret 的资源卡在 Progressing 状态？

SealedSecret 资源的控制器可能会在其所管理的资源上暴露状态条件。从 v2.0.0 版本起，Argo CD 会读取该状态条件以推断 SealedSecret 的健康状态。

SealedSecret 控制器 v0.15.0 之前的版本存在状态条件更新问题，因此默认禁用此功能。可以通过启动 SealedSecret 控制器时添加 --update-status 命令行参数或设置环境变量 SEALED_SECRETS_UPDATE_STATUS 来启用状态条件更新。

若要禁用 Argo CD 检查 SealedSecret 资源的状态条件，请在 argocd-cm ConfigMap 中通过 resource.customizations.health.<group_kind> 键添加以下资源自定义：

resource.customizations.health.bitnami.com_SealedSecret: |
  hs = {}
  hs.status = "Healthy"
  hs.message = "Controller doesn't report resource status"
  return hs

如何轮换 Redis 密钥？

  • 删除 Argo CD 安装命名空间中的 argocd-redis secret。

    kubectl delete secret argocd-redis -n <argocd namesapce>

  • 如果您以 HA 模式运行 Redis，重启 HA 模式的 Redis。

    kubectl rollout restart deployment argocd-redis-ha-haproxy
kubectl rollout restart statefulset argocd-redis-ha-server

  • 如果您以非 HA 模式运行 Redis，重启 Redis。

    kubectl rollout restart deployment argocd-redis

  • 重启其他组件。

    kubectl rollout restart deployment argocd-server argocd-repo-server
kubectl rollout restart statefulset argocd-application-controller

如何解决 Manifest generation error (cached)？

Manifest generation error (cached) 表示生成清单时出现错误，且错误信息已被缓存以避免重复重试。

执行硬刷新（忽略缓存的错误）可以解决临时问题。但如果清单生成持续失败，硬刷新无效。

建议搜索 repo-server 日志中与应用名称相关的错误，以确定导致清单生成失败的原因。