翻译自 GitOps as an Evolution of Kubernetes 。

Kubernetes 的联合创始人 Brendan Burns 在 GitOpsCon 上分享了他对 GitOps 和 Kubernetes 的看法。

不列颠哥伦比亚省温哥华——很多人都在谈论 GitOps 和 Kubernetes，但是当微软公司副总裁、微软 Azure 杰出工程师、Kubernetes联合创始人布伦丹·Burns （Brendan Burns）说话时，我会认真倾听。Burns 在 Linux 基金会的 GitOpsCon 上谈到了 GitOps 如何成为 Kubernetes 的进化步骤。

如何？Burns 首先解释了它如何深深植根于持续集成、部署和交付的开发。真正促使他帮助创建 Kubernetes 的是，“当我们刚开始时，我们试图将可靠的部署放在一起。他们使用当时的DevOps工具，混合了 Puppet，Chef，Salt 和 Ansible （显然还有 Bash ），它大约在 85% 的时间内工作。然后你会按摩它，它最终会在 95% 的时间内起作用： 然而，这段旅程往往充满了困难和不确定性，这催生了 Kubernetes 的想法。

Kubernetes 的诞生本质上是对部署过程的艰巨性和不可靠性的回应。这是 DevOps 挑战和 Docker 在容器革命中取得的创新进步的融合。Docker 专注于密封和封装应用程序，这是重新构想如何执行部署的重要先决条件。在过去的十年中，这种方法已转变为科技界的标准运作方式。

但是，随着 GitOps 的出现，科技界已经迈出了更进一步的一步。它不再旨在重新定义部署过程本身。它不仅仅是关于引导 Kubernetes 进行的部署，而是整个过程 —— 从获取配置到将它们部署到 Kubernetes 可以利用它们的环境中。

GitHub 及其声明性配置现在在确保可靠交付方面发挥着关键作用，并为社区的持续发展做出了贡献。“虽然它现在被普遍接受，” Burns 说，“但这个想法在当时是一个有争议的话题。脚本编写猖獗。值得注意的是，CI/CD 管道，即使在 YAML 中描述，也是命令式程序执行。 Burns 认为 GitOps 具有固有的声明性，是对 Kubernetes 生态系统的可喜强化。

此外，授权人们做更多的事情是我们最初思考过程的另一个中心主题。目标是减轻每天困扰开发人员的负担。从本质上讲，这是社区的旅程 — 从植根于部署和持续交付的最初阶段到今天 GitOps 占主导地位，提供了一种更可靠、声明性和用户授权的方法来管理部署。

它以多种方式实现：

• 关注点分离：使用 Kubernetes 和 GitOps，团队可以划分，专注于特定的任务和职责。这种清晰的描述有助于避免混淆，提高效率，并明确一个团队的职责在哪里结束，另一个团队的责任在哪里开始。
• 多角色：在现代软件开发中，涉及许多角色，例如开发人员、平台工程师和安全团队。每个人都有特定的角色和职责，都需要在同一环境中协同工作。
• GitOps 作为一种解决方案， GitOps 可以帮助管理这个复杂的环境。它允许每个人通过管理 Git 仓库来管理环境，而无需直接与集群进行交互。这可以减少由于一个团队过多掌控而带来的风险，并且可以更容易地促使团队协同工作。它基本上实现了劳动分工的清晰划分，减少了重叠或冲突的风险。
• 自动更新：GitOps 还可以促进自动更新。 Dependabot 等工具可以监控存储库并在必要时提出更新建议。此过程减少了保持最新状态所需的时间和精力，提高了效率并降低了在重要更新上落后的风险。
• 安全性和合规性：GitOps 还支持更好的安全性和合规性。通过管理良好的 Git 存储库，它可以确保每个更改都得到跟踪和审核，这对于满足合规性要求非常重要。

GitOps 工作流及其在平台工程和开发人员之间的交集对于不想被将代码部署到 Kubernetes 的复杂性所困扰的程序员来说尤其重要。无论他们喜欢哪种编程语言——无论是 Java、Python、Dotnet、Rust 还是 Go —— 他们只想推送代码，生成容器镜像，并立即部署。GitOps 使他们能够做到这一点。

Burns 继续说，GitOps的美妙之处在于它的可伸缩性。开发人员不必过分关注其组织中的集群数量或其特定位置。从管道推送模型到 GitOps 拉取模型的转变允许一个抽象级别，其中集群的数量变得有些无关紧要。开发人员只需要处理 Git 存储库。如果出现新集群或旧集群消失，开发人员甚至可能不会注意到。

即使在应用程序生命周期中从早期预生产过渡到暂存再到生产时，工作流的一致性也保持不变。这减少了开发人员的认知负担，使他们能够更专注于他们的代码，而不是部署后的内容。

因此，在 GitOps 中，Git 存储库成为最终的事实来源，平台工程团队可以专注于初始化该 Git 存储库，从而使开发人员能够有效地部署他们的代码。

Burns 还提醒我们，从历史上看，“雪花”（一次性的独特服务器如果“融化”就无法重建）的概念是一个令人担忧的原因。诚然，容器和业务流程在单个容器级别消除了这个问题。然而，我们现在面临着“雪花集群”的问题 —— 内部统一但与其他机器不同的机器集群。

Burns 说，GitOps 为这个问题提供了一个强大的解决方案。从推送模型到拉取模型的转变使得 GitOps 对集群的规模或数量相对漠不关心。每个群集都配置为指向同一个 Git 存储库。当您将 Git 存储库初始化作为创建集群的一部分时，它会自动创建使用正确的软件版本初始化的集群。

因此，此过程可确保整个平台的一致性。例如，它还消除了忘记在部署新版本安全软件的管道中包含集群或必须通知开发团队有关区域更改的机会。这种一致性和可靠性是 GitOps 的主要优势之一。

有趣的是，GitOps 的应用并不局限于 Kubernetes，而是通过服务运营商扩展到公共云资源。用户正在利用 Kubernetes 控制平面来管理容器化资源和 Postgres 数据库或 blob 存储系统的实例。GitOps 可以管理群集中的资源以及云中的资源，从而扩大其范围和效用。

然而，GitOps 并不是万能的解决方案。CI/CD 流水线和 GitOps 都有各自的用武之地。“这不是一场争斗，而是两种非常互补的技术，一种非常擅长轻松地实现状态的真实性，另一种非常擅长编排你希望世界看起来像什么的各个阶段。”

与 Burns 在进入软件之前从事的机器人技术相提并论，控制和计划之间不断切换，人们可以理解传统 CI/CD 管道系统和 GitOps 之间的关系。GitOps 就像一个控制器，可以快速实现状态，但对于需要缓慢、渐进部署的全球规模的软件部署来说，它并不理想。这就是传统的 CI/CD 系统或“规划者”发挥作用的地方。

因此，Burns 总结道，CI/CD 管道和 GitOps 各有优势 —— GitOps 可以轻松地将特定状态变为现实，而传统的 CI 系统则在编排世界应该是什么样子的阶段。了解 GitOps 在容器上下文中的价值及其与传统 CI 系统的相互作用可以显著提高效率和生产力。当然，所有这些都将在 Kubernetes 编排的世界中运行良好。