3. GitOps 基础概念：声明式配置、状态同步、Pull vs Push 模式
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的持续交付模式。其核心思想是将运维和部署逻辑从“手动执行命令”转变为“声明期望状态，由系统自动调和”。理解 GitOps 的三个基础概念——声明式配置、状态同步和Pull vs Push 模式——是掌握后续课程中“标准模板与 GitOps 结合”的关键前提。
3.1 声明式配置（Declarative Configuration）
声明式配置是指：你只需要描述系统“应该是什么样子”，而不需要编写“如何达到这个状态”的步骤。在 GitOps 实践中，整个采集作业平台的基础设施、应用配置、作业参数都以 YAML 或 JSON 文件的形式存储在 Git 仓库中。
关键对比： 命令式（Imperative） vs 声明式（Declarative）
| 维度 | 命令式（Imperative） | 声明式（Declarative） |
|---|---|---|
| 操作方式 | 执行具体命令：kubectl create deployment、kubectl scale |
提交配置文件：deployment.yaml、configmap.yaml |
| 状态管理 | 依赖操作者记忆或脚本顺序 | Git 仓库中始终保存完整期望状态 |
| 可审计性 | 低，操作记录分散在终端日志中 | 高，每次变更对应一次 Git Commit |
| 回滚能力 | 需要手动逆向操作 | 直接 git revert 或切换分支 |
| 适用场景 | 临时调试、一次性任务 | 生产环境持续部署、合规管控 |
在采集作业平台中，声明式配置表现为：
- 作业模板：定义采集任务的参数、调度规则、输出目标。
- 平台配置：定义服务副本数、资源限制、环境变量。
- 网络策略：定义采集器与存储后端之间的访问规则。
# 声明式作业模板示例（采集作业平台）
apiVersion: collector.ops/v1
kind: JobTemplate
metadata:
name: nginx-log-collector
spec:
schedule: "*/5 * * * *"
image: collector-agent:3.2.1
output:
type: kafka
topic: raw-logs
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"
3.2 状态同步（State Synchronization）
状态同步是 GitOps 的核心执行机制。系统持续比较 Git 仓库中的“期望状态”与运行环境中的“实际状态”，当两者不一致时，自动执行调和（Reconciliation）操作，使实际状态向期望状态收敛。
核心原则： 状态同步不是“一次性部署”，而是“持续调和”。即使有人手动修改了集群中的资源，GitOps 控制器也会在下一个同步周期将其恢复为 Git 中定义的版本。
状态同步的典型工作流程包含以下步骤：
- 检测差异：GitOps 控制器（如 ArgoCD、Flux）定期轮询 Git 仓库或监听 Webhook 事件。
- 比对状态：将 Git 中的期望配置与 Kubernetes 集群中的实时资源进行 Diff。
- 执行调和：如果存在偏差，控制器自动应用变更（创建、更新或删除资源）。
- 反馈状态：将同步结果写回 Git 仓库或通知监控系统。
3.3 Pull vs Push 模式
GitOps 的部署模式分为 Pull 模式和 Push 模式，两者在安全模型、网络拓扑和自动化程度上存在显著差异。在采集作业平台场景中，选择哪种模式直接影响边缘采集器的管理方式。
| 对比维度 | Pull 模式（推荐） | Push 模式 |
|---|---|---|
| 执行主体 | 集群内部的 Operator / Agent | CI/CD 管道（如 Jenkins、GitLab CI） |
| 网络方向 | 集群主动拉取 Git 仓库 | CI 系统主动推送至集群 API |
| 安全优势 | 集群无需暴露 API Server 给外部 | 需要管理 CI 系统的集群凭据 |
| 离线容忍 | 支持离线缓存，断网时保持最后状态 | 依赖 CI 系统持续可达 |
| 典型工具 | ArgoCD、Flux、Jenkins X | 传统 CI/CD + kubectl apply |
| 采集平台适用性 | 适合边缘采集器、防火墙后部署 | 适合中心化管控、内网开发环境 |
实践建议： 对于采集作业平台，如果采集器部署在客户内网或跨网络区域，强烈推荐使用 Pull 模式。这样你只需要让采集器集群能够访问 Git 仓库（通常是只读权限），而无需开放 Kubernetes API 端口到公网。
3.4 三者关系总结
声明式配置、状态同步和 Pull/Push 模式共同构成了 GitOps 的三角支柱：
- 声明式配置是基础，确保所有变更可追溯、可复现。
- 状态同步是引擎，驱动系统持续向期望状态收敛。
- Pull 模式是推荐部署方式，尤其适合采集作业平台这种需要跨网络、高安全要求的场景。