一、CI/CD 场景中的痛点与目标¶

1.1 前言¶

我们公司目前每天的jenkins构建测试基本上平稳在2300+左右，同时并发的构建我见过一次120+，只是这一个jenkins节点是不可以完成这么大的任务量的！所以jenkins-slave 的接入就很大程度上提高了性能！

1.1.1 痛点梳理¶

• 构建任务高峰期，Jenkins服务频发不可用状态；
• 服务虚机资源有限，不能随意调用空闲资源；
• Jenkins 服务器宕机后需要人工手动重启；

1.1.2 思路分析¶

基于K8s动态Slave模式：

优势

• 基于云原生现有K8s集群来解决问题，充分的利用现有资源，无需再申请新虚机；

• Slave可在构建任务来之时动态创建，工作结束后自动销毁，释放资源；

• 可通过K8s原生来管理Jenkins的调度策略，防止Slave调度分配不均匀；
• 通过云原生控制器来管理Jenkins配置，后期比较利于维护、扩展；
• Jenkins小概率意外宕机场景，通过K8s的机制可以自愈；

劣势

• 增加了系统复杂度；
• 有一定技术壁垒；
• 实现需要时间；

1.2 Master-Slave 工作原理¶

1.2.1 基于 K8s 集群¶

Jenkins Master 接到构建任务后会动态在集群中的一个工作节点上拉起一个Jenkins Slave Pod来干活，活干完后可及时释放Pod。

1.2.2 设计优势¶

• 动态伸缩

合理的使用资源，每次运行 Job 时，会自动创建一个 Jenkins Slave，Job 完成后， Slave 自动注销并删除容器，资源自动释放，而且 Kubernetes 会根据每个资源的使用情况，动态分配 Slave 到空闲的节点上创建，降低出现因某节点资源利用率高，还排队等待在该节点的情况。

• 服务高可用

当 Jenkins Master 出现故障时，Kubernetes 会自动创建一个新的 Jenkins Master 容器，并且将 Volume 分配给新创建的容器，保证数据不丢失，从而达到集群服务高可用。

• 扩展性好

当 Kubernetes 集群的资源严重不足而导致 Job 排队等待时，可以很容易的添加一 个 Kubernetes Node 到集群中，从而实现扩展。