Kubernetes DevOps CD工具对比选型

2022-06-24

545

作者:行云创新 何小云


一、Flux

Kubernetes DevOps CD工具对比选型


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,用户可以在其中查看其应用程序部署的状态,管理员可以管理项目和用户访问权限。


Kubernetes DevOps CD工具对比选型


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

技术交流
我们建立了多个云原生技术交流群,其中有来自Oracle、Citrix、华为、腾讯等国内外云计算专家,立即扫码,拉你进群。目前已有2000+开发者加入我们......
云原生厂商 云原生技术服务商
在云原生时代,行云创新致力于通过赋能开发者,实现企业快速迭代与交付,大幅提升创新效率。
产品下载