1. 课程导论:GitOps 核心理念、Argo CD 与 Flux 对比、节点池运维痛点与剧本目标

1.1 GitOps 核心理念:声明式运维的基石

GitOps 是一种以 Git 仓库作为单一事实来源(Single Source of Truth)的运维模式。其核心思想是将基础设施与应用的期望状态全部声明式地存储在 Git 中,并通过自动化工具持续确保集群实际状态与 Git 中的声明一致。

核心三要素:
  • 声明式配置(Declarative): 所有资源(Deployment、Service、HPA、节点池)都以 YAML/JSON 描述其期望状态。
  • 不可变基础设施(Immutable): 变更通过修改 Git 中的声明触发,而非直接操作集群。
  • 自动同步(Auto-Sync): 运维代理持续对比 Git 与集群状态,自动修复漂移。
GitOps 核心工作流 Git 仓库 声明式配置 GitOps 代理 Argo CD / Flux Kubernetes 实际状态 Pull / Watch Apply / Sync 状态反馈(Diff / Drift) 核心原则:任何集群变更都必须通过 Git PR/MR 发起,禁止直接 kubectl edit 自动同步确保 Git 与集群之间“零偏差”

1.2 Argo CD 与 Flux:两大 GitOps 引擎对比

Argo CD 和 Flux 是当前最主流的两个 GitOps 工具,它们在设计哲学、同步机制和生态集成上存在显著差异。理解这些差异是选择协同策略的前提。

对比维度 Argo CD Flux
设计哲学 应用为中心(Application CRD),强调 UI/CLI 可视化 资源为中心(Kustomize/Helm),强调自动化与轻量
同步机制 Pull-based + Webhook 触发,支持手动/自动同步 Pull-based + 事件驱动(GitHub/Bitbucket),默认自动同步
多集群支持 原生多集群(Cluster Secret),管理平面统一 通过 Kustomize/Helm 多集群,或使用 Flux CLI 分发
回滚策略 支持历史版本回滚,保留同步记录 依赖 Git revert,无内置回滚历史
健康检查 内置资源健康评估(Health Status) 依赖 Kubernetes 自身状态,无独立健康检查
适用场景 复杂应用编排、多环境管理、需要审计追踪 轻量级部署、大规模集群、追求极简配置
选型建议: 如果你的团队需要频繁查看应用状态、进行手动干预或审计,Argo CD 更合适;如果你追求“配置即代码”的极致自动化,且集群规模较大,Flux 的轻量特性更具优势。

1.3 节点池运维痛点:为什么需要协同剧本?

在 Kubernetes 集群中,节点池(Node Pool)的运维涉及基础设施层(云商实例、伸缩组)与集群层(标签、污点、资源分配)的协同。传统 GitOps 工具单独使用时,会暴露以下痛点:

  • 配置碎片化: 节点池的云商配置(如 AWS Auto Scaling Group)与集群内配置(如 NodeSelector、Taint)分散在不同 Git 仓库或目录,缺乏统一视图。
  • 状态漂移难以追踪: 云商控制台手动扩缩容后,Git 中的声明与实际节点数不一致,Argo CD/Flux 无法直接修复基础设施层。
  • 滚动更新协调困难: 节点池升级(如实例类型变更)需要先更新云商模板,再更新集群标签,两个步骤之间容易产生时间窗口不一致。
  • 多集群节点池管理混乱: 不同集群的节点池规格、标签策略、污点规则缺乏标准化,运维人员需要登录每个集群手动核对。
  • 故障恢复缺乏自动化: 节点池因云商故障缩容后,运维人员需要手动调整 Git 配置并触发同步,恢复时间目标(RTO)难以保障。
节点池运维痛点全景 配置碎片化 云商配置 vs 集群配置 分散在多个 Git 仓库 状态漂移 云商手动扩缩容后 Git 声明与实际不一致 滚动更新协调难 实例升级与标签更新 时间窗口不一致 多集群管理混乱 不同集群规格/标签 缺乏标准化策略 故障恢复自动化低 云商故障缩容后 手动调整 Git 配置 核心矛盾:GitOps 擅长应用层同步,但节点池涉及基础设施层与集群层的跨层协调 单一工具无法同时管理云商 API 和 Kubernetes API

1.4 剧本目标:Argo CD + Flux 协同的节点池运维体系

本课程旨在构建一套 Argo CD 与 Flux 协同 的节点池运维剧本,解决上述痛点。核心目标如下:

  1. 统一配置管理: 使用 Flux 管理基础设施层(云商节点池模板、伸缩策略),使用 Argo CD 管理集群层(节点标签、污点、资源配额),通过 Git 仓库实现配置统一。
  2. 自动化状态修复: 当云商侧节点池发生漂移时,Flux 自动检测并回滚;当集群侧节点标签被误修改时,Argo CD 自动同步恢复。
  3. 标准化滚动更新: 定义节点池升级的 GitOps 工作流:先更新 Flux 管理的云商模板,再自动触发 Argo CD 更新集群标签,确保两步之间无时间窗口。
  4. 多集群策略复用: 通过 Flux 的 Kustomize 多环境覆盖,实现节点池配置的“一次定义,多集群复用”;Argo CD 负责每个集群的差异化标签管理。
  5. 故障快速恢复: 节点池故障时,运维人员只需修改 Git 中的声明,Flux 自动修复基础设施,Argo CD 自动修复集群配置,RTO 从小时级降至分钟级。
重要前提: 本剧本假设你已经具备 Kubernetes 集群管理基础,并了解 Argo CD 和 Flux 的基本安装与配置。课程将聚焦于节点池场景的协同设计,而非工具的基础操作。

通过本课程,你将掌握一套可落地的 GitOps 协同方案,使节点池运维从“手动救火”转变为“声明式自动化”。