Jenkins continuous integration method and system based on Kubernetes

Abstract

The invention relates to the technical field of continuous integration and continuous delivery, and discloses a Jenkins continuous integration method based on Kubernetes. According to the method, a Jenkins server is deployed in a Kubernetes cluster to serve as a control plane, a construction environment is created through a preset multi-container Pod template, and a Pod containing a plurality of containers is dynamically created based on the Pod template, so that each container executes different construction tasks. Containers in the Pod realize collaboration through sharing a network namespace and a storage volume, and a Jenkins server monitors task execution states of the containers in the Pod and performs dynamic scheduling according to task priorities and cluster load states. And after the task is completed, automatically destroying the Pod and releasing cluster resources. According to the method and the device, dynamic expansion and contraction of a construction environment and efficient parallel execution of tasks are realized, the problem that a traditional Jenkins static resource pool is difficult to deal with load changes is solved, the resource utilization rate is improved, the expandability of the system is enhanced, and an efficient and reliable solution is provided for an enterprise-level continuous integration system.

Description

Technical Field

[0001] This application relates to the technical field of continuous integration and continuous deployment, and particularly relates to a Jenkins continuous integration and continuous delivery method based on Kubernetes. Background Art

[0002] In the field of modern software development, continuous integration and continuous delivery have become key practices for improving development efficiency and ensuring software quality. As a mainstream continuous integration tool, Jenkins can support the basic continuous integration needs of enterprises through its Master-Slave distributed build architecture. However, with the popularization of the microservices architecture and the development of cloud-native technologies, several technical limitations of the traditional Jenkins architecture have emerged in practical applications.

[0003] First of all, traditional Jenkins relies on a static proprietary build resource pool. This fixed resource allocation method is difficult to cope with the high-concurrency build requirements in modern application development. In scenarios with large load fluctuations, either resources are left idle, or tasks queue up waiting, unable to achieve on-demand resource allocation and efficient utilization.

[0004] Secondly, the execution nodes of traditional Jenkins are managed in units of virtual machines. This coarse-grained resource scheduling method limits the parallel execution ability of tasks. There is a lack of effective isolation mechanisms between different types of build tasks, which easily causes environmental pollution and dependency conflicts, affecting the stability and reliability of the build.

[0005] Thirdly, during the execution of the build pipeline, there is a lack of effective coordination mechanisms between tasks at each stage. In traditional solutions, the transfer of build products between stages of the pipeline often relies on a shared file system or manual configuration, lacking a standardized and automated data exchange solution, increasing the complexity of configuration and the possibility of errors.

[0006] Finally, the scheduling strategy of traditional Jenkins is too simple, only performing task allocation based on predefined static rules, lacking the ability to perceive the real-time execution status of tasks and perform dynamic optimization. This mechanical scheduling method cannot be intelligently adjusted according to system load and task priorities, making it difficult to achieve the optimal use of resources.

[0007] Therefore, how to realize the evolution of the continuous integration platform from the traditional architecture to the cloud-native architecture, how to achieve intelligent resource scheduling and optimization while ensuring the build quality, and how to design a new generation of continuous integration systems to meet the development needs of the microservices era have become key technical problems that the industry urgently needs to solve. Summary of the Invention

[0008] The purpose of this application is to provide a Jenkins continuous integration method and system based on Kubernetes to solve the problems raised in the above background technology.

[0009] This application discloses a Jenkins continuous integration method based on Kubernetes, including the following steps:

[0010] Step A: Deploy a Jenkins server in the Kubernetes cluster and complete the initialization configuration, so that it serves as the console of the cluster to manage the continuous integration pipeline and its tasks;

[0011] Step B: After the Jenkins server receives a code submission or a manually triggered build signal, it sends a Pod creation request to the Kubernetes cluster based on a preset multi-container Pod template;

[0012] Step C: After the Kubernetes cluster receives the Pod creation request, it creates a pipeline task Pod according to the multi-container Pod template, where the Pod contains multiple containers for executing different build tasks, and the build tasks include code compilation, unit testing, and deployment;

[0013] Step D: After starting the Pod, the multiple containers in the Pod execute their respective build tasks in parallel, and the containers achieve data interaction and collaboration between tasks by sharing the network space and storage volume inside the Pod;

[0014] Step E: The Jenkins server monitors the task execution status of each container in the Pod in real time. When it detects that all build tasks are completed, it sends a Pod destruction command to the Kubernetes cluster to release the cluster resources; the Jenkins server repeats steps B to E according to the new build task requirements and the real-time load status of the cluster.

[0015] In a preferred example, the Jenkins server is deployed as a stateful set or stateless on one or more nodes of the Kubernetes cluster, and the initialization configuration of the Jenkins server includes: configuring Kubernetes cluster authentication information, registering cloud proxy nodes, setting resource quota limits, and configuring default parameters for build tasks.

[0016] In a preferred example, the multi-container Pod template includes: configuration information of a basic build container, a test container, and a deployment container. The configuration information of each container includes an image address, resource limits, environment variables, and storage volume mount points, where the image address is an identifier for the storage location of the container image.

[0017] In a preferred embodiment, the build task includes one or more of code compilation, unit testing, static code scanning, Docker image building and pushing, application configuration management, and integration testing, and the tasks can be executed in a pipeline order defined in advance or generated dynamically.

[0018] In a preferred embodiment, the containers within the Pod achieve coordination in the following ways: sharing the network namespace of the Pod to enable localhost communication, sharing persistent storage volumes to achieve data exchange, sharing configuration information through environment variables, and achieving inter-process communication through Socket files or port mapping.

[0019] In a preferred embodiment, the Jenkins server receives trigger requests through the WebHook interface or a predefined API interface; and dynamically adjusts the Pod creation and scheduling policies based on the following factors:

[0020] · The resource utilization rate of cluster nodes;

[0021] · The number of queued tasks;

[0022] · The average task execution time statistically calculated from historical build data;

[0023] · The task priority or task deadline specified by the user;

[0024] · Node affinity and taint tolerance settings.

[0025] In a preferred embodiment, the Jenkins server monitors the Pod status through the Kubernetes Watch mechanism, including:

[0026] · Polling container logs;

[0027] · Listening for the container exit status code;

[0028] · Collecting resource usage metrics such as CPU, memory, network, and disk I / O;

[0029] · Detecting abnormal container behaviors;

[0030] · Recording the monitoring data into the build history.

[0031] In a preferred embodiment, priority hierarchical management is performed on the build tasks, including:

[0032] · Setting priority tags for different types of tasks;

[0033] · Adjusting the priority in real time according to the task type, resource status, and time constraints;

[0034] · Dynamically adjusting the resource quota of the Pod according to the task priority;

[0035] · A resource preemption mechanism that supports high-priority tasks;

[0036] · A fault tolerance mechanism that realizes automatic retry of task failures and rescheduling of Pods.

[0037] In a preferred example, the system security and efficient utilization of resources are ensured through the following mechanisms:

[0038] · Configure independent service accounts and network policies for each Pod;

[0039] · Encrypt and store access credentials, where the access credentials include code repository credentials, Docker image repository passwords, and cloud service API keys;

[0040] · Automatically trigger resource recovery according to a preset cleaning policy;

[0041] Save the build artifacts and logs after the task is completed, and release the relevant Kubernetes cluster resources.

[0042] In a preferred example, the method further includes the following steps:

[0043] When the Jenkins server sends a Pod creation request to the Kubernetes cluster, dynamically adjust the multi-container Pod template based on historical build task data, real-time performance metrics, and metadata carried by build signals. The adjustments include: analyzing the resource consumption curve of historical build tasks and the real-time resource usage trend, predicting the resource demand curve of this build task, and dividing it into multiple stages, each stage corresponding to a different resource demand intensity; based on the resource demand stage, select the most matching template from a preset set of multi-container Pod templates to generate a customized multi-container Pod template; according to the task dependency graph, optimize the container startup order to make the resource scheduling match the task execution order; allocate elastic resource quotas for high-priority task containers and introduce a delayed scheduling strategy for low-priority task containers;

[0044] After the Pod is started, real-time collect the resource usage data, task execution progress, and exception events of each container, and feedback this data to the Jenkins server. The feedback data is used for: dynamically adjusting the resource allocation strategy of unexecuted task containers; triggering the resource recovery or task suspension strategy of low-priority containers when resource competition occurs for high-priority tasks; re-optimizing the container execution order based on real-time performance data, where the real-time performance data includes network latency and resource consumption trends;

[0045] Before the Pod is destroyed, a task execution report is generated based on the monitoring data. The report includes resource usage trend analysis, abnormal log analysis, and task execution path optimization suggestions, and the report is stored in the build history database for subsequent task scheduling and template update.

[0046] This application also discloses a Jenkins continuous integration system based on Kubernetes, including:

[0047] A deployment module for deploying a Jenkins server in a Kubernetes cluster and completing initialization configuration to make it the console of the cluster to manage the continuous integration pipeline and its tasks;

[0048] A build request module for making the Jenkins server send a Pod creation request to the Kubernetes cluster based on a preset multi-container Pod template after receiving a code submission or a manually triggered build signal;

[0049] A Pod creation module for making the Kubernetes cluster create a pipeline task Pod according to the multi-container Pod template after receiving the Pod creation request, where the Pod contains multiple containers for executing different build tasks, and the build tasks include code compilation, unit testing, and deployment;

[0050] A task execution module for making multiple containers in the Pod execute their respective build tasks in parallel after the Pod is started, and the containers realize data interaction and collaboration between tasks by sharing the network space and storage volume in the Pod;

[0051] A monitoring and management module for making the Jenkins server monitor the task execution status of each container in the Pod in real time, and sending a Pod destruction command to the Kubernetes cluster to release cluster resources after detecting that all build tasks are completed; the Jenkins server repeats the functions of the build request module, the Pod creation module, and the task execution module according to the new build task requirements and the real-time load status of the cluster.

[0052] Adopting the technical solution of this application, by deeply integrating Jenkins and Kubernetes, the following remarkable technical effects are achieved:

[0053] First, this application breaks through the limitations of the traditional Jenkins static resource pool and realizes the dynamic scaling of the build environment. By using the Jenkins server as the control plane of Kubernetes and combining it with the customized configuration of the Pod template, the build resources can automatically scale in and out according to the actual load conditions, significantly improving the resource utilization rate and effectively solving the problems of resource idleness and task queuing in the traditional solution.

