Kargo-面向K8s的下一代持续交付和应用生命周期编排平台

本篇文章是「DevOps云学堂」与你共同进步的第 58篇

嗯，大家可能在Kubernetes社区或之前的社区中认识我，我是Kelsey Hightower。自从离开Google之后，以及在那之前一小段时间，我一直在为初创公司提供咨询，其中之一就是Akuity。

Akuity是Argo CD背后的公司，你们可能因为他们的创新方式而熟知他们。他们为部署提供了比Kubernetes更简单对比的思考方式，并将CI（创建构件的过程）和CD（部署过程）区分得更加清晰。他们做的一件非常有趣的事情是，他们确定了扩展Argo CD的方式：增加更多功能，还是在现有的基础上创造出一种新的、专为当前任务而设计的解决方案。为了介绍这个决策，他们决定创造出一些全新的东西。

我们对CI/CD的理解

接下来我要介绍Jesse，他是Acuity的首席技术官，他将介绍Argo，欢迎Jesse上台。谢谢，Kelsey，也非常感谢大家今天的加入。

今天我们在这里介绍一个我们正在开发的全新开源项目，它被称为Kargo。Kargo是一个多阶段的应用编排工具，用于在各个环境中推进变更。我们的目标是在现有的Git工具之上提供更好、更直观的层次，帮助应用程序开发人员安全地推进他们的应用程序通过多个环境。

在介绍Kargo之前，我想先退后一步，解释一下我们开始这个项目的一些动机。首先，让我们谈谈CI/CD。每个人都追求持续部署的理想期望。梦想是每次合并到主分支的PR都会构建一个构件，这些天一般是一个容器镜像，你测试这个镜像，并将其部署到某个目标环境。理念是使用自动化，尤其是你的CI系统，重复这个部署和测试过程，将一个变更通过多个目标环境，直到达到生产环境。大家对这幅图应该都不陌生，但根据我们的经验，大多数组织并没有实现完全自动化的无人值守部署到生产环境，而且大多数情况下也不会达到那个成熟度水平。这需要在你的自动化测试上进行大量投资，并对其充满信任，才能获得如此高的信心水平。

现实情况是，真实的CI/CD流程要复杂得多。首先，你不会允许每个提交都到达生产环境，这太冒险了。相反，你的变更通常被批量处理成一个有效载荷，然后部署到所谓的“预上线环境”。预上线环境是你运行真实测试的地方，也许你会进行一些性能或规模测试，你可能会有一个质量保证团队对其进行测试。然后你进行一个等价的过程，类似烘烤，让应用程序运行一段时间，以便发现一些问题，比如内存泄漏，或者通过一些小规模的有机使用来暴露问题。一旦每个人对这个版本有了信心，你需要获得一些批准，然后你可以将其部署到生产环境。如果你在高级阶段，你可能会进行A/B测试或金丝雀发布，只将部分流量发送到金丝雀环境。一旦完全推出到生产环境，你可能需要进行一些分析和测量，以确保它真正按预期工作，如果有问题，可能需要回滚。因此，现实情况是，持续交付是一个冗长的过程，涉及手动测试、批准和分析，最终你可能每周只部署几次，而不是每个提交都到达主分支。

对于很多人来说，这幅图也解释了为什么他们对他们的构建流程感到沮丧，并不是因为流水线有问题，而是因为表达这种状态机的过渡太复杂了，无论你是否应该进入下一个环境或子环境，如果你试图为大多数人编写这样的脚本，你会发现在你的构建阶段里的确会出现问题。当你放大这个小方框时，你会看到里面有一个Bash脚本，试图协调整个过程。很多人已经意识到，实际上，在构建过程的左侧或右侧，实际上是在进行编排，我们可能更适合采用一种声明性的方法，明确地表达这些个体状态机，以便能够根据需要进行传播。当人们看到这个图时，并不是说你目前的CI/CD系统有问题，而是你缺乏用Bash脚本来表达状态机的工具，没错，我们确实是这样认为的。所以我们考虑的是，人们使用的工具来驱动这个流程，他们可能使用的是Jenkins，或者GitHub Actions，或者其他一些工具来实现CI/CD流水线。但是，这些工具并没有提供一个很好的方式来管理多个环境和状态之间的传递。而我们希望通过Kargo提供一种更好的方式来解决这个问题。

