一、GitOps 核心概念
1.1 定义
GitOps 是一种 以 Git 为单一可信源 的 DevOps 实践方法论,核心思想是将基础设施配置、应用部署配置等所有运维操作以 声明式配置文件 的形式存储在 Git 仓库中,通过 Git 的版本控制、分支管理、合并请求(MR/PR)流程实现配置的变更管理,再通过自动化工具将 Git 中的声明式配置同步到目标环境(如 Kubernetes 集群、Linux 服务器),最终实现 "配置即代码(IaC)+ 自动化同步 + 持续验证" 的闭环运维模式。
1.2 核心原则
| 原则 | 解释 | 运维场景落地 |
|---|---|---|
| 声明式系统 | 只定义 "目标状态"(如应用需运行 3 个副本、端口 8080 暴露),不关心 "如何实现" | Kubernetes 的 YAML 配置(Deployment、Service)、Linux 的 Ansible Playbook 均为声明式 |
| Git 单一可信源 | 所有环境(开发、测试、生产)的配置唯一存储在 Git 仓库,Git 记录所有变更历史 | 避免 "本地配置漂移",运维人员无需登录服务器修改配置,所有操作通过 Git 提交 |
| 自动化同步 | 工具持续监控 Git 仓库变更,自动将配置同步到目标环境,无需人工干预 | 提交配置到 Git 后,工具自动执行部署/更新,替代传统 "SSH 登录服务器执行脚本" |
| 持续验证与反馈 | 实时校验目标环境状态是否与 Git 中的声明式配置一致,不一致时自动修复或告警 | 若 Kubernetes 集群中应用副本数被手动修改,工具会自动恢复为 Git 中定义的数量 |
| 审计与可追溯 | 所有配置变更通过 Git 提交记录(作者、时间、修改内容)追溯,支持回滚 | 出现故障时,可通过 Git 日志快速定位变更原因,一键回滚到上一稳定版本 |
1.3 GitOps 与传统运维的区别
| 维度 | 传统运维 | GitOps 运维 |
|---|---|---|
| 配置存储 | 分散在服务器、本地文件、Excel 表格 | 集中在 Git 仓库(版本化管理) |
| 变更方式 | 人工登录服务器修改配置、执行脚本 | 通过 Git 提交/PR 变更配置,自动化同步 |
| 环境一致性 | 依赖人工保障,易出现 "开发环境正常,生产环境异常" | 所有环境使用同一套 Git 配置(通过分支区分环境),一致性高 |
| 故障回滚 | 手动执行回滚脚本,依赖运维经验 | 直接基于 Git 版本回滚(如 git revert),快速可靠 |
| 审计追踪 | 无统一日志,难以追溯变更来源 | Git 提交记录完整追溯(谁改、改了什么、什么时候改) |
| 协作模式 | 口头沟通或文档同步,易产生误解 | 通过 Git PR/MR 审核流程,协作透明可追溯 |
二、GitOps 工作流
2.1 标准流程
仓库分层设计(核心原则:分离与隔离)
| 仓库类型 | 用途 | 分支策略 |
|---|---|---|
| 应用代码仓 | 存储业务代码、Dockerfile、构建脚本(如 pom.xml、package.json) |


