引言
- 痛点引入： Kubernetes 配置（YAML/JSON）日益复杂，手动管理在多环境、多团队协作下极易出错（配置漂移、版本混乱、回滚困难）。
- 解决方案： Git 作为成熟的版本控制系统，是管理 K8s 配置的理想选择。结合云原生理念（特别是 GitOps），可实现配置即代码（IaC），提升可靠性、可审计性和自动化水平。
- 文章目标： 阐述 Git 在管理 K8s 配置版本中的核心作用、最佳实践和主流工具链。
一、为什么 Kubernetes 配置需要版本管理？
* **配置即基础设施：** K8s YAML 文件定义了集群状态，是核心资产。
* **面临的挑战：**
* **多环境一致性：** Dev, Test, Staging, Prod 环境配置差异管理。
* **配置漂移：** 手动 `kubectl edit` 导致实际状态与期望状态不符。
* **变更追溯：** 谁在何时修改了什么？为何修改？
* **安全协作：** 多人协作修改时的冲突解决与权限控制。
* **回滚与审计：** 快速回滚到稳定版本，满足合规审计要求。
* **Git 的优势：** 版本历史、分支管理、合并请求、代码审查、访问控制。二、核心概念：Git 作为 K8s 配置的单一可信源
* **声明式配置：** K8s 是声明式系统，Git 完美存储期望状态。
* **单一可信源：** Git 仓库是配置的唯一来源，杜绝未经版本控制的修改。
* **工作流程转变：** 从直接操作集群转向在 Git 中修改配置，通过流程部署到集群。三、Git 管理 K8s 配置的最佳实践
* **3.1 仓库结构设计**
* 单一仓库 vs 多仓库（按应用/团队/环境）的权衡。
* 推荐结构示例：
```
├── clusters/ # 按集群组织
│ ├── production/ # 生产集群配置
│ │ ├── namespace-app1/
│ │ ├── namespace-app2/
│ │ └── cluster-wide/ # 集群级资源 (如 StorageClass, NetworkPolicy)
│ └── staging/
├── base/ # 跨环境通用基础配置 (Kustomize)
├── overlays/ # 环境差异化配置 (Kustomize: dev, staging, prod)
├── charts/ # Helm Chart (可选)
├── policies/ # 策略文件 (如 OPA Gatekeeper)
└── README.md
```
* **3.2 Git 分支策略**
* **环境映射：** `main` -> Prod, `staging` -> Staging, `develop` -> Dev (或使用目录结构 + 单一分支)。
* **特性分支：** 为新功能或修复创建分支，通过 Merge/Pull Request 合并。
* **发布分支：** 为稳定版本创建长期维护分支 (如 `release-1.0`)。
* **3.3 提交规范 (Commit Convention)**
* 清晰的提交信息：说明修改内容、影响范围、关联 Issue。
* 推荐规范：类似 Conventional Commits。
* **3.4 代码审查 (Code Review)**
* Pull/Merge Request 是核心质量控制关口。
* 审查内容：语法正确性、安全性、合规性、资源合理性、是否符合设计模式。
* **3.5 配置模板化与参数化**
* **Helm：** 使用 Charts 和 `values.yaml` 管理参数。
* **Kustomize：** 使用 `kustomization.yaml` 进行配置叠加和补丁。
* 避免硬编码，提升配置复用性。四、迈向自动化：GitOps 工作流
* **什么是 GitOps：** 以 Git 为操作中心，自动化同步 Git 中配置到集群。
* **核心原则：** 声明式、版本化、自动化、持续同步、状态自愈。
* **工作流程：**
1. 开发者在 Git 中修改配置 (创建 PR)。
2. PR 通过审查后合并到目标分支 (如 `main`)。
3. **GitOps 控制器** (如 Argo CD, Flux) 检测到 Git 变更。
4. 控制器自动将变更应用到目标 Kubernetes 集群，使集群状态与 Git 状态一致。
5. 控制器持续监控，确保一致性 (自愈)。
* **优势：** 提升部署速度、可靠性、安全性、可审计性；减少手动操作。五、常用工具链
* **Git 平台：** GitHub, GitLab, Bitbucket。
* **配置管理/模板化：** Kustomize, Helm。
* **GitOps 控制器：**
* **Argo CD：** 功能丰富，UI 强大，支持多集群、复杂应用。
* **Flux：** CNCF 项目，轻量级，更侧重持续交付。
* **策略即代码：** OPA Gatekeeper, Kyverno (管理策略版本)。
* **配置验证：** kubeval, conftest, Datree。六、安全与权限控制
* **Git 仓库权限：** 精细控制谁可以推送、合并到哪些分支/目录。
* **Kubernetes RBAC：** GitOps 控制器应使用最小权限服务账号操作集群。
* **Secrets 管理：** **切勿**将明文密码存 Git！使用 Sealed Secrets, SOPS, Vault, 或 GitOps 工具集成的外部 Secret 管理。
* **审计日志：** 利用 Git 日志和 GitOps 工具日志追踪所有变更。七、故障排查与回滚
* **基于 Git 的排查：** `git blame`, `git diff`, `git log` 定位问题引入的提交。
* **回滚策略：** 最简单的回滚就是 `git revert` 有问题的提交，GitOps 控制器会自动将集群回滚。也可使用 Git 标签标记稳定版本进行回滚。八、总结
* 强调 Git 是管理 K8s 配置版本、实现可追溯性和协作的基石。
* GitOps 是将 Git 作为单一可信源理念的自动化延伸，是云原生配置管理的未来趋势。
* 鼓励采用结构化存储、代码审查、模板化、自动化工具和安全实践。
* 带来的价值：更高的可靠性、效率、安全性与合规性。附录 (可选)
* 示例仓库链接。
* 常用命令速查 (`git`, `kubectl`, `kustomize`, `helm`, `argocd`, `flux`)。
* 进一步学习资源 (文档、教程、社区)。说明：
- 重点突出： 强调 Git 的核心作用 (版本、历史、协作) 和 GitOps 带来的自动化价值。
- 结构清晰： 从为什么、是什么、怎么做、用什么工具到安全实践，层层递进。
- 实践导向： 提供了仓库结构、分支策略等具体建议。
- 工具覆盖： 提到了主流工具链供读者选择。
- 安全提醒： 特别强调了 Secrets 管理的重要性。