Kargo是我们团队为了解决这个挑战而开发的工具。它基于我们在Argo CD中获得的经验，并结合了一些新的概念和想法。Kargo允许您以声明性的方式定义应用程序的不同阶段和环境，并定义它们之间的传递规则。您可以定义应用程序的不同版本，并在不同的环境中推进这些版本。Kargo还提供了一套命令行工具和API，使您能够管理和操作这些应用程序的不同阶段和环境。它是一个开源项目，我们鼓励社区的参与和贡献。

我们相信，通过使用Kargo，您可以更好地管理和推进应用程序的变更，提高交付的可靠性和效率。我们对Kargo充满期待，并希望它能够为开发人员和运维团队带来价值。这就是我们对Kargo的介绍。如果您有任何问题，请随时提问。

CI Pipelines are not CD Pipelines

这个编排，你的CI系统，比如Jenkins和GitHub Actions，是对的。但我们觉得CI系统正在过度利用，试图完成它们最初并非为之构建的CD工作，更复杂的部署任务。每个人都把CI和CD放在一起讨论，好像它们是同一件事情，但从根本上说，CI和CD的目标是非常不同的。对于CI而言，你的主要目标是根据一些代码构建并生成一个构件，而对于CD而言，你的主要目标是给定一个构件并尽可能安全地进行部署。因此，CI流水线往往是短暂的，它们有一个预定义的开始和结束，我们称之为作业。一旦作业完成，你的流水线就结束了。理想情况下，你的流水线需要快速，因为GitHub按分钟收费，每次运行这些作业都可以并行运行，因为每个构件可以独立地生成。如果你事先知道了所有的情况，那么定义这些自上而下、更加严格的DSL流水线就不是问题。这对于运行短期、可重复的测试（如单元测试和集成测试）非常好。但是，当涉及到CD时，事情就会变得更加复杂。CD过程本身并没有预定义的结束，你的部署在完成时才算完成，因为你应该在持续的基础上评估是否准备好投入生产。很多时候，这只是凭感觉来判断，当你对将其推进到下一个阶段有足够的信心时。而且范围实际上要大得多。现在的CD需要更多的灵活性，因此，如果你正在进行A/B测试，你实际上不知道A是否应该进入生产环境，或者B版本是否更好，你需要在获得一些真实世界的证据之后做出决策。所以，如果你只有一个或两个部署目标，你可能用Jenkins就可以了，但一旦你开始有多个部署目标，如不同的区域，或者需要在一周或两周的时间内进行部署，这时CI的局限性就开始显现出来了。所以，你可能会想，那么Argo CD呢？CD在Argo CD的名字中，为什么它不与CI系统集成呢？

Argo CD是必不可少的，但并不足够。

让我们首先澄清一下Argo CD的作用。Argo CD的主要功能是管理Kubernetes应用程序的声明式状态，并确保期望状态与实际状态一致。每个部署或同步操作（称为"Sync"）都会影响单个目标环境。尽管Argo CD被形容为高级的kubectl apply命令，但它也有很多限制。以下是Argo CD无法完成的任务：

Argo CD无法理解已部署目标的多个部署目标以及它们之间的关系。它没有管道（pipeline）的概念，无法在多个目标环境之间进行编排。
Argo CD甚至无法将更改写回Git。它期望其他工具（人员或机器人）在同步之前完成这项任务。
即使Argo CD能够理解应用程序何时达到健康状态，它也不会在同步后对更新进行任何验证，比如运行一些测试或分析。

