📚 课程目录第2章 GitOps流水线架构

2. GitOps 流水线架构：Flux/ArgoCD 核心组件、Operator 模式、同步机制与状态漂移检测

2.1 GitOps 核心架构原则

GitOps 流水线的核心思想是将 Git 仓库作为声明式基础设施和应用程序的唯一事实来源（Single Source of Truth）。所有对环境的变更都必须通过修改 Git 仓库中的清单文件来触发，由 Operator 自动完成同步，从而保证集群状态与 Git 仓库状态一致。

  核心原则：
  声明式配置：所有环境状态（Kubernetes 资源、应用配置）都以 YAML/JSON 形式存储在 Git 中。
不可变事实来源：Git 仓库是唯一被信任的状态定义，禁止手动修改集群资源。
自动同步：Operator 持续监控 Git 仓库变更，自动将声明状态应用到目标集群。
自愈能力：当集群状态发生漂移（Drift）时，Operator 自动将其回滚至 Git 中定义的状态。

2.2 Flux vs ArgoCD：核心组件对比

Flux 和 ArgoCD 是目前最主流的两个 GitOps Operator。它们在架构设计、同步策略和组件划分上存在显著差异，理解这些差异对于故障排查至关重要。

对比维度	Flux (v2)	ArgoCD
架构模式	多组件微服务架构（Source Controller / Kustomize Controller / Helm Controller / Notification Controller）	单体应用 + API Server + Repo Server + Application Controller
同步触发	基于 Git 仓库的 Webhook 或定时轮询（默认 2 分钟）	基于 Git 仓库的 Webhook 或定时轮询（默认 3 分钟），支持手动 Sync
同步策略	默认自动同步，支持 prune（清理多余资源）	支持自动同步和手动同步，提供 Sync Policy（Prune / Self-Heal）
状态漂移检测	通过 Source Controller 持续对比 Git 中的期望状态与集群实际状态	通过 Application Controller 定期对比 Git 状态与 Live 状态，生成 Diff
多集群支持	通过 Kustomize 和 Cluster API 原生支持	内置多集群管理，支持 Cluster Registration 和 Project 隔离
UI / Dashboard	无原生 UI，依赖 CLI 和第三方工具	提供功能丰富的 Web UI，支持实时状态查看、同步操作和 Diff 展示

故障排查提示：在 Flux 中，如果同步失败，应首先检查 gotk reconcile 命令的输出以及各个 Controller 的 Pod 日志。在 ArgoCD 中，Web UI 的“App Details”页面直接显示同步状态和错误信息，是首选的排查入口。

2.3 Operator 模式与 Reconcile Loop

GitOps Operator 本质上是 Kubernetes 的 Operator，它通过 Reconcile Loop（调谐循环） 持续驱动集群状态向期望状态收敛。Operator 模式的核心组件包括：

Custom Resource Definitions (CRDs)：定义 GitOps 资源模型，如 Flux 的 GitRepository、Kustomization，ArgoCD 的 Application、AppProject。
Controller：监听 CRD 资源的变化，触发 Reconcile 逻辑。
Reconciler：核心业务逻辑，负责从 Git 拉取清单、与集群状态对比、执行 Apply 或 Prune 操作。

2.4 同步机制详解

同步机制是 GitOps 流水线的核心执行环节。无论是 Flux 还是 ArgoCD，同步过程都遵循以下关键步骤：

源获取：从 Git 仓库中拉取指定分支或 Tag 的清单文件。
清单渲染：对 Kustomize 或 Helm Chart 进行渲染，生成最终的 Kubernetes 资源 YAML。
状态对比：将渲染后的期望状态与集群中的实际 Live 状态进行 Diff 对比。
资源应用：对新增或变更的资源执行 kubectl apply，对已删除的资源执行 kubectl delete（如果启用了 Prune）。
健康检查：等待资源达到 Ready 状态，确认同步成功。

常见同步故障点：

Git 凭证失效：Operator 无法访问私有 Git 仓库，导致源获取失败。
清单渲染错误：Kustomize 或 Helm 模板语法错误，导致渲染后的 YAML 不合法。
资源冲突：集群中已存在同名资源但标签或注解不匹配，导致 Apply 失败。
Prune 策略误删：未正确配置 prune: true 导致资源残留，或误删了不应删除的资源。

2.5 状态漂移检测机制

状态漂移（State Drift）是指集群实际运行状态与 Git 仓库中定义的期望状态不一致的现象。漂移检测是 GitOps 自愈能力的基础，也是故障排查中需要重点关注的环节。

漂移类型	触发原因	检测方式	Operator 响应
手动漂移	运维人员通过 `kubectl edit` 或 `kubectl scale` 直接修改集群资源	Operator 定期对比 Git 状态与 Live 状态	自动回滚至 Git 定义状态（如果启用了 Self-Heal）
外部干扰漂移	集群自动缩放、节点故障、HPA 调整等外部因素导致资源变更	Operator 通过 Watch 机制或定时轮询检测	重新 Apply 期望状态，恢复资源配置
配置残留漂移	Git 仓库中删除了某个资源，但集群中该资源未被清理	Operator 在同步时执行 Prune 检测	根据 Prune 策略决定是否删除残留资源
版本回退漂移	Git 仓库回滚到旧版本，但集群仍运行新版本	Operator 检测到 Git 状态版本低于集群当前版本	执行回滚操作，将集群降级至 Git 中的旧版本

  漂移检测的故障排查要点：
  Flux：使用 flux get kustomizations 查看同步状态，使用 flux reconcile kustomization <name> --with-source 手动触发同步并观察日志。
ArgoCD：在 Web UI 中查看 Application 的“Diff”页面，可以直观看到 Git 状态与 Live 状态的具体差异。
通用方法：对比 Git 仓库中最后一次提交的 SHA 与 Operator 当前同步的 SHA，如果不一致，说明同步存在延迟或失败。

2.6 故障排查关键命令速查

以下是在 Flux 和 ArgoCD 环境中进行故障排查时最常用的命令，建议熟记：

# Flux 故障排查命令
flux get sources git                          # 查看 Git 源状态
flux get kustomizations                       # 查看 Kustomization 同步状态
flux reconcile kustomization <name> --with-source  # 手动触发同步
kubectl logs -n flux-system deployment/source-controller  # 查看 Source Controller 日志

# ArgoCD 故障排查命令
argocd app list                               # 查看所有 Application 状态
argocd app get <app-name>                     # 查看 Application 详细信息
argocd app sync <app-name>                    # 手动触发同步
argocd app diff <app-name>                    # 查看 Git 与 Live 状态的差异
kubectl logs -n argocd deployment/argocd-application-controller  # 查看 Application Controller 日志

最佳实践：在排查同步故障时，始终遵循“从 Git 到集群”的链路顺序：先确认 Git 仓库可访问且清单正确，再检查 Operator 的 Reconcile 状态，最后查看集群中资源的实际状态。不要跳过任何环节。