📚 课程目录第2章 GitOps基础回顾

GitOps 基础回顾：ArgoCD / Flux 核心原理、声明式配置、Pull vs Push 模型、多集群架构模式

在深入多集群 CrashLoop 容错设计之前，必须重新校准 GitOps 的核心认知。本章从声明式配置、Pull 与 Push 模型、ArgoCD 与 Flux 的架构差异，以及多集群拓扑模式四个维度，建立后续容错设计的技术基线。

2.1 声明式配置：GitOps 的契约基础

GitOps 的本质是将运维状态声明为代码，存储在 Git 仓库中，并由 Operator 持续调和。声明式配置要求集群的期望状态（Desired State）与实际状态（Actual State）始终保持一致。

  关键原则： 声明式配置必须是幂等的、完整的、可版本化的。任何手动 kubectl edit 或 patch 操作都会破坏 GitOps 的调和基线。

特性	声明式配置	命令式配置
状态来源	Git 仓库（单一事实源）	CLI 或脚本（分散）
回滚方式	git revert + 自动同步	手动执行逆操作
审计能力	完整的 Git 提交历史	依赖操作日志
漂移检测	Operator 自动检测并告警	无内置机制

声明式配置的典型结构如下：

# application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  destination:
    namespace: production
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/team/config.git
    path: overlays/production
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

2.2 Pull vs Push 模型：架构分水岭

GitOps 的部署模型决定了控制流的方向，直接影响多集群场景下的网络策略、安全边界和容错能力。

多集群容错启示： Pull 模型天然适合多集群场景——每个集群的 Operator 独立运行，即使控制平面中断，集群仍能按最后一次同步状态运行。Push 模型在控制平面故障时，所有集群同时失去部署能力。

2.3 ArgoCD 与 Flux 核心原理

ArgoCD 和 Flux 是当前最主流的 GitOps Operator，两者在架构设计上存在关键差异，直接影响 CrashLoop 场景下的行为。

维度	ArgoCD	Flux v2
架构风格	单体 Application Controller + API Server	多组件微服务（Source Controller / Kustomize Controller / Helm Controller）
同步触发	轮询 Git（默认 3 分钟）+ Webhook	基于 GitRepository 对象的轮询 + 事件驱动
漂移检测	内置 Diff + 自动 Sync（selfHeal）	通过 Kustomize 或 Helm 的 reconciliation 循环
多集群支持	ApplicationSet + 集群 Secret 注册	Kustomization 跨集群 + Cluster API 集成
回滚策略	手动回滚 + Sync 到历史版本	git revert + 自动 reconciliation
CrashLoop 行为	Application 状态卡在 OutOfSync，不自动重试	Kustomization 进入失败状态，按 backoff 重试

2.4 多集群架构模式

多集群 GitOps 部署通常采用三种架构模式，每种模式对同步窗口和 CrashLoop 容错的影响不同。

CrashLoop 容错设计要点： 在 Hub-and-Spoke 模式下，Hub 集群的 CrashLoop 会导致所有 Spoke 集群失去同步能力。Fleet 模式虽然隔离性好，但需要为每个集群配置同步窗口参数。Hybrid 模式是折中方案，建议在管理集群部署全局同步窗口策略，区域集群保留本地容错能力。

2.5 同步窗口与调和循环

同步窗口（Sync Window）是 GitOps 中控制部署时间窗口的机制，在多集群场景下用于避免大规模并发部署导致的集群过载或依赖冲突。

ArgoCD 和 Flux 的同步窗口实现方式不同：

ArgoCD Sync Window： 通过 Application 的 syncPolicy.syncOptions 或全局 argocd-cm 配置，支持禁止/允许特定时间窗口的同步。
Flux 同步窗口： 通过 Kustomization 的 .spec.suspend 字段或 OCIRepository 的 .spec.interval 控制调和频率。

# ArgoCD 同步窗口配置示例
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  sync.window: |
    - kind: deny
      schedule: "0 0 * * *"
      duration: 6h
      applications:
        - "prod-*"
      clusters:
        - "https://cluster-prod.example.com"
      namespaces:
        - "production"

  CrashLoop 与同步窗口的关联： 当应用进入 CrashLoop 状态时，同步窗口可能阻止 Operator 自动回滚或修复。容错设计需要确保同步窗口内仍允许紧急回滚操作，通常通过设置 allowEmergency: true 或使用独立的紧急同步通道。

2.6 多集群 GitOps 的调和状态机

理解调和状态机是 CrashLoop 容错设计的前提。无论是 ArgoCD 还是 Flux，其调和循环都遵循类似的状态转换逻辑：

检测阶段： Operator 定期对比 Git 中的期望状态与集群实际状态。
差异计算： 生成 Diff，识别需要创建、更新或删除的资源。
同步执行： 按依赖顺序应用变更，支持 Dry-Run 预检。
健康评估： 检查资源是否达到 Running/Ready 状态。
失败处理： 如果资源进入 CrashLoopBackOff，Operator 根据策略决定是否回滚或重试。

在多集群场景下，每个集群的调和循环是独立的，但共享同一个 Git 仓库作为状态源。这意味着一个集群的 CrashLoop 不会直接影响其他集群的调和过程，但可能因为共享的同步窗口配置而产生间接影响。

最佳实践： 为每个集群配置独立的同步窗口参数，避免全局同步窗口导致所有集群同时进入 CrashLoop 修复窗口。推荐使用 Fleet 或 Hybrid 模式，并在管理集群层面设置全局告警而非全局同步控制。