4、初始配置:argocd-cm ConfigMap 详解、默认参数与自定义配置入口
Argo CD 的核心配置几乎全部集中在 argocd-cm ConfigMap 中。该 ConfigMap 位于 argocd 命名空间下,是平台工程师调整 Argo CD 行为、集成外部系统、定义 UI 风格以及控制 Git 仓库连接参数的首要入口。理解其默认参数结构,是进行后续调优和扩展的基础。
4.1 argocd-cm 的核心定位
argocd-cm 是一个标准的 Kubernetes ConfigMap,Argo CD 的 argocd-server 和 argocd-repo-server 组件在启动时会读取它。它不包含敏感信息(如密码、),敏感配置应放在 argocd-secret 中。该 ConfigMap 采用 YAML 格式的键值对存储,其中大部分配置项以 data 字段下的多行字符串形式存在。
配置生效机制: 修改
argocd-cm 后,无需重启 Pod。Argo CD 组件会通过文件系统 watch 机制自动热加载变更。通常等待 30-60 秒即可生效。
4.2 默认参数详解与分类
默认安装的 argocd-cm 通常只包含少量必要字段。以下表格列出了最核心的默认参数及其作用域,平台工程师应优先掌握这些配置入口。
| 配置键 (Key) | 默认值 / 示例 | 作用域 | 说明 |
|---|---|---|---|
url |
https://localhost:8080 |
全局 | Argo CD 的外部访问 URL,用于 SSO 回调、Webhook 通知等。 |
repositories |
空列表 | 仓库 | 预配置的 Git 仓库列表(非敏感信息),支持 SSH 和 HTTPS 连接。 |
repository.credentials |
空列表 | 仓库 | 仓库凭据模板,用于匹配多个仓库的通用认证信息。 |
configManagementPlugins |
空字符串 | 插件 | 自定义配置管理插件(如 Helm、Kustomize 之外的扩展)。 |
resource.customizations |
空字符串 | 资源 | 自定义资源健康检查、资源动作、忽略差异等。 |
accounts.* |
默认 admin | 认证 | 本地用户账号配置,包括角色绑定和权限。 |
rbac.* |
默认策略 | RBAC | 基于角色的访问控制策略定义(Casbin 格式)。 |
ui.banner.* |
空字符串 | UI | Web UI 顶部横幅内容、背景色、文字颜色。 |
help.chatUrl |
空字符串 | UI | UI 帮助菜单中的聊天链接。 |
timeout.reconciliation |
180s |
调谐 | 应用状态与期望状态不一致时的重试间隔。 |
4.3 自定义配置入口与最佳实践
平台工程师不应直接修改默认安装的 ConfigMap 文件,而应通过 Helm values 或 Kustomize 补丁进行声明式管理。以下是几个高频自定义入口的配置示例。
4.3.1 配置外部 URL 与 SSO 回调
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
namespace: argocd
data:
url: "https://argocd.platform.example.com"
# 如果使用 Dex 作为 SSO 提供商,还需配置 oidc.config
oidc.config: |
name: Dex
issuer: https://dex.platform.example.com
clientID: argocd-client
clientSecret: $oidc.dex.clientSecret # 引用 argocd-secret 中的键
requestedScopes: ["openid", "profile", "email", "groups"]
4.3.2 配置仓库凭据模板
当多个 Application 使用不同仓库但共享同一 SSH 密钥时,使用凭据模板可避免重复配置。
data:
repository.credentials: |
- url: https://gitlab.platform.example.com/*
username: gitlab-ci-
passwordSecret:
name: gitlab--secret
key: password
- sshPrivateKeySecret:
name: repo-ssh-secret
key: sshPrivateKey
4.3.3 自定义资源健康检查
对于自定义资源(CRD),Argo CD 默认无法判断其健康状态。通过 resource.customizations 可以注入 Lua 脚本。
data:
resource.customizations: |
argoproj.io/Application:
health.lua: |
hs = {}
hs.status = "Progressing"
hs.message = ""
if obj.status ~= nil then
if obj.status.health ~= nil then
hs.status = obj.status.health.status
hs.message = obj.status.health.message
end
end
return hs
配置冲突风险: 当使用 Helm Chart 部署 Argo CD 时,
argocd-cm 中的 repositories 字段与 repository.credentials 字段如果同时存在,Argo CD 会合并处理。但若在 Helm values 中通过 configs.cm 直接覆盖整个 data 字段,会导致默认配置丢失。建议使用 Helm 的 --set 或 values 中的 configs.cm 逐项覆盖,而非整体替换。
4.4 配置验证与调试
修改配置后,建议通过以下步骤验证生效情况:
- 检查 ConfigMap 内容:
kubectl get configmap argocd-cm -n argocd -o yaml - 查看 Argo CD 日志:
kubectl logs -n argocd deployment/argocd-server --tail=50 | grep -i "config" - 通过 API 验证: 调用
/api/v1/settings接口,返回的 JSON 中应包含已生效的配置项。 - UI 验证: 访问 Argo CD Web UI,检查“设置”页面或横幅是否按预期显示。
平台工程要点: 将
argocd-cm 的配置纳入 GitOps 管理。在 Git 仓库中维护一份基线配置,通过 Application 对象自管理 Argo CD 自身的配置,实现“用 Argo CD 管理 Argo CD”。这是平台工程中“自举”模式的最佳实践。