3. Git作为单一事实来源：Git仓库结构设计、分支策略与环境配置管理
在GitOps模型中，Git仓库不仅是代码的存储载体，更是整个系统的单一事实来源（Single Source of Truth）。集群的期望状态、应用配置、基础设施定义以及环境差异，都必须以声明式清单的形式持久化在Git仓库中。本章将深入剖析仓库结构设计、分支策略选择以及环境配置管理三个核心维度，帮助你在Operator集成场景下构建可审计、可回滚、可复制的GitOps工作流。
核心原则： 任何对集群状态的变更，都必须通过Pull Request（PR）提交到Git仓库，再由Operator或Argo CD等工具自动同步到目标环境。手动修改集群的行为应被严格禁止。
3.1 Git仓库结构设计：单仓库 vs. 多仓库
仓库结构的选择直接影响团队协作效率、权限控制粒度以及CI/CD流水线的复杂度。以下是两种主流模式的对比：
| 维度 | 单仓库（Monorepo） | 多仓库（Multi-Repo） |
|---|---|---|
| 管理成本 | 低，一个仓库统一管理所有环境与应用 | 高，需维护多个仓库的权限与流水线 |
| 原子性变更 | 支持，一次PR可同时修改应用代码与基础设施 | 需跨仓库协调，原子性难以保证 |
| 权限控制 | 粗粒度，难以按应用或环境隔离 | 细粒度，每个仓库可独立设置权限 |
| CI/CD复杂度 | 中等，需按路径触发不同流水线 | 简单，每个仓库独立触发 |
| 推荐场景 | 中小团队、微服务数量较少（<20）、统一运维 | 大型组织、多团队独立交付、严格安全隔离 |
对于Operator集成场景，推荐采用分层单仓库结构，将应用代码、Operator部署清单、环境配置按目录层级清晰分离：
gitops-repo/
├── apps/ # 应用声明式清单
│ ├── frontend/
│ │ ├── base/ # Kustomize base
│ │ └── overlays/ # 环境覆盖
│ └── backend/
├── operators/ # Operator部署与CRD
│ ├── prometheus-operator/
│ └── custom-operator/
├── infrastructure/ # 基础设施（Ingress、StorageClass）
├── clusters/ # 集群级配置（RBAC、Namespace）
└── environments/ # 环境差异配置
├── dev/
├── staging/
└── prod/
关键设计：
base/ 目录存放通用清单，overlays/ 通过Kustomize的patch机制注入环境差异。Operator的CRD实例应放在对应应用的目录下，而非混入Operator自身部署目录。
3.2 分支策略：GitFlow vs. Trunk-Based
分支策略决定了变更如何流入Git仓库的“事实来源”主干。在GitOps实践中，分支策略直接影响同步延迟与发布风险。
3.2.1 GitFlow（适合正式环境严格管控）
- 结构：
main（生产）、develop（开发集成分支）、feature/*、release/*、hotfix/*。 - GitOps同步点： Operator只监听
main分支。所有变更必须经过develop→release→main的合并流程。 - 优势： 发布流程严谨，支持多版本并行维护，适合合规要求高的金融、医疗场景。
- 劣势： 合并频繁，同步延迟高，不适合高频发布的云原生应用。
3.2.2 Trunk-Based（适合高频发布与GitOps）
- 结构： 只有
main（或master）主干，配合短期特性分支（feature/short-lived）。 - GitOps同步点： Operator持续监听
main分支。特性分支通过PR合并到main后，立即触发自动同步。 - 优势： 低延迟、高频率、减少合并冲突，与GitOps“持续同步”理念天然契合。
- 劣势： 对CI质量门禁要求高，需要完善的自动化测试与预生产环境验证。
避坑提示： 不要将
develop 或 feature 分支设置为Operator的同步目标。这会导致未经验证的清单被自动应用到集群，引发配置漂移。GitOps的“事实来源”必须是经过评审的稳定分支。
3.3 环境配置管理：从差异到一致性
环境配置管理的核心挑战在于：如何在保持声明式清单一致性的前提下，优雅地处理开发、预发、生产等环境之间的差异。GitOps推荐使用Kustomize或Helm作为配置管理工具。
3.3.1 环境差异分类
| 差异类型 | 示例 | 管理方式 |
|---|---|---|
| 资源规模 | 副本数：dev=1, prod=5 | Kustomize patches 或 Helm values |
| 外部依赖 | 数据库连接串、 | Sealed Secrets / External Secrets Operator |
| 功能开关 | Feature Flag 启用/禁用 | ConfigMap 或 Operator CRD 字段 |
| 基础设施 | Ingress域名、StorageClass名称 | 环境目录覆盖 |
3.3.2 推荐实践：环境即目录
在Git仓库中，每个环境对应一个独立的目录层级，通过Kustomize的overlay机制实现差异注入：
environments/
├── dev/
│ ├── kustomization.yaml
│ ├── replica-patch.yaml # 副本数=1
│ └── ingress-patch.yaml # dev.example.com
├── staging/
│ ├── kustomization.yaml
│ ├── replica-patch.yaml # 副本数=3
│ └── ingress-patch.yaml # staging.example.com
└── prod/
├── kustomization.yaml
├── replica-patch.yaml # 副本数=5
└── ingress-patch.yaml # prod.example.com
Operator集成要点： 如果Operator管理了自定义资源（CR），环境差异应通过CR的字段体现，而非修改Operator本身的部署配置。例如，
RedisCluster CR的 spec.replicas 在不同环境使用不同值，Operator只需保持同一版本即可。
3.4 配置安全：Secrets 管理
Git仓库不应存储明文敏感信息。在GitOps工作流中，推荐使用以下方案管理Secrets：
- Sealed Secrets： 在集群外加密Secrets，加密后的资源可安全提交到Git仓库，只有集群内的控制器能解密。
- External Secrets Operator： 从外部密钥管理系统（如AWS Secrets Manager、Vault）同步Secrets到Kubernetes，Git仓库只存储引用配置。
- SOPS + Age/GPG： 在提交前对YAML文件中的敏感字段进行加密，CI流水线中解密。
安全红线： 严禁将明文密码、、证书私钥提交到Git仓库。一旦泄露，应立即轮换密钥并清理Git历史中的敏感数据。