[0054] Second, based on the cooperation mechanism of multi-container Pods, this application optimizes the task execution efficiency. By running multiple related build task containers within the same Pod and using the shared network namespace and storage volume to achieve efficient communication and data exchange between containers, the average task execution time is significantly reduced. At the same time, the isolation between containers ensures the consistency and reliability of the task execution environment.

[0055] Third, this application establishes an efficient task priority management and scheduling mechanism. Through a multi-dimensional priority evaluation system and combined with real-time resource usage monitoring, the system can accurately identify the urgency of tasks and reasonably allocate resources. In the case of resource competition, the response speed of high-priority tasks and the success rate of task scheduling are significantly improved.

[0056] Fourth, this application realizes a powerful fault tolerance and exception handling ability. Through a hierarchical fault recovery mechanism and a progressive recovery strategy from the container level to the Pod level, the average fault recovery time of the system is significantly shortened, and the service availability is significantly improved. The stability of task execution is greatly enhanced, effectively reducing the build failures caused by environmental problems.

[0057] Finally, this application significantly improves the scalability and maintainability of the system. Through the declarative API and the standardized Pod template definition, the system configuration and management become simple and efficient. Operations and maintenance personnel can easily add new build types and adjust resource policies, greatly shortening the average configuration time and significantly improving the maintainability of the system.

[0058] Through the comprehensive effect of the above technical effects, this application provides an efficient, reliable, and easily extensible solution for enterprise-level continuous integration systems, effectively supporting the requirements of rapid iteration and continuous delivery in modern software development.

[0059] The specification of this application records a large number of technical features, which are distributed in various technical solutions. If all possible combinations of technical features (i.e., technical solutions) of this application were to be listed, the specification would become overly lengthy. To avoid this problem, each of the technical features disclosed in the above-mentioned invention content of this application, each of the technical features disclosed in the following embodiments and examples, and each of the technical features disclosed in the drawings can be freely combined with each other to form various new technical solutions (all of these technical solutions are deemed to have been recorded in this specification), unless such a combination of technical features is technically infeasible. For example, in one example, features A + B + C are disclosed, and in another example, features A + B + D + E are disclosed. Features C and D are equivalent technical means that perform the same function, and only one of them can be used technically and it is impossible to use both simultaneously. Feature E can be combined with feature C technically. Then, the solution A + B + C + D should not be deemed to have been recorded due to technical infeasibility, while the solution A + B + C + E should be deemed to have been recorded. Brief Description of the Drawings

[0060] Figure 1 is a schematic flowchart of a Jenkins continuous integration method based on Kubernetes according to the first embodiment of this application

[0061] Figure 2 is a schematic structural diagram of a Jenkins continuous integration system based on Kubernetes according to the second embodiment of this application Detailed Embodiments

[0062] In the following description, many technical details are presented to enable the reader to better understand this application. However, those of ordinary skill in the art can understand that even without these technical details and various changes and modifications based on the following embodiments, the technical solutions claimed in this application can still be implemented.

[0063] Explanation of Some Concepts:

[0064] Jenkins: It is a popular open-source continuous integration tool in the industry, providing the ability to automate the building, testing, and deployment of applications. It adopts a Master-Slave distributed architecture, supports various types of build tasks and a rich plugin ecosystem, and is one of the core components of the DevOps toolchain.

[0065] Kubernetes: It is an open-source container orchestration platform used to automate the deployment, scaling, and management of containerized applications. It provides cloud-native capabilities such as declarative APIs, controller patterns, service discovery, load balancing, and self-healing, and is the de facto standard for current container orchestration technologies.

[0066] Continuous Integration (CI): It is a software development practice aimed at frequently merging developers' code changes into the main branch and automatically triggering tasks such as building and testing to detect and resolve integration issues as early as possible, ensuring code quality and deliverability.

[0067] Continuous Delivery (CD): Based on continuous integration, it automatically pushes the build artifacts to the pre-production environment for verification and enables one-click deployment to the production environment, thus shortening the software development-to-delivery cycle and achieving rapid business iteration.

[0068] Cloud Native: It is a method of building and running scalable applications based on the cloud computing environment, leveraging technologies such as containers, microservices, and DevOps. Cloud-native applications have characteristics such as automated management, elastic scalability, fault isolation, and declarative configuration, and can fully utilize the distributed advantages of the cloud platform.

[0069] Pod: It is the smallest deployable unit in Kubernetes, consisting of one or more containers. Containers in a Pod share the network namespace and storage volume, and are suitable for deploying tightly coupled application components. Pod is also the basis for Kubernetes scheduling, networking, storage, and other models.

[0070] Container: It is an operating system-level virtualization technology that achieves resource isolation and limitation through mechanisms such as namespaces and cgroups. Compared with virtual machines, containers are more lightweight and have a faster startup speed, making them suitable for deploying modern microservices applications. Docker is currently the most mainstream container engine.

[0071] Declarative API: It is an API paradigm based on programming with the desired state. Users declare the desired resource state, and the system continuously works through a control loop until the actual state is adjusted to the desired state. Compared with imperative APIs, declarative APIs are more concise, stable, and easier to manage automatically.

[0072] Service Governance: It is a technology for managing a loosely coupled service cluster. It includes mechanisms such as service registration and discovery, load balancing, circuit breaking and degradation, configuration management, and security authentication to ensure the reliability, high availability, and consistency of service calls and achieve quality assurance in a microservices architecture.

[0073] The following briefly describes some innovative points of this application:

[0074] Generally speaking, in view of the insufficient adaptability of traditional Jenkins in container cloud environments such as Kubernetes, this application proposes a method for dynamically scheduling and optimizing the Jenkins continuous integration pipeline based on the concept of cloud native.

[0075] The traditional Jenkins Master-Slave distributed build architecture could well support the continuous integration needs of enterprises in the era of monolithic applications. However, in the era of cloud native microservices, it faces several challenges: First, traditional Jenkins relies on a static proprietary build resource pool and is difficult to flexibly cope with the highly concurrent and peak-valley load changes in modern application development. Second, the execution node granularity in terms of VMs is relatively coarse, and it is difficult to achieve fine-grained optimization in terms of time and space scheduling, leaving great room for improvement in execution efficiency and resource utilization. Third, looking at the flow of build products in each stage of the pipeline, there is a lack of explicit modeling of the inherent dependencies between tasks, a lack of necessary input-output data interaction mechanisms between containers, and a separation between task orchestration and container orchestration. Finally, the scheduling strategy is based on static Stage definitions, lacking real-time feedback on task execution, and the pipeline parallelism in the time dimension is limited. Therefore, how to achieve the cross-generation upgrade of Jenkins from a traditional CI tool to a cloud native container scheduling platform has become a key technical problem that the industry urgently needs to solve.

[0076] The core idea of this application is to use Jenkins as the control plane of Kubernetes, containerize and dynamically schedule the execution engine, and perform container orchestration based on the dependencies between tasks. On the one hand, leveraging the elastic on-demand supply ability of cloud resources through the Kubernetes declarative API, it breaks through the shackles of the traditional Jenkins static resource pool. On the other hand, tasks in each stage of the pipeline such as compilation, testing, and deployment are atomically encapsulated in containers. Combining with the orchestration template of multi-container Pods, the transfer of build products between containers is realized by mounting shared storage volumes, thus establishing a direct mapping between task granularity and resource granularity. On this basis, this application further uses real-time container monitoring data to heuristically identify the critical path in the task dependency graph, dynamically adjust the concurrency of cross-stage containers, and minimize the end-to-end latency of the pipeline. In addition, combined with the time sensitivity of tasks, hierarchical batch processing of build requests is performed to balance scheduling saturation and business continuity in the time domain.

[0077] The technical solution of this application specifically includes the following steps: First, statelessize the Jenkins server and implement two-way authentication with the Kubernetes API Server to serve as the control plane of CI / CD. Second, abstract the commonalities of each stage of the pipeline, define the Kubernetes orchestration template for multi-container Pods, and aggregate the runtime environment facilities for building, testing, and deployment. Then, after Jenkins receives a build request, it sends a Pod creation instruction to Kubernetes. The scheduling optimizer monitors the execution status of tasks in each stage based on the container engine and uses the greedy algorithm to continuously eliminate scheduling delays. At the same time, it applies bypass optimization heuristics to minimize the resource occupancy of non-critical tasks. Finally, for the time sensitivity of tasks in each stage of the pipeline, a hierarchical queue model is used to distinguish task priorities, and combined with predictive resource allocation, balanced scheduling is performed within the batch window.

[0078] Based on the containerization of build tasks, this application extends the "directed acyclic graph" in traditional scheduling to a "directed skyline", and establishes a dynamic feedback mechanism between offline task orchestration and online container orchestration, simplifying the complexity of task orchestration. In response to the volatility of CI / CD loads, hierarchical batch processing in the time domain is introduced, and the trade-off between scheduling performance and business continuity is achieved through task saturation control, with self-adaptability to pursue dynamic balance under continuous feedback.

[0079] The innovations of this application are as follows: First, the decoupled integration of CI / CD task orchestration and cloud-native resource orchestration realizes the coordination between two-layer scheduling in "orchestration of orchestration". Second, the scheduler integrates task semantic information and runtime monitoring information, has the ability to decompose tasks at the task granularity and control containers at the container granularity, performs centralized scheduling on the critical path sensitive to latency, and performs distributed scheduling on non-critical tasks, mining the parallelism of the pipeline from two orthogonal dimensions of time and space. Third, the scheduler has self-adaptive ability, can dynamically adjust the weights of "task issuance frequency" and "time window batch processing" according to system saturation, and actively balance scheduling resources on the premise of ensuring business continuity to avoid local over-optimization.

[0080] In summary, starting from the design concept of cloud-native and using the declarative API as a bridge, this application deeply integrates the CI / CD process of traditional Jenkins with the elastic resource model of cloud computing, forming a highly intelligent new container scheduling mechanism. Through innovative technologies such as task semantic perception, multi-granularity collaborative scheduling, and batch processing balance, this mechanism has achieved a leapfrog performance improvement, providing a top-level design and integrated solution for continuous integration, continuous delivery, and continuous deployment of software development in the cloud-native era.

[0081] To make the objectives, technical solutions, and advantages of this application clearer, the following will further describe the implementation manners of this application in detail with reference to the accompanying drawings.

[0082] The first embodiment of this application relates to a Jenkins continuous integration method based on Kubernetes, and its process is as Figure 1 shown. This method includes the following steps:

