📚 课程目录第2章 Argo CD简介

Argo CD 简介：核心概念、架构组件、与 GitOps 的关系

Argo CD 是 CNCF 毕业项目，也是 Kubernetes 生态中最主流的声明式 GitOps 持续交付工具。它通过将应用期望状态存储在 Git 仓库中，自动同步集群实际状态，确保环境始终与代码仓库保持一致。在云原生安全运行基线核验场景中，Argo CD 既是部署引擎，也是观测锚点——其自身状态、同步策略、健康检查机制直接决定了基线是否被正确执行。

2.1 核心概念

理解 Argo CD 需要先掌握以下 5 个核心抽象，它们构成了 GitOps 工作流的数据模型：

概念	定义	安全基线核验中的角色
Application	一组 Kubernetes 资源的声明式定义，包含来源（Git Repo）、目标（集群/命名空间）、同步策略。	每个基线核验规则可映射为一个 Application，便于独立观测与审计。
Project	Application 的逻辑分组与权限边界，控制可访问的 Git 仓库、目标集群、资源类型。	用于隔离不同安全等级（如生产/非生产）的基线核验任务。
Sync Status	集群实际状态与 Git 期望状态的比较结果：Synced / OutOfSync / Unknown。	基线漂移检测的直接指标，OutOfSync 即视为安全事件。
Health Status	Kubernetes 资源运行健康度：Healthy / Degraded / Progressing / Missing。	基线核验通过后，需确认资源健康才算合规。
Sync Operation	将 Git 期望状态应用到集群的原子操作，支持自动/手动、自愈、Prune 等策略。	核验触发动作，需记录操作日志用于审计追溯。

基线核验视角： 在安全运行基线场景中，Sync Status 和 Health Status 是最关键的观测指标。建议将每个基线规则封装为独立的 Application，并启用自动同步 + 自愈，确保基线一旦被篡改立即恢复。

2.2 架构组件

Argo CD 采用控制面-工作负载分离的微服务架构，核心组件包括：

API Server：REST/gRPC 网关，处理 Web UI、CLI、CI/CD 系统请求；负责认证、授权、RBAC 校验。
Repository Server：内部 Git 客户端，负责拉取、缓存、生成 Kubernetes 清单（支持 Helm、Kustomize、Jsonnet 等）。
Application Controller：核心循环控制器，持续对比 Git 期望状态与集群实际状态，触发同步或告警。
Redis：缓存层，存储 Application 状态、Git 仓库元数据、操作锁，提升性能并支持高可用。
Dex / 内置 OAuth：身份认证代理，对接 LDAP、SAML、GitHub、GitLab 等外部 IdP。

2.3 与 GitOps 的关系

Argo CD 是 GitOps 理念在 Kubernetes 上的标准实现。GitOps 的核心原则与 Argo CD 的对应关系如下：

GitOps 原则	Argo CD 实现方式	安全基线核验意义
声明式期望状态	所有 Kubernetes 资源以 YAML/Helm/Kustomize 形式存储在 Git 中。	基线规则版本化，可审计、可回滚。
状态不可篡改	Git 作为单一事实来源，集群手动变更会被自动同步覆盖。	防止绕过基线的手动修改，保障运行态合规。
自动同步与自愈	Application Controller 持续对比，自动修复漂移。	基线漂移自动恢复，减少人工介入窗口。
可观测与审计	提供 Sync Status、Health Status、操作历史、事件日志。	基线核验结果可追溯，满足合规审计要求。
拉取式部署	集群主动拉取 Git 状态，而非 CI/CD 推送。	减少集群外网暴露面，提升安全隔离性。

  关键认知： GitOps 不是工具，而是一种运维模式。Argo CD 将 GitOps 原则落地为可执行的控制器逻辑。在安全基线核验场景中，Argo CD 充当了“基线执行引擎”和“漂移检测器”的双重角色——它确保 Git 中定义的基线规则被持续、自动地应用到集群，并提供实时状态供观测标签体系采集。

安全基线核验前置条件： 在使用 Argo CD 作为基线引擎前，必须确保以下三点已就绪：① Git 仓库已配置分支保护与签名校验；② Argo CD 已启用 TLS 与 RBAC；③ Application 的同步策略设置为 自动同步 + 自愈 + Prune，否则基线无法自动恢复。