Kubernetes-based jenkins task building method and device

Abstract

The present disclosure provides a Kubernetes-based Jenkins task building method and device. The method comprises: in response to receiving a building task request, determining whether there is an available Agent pod in a resource pool, the resource pool comprising N Agent pods deployed in a Kubernetes node cluster to run N Jenkins executors, the N Agent pods corresponding one-to-one to the N Jenkins executors; when it is determined that there is an available Agent pod in the resource pool, causing the corresponding available Jenkins executor to execute a building task corresponding to the building task request; and after the building task is executed, deleting the Agent pod corresponding to the building task, and creating a new Agent pod as part of the resource pool, so that the number of Agent pods in the resource pool returns to N.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a Kubernetes-based Jenkins task building method and apparatus, computing device, computer-readable storage medium, and computer program product. Background Technology

[0002] Jenkins is a continuous integration tool developed in Java, acting as a scheduling center in the entire CI / CD DevOps process. To execute build tasks using Jenkins, two methods can be employed: static and dynamic builds. In static builds, a master-slave architecture can be used for distributed builds, distributing build tasks across Jenkins slave nodes to reduce the load on the Jenkins master node. While static builds are efficient, multiple build tasks may be assigned to the same Jenkins slave node, resulting in an impure build environment. Static nodes also consume resources even when not actively running, leading to low resource utilization. In dynamic builds, a Kubernetes plugin can be installed in Jenkins to execute build tasks in a dynamic slave mode based on Kubernetes. Upon receiving a build task request, the Jenkins master node dynamically starts a Jenkins slave pod on a worker node in the Kubernetes cluster to execute the corresponding build task. Dynamic builds facilitate resource reclamation and ensure a clean build environment. However, this dynamic build process requires creating build nodes, and even with parameter optimization, it still takes time. Furthermore, builds cannot be queued, and consecutive builds for the same task are prone to failure. While setting pod retention times can address build continuity issues, the build environment is not pristine. Current dynamic build systems lack the ability to automatically rebuild pods after deletion, and JNLP images do not support modifying their own agent tags. Summary of the Invention

[0003] In view of this, this disclosure provides a Kubernetes-based Jenkins task building method and apparatus, computing device, computer-readable storage medium, and computer program product to alleviate, mitigate, or even eliminate the aforementioned problems.

[0004] According to one aspect of this disclosure, a Jenkins task building method based on Kubernetes is provided, characterized in that the method includes: in response to receiving a build task request, determining whether there is an available Agent pod in a resource pool, the resource pool including N Agent pods deployed in a Kubernetes node cluster to run N Jenkins executors, the N Agent pods corresponding one-to-one with the N Jenkins executors; when it is determined that there is an available Agent pod in the resource pool, causing the corresponding available Jenkins executor to execute the build task corresponding to the build task request; and after the build task is completed, deleting the Agent pod corresponding to the build task, and creating a new Agent pod as part of the resource pool, so that the number of Agent pods in the resource pool is restored to N.

[0005] According to some embodiments of this disclosure, the resource pool is created through the following steps: creating N Agent pods, setting the tag value and name of the Agent, and obtaining the Secret value corresponding to each Agent pod. The tag value is used to effectively acquire, filter, and organize Agent pods, and the name is used to uniquely identify the Agent pod. The Secret value is used for communication between the Agent pod and the Jenkins server. Based on the Secret value, the N created Agent pods are registered with the Jenkins server, so that each Agent pod can run build tasks scheduled by the Jenkins server.

[0006] According to some embodiments of this disclosure, the completion of the build task is determined by the following steps: based on the tag value of the Agent corresponding to the build task and the idle flag of the execution machine in the Agent pod, the completion of the build task is determined, wherein the tag value is used to indicate whether the Agent pod corresponding to the tag value needs to be recycled, and the idle flag is used to indicate whether the corresponding execution machine is available.

[0007] According to some embodiments of this disclosure, the method further includes: when it is determined that there is no available Agent pod in the resource pool, creating a new Agent pod as part of the resource pool.

[0008] According to some embodiments of this disclosure, the method further includes: when the number of Agent pods in the resource pool is equal to M, and when it is determined that there are no available Agent pods in the resource pool, creating a new Agent pod through a Kubernetes plugin to run the Jenkins execution machine to execute the build task corresponding to the build task request.

[0009] According to some embodiments of this disclosure, the method further includes: when it is determined that there is no available Agent pod in the resource pool, creating a new Agent pod through a Kubernetes plugin to run a Jenkins execution machine to execute the build task corresponding to the build task request.

[0010] According to some embodiments of this disclosure, the method further includes: reducing the number of Agent pods in the resource pool as the number of concurrent build tasks gradually decreases.

[0011] According to some embodiments of this disclosure, the method further includes: alerting the administrator when the number of available Agent pods in the resource pool is less than P.

