如果你开始使用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） |