GitOps 核心思想 - 当 Git 成为唯一信源

GitOps 核心思想 - 当 Git 成为唯一信源

在我们之前的 CI/CD 系列中，我们构建了一条流水线：GitHub Actions 在代码测试和构建通过后，执行 kubectl apply 命令将变更推送 (Push) 到 Kubernetes 集群。这种模式非常普遍且有效，但当系统规模和团队复杂度增加时，它可能会遇到一些挑战：

• 权限难题: CI/CD 系统需要拥有对多个 Kubernetes 集群的写入权限，这使得 CI/CD 系统本身成了一个巨大的安全攻击面和权限管理的复杂点。
• 状态不一致: 如果有人（或系统）绕过 CI/CD 流水线，直接使用 kubectl 手动修改了集群中的配置，那么集群的实际状态就与我们期望的状态（定义在 CI/CD 流程中的状态）产生了漂移 (Drift)，而我们可能对此一无所知。
• 可追溯性与审计困难: 很难从集群本身直接反查出某个资源的当前状态是由哪一次部署、哪个代码提交造成的。

为了解决这些问题，一种以 Git 为中心的、更为严格和声明式的实践范式——GitOps——应运而生。

什么是 GitOps？

GitOps 是一种现代化的、用于实现云原生应用持续交付的运维模式。它的核心思想是：将 Git 仓库作为定义基础设施和应用程序期望状态的唯一、可信的来源 (Single Source of Tru