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仓库中的变化管理部署。