[0083] Step 100: Deploy a Jenkins server in the Kubernetes cluster and complete the initialization configuration, so that it serves as the console of the cluster to manage the continuous integration pipeline and its tasks.

[0084] Step 200: After the Jenkins server receives a code submission or a manually triggered build signal, it sends a Pod creation request to the Kubernetes cluster based on a preset multi-container Pod template.

[0085] Step 300: After the Kubernetes cluster receives the Pod creation request, it creates a pipeline task Pod according to the multi-container Pod template, where the Pod contains multiple containers for executing different build tasks, and the build tasks include code compilation, unit testing, and deployment.

[0086] Step 400: After starting the Pod, the multiple containers in the Pod execute their respective build tasks in parallel, and the containers achieve data interaction and collaboration between tasks by sharing the network space and storage volume within the Pod.

[0087] Step 500: The Jenkins server monitors the task execution status of each container in the Pod in real time. When it detects that all build tasks are completed, it sends a Pod destruction command to the Kubernetes cluster to release the cluster resources; the Jenkins server repeats steps 200 to 500 according to the new build task requirements and the real-time load status of the cluster.

[0088] Specifically, the purpose of step 100 is to enable Jenkins to make full use of the container orchestration and resource management capabilities of Kubernetes as the control center of the entire CI / CD pipeline. Specifically, it is necessary to start the Jenkins service on one or more worker nodes of the Kubernetes cluster, and it can be deployed in a stateful or stateless manner. At the same time, it is also necessary to configure the necessary Kubernetes authentication information for Jenkins so that it can communicate and interact with the cluster through the Kubernetes API. In addition, Jenkins also needs to register some cloud proxy nodes, preset some resource quotas and default build parameters, etc., to prepare for the subsequent dynamic creation of Slave nodes.

[0089] Furthermore, in step 200, when Jenkins receives a Webhook notification of code submission or the user manually clicks the build button, it generates one or more creation requests for Kubernetes Pods according to the pre-defined build pipeline configuration. It should be noted that the specific configuration of each Pod is based on a preset multi-container Pod template, which defines the build environment, required computing resources of each container in the Pod, and the way they cooperate. Through this templated approach, a standardized and customizable build environment can be quickly created on demand, improving the flexibility of task scheduling.

[0090] In step 300, when the API Server of Kubernetes receives the request, it decides on which nodes to create the Pod based on the request parameters and the current resource status of the system, and sends the creation operation to the Kubelet component on the corresponding nodes. The Kubelet creates a Pod containing multiple containers according to the request parameters and the preset Pod template. These containers are responsible for different build tasks, such as code compilation, unit testing, application packaging, and deployment. By placing multiple containers in a single Pod, their work can be coordinated more closely, improving the execution efficiency of tasks.

[0091] In step 400, first of all, all containers within the same Pod are in a shared network namespace and can communicate directly via the localhost address as if they were on the same machine. Secondly, these containers can also mount shared storage volumes to share data and files between containers. For example, the code compilation container can output the compiled application package to the shared volume for use by subsequent test and deployment containers. Thirdly, configuration information can also be shared between containers through environment variables. This close cooperation method of multi-containers enables complex build tasks to be split into multiple atomic steps, each step can be executed and optimized by a dedicated container, and different containers can efficiently share data and status, thus greatly improving the execution efficiency and flexibility of tasks.

[0092] In step 500, the Jenkins server uses the Watch mechanism provided by Kubernetes to obtain the running status of each container in the Pod in real time, including metrics such as the container's log output, exit status code, resource usage, etc. Once it is found that a critical task container exits abnormally or fails to respond for a long time, Jenkins can respond in a timely manner, such as rescheduling the Pod, adjusting resource configuration, or triggering an alarm. When Jenkins monitors that all task containers have completed successfully, it will immediately send a request to Kubernetes to delete the Pod, releasing the cluster resources in a timely manner and avoiding unnecessary waste. At the same time, Jenkins will automatically repeat steps 200 to 500 according to new code submissions or changes in resource status, forming an automated and continuous software build and delivery loop, thus achieving true DevOps.

[0093] In summary, steps 100 to 500 describe a continuous integration practice based on Kubernetes and Jenkins. The core idea is to utilize Kubernetes' declarative API and multi-container orchestration capabilities to enable Jenkins to dynamically create, schedule, and monitor build tasks, while allowing different build steps to closely collaborate within the same Pod, thereby greatly improving the flexibility, scalability, and execution efficiency of the CI / CD pipeline. This method overcomes the limitations of the traditional Jenkins master-slave mode in aspects such as resource utilization, task scheduling, and environment consistency, providing new ideas and practical paradigms for continuous delivery practices in the cloud-native era.

[0094] Optionally, the Jenkins server is deployed as a stateful set or statelessly on one or more nodes of the Kubernetes cluster. The initialization configuration of the Jenkins server includes: configuring Kubernetes cluster authentication information, registering cloud proxy nodes, setting resource quota limits, and configuring default parameters for build tasks.

[0095] Specifically, first, the Jenkins server can be deployed in the Kubernetes cluster in a stateful or stateless manner. Stateful deployment means that Jenkins' data (such as build history, credentials, etc.) will be persistently stored in the cluster's storage resources, and even if the Jenkins server restarts or migrates, this data will not be lost. This deployment method is suitable for scenarios with high requirements for data reliability. Stateless deployment means that the Jenkins server will not save any state data in the cluster, and all data is temporary. If the Jenkins server restarts or migrates, this data will be lost. This deployment method is simpler and more flexible and is suitable for scenarios with low requirements for data reliability.

[0096] Secondly, when the Jenkins server starts, some initialization configurations are required, including:

[0097] 1) Configure Kubernetes cluster authentication information: Jenkins needs to communicate with the Kubernetes API server to create and manage the Pods for build tasks. For security reasons, the Kubernetes API server usually requires authentication and authorization. Therefore, it is necessary to configure the authentication credentials for connecting to the Kubernetes cluster in Jenkins, such as access tokens or client certificates, etc.

[0098] 2) Register cloud agent nodes: In Jenkins, the nodes that execute build tasks are called agent nodes. In a Kubernetes environment, these agent nodes are actually dynamically created Pods. To enable Jenkins to dynamically create agent nodes, it is necessary to register a Kubernetes cloud in Jenkins and configure the corresponding Pod templates and labels.

[0099] 3) Set resource quota limits: To prevent the Pods of build tasks created by Jenkins from occupying too many cluster resources and affecting other applications, it is necessary to set resource quota limits for build tasks in Jenkins, such as CPU, memory, disk, etc. These limits can be configured in the Pod template.

[0100] 4) Configure the default parameters of build tasks: In Jenkins, some default parameters can be configured for build tasks, such as the code repository address, build trigger, timeout, etc. These parameters can be used as default values when creating build tasks, reducing the workload of repeated configuration.

[0101] Through the above initialization configurations, the Jenkins server can be seamlessly integrated with the Kubernetes cluster, dynamically create and manage the Pods for build tasks, and execute the CI / CD pipeline.

[0102] Optionally, the multi-container Pod template includes: configuration information of a base build container, a test container, and a deployment container. Each container configuration information includes an image address, resource limits, environment variables, and storage volume mount points, where the image address is an identifier for the storage location of the container image.

[0103] Specifically, in Kubernetes, a Pod is the smallest scheduling unit and can contain one or more containers. In the CI / CD scenario of Jenkins, a build task usually requires multiple steps, such as code compilation, unit testing, application packaging, deployment, etc. To execute these steps in the same Pod and improve task efficiency and data sharing, a multi-container Pod template can be used.

[0104] A typical multi-container Pod template usually includes the following containers:

[0105] 1) Base build container: This container provides the basic environment for executing build tasks, such as JDK, Maven, Git, etc. It is usually a general image containing necessary tools and libraries.

[0106] 2) Test container: This container is mainly used to execute tasks such as unit testing and integration testing, and may require some special test frameworks and libraries, such as JUnit, Selenium, etc.

[0107] 3) Deployment container: This container is mainly used to deploy the build artifacts to the target environment, such as application servers, Docker repositories, etc. It may require some special deployment tools, such as Ansible, Docker CLI, etc.

[0108] For each container, detailed configuration is required in the Pod template, mainly including:

[0109] 1) Image address: Specify the image used by the container, usually a public or private Docker image repository address, such as Docker Hub, Harbor, etc.

[0110] 2) Resource limits: Specify the upper limit of computing resources that the container can use, such as CPU, memory, etc., to prevent a single container from occupying too many resources.

[0111] 3) Environment variables: Specify the environment variables during container runtime, such as build parameters, credentials, etc.

[0112] 4) Storage volume mounts: Specify the storage volumes mounted by the container for sharing data between containers, such as source code, build artifacts, etc.

[0113] By configuring each container in detail in the Pod template, a complete, data-sharing, and resource-isolated build environment can be achieved, improving the efficiency and reliability of build tasks.

[0114] The above is a detailed explanation of the Jenkins server deployment method, initialization configuration, and multi-container Pod template configuration. These optional steps provide best practices and considerations for deploying and configuring Jenkins on Kubernetes, helping to further improve the flexibility and scalability of the CI / CD pipeline.

[0115] Optionally, the build tasks include one or more of code compilation, unit testing, static code scanning, Docker image building and pushing, application configuration management, and integration testing, and these tasks can be executed in the order of a predefined or dynamically generated pipeline.

[0116] Specifically, in an exemplary CI / CD pipeline, one build can include multiple tasks, each task completing a specific function, and multiple tasks are executed in a certain order in sequence, ultimately completing the entire build process.

[0117] The following describes the build task types by way of example:

[0118] Code compilation: This task mainly compiles the source code into an executable binary file or library file. For different programming languages, different compilation tools may be used, such as javac for Java and g++ for C++. The compilation process usually also includes subtasks such as code style checking and syntax checking.

[0119] Unit testing: This task mainly tests the smallest testable units of the code to verify the correctness of the code. Unit tests are usually written by developers and automatically executed by test frameworks, such as JUnit for Java and unittest for Python. Unit tests can quickly discover bugs in the code and improve code quality.

[0120] Static code scanning: This task mainly performs static analysis on the code to discover potential problems in the code, such as security vulnerabilities, performance bottlenecks, and code specification violations. Optionally, static code scanning tools include SonarQube, FindBugs, etc. Static code scanning can help developers write more secure and higher-quality code.

