FluxCD、ArgoCD还是Jenkins X：哪个是适合你的GitOps工具？

type

status

date

slug

summary

前言

如果你已经了解了GitOps是什么，并且不想阅读每个工具的长篇描述，你可以跳到最后直接阅读结论部分！

GitOps的简要介绍

这个术语是由Weaveworks公司的Alexis Richardson在一篇名为“通过拉取请求进行运维”的博客文章中提出的。其基本思想是通过向Git提交更改并通过拉取请求进行批准来单独管理Kubernetes上的资源。

如果这听起来有点模糊，让我们定义GitOps的这四条规则，以使其更具体：

将所有Kubernetes资源配置存储在Git中。

仅使用拉取请求来修改Git仓库中的资源。

一旦Git被修改，立即并完全自动地将更改应用到集群中。

如果实际状态偏离期望状态，则要么纠正它，要么向操作人员发出警报。

当我们将这些规则结合起来时，我们得到一个系统，其中应用程序环境的所有更改都被记录下来，我们可以应用基于Git的工具来管理历史记录。我们还可以通过使用拉取请求来进行批准流程。

从架构上讲，GitOps将允许我们将应用程序的持续集成（CI）流程与部署过程分开，因为部署过程将根据对GitOps存储库的更改而启动，而不是作为CI过程的一部分。（关于GitOps和CI/CD的更多信息，请参阅此处。）

FluxCD

Flux被描述为用于Kubernetes的GitOps操作器，它将Git存储库中清单的状态与集群中正在运行的内容同步。在这次评估中的三个工具中，它是迄今为止最简单的一个。事实上，仅需几个步骤就可以设置一个GitOps工作流程，这实在令人惊讶。

该工具在集群中运行，更新将应用于该集群，并且其主要功能是监视远程Git存储库以应用Kubernetes清单中的更改。它最初由Weaveworks开发，现在是一个在GitHub上以Apache 2.0许可证发布的Cloud Native Computing Foundation项目。

专注于软件交付周期的部署部分，特别是在将Git存储库和容器注册表与集群中工作负载的版本和状态进行同步方面，该工具易于安装和维护。

它可以监视每次安装的一个单独的远程存储库，并且只能在其基础服务帐户具有更改权限的命名空间中应用更改。虽然乍一看似乎受到限制，但更多具有多个团队、各自拥有Git存储库和目标部署环境的复杂场景都可以通过相应数量的Flux实例进行设置，每个实例都具有自己特定的RBAC权限

安装

Flux的安装就像在集群中部署任何其他典型的Pod一样简单。它官方支持基于Helm Charts和Kustomize的安装方式。还有一个名为fluxctl的命令行界面（CLI）工具，发布为二进制文件，用于协助安装过程并与集群中正在运行的Flux守护程序进行交互以执行一些管理任务。

在集群中安装Flux的最简单方法是应用一小组清单，可以使用fluxctl install命令生成，其中包括将被监视的Git存储库的URL等适当的参数。

GitOps部署

作为Flux的主要功能，它定期从远程Git存储库中拉取并将其清单文件应用到集群中，以真正的GitOps方式。这可用于部署应用程序，也可用于维护以Kubernetes清单形式存在的任何类型的集群配置。也可以使用fluxctl sync命令手动触发同步。

管理

考虑到Flux实际上是一个部署在Pod中的单个二进制文件，从集群管理员的角度来看，在安装后几乎没有什么需要管理的。可以通过重新应用具有新值的相同清单或仅使用Kustomize或Helm进行更改配置或升级到新版本。

除了安装外，fluxctl CLI还可以帮助完成一些其他任务，例如立即触发同步或列出集群中部署的相关配置和工作负载。

多租户

由于对远程Git存储库和目标命名空间的结构几乎没有任何假设，因此Flux没有多租户模式。

作为一个简单的组件，它会监视存储库并应用其更改，因此在同一集群中使用不同的Flux实例非常简单，每个实例都可以监视不同的远程Git存储库，并在不同的目标命名空间中同步它们的更改。这种可能性将允许各个团队拥有自己的Git存储库。

总的来说，应该由团队选择存储库的布局以及如何将应用程序映射到集群中的命名空间中。为了在团队之间提供隔离，可以使用不同的存储库，因此每个存储库都可以使用不同的Flux实例进行监视。

虽然在集群中运行多个Flux pod可能会增加一些管理开销，但它将允许团队管理自己的环境存储库，并具有适当的权限提交更改和批准拉取请求。此外，它还将为不同的命名空间启用一定程度的隔离，为集群中不同的Flux实例使用的每个服务帐户提供更具体的RBAC设置。

多集群