[0012] According to another aspect of this disclosure, a Kubernetes-based Jenkins task build apparatus is provided, characterized in that the apparatus comprises: an available executor determination module configured to, in response to receiving a build task request, determine whether there is an available Agent pod in a resource pool, the resource pool comprising N Agent pods deployed in a Kubernetes node cluster to run N Jenkins executors, the N Agent pods corresponding one-to-one with the N Jenkins executors; a build task execution module configured to, when it is determined that there is an available Agent pod in the resource pool, cause the corresponding available Jenkins executor to execute the build task corresponding to the build task request; and a resource pool maintenance module configured to, after the build task is executed, delete the Agent pod corresponding to the build task and create a new Agent pod as part of the resource pool, so that the number of Agent pods in the resource pool is restored to N.

[0013] According to another aspect of this disclosure, a computing device is provided, characterized in that the computing device includes: a memory configured to store computer-executable instructions; and a processor configured to perform any of the methods provided according to the foregoing aspects of this disclosure when the computer-executable instructions are executed by the processor.

[0014] According to another aspect of this disclosure, a computer-readable storage medium is provided, characterized in that the computer-readable storage medium stores computer-executable instructions that, when executed, perform any of the methods provided according to the foregoing aspects of this disclosure.

[0015] According to another aspect of this disclosure, a computer program product is provided, characterized in that the computer program product includes computer-executable instructions that, when executed by a processor, perform any of the methods provided according to the foregoing aspects of this disclosure.

[0016] According to the Kubernetes-based Jenkins task building method provided in this disclosure, a resource pool can be used to execute build tasks (the resource pool includes N Agent pods deployed in a Kubernetes node cluster to run N Jenkins executors, and the N Agent pods correspond one-to-one with the N Jenkins executors). That is, when there is an available Agent pod in the resource pool, the corresponding available Jenkins executor executes the build task corresponding to the build task request, thereby enabling the build task to be executed in a clean environment. In addition, by deleting the Agent pod corresponding to the build task after the build task is completed and creating a new Agent pod as part of the resource pool, the number of Agent pods in the resource pool is restored to N. This can improve resource utilization while supporting the queuing of multiple build tasks, thereby achieving higher build efficiency.

[0017] These and other aspects of this disclosure will be clear from the embodiments described below, and will be elucidated with reference to the embodiments described below. Attached Figure Description

[0018] In the following description of exemplary embodiments in conjunction with the accompanying drawings, further details, features, and advantages of the present disclosure are disclosed, in which: Figure 1 The illustration shows an example flowchart of a Kubernetes-based Jenkins task building method according to some embodiments of the present disclosure; Figure 2 The diagram illustrates an exemplary principle of a method for performing build tasks using a resource pool. Figure 3 An exemplary schematic diagram illustrates a method for determining whether a build task is complete and performing resource reclamation according to some embodiments of the present disclosure; Figure 4The diagram illustrates an exemplary schematic of another Kubernetes-based Jenkins task building method according to some embodiments of the present disclosure; Figure 5 The diagram illustrates an exemplary schematic of yet another Kubernetes-based Jenkins task building method according to some embodiments of the present disclosure; Figure 6 Schematic illustration Figure 5 Example flowchart of the method shown; Figure 7 The illustration schematically shows an example block diagram of a Kubernetes-based Jenkins task build appliance according to some embodiments of the present disclosure; Figure 8 An example system is illustrated, which includes an example computing device representing one or more systems and / or devices that can implement the various technologies described herein. Detailed Implementation

[0019] Several embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings to enable those skilled in the art to implement the technical solutions of this disclosure. The technical solutions of this disclosure can be embodied in many different forms and for many different purposes, and should not be limited to the embodiments set forth herein. These embodiments are provided to make the technical solutions of this disclosure clear and complete, but the described embodiments do not limit the scope of protection of this disclosure.

[0020] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms such as those defined in commonly used dictionaries should be interpreted as having meanings consistent with their meanings in the relevant field and / or the context of this specification, and will not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0021] Before detailing the embodiments of this disclosure, some related concepts will first be explained.

[0022] 1. Kubernetes: Abbreviated as k8s, it is an open-source platform for automating container operations, including deployment, scheduling, and scaling between node clusters. A Kubernetes node cluster represents a group of nodes, which can be physical servers or virtual machines on which the Kubernetes platform is installed.

[0023] 2. Pod: The smallest API object in a Kubernetes project, consisting of multiple containers and related configuration information. In Kubernetes, the most basic management unit is the Pod, not the container. A Pod is a layer of encapsulation on top of a container in Kubernetes. It consists of one or more containers running on the same host. The reason for encapsulation by Pod is that the recommended usage of a container is to run only one process inside it, while in general, an application is composed of multiple components.

[0024] Figure 1 The illustration shows an example flowchart of a Kubernetes-based Jenkins task build method (hereinafter referred to as build method 100 for brevity) according to some embodiments of this disclosure. Exemplarily, build method 100 can be implemented by a Jenkins server.

