3. 存储后端基础：Kubernetes Secrets、ConfigMap、etcd 在 Argo CD 中的角色

Argo CD 作为声明式 GitOps 工具，其核心状态（应用定义、同步状态、集群配置、用户凭证）必须持久化存储。Kubernetes 原生提供的 Secrets、ConfigMap 以及底层分布式键值存储 etcd，共同构成了 Argo CD 的存储后端基础。理解这三者的角色与交互，是掌握版本漂移校准的前提。

3.1 存储层次与职责划分

Argo CD 并未使用外部数据库（如 PostgreSQL），而是直接依赖 Kubernetes 的存储原语。这种设计简化了运维，但也意味着存储的可靠性、一致性和版本管理完全由 Kubernetes 控制平面保障。下表总结了三种存储组件在 Argo CD 中的具体职责：

3.2 核心存储组件详解

3.2.1 etcd：Argo CD 的“状态中枢”

etcd 是 Kubernetes 控制平面的核心，也是 Argo CD 所有自定义资源（CRD）实例的最终存储位置。当用户通过 argocd app create 或 kubectl apply 创建 Application 资源时，该资源会被序列化并写入 etcd。Argo CD 的 application-controller 持续从 etcd 监听这些资源的变化，并据此驱动同步循环。

• 版本管理： etcd 为每个键维护一个全局递增的 resourceVersion。Argo CD 利用此机制实现乐观锁，防止并发写冲突。
• 漂移检测基础： controller 将 etcd 中 Application 的 status.sync.status 字段与 Git 中的期望清单对比，产生“OutOfSync”状态。
• 高可用： etcd 集群（通常 3 或 5 节点）通过 Raft 共识算法保证数据一致性。etcd 故障将直接导致 Argo CD 无法读取或写入状态。

3.2.2 Secrets：敏感凭证的“保险柜”

Argo CD 需要访问 Git 仓库和 Kubernetes 集群。这些访问凭证（SSH 私钥、API 、kubeconfig 证书）存储在 Kubernetes Secrets 中。Argo CD 的 repo-server 和 application-controller 通过挂载或 API 调用来读取这些 Secret。

# 示例：查看 Argo CD 用于连接 Git 仓库的 Secret
kubectl get secret -n argocd argocd-repo-server-tls -o yaml
# 输出中 data 字段包含 base64 编码的证书和密钥

3.2.3 ConfigMap：运行时行为的“调节旋钮”

ConfigMap 存储 Argo CD 的非敏感配置。最核心的是 argocd-cm，它控制着仓库连接方式、资源自定义、UI 品牌等。修改 ConfigMap 通常不需要重启 Pod，Argo CD 组件会动态重载。

• argocd-cm： 定义仓库凭据的引用方式、资源排除规则、应用状态保留策略。
• argocd-rbac-cm： 定义基于角色的访问控制策略，影响用户能否触发同步。
• argocd-ssh-known-hosts-cm： 存储已知的 Git 服务器 SSH 主机密钥，用于验证仓库身份。

3.3 存储组件交互流程（SVG 架构图）

下图展示了 Argo CD 核心组件与三种存储后端的交互关系，以及版本漂移检测的数据流路径：

3.4 存储版本漂移的典型场景

在 Argo CD 的日常运维中，存储后端本身也可能发生“版本漂移”，这通常不是指应用清单的变更，而是存储数据的意外修改或回退。以下场景需要特别关注：

1. etcd 快照恢复： 当 Kubernetes 集群从旧快照恢复时，etcd 中的 Argo CD Application 状态可能回退到过去的版本。此时，Argo CD 会认为当前状态与 Git 期望状态不一致，触发大规模同步。
2. Secrets 被手动覆盖： 运维人员通过 kubectl apply 直接修改了 argocd-repo-server-tls Secret，导致 repo-server 无法连接仓库。Argo CD 会报告仓库连接错误，而非应用版本漂移。
3. ConfigMap 配置漂移： 多集群环境中，不同集群的 argocd-cm 配置不一致，导致同一 Application 在不同集群上的同步行为不同。

3.5 存储后端对比总结

下表从版本漂移校准的角度，对比三种存储后端的关键特性：