[0121] Docker image building and pushing: This task mainly packages the application into a Docker image and pushes it to a Docker repository for subsequent deployment. Docker images are a lightweight, portable, and self-contained application packaging method, which is very suitable for modern microservice architectures. Optionally, Docker image building tools include Docker Build, Jib, etc.

[0122] Application Configuration Management: This task mainly manages the application's configuration files, such as database connection strings, API keys, etc. In different environments (development, testing, production), the application's configuration may vary. Configuration management tools can help us synchronize and manage these configurations across different environments, such as Ansible, Chef, etc.

[0123] Integration Testing: This task mainly conducts end-to-end testing on the various modules of the application and their interactions to verify the correctness of the entire system. Integration testing is usually carried out in an environment similar to the production environment, requiring the deployment of the complete application and simulating real user operations. Integration testing can uncover problems that are difficult to detect by unit testing, such as incompatible interfaces between modules, performance bottlenecks, etc.

[0124] The above are the specific build task types available. In an actual CI / CD pipeline, one or more task types can be selected according to the project's requirements.

[0125] On the other hand, the execution order of tasks can be predefined or dynamically generated.

[0126] Specifically, the predefined order means that when creating a Jenkins build task, the execution order of each task is explicitly specified, such as first performing code compilation, then unit testing, and finally building and pushing the Docker image. This method is relatively simple and intuitive and is suitable for scenarios where the pipeline structure is relatively fixed and changes little.

[0127] The dynamically generated order means that the execution order of tasks is determined dynamically according to certain conditions, such as only executing subsequent tasks after unit testing passes, or selecting to execute some tasks according to the content of code changes. This method is more flexible, can dynamically adjust the pipeline according to the actual situation, reduce unnecessary task execution, and improve the build efficiency. Optionally, the methods for dynamically generating the order include:

[0128] Conditional Execution: Determine whether to execute subsequent tasks according to a certain condition (such as unit test results, code branches, etc.).

[0129] Parallel Execution: Execute independent tasks (such as unit testing and static code scanning) in parallel to improve efficiency.

[0130] Matrix Execution: Execute tasks in parallel for different environments (such as different operating systems, different programming language versions) to improve coverage.

[0131] In summary, by reasonably selecting the build task types and execution order, an efficient, reliable, and flexible CI / CD pipeline can be constructed to improve the quality and speed of software delivery.

[0132] Optionally, the containers within the Pod achieve coordination in the following ways: sharing the network namespace of the Pod to enable localhost communication, sharing persistent storage volumes to achieve data exchange, sharing configuration information through environment variables, and achieving inter-process communication through Socket files or port mapping.

[0133] The following specifically describes how multiple containers within the same Pod work together.

[0134] In Kubernetes, a Pod is the smallest scheduling unit. The containers within a Pod share some resources, such as network, storage, etc., which provides convenient conditions for container coordination. Optionally, the main ways of container coordination within a Pod are as follows:

[0135] 1) Sharing the network namespace of the Pod

[0136] In Kubernetes, each Pod has its own independent network namespace, and all containers within the Pod share this network namespace. This means that the containers within the Pod can access each other through the localhost address and port number, just as if they were on the same machine. This network model greatly simplifies communication between containers. Containers do not need to know the IP address of the other party, only the port number of the other party to communicate.

[0137] For example, assume there are two containers within a Pod, one is a Web application container and the other is a database container. The Web application container listens on port 8080, and the database container listens on port 3306. Then the Web application container can connect to the database container through the URL jdbc:mysql: / / localhost:3306 without knowing the actual IP address of the database container.

[0138] 2) Sharing persistent storage volumes

[0139] In Kubernetes, persistent storage volumes such as local disks, NFS, cloud storage, etc. can be mounted for a Pod. All containers within the Pod can share access to these storage volumes, thus achieving data sharing and exchange.

[0140] For example, assume there are two containers within a Pod, one is a Web application container and the other is a file upload processing container. The Web application container writes the files uploaded by users to a shared storage volume. The file upload processing container reads the files from this shared storage volume for processing, and after processing, writes the results back to this shared storage volume. The Web application container reads the processing results from the shared storage volume and returns them to the user. Through the shared storage volume, the two containers can easily exchange data files.

[0141] 3) Sharing configuration information through environment variables

[0142] In Kubernetes, environment variables can be set for the containers within a Pod, and all containers can read these environment variables. Therefore, some configuration information, such as the database connection URL, API keys, etc., can be shared through environment variables.

[0143] For example, assume there are two containers within a Pod, one is a web application container and the other is a database migration container. An environment variable DB_URL can be set in the Pod's configuration file, pointing to the database connection URL. Both the web application container and the database migration container can read this environment variable, thus knowing how to connect to the database without hard - coding the database connection URL in the code.

[0144] 4) Achieving inter - process communication through socket files or port mapping

[0145] In addition to the above three methods, the containers within a Pod can also use socket files or port mapping to achieve more flexible inter - process communication.

[0146] A socket file is a special file that can be used for inter - process communication. Containers within a Pod can share socket files through a shared storage volume to achieve inter - process communication. For example, container A creates a socket file and listens for requests; container B sends requests to container A by writing to this socket file, container A processes the requests and writes the results back to the socket file, and container B reads the response results.

[0147] Port mapping means mapping the internal port of a container to the port of the Pod, and then accessing the container through the IP address and port number of the Pod. For example, if a web application container listens on port 8080, this port can be mapped to port 80 of the Pod in the Pod configuration file, so that the web application can be accessed through the IP address and port 80 of the Pod.

[0148] Through the above four methods, the containers within a Pod can easily achieve collaborative work, share data and configurations, simplify the interaction between containers, and improve the maintainability and scalability of the application. This is also a major advantage of the Kubernetes multi - container Pod model.

[0149] In summary, the multi-container model of Kubernetes Pods and the coordination mechanism between containers provide good support for implementing complex distributed applications and also provide infrastructure support for the coordinated execution of build, test, and deployment tasks in the CI / CD pipeline. By reasonably leveraging these features, an efficient, reliable, and flexible CI / CD system can be built.

[0150] Optionally, the Jenkins server receives trigger requests through the WebHook interface or a predefined API interface; and dynamically adjusts the Pod creation and scheduling policies based on the following factors:

[0151] · The resource utilization rate of cluster nodes;

[0152] · The number of queued tasks;

[0153] · The average task execution time statistically calculated from historical build data;

[0154] · The task priority or task deadline specified by the user;

[0155] · Node affinity and taint tolerance settings.

[0156] The following details how the Jenkins server receives trigger requests for build tasks and some factors to consider when creating and scheduling task Pods to better utilize cluster resources and improve task execution efficiency.

[0157] 1) Trigger methods for build tasks:

[0158] The Jenkins server can receive trigger requests for build tasks in two ways:

[0159] WebHook interface: This is an event-driven trigger method. When an event occurs (such as code commit, Pull Request, timer, etc.), the event source sends an HTTP request to the WebHook interface of the Jenkins server to notify Jenkins to trigger the corresponding build task. For example, when a developer commits code to the Git repository, the Git server can send a POST request to the WebHook interface of Jenkins, carrying metadata of this commit (such as branch, committer, commit message, etc.). After Jenkins receives the request, it can decide whether to trigger the build task based on the request parameters. WebHook is a loosely coupled trigger method, and there is no direct dependency between Jenkins and the event source.

[0160] Predefined API Interfaces: This is an explicit triggering method. Jenkins provides a set of REST API interfaces, and external systems can trigger build tasks by calling these API interfaces. For example, a specific build task can be triggered by sending a POST request to the API interface / job / {jobName} / build. API interfaces are generally used for integration with other systems, such as automated testing platforms, release management systems, etc.

[0161] 2) Dynamically adjust the Pod creation and scheduling policies

[0162] When creating and scheduling Jenkins task Pods in a Kubernetes cluster, the following factors need to be considered to better utilize the cluster resources and improve the execution efficiency of tasks:

[0163] Resource utilization of cluster nodes: When selecting nodes to run task Pods, nodes with lower resource utilization should be given priority to avoid the situation where individual nodes are overloaded while other nodes are idle. The Metrics Server component of Kubernetes can be used to monitor the usage of resources such as CPU and memory of each node in real time, and the Jenkins scheduler can select appropriate nodes based on this metric data. For example, nodeSelector or nodeAffinity can be set for task Pods to make them scheduled to nodes with low resource utilization as much as possible.

[0164] Number of queued tasks: If there are a large number of build tasks currently queued for execution and the cluster resources are relatively tight, then the priority of new tasks can be considered to be reduced, or the creation of new task Pods can be delayed to avoid worsening the load situation of the cluster. The Jenkins scheduler can dynamically adjust the priority and creation policy of tasks based on the number of currently queued tasks and the load situation of the cluster.

[0165] Average task execution time statistically analyzed from historical build data: Based on the average task execution time statistically analyzed from historical build data, the execution duration of new tasks can be estimated, so as to apply for appropriate resources (such as CPU, memory, timeout, etc.) for task Pods. For example, if the average execution time of a task is 30 minutes, then a 30-minute timeout can be applied for its Pod to avoid the Pod occupying resources for a long time. The Metrics plugin of Jenkins can collect historical execution data of build tasks and statistically analyze the average execution time.

[0166] User-specified task priority or deadline: When triggering a build task, the user can specify the task priority (such as high, medium, low) or the expected completion time (such as to be completed before 5 pm this afternoon). The Jenkins scheduler should respect the user's settings and give more resources and a higher scheduling priority to high-priority or upcoming tasks. For example, the priorityClassName can be set for the task Pod to enable the Kubernetes priority scheduler to give them a higher priority.

[0167] Node affinity and taint toleration settings: Node affinity and tolerations are Kubernetes scheduling policies used to control the attraction and repulsion between Pods and nodes. For example, nodeAffinity can be set for the task Pods to make them preferably scheduled to nodes with certain labels (such as nodes configured with high-performance CPUs); or tolerations can be set to allow them to be scheduled to nodes with certain taints (such as nodes configured with GPUs). The Jenkins scheduler should utilize these scheduling policies to schedule the task Pods to the most suitable nodes for execution.

[0168] In summary, it is necessary to dynamically select the best strategy according to the characteristics of the task, the user's needs, the real-time state of the cluster, etc., to enable the task Pods to execute efficiently and improve the utilization rate of cluster resources. This requires the close cooperation of the Jenkins scheduler and the Kubernetes scheduler to jointly complete the scheduling and execution of tasks.

