一、Jenkins 分布式架构介绍
Jenkins 采用 Master - Slave/Agent 主从架构，是持续集成/持续交付（CI/CD）场景中提升构建效率、扩展能力的关键设计，其核心组件与逻辑如下：
1、核心组成：主节点（Master）与从节点（Agent/Slave）
Jenkins 分布式架构由两类节点组成，两者职责明确分离，协同工作。
| 节点类型 | 核心职责 | 关键说明 |
|---|---|---|
| 主节点（Master） | 1. 配置管理：管理全局配置、插件和用户权限。 2. 接收和解析任务请求（如 Pipeline 脚本）。 3. 任务调度：根据作业（Job）规则，将构建任务分配给合适的从节点执行。 4. 监控与报告：跟踪从节点状态（连接、负载、异常），收集任务执行结果生成构建报告（成功率、时间、历史记录）并展示。 | 不建议直接执行构建任务，避免因资源占用导致界面卡顿或调度失效 |
| 从节点（Agent） | 1. 无需安装完整 Jenkins：Slave 节点仅需运行"代理程序"（Agent），即可接收 Master 分发的构建任务。 2. 资源扩展：突破 Master 节点硬件限制，通过多 Slave 节点并行执行任务，大幅提升构建效率。 3. 执行具体操作（如代码编译、镜像构建、自动化测试） 4. 环境适配：Slave 节点可部署在不同环境（如 Windows/Linux、物理机/虚拟机），满足多平台构建需求。 5. 将执行日志和结果回传主节点 | 可根据任务需求配置不同环境（如 Linux 编译环境、Windows 测试环境） |
Jenkins 的主从节点架构，不像 MySQL 主从那样的架构方式，从节点本身并不需要安装完整的 Jenkins，只需要运行 "代理程序"。它更像 K8S 的控制平面与Node节点之间的关系。
2、核心优势：为何需要分布式架构
相比单节点部署，分布式架构主要解决以下 4 个核心问题：
- 提升性能：将高负载任务分散到多台从节点，避免单节点 CPU、内存、磁盘 IO 瓶颈。
- 环境隔离/灵活性：不同任务可使用专属从节点（如 Python 项目用 Python 环境节点，Java 项目用 JDK 环境节点），避免依赖冲突，并能实现 "多环境构建"、"跨平台构建"。
- 高可用性：单个从节点故障仅影响其负责的任务，主节点可将任务重新分配到其他健康节点，降低整体故障风险。
- 弹性扩展/伸缩性：业务增长时，无需重构主节点，只需新增从节点即可提升整体处理能力。
当然，Jenkins 的高可用性是相对的。Jenkins 的主节点（Master）本身不直接支持 "多节点高可用（HA）" 架构（不像 K8S）。主节点挂掉以后，整个集群也会不可用。
为什么 Jenkins 原生不支持多主节点？
Jenkins 设计之初是单主节点架构，主节点负责存储配置（
JENKINS_HOME目录）、任务调度、用户权限等核心功能。由于：
JENKINS_HOME目录包含实时更新的配置文件、构建历史、插件状态等，多主节点同时读写会导致数据冲突（如配置覆盖、锁竞争）。- 主节点与从节点的通信依赖唯一的主节点地址，多主节点会导致从节点无法确定连接目标。
因此，Jenkins 没有原生的 "多主节点集群" 方案，需通过外部工具或架构设计实现高可用。
基于 Kubernetes 的主节点高可用（容器化场景）
核心思路：利用 Kubernetes（K8s）的 Deployment + 持久卷（PV）实现主节点的自动恢复和冗余。
- 将 Jenkins 主节点打包为容器镜像，通过 K8s Deployment 部署，设置副本数为 1（避免多主节点冲突）。
- 使用 K8s 持久卷（PV，后端绑定高可用存储如 Ceph）挂载
JENKINS_HOME，确保数据持久化。- 配置 K8s Service（固定访问入口）和就绪探针（Liveness/Readiness Probe）：
- 当主节点容器故障时，K8s 自动销毁故障容器并在新节点重建，通过 PV 恢复
JENKINS_HOME。- 配合 HPA（Horizontal Pod Autoscaler）可实现资源自动扩展（但副本数仍需限制为 1）
二、Jenkins 集群配置
假设现在有三台服务器，一台安装有 Jenkins Master 节点；一台安装有 Maven 环境（agent-maven-01），还有一台安装有 Docker 环境（agent-docker-01）。我们希望 Docker 镜像构建任务能运行在 agent-docker-01 上，Maven Jar 包构建任务能运行在 agent-maven-01 上。针对这个场景，我们来配置一个 Jenkins 集群。
未完待续。。。