GitOps | devexamples

GitOps 以 Git 作为基础设施与应用状态的唯一事实来源，由自动化控制器持续把集群调谐到已提交的期望状态。

Git 即期望状态

在 GitOps 流程中，仓库声明系统期望状态：Deployment、Service、策略与基础设施。集群内的控制器（如 Argo CD 或 Flux）监听该仓库并与实际状态比较，发现差异就应用。合并 Pull Request 于是成为发布动作，提交历史成为审计日志。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.8.2

何时使用

当多个团队修改共享集群、审计方需要知道谁在何时改了什么、或者灾难恢复等同于重新应用仓库时，GitOps 很合适。它与 Kubernetes 最契合，因为控制器可以持续调谐。与流水线推送式部署相比，GitOps 从集群内部拉取变更，部署凭据无需离开环境。

权衡

调谐循环会与手工热修复冲突，因此要定义紧急通道流程。仓库结构很重要：按环境分目录能让晋级显式可见，而复杂的分支策略会带来大量合并工作。密钥管理与清单渲染工具也会增加复杂度。

示例与常见误解

某平台团队把每个环境放在独立目录。晋级一个版本就是提交一个把镜像 tag 从预发复制到生产的 Pull Request，并由另一位工程师评审。若有人手工修改集群，控制器会在一分钟内报告漂移。把 GitOps 等同于把 YAML 放进 Git 的误解忽略了调谐器，而它才是模型可运转的关键。相关概念包括基础设施即代码、CI/CD 与不可变基础设施。