Jenkins 构建集群在 Kubernetes 上的实践与优化

2.2 常见问题

随着业务发展，我们遇到了典型的瓶颈：

• 资源闲置与排队并存：部分 Slave 空闲，但队列中任务积压。
• 空间不足：Workspace 遗留导致构建失败。
• 环境隔离难：业务间无法共享编译环境，导致重复建设。

2.3 优化改进

针对上述问题，我们实施了四项优化措施：

1. 同质 Slave 统一 Label：将同类型 Slave 打上相同标签，同类型 Job 通过 Label 调度，形成资源池。
2. 调整 Executor 数量：根据业务场景适量增加 Slave 的执行器数量，提升并发能力。
3. 定时清理 Workspace：扫描并清理废弃 Job 的残留文件，释放磁盘空间。
4. 配置清理规则：在 Post Build Action 中设置清理策略，保留必要的缓存（如 ccache），删除无用文件。

例如，通过保留关键缓存，可将 200GB 的编译空间压缩至 50GB 左右，极大缓解存储压力。

2.4 优化效果

实施后取得了显著成效：

• 并发能力提升：Label 资源池化有效缓解了队列等待。
• 空间利用率提高：构建失败率因空间不足大幅下降。
• 资源趋于均衡：Disk 和 CPU 利用率在不同 Slave 间更加均匀。

2.5 方案反思

优势：资源池化、并发量增大、Job 配置透明化。

局限：Jenkins 内置调度策略可能导致资源不均；同一 Job 多次构建倾向同一节点；环境隔离性较差，业务调整时需重构基础设施。

三、基于 Docker 插件的容器化实践

3.1 需求驱动

APK 编译面临单点服务器性能差、环境依赖复杂、并发困难等问题。引入容器化成为必然选择。

3.2 镜像固化

Docker Image 需包含构建账号、权限、SDK/NDK 及工具链。建议按产品线划分镜像，避免'大而全'导致的维护成本过高。同时需配套自动化构建、更新和部署流程。

3.3 插件集成

使用 Jenkins Docker 插件（如 0.15.0 版本）可实现容器化 Slave。插件支持 SSH 连接，后续版本开始支持 JNLP。

配置要点：

• 添加 Docker Host 信息，可视为普通 Slave。
• 定义 Docker Template，关联具体镜像。

3.4 配置示例

• Name：Docker 配置名称。
• Docker URL：连接 Docker Host 的地址。
• Container Cap：设置并发数量限制。
• Launch Method：连接方式（早期仅支持 SSH）。

3.5 方案反思

优势：环境标准化、隔离性好、按需弹性伸缩、资源共享。

局限：Docker Host 与 Image 强耦合，配置繁琐；调度策略仍依赖 Jenkins 默认机制，存在不均衡风险。

四、基于 Kubernetes 的容器化实践

4.1 为什么选择 K8s

面对 Docker 插件的局限性，Kubernetes 提供了更强大的编排能力。它支持 Pod 概念，允许在一个 Pod 中运行多个 Container，并通过插件创建 Pod 来挂载 Jenkins Slave。

4.2 业务需求

• 资源收缩严重，需保障业务正常运转。
• 容器化与标准化，确保构建环境隔离。
• 利用 K8s 资源限制与调度策略，实现服务器资源共享。

此外还需考虑性能对比、版本选择、Registry 管理及构建优化（如代码镜像、编译缓存）。

4.3 可行性验证

通过 VM 与 Docker 容器的编译性能对比测试，确认两者性能基本一致，坚定了迁移信心。

4.4 组件版本

参考主流稳定版本组合，确保兼容性。

4.5 镜像构建

使用 Ansible Playbook 批量部署环境，结合 Dockerfile 自动化构建镜像。

4.6 依赖管理

• 外部工具：单一可信数据源，Ceph 存储，Node 通过 NFS 挂载。
• 代码镜像：本地目录挂载，Volume 使用。
• 编译缓存：本地目录挂载，支持命中率统计和多基线复用。

4.7 全景架构

Jenkins 通过 K8s 插件在 Node 上创建容器作为 Slave。外部依赖包括 Cache、Tools、Mirror、Harbor 及监控组件 Grafana。

4.8 实施效果

迁移至容器化后：

• 资源利用率提升 50% 以上。
• 资源成本下降 35%。
• 新业务上线速度显著加快。

4.9 插件配置

• 配置 Kubernetes API URL。
• 添加 Pod Template（Image）。
• 启动命令间接使用 JNLP。
• 配置资源限制（CPU/Memory）。

4.10 配置示例

注意划线部分的参数配置，确保连接正常。

4.11 资源限制

对 CPU 和 Memory 设置 Limit 和 Request，防止资源争抢影响集群稳定性。

4.12 启动脚本

容器启动脚本需处理 SECERT 和 SLAVE_NAME 参数，JENKINS_URL 通常设置为环境变量。

4.13 方案反思

优势：继承 Docker 优点，支持资源限制，利用 K8s 原生调度。

局限：K8s Cluster 的高可用性至关重要，单 Master 故障会导致整个构建集群瘫痪，需自行实现 HA 方案。

4.14 持续改进

未来方向包括 Jenkins Master 容器化、Job 脚本化以及流水线驱动的持续交付。

4.15 总结

三种方案各有优劣，应根据实际业务规模与团队技术栈选择合适的落地路径。