Kubernetes DevOps CD 工具对比选型

一、Flux

1.1 安装

Flux 安装和部署其他 Pod 的方式一样，支持 Helm Charts 或 Kustomize 方式的安装。同时 fluxctl 还提供命令行（CLI）工具。

可以通过 fluxctl install 命令添加参数得方式来监视的 Git 仓库的 URL。

1.2 GitOps 部署

Flux 会定期拉取远程 Git 仓库，如果仓库里的文件有新更改，Flux 会以 GitOps 方式将文件更新到目标集群。可以是部署应用程序，或维护 Kubernetes 集群配置等。

除了定期自动方式，也可以通过 fluxctl sync 命令手动触发。

1.3 管理

从 K8S 群集管理的角度来看， Flux 实际上是在 Pod 中部署的单个二进制文件，安装后几乎不需要管理。

可以通过更新 yaml 文件的方式来更改配置或升级到新版本，或使用 Kustomize 或 Helm 进行更改。

除此之外，还可以 fluxctl 命令行工具进行管理，如立即触发同步、或查询并展示集群中部署的相关配置和工作负载。

1.4 多租户

由于 Flux 在架构设计上没考虑远程 Git 仓库和 K8S 命名空间的复杂性， Flux 没有考虑多租户模式。

虽然 Flux 没有多租户模式，但可以由团队来自行管理 Git 仓库，以及如何在 K8S 集群中用命名空间代表的应用程序和目标环境进行关联。为了实现不同团队之间的隔离，可以使用不同的 Git 仓库，以及使用不同的 Flux 实例来监视每一个 Git 仓库。

在使用方式上，可以在同一个 K8S 集群中创建多个 Flux 实例，每一个实例监视不同的 Git 仓库，并同步仓库的更新到不同的 K8S 命名空间中。这种方式需要不同的团队分别管理自己的 Git 仓库。

虽然在集群中运行多个 Flux 实例可能会增加一些管理开销，但它可以让团队管理自己的环境仓库，并拥有适当的权限来提交更改和批准 PR。此外它还可以在命名空间之间实现一定程度的隔离，为集群中不同的 Flux 实例使用的每个服务账户提供更具体的 RBAC 设置。

1.5 多集群

基于多租户的使用方案，Flux 同样可以用于多集群场景：不同的集群会有不同的 Flux 实例来监视 Git 仓库中的变化。

可以在仓库中指定一个要监视的目录，团队可以灵活的选择多集群情况下的最佳 Git 目录结构。一个单一的版本库可以由两个或多个来自不同集群的 Flux 实例来监视，每一个 Flux 实例监视一个特定的目录；也可以使用单独的版本库来实现相应的功能。

1.6 附加功能

1.6.1 自动部署新版本容器镜像

当新版本的容器镜像可用时，Flux 可以选择更新集群中的工作负载。如果需要启用该功能，需要运行 fluxctl automate 或者在工作负载的部署文件中添加注释，它会轮询镜像仓库中的镜像元数据，如果指定镜像有新版本可用，它可以使用新的镜像来更新部署。

当自动部署新版本镜像时，Flux 会写一个提交回原始 Git 仓库，以更新 yaml 文件中使用的镜像版本，因此 Git 仍然会与集群中运行的实例保持一致。

1.6.2 重新应用偏移的资源

不管 Git 仓库有什么新的变化，Flux 都会在一段时间内同步工作负载的状态，并重新应用其清单。当应用程序和配置的状态在 GitOps 工作流外部更改时，这非常有用。

1.6.3 垃圾回收

当资源从环境仓库中被删除时，Flux 可以将其从集群中删除。这种潜在的危险操作需要跟踪 GitOps 工作流程已创建了哪些资源。

当启用此功能后，Flux 将根据源（仓库 URL、分支和安装过程中指定的路径组合），在同步循环期间给集群中部署的所有资源贴上特定的标签。当涉及到垃圾回收循环时，Flux 将查询 APIServer，以检索所有标记为来自源的对象，并删除那些在上一阶段没有同步的对象。