[0025] Specifically, in step 110, in response to receiving a build task request, it is determined whether there are available Agent pods in the resource pool. The resource pool includes N Agent pods deployed in a Kubernetes node cluster to run N Jenkins executors, and the N Agent pods correspond one-to-one with the N Jenkins executors. For example, the value of N can be reasonably selected based on the historical number of concurrent build tasks or the expected number in the future. However, it should be noted that this disclosure does not limit the specific value of N; for example, N can be 2, 3, 10, 20, or other positive integers. The term "resource pool" is an abstraction of the N Agent pods deployed in the Kubernetes node cluster, that is, a collection of these Agent pods. The one-to-one correspondence between the N Agent pods and the Jenkins executors ensures that the Jenkins executor in an Agent pod is used to execute only one corresponding build task, thereby guaranteeing that the build task is executed in a clean environment.

[0026] In some embodiments, at least a portion of the Agent pods in the resource pool can be created through the following steps: creating Agent pods, setting the tag value and name for each Agent, and obtaining the Secret value corresponding to the created Agent pod. The tag value is used to effectively acquire, filter, and organize Agent pods, and the Secret value is used for communication between the created Agent pod and the Jenkins server. Based on the Secret value, the created Agent pod is registered with the Jenkins server, enabling the created Agent pod to run build tasks scheduled by the Jenkins server. These steps can be accomplished by writing corresponding script commands. Other Agent pods in the resource pool that are different from the at least a portion of the Agent pods can be created using Kubernetes plugins to run corresponding Jenkins executors, thereby executing corresponding build tasks. This method of creating Agent pods using Kubernetes plugins is the dynamic build described in the "Background Technology" section, where, upon receiving a build task request, the Jenkins Master node dynamically starts a JenkinsSlave Pod on a worker node in the Kubernetes node cluster to execute the build task corresponding to the build task request.

[0027] In step 120, when it is determined that an available Agent pod exists in the resource pool, the corresponding available Jenkins executor executes the build task corresponding to the build task request. For example, when it is determined that an available Agent pod exists in the resource pool (there may be multiple available Agent pods, for example, two or more), a corresponding available Jenkins executor can be selected from these available Agent pods to execute the build task corresponding to the build task request. For example, the Jenkins server can schedule an available Agent pod from these available Agent pods to execute the build task. The term "build task" refers to various operations performed by Jenkins on a DevOps project, including but not limited to one or more of the following operations: cleanup, compilation, testing, packaging, integration testing, verification, and deployment.

[0028] In step 130, after the build task is completed, the Agent pod corresponding to the build task is deleted, and a new Agent pod is created as part of the resource pool, restoring the number of Agent pods in the resource pool to N. Deleting the Agent pod corresponding to the build task after its completion releases corresponding resources, improving resource utilization. Creating a new Agent pod as part of the resource pool, restoring the number of Agent pods in the resource pool to N, supports queuing of multiple build tasks, thereby achieving higher build efficiency.

[0029] It should be noted that the operation of "deleting the Agent pod corresponding to the build task" can be performed immediately after the build task is completed. Alternatively, this operation can be performed after a period of time after the build task is completed. For example, the Agent pods corresponding to the build tasks that have been completed can be scanned and identified periodically (e.g., hourly), and then these Agent pods can be deleted (reclaimed).

[0030] It should be noted that in this disclosure, in addition to build tasks that can be executed normally, build tasks with abnormal execution status should also be considered as completed. For example, when the Jenkins execution machine in an Agent pod is in a busy state for a long time, causing the corresponding Agent pod to become unavailable, such build tasks with abnormal execution status can be considered as completed, and the corresponding Agent pod can then be deleted. A new Agent pod can be created using the dynamic build method described above, or a new Agent pod can be created by writing corresponding script commands.

[0031] By using build method 100, a resource pool can be used to execute build tasks. When an available Agent pod exists in the resource pool, the corresponding available Jenkins execution machine executes the build task corresponding to the build task request, allowing the build task to be executed in a clean environment. In addition, by deleting the Agent pod corresponding to the build task after the build task is completed and creating a new Agent pod as part of the resource pool, the number of Agent pods in the resource pool is restored to N. This can improve resource utilization while supporting the queuing of multiple build tasks, thereby achieving higher build efficiency.

[0032] The following is through Figure 2 To further explain the principle of using resource pools to perform build tasks, such as... Figure 2As shown, resource pool 200 includes N Agent pods (Agent pod 1, Agent pod 2, ..., Agent pod N) deployed in a Kubernetes node cluster to run N Jenkins executors, wherein the N Agent pods correspond one-to-one with the N Jenkins executors.

[0033] like Figure 2 As shown, when the Jenkins server receives a build task request (Req 1, Req 2, …, Req P), it determines whether an available Agent pod exists in resource pool 200. It should be noted that, generally speaking, Figure 2 The P build requests shown can be sent to the Jenkins server in any order. For example, when these build requests are concurrent build requests, the Jenkins server receives these build requests simultaneously. Alternatively, Req 1, Req 2, ..., Req P can be received by the Jenkins server sequentially.

