4. GitOps 工作流基础：Git 作为单一事实来源、声明式配置、Pull 机制与 Push 机制对比
GitOps 的核心思想是将 Git 仓库作为整个系统的单一事实来源，所有环境状态（基础设施、应用配置、网络策略）都通过声明式配置定义在 Git 中，并通过自动化机制确保实际运行环境与 Git 中的期望状态保持一致。本章将拆解这三个基础支柱，并重点对比 Pull 与 Push 两种同步机制。
4.1 Git 作为单一事实来源
在传统运维模式中，配置分散在 CI/CD 脚本、运维工具、人工操作和监控系统中，一旦出现配置漂移，很难追溯根因。GitOps 要求所有环境状态都集中存储在 Git 仓库中，形成唯一的权威参考点。
| 特性 | 传统模式 | GitOps 模式 |
|---|---|---|
| 配置存储 | 分散在多个系统、脚本、人工操作中 | 集中存储在 Git 仓库 |
| 变更追溯 | 依赖操作日志、聊天记录、记忆 | 完整的 Git 提交历史，可回滚到任意版本 |
| 权限控制 | 系统级权限，难以细粒度审计 | 基于 Git 仓库的 PR 审批、分支保护 |
| 状态一致性 | 容易发生配置漂移 | 持续协调，自动修复漂移 |
实践要点：单一事实来源并不意味着所有配置都放在一个仓库中。推荐按环境（dev/staging/prod）或按领域（网络/安全/应用）拆分仓库，但每个仓库内部必须保持自包含和可复现。
4.2 声明式配置
声明式配置是 GitOps 的第二个支柱。与命令式（Imperative）配置不同，声明式只描述“最终状态是什么”，而不描述“如何到达这个状态”。Envoy 的 xDS 协议天然支持声明式配置，Envoy 代理只关心最终的路由、监听器、集群配置，而不关心这些配置是如何生成的。
| 对比维度 | 命令式配置 | 声明式配置 |
|---|---|---|
| 操作方式 | 执行一系列步骤（kubectl run、kubectl scale） | 提交期望状态文件（kubectl apply -f） |
| 幂等性 | 非幂等，重复执行可能产生不同结果 | 幂等，重复 apply 结果一致 |
| 漂移检测 | 需要额外工具对比 | 天然支持，持续协调 |
| Envoy 场景 | 手动调用 POST /config_dump 或重启 | 通过 xDS 推送期望的监听器/路由/集群 |
# 声明式 Envoy 配置示例（简化版）
# 期望状态：监听 8080 端口，将流量路由到 backend 集群
static_resources:
listeners:
- name: listener_8080
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: backend
domains: ["*"]
routes:
- match: { prefix: "/" }
route: { cluster: backend_service }
http_filters:
- name: envoy.filters.http.router
clusters:
- name: backend_service
connect_timeout: 0.25s
type: STRICT_DNS
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: backend_service
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address: { address: backend.example.com, port_value: 80 }4.3 Pull 机制与 Push 机制对比
GitOps 工作流中，将 Git 中的期望状态同步到实际运行环境有两种主流机制：Push 机制和Pull 机制。理解两者的差异对于设计可靠的自动化验证方案至关重要。
4.3.1 Push 机制
Push 机制由 CI/CD 管道主动将配置“推送”到目标环境。典型的流程是：开发人员提交代码 → CI 构建 → CD 工具（如 Jenkins、GitHub Actions）直接调用 Kubernetes API 或 Envoy 管理接口应用配置。
- 优点：流程直观，与现有 CI/CD 工具链集成简单。
- 缺点：CI/CD 工具需要直接访问目标集群的 API；如果网络隔离或权限不足，推送可能失败；缺少持续协调能力，一旦推送完成后环境被手动修改，不会自动修复。
4.3.2 Pull 机制
Pull 机制由运行在目标环境中的 Operator 或 Agent 主动从 Git 仓库拉取配置。典型的实现是 Argo CD 或 Flux，它们在集群内部运行，持续监控 Git 仓库的变化，并将期望状态应用到集群。
- 优点：Agent 在集群内部运行，无需外部 CI/CD 工具直接访问集群 API；天然支持持续协调，自动修复配置漂移；安全性更高，集群无需对外暴露管理端口。
- 缺点：需要额外部署和维护 Operator；初次配置相对复杂。
关键区别：Push 机制是“事件驱动”的（CI 完成后推送一次），Pull 机制是“状态驱动”的（持续对比 Git 和实际状态，不断协调）。对于 Envoy 配置热更新场景，Pull 机制能更好地保证配置一致性，尤其是在多集群或边缘部署场景中。
4.4 选择建议：Envoy 配置热更新场景
在 Envoy 配置热更新自动化验证的课程场景中，我们推荐使用 Pull 机制，原因如下：
| 场景需求 | Push 机制支持 | Pull 机制支持 |
|---|---|---|
| 配置漂移自动修复 | 不支持 | ✅ 持续协调 |
| 多集群统一管理 | 需要为每个集群配置 CI/CD | ✅ 一个 Git 仓库管理所有集群 |
| Envoy xDS 热更新 | 需要额外触发机制 | ✅ Operator 自动触发 |
| 安全合规（最小权限） | CI/CD 需要集群 API 访问权限 | ✅ Operator 在集群内部运行 |
| 自动化验证集成 | 需要单独编写验证脚本 | ✅ 可在同步窗口内自动验证 |
注意：Pull 机制虽然优势明显，但并非银弹。在需要紧急热修复的场景下，Push 机制可以绕过 Git 审批流程直接生效。生产环境中建议采用混合模式：日常变更走 Pull 机制，紧急变更走 Push 机制并事后补录 Git。