出于相同的原因——简单性——Flux可以在多集群场景中使用。不同的集群将具有各自监视远程存储库更改的Flux实例。鉴于可以指定要监视的存储库中的目录，团队可以灵活选择最适合多集群情况的存储库布局。一个单一的存储库可以由来自不同集群的两个或更多Flux实例监视，每个实例监视一个特定的目录，或者可以使用不同的存储库。

其他功能

自动部署新版本的容器映像当工作负载的新版本容器映像可用时，Flux可以选择更新集群中的工作负载。如果启用了此功能，可以通过运行fluxctl automate或在工作负载的部署清单中添加注释来轮询注册表以获取映像元数据，如果使用的映像有新版本可用，则可以使用新版本更新部署。在执行此操作时，Flux将向原始Git存储库写入提交，以更新集群中运行的清单中使用的映像版本，因此Git仍然是集群中运行内容的真实来源。

重新应用偏离的资源

无论来自Git存储库的新更改如何，Flux都会在一定时间间隔内重新应用其清单，以同步工作负载的状态。当应用程序和配置的状态从GitOps工作流程之外发生更改时，这是非常有用的。

垃圾收集

当资源从环境存储库中删除时，Flux可以从集群中删除它们。此潜在危险操作需要跟踪哪些资源是由GitOps工作流程创建的。

启用此功能时，Flux将根据源（在安装过程中指定的存储库URL、分支和路径的组合）给予同步循环期间在集群中部署的所有对象特定的标签。在执行垃圾收集循环时，Flux将查询API服务器以检索所有标记为源的对象，并删除上一阶段未同步的对象。

限制

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

总结：我应该使用FluxCD吗？

Flux专注于将清单部署到集群中，因此您仍然需要使用CI工具来构建和测试应用程序，并最终将容器映像推送到注册表。另一方面，由于Flux周期性地从内部拉取更改，CI工具无需访问集群，从而最大程度地减少了集群的暴露。从团队组织的角度来看，没有内置的多租户支持。如果将使用单个Flux守护程序，则团队应同意如何组织单个Git存储库。因此，如果您正在寻找一种使用简单且轻量级工具自动化Kubernetes部署的解决方案，Flux是一个很好的选择。

ArgoCD

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

部署从由ArgoCD跟踪的Git存储库中应用程序清单的更改开始，与Flux的工作方式类似。然而，它的闪光点在于能够以精细的控制管理多租户和多集群部署。它可以将不同团队的多个应用程序同步到一个或多个Kubernetes集群中。此外，它还具有一个现代化的Web界面，用户可以在其中查看其应用程序部署的状态，管理员可以管理项目和用户访问权限。

安装和管理

ArgoCD 完全以原生的 Kubernetes 方式进行安装和管理。它在自己的命名空间中运行于 Kubernetes 之上,所有配置都存储在 ConfigMap、Secret 和自定义资源中。这使得使用 GitOps 工作流来管理 ArgoCD 本身成为可能。

支持的清单格式

在支持不同格式的 GitOps 存储库方面,ArgoCD 表现出色。根据文档,它可以处理:

Kustomize 应用

Helm 模板

Ksonnet 应用

YAML/JSON 清单目录,包括 Jsonnet

任何作为配置管理插件配置的自定义配置管理工具

功能特性

ArgoCD 在重要功能如多租户支持方面表现出色,但同时也提供了大量自定义选项。

多租户

单个 ArgoCD 实例可以处理不同团队的多个应用。它使用 Project 的概念实现这一点。Project 可以包含多个应用,并映射到一个团队。团队成员只能看到分配给他们的 Project,从而只能看到这些 Project 中的应用。这个模型与 Kubernetes 中的命名空间资源管理非常相似。

多集群

ArgoCD 不仅可以同步运行它自己的 Kubernetes 集群上的应用,还可以管理外部集群。它可以配置为只能访问一组受限的命名空间。

其他集群的 API 服务器凭证将存储为 ArgoCD 命名空间中的 Secret。只要你愿意远程暴露其他集群的 API,这个功能就非常有用,可以让你从一个中心位置管理所有部署。内置的 RBAC 机制提供了控制对不同环境部署访问权限的选项,只允许特定用户访问。

配置偏差检测

当集群操作员未通过 GitOps 工作流(即未提交到 Git)而直接更改资源时,Kubernetes 资源会偏离存储在 Git 中的配置。这在 GitOps 中是一个问题,因为很容易做出这些更改,使 Git 存储库中的状态过期。与 Flux 类似,ArgoCD 可以检测这些更改并将其还原,使状态回到 Git 中定义的状态。

垃圾收集

删除资源是 GitOps 的另一个问题。当 Git 中删除了一个资源(如 Deployment)时,kubectl apply 会忽略它(除非使用实验性的 --prune 标志)。这使得开发人员无法删除他们创建的资源,因为他们与 Kubernetes 的接口是 Git 存储库。Helm 解决了这个问题,ArgoCD 也是如此。它可以在同步过程中删除过时的资源,因此您不必仅为此功能而使用 Helm。