[0169] Optionally, the Jenkins server monitors the Pod status through the Kubernetes Watch mechanism, including:

[0170] · Polling container logs;

[0171] · Listening for the container exit status code;

[0172] · Collecting resource usage metrics such as CPU, memory, network, and disk I / O;

[0173] · Detecting abnormal container behaviors;

[0174] · Recording the monitoring data into the build history.

[0175] The following specifically describes how the Jenkins server monitors the running status of task Pods in the Kubernetes cluster, including logs, exit status, resource usage, etc., so as to keep track of the execution progress and results of tasks in real time and be able to detect and handle abnormal situations in a timely manner. Optionally, several main ways for the Jenkins server to monitor Pod status are as follows:

[0176] Poll container logs

[0177] In Kubernetes, the standard output (stdout) and standard error (stderr) of each container are redirected to the container's log file. The Jenkins server can poll the container logs through the Kubernetes API interface to obtain the output information of the container in real time. Specifically, Jenkins can call the API interface / api / v1 / namespaces / {namespace} / pods / {name} / log, and by passing in the name of the Pod and the name of the container, it can obtain the container's logs.

[0178] By polling the container logs, Jenkins can understand the execution progress of the task in real time, such as the start and end of build steps, the execution results of test cases, error and exception information, etc. Jenkins can also parse the log information and display it on the page of the build task, or trigger certain actions according to the log content, such as sending notifications, aborting the build, etc.

[0179] Listen for container exit status code

[0180] When a container finishes execution, it will exit and return a status code. A status code of 0 indicates that the container exited normally, and a non-zero status code indicates that the container exited abnormally. The Jenkins server can listen for the container's exit status code through the Kubernetes API interface to determine whether the task was executed successfully. Specifically, Jenkins can call the API interface / api / v1 / watch / namespaces / {namespace} / pods / {name}, and by passing in the name of the Pod, it can listen for the status change events of the Pod in real time, including the container's exit event.

[0181] By listening for the container exit status code, Jenkins can promptly learn the execution results of the task, such as whether the build was successful, whether the tests passed, etc. If the container exits abnormally, Jenkins can also judge the possible reasons based on the status code, such as compilation errors, test failures, timeout exits, etc., and take corresponding measures, such as sending alerts, retrying the task, etc.

[0182] Collect resource usage metrics

[0183] During the task execution, Jenkins also needs to monitor the resource usage of the task Pod, such as metrics like CPU, memory, network, disk I / O, etc., in order to understand the consumption of cluster resources by the task, and then optimize the allocation and use of resources. Jenkins can collect the resource usage metrics of Pods through the Metrics Server component of Kubernetes. Metrics Server runs in the form of a DaemonSet on each node of the cluster, regularly obtains the resource usage data of Pods from Kubelet, and then aggregates these data together, exposing an API interface for querying.

[0184] Jenkins can obtain the resource usage metrics such as CPU and memory of a certain Pod by calling the API interface of Metrics Server, such as / apis / metrics.k8s.io / v1beta1 / namespaces / {namespace} / pods / {name}. Jenkins can also record these metric data into the build task, generate a resource usage report, or dynamically adjust the resource requests and limits of Pods according to the resource usage situation.

[0185] Detect abnormal container behaviors

[0186] In addition to the above optional monitoring metrics, Jenkins also needs to be able to detect abnormal behaviors of containers, such as containers restarting repeatedly, container processes becoming zombie, container memory leaks, etc., in order to discover and handle problems in a timely manner and ensure the stable execution of tasks. Jenkins can detect abnormal behaviors of containers by analyzing Kubernetes Events, the resource usage curves of containers, error keywords in container logs, etc.

[0187] For example, if a container restarts frequently, Kubernetes will generate multiple Events of Pod restarts. Jenkins can discover the restart problem of the container by listening to and analyzing these events. Another example is that if the memory usage curve of a container shows a continuous upward trend and finally leads to the container being terminated by OOM (Out of Memory), Jenkins can discover the possible memory leak problem by analyzing the memory usage curve of the container. Another example is that if certain error keywords, such as "OutOfMemoryError", "NullPointerException", etc., appear in the container log, Jenkins can quickly locate the code-level error by searching for these keywords.

[0188] Record monitoring data

[0189] After the Jenkins server monitors various status and metric data of the Pods, it needs to record this data, associate it with the corresponding build tasks, and form a complete build history. In this way, users can view the detailed execution status of each build task on the Jenkins UI interface, including log output, resource usage, test reports, etc.

[0190] In addition, Jenkins can also perform statistics and analysis on the monitoring data, generate some trend charts and statistical reports, such as build success rate trends, average build duration, resource usage percentage, etc., to help users evaluate and optimize the CI / CD process. Jenkins can also export the monitoring data to third-party systems, such as time series databases, log analysis platforms, etc., for further analysis and visualization.

[0191] Generally speaking, monitoring is an important part of the CI / CD process, which can timely discover and solve problems, and ensure the stable execution of build tasks and delivery quality. The Watch mechanism and rich API interfaces provided by Kubernetes provide good support for Jenkins to achieve comprehensive monitoring of Pods.

[0192] Optionally, perform priority classification management on build tasks, including:

[0193] · Set priority tags for different types of tasks;

[0194] · Adjust the priority in real time according to task type, resource status and time constraints;

[0195] · Dynamically adjust the resource quota of Pods according to task priority;

[0196] · Support the resource preemption mechanism for high-priority tasks;

[0197] · Implement a fault tolerance mechanism for automatic task failure retry and Pod rescheduling.

[0198] The following details how to perform priority classification management on Jenkins build tasks to preferentially ensure the execution of important tasks and improve the overall build efficiency in the case of limited resources. Optionally, several main strategies for priority classification management are as follows:

[0199] 1) Set priority tags for different types of tasks

[0200] In Jenkins, different types of build tasks can be defined, such as feature development, defect fixing, performance optimization, etc. Different types of tasks may have different requirements for delivery time and resource consumption, so different priorities need to be set. Jenkins can set a priority label for each task type, such as high, medium, low, etc., to indicate the importance of tasks of that type.

[0201] When multiple tasks trigger builds simultaneously, the Jenkins scheduler can determine the execution order of tasks based on the priority labels of the tasks. Tasks with higher priorities will be scheduled for execution first. This can prevent some low-priority tasks from occupying too many resources and affecting the execution of high-priority tasks.

[0202] 2) Adjust priorities in real time according to task types, resource status, and time constraints

[0203] The priorities of tasks are not fixed but need to be adjusted dynamically according to the actual situation. For example, in the later stage of a project, the priority of defect-fixing tasks may need to be increased, while the priority of feature-development tasks may need to be decreased. Another example is that in a situation of resource shortage, the priorities may need to be further refined and tasks divided into multiple levels.

[0204] Jenkins can use some rule engines or machine learning algorithms to calculate the priorities of tasks in real time based on factors such as task types, resource status, and time constraints. For example, a weight can be set for each factor, and then they can be combined to calculate a priority score. When a certain factor changes, the priority score will also be adjusted accordingly, thus dynamically changing the priorities of tasks.

[0205] 3) Dynamically adjust the resource quotas of Pods according to task priorities

[0206] In Kubernetes, each Pod needs to request a certain amount of resource quotas, such as CPU, memory, etc. For tasks with different priorities, their resource requirements may also be different. For example, high-priority tasks may need more CPU and memory to speed up the build process, while low-priority tasks can appropriately reduce the resource quotas to save cluster resources.

[0207] Jenkins can dynamically adjust the resource quotas of its corresponding Pods according to the priority of tasks. Specifically, when creating a Pod, different resource requests and limits are set according to the task priority. For example, a high-priority task can set the CPU request to 2 cores and the memory request to 4GB; while a low-priority task can set the CPU request to 0.5 cores and the memory request to 1GB. This allows high-priority tasks to obtain more resource guarantees while also limiting the resource consumption of low-priority tasks.

[0208] 4) Support for a resource preemption mechanism for high-priority tasks

[0209] In some cases, even if resource quotas are reserved for high-priority tasks, there may be insufficient resource competition, resulting in high-priority tasks not being scheduled and executed in a timely manner. In such cases, a resource preemption mechanism is needed to allow high-priority tasks to use resources first and, if necessary, terminate or evict low-priority tasks.

[0210] Kubernetes itself supports a priority-based resource preemption mechanism (Pod PriorityPreemption). Specifically, a priority class is assigned to each Pod, and the priority class defines the priority value of the Pod. When cluster resources are insufficient, the Kubernetes scheduler will attempt to evict low-priority Pods to free up resources for high-priority Pods. The evicted Pods will be rescheduled to other available nodes.

[0211] Jenkins can utilize this mechanism to assign a higher priority class to the Pods created for high-priority tasks, enabling them to obtain resources first and allowing low-priority Pods to be evicted. This ensures the timely execution of high-priority tasks without overly affecting low-priority tasks, achieving a dynamic balance.

[0212] 5) Implement a fault tolerance mechanism for automatic task failure retry and Pod rescheduling

[0213] During the execution of a build task, various exceptions and failures may occur, such as code compilation errors, test case failures, network timeouts, etc., resulting in the failure of the task execution. To improve the stability and success rate of the build, a fault tolerance mechanism is needed that can automatically retry failed tasks or reschedule the tasks to other available nodes for execution.

[0214] Jenkins can configure a failure retry policy for each build task, such as the number of retries and the retry interval. When a task fails to execute, Jenkins will automatically trigger a retry according to the retry policy until the task is successfully executed or the maximum number of retries is reached. This can automatically fix some temporary or intermittent failures and improve the success rate of builds.

[0215] In addition, Jenkins can also monitor abnormal events of Pods, such as a Pod being in the Pending state all the time, a Pod being evicted, or a failure of the node where the Pod is located. When these abnormal events occur, Jenkins can automatically reschedule the affected task Pods to other available nodes for execution without manual intervention. This can improve the fault tolerance and availability of build tasks.

[0216] Generally speaking, hierarchical priority management can reasonably allocate resources in the case of limited resources, give priority to ensuring the execution of critical tasks, and improve the overall build efficiency and delivery quality. Some native mechanisms provided by Kubernetes and Jenkins, such as priority scheduling, resource quotas, retries, and rescheduling, provide good support for implementing hierarchical priority management.

[0217] Optionally, the following mechanisms are used to ensure system security and efficient resource utilization:

[0218] · Configure an independent service account and network policy for each Pod;

