Jenkins X：基于 Kubernetes 的 Serverless Jenkins

云原生时代，应用模块不断被拆分，模块的数量不断上涨并且模块之间关系也愈加复杂。企业在落地云原生技术的时，同时也需要有强大的 DevOps 手段，没有 DevOps 的云原生不可能是成功的。Jenkins X 是 CDF（持续交付基金会）与 Jenkins 社区在云原生时代的全新 DevOps 产品，本文我们将介绍 Jenkins X 以及 Jenkins X 背后的技术。

背景

Jenkins 在2004年诞生。根据官网的数据统计（截止2019年3月）有 250,000 的 Jenkins 服务器正在运行、15,000,000+ Jenkins 用户、1000+ Jenkins插件。Jenkins 在 DevOps 领域取得了巨大的成功，但随着技术的不断发展与用户数量的不断上升，传统 Jenkins 所暴露出来的问题也越来越多。在这里我们将介绍传统 Jenkins 所遇到的挑战。

Jenkins 所遇到的挑战 - 单点故障

在传统的 Jenkins 当中，我们首先会遇到的问题就是 Jenkins 的单点故障问题。

Jenkins 的历史非常悠久，在当时大多数程序都是单机程序，Jenkins 也不例外。

对比其他系统，Jenkins 的单点故障问题会更加凸显，熟悉 Jenkins 的用户都知道，它是一个基于插件的系统，而我们会经常安装插件，这时候我们就需要重启 Jenkins 服务器。这将导致共用这个平台的所有用户都无法使用。

Jenkins 所遇到的挑战 - JVM消耗资源多

Jenkins 是 Java 系的程序，这使得 Jenkins 需要使用 JVM，而 JVM 将会消耗大量的内存。

CI/CD 任务往往都是在代码提交时被触发，在非工作时间，这些资源消耗是可以大大降低的。

Jenkins 所遇到的挑战 - Job 的调度方式使 CI/CD 变得困难

在 Jenkins 诞生的年代，机器资源并没有像现在一样丰富、可调度，导致 Jenkins 的调度模式使得不适合现代的环境。

Jenkins 的调度模式是一种尽量能够节省资源的方式进行调度的。在一般的调度过程中 Jenkins 需要经历以下几个阶段：

检查有没有可用的 agent -> 如果没有的可用的 agent，计算是否有 agent 预计将要运行完任务 -> 等待一段时间-> 启动动态的 agent -> agent 与 master 建立连接。

这种方式使 CI/CD 任务被执行的太慢，我们往往都需要等待几十秒甚至更长时间来准备 CI/CD 的执行环境。

Jenkins X 的诞生与理念

Jenkins X 是起源于 Jenkins 的一个项目，在2018 年 2 月从 JEP（Jenkins Enhancement Proposals）中诞生。目前已经成为一个独立的项目，并且有了自己独立的 Logo。

Jenkins X 的设计目标是使用 Kubernetes 的力量来构建现代化的 CI/CD 平台，为用户提供自动化的 CI/CD。

在现代化方面我认为主要有两个部分，其中一部分为用户体验的现代化，另外一部分则是架构方面的现代化。我们这里将首先介绍有关用户体验的现代化，稍后再介绍架构方面的现代化。

重新思考云原生时代的 CI/CD

用户在使用传统的 Jenkins 的 时候往往都在思考一个问题，我们应该怎样创建一个流水线来完成的工作。而用户想要的并不是如何创建一个流水线，而是想要：

• 更快的上市时间

• 更高的部署频率</