4. GitOps 工作流：从 Git 仓库提交变更到 Flux 自动同步节点池配置的完整流程

本章将完整演示一次 GitOps 驱动的节点池配置变更：从开发者在 Git 仓库中修改 YAML 清单开始，到 Flux 自动检测、拉取、应用配置至目标集群的全过程。理解这一闭环流程，是后续进行配置巡检与版本回滚验证的基础。

4.1 工作流全景：GitOps 闭环的五个阶段

Flux 的节点池配置同步遵循“声明式期望 → 持续对比 → 自动调和”的核心模式。整个变更流程可划分为以下五个阶段：

4.2 流程详解：从 Git Push 到集群生效

4.2.1 阶段一：提交变更到 Git 仓库

运维人员修改节点池配置文件，例如调整节点池的实例规格或扩缩容范围：

# 修改节点池 YAML：调整 minSize 和 maxSize
# nodepool-prod.yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachinePool
metadata:
  name: prod-pool-1
  namespace: clusters
spec:
  replicas: 3
  template:
    spec:
      version: v1.28.3
      # 修改实例类型
      instanceType: m5.xlarge
---
# 提交并推送
git add nodepool-prod.yaml
git commit -m "feat: 调整 prod-pool-1 实例类型为 m5.xlarge，副本数保持 3"
git push origin main

4.2.2 阶段二：Flux 检测 Git 变更

Flux Source Controller 根据 GitRepository 自定义资源的配置，定期（默认 1 分钟）轮询 Git 仓库。当检测到新的 Commit 时，它会拉取最新代码并更新本地的 Source 状态。

# GitRepository 示例
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: cluster-config
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/team-ops/cluster-gitops
  ref:
    branch: main

4.2.3 阶段三：Kustomize Controller 协调期望状态

Kustomize Controller 监控 Kustomization 资源，一旦发现关联的 GitRepository Source 有更新，立即触发调和循环：

1. 从 Source Controller 获取最新的 artifact（压缩后的清单文件）。
2. 执行 Kustomize 构建，渲染出最终的 Kubernetes 资源清单。
3. 将渲染后的清单与集群中当前资源进行 三方对比（Three-Way Diff）。

# Kustomization 示例
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: nodepools
  namespace: flux-system
spec:
  interval: 1m
  path: ./clusters/prod/nodepools
  prune: true
  sourceRef:
    kind: GitRepository
    name: cluster-config
  targetNamespace: clusters

4.2.4 阶段四：Server-Side Apply 应用配置

Kustomize Controller 使用 Server-Side Apply 将期望状态写入 Kubernetes API Server。此方式可以精确管理字段所有权，避免并发写冲突。对于节点池 CRD（如 MachinePool 或 ClusterClass），Flux 会直接更新其 spec 字段。

4.2.5 阶段五：确认同步状态

运维人员可以通过 Flux CLI 或 kubectl 验证同步是否成功：

# 查看 Kustomization 同步状态
flux get kustomizations nodepools

# 查看最近一次调和记录
flux reconcile kustomization nodepools

# 直接查看节点池资源是否已更新
kubectl get machinepool prod-pool-1 -n clusters -o yaml | grep instanceType

4.3 完整流程可视化

下图展示了从 Git 提交到节点池配置生效的完整 GitOps 工作流，包含核心组件与数据流向：

4.4 关键机制：Flux 的调和循环与状态反馈

Flux 的调和循环并非一次性操作，而是一个持续运行的闭环。理解其内部机制有助于排查同步延迟或失败问题：

• 轮询间隔（Interval）： GitRepository 和 Kustomization 各自定义 spec.interval，默认 1 分钟。Source Controller 按此频率检查 Git 变更。
• 状态更新： 每次调和后，Kustomize Controller 会更新 Kustomization 资源的 status 字段，包括 conditions（Ready/Stalled/Progressing）、lastAppliedRevision（最近应用的 Git Commit SHA）和 lastHandledReconcileAt。
• 失败重试： 如果 Apply 失败（如 CRD 版本不兼容、资源冲突），Flux 会以指数退避方式重试（10s → 20s → 40s … 最大 5 分钟），直到成功或达到重试上限。

4.5 实践检查清单

在完成一次节点池配置变更后，建议按以下清单确认流程完整性：