2. Argo CD 核心概念回顾：Application、Project、Sync Policy、Sync Waves、Health Checks
在构建云原生日志平台的变更门禁与灰度发布准入检查之前，必须深入理解 Argo CD 的五大核心概念。这些概念构成了所有自动化部署策略的基石，也是后续实现精细化控制的关键。
2.1 Application（应用）
Application 是 Argo CD 中管理部署的最小单元，它定义了一个应用实例的完整生命周期。一个 Application 资源通过 YAML 清单将 Git 仓库中的 Kubernetes 资源描述与目标集群的命名空间绑定。
| 字段 | 说明 | 示例值 |
|---|---|---|
| source | 定义 Git 仓库地址、目标路径及 Helm/Kustomize 参数 | repoURL: https://git.example.com/log-platform.git |
| destination | 指定目标集群和命名空间 | namespace: log-prod |
| project | 所属项目，用于资源隔离与权限控制 | project: log-platform |
| syncPolicy | 自动同步策略配置 | automated: { prune: true } |
关键理解： Application 是 GitOps 中“声明式”的载体。Argo CD 持续对比 Git 中的期望状态与集群中的实际状态，当两者不一致时触发同步操作。
2.2 Project（项目）
Project 是 Argo CD 中用于逻辑分组和权限隔离的顶层资源。它定义了哪些 Application 可以部署到哪些集群和命名空间，以及允许访问哪些 Git 仓库。
- 资源白名单： 限制 Project 内 Application 可以创建的 Kubernetes 资源类型（如只允许 Deployment、Service、ConfigMap）。
- 目标集群限制： 指定允许部署的目标集群 URL 或名称。
- 源仓库限制： 只允许从授权的 Git 仓库拉取清单。
- 角色绑定： 通过 RBAC 控制不同团队对 Project 内 Application 的操作权限。
日志平台实践： 为日志平台创建独立的
log-platform Project，将采集端、存储端、查询端分别定义为不同的 Application，并通过 Project 策略确保生产环境命名空间只能由 CI/CD 管道触发变更。
2.3 Sync Policy（同步策略）
Sync Policy 决定了 Argo CD 如何将 Git 中的期望状态应用到集群。它分为手动同步和自动同步两种模式，自动同步又包含多个精细控制选项。
| 策略类型 | 子选项 | 行为描述 |
|---|---|---|
| 手动同步 | — | 需要人工点击 Sync 按钮或调用 API 触发 |
| 自动同步 | prune: true |
自动删除 Git 中已移除的资源 |
selfHeal: true |
自动修复集群中被手动修改的资源 | |
allowEmpty: true |
允许同步空的资源清单（用于清理场景） |
灰度发布注意： 在灰度发布阶段，建议关闭
selfHeal 或使用 prune: false，避免自动同步覆盖正在进行的流量切换验证。
2.4 Sync Waves（同步波次）
Sync Waves 允许将 Application 内的资源按依赖顺序分批部署。Argo CD 按照 wave 编号从小到大依次同步，只有当前 wave 中的所有资源健康后，才会进入下一个 wave。
- 默认 wave： 所有资源默认属于 wave 0。
- 自定义 wave： 通过 annotation
argocd.argoproj.io/sync-wave: "1"指定。 - 依赖管理： 常用于先部署 ConfigMap/Secret，再部署 Deployment，最后部署 Service/Ingress。
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
argocd.argoproj.io/sync-wave: "2" # 在 ConfigMap 之后部署
spec:
template:
spec:
containers:
- name: log-collector
image: log-collector:latest
日志平台场景： Wave 0 部署 Elasticsearch 集群配置；Wave 1 部署 Logstash 管道；Wave 2 部署 Kibana 前端。确保后端就绪后再暴露服务。
2.5 Health Checks（健康检查）
Health Checks 是 Argo CD 判断资源是否“健康”的机制。Argo CD 内置了常见 Kubernetes 资源的健康检查逻辑，同时也支持通过 Lua 脚本自定义健康检查。
| 资源类型 | 内置健康检查逻辑 |
|---|---|
| Deployment | 检查 status.availableReplicas 是否等于 spec.replicas |
| StatefulSet | 检查 status.readyReplicas 是否等于 spec.replicas |
| Service | 检查是否有 Endpoints |
| Custom Resource | 需要自定义 Lua 脚本或依赖 Operator 上报状态 |
准入检查基础： 在灰度发布准入检查中，Health Checks 是判断新版本是否“就绪”的核心依据。只有所有资源通过健康检查，Argo CD 才会认为同步成功，后续的流量切换才能触发。
2.6 核心概念在日志平台中的映射
将上述概念映射到云原生日志平台的变更管理流程中，可以形成清晰的职责划分：
- Application： 每个日志组件（Filebeat、Logstash、Elasticsearch、Kibana）各对应一个 Application。
- Project： 创建
log-platformProject，统一管理所有日志组件的部署权限。 - Sync Policy： 灰度阶段使用手动同步 + 准入检查；全量发布后切换为自动同步。
- Sync Waves： 确保存储层（Elasticsearch）先于采集层（Filebeat）部署。
- Health Checks： 自定义 Elasticsearch 集群健康状态检查，确保分片分配完成后再接入新数据。
课程衔接： 在后续章节中，我们将基于这些核心概念，构建日志平台的变更门禁规则和灰度发布准入检查逻辑。理解 Application 与 Project 的边界、Sync Waves 的依赖顺序以及 Health Checks 的判定标准，是实现自动化安全变更的前提。