5月27日 23:40

什么是 GitOps？核心原则和主流工具怎么选？

GitOps 是什么？

GitOps 是一种以 Git 仓库为单一事实来源（Single Source of Truth）的持续交付方法。简单说，你把基础设施和应用的所有配置都用声明式代码写在 Git 里，集群自己从 Git 拉取变更并应用——不需要人工登录集群执行 kubectl apply，也不需要在 CI 流水线里直接推送部署。

这套方法最早由 Weaveworks 在 2017 年提出，核心动机是解决传统 CI/CD 的几个痛点：配置分散在多个平台、部署操作缺乏审计追踪、回滚靠人工记忆、集群权限难以收敛。GitOps 把这些问题统一收归到 Git 的工作流里解决。

GitOps 的四大核心原则

声明式描述

所有环境配置用声明式代码定义，而不是用脚本一步步执行。Kubernetes 天然就是声明式的——你写一个 Deployment YAML 描述「要 3 个副本」，而不是写脚本去逐个创建 Pod。GitOps 继承了这一思路，配置文件只描述期望状态，不描述操作步骤。

Git 作为单一事实来源

Git 仓库是系统期望状态的唯一权威来源。任何对集群的变更都必须先提交到 Git，经过 code review 后再同步到集群。这意味着：每一次变更都有 commit 记录、有作者、有 review 历史——审计和回滚变得和 git revert 一样简单。

自动拉取部署

集群内的 Operator 组件持续监听 Git 仓库的变化，检测到新提交后自动将配置应用到集群。这是 GitOps 和传统 CI/CD 最大的区别——传统方式是 CI 流水线把构建产物「推」到集群，GitOps 是集群内的组件主动「拉」取变更。拉取模式的好处是：CI 工具不需要集群的访问凭证，攻击面大幅缩小。

持续协调

系统持续比较集群的实际状态和 Git 中定义的期望状态，发现偏差自动纠正。如果有人绕过 GitOps 直接修改了集群配置（比如手动 kubectl edit），协调循环会检测到配置漂移并将其恢复到 Git 中的定义。这就是 Kubernetes 控制循环理念在部署流程上的延伸。

GitOps vs 传统 CI/CD：关键差异在哪？

维度	传统 CI/CD	GitOps
部署方式	Push：CI 推送到集群	Pull：集群主动拉取
配置存储	分散在 CI 平台、配置中心	集中在 Git 仓库
访问凭证	CI 需要集群凭证	集群内组件自行拉取，CI 不需集群权限
审计追踪	依赖 CI 日志，往往不完整	每次变更都有 Git commit
回滚方式	需要重新触发流水线或手动操作	git revert 即可回滚
配置漂移检测	通常不支持	自动检测并纠正

最核心的差异是 Push vs Pull。传统 CI/CD 中，Jenkins 或 GitHub Actions 需要持有集群的 kubeconfig 才能执行部署——一旦 CI 被攻破，攻击者就拿到了集群的控制权。GitOps 把部署动作收回到集群内部，CI 只负责构建镜像和推送镜像仓库，不需要任何集群访问权限。

GitOps 工作流程

一个典型的 GitOps 部署流程如下：

开发者提交业务代码到应用仓库，触发 CI
CI 运行测试、构建容器镜像、推送到镜像仓库
CI 更新配置仓库中的镜像 tag（这一步是关键——只改配置，不碰集群）
集群内的 GitOps Operator 检测到配置仓库的变更
Operator 自动将新配置同步到集群
协调循环持续监控，确保集群状态与 Git 一致

注意第 3 步：CI 不直接部署，而是通过更新 Git 配置间接触发部署。这保证了所有部署操作都有 Git 记录可追溯。

主流 GitOps 工具对比

目前生产环境使用最广泛的两个工具是 Argo CD 和 Flux，选哪个是团队落地 GitOps 时最常纠结的问题。

Argo CD

Argo CD 是 Intuit 开源的 Kubernetes 原生 GitOps 工具，目前是 CNCF 毕业项目。

核心能力：

通过 Application CRD 定义应用和环境的映射关系，支持多租户（Project）和多集群管理
内置 Web UI 和 CLI，可视化展示应用同步状态和资源拓扑
支持 Kustomize、Helm、Jsonnet 等多种配置管理工具
支持自动同步和手动同步两种模式，自动同步可配置 self-heal（自动修复配置漂移）