[0034] For example, at the current moment, the Jenkins server receives a build task request (Req 1). The Jenkins server then determines whether there is an available Agent pod in resource pool 200. Assuming the Jenkins server determines that the Agent pod in resource pool 200 is available (for example, Agent pod 2 is available), it causes Agent pod 2 to execute the build task corresponding to Req 1. After the build task is completed, the Agent pod corresponding to the build task (Agent pod 2 in this example) is deleted, and a new Agent pod is created as part of the resource pool, so that the number of Agent pods in resource pool 200 is restored to N. That is, in this example, a new Agent pod is created as a replacement for Agent pod 2.

[0035] As another example, at the current moment, the Jenkins server receives a build task request (Req 2, ReqP). The Jenkins server then determines whether there are available Agent pods in resource pool 200. Assuming the Jenkins server determines that the Agent pods in resource pool 200 are available (for example, Agent pod 1 and Agent pod N are available), it schedules the corresponding Jenkins execution machines to execute the build tasks corresponding to Req 2 and Req P according to the preset scheduling rules. After the build tasks are completed, the Agent pods corresponding to the build tasks (Agent pod 1 and Agent pod N in this example) are deleted, and new Agent pods are created as part of the resource pool, so that the number of Agent pods in resource pool 200 is restored to N. That is, in this example, two new Agent pods are created to replace Agent pod 1 and Agent pod N respectively.

[0036] Figure 3 An exemplary schematic diagram illustrates a method for determining whether a build task is complete and performing resource reclamation according to some embodiments of this disclosure. Figure 3 As shown, taking build task X as an example, it is possible to determine whether build task X is complete based on the tag value 310 of Agent X corresponding to build task X and the idle flag 320 of the Jenkins executor in Agent X. The tag value 310 is used to indicate whether Agent Pod X corresponding to tag value 310 needs to be recycled (deleted), and the idle flag 320 is used to indicate whether the corresponding Jenkins executor is available.

[0037] In this disclosure, different methods of creating Agent Pods can be distinguished by setting different environment variables, and then the label value can be set according to the environment variables. For example, when Agent Pod X is created using dynamic building, a first label (e.g., "dynamic") can be used as the environment variable corresponding to Agent Pod X. When Agent Pod X is created using script commands, a second label (e.g., "static") different from the first label can be used as the environment variable corresponding to Agent Pod X. In this case, a check can be performed in the script that creates the Agent after the build. If the environment variable is equal to "static", then the label value 310 of Agent X is set to "dirty". Of course, this is just an example; the label value 310 can also be set to other fields. The idle flag 320 is used to indicate whether the Jenkins executor is available. When the idle flag 320 is equal to "true", it indicates that the Jenkins executor is available; when the idle flag 320 is equal to "false", it indicates that the Jenkins executor is unavailable.

[0038] Taking build task X as an example again, build task X can be considered complete when both of the following conditions are met: Agent X's tag value 310 is "dirty" and the corresponding Jenkins executor's idle flag 320 is "true". This scheme, which uses both the tag value of the Agent corresponding to the build task and the idle flag of the corresponding Jenkins executor to determine whether the build task is complete, can reduce the workload of resource pool maintenance and allow administrators to customize the scanning time of the maintenance process (for example, if only the idle flag is used for judgment, it would require scanning every second to determine whether the corresponding Agent pod has stopped working, which would increase the workload of resource pool maintenance).

[0039] In some embodiments, when it is determined that no available Agent pod exists in the resource pool, a new Agent pod is created as part of the resource pool via a script command, thereby enabling automatic scaling of the resource pool. In some embodiments, when the number of Agent pods in the resource pool is equal to M, and it is determined that no available Agent pod exists in the resource pool, a new Agent pod can be created via a Kubernetes plugin to run the Jenkins executor and execute the corresponding build tasks. The following section combines... Figure 4 These implementation schemes are illustrated by way of example.

[0040] like Figure 4As shown, resource pool 410 initially comprises N Agent pods (Agent pod 1, Agent pod 2, …, Agent pod N) deployed in a Kubernetes node cluster to run N Jenkins executors. When it is determined that no available Agent pod exists in resource pool 410, a new Agent pod is created as part of resource pool 410 via script commands to scale up resource pool 410; that is, Agent pod N+1 is created as part of resource pool 410. It should be understood that… Figure 4 This is just an illustration; more Agent pods could be created as part of resource pool 410.

