GitOps 入门与实践：用 Git 驱动一切

在云原生和 Kubernetes 时代，如何高效、可靠地管理基础设施和应用部署，成为工程团队的重要挑战。GitOps 作为一种新兴的运维与交付模式，正逐渐成为主流实践。

本文将从概念、核心思想、工作流程到实践落地，系统介绍 GitOps。

---

一、什么是 GitOps？

GitOps = Git + Operations（运维）

GitOps 是一种以 Git 作为单一可信数据源（Single Source of Truth） 的运维模型，通过声明式配置和自动化工具，实现基础设施和应用的持续交付。

简单来说：

👉 所有系统状态都定义在 Git 中
👉 所有变更通过 Git 提交完成
👉 系统自动同步 Git 中的期望状态

---

二、GitOps 的核心理念

1. 声明式（Declarative）

不描述“怎么做”，而是描述“期望是什么”。

例如在 Kubernetes 中：

replicas: 3
image: nginx:latest

你不需要写脚本扩容，只需声明最终状态。

---

2. Git 作为唯一事实来源

Git 仓库中保存：

• Kubernetes YAML
• Helm Chart
• Kustomize 配置
• 基础设施定义（如 Terraform）

优势：

• 完整历史记录（审计）
• 可回滚
• 权限控制（PR 审核）

---

3. 自动化同步（Reconciliation）

系统持续执行：

👉 “实际状态” vs “Git 中的期望状态”

一旦不一致，就自动修复。

---

4. 不可变基础设施（Immutable Infrastructure）

避免“在线修改”，所有变更必须通过 Git：

❌ 手动 kubectl 修改
✅ 修改 YAML → 提交 Git → 自动部署

---

三、GitOps 的工作流程

一个典型流程如下：

开发者修改配置
        ↓
提交到 Git（PR + Code Review）
        ↓
合并到主分支
        ↓
GitOps 工具检测到变更
        ↓
自动同步到集群
        ↓
系统状态与 Git 保持一致

---

四、GitOps 架构模式

1. Push 模式（传统 CI/CD）

CI 工具 → 推送部署到 Kubernetes

问题：

• 凭证管理复杂
• 安全性较弱
• 状态不可见

---

2. Pull 模式（GitOps 推荐）

Kubernetes 集群中的 Agent
        ↓
主动从 Git 拉取配置
        ↓
应用到集群

优点：

• 更安全（无需暴露集群）
• 更符合“声明式”
• 自动修复漂移

---

五、常见 GitOps 工具

1. Argo CD

特点：

• Kubernetes 原生
• UI 可视化
• 支持自动同步与回滚

适合：

👉 大多数 K8s 场景

---

2. Flux

特点：

• CNCF 项目
• 更轻量
• 与 Git 深度集成

---

3. Jenkins X（已逐渐淡出主流）

---

六、GitOps 的核心优势

1. 可追溯性（Auditability）

所有变更都有记录：

git log

谁改了什么，一目了然。

---

2. 可回滚（Rollback）

回滚只需：

git revert

系统自动恢复到旧版本。

---

3. 一致性（Consistency）

开发 / 测试 / 生产环境：

👉 全部来源于同一套配置

---

4. 自动修复（Self-healing）

如果有人手动改了集群：

👉 GitOps 工具会自动恢复正确状态

---

5. 安全性更高

• 不需要 CI 直接访问生产环境
• 权限集中在 Git

---

七、GitOps vs 传统 CI/CD

对比项	传统 CI/CD	GitOps
部署方式	CI 推送	集群拉取
状态管理	分散	Git 统一
回滚	复杂	Git revert
审计	较弱	强（Git log）
安全性	较低	更高

---

八、GitOps 实践示例（Kubernetes）

1. Git 仓库结构

repo/
├── apps/
│   ├── frontend/
│   └── backend/
├── environments/
│   ├── dev/
│   ├── staging/
│   └── prod/

---

2. 修改配置

replicas: 5

---

3. 提交变更

git commit -am "scale backend to 5 replicas"
git push

---

4. 自动部署

GitOps 工具检测到变化并执行：

kubectl apply -f ...

---

九、GitOps 的挑战

1. 学习成本

• Kubernetes
• 声明式思想
• Git 工作流

---

2. 调试难度

问题可能来自：

• Git 配置
• 控制器
• 集群状态

---

3. 多环境管理复杂

需要：

• 分支策略
• Kustomize / Helm

---

十、最佳实践

✅ 1. 使用 PR 审核所有变更

避免直接 push 主分支

---

✅ 2. 环境隔离

• dev / staging / prod 分开管理

---

✅ 3. 使用 Kustomize 或 Helm

提高配置复用性

---

✅ 4. 启用自动同步 + 手动审批（生产环境）

---

✅ 5. 严格禁止手动改集群

否则 GitOps 会“打架”

---

十一、总结

GitOps 本质上是：

用 Git 管理一切，用自动化确保一致性

它将：

• 运维流程代码化
• 部署流程标准化
• 系统状态可追踪化

在 Kubernetes 和云原生体系中，GitOps 已经成为一种事实标准。

---

如果你现在在做：

• Kubernetes 运维
• 平台工程（Platform Engineering）
• DevOps 转型

👉 GitOps 基本是“必学项”。