示例 Application 配置：

yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

适合场景： 多团队协作、多集群管理、需要精细权限控制、需要可视化运维界面。

Flux

Flux 是 Weaveworks 开源的 GitOps 工具，也是 CNCF 毕业项目，设计哲学是轻量和模块化。

核心能力：

架构拆分为 source-controller、kustomize-controller、helm-controller、notification-controller 等独立组件，按需启用
原生支持监听 Git 仓库变更和容器镜像 tag 变化——镜像更新后可自动触发配置更新和部署
资源占用低，适合资源受限环境
与 Kubernetes 控制器模式深度对齐

示例 GitRepository 配置：

yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: podinfo
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/stefanprodan/podinfo
  ref:
    branch: master
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: podinfo
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: podinfo
  path: ./kustomize
  prune: true

适合场景： 单集群或少量集群、追求轻量部署、团队对 GitOps 有一定经验、不需要复杂 UI。

Argo CD vs Flux：怎么选？

维度	Argo CD	Flux
架构	单体应用，功能集中	微服务化，组件按需组合
多租户	内置 Project 机制	无原生支持，需多实例
多集群	原生支持	需要每集群部署实例
UI 界面	功能完善的 Web UI	无官方 UI，依赖 CLI 和 CRD 状态
镜像自动更新	需配合 Image Updater	原生 image-reflector 支持
资源消耗	较高	较低
学习曲线	UI 友好，上手快	依赖 CRD 配置，需熟悉概念
社区活跃度	非常活跃，贡献者多	活跃，CNCF 托管

选型建议： 如果团队规模大、管理多集群多环境、需要权限隔离和可视化运维，选 Argo CD；如果集群数量少、追求轻量、团队更习惯声明式配置而非 UI 操作，选 Flux。两者都是生产级别的选择，不存在绝对优劣。

生产环境踩坑经验

配置漂移的处理策略： 开启 self-heal 自动修复看似省心，但生产环境中有人可能故意临时调整资源（比如紧急扩容）。建议生产环境使用手动同步+审批流程，非关键环境开启自动同步。

敏感信息管理： 不要把 Secret 明文提交到 Git。使用 Sealed Secrets 或 External Secrets Operator，在集群内解密。Flux 和 Argo CD 都支持集成这些方案。

仓库结构设计： 推荐把应用配置和基础设施配置分仓库管理。应用仓库放 Deployment、Service 等业务资源；基础设施仓库放 Namespace、RBAC、监控等平台资源。避免混在一起导致权限边界模糊。

shell
config-repo/
├── apps/                # 应用配置
│   ├── app-a/
│   │   ├── base/        # 基础配置
│   │   └── overlays/    # 环境差异
│   │       ├── dev/
│   │       ├── staging/
│   │       └── prod/
│   └── app-b/
└── infra/               # 基础设施配置
    ├── namespaces/
    ├── rbac/
    └── monitoring/

CI 与 GitOps 的边界： CI 只负责构建镜像和推送镜像仓库，CI 不应该有集群访问权限。如果 CI 需要更新配置仓库中的镜像 tag，用 bot 账号提 PR 而不是直接 push 到 main 分支——这样可以通过 code review 把关。

回滚策略： GitOps 的回滚本质是 git revert 配置变更，但要注意镜像回滚。如果新版本镜像已经推送到仓库，回滚 Git 配置后集群会重新拉取旧版本镜像。确保镜像仓库不会覆盖已有的 tag。

GitOps 的局限和适用边界

GitOps 不是银弹。以下场景需要谨慎评估：

非容器化应用：GitOps 的协调模型依赖声明式 API，传统虚拟机或物理机部署需要额外适配
实时动态配置：需要秒级生效的功能开关等配置，走 Git 审批流程太慢，应该配合配置中心使用
超大规模集群：单 Argo CD 实例管理数千个 Application 时会遇到性能瓶颈，需要考虑分片或多实例方案
数据库变更：Schema 迁移的回滚不像应用回滚那么简单，GitOps 需要配合专门的数据库迁移工具

GitOps 在 Kubernetes 生态中已经是非常成熟的实践，但落地时需要根据团队规模、集群复杂度和安全要求选择合适的工具和策略，而不是照搬模板。从非生产环境开始试点，验证工作流后再逐步推广到生产环境。

标签：Devops