[0041] Continuing with the example of creating one Agent pod (Agent pod N+1), Agent pod N+1 can run a Jenkins executor to execute the corresponding build tasks. New Agent pods may be continuously created, eventually resulting in resource pool 410 containing M Agent pods (M is always greater than N), i.e., ... Figure 4 As shown in resource pool 420, resource pool 420 includes M pods (Agent pod 1, Agent pod 2, …, Agent pod M) deployed in a Kubernetes node cluster. When the number of Agent pods in resource pool 420 equals M, and it is determined that there are no available Agent pods in resource pool 420, a new Agent pod can be created using a Kubernetes plugin to run the Jenkins execution machine and execute the corresponding build tasks. That is, Agent pod M+1 can be created using a Kubernetes plugin to run the Jenkins execution machine. In this case, Agent pod M+1 is not considered part of resource pool 420. The capacity of the resource pool may need to be limited (e.g., due to considerations of resource pool maintenance, script command execution time, etc.). In this case, the implementation scheme of creating new Agent pods using dynamic construction (i.e., the above-mentioned method using Kubernetes plugins) can constrain the capacity of the resource pool.

[0042] Unlike the above implementation scheme, in some embodiments, when it is determined that no available Agent pod exists in the resource pool, a new Agent pod can be created using a Kubernetes plugin to run the Jenkins execution machine and perform the corresponding build tasks. The following section combines... Figure 5 and Figure 6To further clarify this implementation plan.

[0043] like Figure 5 As shown, resource pool 510 includes N Agent pods (Agentpod 1, Agent pod 2, ..., Agent pod N) deployed in a Kubernetes node cluster to run N Jenkins executors. When it is determined that there are no available Agent pods in resource pool 510, a new Agent pod is created via a Kubernetes plugin to run a Jenkins executor to execute the corresponding build tasks; that is, Agent pod N+1 (created by...) is created. Figure 5 As indicated by reference numeral 520 in the attached diagram, in this case, Agent pod N+1 is not considered part of resource pool 510, meaning that resource pool 510 is not being expanded.

