Design and Implementation of a High‑Availability Jenkins Distributed Cluster with Kubernetes and LVS

Jenkins, a Java‑based open‑source automation tool, has been widely used in continuous integration systems, but increasing job numbers, build frequency, and service pressure have caused resource consumption, complex configuration, and high maintenance costs for the EOS code‑quality scanning platform.

Project Background – Using a single master for builds leads to heavy CPU and memory usage, and while Jenkins supports master‑slave distribution, it does not fully solve service‑level scalability and configuration challenges.

Containerized Solution – A high‑availability Jenkins distributed cluster was designed, combining a master‑slave architecture with Kubernetes‑based containerization and LVS load‑balancing. The master manages jobs, while slaves are dynamically created as Pods based on job labels, providing elastic scaling and efficient resource utilization.

Master‑Slave Distributed Architecture – Jobs are triggered on the server, Jenkins API invokes the master, which schedules tasks to slaves. The simplified EOS‑Server scan flow includes triggering a scan, cloning code, executing scan scripts, and returning results.

Node Connection Methods – Two Jenkins‑provided methods are used: SSH‑based slave launch (master initiates connection) and JNLP‑based launch (slave initiates connection). Automated scripts create nodes based on labels and connect them to the master via JNLP.

Kubernetes Containerization Practice – Custom Jenkins master and slave Docker images were built (based on CentOS7) and deployed to a Kubernetes cluster. The master runs on a designated node; when a build request arrives, the Jenkins Kubernetes plugin creates a slave Pod with the appropriate label, registers it to the master, and deletes the Pod after the job completes, ensuring optimal cluster resource usage.

LVS Load Balancing – LVS with IPVSADM and Keepalived (DR + weighted round‑robin) provides high‑performance, high‑availability server clustering. The primary LVS node supplies data sources (CFS) to all Jenkins servers, while the secondary node offers hot‑standby scheduling and remote backup via rsync + inotify.

Project Outcomes – After containerization, the system achieved high availability (automatic master failover), resource sharing (jobs run on any Docker host via labels), efficient slave resource allocation (dynamic Docker‑based slaves with automatic lifecycle), and easy scalability (adding Kubernetes nodes when resources are scarce).