1. GitOps 概述
1.1 什么是 GitOps
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生运维模式。它将声明式基础设施与版本控制相结合，通过自动化流程确保集群的实际状态始终与 Git 中定义的期望状态保持一致。
核心思想： Git 仓库不仅是代码的存储地，更是整个系统状态的权威描述。任何对基础设施或应用配置的变更，都必须先提交到 Git，再由自动化工具同步到目标环境。
1.2 GitOps 三大核心原则
| 原则 | 说明 | 关键实践 |
|---|---|---|
| 声明式（Declarative） | 系统期望状态由描述性文件定义，而非指令性脚本 | 使用 Kubernetes YAML、Helm Chart、Kustomize 等声明式配置 |
| 版本控制（Version Controlled） | 所有配置变更通过 Git 提交记录，可追溯、可回滚 | 分支策略、Pull Request 审查、标签与 Release |
| 自动化（Automated） | Git 仓库变更自动触发同步，无需手动干预 | Argo CD、Flux CD 等 Operator 持续对比与同步 |
1.3 GitOps 与传统 CI/CD 的区别
传统 CI/CD 以“推送（Push）”模式驱动，而 GitOps 采用“拉取（Pull）”模式。下表从多个维度对比两种模式的核心差异：
| 对比维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 部署模式 | CI 流水线推送制品到环境 | Operator 从 Git 拉取期望状态并同步 |
| 配置存储 | 分散在 Jenkinsfile、脚本、配置中心 | 统一存储在 Git 仓库 |
| 变更触发 | Webhook 或定时触发流水线 | Git 提交触发自动同步 |
| 回滚方式 | 重新运行旧版本流水线或手动恢复 | git revert 或切换到旧分支 |
| 状态一致性 | 依赖流水线执行结果，可能漂移 | 持续对比，自动修复漂移 |
| 安全模型 | CI 工具需要集群凭证 | Operator 只读访问 Git，无需暴露集群凭证 |
关键洞察： GitOps 将“部署”从 CI 流水线中剥离，CI 只负责构建和测试，部署由专门的 GitOps Operator 完成。这种分离显著降低了 CI 系统的权限风险，同时提升了部署的可审计性。
1.4 GitOps 工作流示例
一个典型的 GitOps 工作流包含以下步骤：
- 开发人员 修改应用配置或 Kubernetes 清单，提交 Pull Request 到 Git 仓库。
- CI 流水线 执行代码检查、单元测试、镜像构建，并将新镜像推送到容器仓库。
- 代码审查 通过后，变更合并到主分支（main/release）。
- GitOps Operator（如 Argo CD）检测到 Git 仓库状态变化，拉取最新配置。
- Operator 对比集群当前状态与 Git 中定义的期望状态，生成差异补丁。
- 自动同步 将变更应用到目标集群，完成配置热更新。
1.5 为什么 GitOps 适合 Envoy 配置热更新
Envoy 作为数据面代理，其配置变更频繁且对正确性要求极高。GitOps 为 Envoy 配置管理带来以下优势：
- 配置版本化： 每次 Envoy 配置变更都有 Git 提交记录，方便审计和问题定位。
- 声明式路由规则： 使用 Istio VirtualService / DestinationRule 等 CRD 声明式定义流量策略。
- 自动同步与回滚： 当配置错误导致故障时，可通过
git revert快速恢复。 - 同步窗口控制： 结合同步窗口策略，在业务低峰期执行配置变更，降低风险。
注意： GitOps 并非银弹。对于需要毫秒级响应的配置变更，或涉及敏感凭证的动态注入场景，需要结合 Secret 管理工具（如 Sealed Secrets、External Secrets）和同步窗口策略来弥补纯 GitOps 的不足。