1.6.4 局限性

Flux 最大的局限，可能是设计上的，也是它最大的优势。它只支持一个单一的仓库。这个特性使它成为一个相当简单的工具，易于理解和故障排除。考虑到它运行在轻量级部署上，这个限制可以通过集群中的多个实例来克服，正如前面的“多租户”部分所描述的那样。

二、ArgoCD

ArgoCD 是一个用于 Kubernetes 的、声明性的、基于 GitOps 的持续交付 （CD） 工具。它专注于应用程序部署的管理，具有出色的功能集，涵盖多个同步选项、用户访问控制、状态检查等。它自 2018 年以来由 Intuit 开发，并在 Apache 2.0 许可证下在 Github 上开源。

部署从 ArgoCD 跟踪的 Git 存储库中的应用程序清单的更改开始，类似于 Flux 的工作方式。但是，使它大放异彩的是能够通过精细控制来管理多租户和多群集部署。它可以将不同团队的多个应用程序同步到一个或多个 Kubernetes 集群。此外，它还具有一个很好的现代 Web UI，用户可以在其中查看其应用程序部署的状态，管理员可以管理项目和用户访问权限。

2.1 安装与管理

ArgoCD 完全以 Kubernetes 原生方式安装和管理。它在 Kubernetes 上在自己的命名空间中运行，所有的配置都存储在 ConfigMaps、Secrets 和 Custom Resources 中。这使得我们可以使用 GitOps 工作流程来管理 ArgoCD 本身。

2.2 支持的清单格式

ArgoCD 在 GitOps 仓库中提供了对不同格式的最广泛支持。根据文档，它可以处理：

• · Kustomize 应用程序

• · 2.Helm Charts

• · 3.Ksonnet 应用

• · 4.YAML/JSON 清单目录，包含 Jsonnet

• · 5.配置管理插件配置的任何自定义配置管理工具

2.3 特性

ArgoCD 在多租户等重要功能方面非常出色，同时也提供有众多的自定义选项。

2.3.1 多租户

一个 ArgoCD 实例可以处理不同团队的许多应用程序。它使用项目的概念进行此操作。项目可以容纳多个应用程序，并映射到一个团队。团队成员仅能看到分配给他们的项目，并且通过扩展仅能看到那些项目中的应用程序。这种模式与 Kubernetes 中的命名空间中的资源非常相似。

2.3.2 多集群

ArgoCD 可以在运行它的 Kubernetes 集群上同步应用程序，还可以管理外部集群。可以将其配置为仅有权访问一组受限制的命名空间。

其他群集的 API 服务器的凭证会作为秘密存储在 ArgoCD 的命名空间中。只要你可以远程公开其他集群的 API，这对于从一个地方管理所有部署都是非常有用的功能。内置的 RBAC 机制提供了一些选项，以控制仅特定用户对不同环境中的部署的访问。

2.3.3 配置偏移检测

当集群的操作员在没有通过 GitOps 工作流（即提交到 Git）的情况下更改资源时，Kubernetes 资源可能会和存储在 Git 中的配置不一致。这在 GitOps 中时一个比较棘手和严重的问题：因为很容易进行这些更改并使 Git 存储库中的状态过时。与 Flux 类似，ArgoCD 可以检测到这些更改并恢复它们，从而将状态恢复到 Git 中定义的状态。

2.3.4 垃圾回收

删除资源是 GitOps 的另一个问题。当从 Git 中删除诸如部署之类的资源时，kubectl apply 将忽略它（除非使用实验性的--prune 标志）。这使得开发人员无法删除他们创建的资源，因为它们与 Kubernetes 的接口是 Git 仓库。Helm 确实解决了这个问题，但 ArgoCD 也是如此。它可以在自己的同步过程中删除过时的资源，所以你不必使用 Helm 来实现这个功能。

2.4 局限性