[0219] · Encrypt and store access credentials, which include code repository credentials, Docker image repository passwords, and cloud service API keys;

[0220] · Automatically trigger resource recycling according to a preset cleanup policy;

[0221] Save the build artifacts and logs after the task is completed and release the relevant Kubernetes cluster resources.

[0222] The following details how to ensure system security and efficient resource utilization in the Jenkins on Kubernetes system. The optional specific methods are as follows:

[0223] 1) Configure an independent service account and network policy for each Pod

[0224] In Kubernetes, a ServiceAccount is a special type of account used to provide authentication and authorization for Pods. Each Pod can be associated with a ServiceAccount, and the containers within the Pod can use this ServiceAccount to access the Kubernetes API and other services. By default, all Pods share a ServiceAccount named "default", which usually has relatively high permissions.

[0225] To enhance the security of the system, an independent ServiceAccount can be configured for each Jenkins task Pod, granting it only the minimum necessary permissions. For example, a build task Pod only requires permissions to read the code repository and push images, without the need to modify cluster resources. This can prevent Pods from accessing resources with excessive privileges. Even if a Pod is compromised, the potential damage can be minimized.

[0226] In addition, an independent NetworkPolicy can be configured for each Pod to restrict network traffic between Pods. For example, a network policy can be configured to only allow the Jenkins server to access specific ports of the proxy Pod, while prohibiting proxy Pods from accessing each other. This can prevent malicious containers from scanning and attacking other containers, enhancing the network security of the system.

[0227] 2) Encrypt and store access credentials

[0228] In the CI / CD process, various access credentials are often required, such as the username and password for the code repository, the login token for the Docker image repository, and the API keys for cloud services. These credentials are usually highly sensitive and pose a significant risk. Once leaked, they can lead to serious security incidents, such as code leakage, image contamination, and abuse of cloud resources.

[0229] To protect these access credentials, they should not be stored directly in plain text in the Jenkins configuration file or environment variables. Instead, they should be encrypted and stored using some secure secret management solutions. For example, Kubernetes' Secret resource can be used to store the credentials. Secrets store data in ciphertext, and the plaintext data can only be obtained through API calls. When creating a task Pod, Jenkins can inject the Secret into the Pod in the form of an environment variable or a Volume for use by the containers.

[0230] In addition, some specialized Secret management tools can also be used, such as HashiCorp Vault, AWS SecretsManager, etc. They provide more complete functions for key management, rotation, auditing, etc. Jenkins can be integrated with these tools through plugins or API calls to achieve the secure storage and use of credentials.

[0231] 3) Automatically trigger resource recovery according to the preset cleanup policy

[0232] In a continuous integration system, tasks such as building, testing, and deployment are continuously executed, generating a large amount of intermediate data and products, such as code repository copies, build logs, test reports, artifact packages, etc. If these data and products are not cleaned up in a timely manner, they will occupy a large amount of storage space and computing resources, affecting the performance and stability of the system.

[0233] Therefore, it is necessary to automatically trigger the recovery and release of resources according to a certain cleanup policy. Optionally, the cleanup policy includes:

[0234] Time-based cleanup: Set a retention time, such as 30 days, and clean up data and products that exceed the retention time.

[0235] Space-based cleanup: Set a space quota, such as 10GB. When the total size of data and products exceeds the quota, trigger cleanup and preferentially clean up older data.

[0236] Version-based cleanup: Set a maximum number of versions, such as 10, and only retain the latest N versions of data and products, and clean up the rest.

[0237] Jenkins can achieve automatic cleanup of build data and products through some plugins or scripts. For example, the "Workspace Cleanup" plugin can be used to regularly clean up files in the Jenkins workspace according to different rules and policies. It is also possible to manually delete some expired data and products in the pipeline script.

[0238] Kubernetes also provides some native cleanup mechanisms, such as the container's livenessProbe and startupProbe, the Pod's restartPolicy, the Job's.spec.ttlSecondsAfterFinished, etc., which can automatically restart or destroy abnormal containers and Pods and reclaim the resources they occupy.

[0239] 4) Save the build products and logs after the task is completed and release the relevant resources

[0240] After the build task is completed, on the one hand, some key data generated during the build process, such as artifact packages, test reports, code coverage data, etc., need to be saved for subsequent analysis and auditing. On the other hand, the resources occupied by the task, such as code copies, build environments, execution nodes, etc., need to be released as soon as possible for other tasks to use.

[0241] For build artifacts, they can be archived in an artifact repository such as Artifactory, Nexus, etc., or uploaded to an object storage such as Amazon S3, Google Cloud Storage, etc. Jenkins can automatically push the build artifacts to these repositories or storages through plugins or scripts and generate a unique identifier such as a version number, build number, etc., for subsequent tracking and use.

[0242] For build logs, they can be saved to a log aggregation platform such as ELK, Splunk, etc., or saved to a persistent storage such as NFS, cloud disks, etc. Jenkins can collect and transmit the build logs to these platforms or storages in real time through plugins or scripts and establish some indexes and tags for subsequent search and analysis.

[0243] When the build task is completed, Jenkins needs to clean up and release the Kubernetes resources related to the task, such as Pods, PVCs, ConfigMaps, etc., to avoid resource waste and leakage. An optional way is to set a restart policy of.spec.restartPolicy = Never in the Pod template of the task. In this way, when all containers in the Pod exit normally, the Pod will automatically enter the "Succeeded" or "Failed" state and will no longer occupy node resources. Jenkins can also explicitly delete the task Pod in the post section of the pipeline script or use a TTL controller to automatically clean up expired Pods.

[0244] In short, in terms of system security and resource utilization, Jenkins needs to take some necessary measures, such as the principle of least privilege, network isolation, credential protection, regular cleaning, etc., to ensure the stability, reliability, and efficiency of the system. At the same time, it is also necessary to make full use of the security and resource management mechanisms provided by the Kubernetes platform to complement Jenkins and jointly build a secure and efficient CI / CD environment.

[0245] Optionally, the method of this embodiment further includes the following steps:

[0246] When the Jenkins server sends a Pod creation request to the Kubernetes cluster, the multi-container Pod template is dynamically adjusted based on historical build task data, real-time performance metrics, and metadata carried in build signals. The adjustments include: analyzing the resource consumption curve of historical build tasks and the real-time resource usage trend, predicting the resource demand curve for the current build task, and dividing it into multiple stages, each corresponding to a different resource demand intensity; based on the resource demand stages, selecting the most matching template from a preset set of multi-container Pod templates to generate a customized multi-container Pod template; optimizing the container startup order according to the task dependency graph to match resource scheduling with the task execution order; allocating elastic resource quotas for high-priority task containers and introducing a delayed scheduling strategy for low-priority task containers;

[0247] After the Pod starts, the resource usage data, task execution progress, and exception events of each container are collected in real time and the data is fed back to the Jenkins server. The feedback data is used for: dynamically adjusting the resource allocation strategy for unexecuted task containers; triggering the resource reclamation or task suspension strategy for low-priority containers when resource competition occurs for high-priority tasks; re-optimizing the container execution order based on real-time performance data, where the real-time performance data includes network latency and resource consumption trends;

[0248] Before the Pod is destroyed, a task execution report is generated based on the monitoring data. The report includes resource usage trend analysis, exception log analysis, and task execution path optimization suggestions, and the report is stored in the build history database for subsequent task scheduling and template update.

[0249] Specifically, the dynamic adjustment of the multi-container Pod template combines historical build task data and real-time performance metrics. Through this combination, the resource requirements of the current build task can be accurately predicted. This prediction is based on a dual analysis of historical patterns and the current system state, which can significantly improve the accuracy of resource allocation. The resource demand curve is the trend of resource consumption of a task over time during the build process. By dividing it into multiple stages, the intensity of resource requirements at different stages of the task can be identified. For example, the code compilation stage may require higher CPU resources, while the testing stage may require more I / O resources. By dividing the stages, more reasonable resource quotas can be allocated for each stage. According to the resource demand stage, the most suitable template is selected from a preset set of Pod templates, and a customized Pod template is generated. In this way, a high degree of matching between task requirements and resource allocation is achieved, effectively avoiding resource waste or resource shortage. The task dependency graph clarifies the order and dependencies between build tasks. For example, the unit test container must wait for the code compilation container to complete before it can start. By optimizing the start order, the efficient use of resources can be ensured, and the waiting time for task execution can be reduced. Elastic resource quotas are allocated to high-priority task containers to ensure that their resource requirements can be met in a timely manner; for low-priority task containers, a delayed scheduling strategy is introduced to avoid occupying critical resources. This differential processing mechanism can prioritize the execution of critical tasks when resources are limited.

[0250] In terms of the real-time acquisition and feedback mechanism, after the Pod is started, the system immediately collects the resource usage data (such as CPU, memory, network bandwidth, etc.) of each container and the task execution progress. These data can reflect the execution status of the current task and provide a reliable basis for subsequent adjustments. The real-time feedback of resource data can be used to dynamically adjust the resource allocation of unexecuted task containers. For example, when a certain task container finds that its execution efficiency is low, its resource quota can be dynamically increased, or the resource competition can be reduced by adjusting the task scheduling order. When resource competition occurs for high-priority tasks, by triggering the resource recycling or suspension strategy for low-priority tasks, resources can be released in a timely manner to ensure the smooth completion of critical tasks. If the network latency increases or the resource consumption trend changes, the system can re-optimize the execution order of the containers based on the real-time performance data to further improve the task execution efficiency.

[0251] The task execution report includes resource usage trend analysis, exception log analysis, and suggestions for optimizing the task execution path. Resource usage trend analysis can help identify bottlenecks in resource allocation; exception log analysis helps quickly locate problems; and suggestions for optimizing the task execution path provide a reference for subsequent build tasks. After storing the report in the build history database, it can provide data support for future task scheduling and Pod template updates, forming a continuously optimized closed-loop mechanism.