总结:我应该使用 ArgoCD 吗?

ArgoCD 感觉就像是 Flux 的大哥。它是一个功能丰富的工具,与 Kubernetes 集成无缝。我们非常喜欢它虽然功能很多,但范围很明确:从 Git 存储库同步清单到集群。

与 Flux 一样,ArgoCD 不会帮助您测试应用或构建 Docker 镜像。您可以继续使用现有的 CI 工具。但是,如果您想要部署到其他目标集群,ArgoCD 将需要访问外部集群。

在任何较大的公司中,多租户功能都可能非常方便。如果没有这个功能,您将不得不以某种形式自行实现它,所以 ArgoCD 对此的一流支持是非常受欢迎的。如果您想要管理来自多个应用的部署,并对用户访问和清单同步设置进行精细控制,ArgoCD 似乎是一个不错的选择。

Jenkins X

Jenkins X是一个围绕GitOps构建的完整CI/CD解决方案，底层使用了Tekton。从名称上看，我们可能会期望看到我们所熟悉的Jenkins的下一个版本，以及其作业和插件。事实上，Jenkins X走了不同的方向，与经典的Jenkins几乎没有什么共同之处。

它放弃了Jenkins的主节点-工作节点架构，构建为一个原生于Kubernetes的CI/CD引擎。它在Github上以Apache 2.0许可证开源，由Cloudbees开发，后者还提供商业发行版。

需要注意的是，除了基于GitOps的部署能力之外，Jenkins X还涵盖了开发周期的更广泛范围，包括典型CI流水线中的构建和测试阶段，以及构建和存储容器映像。为了实现这一点，它捆绑和配置了一套令人印象深刻的云原生项目，实现了现代化的开发工作流。

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

安装

Jenkins X的安装必须通过jx boot命令完成,并且需要对Kubernetes集群拥有广泛的权限,足以创建命名空间、CRD、设置服务账户以及创建GCP资源(如Cloud Storage bucket)。

在安装过程开始时,boot配置存储库将被克隆,系统会提示用户接受(或更改)一些默认选项,并提供GitHub用户的凭据,该用户将用作拉取请求线程中的机器人。

默认情况下,GitHub中将提供三个Git存储库来保存集群中环境的状态:dev、staging和production。dev环境(从boot配置存储库克隆)是工具运行的位置。staging和production是用户应用程序部署时运行的环境。每个环境在集群中用一个单独的命名空间表示,并拥有自己的Git存储库。

在我们评估Jenkins X的过程中,有一个正在进行的讨论,旨在使boot安装过程能够使用Helm 3和helmfile。

GitOps部署

在应用程序存储库合并到master分支并成功构建后,将为应用程序的Helm chart创建一个新的release版本。要将此新版本部署到某个环境中,需要更新相应的GitOps存储库。例如,要部署到production环境,需要更新表示production环境的Git存储库。

遵循GitOps原则,环境存储库的此类更改将触发使用Tekton的部署流水线,以同步存储库中描述的内容与集群中运行的内容。也可以通过jx promote命令发起部署过程,该命令将更新环境存储库,从而触发同步。

管理

安装后,可以通过更新dev环境存储库中的配置文件来调整一些内部配置。当更改提交并push后,将触发一个流水线,Jenkins X将读取配置并自行更新。因此,Jenkins X本身就是通过GitOps工作流进行管理的。

多租户

考虑到Jenkins X集群中不同团队的应用程序之间没有特定的隔离,所以不支持多租户。用户和应用程序都将共享相同的内部资源和组件,以及相同的一组环境。虽然有团队的概念,并由jx team子命令支持,但这只是一个半生不熟的解决方案,基本上是重复复制整个Jenkins X部署。

多集群

应用程序环境(如staging和production)可以运行在其他集群中(在文档中有描述)。这是Jenkins X的一个新功能,被忽视了太久。这种忽视的结果是,现在有不同的解决方案存在各种缺陷,看起来我们需要再等待一段时间才能获得最终的认可解决方案。

功能

Jenkins X带来了大量独特的功能,使开发人员体验比其他两种工具更加顺畅完整。

新项目快速启动

对于新项目,jx quickstart命令可帮助创建一个新的Git存储库,其中包含应用程序框架、Helm chart,以及使用Skaffold构建Docker镜像的预定义构建管道。它还会在GitHub中提供该存储库,并设置webhook以在分支和拉取请求的新提交时触发构建和其他操作。现有项目可以使用jx import命令进行设置,它将帮助创建Dockerfile和Helm chart(如果尚未存在),并设置适当的webhook。

Git存储库的提供

