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