[0044] like Figure 6 As shown, in step 610, after receiving the task build request, the Jenkins server schedules the task based on the Agent tag value or Agent name value bound to the build task; in step 620, it determines the resource pool (e.g., Figure 5 The system checks if there are any idle (i.e., available) Agent pods in resource pool 510. For example, if the idle flag of the execution machine corresponding to all Agent pods in the resource pool is "false", it can be determined that there are no idle Agent pods in the resource pool. In this case, a new Agent pod is created using dynamic construction in step 650, and the corresponding dynamic construction execution machine performs the build task. How to handle the corresponding Agent pod after the build task is completed can be handled in step 660 according to the configuration of the pod template. For example, when the container retention policy (Pod Retention) in the Pod Template is set to "Never", the corresponding Agent pod is deleted after the build is completed. If there are available Agent pods in the resource pool (e.g., ... Figure 5If Agent pod 1 is in resource pool 510, then in step 630, the Jenkins server will schedule the build task corresponding to the build request to Agent pod 1 for execution. In step 640, the Agent script created after the build can be checked. If the environment variable is equal to "static", then the label value of Agent 1 will be set to "dirty". After the build task is completed, Agent pod 1 will be deleted and a new Agent pod will be created as part of the resource pool (i.e., replacing Agent pod 1).

[0045] In some embodiments, the build method 100 further includes: reducing the number of Agent pods in the resource pool when the number of concurrent build tasks gradually decreases. For example, by monitoring changes in the number of concurrent build tasks over a certain period, when the number of concurrent build tasks gradually increases, the resource pool can be expanded using the methods provided in the foregoing aspects of this disclosure to execute the corresponding build tasks; when the number of concurrent build tasks gradually decreases, the number of Agent pods in the resource pool can be reduced to release corresponding machine resources. This disclosure does not limit the magnitude of the reduction in the number of Agent pods in the resource pool; for example, the magnitude can be positively correlated with the increase in the number of concurrent build tasks. Through this implementation, the capacity of the resource pool can be configured more rationally according to actual build needs, thereby further improving resource utilization.

[0046] In some embodiments, the construction method 100 further includes: alerting the administrator when the number of available Jenkins Agentpods in the resource pool is less than P. This disclosure does not limit the specific value of P; it can be 1, 2, 3, or any positive integer, and those skilled in the art can flexibly set this value according to the actual scenario. To achieve automated monitoring and alerting, for example, Prometheus (an open-source system monitoring and alerting tool) and Grafana (an open-source time-series statistics and monitoring platform) can be used to monitor the Agent pod resources of the resource pool and automatically adjust according to the busyness of task construction. Specifically, the Executors Busy per Label (Stacked) in the Jenkins Jobs Stats template can be configured to be the label of the resource pool using Prometheus and Grafana, and then alert information can be configured: taking N Jenkins executors in the resource pool as an example, when the number of busy Jenkins executors is equal to N-1, an email alert can be sent to the administrator. Additionally, you can monitor Agent pods with the label "dirty". If an Agent pod with the label "dirty" exists for more than a preset time period (e.g., 30 minutes), an alarm will be issued and the corresponding Agent pod will be deleted.

[0047] Figure 7 An example block diagram of a Kubernetes-based Jenkins task build appliance (hereinafter referred to as Jenkins task build appliance 700 for brevity) according to some embodiments of this disclosure is illustrated. Figure 7 As shown, the Jenkins task build apparatus 700 includes an available executor determination module 710, a build task execution module 720, and a resource pool maintenance module 730.

[0048] Specifically, the available executor determination module 710 can be configured to: in response to receiving a build task request, determine whether there is an available Agent pod in the resource pool, wherein the resource pool includes N Agent pods deployed in a Kubernetes node cluster to run N Jenkins executors, and the N Agent pods correspond one-to-one with the N Jenkins executors; the build task execution module 720 can be configured to: when it is determined that there is an available Agent pod in the resource pool, cause the corresponding available Jenkins executor to execute the build task corresponding to the build task request; the resource pool maintenance module 730 can be configured to: after the build task is completed, delete the Agent pod corresponding to the build task, and create a new Agent pod as part of the resource pool, so that the number of Agent pods in the resource pool is restored to N.

[0049] It should be understood that the Jenkins task build appliance 700 can be implemented in software, hardware, or a combination of both. Multiple different modules within the Jenkins task build appliance 700 can be implemented within the same software or hardware architecture, or a single module can be implemented by multiple different software or hardware architectures.

[0050] Furthermore, the Jenkins task build appliance 700 can be used to implement the build method 100 described above, the details of which have been described in detail above and will not be repeated here for the sake of brevity. The Jenkins task build appliance 700 can have the same features and advantages as described with respect to the aforementioned build method 100.

[0051] Figure 8 An example system is illustrated, including an example computing device 800 representing one or more systems and / or devices that can implement the various technologies described herein. The computing device 800 can be, for example, a server of a service provider, a device associated with a server, a system-on-a-chip, and / or any other suitable computing device or computing system. Any one or more of the devices in the Jenkins task building apparatus 700 described above can take the form of computing device 800. Alternatively, the Jenkins task building apparatus 700 can be implemented as a computer program in the form of application 816.

[0052] like Figure 8The example computing device 800 shown includes a processing system 811, one or more computer-readable media 812, and one or more I / O interfaces 813 that are communicatively coupled to each other. Although not shown, the computing device 800 may also include a system bus or other data and command transfer system that couples the various components to each other. The system bus may include any or a combination of different bus architectures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any of the various bus architectures. Various other examples, such as control and data lines, are also conceived.

[0053] Processing system 811 represents the functionality of performing one or more operations using hardware. Therefore, processing system 811 is illustrated as including hardware elements 814 that can be configured as processors, function blocks, etc. This may include other logic devices implemented in hardware as application-specific integrated circuits (ASICs) or formed using one or more semiconductors. Hardware element 814 is not limited by the materials in which it is formed or the processing mechanism employed therein. For example, a processor may consist of semiconductors and / or transistors (e.g., integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically executable instructions.

[0054] Computer-readable medium 812 is illustrated as including memory / storage device 815. Memory / storage device 815 represents a memory / storage capacity associated with one or more computer-readable media. Memory / storage device 815 may include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disk, magnetic disk, etc.). Memory / storage device 815 may include fixed media (e.g., RAM, ROM, fixed hard disk drive, etc.) and removable media (e.g., flash memory, removable hard disk drive, optical disk, etc.). Computer-readable medium 812 may be configured in various other ways as further described below.

[0055] One or more I / O interfaces 813 represent the functionality to allow users to input commands and information to computing device 800 using various input devices and optionally also to present information to the user and / or other components or devices using various output devices. Examples of input devices include keyboards, cursor control devices (e.g., mice), microphones (e.g., for voice input), scanners, touch functionality (e.g., capacitive or other sensors configured to detect physical touch), cameras (e.g., capable of detecting non-touch-related movements as gestures using visible or invisible wavelengths (such as infrared frequencies), etc. Examples of output devices include display devices (e.g., monitors or projectors), speakers, printers, network interface cards, haptic-responsive devices, etc. Therefore, computing device 800 can be configured to support user interaction in various ways as further described below.

[0056] The computing device 800 also includes an application 816. The application 816 may be, for example, a software instance of the Jenkins task building apparatus 700, and may implement the techniques described herein in combination with other components in the computing device 800.

[0057] This document describes various technologies within the general context of software and hardware components or program modules. Generally, these modules include routines, programs, elements, components, data structures, etc., that perform specific tasks or implement specific abstract data types. As used herein, the terms "module," "function," and "component" generally refer to software, firmware, hardware, or a combination thereof. The technologies described herein are characterized as platform-independent, meaning that these technologies can be implemented on a variety of computing platforms with various processors.

[0058] Implementations of the described modules and technologies may be stored on or transmitted across some form of computer-readable medium. Computer-readable medium may include a variety of media accessible by the computing device 800. By way of example and not limitation, computer-readable medium may include "computer-readable storage medium" and "computer-readable signal medium".

[0059] In contrast to simple signal transmission, carrier waves, or signals themselves, a "computer-readable storage medium" refers to a medium and / or device capable of persistently storing information, and / or a tangible storage device. Therefore, a computer-readable storage medium refers to a non-signal-bearing medium. Computer-readable storage media include hardware such as volatile and non-volatile, removable and non-removable media and / or storage devices implemented using methods or techniques suitable for storing information (such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data). Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage devices, hard disks, cassette tapes, magnetic tapes, disk storage devices or other magnetic storage devices, or other storage devices, tangible media, or articles of art suitable for storing desired information and accessible by a computer.

[0060] "Computer-readable signal medium" refers to a signal-bearing medium configured to transmit instructions, such as via a network, to computing device 800. A signal medium typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, data signal, or other transmission mechanism. Signal media also include any information transmission medium. The term "modulated data signal" refers to a signal in which one or more of its characteristics are set or altered to encode information. By way of example and not limitation, communication media include wired media such as wired networks or direct connections, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0061] As previously described, hardware element 814 and computer-readable medium 812 represent instructions, modules, programmable device logic, and / or fixed device logic implemented in hardware, which in some embodiments can be used to implement at least some aspects of the techniques described herein. Hardware elements may include components of integrated circuits or systems-on-a-chip, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other implementations or other hardware devices in silicon. In this context, hardware elements can serve as processing devices for executing program tasks defined by instructions, modules, and / or logic embodied by the hardware element, and as hardware devices for storing instructions for execution, such as the previously described computer-readable storage medium.

[0062] The foregoing combinations can also be used to implement the various techniques and modules described herein. Therefore, software, hardware, or program modules and other program modules can be implemented as one or more instructions and / or logic embodied on some form of computer-readable storage medium and / or by one or more hardware elements 814. The computing device 800 can be configured to implement specific instructions and / or functions corresponding to the software and / or hardware modules. Thus, modules can be implemented at least partially in hardware as modules executable as software by the computing device 800, for example, by using the computer-readable storage medium and / or hardware elements 814 of a processing system. Instructions and / or functions can be executable / operable by one or more articles of art (e.g., one or more computing devices 800 and / or processing systems 811) to implement the techniques, modules, and examples described herein.

[0063] In various implementations, the computing device 800 can be configured in various ways. For example, the computing device 800 can be implemented as a computer-type device, including personal computers, desktop computers, multi-screen computers, laptop computers, netbooks, etc. The computing device 800 can also be implemented as a mobile device, including mobile devices such as mobile phones, portable music players, portable gaming devices, tablet computers, multi-screen computers, etc. The computing device 800 can also be implemented as a television-type device, including devices with or connected to a generally large screen in a leisure viewing environment. These devices include televisions, set-top boxes, game consoles, etc.

[0064] The techniques described herein can be supported by these various configurations of computing device 800, and are not limited to specific examples of the techniques described herein. Functionality can also be implemented, in whole or in part, on the “cloud” 820 using distributed systems, such as through platform 822 as described below.

[0065] Cloud 820 includes and / or represents platform 822 for resource 824. Platform 822 abstracts the underlying functionality of the hardware (e.g., server) and software resources of cloud 820. Resource 824 may include applications and / or data that can be used when performing computer processing on a server remote from computing device 800. Resource 824 may also include services provided via the Internet and / or via subscriber networks such as cellular or Wi-Fi networks.

[0066] Platform 822 can abstract resources and functions to connect computing device 800 to other computing devices. Platform 822 can also be used to abstract resource hierarchy to provide a tiered hierarchy of the appropriate level of demand for resource 824 implemented via platform 822. Therefore, in interconnect device embodiments, the implementation of the functions described herein can be distributed throughout system 1600. For example, functions can be implemented partly on computing device 800 and partly through platform 822, which abstracts the functions of cloud 820.

[0067] It should be understood that, for clarity, embodiments of this disclosure have been described with reference to different functional units. However, it will be apparent that, without departing from this disclosure, the functionality of each functional unit may be implemented in a single unit, in multiple units, or as part of other functional units. For example, functionality described as being performed by a single unit may be performed by multiple different units. Therefore, references to a particular functional unit are considered merely as references to the appropriate unit used to provide the described functionality, and not as indicating a strict logical or physical structure or organization. Thus, this disclosure may be implemented in a single unit, or may be physically and functionally distributed among different units and circuits.

[0068] It will be understood that although the terms first, second, third, etc., may be used herein to describe various devices, elements, components, or parts, these devices, elements, components, or parts should not be limited by these terms. These terms are used only to distinguish one device, element, component, or part from another device, element, component, or part.

[0069] Although this disclosure has been described in conjunction with some embodiments, it is not intended to be limited to the specific forms set forth herein. Rather, the scope of this disclosure is limited only by the appended claims. Additionally, although individual features may be included in different claims, these may be advantageously combined, and inclusion in different claims does not imply that such a combination of features is not feasible and / or advantageous. The order of features in the claims does not imply that the features must be in any particular order of their operation. Furthermore, in the claims, the word "comprising" does not exclude other elements, and the terms "a" or "an" do not exclude a plurality. Reference numerals in the claims are provided only by way of explicit example and should not be construed as limiting the scope of the claims in any way.

[0070] It should be understood that, for clarity, embodiments of this disclosure have been described with reference to different functional units. However, it will be apparent that, without departing from this disclosure, the functionality of each functional unit may be implemented in a single unit, in multiple units, or as part of other functional units. For example, functionality described as being performed by a single unit may be performed by multiple different units. Therefore, references to a particular functional unit are considered merely as references to the appropriate unit used to provide the described functionality, and not as indicating a strict logical or physical structure or organization. Thus, this disclosure may be implemented in a single unit, or may be physically and functionally distributed among different units and circuits.

[0071] This disclosure provides a computer-readable storage medium storing computer-readable instructions that, when executed, implement the aforementioned Kubernetes-based Jenkins task building method.

[0072] This disclosure provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computing device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computing device to perform the Kubernetes-based Jenkins task building method provided in the various alternative implementations described above.

[0073] By studying the accompanying drawings, the disclosure, and the appended claims, those skilled in the art can understand and implement variations of the disclosed embodiments in practicing the claimed subject matter. In the claims, the word "comprising" does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used advantageously.

Claims

1. A Jenkins task building method based on Kubernetes, characterized in that, The method includes: In response to receiving a build task request, it is determined whether there is an available Agent pod in the resource pool, wherein the resource pool includes N Agent pods deployed in a Kubernetes node cluster to run N Jenkins executors, and the N Agent pods correspond one-to-one with the N Jenkins executors; When it is determined that there is an available Agent pod in the resource pool, the corresponding available Jenkins execution machine executes the build task corresponding to the build task request; Based on the predefined tag value of the Agent pod corresponding to the build task and the idle flag of the Jenkins execution machine in the Agent pod, it is determined whether the build task is complete. The predefined tag value indicates whether the Agent pod corresponding to the predefined tag value needs to be recycled, and the idle flag indicates whether the corresponding Jenkins execution machine is available. After the build task is completed, the Agent pod corresponding to the build task is deleted, and a new Agent pod is created as part of the resource pool, so that the number of Agent pods in the resource pool is restored to N.

2. The method according to claim 1, characterized in that, The resource pool is created through the following steps: Create N Agent pods, set the tag value and name for each Agent, and obtain the Secret value corresponding to each Agent pod. The tag value is used to obtain, filter, and organize Agent pods, and the Secret value is used for communication between Agent pods and the Jenkins server. Based on the Secret value, the N Agent pods created are registered with the Jenkins server, so that each Agent pod can run build tasks scheduled by the Jenkins server.

3. The method according to claim 1, characterized in that, The method further includes: When it is determined that there is no available Agent pod in the resource pool, a new Agent pod is created as part of the resource pool.

4. The method according to claim 3, characterized in that, The method further includes: When the number of Agent pods in the resource pool is equal to M, and when it is determined that there are no available Agent pods in the resource pool, a new Agent pod is created through a Kubernetes plugin to run the Jenkins executor and execute the build task corresponding to the build task request.

5. The method according to claim 1, characterized in that, The method further includes: When it is determined that there is no available Agent pod in the resource pool, a new Agent pod is created using a Kubernetes plugin to run the Jenkins execution machine and execute the build task corresponding to the build task request.

6. The method according to claim 1, characterized in that, The method further includes: As the number of concurrent build tasks gradually decreases, the number of Agent pods in the resource pool is reduced.

7. The method according to claim 1, characterized in that, The method further includes: An alert is sent to the administrator when the number of available Agent pods in the resource pool is less than P.

8. A Jenkins task build device based on Kubernetes, characterized in that, The device includes: An available executor determination module is configured to determine, in response to receiving a build task request, whether there is an available Agent pod in a resource pool, the resource pool comprising N Agent pods deployed in a Kubernetes node cluster to run N Jenkins executors, the N Agent pods corresponding one-to-one with the N Jenkins executors; A build task execution module is configured to, when it is determined that an available Agent pod exists in the resource pool, cause the corresponding available Jenkins execution machine to execute the build task corresponding to the build task request; and The resource pool maintenance module is configured to delete the Agent pod corresponding to the build task after the build task is completed, and create a new Agent pod as part of the resource pool, so that the number of Agent pods in the resource pool is restored to N. The resource pool maintenance module is further configured to determine whether the build task is complete based on the predefined tag value of the Agent pod corresponding to the build task and the idle flag of the Jenkins executor in the Agent pod. The predefined tag value is used to indicate whether the Agent pod corresponding to the predefined tag value needs to be recycled, and the idle flag is used to indicate whether the corresponding Jenkins executor is available.

9. A computing device, characterized in that, The computing device includes: Memory, which is configured to store computer-executable instructions; A processor configured to perform the method according to any one of claims 1 to 7 when the computer-executable instructions are executed by the processor.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when executed, perform the method according to any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, perform the method according to any one of claims 1 to 7.

Images