ArgoCD 感觉就像 Flux 的老大哥。它是一个功能丰富的工具，与 Kubernetes 完美集成。它的范围也非常明确：它将清单从 Git 存储库同步到集群。

基本上团队所属项目的整个配置都保存在存储 ArgoCD 配置的 Git 仓库中的文件中。这意味着，每次创建或修改新团队时，都必须更新此文件。在大公司里，开发团队的组建和解散都是在不断地进行，这种管理方式可能会变得很繁琐，也限制了 ArgoCD 提供的多租户设置。

三、Jenkins X

Jenkins X 是一个围绕 GitOps 构建的完整的 CI/CD 解决方案，其底层使用了 Tekton。首先，从名称来看，我们希望看到大家都了解到的 Jenkins 的下一代，包含其任务和插件功能。实际上，Jenkins X 采取了不同的方向，与经典的 Jenkins 几乎没有共同点。

它抛开了 Jenkins 的 master-worker 节点架构，并以成为 Kubernetes 原生 CI/CD 引擎打造。它在 GitHub 上以 Apache 2.0 许可下开源，由 Cloudbees 开发，该公司还提供了商业发行版。

值得注意的是，除了基于 GitOps 的部署功能外，Jenkins X 还涵盖了更广泛的开发周期，包括来自典型 CI 流水线的构建和测试阶段，以及容器镜像的构建和存储。为此，它将一组令人印象深刻的云原生项目捆绑并配置在一起，从而实现了现代化的开发工作流程。

Jenkins X 将设置 Skaffold 和 Kaniko 来构建容器图像，并使用 Helm 图表来打包 Kubernetes 清单。在内部，它使用 Tekton 运行流水线，并使用 Lighthouse 与你选择的 Git 提供程序集成（例如 GitHub），并在 PR 线程中启用丰富的交互。

4.1 安装

安装必须使用 jx boot 命令完成，并且它假定用户具有对 Kubernetes 群集的广泛权限，足以创建名称空间，CRD，设置 sa 以及创建 GCP 资源（如 Cloud Storage buckets）。

在这个过程的开始，将克隆启动配置库，并提示用户接受或更改一些默认选项，并提供 GitHub 用户的凭据，这些凭据将在 PR 线程中用作机器人的 GitHub 用户的凭据。

默认情况下，在 GitHub 中提供了三个 Git 仓库，以保持集群中环境的状态：dev、staging 和 production。dev 环境（从引导配置仓库中克隆出来的）是工具运行的地方。staging 环境和 production 环境是用户应用程序部署时运行的环境。每个环境在集群中都有自己的命名空间和 Git 仓库。

4.2 GitOps 部署

如果应用仓库中合并到 master 后成功构建了应用程序，则会创建应用程序 Helm chart 的新发布版本。要在其中一个环境中部署此新版本，需要更新相应的 GitOps 存储库。例如，要部署到生产环境中，需要更新代表生产环境的 Git 仓库。

遵循 GitOps 原则，环境仓库中的这种变化会触发 Tekton 的部署流水线，使用 Tekton 将仓库中描述的内容与集群中正在运行的内容同步。部署过程也可以通过 jx promote 命令启动，该命令将更新环境仓库，从而触发同步。

4.4 管理

安装完成后，可以通过更新 dev 环境仓库中的配置文件来调整某些内部配置。当更改提交并推送后，会触发一个流水线，Jenkins X 会在其中读取配置并自行更新。此外，Jenkins X 本身就是由 GitOps 工作流来管理的。

4.5 多租户

考虑到 Jenkins X 集群中来自不同团队的应用程序之间没有特别的隔离，因此不支持多租户。用户和应用程序都将共享相同的内部资源和组件，以及同一套环境。尽管存在团队的概念，并由 jx team 子命令支持，但这是一个半生不熟的解决方案，基本上是复制粘贴整个 Jenkins X 的部署。

4.6 多集群

应用程序环境（例如 staging 和 production）可以在其他集群中运行。这是 Jenkins X 中的一个新功能，被忽视了太久了。这种忽视的后果是，现在有不同的解决方案，有不同的弊端，看来我们还得再等一段时间才能找到最终的解决方案。

