#故障排查

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

如果 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。

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

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

#如何解决 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>

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

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

• 如果您运行的是非 HA 模式，重启 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 日志，搜索应用名称，以确定导致清单生成失败的具体错误。