📚 课程目录第1章课程导论

1. GitOps 核心概念：声明式配置、状态同步、不可变基础设施、Git 作为单一事实来源

GitOps 是一种以 Git 仓库为单一事实来源（Single Source of Truth）的运维模式，它将声明式配置与自动化状态同步相结合，实现基础设施与应用的持续交付。理解以下四个核心概念，是掌握 Flux 与 Argo CD 选型对比的基础。

声明式配置描述系统“应该是什么状态”，而非“如何达到该状态”。运维人员只需在 Git 仓库中定义期望的最终状态（如 Deployment 副本数、Service 端口、ConfigMap 内容），GitOps 工具会自动将实际集群状态收敛至该期望状态。

实践要点：声明式配置要求所有资源清单（Deployment、Service、Ingress 等）都存储在 Git 仓库中，避免使用 kubectl run 或 helm install --set 等命令式操作破坏单一事实来源。

状态同步是 GitOps 的核心循环机制：GitOps Operator 持续比较 Git 仓库中的期望状态与 Kubernetes 集群的实际状态，当两者不一致时自动执行协调（Reconciliation）操作，将集群状态拉回期望状态。

  关键指标：Flux 默认同步间隔为 1 分钟（可配置），Argo CD 默认同步间隔为 3 分钟。在资源配额校准场景中，较短的同步间隔能更快发现配额超限并触发告警。

不可变基础设施强调：一旦部署，运行中的组件不应被修改。任何变更都应通过替换整个组件（如重建 Pod、升级镜像版本）来实现，而非对运行中的容器执行 exec 或 patch 操作。

优势：消除配置漂移（Configuration Drift），环境一致性高，回滚简单（直接切换至旧版本镜像）。
与 GitOps 的关系：Git 仓库中的每次提交都对应一个不可变的基础设施版本，Operator 通过更新镜像 Tag 或 Helm Chart 版本来触发滚动更新。
资源配额校准场景：当 Namespace 资源配额（ResourceQuota）需要调整时，应修改 Git 仓库中的配额 YAML 文件，而非直接 kubectl edit resourcequota。

在 GitOps 模型中，Git 仓库是唯一被信任的权威数据源。所有环境（开发、预发、生产）的期望状态都必须在 Git 仓库中定义，任何手动修改集群的行为都会在下一次同步时被覆盖。

常见误区：部分团队将 Git 仓库仅作为“备份”使用，仍通过 kubectl 直接修改集群。这破坏了单一事实来源原则，导致 Git 状态与集群状态永久偏离，GitOps 工具将无法正常工作。在资源配额校准场景中，务必坚持“先改 Git，再同步集群”的工作流。

声明式配置是 GitOps 的“语言”，Git 仓库是“存储介质”，状态同步是“执行引擎”，不可变基础设施是“安全约束”。四者共同构成 GitOps 的闭环体系，为 Flux 与 Argo CD 的资源配额校准能力提供了理论基础。