使用提供的GitHub用户凭证,在安装期间,环境存储库(dev、staging和production)将在所选组织或作为用户存储库中的GitHub中创建。此外,如上所述的新quickstart项目,也会为应用程序框架提供一个存储库。

构建流水线

Jenkins X支持在应用程序存储库的事件后触发任务流水线。例如,为新分支或拉取请求构建应用程序并运行测试。针对不同编程语言和框架,有默认的构建流水线,称为构建包。应用程序应该有一个jenkins-x.yaml文件指向其父构建包,流水线可以进行定制。

ChatOps

ChatOps是指在聊天线程中管理开发和运维活动的术语,通常有机器人用户的支持来执行一些自动或请求的操作。在Jenkins X中,在应用程序或环境存储库中新建的拉取请求(PR)将触发流水线运行。由安装期间配置的GitHub用户充当机器人,将流水线步骤的结果发布到PR线程。用户可以与机器人交互,请求额外的任务,如重新运行测试或批准并合并PR。

为了集成webhook、触发器和事件,Jenkins X在内部使用最初为Kubernetes项目在GitHub上运行构建而开发的Prow。或者,Jenkins X团队正在开发Lighthouse,以提供类似的功能,但扩展了对BitBucket和GitLab等不同Git提供商的支持。

预览环境

构建成功后(例如在Jenkins X配置的应用程序存储库中新建的PR中),将为当前构建创建临时预览部署。通过此预览,可以在合并到master之前手动检查提交为PR的当前更改——例如,在浏览器中打开Web API应用程序。

限制

虽然其他两种工具的范围远远小于Jenkins X,但它们在声称要做的事情上表现完美。另一方面,Jenkins X是一个复杂的全方位解决方案,它设置了不同的期望值。最显著的缺失功能是多租户支持。当Jenkins X安装在集群上时,我们希望它能够为所有团队服务。不幸的是,Jenkins X的多租户模型最多可以与Flux的相媲美,但后者是一个用于简单工作的简单工具,而Jenkins X则安装了大量组件,我当然不希望为每个团队重复安装。

总结:我应该使用Jenkins X吗?

Jenkins X是一个雄心勃勃的项目,覆盖了应用程序开发的广泛范围,将CI和CD集成在一个包中。这是开箱即用的重大能力,使额外的CI工具变得不必要。但是,现有项目可能需要适应新的工具链,以利用在向分支和拉取请求推送后触发的任务(构建、测试和其他作业)。

该项目正在活跃开发中,令人印象深刻的是事物正在如此迅速地发展。我们很高兴看到jx CLI可用性的改进、Web UI中更好的状态和项目概览,以及在如此短的时间内添加了新功能。另一方面,考虑到广泛的功能范围,理解所有概念并熟悉内部组件(以防需要调整某些默认选项)可能需要一些时间。

如果您希望基于Git获得现代化的开发和部署工作流,在拉取请求中拥有丰富的ChatOps交互,就像Kubernetes和GitHub上的其他开源项目一样,而无需自己组装整套独立工具和配置,那么Jenkins X绝对是一个很好的选择。在云原生领域,非常需要这种uber工具,因为并非每家公司都有时间和资源从众多不同工具中进行 IKEA组装。

采用Jenkins X的最大挑战在于,很难判断它是完美解决了公司所有CI/CD需求的解决方案,还是一个过于复杂的庞然大物,虽然一开始可以带来一些快速胜利,但从长远来看可能会成为障碍。摆脱这种困境的唯一方法是Jenkins X功能齐全,任何公司在采用时都知道它将是未来的正确工具。请参阅"限制"部分,了解为什么目前可能还不是这种情况。

总结来说,Flux、ArgoCD 和 Jenkins X 这三个项目都有非常有趣和强大的能力来管理 Kubernetes 中的部署,但每一个都有自己的优缺点,需要根据您的具体情况进行评估。这些工具并不是在相互竞争,而是旨在满足不同的使用场景。

Flux 是一个小巧轻量级的组件,可实现基于 GitOps 的部署,可能会很好地补充您当前的设置。它只需要访问一个(而且只有一个)Git 存储库,并且可以在有限的 RBAC 权限下运行。

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

Jenkins X 则将一系列工具捆绑在一起,为基于 GitHub(其他提供商将很快得到支持)存储库的开发工作流程提供了一种固执己见的选择,就像您在现代开源项目中所期望的那样。它运行 CI 流水线来构建和测试应用程序,在拉取请求中提供丰富的交互,并基于 Git 存储库中的更改来管理部署。

所有三个项目都有自己的优势和适用场景。Flux 适合于轻量级的 GitOps 部署;ArgoCD 提供了更全面的功能来管理多个应用和集群;而 Jenkins X 则为现代化应用开发提供了一体化的工作流解决方案。根据您的具体需求,选择最适合的工具。它们并非互相竞争,而是能够形成互补。