Jenkins 部署-K8s OR 物理机
作者 765 DevOps
发表于 2021-06-10 更新于 2021-06-11 分类于 Jenkins
本文字数: 1k 阅读时长 ≈ 1 分钟
如果你开始使用 Jenkins 作为你的 CI 工具,刚好也在使用 K8s 集群做 CD,那你一定很纠
结我的 Jenkins 到底用什么方式进行部署管理呢?
这里我将我们遇到的实际经验分享给各位参考,希望能给到你一些帮助吧,
1、结论
不拖沓,直接上结论:
轻易不要上 K8s,启动速度和 Slave 镜像管理以及构建缓存等会比较耗精力;在 CICD 起
步,日构建在 500 次左右,特别是含 Android 的 gradle 构建时,建议直接上物理机,绝
对真香。
选择适合的,并不是技术领先的,当然能 Hold 住的大佬,请随意哈
备注说明下目前我遇到的构建量级吧,相对大厂是小儿科了点,勿喷哈。
• Web 应用构建,约日均构建在 400-500 次/日
• 移动端构建(Android 为主),约日均构建在 30-50 次/日,偶尔会有批量的渠道
打包量比较大(渠道量 1K+)
2、K8s 集群里的 Jenkins
2.1、选择背景
公司开始做中台了,其中包括建设 CICD 系统,基本是从 O 起步吧,当初直接选型了:
java spring 微服务 + K8s 作为接下来的技术发展方向。作为打辅助的持续交付系统也就
那个时候定型的,选型 CI 工具为 Jenkins(当然还有很多的周边的工具链选型),部署
原则:Everything in docker
2.2、遇到问题
• K8s 集群稳定性是第一大考验
• 动态的 Slave 启动慢,修改长时间存活,莫名会出现心跳终端,SalvePod 假死
• 各 Slave 节点构建依赖的缓存共享设置,尤其是移动端的 Gradle 的缓存(谁用谁
知道!参考:流利说客户端持续交付工程实践……)
• Slave 多了后占用的资源无法想象,最后不得不给 Jenkins 独立的 Node,打上标
签区分
• 还有就是构建过程,一个字儿:超级慢,很大原因是 K8s 集群的 Ceph 文件系统
• Slave 镜像维护成本也颇高,尤其是需要版本升级的时候
• …
3、物理机里的 Jenkins
3.1、选择背景
我们重新建设了 DevOps 平台(定位:一站式研发协同平台),对于原有的功能迁移后,
发现对于很多核心、根本问题,治标不治本。新平台也迫切需要出成绩,最终开出了 历
史的倒车,我们回到了物理机 Jenkins。
3.2、效果
一个字:快,平均提速达到 30%+(其中移动端提速了甚至到了 50%),且稳定性更高
3.3、成本核算
迁移到物理是不是成本很高啊,那可是物理机啊,然并卵……
迁移前
迁移后
K8s 独立 Node:64c+128G(1),32c+32G(1)
32c+32G(5)