基于【k8s】的Jenkins动态扩展与高可用部署实战

1. 为什么要在Kubernetes上部署Jenkins？

如果你正在管理一个软件开发团队，或者自己就是个爱折腾的开发者，那你对Jenkins肯定不陌生。它就像一个不知疲倦的“构建机器人”，帮你自动编译代码、运行测试、打包部署，是CI/CD（持续集成/持续交付）的核心引擎。但传统的部署方式，比如直接装在一台虚拟机或者物理服务器上，时间一长就会遇到不少头疼的问题。

想象一下，你的团队规模在扩大，项目越来越多，每天触发的构建任务像潮水一样涌来。那台老旧的Jenkins服务器开始气喘吁吁，CPU和内存使用率经常飙到红线，构建队列排得老长，开发人员只能干等着。更糟的是，万一这台服务器硬盘坏了或者网络断了，整个CI/CD流程立刻瘫痪，所有人的工作都得停下来。这种单点故障的风险，在追求快速迭代和稳定交付的今天，是绝对不能接受的。

这时候，Kubernetes（简称K8s）的价值就凸显出来了。把Jenkins搬到K8s上，绝不仅仅是为了“赶时髦”，而是为了解决这些实实在在的痛点。你可以把K8s理解成一个高度智能的“数据中心调度官”。它管理着一群服务器（节点），上面跑着无数个集装箱（容器）。我们的Jenkins，就是其中一个（或一组）特殊的集装箱。

这么做的好处是立竿见影的。首先，资源利用变得“聪明”了。在K8s里，Jenkins不再独占一整台服务器的资源。当构建任务不多时，它可能只占用很少的CPU和内存；一旦检测到任务队列变长，K8s可以配合一些策略，自动“变出”更多的Jenkins构建节点（Agent）来处理工作，等忙完了再自动回收资源。这就像你开的餐厅，平时只有几个服务员，但周末客流高峰时，能立刻从兼职库里调派人手，高峰期过了就让他们下班，绝不浪费人力成本。

其次，高可用性得到了本质提升。在K8s中部署Jenkins，我们通常会以Deployment的方式运行。这意味着，K8s会确保始终有指定数量的Jenkins主实例（比如1个或2个）是健康的。如果运行Jenkins的那个节点挂了，K8s的调度器会在几分钟内，在另一个健康的节点上重新启动一个新的Jenkins实例，并且自动挂载上之前持久化的数据（配置、任务历史、插件等）。对用户来说，可能只是感觉访问稍微卡顿了一下，服务很快就恢复了，构建历史也完好无损。这彻底告别了“一损俱损”的单点故障时代。

最后，环境标准化和快速迁移也是一大优势。所有的依赖、配置都封装在容器镜像和K8s的配置声明里。你需要复制一套完全相同的Jenkins环境给测试团队？或者因为机房迁移要整体搬迁？在K8s里，这几乎就是几条命令的事情。这种一致性和可移植性，对于维护复杂软件交付链的团队来说，价值巨大。

所以，在K8s上部署Jenkins，核心目标就是构建一个弹性伸缩、高可用、易于管理的现代化CI/CD基础设施。接下来，我们就手把手带你实现它。

2. 部署前的核心准备工作

实战开始前，我们需要把“舞台”搭好。这不仅仅是安装软件，更重要的是理解每个组件的作用，并做好规划，避免后续踩坑。我根据自己的经验，把准备工作分成了几个关键部分。

2.1 Kubernetes集群就绪

这是我们的基础运行平台。你可以使用任何形式的K8s集群：

• 本地开发：Minikube, Kind (Kubernetes in Docker)。
• 云服务：阿里云ACK、腾讯云TKE、华为云CCE、亚马逊EKS等。
• 自建集群：使用kubeadm等工具在自有服务器上搭建。

我强烈建议，生产环境至少使用3个节点（1个Master，2个Worker）的集群，以保证基本的高可用。集群的网络插件（如Calico、Flannel）、存储插件（如NFS Provisioner, Ceph CSI）也需要提前部署和测试通。这里假设你已经有一个版本在1.20以上的、运行正常的K8s集群，并且kubectl命令可以正常操作。

提示：如果你在本地使用Minikube，记得通过 minikube start --memory=4096 --cpus=2 这样的命令分配足够的资源，因为Jenkins本身需要一定的内存。

2.2 选择与准备Jenkins镜像

这是至关重要的一步，选错了镜像可能会遇到兼容性问题或安全漏洞。Jenkins官方在Docker Hub上提供了多个镜像标签：

除了基础镜像，还有一个流行的选择是 jenkinsci/blueocean。这个镜像预装了Blue Ocean插件，提供了更现代、可视化的流水线编辑和展示界面，对新手非常友好。但请注意，Blue