本文分析了在使用Jenkins和Kubernetes进行CI/CD时遇到的构建时延问题，主要由NodeProvisionerStrategry和Jenkins Kubernetes Plugin的策略引起。提出了一种新的优化方案，包括立即创建slave容器、预热足够数量的构建池以及动态维护在线slave数量，以降低构建的等待时延，提升构建效率。
Jenkins在云端构建性能优化分析
问题背景
目前我们的PaaS平台使用了Jenkins对作为分布式构建调度平台，目前每天大概有5000左右的业务构建在上面运行，并且这些构建80%的执行是在高峰时段的几个小时内，执行包含单元测试，静态代码检查，打包，烘焙镜像，自动化测试以及部署等任务。为了保证构建的性能，提高构建资源的使用率，我们使用了Kubernates 对Jenkins的构建的节点Jenkins-slave进行动态管理，CI系统的整体架构如下图：
- Jenkins Master总共有5台，构建管理组件负责将流水线任务相对平均地分布在这5台机器，同时也是为了避免单点失败
- 每个Jenkins master安装了一个基于开源社区的jenkins-kubernates plugin，同时做了一些定制化的逻辑，用于在k8s集群上创建不同构建类型的jenkins-slave
- 为保证干净的Runtime环境，每个Jenkins slave只运行一个构建任务，构建结束后slave会从Master删除，同时对应的K8s pod也会回收
用户使用PaaS平台的流水线进行构建时，都希望自己的构建任务尽快地开始。由于所有的构建最终都将运行于Jenkins的工作节点：Jenkins-slave， 只有当前的Jenkins Master有可用的slave(executor)时，构建任务才会被调度到该slave上并马上执行,否则构建将呆在队列里，因此为了让用户体验到构建的零时延，不能在用户点击构建后才
最低0.47元/天 解锁文章
扫一扫
696
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
