Kubernetes GitOps 交付体系：用声明式流程管理集群变更

Kubernetes 的优势是声明式 API，但很多团队仍然用手工 kubectl apply 管理生产变更。短期看很快，长期看会带来配置漂移、权限失控、变更不可追踪和回滚困难。GitOps 的核心思想是：Git 仓库保存期望状态，控制器持续把集群拉回期望状态，所有生产变更都通过代码审查和自动同步完成。

GitOps 不只是部署工具选择，而是一种变更治理模型。它让集群状态、审计记录、发布流程和回滚入口统一到 Git。

GitOps 的基本闭环

典型链路如下：

1. 开发或平台工程师提交 manifest、Helm values 或 Kustomize patch。
2. CI 执行 lint、测试、镜像扫描、策略检查。
3. 合并到目标分支。
4. Argo CD 或 Flux 检测到仓库变化。
5. 控制器同步资源到集群。
6. 可观测性系统验证发布结果。

关键变化是：生产集群不再以人工命令为主入口，而以 Git 合并为入口。这样可以清楚知道谁在什么时候改了什么，以及如何回滚。

仓库结构

仓库结构没有唯一标准，但要清晰表达应用、环境和集群边界。常见结构：

platform-gitops/
  apps/
    checkout/
      base/
      overlays/
        dev/
        staging/
        prod/
  clusters/
    prod-hk/
    prod-sg/
  platform/
    ingress/
    monitoring/
    cert-manager/

应用配置和平台配置可以分仓，也可以单仓。多团队环境下，建议把应用仓库与集群配置仓库分离，避免应用团队拥有过大的平台修改权限。

Helm、Kustomize 与原生 YAML

Helm 适合参数化复杂应用，Kustomize 适合环境差异叠加，原生 YAML 适合简单资源。不要为了统一而强行使用一种工具。

常见组合是：第三方组件使用 Helm，内部应用使用 Kustomize overlay，少量平台策略使用原生 YAML。重点是渲染结果可审查、差异可理解、回滚可执行。

在 CI 中建议渲染最终 manifest，并执行：

• YAML 语法检查。
• Kubernetes schema 校验。
• 策略检查。
• 镜像来源检查。
• 资源 requests 检查。

环境提升

GitOps 中的环境提升应避免复制粘贴。推荐使用基础配置加环境 patch。开发环境可以更宽松，生产环境应显式声明副本数、资源 requests、PDB、HPA、Ingress、Secret 引用。

镜像版本提升可以采用两种方式：

• CI 修改 GitOps 仓库中的 image tag 或 digest。
• GitOps 控制器配合镜像自动更新策略。

生产环境建议使用 digest 或不可变 tag，减少“同一个 tag 指向不同镜像”的风险。

漂移检测

GitOps 的一个重要能力是发现集群实际状态与 Git 期望状态不一致。漂移可能来自人工修改、控制器默认值、Webhook 注入、自动扩缩容字段变化。

不是所有漂移都需要立刻修复。例如 HPA 修改 replicas 是正常行为，某些 status 字段也不应纳入比较。需要配置忽略规则，但不能把大量业务字段都忽略掉，否则 GitOps 失去意义。

对生产集群，建议将高风险漂移告警化，例如 Deployment 镜像被人工替换、Service 类型被改成 LoadBalancer、RBAC 被扩大。

权限边界

GitOps 控制器通常拥有较高集群权限，因此要限制谁能修改 GitOps 仓库。建议：

• 使用代码审查保护主分支。
• 生产变更需要平台或服务负责人审批。
• 控制器权限按项目或 namespace 分隔。
• 避免一个控制器管理所有集群所有资源。
• 对 Argo CD 项目设置资源白名单和目标 namespace。

Git 权限就是生产权限。这个观念必须明确。

Secret 管理

GitOps 最大挑战之一是 Secret。不能把明文 Secret 提交进仓库。常见方案：

• Sealed Secrets：提交加密后的 Secret，由集群内控制器解密。
• SOPS：使用 KMS 或 PGP 加密文件，CI/CD 或控制器解密。
• External Secrets Operator：仓库保存外部密钥引用，真实密钥保存在 Vault 或云 Secret Manager。

对多环境、多集群，External Secrets 通常更容易统一轮换和审计。

回滚策略

GitOps 回滚本质上是回退 Git 期望状态。可以通过 revert commit、切换 image digest、回退 Helm values 实现。

但要注意，配置回滚不一定等于业务恢复。数据库迁移、缓存结构、消息格式、外部依赖变更都可能不可逆。因此发布流程要把应用版本、配置变更和数据迁移的关系讲清楚。

建议将高风险变更拆成小步：

1. 先发布兼容代码。
2. 再变更配置或流量。
3. 观察稳定后执行数据迁移。
4. 最后清理旧逻辑。

人工操作

GitOps 并不意味着禁止所有人工操作。事故中可能需要临时扩容、摘流量、暂停同步或回滚。但这些动作要在事故结束后写回 Git，消除漂移。

建议建立 break-glass 权限：平时不可用，事故时临时授权，事后审计。

总结

GitOps 的价值不是让部署看起来更时髦，而是把 K8s 变更纳入工程纪律。它让配置有来源、变更有审查、漂移可发现、回滚有入口。落地时要关注仓库结构、权限、Secret、策略和可观测性，工具只是其中一环。好的 GitOps 体系会让集群更可控，也会让团队更敢于频繁、小步地交付。