1.1 GitOps 核心概念：声明式部署、状态同步、Pull vs Push 模式、Git 作为单一事实来源
GitOps 是一种以 Git 仓库作为系统状态唯一权威来源的运维模式。它通过声明式配置和自动化同步机制，将基础设施与应用程序的交付过程统一纳入版本控制。理解其核心概念是掌握后续资源配额校准与故障排查的基础。
1.1.1 声明式部署（Declarative Deployment）
声明式部署的核心思想是“定义目标状态，而非操作步骤”。运维人员只需在 Git 仓库中描述系统“应该是什么样”，而不需要编写脚本去执行“如何变成这样”。
| 对比维度 | 声明式（Declarative） | 命令式（Imperative） |
|---|---|---|
| 关注点 | 目标状态（What） | 操作步骤（How） |
| 幂等性 | 天然幂等，重复执行结果一致 | 需额外处理幂等逻辑 |
| 可审计性 | Git 历史完整记录每次状态变更 | 操作日志分散，难以追溯 |
| 故障恢复 | 自动收敛至 Git 中定义的状态 | 需人工介入重新执行命令 |
| 典型工具 | Kubernetes YAML + Argo CD / Flux | kubectl run / apply 命令 |
实践要点：在 GitOps 中，所有资源配额（如 CPU、内存、存储）都应以声明式 YAML 文件的形式存放在 Git 仓库中。任何手动通过 kubectl edit 或 dashboard 修改的行为都会导致状态漂移，成为故障排查的隐患。
1.1.2 Git 作为单一事实来源（Single Source of Truth）
Git 仓库存储了集群所有资源的期望状态，包括 Deployment、Service、ConfigMap、ResourceQuota、LimitRange 等。任何对集群的变更都必须先提交到 Git，再由自动化工具同步到目标环境。这种机制确保了环境状态的可复现性与可审计性。
1.1.3 状态同步（State Synchronization）
状态同步是 GitOps 的核心执行机制。GitOps Operator（如 Argo CD、Flux）持续对比 Git 仓库中的期望状态与集群中的实际状态，当发现差异时执行同步操作，将集群状态收敛至期望状态。
同步触发条件：
- 定时轮询：Operator 每隔 N 秒（如 180s）自动拉取 Git 仓库最新提交。
- Webhook 触发：Git 仓库收到 push 事件后，通过 Webhook 通知 Operator 立即同步。
- 手动同步：运维人员通过 CLI 或 UI 手动触发同步操作。
1.1.4 Pull vs Push 模式
GitOps 的两种主流架构模式决定了 Agent 的部署位置与通信方向。理解其差异有助于在资源配额校准场景中定位同步失败的根本原因。
| 对比维度 | Pull 模式（推荐） | Push 模式 |
|---|---|---|
| Agent 位置 | Agent 运行在目标集群内部 | CI/CD 系统运行在集群外部 |
| 通信方向 | 集群主动拉取 Git 仓库 | 外部系统推送配置到集群 |
| 安全性 | 集群无需对外暴露 API | 需暴露集群 API 或使用 Tunnel |
| 网络依赖 | 集群出网可达 Git 即可 | CI/CD 系统需入网访问集群 |
| 典型工具 | Argo CD、Flux | Jenkins + kubectl、GitLab CI |
| 故障排查难度 | 低（Agent 日志在集群内） | 高（需排查 CI/CD 与集群网络） |
故障排查提示：在资源配额校准场景中，如果使用 Push 模式且 CI/CD 系统与集群之间存在 NAT 或防火墙，同步失败的概率会显著增加。建议生产环境优先采用 Pull 模式，将 Agent 部署在集群内部，降低网络链路复杂度。