4.6.1 功能特性 Features

Jenkins X 自带了大量独特的功能，使得开发者的体验比其他两个工具更加流畅和完善。

4.6.2 快速入门新项目

对于新项目，jx quickstart 命令可以帮助创建一个新的 Git 仓库，其中包含带有 Helm chart 的应用程序框架，以及使用 Skaffold 构建 Docker 镜像的预定义构建流水线。它还在 GitHub 中配置了 Git 仓库，在分支中的新提交和 PR 之后设置了一个 Webhook 来触发构建和其他操作。可以使用 jx import 命令配置现有项目，这将有助于创建 Dockerfile 和 Helm chart（如果不存在），并设置适当的 webhooks。

4.6.3 配置 Git 仓库

使用提供的 GitHub 用户凭据，在安装过程中，将在选定组织的 GitHub 中创建环境仓库（dev，staging 和 production），或作为用户仓库创建。同样，对于上面提到的新的快速入门项目，也会提供一个 Git 仓库与应用框架。

4.6.4 构建流水线

Jenkins X 支持在应用程序仓库中发生事件后触发任务流水线。例如，为新的分支或拉取请求，构建应用程序并运行测试。在所谓的构建包（buildpacks）中有针对不同编程语言和框架的默认构建流水线。应用程序需有一个指向其父构建包的 jenkins-x.yaml 文件，并且可以自定义流水线。

4.6.5 ChatOps

ChatOps 是用于在聊天线程中管理开发和操作活动的术语，通常在机器人用户的支持下执行一些自动或请求的操作。在 Jenkins X 中，在应用程序或环境仓库中创建的新 PR 将触发运行流水线。流水线步骤的结果由 bot（安装过程中配置的 GitHub 用户）发布到 PR 线程中。用户可以与机器人进行交互，以请求其他任务，例如重新运行测试，或批准并合并 PR。

为了集成 Webhook，触发器和事件，Jenkins X 在内部使用 Prow，该工具最初是为 GitHub 中的 Kubernetes 项目运行构建的。另外，Jenkins X 团队正在开发 Lighthouse，以提供类似的功能，扩展对不同的 Git 发行版（如 BitBucket 和 GitLab）的支持。

4.6.6 预览环境

成功构建后，例如在 Jenkins X 配置的应用程序仓库中新创建的 PR 中，将为当前构建创建临时预览部署。通过此预览，可以手动检查作为 PR 提交的当前更改（例如，在浏览器中打开 Web API 应用程序），然后再将其合并到 master。

4.7 局限性

虽然其他两个工具的范围比 Jenkins X 要小得多，但它们能完美地实现它们所说的功能。另一方面，Jenkins X 是一个复杂的全方位解决方案，这就给人们设定了不同的期望。最显著的缺失的功能是多租户功能。当 Jenkins X 被安装到一个集群上时，我们会期望它能够服务于所有团队。遗憾的是，Jenkins X 的多租户模式可以与 Flux 的多租户模式进行比较，虽然后者是一个简单的工具，但 Jenkins X 安装了大量的组件，管理员应该不想为每个团队重复安装这些组件。

六、方案比较

Flux 是一个小型、轻量级的组件，可以实现基于 GitOps 的部署，可能会对你当前的设置进行互补。它只需要访问一个（也只有一个）Git 仓库，并且可以在有限的 RBAC 权限下运行。

ArgoCD 可以管理不同集群中多个应用程序的部署。它在集群内运行，但也可以管理团队和项目的访问权限和权限。它有一个流畅的 Web 界面来管理应用程序和项目，并提供了一套不错的功能来管理部署。

Jenkins X 捆绑了一些有争议的工具，来构建一个围绕 GitHub 仓库的开发工作流（很快就会支持其他供应商）。它运行 CI 流水线来构建和运行应用程序的测试，在 PR 中提供丰富的交互，并根据 Git 仓库中的变化管理部署。