📚 课程目录第2章 GitOps 核心原理回顾

GitOps 核心原理回顾

在进入节点池巡检与配额校准实战之前，必须重新锚定 GitOps 的四大核心原理。这些原理不仅是 ArgoCD 的运行基石，也是后续所有自动化策略的设计依据。

1. 声明式配置（Declarative Configuration）

GitOps 的第一原则：所有目标状态必须用声明式文件描述。Kubernetes 资源的期望状态（Deployment、Service、Namespace、ResourceQuota 等）都存储在 Git 仓库中，作为单一事实来源。

  关键区别： 命令式（Imperative）→ “如何做”；声明式（Declarative）→ “最终要什么”。GitOps 只关心“要什么”，系统自动计算并执行差异。

对比维度	命令式配置	声明式配置（GitOps）
操作方式	kubectl run / create / delete	kubectl apply -f manifest.yaml
状态来源	操作者记忆 + 脚本	Git 仓库中的 YAML 文件
回滚能力	手动逆向操作	git revert + 自动同步
审计追踪	无原生记录	Git commit 历史

2. 状态同步（State Synchronization）

GitOps 控制器持续对比 Git 仓库中的期望状态与集群中的实际状态。一旦发现偏差，自动执行调和（Reconciliation）操作，将集群拉回期望状态。

# 状态同步的核心循环（伪代码）
for {
    desired := loadFromGit(repo, branch, path)
    actual := getClusterState()
    diff := compare(desired, actual)
    if diff != empty {
        applyToCluster(diff)
    }
    sleep(reconciliationInterval)
}

实战要点： 同步不是“全量覆盖”。ArgoCD 使用 3-way merge 策略，避免删除 Git 中未定义但集群中存在的资源（除非配置了 Prune）。

3. Pull vs Push 模式

GitOps 部署模型分为两种，ArgoCD 采用 Pull 模式，这也是它与传统 CI/CD 工具（Push 模式）的本质区别。

安全提示： 生产环境严禁使用 Push 模式直接向集群推送配置。Pull 模式确保集群凭证仅存在于集群内部，CI 流水线即使被攻破也无法直接操作集群。

4. Sync Wave 在 ArgoCD 中的角色

Sync Wave 是 ArgoCD 提供的资源同步排序机制。当一次同步涉及多个资源时（例如先创建 Namespace，再创建 ResourceQuota，最后创建 Deployment），Sync Wave 确保它们按依赖顺序执行。

4.1 核心概念

Wave（波次）： 每个资源可以标注 argocd.argoproj.io/sync-wave 注解，值为整数（可正可负）。
执行顺序： 从小到大依次执行。Wave 0 先执行，Wave 1 次之，Wave 2 最后。
波次内并行： 同一 Wave 内的资源并行同步，不保证顺序。
波次间等待： 只有当前 Wave 所有资源健康（Healthy）后，才会进入下一个 Wave。

# 为资源指定 Sync Wave 注解
apiVersion: v1
kind: Namespace
metadata:
  name: node-pool-system
  annotations:
    argocd.argoproj.io/sync-wave: "-5"   # 最先执行
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: node-pool-quota
  namespace: node-pool-system
  annotations:
    argocd.argoproj.io/sync-wave: "0"    # 第二波
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-pool-controller
  namespace: node-pool-system
  annotations:
    argocd.argoproj.io/sync-wave: "5"    # 最后执行

4.2 Sync Wave 在节点池巡检中的价值

场景	无 Sync Wave 的问题	使用 Sync Wave 的解决
先建 Namespace 再建资源	资源创建失败（Namespace 不存在）	Namespace Wave -5 → 资源 Wave 0
先设配额再部署巡检器	巡检器可能超配额启动失败	ResourceQuota Wave 0 → 巡检器 Wave 5
先配 RBAC 再创建 ServiceAccount	权限绑定引用不存在的账户	ServiceAccount Wave 0 → RoleBinding Wave 1
先拉 ConfigMap 再挂载	Pod 启动时 ConfigMap 未就绪	ConfigMap Wave 0 → Deployment Wave 5

4.3 Sync Wave 执行流程

实战建议： 在节点池巡检场景中，建议将 Namespace 和 CRD 放在 Wave -5，ResourceQuota 和 RBAC 放在 Wave 0，巡检器 Deployment 放在 Wave 5。这样确保配额和权限先就绪，巡检器启动时不会因缺少资源而失败。

5. 原理与实战的映射关系

本章回顾的四大原理将在后续课程中反复应用：

声明式配置 → 节点池的期望规格（CPU、内存、GPU 配额）全部以 YAML 形式存储在 Git 中。
状态同步 → ArgoCD 持续对比 Git 中的配额声明与集群实际配额，发现偏差自动校准。
Pull 模式 → 巡检器部署在集群内部，主动拉取 Git 中的配额策略，无需外部 CI 介入。
Sync Wave → 确保配额资源先创建，巡检器后启动，避免启动顺序导致的初始化失败。