为了解决其中的一些特定问题，有一些工具（如镜像更新工具）尝试解决这些问题。但是，并没有一个工具能够将所有功能整合在一起，提供统一的体验。在实践中，我们发现与客户讨论最频繁的问题之一是如何在不同环境之间进行推进（promote）操作。他们可以在我们的平台上快速启动Argo CD，但是接下来的一个月里，他们要花时间编写脚本来实现跨环境的部署。我们向他们提供了一些使用CI系统的指导和示例，但这种方法并不完美。虽然你可以使用Argo CD、Jenkins等工具强制实现这一点，但体验并不理想，我们可以做得更好。

因此，我们希望通过Argo来改善用户体验，并开始了一个新的项目。但是，在你开始使用Argo之前，还有一件事需要考虑，即目标平台的设计和架构。不同的目标平台需要使用不同的工具和方法。例如，在Linux服务器上，目标可能是通过SSH访问shell，而在Docker中，目标可以是Docker API。而在使用Kubernetes时，目标则是一个集群，涉及到多个机器。在Argo CD之前，部署对象（Deployment Object）是主要的目标，但它的功能相对简单，缺乏很多编排功能。

因此，Argo CD在我看来是一种"最后一英里"（Last Mile）技术，在你做出所有决策并完成编排后，告诉Argo CD如何处理单个集群的部署。如果要处理多集群或多阶段的编排，那么就需要考虑使用Argo来实现。Argo CD对于开发人员来说是一个直观的界面，可以在日常工作中使用。

Kargo

Kargo是一个面向Kubernetes的下一代持续交付和应用生命周期编排平台。它基于GitOps原则，并与现有技术（如Argo CD）集成，以简化和自动化在应用程序生命周期的各个阶段逐步推出变更的过程。

Kargo简单演示（阶段 - 自下而上定义流水线）

image.png

这是我们的主要流水线视图。你看到的是一个多阶段部署流水线，包括三个阶段：Dev、Staging和Prod。但是，你首先应该了解的是，Kargo的流水线定义是自下而上的方式。通常情况下，我们会使用阶段（stages）来建模不同的环境，并且它们是相互独立定义的。从下而上的定义方式是因为每个阶段将描述部署所使用的Git仓库和路径。因此，你需要告诉Kargo可以在哪个Git仓库中写入GitOps的更改。每个阶段可能与一个Argo应用程序相关联，这样Kargo就可以持续监视该应用程序的健康状态。这就是这部分的含义。未来，这些阶段将描述需要在每个阶段上运行的资格测试。然后，一旦定义了这些阶段，你需要描述它们之间的关系。阶段之间的关系是通过订阅（subscriptions）来建立的。订阅实际上是告诉Kargo监视其他阶段，如果在上游阶段（Upstream）符合条件，那么它是我可以部署到自己阶段的一项资格。在这个例子中，Prod阶段订阅了Staging阶段，Staging阶段订阅了Dev阶段。希望这能帮助你理解这部分的内容。

Kargo简单演示（Freight - 配置/镜像更改以进行推进）

实际上，Kargo订阅了一个镜像仓库。如果新的镜像被推送到这个镜像仓库，开发人员可以自动或手动从中进行推进。推进的镜像将出现在我们称之为"freight line"的列表中，它是顶部的一个小列表。

那么，什么是"freight line"，实际上它是什么意思呢？"Freight"是指你希望作为一个单位进行推进和部署的一个或多个工件的逻辑集合。在最简单的情况下，它可能只是一个对容器镜像标签的引用，就像在这个示例中一样。但是，"freight"不仅仅指镜像标签，它还可以是一个你希望推进的配置，比如启用某个功能标志的环境变量。稍后我们将会看到，"freight"实际上可以指的不仅仅是镜像标签，它还可以是一个配置，你希望推进的配置，比如启用某个功能标志的环境变量。