[0252] There is a close collaborative relationship among the above-mentioned technical features. Dynamically adjusting the Pod template is the starting point for optimizing the build task. By predicting the resource requirements of the current task based on historical data and real-time performance metrics, a customized template is generated and the task dependencies are optimized. During the task execution process, the real-time feedback mechanism can collect resource usage data and task progress information, providing a basis for dynamically adjusting the resource allocation of unexecuted tasks. This synergy ensures the accuracy and real-time nature of resource allocation, significantly improving the task execution efficiency. By dividing the resource demand curve into multiple stages, resources can be allocated more precisely, and combined with the differential processing mechanism for high- and low-priority tasks, the needs of critical tasks are prioritized under limited resources, while the execution of low-priority tasks is postponed or restricted. This collaborative mechanism can effectively avoid task delays caused by resource competition and improve the overall throughput of the system. Real-time performance data can reflect the current state of the system. By dynamically adjusting the execution order of containers, the resource scheduling is made more compatible with the task dependencies. This optimization not only reduces the task waiting time but also decreases the impact of resource competition on task performance. The generation and storage of task execution reports provide key data support for subsequent tasks. For example, by analyzing historical reports, common problems in resource allocation can be identified, and based on this, the Pod template can be updated or the scheduling strategy can be optimized. After the reports are stored in the historical database, it lays the foundation for the long-term optimization of the system, forming a complete closed-loop from resource prediction, task execution to subsequent optimization.

[0253] Taking an enterprise-level continuous integration scenario as an example, the build tasks of a software project include steps such as code compilation, unit testing, integration testing, and deployment. The system needs to handle concurrent requests for multiple tasks, and some of these tasks have higher priorities. In terms of dynamically adjusting the Pod template, the system analyzes historical data and finds that the code compilation stage usually requires high CPU resources, while the unit testing stage requires high memory resources. Based on this data and the real-time system load, the system predicts the resource demand curve of the current task and generates a customized Pod template. For example, allocate 4 cores of CPU and 2GB of memory to the code compilation container, while allocate 1 core of CPU and 4GB of memory to the unit testing container. In addition, the system identifies task dependencies, starts the code compilation container first, and delays the start of the unit testing container to ensure more efficient resource allocation. In terms of real-time feedback and dynamic adjustment, when the task reaches the integration testing stage, the system monitors that the resource demand of high-priority tasks surges, while low-priority tasks occupy some key resources. The system immediately triggers the resource recycling mechanism, pauses the containers of low-priority tasks, and releases resources for high-priority tasks to use, thus avoiding task delays. After the task is completed, the system generates an execution report, recording the resource usage trends in each stage, the log analysis of test failures, and the optimization suggestions for the resource allocation strategy. For example, the report shows that the memory consumption in the unit testing stage is 20% higher than expected. The system stores this data in the historical database and adjusts the memory allocation of the unit testing container during the next task scheduling.

[0254] By adopting the above technical solutions, through dynamically adjusting the Pod template and the real-time feedback mechanism, the accuracy and utilization rate of resource allocation are significantly improved, and resource waste and task delays are avoided. By optimizing task dependencies and the container startup order, combined with the differential processing strategy for high- and low-priority tasks, the overall build time is shortened by about 30%. The real-time acquisition and feedback mechanism enables the system to quickly respond to resource competition and load fluctuations and maintain efficient operation. The generation and storage of the task execution report provide data support for subsequent task scheduling and resource allocation, realizing a closed-loop of continuous optimization. Through the above collaborative mechanism, this embodiment effectively solves the problems of low resource scheduling efficiency, serious task competition, and insufficient system optimization in traditional build systems, and provides a more intelligent and dynamic solution for enterprise-level continuous integration systems.

[0255] Furthermore, the above embodiments deeply integrate the technical advantages of Jenkins and Kubernetes, and innovatively design a dynamic build environment management mechanism based on multi-container Pod templates. This mechanism has achieved the unification of build environment standardization and dynamic scaling, breaking through the contradiction between environment consistency and resource elasticity in traditional solutions. The core of the system design lies in: taking the Jenkins server as the control plane, deeply integrating with the Kubernetes cluster through declarative APIs to achieve programmatic orchestration of the build environment; based on the templatized design of multi-container Pods, enabling different types of build tasks to work together in isolated environments; through hierarchical priority management and resource scheduling strategies, ensuring the execution efficiency of critical tasks even when cluster resources are tight.

[0256] The technical solution of the above embodiments constructs a complete closed-loop system from task triggering, resource allocation, status monitoring to exception handling. When the system detects that a high-priority task needs to be executed, a series of collaborative mechanisms will be triggered: the priority evaluator first calculates the real-time priority of the task based on multi-dimensional indicators such as task urgency, resource competition degree, and task correlation degree; the resource scheduler then dynamically creates Pods or reallocates resources based on the priority results in combination with the cluster resource status; the monitoring system continuously tracks the task execution status and feeds back the status information to the scheduling system in real time to form a closed-loop optimization; the exception handling mechanism can quickly perform failover and recovery based on preset policies when problems are found to ensure the stability of the system.

[0257] The innovation of the above embodiments is also reflected in solving multiple technical difficulties: through the carefully designed multi-container Pod templates, the balance between build environment standardization and personalized requirements is achieved; based on the priority evaluation algorithm of multi-dimensional indicators, the accuracy and fairness of resource scheduling are ensured; the design of the container communication and status synchronization mechanism guarantees the reliability and efficiency of task execution; the complete exception handling strategy provides progressive fault recovery capabilities from single-container retry to full-Pod rescheduling.

[0258] This dynamic build environment management mechanism based on multi-container Pod templates not only fundamentally solves problems such as low resource utilization and poor scalability in traditional Jenkins build environments, but also provides a more flexible task execution mode through the collaborative mechanism between containers. The system can automatically adjust the resource allocation strategy according to the real-time load situation, significantly improving the overall efficiency while ensuring the build quality. Practice shows that this solution has obvious advantages when dealing with high-concurrency build tasks compared with traditional solutions: the resource utilization rate is increased by more than 40%, the average task execution time is reduced by 30%, and the system expansion ability is significantly enhanced.

[0259] Through the innovative design and implementation of the above technical solutions, the above embodiments have successfully solved the key technical challenges faced by the continuous integration system under the microservices architecture, providing a new technical path for building an efficient and reliable continuous integration system.

[0260] To better understand the technical solutions of this application, a specific example is given below for illustration. The details listed in this example are mainly for easy understanding and do not limit the protection scope of this application.

[0261] This example proposes a Jenkins continuous integration method based on Kubernetes. The specific process is as follows:

[0262] 1) Task triggering: When specific conditions are met (such as code submission, scheduled triggering, manual triggering, etc.), Jenkins, as the control center of the CI / CD process, will initiate a new build task.

[0263] 2) Dynamically create a build environment: Jenkins sends a request to create a Pod to the Kubernetes cluster according to the type and requirements of the task. Kubernetes dynamically creates one or more containers based on a predefined Pod template to form a Pod as the execution environment for the build task. The Pod template defines various services required for the build, such as code compilation, testing, packaging, etc.

[0264] 3) Execute build steps in parallel: Multiple containers in the Pod are started in parallel, and each container is responsible for executing one or more steps in the build process. For example, one container is used for code compilation, another container is used for unit testing, and another container is used for packaging and deployment. These containers can perform necessary data exchange and collaboration through shared storage and networks.

[0265] 4) Recycle build resources: When all containers in the Pod have completed execution, Jenkins sends a request to Kubernetes to delete the Pod, quickly recycling the computing resources occupied by the build task, such as CPU and memory, to avoid resource waste. Logs, test reports, artifact packages, etc. generated during the build process will be persistently saved to external storage for subsequent query and analysis.

[0266] It should be noted that the entire process of this example has a high degree of automation, dynamically creates and destroys the build environment on demand, makes full use of the container orchestration and scheduling capabilities of Kubernetes, and greatly improves resource utilization and task execution efficiency. At the same time, by decomposing the build process into multiple parallel steps, not only the build speed is optimized, but also the entire process becomes more modular, reusable, and maintainable.

[0267] This cloud-native CI / CD solution based on Jenkins and Kubernetes not only makes the creation and recycling of the build environment more elastic and efficient, but also makes the orchestration and scheduling of the build process more intelligent and flexible, which is an excellent practice in adapting to modern microservices architecture and DevOps concepts.

[0268] Furthermore, the core of this example is to use Jenkins as the control panel for the CI / CD process, deeply integrate with the management panel (API Server) of the Kubernetes cluster, and form a complete cloud-native CI / CD closed loop. The key components and concepts involved include:

[0269] Jenkins Server: As a traditional CI tool, Jenkins is responsible for defining and orchestrating the entire build, test, and deployment process. However, in this solution, Jenkins no longer directly manages the build nodes and execution environments, but instead delegates these responsibilities to Kubernetes by interacting with the Kubernetes API Server. The main functions of Jenkins are to parse the pipeline script, initiate Pod creation and deletion requests, monitor the Pod status changes, and integrate the build results.

[0270] Kubernetes API Server: As the "brain" of the Kubernetes cluster, the API Server provides a set of declarative REST APIs for managing various resources in the cluster, such as Pods, Services, Volumes, etc. It receives Pod creation and deletion requests from Jenkins, determines which Nodes to schedule the Pods based on the request parameters and the cluster status, and continuously monitors and maintains the Pod lifecycle.

[0271] Kubernetes Node: As a worker node in the Kubernetes cluster, each Node runs a Kubelet agent and a container runtime (such as Docker). When the Kubelet receives a Pod scheduling request from the API Server, it calls the container runtime to create and start the containers inside the Pod, monitors the running status of the containers, and recycles the resources when the containers terminate. The Node is the actual carrier for executing the build tasks.

[0272] Pod: As the smallest scheduling unit in Kubernetes, a Pod encapsulates a group of closely related containers that share the same network namespace and storage volume and cooperate to complete an independent build task. The lifecycle of the Pod is jointly managed by the APIServer and the Kubelet to ensure that the containers inside the Pod run as expected and are automatically destroyed after the task is completed.

[0273] To achieve efficient parallel builds, this solution introduces the concept of "multi-container Pod templates". A Pod template defines a Pod prototype containing multiple containers, with each container corresponding to an independent step in the build process, such as code compilation, unit testing, static checking, packaging and deployment, etc. These steps can be executed in parallel, greatly shortening the build time. At the same time, since all containers run within the same Pod, they can efficiently share data and collaborate through shared storage and the localhost network.

[0274] When Jenkins triggers a new build task, it reads the predefined Pod template, fills in some dynamic parameters (such as code version, environment variables, etc.), and then sends a Pod creation request to the API Server. The API Server selects one or more eligible Nodes based on the cluster's resource status and scheduling policies, creates and runs the Pod. Throughout the Pod's lifecycle, the Kubelet will collect the execution logs and status codes of the containers within the Pod in real-time and send them back to the API Server; Jenkins will also periodically query the Pod's status through the Label selector until it detects that the Pod is successful or failed. Once all containers have finished executing, Jenkins will immediately send a Pod deletion request, triggering the Kubelet to clean up and recycle the resources occupied by the Pod.

