前 言
当前微服务和云原生应用解决方案日趋成熟， 应用架构的细分和服务间的解耦使得服务有了独立发布的能力，容器化与Kubernetes也已成为微服务应用部署的标准方式。由此带来构建部署的频率提升对CI/CD工具的并发性能、扩容能力以及稳定性带来新的挑战。在云原生时代下，传统的CI/CD工具的缺点越来越明显，基于Kubernetes 能力打造新的云原生CI/CD平台逐渐成为主流。
例如Jenkins 作为老牌流水线框架被大家所悉知，它依靠庞大的插件生态，占据了目前大部分的企业级 CI/CD 引擎的份额。但在云原生时代，Jenkins 也暴露出很多的问题，Master单点故障、磁盘存储、内存占用、并行构建性能等。因此Jenkins 也推出了 Jenkins X 作为基于 Kubernetes 的新一代流水线引擎。同时还有像Tekton、Argo CD等较为流行的基于 Kubernetes 原生的CI/CD工具。
下面我们就来对Tekton、Jenkins X、Argo CD等主流云原生CI/CD工具进行对比。在具体比较之前，让我们先了解一些基础内容。
什么是Tekton?
Tekton 是一个基于 Kubernetes 的云原生 CI/CD 开源框架，属于 CD 基金会的项目之一。Tekton 通过定义 CRD 的方式，让用户以灵活的自定义流水线以满足自身 CI/CD 需求。
Tekton架构
Tekton 引入了几个新的 CRD，包括 Task、Pipeline、TaskRun 和 PipelineRun
l Task: Task 为构建任务，是 Tekton 中不可分割的最小单位，正如同 Pod 在 Kubernetes 中的概念一样。在 Task 中，可以有多个 Step，每个 Step 由一个 Container 来执行。
l Pipeline: Pipeline 由一个或多个 Task 组成。在 Pipeline 中，用户可以定义这些 Task 的执行顺序以及依赖关系来组成 DAG（有向无环图）。
l PipelineRun: PipelineRun 是 Pipeline 的实际执行产物，当用户定义好 Pipeline 后，可以通过创建 PipelineRun 的方式来执行流水线，并生成一条流水线记录。
l TaskRun: PipelineRun 被创建出来后，会对应 Pipeline 里面的 Task 创建各自的 TaskRun。一个 TaskRun 控制一个 Pod，Task 中的 Step 对应 Pod 中的 Container。当然，TaskRun 也可以单独被创建。
一个 Pipeline 通常由多个 Task 组成，这些 Task 串、并执行。而每个 Task 中，又有若干个 Step ，Step 是串行执行的。
同时 Pipeline 还定义了输入、输出，通常输入 Git 仓库，输出镜像。在运行时，Pipeline 对象作为一个模板，被 PipelineRun 引用，创建运行实例。
通过PipelineRunController 监听 PipelineRun 对象，将 PipelineRun 中所有的 Task 构建为一张有向无环图，创建 TaskRun。而 TaskRunController 监听 TaskRun 对象的变化，根据 TaskRun 引用的 Task，创建 Pod 运行 Step。
每个任务在它自己的Kubernetes Pod中执行。因此，默认情况下，Pipeline中的任务不共享数据。要在任务之间共享数据，必须显式地配置每个任务，使其输出可用于下一个任务，并将先前执行的任务的输出作为其输入，还可以通过PV的方式共享数据。
Tekton的组件
l Tekton Pipelines：tekton 的基础，定义了一组 CRD，用于定义 pipeline。包含tekton-pipeline-controller和tekton-pipeline-webhook两个组件。
l Tekton Triggers：允许基于 event 实例化 pipeline。比如：git的pr请求
l Tekton Cli：提供命令行工具和 tekton 交互
l Tekton Dashboard：图形化界面展示 pipeline 信息
l Tekton Catalog：高质量的、社区贡献的 pipeline 仓库
l Tekton Hub：图形化界面访问 tekton catalog
l Tekton Operator：在k8s上安装、移除、更新tekton组件的项目
什么是Jenkins X?
Jenkins X是基于Kubernetes的持续集成、持续部署平台。也是Jenkins的子项目。Jenkins X旨在使程序员在研发过程中能够轻松遵循DevOps原理和最佳实践。
Jenkins X架构
Jenkins X 基于松耦合架构的 DevOps 模型，被设计用来支持在多个团队间，部署大量可重复、可管理的分布式微服务。在Jenkins X的设计中，整合了Tekton，Helm，Draft，GitOps，以及Nexus，Chartmuseum，Monocular，Skaffold等诸多系统和工具，从而实现自动构建编译环境，生成容器镜像，流水线，自动化部署，并通过简单的Review实现不同环境间的自动发布。
Jenkins X 特性
1.完美封装的命令行工具
Jenkins X 带来了一个方便使用的命令行工具 jx ：
l 安装 Jenkins X 到已经存在的 Kubernetes 集群
l 创建一个新的 kubernetes 集群 并安装Jenkins X
l 导入项目到Jenkins X 中以及他们的持续部署流水线设置
l 创建新的Spring Boot应用 并导入Jenkins X 中，以及他们的持续部署流水线设置
2.自动化流水线
选择项目类型自动生成Jenkinsfile定义流水线
l 自动生成Dockerfile并打包容器镜像
l 自动创建Helm Chart并运行在Kubernetes集群
l 自动关联代码库和流水线，作为代码变更自动触发（基于Webhook实现）
l 自动版本号自动归档
3基于GitOps的部署升级
l 所有的环境，应用列表，版本，配置信息统一放在代码库中进行版本控制
l 通过Pull Request实现研发和运维的协同，完成应用部署升级（Promotion）
l 可自动部署和手动部署，在必要的时候增加手工Review
4.自动生成预览环境和信息同步反馈
l 预览环境用于代码Review环节中临时创建
l 同Pull Request工作流程集成并实现信息同步和有效通知
l 验证完毕后自动清理
l 提交和应用状态自动同步到Github注释
l 自动生成release notes信息供验证
什么是Argo CD?
Argo CD 是一个为 Kubernetes 而生的，遵循声明式 GitOps 理念的持续部署（CD）工具。Argo CD 可在 Git 存储库更改时自动同步和部署应用程序
Argo CD架构
Argo CD 是通过一个 Kubernetes 控制器来实现的，它持续 watch 正在运行的应用程序并将当前的实时状态与所需的目标状态（ Git 存储库中指定的）进行比较。已经部署的应用程序的实际状态与目标状态有差异，则被认为是异常状态，Argo CD 会报告显示这些差异，同时提供工具来自动或手动将状态同步到期望的目标状态。在 Git 仓库中对期望目标状态所做的任何修改都可以自动应用反馈到指定的目标环境中去。
从整体上看，Argo CD 有三个主要的组成部分：API Server 、Repository Server 、Application Controller。
API Server
Argo CD 的 API Server 是一个 gRPC/REST server，它公开 Web UI、CLI 以及一些其他场景需要用到的 API。
它主要进行以下几个内容：
l 应用程序管理和状态报告；
l 调用应用程序操作（例如：同步、回滚、用户定义的操作）；
l repository 和集群 credential 管理（存 K8s secrets）；
l 身份验证和授权委托给外部身份认证组件；
l RBAC（Role-based access control 基于角色的访问控制）；
l Git webhook 事件的 listener/forwarder；
Repository Server
Repository Server 是一个内部服务，它负责保存应用程序 Git 仓库的本地缓存，并负责生成和返回可供 Kubernetes 使用的 manifests，它接受的输入信息主要有以下内容：
l 仓库地址（URL）
l revision（commit, tag, branch）
l 应用程序路径
l 模板的特定设置：比如 helm values.yaml 等
Application Controller
Application Controller 是一个 Kubernetes controller，它持续监听正在运行的应用程序并将当前的实时状态与所需的目标状态（如 repo 中指定的）进行比较。它检测 OutOfSync 应用程序状态并有选择地采取纠正措施。它负责为生命周期事件（PreSync、Sync、PostSync）调用任何用户定义的 hooks。
Argo CD特性
l 将应用程序自动部署到指定的目标环境
l 支持多种配置管理/模板工具（Kustomize、Helm、Jsonnet、plain-YAML）
l 能够管理和部署到多个集群
l SSO 集成（OIDC、OAuth2、LDAP、SAML 2.0、GitHub、GitLab、Microsoft、LinkedIn）
l 支持多租户和 RBAC 授权策略
l 可随地滚动回滚到 Git 存储库中提交的任何应用程序配置
l 应用资源健康状态分析
l 自动配置检测和可视化
l 自动或手动将应用程序同步到所需状态
l 提供应用程序活动实时视图的 Web UI
l 用于自动化和 CI 集成的 CLI
l Webhook 集成（GitHub、BitBucket、GitLab）
l 用于自动化的访问令牌
l 提供PreSync、Sync、PostSync Hooks以支持复杂的应用程序推出（例如蓝/绿和金丝雀升级）
l 应用程序事件和 API 调用的审计跟踪
l Prometheus 监控指标
l 用于覆盖 Git 中的 ksonnet/helm 参数
指标对比
| 指标 | Tekton | Jenkins X | Argo CD |
| 安装与部署 | 提供Tekton Operator用于安装、移除、更新Tekton组件 | 提供一个方便使用的命令行工具 jx可用来安装Jenkins X | 通过k8s yaml文件部署，并且提供多租户的部署模式 |
| 高可用 | 通过配置Deployment的多副本实现 | 通过配置Deployment的多副本实现 | 通过配置Deployment的多副本实现 |
| 并发构建性能 | 依赖Kubernetes 的 Pod 调度能力，通过对集群节点扩容即可提升并发能力 | 依赖Kubernetes 的 Pod 调度能力，通过对集群节点扩容即可提升并发能力 | 不提供CI能力依赖其他工具，CD性能取决于Git仓库和Kubernetes |
| 易用性 | 提供简单的Dashboard页面 | 提供功能丰富的Web UI页面 | 提供功能丰富的Web UI页面 |
| 扩展性 | Tekton Hub提供100+插件。自研插件也比较简单，没有开发语言限制 | 插件生态丰富 | 不支持插件扩展 |
| 成熟度 | CD基金会项目，开源社区活跃Github star数7.7k。 | CD基金会项目，开源社区活跃Github star数4.3k。 | 开源社区活跃Github star数12.3k。 |
| 复杂度 | 非常轻量，易于维护 | 架构较为复杂，组件众多，需要一定的维护成本 | 架构比较简单，易于维护 |
总结
云原生CI/CD工具由于都是基于Kubernetes 打造的在高可用、并发性能、扩容能力都非常不错没有太大的区别。如何选择适合自己的云原生CI/CD工具主要就是根据业务需求、使用场景、扩展性以及易用性来选择了。下面我们总结了一下Tekton、Jenkins X、Argo CD的优势与适用场景，希望能帮助您更好的做出决策。
Tekton更像是一套构建 CI/CD 系统的开发框架，它非常的轻量、灵活、可扩展性极高。它不能立即使你获得CI/CD的能力。但得益于 Tekton 高度抽象化的设计，可以设计出各式各样具有创造力的CI/CD流水线。Tekton更适用于具有良好工程能力的团队，希望从零打造一套极具特色的CI/CD平台。
Jenkins X是一个雄心勃勃的项目，他整合了众多工具提供开箱即用的强大功能，不需要自己拼凑出一整套独立的工具和配置。采用Jenkins X的最大挑战是，很难知道它是解决公司所有CI/CD需求的完美解决方案，还是一个过于复杂的怪兽，它最初会带来一些快速的胜利，但在未来的发展中可能会成为一个障碍。Jenkins X更适用于具有非常丰富的Jenkins使用经验的团队，希望在兼容现有平台的前提下引入云原生的CI/CD，那么Jenkins X是一个不错的选择。
Argo CD也足够轻量级，Gitops是它的主要优势。它使用Gitops的方式管理不同集群中多个应用程序的部署，应用程序部署和生命周期管理是自动化的、可审计的以及易于回滚的。但是灵活性和扩展能力不足，对于CI部分还需要与其他工具协作。Argo CD更适用于团队中已有成熟稳定的CI工具，希望引入Gitops来优化CD部署与管理。