[0275] In summary, this example combines the process orchestration capabilities of Jenkins with the container scheduling capabilities of Kubernetes, retaining both Jenkins' flexible DSL syntax and rich plugin ecosystem, while also introducing Kubernetes' dynamic resource provisioning and elastic load scheduling, achieving a true sense of "cloud native". Developers do not need to concern themselves with underlying resource management and environment configuration. They only need to define standardized pipeline steps in Jenkins to obtain a highly automated, scalable, and easily maintainable CI / CD system.

[0276] The second embodiment of this application relates to a Jenkins continuous integration system based on Kubernetes, and its structure is as Figure 2 shown. The Jenkins continuous integration system based on Kubernetes includes:

[0277] A deployment module, used to deploy the Jenkins server in the Kubernetes cluster and complete the initialization configuration, making it the console of the cluster to manage the continuous integration pipeline and its tasks;

[0278] A build request module, configured to enable the Jenkins server to send a Pod creation request to the Kubernetes cluster based on a preset multi-container Pod template after receiving a code submission or a manually triggered build signal;

[0279] A Pod creation module, configured to enable the Kubernetes cluster to create a pipeline task Pod according to the multi-container Pod template after receiving the Pod creation request, where the Pod includes multiple containers for executing different build tasks, and the build tasks include code compilation, unit testing, and deployment;

[0280] A task execution module, configured to enable the multiple containers in the Pod to execute their respective build tasks in parallel after the Pod is started, and the containers achieve data interaction and collaboration between tasks by sharing the network space and storage volume within the Pod;

[0281] A monitoring and management module, configured to enable the Jenkins server to monitor the task execution status of each container in the Pod in real time, and send a Pod destruction command to the Kubernetes cluster to release cluster resources after detecting that all build tasks are completed; the Jenkins server repeats the functions of the build request module, the Pod creation module, and the task execution module according to new build task requirements and the real-time load status of the cluster.

[0282] The first implementation manner is a method implementation manner corresponding to this implementation manner. The technical details in the first implementation manner can be applied to this implementation manner, and the technical details in this implementation manner can also be applied to the first implementation manner.

[0283] It should be noted that those skilled in the art should understand that the implementation functions of the various modules shown in the above implementation manners of the Jenkins continuous integration system based on Kubernetes can be understood with reference to the relevant descriptions of the foregoing Jenkins continuous integration method based on Kubernetes. The functions of the various modules shown in the above implementation manners of the Jenkins continuous integration system based on Kubernetes can be implemented by a program (executable instruction) running on a processor, or can also be implemented by specific logic circuits. If the above Jenkins continuous integration system based on Kubernetes in the embodiments of the present application is implemented in the form of software function modules and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiments of the present application, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in the various embodiments of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read Only Memory), magnetic disks, or optical discs that can store program codes. Thus, the embodiments of the present application are not limited to any specific combination of hardware and software.

[0284] Correspondingly, the embodiments of the present application also provide a computer storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the method embodiments of the present application are implemented.

[0285] In addition, an embodiment of the present application further provides a Jenkins continuous integration system based on Kubernetes, which includes a memory for storing computer-executable instructions and a processor. The processor is configured to implement the steps in the above method embodiments when executing the computer-executable instructions in the memory. Among them, the processor may be a central processing unit (Central Processing Unit, abbreviated as "CPU"), or other general-purpose processors, digital signal processors (Digital Signal Processor, abbreviated as "DSP"), application specific integrated circuits (Application Specific Integrated Circuit, abbreviated as "ASIC"), etc. The aforementioned memory may be a read-only memory (read-only memory, abbreviated as "ROM"), a random access memory (random access memory, abbreviated as "RAM"), a flash memory (Flash), a hard disk, or a solid-state drive, etc. The steps of the methods disclosed in the embodiments of the present application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0286] All documents mentioned in the present application are considered to be integrally included in the disclosure of the present application so as to be used as a basis for modification when necessary. In addition, it should be understood that after reading the above disclosure of the present application, those skilled in the art can make various changes or modifications to the present application, and these equivalent forms also fall within the scope claimed by the present application.

Claims

1. A Jenkins continuous integration method based on Kubernetes, characterized in that: The following steps are involved: Step A: Deploy a Jenkins server in the Kubernetes cluster and complete the initial configuration so that it can serve as the console of the cluster to manage the continuous integration pipeline and its tasks; Step B: After receiving a code submission or manually triggered build signal, the Jenkins server sends a Pod creation request to the Kubernetes cluster based on a preset multi-container Pod template; Step C: After receiving the Pod creation request, the Kubernetes cluster creates a pipeline task Pod according to the multi-container Pod template, wherein the Pod includes multiple containers for performing different build tasks, and the build tasks include code compilation, unit testing, and deployment; Step D: After starting the Pod, multiple containers in the Pod execute their own build tasks in parallel, and the containers realize data interaction and collaboration between tasks by sharing the network space and storage volume in the Pod; Step E: The Jenkins server monitors the task execution status of each container in the Pod in real time. When it detects that all build tasks have been completed, it sends a Pod destruction command to the Kubernetes cluster to release cluster resources; the Jenkins server repeats steps B to E according to new build task requirements and the real-time load status of the cluster.

2. The method according to claim 1, characterized in that The Jenkins server is deployed as a stateful set or stateless on one or more nodes of the Kubernetes cluster. The initialization configuration of the Jenkins server includes: configuring Kubernetes cluster authentication information, registering cloud proxy nodes, setting resource quota limits, and configuring default parameters for build tasks.

3. The method according to claim 1, characterized in that The multi-container Pod template includes: configuration information of a basic construction container, a test container, and a deployment container, each container configuration information includes an image address, resource restrictions, environment variables, and a storage volume mount point, wherein the image address is a storage location identifier of a container image.

4. The method according to claim 1, characterized in that The construction tasks include one or more of code compilation, unit testing, static code scanning, Docker image building and pushing, application configuration management, and integration testing. The tasks can be executed in a predefined or dynamically generated pipeline sequence.

5. The method according to claim 1, characterized in that The containers in the Pod achieve collaboration in the following ways: sharing the Pod's network namespace to achieve localhost communication, sharing persistent storage volumes to achieve data exchange, sharing configuration information through environment variables, and achieving inter-process communication through Socket files or port mapping.

6. The method according to claim 1, characterized in that The Jenkins server receives trigger requests through the WebHook interface or the predefined API interface and dynamically adjusts the Pod creation and scheduling strategy based on the following factors: Resource utilization of cluster nodes; The number of queued tasks; Average task execution time of historical build data statistics; User-specified task priorities or deadlines; Node affinity and taint tolerance settings.

7. The method according to claim 1, characterized in that The Jenkins server monitors the Pod status through the Kubernetes Watch mechanism, including: Poll container logs; Monitor container exit status code; Collect resource usage metrics such as CPU, memory, network, and disk I / O; Detect abnormal container behavior; · Record monitoring data to the build history.

8. The method according to claim 1, characterized in that Prioritize and manage build tasks, including: Set priority tags for different types of tasks; Adjust priorities in real time based on task type, resource status, and time constraints; Dynamically adjust Pod resource quotas based on task priority; Support resource preemption mechanism for high priority tasks; Implement a fault-tolerant mechanism that automatically retry failed tasks and reschedule Pods.

9. The method according to claim 1, characterized in that Ensure system security and efficient use of resources through the following mechanisms: Configure independent service accounts and network policies for each Pod; Encrypted storage of access credentials, including code repository credentials, Docker image repository passwords, and cloud service API keys; Automatically trigger resource recycling according to preset cleanup strategies; After the task is completed, the build products and logs are saved, and the related Kubernetes cluster resources are released.

10. The method according to claim 1, characterized in that Further comprising the steps of: When the Jenkins server sends a Pod creation request to the Kubernetes cluster, the multi-container Pod template is dynamically adjusted based on historical build task data, real-time performance indicators, and metadata carried by the build signal. The adjustment includes: analyzing the resource consumption curve of the historical build task and the real-time resource usage trend, predicting the resource demand curve of the current build task, and dividing it into multiple stages, each stage corresponding to a different resource demand intensity; based on the resource demand stage, selecting the most matching template from the preset multi-container Pod template set, and generating a customized multi-container Pod template; optimizing the container startup sequence according to the task dependency graph, so that resource scheduling matches the task execution sequence; allocating elastic resource quotas for high-priority task containers, and introducing a delayed scheduling strategy for low-priority task containers; After the Pod is started, the resource usage data, task execution progress and abnormal events of each container are collected in real time, and the data is fed back to the Jenkins server. The feedback data is used to: dynamically adjust the resource allocation strategy of the container of unexecuted tasks; trigger the resource recovery or task suspension strategy of the low-priority container when resource competition occurs in high-priority tasks; re-optimize the container execution order based on real-time performance data, and the real-time performance data includes network delay and resource consumption trend; Before the Pod is destroyed, a task execution report is generated based on the monitoring data. The report includes resource usage trend analysis, abnormal log analysis, and task execution path optimization suggestions. The report is stored in the build history database for subsequent task scheduling and template updates.

11. A Jenkins continuous integration system based on Kubernetes, characterized in that: include: A deployment module, which is used to deploy a Jenkins server in a Kubernetes cluster and complete the initial configuration so that it can serve as the console of the cluster to manage the continuous integration pipeline and its tasks; A build request module is used to enable the Jenkins server to send a Pod creation request to the Kubernetes cluster based on a preset multi-container Pod template after receiving a code submission or a manually triggered build signal; A Pod creation module, configured to enable the Kubernetes cluster to create a pipeline task Pod according to the multi-container Pod template after receiving the Pod creation request, wherein the Pod includes multiple containers for performing different build tasks, and the build tasks include code compilation, unit testing, and deployment; A task execution module is used to enable multiple containers in the Pod to execute their respective construction tasks in parallel after starting the Pod, and the containers can realize data interaction and collaboration between tasks by sharing the network space and storage volume in the Pod; The monitoring management module is used to enable the Jenkins server to monitor the task execution status of each container in the Pod in real time. When it is detected that all build tasks are completed, a Pod destruction command is sent to the Kubernetes cluster to release cluster resources; the Jenkins server repeatedly executes the functions of the build request module, the Pod creation module and the task execution module according to the new build task requirements and the real-time load status of the cluster.

Images