Task processing method and computing device

Abstract

The embodiment of the invention provides a task processing method and computing equipment. The method is applied to a management plane in a K8S cluster. The K8S cluster comprises a plurality of computing nodes; the method comprises the steps that a task processing request is obtained, the task processing request comprises a docker command, and a target computing node is determined in a plurality of computing nodes; sending a task processing request to the target computing node; wherein a first Docker daemon process and a second Docker daemon process are deployed in the target computing node; and executing the docker command by using the first Docker daemon process under the condition that the type of the docker command is to start and manage a container group Pod, and executing the docker command by using the second Docker daemon process under the condition that the type of the docker command is to create and manage a task container and a mirror image resource in the Pod. According to the method, the problem of data isolation in a'container nested container 'scene is solved, and the stability and efficiency of the K8S cluster in the CI / CD process are guaranteed.

Description

Technical Field

[0001] This application relates to the field of computing technology, and in particular to a task processing method and a computing device. Background Technology

[0002] In continuous integration (CI) / continuous delivery (CD) scenarios, Kubernetes (K8S) clusters are widely used to dynamically manage the building and deployment of containerized applications. For example, K8S clusters achieve elastic scaling of the build environment by dynamically allocating computing resources (such as Pods), while isolating the runtime environments of different tasks through containerization technology.

[0003] During the build process, if Pods need to execute some Docker commands, a "container-nested-container" scenario will be created. In this scenario, the Pod, as the outer container, can be scheduled and started by the Kubernetes cluster to carry out the main process of the build task; the inner container created within the Pod using Docker commands can be used to generate or manipulate container images.

[0004] In this scenario, the execution environment of Docker commands within a Pod conflicts with the container (Docker) management of the K8S cluster itself, leading to data isolation issues and severely impacting the stability and efficiency of the CI / CD process. Summary of the Invention

[0005] This application provides a task processing method and computing device that can solve the data isolation problem in the "container nested container" scenario, which is beneficial to ensuring the stability and efficiency of the K8S cluster in the CI / CD process.

[0006] In a first aspect, embodiments of this application provide a task processing method, which is applied to the management plane of a Kubernetes cluster; the Kubernetes cluster includes multiple compute nodes; the method includes:

[0007] Obtain the task processing request, which includes docker commands;

[0008] Determine the target computing node from among multiple computing nodes;

[0009] A task processing request is sent to the target computing node; the target computing node has a first Docker daemon and a second Docker daemon deployed; when the type of the docker command is to start and manage the container group Pod, the first Docker daemon is used to execute the docker command; when the type of the docker command is to create and manage task containers and image resources inside the Pod, the second Docker daemon is used to execute the docker command.

[0010] It should be noted that on the target compute node, the first Docker daemon can be used to start and manage Pods, while the second Docker daemon can be used to handle Docker commands issued from that Pod. The runtime parameters of the first and second Docker daemons are independent of each other, and the runtime parameters include at least one of the following: data storage path, socket file path, or network resources.

[0011] The docker command is used to manage container and image resources. docker commands can include, but are not limited to, at least one of the following: image build (docker build), image save (docker save), or create and start a container (docker run).

[0012] In the above technical solution, two independent Docker daemons (a first Docker daemon and a second Docker daemon) are deployed on each compute node in the Kubernetes cluster. These two Docker daemons can be used to execute different types of Docker commands. By configuring these two Docker daemons to be independent of each other in terms of running parameters, the execution of Docker commands inside the Pod by the second Docker daemon does not affect the operation of the first Docker daemon (for example, it will not accidentally delete data in the first Docker daemon, causing build anomalies). Furthermore, it enables flexible management (storage and deletion) of data in the second Docker daemon, thereby solving the data coupling problem in "container-nested-container" scenarios and helping to ensure the stability and efficiency of the Kubernetes cluster in the CI / CD process.

[0013] In one possible implementation, determining the target computing node among multiple computing nodes based on the task processing request includes:

[0014] If the task processing request includes the target version information corresponding to the docker command, the target node label is determined based on the target version information; the version information of the second Docker daemon corresponding to the target node label matches the target version information.

[0015] The target computing node is determined based on the target node label and the node labels of multiple computing nodes.

[0016] In the above technical solution, after receiving a task processing request, the management plane can determine the target node label based on the target version information corresponding to the docker command in the task processing request. The target node label is then matched with the labels of multiple compute nodes to allocate an appropriate target compute node for the task processing request. This allows the second Docker daemon in the target compute node to meet the execution requirements of the docker command in the task processing request, thus solving the version compatibility problem in the "container nested container" scenario.

[0017] In one possible implementation, when the docker command type is to start and manage a Pod, the method further includes:

[0018] Configure volume mount parameters and send them to the target compute node. The volume mount parameters are used to instruct the target compute node to mount the socket file path of the second Docker daemon to the communication path of the Pod during the process of starting the Pod through the first Docker daemon. The socket file path is used to obtain the socket file of the second Docker daemon, and the socket file is used for the process in the Pod to establish communication with the second Docker daemon.

[0019] In the above technical solution, the Kubernetes cluster management plane can configure volume mount parameters for the target compute node. This allows the target compute node to automatically mount the socket file path of the second Docker daemon to the Pod's communication path during the Pod startup process via the first Docker daemon. Therefore, when the Docker command type involves creating and managing task containers and image resources within the Pod, the process within the Pod on the target compute node can obtain the socket file of the second Docker daemon based on its socket file path and establish communication with it to process the Docker command. This method avoids conflicts between the second and first Docker daemons on the target compute node, ensuring stable operation of the target compute node.

[0020] Secondly, embodiments of this application provide a task processing method, which is applied to a compute node in a K8S cluster. The compute node has a first Docker daemon and a second Docker daemon deployed on it. The first Docker daemon is used to start and manage container groups (Pods) on the compute node, and the second Docker daemon is used to process Docker commands issued from within the Pods. The method includes:

[0021] Receive task processing requests sent by the management plane in the K8S cluster, where the task processing requests include Docker commands;

[0022] When the type of the docker command is to start and manage a container group Pod, the docker command is executed using the first Docker daemon.

[0023] When the type of docker command is to create and manage task containers and image resources inside a Pod, the docker command is executed using a second Docker daemon.

[0024] In the above technical solution, by deploying two independent Docker daemons (a first Docker daemon and a second Docker daemon) on each compute node in the Kubernetes cluster, these two Docker daemons can be used to execute different types of Docker commands. These two Docker daemons are independent of each other in terms of runtime parameters, ensuring that the execution of Docker commands within a Pod by the second Docker daemon does not affect the operation of the first Docker daemon (e.g., it will not accidentally delete data from the first Docker daemon, causing build anomalies). Furthermore, it allows for flexible management (storage and deletion) of data in the second Docker daemon, thereby resolving the data coupling problem in "container-nested-container" scenarios and contributing to the stability and efficiency of the Kubernetes cluster in the CI / CD process.

[0025] In one possible implementation, the method further includes:

[0026] On the compute nodes, the first Docker daemon and the second Docker daemon are deployed in different storage directories respectively;

[0027] Configure independent running parameters for the first Docker daemon and the second Docker daemon respectively; wherein, the first running parameters configured for the first Docker daemon include the first data storage path and the first socket file path corresponding to the first Docker daemon, and the second running parameters configured for the second Docker daemon include the second data storage path and the second socket file path corresponding to the second Docker daemon;

[0028] Start the first Docker daemon and the second Docker daemon.

[0029] In the above technical solution, by deploying the two Docker daemons in different storage directories on each compute node and configuring independent running parameters (including data storage path and / or socket file path) for the two Docker daemons, the running processes of the two Docker daemons on the target compute node are decoupled. This helps to ensure the stable operation of the two Docker daemons on the target compute node and can also solve the data isolation problem in the "container nested container" scenario, which helps to ensure the stability and efficiency of the K8S cluster in the CI / CD process.

[0030] In one possible implementation, executing docker commands using a first Docker daemon includes:

[0031] The first socket file is obtained based on the path of the first socket file, and the first Docker daemon is called to process the docker command based on the first socket file. The first socket file is used to establish communication with the first Docker daemon.

[0032] Obtain the first processing data generated by the first Docker daemon during the processing of Docker commands, determine the first storage space based on the first data storage path, and store the first processing data in the first storage space.

[0033] In the above technical solution, by configuring a separate first socket file path for the first Docker daemon, the calling processes of the first Docker daemon and the second Docker daemon are distinguished, avoiding conflicts between their execution on the target compute node and ensuring stable operation of the target compute node. By configuring a separate first data storage path for the first Docker daemon, the data storage processes of the first Docker daemon and the second Docker daemon are isolated, thus solving the data isolation problem existing in the "container nested container" scenario, which is beneficial to ensuring the stability and efficiency of the Kubernetes cluster in the CI / CD process.

[0034] In one possible implementation, executing Docker commands using a second Docker daemon includes:

[0035] The second socket file path is used to obtain the second socket file of the second Docker daemon, and communication is established with the second Docker daemon based on the second socket file. The second Docker daemon is also invoked to process docker commands. The second socket file path is independent of the first socket file path.

[0036] The second processing data generated by the second Docker daemon during the processing of Docker commands is obtained, and the second storage space is determined according to the second data storage path. The second processing data is stored in the second storage space, and the second data storage path is independent of the first data storage path.

[0037] After the docker command completes execution, delete the second processing data in the second storage space.

[0038] In the above technical solution, by configuring a separate second socket file path for the second Docker daemon, the invocation process of the second Docker daemon is distinguished from that of the first Docker daemon, avoiding conflicts between their execution on the target compute node and ensuring stable operation. By configuring a separate second data storage path for the second Docker daemon, the second processing data generated during the execution of Docker commands is stored separately in the second storage space corresponding to the second data storage path, achieving physical isolation from the first storage space where the first processing data is stored. This solves the problem of mixed storage of second processing data generated during the execution of Docker commands within a Pod in a K8S cluster and K8S cluster system management data (referring to the first processing data generated by the first Docker daemon). Since the storage space for this second processing data is independent and isolated from the storage space for data generated by the first Docker daemon during its operation, deleting this second processing data will not mistakenly delete the first processing data generated by the first Docker daemon during its operation, thus avoiding build anomalies caused by data deletion.

[0039] In one possible implementation, the first operating parameters further include a first network resource; executing Docker commands using a first Docker daemon includes:

[0040] Based on the first network resources, a first communication network environment is built in the computing node, and the first Docker daemon is used to execute Docker commands in the first communication network environment;

[0041] The second set of runtime parameters also includes a second set of network resources; and the execution of Docker commands using a second Docker daemon, including:

[0042] A second communication network environment is built on the computing node based on the second network resources, and the second Docker daemon is used to execute Docker commands in the second communication network environment;

[0043] Among them, the first network resource and the second network resource are independent of each other, and the first communication network environment and the second communication network environment are isolated from each other.

[0044] In the above technical solution, by configuring independent network resources for the two Docker daemons (the first Docker daemon and the second Docker daemon), network resource conflicts between the two daemons can be avoided, ensuring the stability of data transmission during the operation of each Docker daemon and improving network stability.

[0045] In one possible implementation, the method further includes:

[0046] When the docker command type is to start and manage a Pod, receive volume mount parameters sent by the management plane;

[0047] Based on the volume mount parameters, during the process of starting the Pod using the first Docker daemon, the path of the second socket file of the second Docker daemon is mounted to the communication path of the Pod; the path of the second socket file is used to obtain the second socket file of the second Docker daemon, and the second socket file is used for the process in the Pod to establish communication with the second Docker daemon.

[0048] In the above technical solution, based on the volume mount parameters, during the process of starting a Pod through the first Docker daemon, the target compute node mounts the socket file path of the second Docker daemon to the Pod's communication path. This allows processes within the Pod to access the second socket file of the second Docker daemon based on its second socket file path when executing Docker commands that create and manage task containers and image resources within the Pod. Communication is then established between the second Docker daemon and the first Docker daemon to invoke the second Docker daemon to process the Docker command. This method avoids conflicts between the execution of the second Docker daemon and the first Docker daemon on the target compute node, ensuring stable operation of the target compute node.

[0049] Thirdly, embodiments of this application provide a task processing device applied to the management plane of a Kubernetes cluster; the Kubernetes cluster includes multiple compute nodes; the task processing device includes:

[0050] The send / receive module is used to obtain task processing requests, which include Docker commands.

[0051] The processing module is used to determine the target computing node among multiple computing nodes;

[0052] The transceiver module is also used to send task processing requests to the target computing node; wherein, the target computing node has a first Docker daemon and a second Docker daemon deployed; when the type of the docker command is to start and manage the container group Pod, the first Docker daemon is used to execute the docker command; when the type of the docker command is to create and manage task containers and image resources inside the Pod, the second Docker daemon is used to execute the docker command.

[0053] The task processing apparatus provided in this application embodiment can execute the technical solutions shown in any of the first aspects, and its beneficial effects are similar, so they will not be described again here.

[0054] In one possible implementation, the processing module is specifically used for:

[0055] If the task processing request includes the target version information corresponding to the docker command, the target node label is determined based on the target version information; the version information of the second Docker daemon corresponding to the target node label matches the target version information.

[0056] The target computing node is determined based on the target node label and the node labels of multiple computing nodes.

[0057] In one possible implementation, when the docker command type is to start and manage a Pod, the processing module is also used to configure volume mount parameters;

[0058] The transceiver module is also used to send volume mount parameters to the target compute node; wherein, the volume mount parameters are used to instruct the target compute node to mount the socket file path of the second Docker daemon to the communication path of the Pod during the process of starting the Pod through the first Docker daemon; the socket file path is used to obtain the socket file of the second Docker daemon, and the socket file is used for the process in the Pod to establish communication with the second Docker daemon.

[0059] Fourthly, embodiments of this application provide a task processing device applied to compute nodes in a Kubernetes cluster; the Kubernetes cluster includes multiple compute nodes; a first Docker daemon and a second Docker daemon are deployed in the compute nodes; the first Docker daemon is used to start and manage container groups (Pods) in the compute nodes, and the second Docker daemon is used to process Docker commands issued from within the Pods; the task processing device includes:

[0060] The transceiver module is used to receive task processing requests sent by the management plane in the K8S cluster. These task processing requests include Docker commands.

[0061] The processing module is used to execute docker commands using the first Docker daemon when the docker command type is to start and manage a Pod.

[0062] The processing module is also used to execute docker commands using a second Docker daemon when the type of docker command is to create and manage task containers and image resources inside a Pod.

[0063] The task processing apparatus provided in this application embodiment can execute the technical solutions shown in any of the second aspects, and its beneficial effects are similar, so they will not be described again here.

[0064] In one possible implementation, the processing module is further configured to:

[0065] On the compute nodes, the first Docker daemon and the second Docker daemon are deployed in different storage directories respectively;

[0066] Configure independent running parameters for the first Docker daemon and the second Docker daemon respectively; wherein, the first running parameters configured for the first Docker daemon include the first data storage path and the first socket file path corresponding to the first Docker daemon, and the second running parameters configured for the second Docker daemon include the second data storage path and the second socket file path corresponding to the second Docker daemon;

[0067] Start the first Docker daemon and the second Docker daemon.

[0068] In one possible implementation, the processing module is specifically used for:

[0069] The first socket file is obtained based on the path of the first socket file, and the first Docker daemon is called to process the docker command based on the first socket file. The first socket file is used to establish communication with the first Docker daemon.

[0070] Obtain the first processing data generated by the first Docker daemon during the processing of Docker commands, determine the first storage space based on the first data storage path, and store the first processing data in the first storage space.

[0071] In one possible implementation, the processing module is further configured to:

[0072] The second socket file path is used to obtain the second socket file of the second Docker daemon, and communication is established with the second Docker daemon based on the second socket file. The second Docker daemon is also invoked to process docker commands. The second socket file path is independent of the first socket file path.

[0073] The second processing data generated by the second Docker daemon during the processing of Docker commands is obtained, and the second storage space is determined according to the second data storage path. The second processing data is stored in the second storage space, and the second data storage path is independent of the first data storage path.

[0074] After the docker command completes execution, delete the second processing data in the second storage space.

[0075] In one possible implementation, the first operating parameter further includes a first network resource; the processing module is specifically used for:

[0076] Based on the first network resources, a first communication network environment is built in the computing node, and the first Docker daemon is used to execute Docker commands in the first communication network environment;

[0077] The second operating parameter also includes a second network resource; the processing module is specifically used for:

[0078] A second communication network environment is built on the computing node based on the second network resources, and the second Docker daemon is used to execute Docker commands in the second communication network environment;

[0079] Among them, the first network resource and the second network resource are independent of each other, and the first communication network environment and the second communication network environment are isolated from each other.

[0080] In one possible implementation, the transceiver module is also configured to receive volume mount parameters sent by the management plane when the docker command type is "Start and manage Pod".

[0081] The processing module is also used to mount the second socket file path of the second Docker daemon to the communication path of the Pod during the process of starting the Pod using the first Docker daemon, based on the volume mount parameters; the second socket file path is used to obtain the second socket file of the second Docker daemon, and the second socket file is used for the process in the Pod to establish communication with the second Docker daemon.

[0082] Fifthly, embodiments of this application provide a computing device, including: a processor and a memory; the processor and the memory are coupled.

[0083] Memory is used to store program instructions;

[0084] The processor is used to execute program instructions to perform the methods shown in any of the first aspects.

[0085] The computing device provided in the embodiments of this application can execute the technical solutions shown in any of the first aspects or any of the second aspects, and the beneficial effects are similar, so they will not be described again here.

[0086] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions that, when executed by a computer, implement the method as shown in any of the first aspects.

[0087] The computer-readable storage medium provided in the embodiments of this application can execute the technical solutions as shown in any of the first aspects or any of the second aspects, and the beneficial effects are similar, so they will not be described again here.

[0088] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method as shown in any of the first or second aspects.

[0089] The computer program product provided in the embodiments of this application can execute the technical solutions shown in any of the first or second aspects, and the beneficial effects are similar, so they will not be described again here.

[0090] The task processing method and computing device provided in this application can solve the data isolation problem in the "container nested container" scenario, which is beneficial to ensuring the stability and efficiency of K8S cluster in CI / CD process. Attached Figure Description

[0091] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0092] Figure 1A This is a schematic diagram of the system architecture of the task processing system provided in the embodiments of this application;

[0093] Figure 1B A schematic diagram of a configuration page provided in an embodiment of this application;

[0094] Figure 2 One of the flowcharts of the task processing method provided in the embodiments of this application;

[0095] Figure 3 A second schematic flowchart illustrating the task processing method provided in this application embodiment;

[0096] Figure 4 The third flowchart illustrating the task processing method provided in this application embodiment;

[0097] Figure 5 This application provides a schematic diagram of a task processing procedure as an embodiment of the present application.

[0098] Figure 6 This is a schematic diagram of the structure of a task processing device provided in an embodiment of this application;

[0099] Figure 7 This is a schematic diagram of another task processing device provided in an embodiment of this application;

[0100] Figure 8 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application.

[0101] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0102] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0103] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of the technical solutions in the embodiments of this application. However, it does not mean that the applicant has used or necessarily used such solutions.

[0104] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0105] It should be noted that in the embodiments of this application, the term "at least one" refers to one or more, and "more than one" refers to two or more.

[0106] First, the terminology used in the embodiments of this application will be explained.

[0107] 1. Kubernetes (K8S): An open-source platform for the automatic deployment, scaling, and management of container groups (Pods) in clusters, providing a Pod-centric infrastructure. A Pod is the smallest deployable object in K8S. A Pod can include one or more tightly coupled containers that share the same network namespace and storage volume. K8S uses a matcher to distribute Pods across different compute nodes in the K8S cluster, enabling the running and management of containerized applications within the K8S cluster.

[0108] A Kubernetes (K8S) cluster can be deployed across a set of compute nodes that can run containerized applications. A K8S cluster contains at least one management plane (or "control plane") and one or more compute nodes. In continuous integration (CI) scenarios, using K8S cluster technology to build slave nodes (physical machines or virtual machines) achieves the effects of dynamic scaling of containers, enclosed build environments, and time-sharing reuse of cluster resources.

[0109] 2. Docker: A containerization technology that supports the creation and use of Linux containers. Docker can adopt a client-server architecture, which includes the following components: a client module (Docker client), a daemon module (dockerd), and a container runtime (Containerd) management module. The Docker client interacts with the user, receiving user input commands and generating corresponding operation requests. dockerd is the core component of the Docker architecture; it acts as a background daemon responsible for core functions such as container lifecycle management, image storage, networking, and storage volumes. The Containerd management module is responsible for container execution and image management.

[0110] In this architecture, the collaboration process between these components is as follows:

[0111] (1) The Docker client receives Docker commands input by the user.

[0112] Docker commands can include, but are not limited to, at least one of the following commands: image build (docker build), image save (docker save), or create and start a container (docker run).

[0113] Users input docker commands into the docker client via the terminal. The docker client receives the docker command and translates it into a request message conforming to the pre-configured Application Programming Interface (API) specification. The docker command line interface (CLI) tool can then send this request message to dockerd via an inter-process communication channel.

[0114] For example, the inter-process communication channel can be a Unix socket, and its default path can be " / var / run / docker.sock".

[0115] (2) dockerd can parse the request message to determine the Docker operation requested by the user.

[0116] If a Docker operation involves creating a container instance, dockerd can invoke the Containerd management module to create the container. dockerd can check in the local image repository whether an image is available for the Docker operation. If an available image is found, dockerd generates a corresponding container creation task and sends the task to the Containerd management module.

[0117] (3) The Containerd management module performs Docker operations.

[0118] For example, the Containerd management module can receive container creation tasks and verify whether the container image is ready based on the task description in the container creation task. After successful verification, the Containerd management module can call runc to start the container process. runc is a low-level container runtime tool that conforms to the Open Container Initiative (OCI) standard. runc can perform the operation of starting the container process according to the calling instructions of the Containerd management module and the parameters provided (including image path, container configuration, etc.).

[0119] 3. Jenkins: An open-source, scalable automation server that allows developers to improve software development efficiency by automating the build, testing, and deployment processes. Jenkins can run on a Kubernetes cluster to leverage Kubernetes' scalability and resilience. By using Kubernetes, Jenkins can dynamically create and manage Pods within the Kubernetes cluster.

[0120] 4. Pipeline task: This refers to the process of combining multiple steps into a single task, or implementing a component to perform a specified task. A pipeline task can be viewed as a combination of multiple steps that share a workspace and work together to complete the specified task.

[0121] The system architecture provided in the embodiments of this application will be described below for ease of understanding.

[0122] Figure 1A This is a schematic diagram of the system architecture of the task processing system provided in an embodiment of this application. Please refer to [link / reference]. Figure 1A Task processing systems can include continuous integration systems (such as Jenkins) and Kubernetes clusters.

[0123] Continuous integration systems can include task management components (such as Jenkins Master) for receiving and coordinating pipeline tasks. Continuous integration systems can be deployed on a standalone physical server or within a server cluster consisting of multiple physical servers.

[0124] In this embodiment of the application, the K8S cluster may include a management plane and multiple compute nodes. The K8S cluster is used to provide a dynamic, containerized build execution environment for the continuous integration system.

[0125] The management plane can include multiple components such as an API server, a configuration database (etcd), a scheduler, and a controller manager. It is used to maintain the expected state of the Kubernetes cluster and to call and manage each compute node. The management plane can be deployed on a separate physical server or in a server cluster consisting of multiple physical servers. Its components can be deployed independently on different compute nodes or centrally on a single compute node.

[0126] In a multi-node compute system, each compute device can receive and execute instructions from the management plane, and each compute node can be responsible for the actual operation of applications and workloads. Each compute node can also be used to host the creation, operation, and destruction of Pods, providing compute, storage, and network resources for containerized tasks.

[0127] It should be noted that each computing node in the embodiments of this application can be a physical server. In some embodiments, the computing node can also be referred to as a "host machine".

[0128] In some embodiments, users can set up Jenkins and integrate Kubernetes into Jenkins.

[0129] Optionally, users can configure the underlying cloud platform (Configure Clouds) to build a Kubernetes cluster. The configuration page of the underlying cloud platform can be accessed as follows: Figure 1B As shown.

[0130] Figure 1B Please refer to the schematic diagram of a configuration page provided in an embodiment of this application. Figure 1B This configuration page can include multiple fields and the corresponding fill area for each field. Below, we will introduce each of these fields one by one.

[0131] K8S Name: This refers to the name defined in the K8S cloud configuration. Jenkins can identify and manage different K8S clusters based on the K8S name.

[0132] K8S address: refers to the K8S API server address, which is usually an Internet Protocol (IP) address or domain name. Jenkins can communicate with the K8S cluster based on the K8S address.

[0133] K8S Service Certificate Key: Used to indicate the Secure Socket Layer (SSL) certificate key for secure communication with the K8S API server, ensuring data security during transmission.

[0134] Disable Hypertext Transfer Protocol Secure (HTTPS) certificate checking: A security option. If this option is checked, Jenkins will not check the validity of the SSL certificate when communicating with the Kubernetes API server. If this option is not checked, Jenkins will check the validity of the SSL certificate when communicating with the Kubernetes API server.

[0135] Kubernetes namespaces are used to logically group cluster resources within a Kubernetes cluster. Jenkins can create and manage resources within specific Kubernetes namespace configurations.

[0136] Credentials: These are the Kubernetes tokens used for authentication. Jenkins can use these tokens to interact with the Kubernetes API server to perform operations such as deployment and scaling.

[0137] Direct Connection: If this option is selected, Jenkins can connect directly to the K8S API server; if it is not selected, Jenkins can connect to the K8S API server through a proxy or middleware.

[0138] Jenkins address: The address of the Jenkins server, used when the K8S cluster calls back to Jenkins.

[0139] Jenkins Channel: A specific channel or port used to indicate communication between Jenkins and the Kubernetes cluster.

[0140] Connection Timeout: Configures the maximum time Jenkins should wait for a connection response from the Kubernetes API server. If no response is received within this time, Jenkins will consider the connection to have failed.

[0141] Read Timeout: Configures the maximum time Jenkins can wait for a response from the Kubernetes API server. If no response is received within this time, Jenkins will consider the request to have failed.

[0142] Container (Pod) Labels: Defines the template for a Pod running in Kubernetes, including settings such as Pod name, image, command, and parameters. It defines the Pod environment in which a Jenkins job runs within the Kubernetes cluster.

[0143] Number of Pods: The number of Pod instances launched for a Jenkins job in the Kubernetes cluster. This value can be adjusted as needed to scale up or down the number of running instances for the job.

[0144] Below, in conjunction with Figure 1A The system architecture shown illustrates the process of executing pipelined tasks based on this system architecture.

[0145] Continuous integration systems can be used to respond to pipeline task triggering commands by initiating task processing requests to the Kubernetes cluster's API Server based on pre-configured Pod templates. Triggering methods for these commands can include, but are not limited to, manual triggering by the user and / or scheduled task triggering.

[0146] After receiving a task processing request, the API Server can store the metadata information (such as name and resource requirements) of the Pod to be created in etcd.

[0147] The Scheduler in a Kubernetes cluster can continuously monitor the API Server. When it detects a newly created, unused Pod, the Scheduler can determine the target compute node among multiple compute nodes to bind the Pod based on preset allocation policies (such as load balancing, resource requirements, etc.), and write the binding policy back to etcd through the API Server.

[0148] The node agent (kubelet) component deployed on the target compute node continuously monitors the API Server to promptly detect events relevant to itself. When the kubelet component detects that a Pod has been deployed to the target compute node, it pulls the required image from the specified container image repository and starts the container to initialize an independent Pod. This Pod is used as the execution agent (such as the Jenkins Agent) for this pipeline task (including build tasks) and establishes a communication connection with the task management component (such as the Jenkins Master).

[0149] A build task can be a set of specific automated operations in the software development process that transform source code into deployable and runnable artifacts. A continuous integration system can distribute the specific steps of the build task (such as code compilation and packaging) to the Pod for execution.

[0150] This application provides a task processing method to address the data isolation problem in this scenario. It offers an efficient, secure, and flexible container management solution for CI / CD scenarios, ensuring the stability and efficiency of the Kubernetes cluster during the CI / CD process. This task processing method deploys two independent Docker daemons (a first Docker daemon and a second Docker daemon) on each compute node and configures these two daemons to be independent in their running parameters. These running parameters can include at least one of the following: data storage path, socket file path, or network resources. By setting up two independent Docker daemons, physical isolation between the Kubernetes cluster's management data and the Docker operation data within the Pod can be achieved, resolving the data coupling problem in "container-nested-container" scenarios. This provides an efficient, secure, and flexible container management solution for CI / CD scenarios, ensuring the stability and efficiency of the Kubernetes cluster during the CI / CD process.

[0151] This task processing method can also allocate each task processing request to a target compute node matching its node label across multiple compute nodes, based on the node label corresponding to the docker command in each task processing request. This node label matching rule allows the Kubernetes cluster management plane to allocate each task processing request to a target compute node matching its node label, ensuring that when executing docker commands within a Pod, the version of the Docker daemon (such as dockerd) that the docker command depends on matches the version of the second Docker daemon on the allocated target compute node. This resolves version compatibility issues in "container-nested-container" scenarios.

[0152] The technical solutions of the embodiments of this application will be described in detail below with specific examples. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0153] Figure 2 This is one of the flowcharts illustrating a task processing method provided in an embodiment of this application. The task processing method can be... Figure 1A The management plane in the illustrated Kubernetes cluster interacts with the target compute nodes. This cluster comprises multiple compute nodes, each deploying a first Docker daemon and a second Docker daemon. The first and second Docker daemons are isolated from each other by configuring independent runtime parameters, which may include data storage paths and socket file paths. In some embodiments, these parameters may also include network resources. It should be noted that configuring independent runtime parameters for the first and second Docker daemons will be described in [the following text is incomplete and requires further context]. Figure 3 The examples are illustrated below.

[0154] Please see Figure 2 The method may include the following steps:

[0155] S201, The management plane obtains task processing requests.

[0156] like Figure 1A As shown, the management plane can obtain task processing requests sent by the continuous integration system. Alternatively, the management plane can also generate the task processing request based on the internal management needs of the Kubernetes cluster.

[0157] The task processing request may include docker commands, and the number of docker commands can be one or more.

[0158] The docker command can be used to manage container and image resources. The docker command can be, but is not limited to, at least one of the following commands: image build (docker build), image save (docker save), or create and start a container (docker run).

[0159] The docker command can be of the following types: start and manage a Pod, or create and manage task containers and image resources inside a Pod.

[0160] Optionally, the image resource can be an image resource related to a task container. The image resource can contain all the files and configurations required for an application to run.

[0161] Task containers are containers created inside a Pod using docker commands, and can be used to generate or manipulate container images.

[0162] Optionally, the task processing request can be used to request the Kubernetes cluster to allocate the pipeline task to the target compute node for execution. The pipeline task may include at least one build task, which may include Docker commands.

[0163] S202. The management plane determines the target computing node among multiple computing nodes.

[0164] When a task processing request includes a target node label, the management plane can determine the target computing node based on the target node label and the node labels of multiple computing nodes.

[0165] In a Kubernetes (K8S) cluster, task processing requests are allocated to target compute nodes whose target node labels match. This node label matching rule ensures that the version of the Docker daemon (e.g., dockerd) used by the Docker commands within the corresponding Pods matches the version of the second Docker daemon on the allocated target compute node. This resolves the version compatibility issue between the Docker daemon on the compute node and the Docker daemon used by the Docker commands in "container-nested-container" scenarios, thus contributing to the stability and efficiency of the K8S cluster in CI / CD processes.

[0166] Optionally, if the task processing request includes target version information corresponding to the Docker command, the process of the management plane determining the target compute node will be... Figure 4Detailed explanation is provided in the embodiments.

[0167] S203. The management plane sends a task processing request to the target computing node.

[0168] Correspondingly, the target compute node can receive task processing requests sent by the management plane in the Kubernetes cluster, where the task processing requests include Docker commands. The target compute node deploys a first Docker daemon and a second Docker daemon. When the Docker command type is to start and manage a Pod, the first Docker daemon executes the Docker command; when the Docker command type is to create and manage task containers and image resources within a Pod, the second Docker daemon executes the Docker command.

[0169] The first Docker daemon is used to start and manage Pods on compute nodes, while the second Docker daemon is used to handle Docker commands issued from inside the Pod.

[0170] In some embodiments, when the docker command type is to start and manage a Pod, the management plane can also configure volume mount parameters and send the volume mount parameters to the target compute node.

[0171] The volume mount parameter can be used to instruct the target compute node to mount the socket file path of the second Docker daemon to the Pod's communication path during the Pod startup process via the first Docker daemon. This socket file path is used to obtain the socket file of the second Docker daemon, which is used by processes within the Pod to establish communication with the second Docker daemon.

[0172] In some embodiments, the task processing request may include the volume mount parameters. Optionally, the volume mount parameters may also be referred to as "startup container parameters".

[0173] For example, the volume mount parameter can be "-v / var / run / docker-27.0.0.sock: / var / run / docker.sock", which means: mount the socket file path of the second Docker daemon on the target compute node ( / var / run / docker-27.0.0.sock) to the specified communication path ( / var / run / docker.sock) inside the Pod, so that the process inside the Pod can establish communication with the second Docker daemon.

[0174] In this method, the Kubernetes cluster management plane can configure volume mount parameters for the target compute node. This allows the target compute node to automatically mount the socket file path of the second Docker daemon to the Pod's communication path during the Pod startup process via the first Docker daemon. Therefore, when the Docker command type involves creating and managing task containers and image resources within the Pod, the process within the Pod on the target compute node can obtain the socket file of the second Docker daemon based on its socket file path and establish communication with it to process the Docker command. This approach avoids conflicts between the second and first Docker daemons on the target compute node, ensuring stable operation of the target compute node.

[0175] S204. When the type of the docker command is to start and manage a Pod, the target compute node uses the first Docker daemon to execute the docker command.

[0176] In some embodiments, when the docker command type is to start and manage a Pod, the target compute node may also perform the following steps: receive volume mount parameters sent by the management plane; and mount the second socket file path of the second Docker daemon to the communication path of the Pod during the process of starting the Pod using the first Docker daemon, according to the volume mount parameters.

[0177] The path to the second socket file can be used to obtain the second socket file of the second Docker daemon. The second socket file can be used to establish communication between the processes within the Pod and the second Docker daemon.

[0178] In this method, during the startup of the Pod via the first Docker daemon, the target compute node mounts the socket file path of the second Docker daemon to the Pod's communication path. This allows processes within the Pod to access the socket file of the second Docker daemon—a process that creates and manages task containers and image resources within the Pod—based on the socket file path. Communication is then established between the second Docker daemon and the first Docker daemon, enabling the second Docker daemon to execute the Docker command. This approach avoids conflicts between the second and first Docker daemons on the target compute node, ensuring stable operation.

[0179] In some embodiments, the target compute node can execute docker commands using the first Docker daemon by performing the following steps S2041 and S2042:

[0180] Step S2041: Obtain the first socket file of the first Docker daemon based on the first socket file path, and call the first Docker daemon to process the docker command based on the first socket file.

[0181] The first socket file can be used to establish communication with the first Docker daemon.

[0182] For example, the path to the first socket file can be "-H unix: / / / var / run / docker.sock".

[0183] It should be noted that before executing step S2041, this method can configure the path of the first socket file for the first Docker daemon on the target compute node. The configuration process of the first socket file path will be... Figure 3 The examples are illustrated below.

[0184] Step S2042: Obtain the first processing data generated by the first Docker daemon during the processing of docker commands, determine the first storage space according to the first data storage path, and store the first processing data in the first storage space.

[0185] For example, the first data storage path could be " / var / lib / docker".

[0186] For example, the first processed data may include containers, images, and network data generated by the first Docker daemon during the processing of docker commands.

[0187] It should be noted that before executing step S2042, this method can configure the first data storage path for the first Docker daemon on the target compute node. The configuration process of this first data storage path will be... Figure 3 The examples are illustrated below.

[0188] This method distinguishes the calling processes of the first Docker daemon from those of the second Docker daemon by configuring a separate first socket file path for the first Docker daemon, thus avoiding conflicts between their execution on the target compute node and ensuring its stable operation. Furthermore, configuring a separate first data storage path for the first Docker daemon isolates their data storage processes from those of the second Docker daemon, resolving data isolation issues in "container-nested-container" scenarios and contributing to the stability and efficiency of the Kubernetes cluster in the CI / CD process.

[0189] S205. When the type of docker command is to create and manage task containers and image resources inside a Pod, the target compute node uses a second Docker daemon to execute the docker command.

[0190] When the docker command type is "Create and manage task containers and image resources inside a Pod," it means that the process inside the Pod needs to call the second Docker daemon on the target compute node to execute the docker command in order to create and manage task containers and image resources inside the Pod. In this case, the target compute node can execute the docker command using the second Docker daemon by performing the following steps S2051 to S2053:

[0191] Step S2051: Obtain the second socket file of the second Docker daemon based on the path of the second socket file, and call the second Docker daemon to process the docker command based on the second socket file.

[0192] The second socket file can be used to establish communication between processes within a Pod and a second Docker daemon.

[0193] The path to the second socket file is independent of the path to the first socket file.

[0194] Optionally, the second socket file path may include the version information of the second Docker daemon. For example, if the version of the second Docker daemon is 20.10.4, the second socket file path may be "-H unix: / / / var / run / docker-20.10.4.sock".

[0195] Optionally, in a K8S cluster, processes within a Pod can use a second socket file to call a second Docker daemon in the compute node via a Docker client to process Docker commands.

[0196] It should be noted that before executing step S2051, this method can configure the path to the second socket file for the second Docker daemon on the target compute node. The configuration process for this second socket file path will be... Figure 3 The examples are illustrated below.

[0197] Step S2052: Obtain the second processing data generated by the second Docker daemon during the processing of docker commands, determine the second storage space according to the second data storage path, and store the second processing data in the second storage space.

[0198] The second data storage path is independent of the first data storage path. The second storage space is isolated from the first storage space.

[0199] Optionally, the second data storage path may include the version information of the second Docker daemon. For example, if the version of the second Docker daemon is 20.10.4, the second data storage path may be " / var / lib / docker20.10.4".

[0200] For example, the second processed data may include containers, images, and network data generated by the second Docker daemon during the processing of docker commands.

[0201] It should be noted that before executing step S2052, this method can configure the second data storage path for the second Docker daemon on the target compute node. The configuration process of this second data storage path will be... Figure 3 The examples are illustrated below.

[0202] This method distinguishes the second Docker daemon from the first Docker daemon by configuring a separate second socket file path, preventing conflicts between their execution on the target compute node and ensuring stable operation. Furthermore, by configuring a separate second data storage path for the second Docker daemon, the second processing data generated during Docker command execution is stored separately in the second storage space corresponding to this path, achieving physical isolation from the first storage space where the first processing data is stored. This resolves the issue of mixed storage of second processing data generated during Docker command execution within a Pod in a Kubernetes cluster and Kubernetes cluster system management data (referring to the first processing data generated by the first Docker daemon).

[0203] For example, docker command 1 can be executed in Pod1 on compute node 1. The second processing data generated by the second Docker daemon 1 on compute node 1 during the execution of docker command 1 in Pod1 will be independently stored in the second storage space 1 corresponding to storage path 1 (such as " / var / lib / docker27.0.0"), which is isolated from the first storage space corresponding to the storage path of the first Docker daemon 1 on compute node 1 (such as " / var / lib / docker").

[0204] The docker command 2 can be executed in Pod2 on compute node 2. The second processing data generated by the second Docker daemon 2 on compute node 2 during the execution of the docker command 2 in Pod2 will be stored in the second storage space 2 corresponding to the storage path 2 (e.g., " / var / lib / docker20.10.4"), which is isolated from the first storage space corresponding to the storage path of the first Docker daemon 2 on compute node 2 (e.g., " / var / lib / docker").

[0205] Step S2053: After the docker command is executed, delete the second processing data in the second storage space.

[0206] In some embodiments, secondary processing data generated by the Pod during the execution of Docker commands can be deleted within the Pod using a deletion command (such as a Docker command for data deletion) to avoid long-term occupation of disk space.

[0207] In this method, since the storage space where the second processing data is stored is an independent storage space, which is isolated from the storage space where the data generated by the first Docker daemon of the target K8S cluster during operation is stored, the first processing data generated by the first Docker daemon during operation will not be accidentally deleted after the second processing data is deleted, thereby avoiding the problem of build anomalies caused during data deletion.

[0208] For example, after docker command 1 completes execution within Pod1, compute node 1 can delete the second processing data generated by the second Docker daemon 1 during the execution of docker command 1. Similarly, after docker command 2 completes execution within Pod2, compute node 2 can delete the second processing data generated by the second Docker daemon 2 during the execution of docker command 2.

[0209] The task processing method provided in this application isolates the Pod startup process from the Docker command processing within the Pod by deploying two independent Docker daemons (a first Docker daemon and a second Docker daemon) on the target computing node. This solves the data coupling problem in "container-nested container" scenarios. Because the first and second Docker daemons operate independently in terms of parameters, the execution of Docker commands within the Pod by the second Docker daemon does not affect the operation of the first Docker daemon (e.g., it prevents accidental deletion of data in the first Docker daemon, thus avoiding build anomalies). Furthermore, it allows for flexible data management (storage and deletion) of the second Docker daemon's data. In summary, this method solves the data isolation problem in "container-nested container" scenarios, ensuring the stability and efficiency of the Kubernetes cluster in the CI / CD process.

[0210] Below, in conjunction with Figure 3 This document describes the configuration process of two Docker daemons for any one of the multiple compute nodes in a K8S cluster.

[0211] Figure 3 This is a second schematic flowchart illustrating the task processing method provided in this application embodiment. This task processing method can be applied to... Figure 1A The execution is performed on each compute node in the K8S cluster shown.

[0212] Please see Figure 3 The method includes the following steps:

[0213] S301. On the compute node, deploy the first Docker daemon and the second Docker daemon in different storage directories respectively.

[0214] The first Docker daemon can be used to start and manage Pods on compute nodes, while the second Docker daemon can be used to handle Docker commands issued from inside the Pod.

[0215] For example, the first Docker daemon can be deployed in the first storage directory (such as / usr / bin / dockerd), and the second Docker daemon can be deployed in the second storage directory (such as / usr / local / bin / docker-20.10.4 / dockerd-20.10.4). The first and second storage directories are independent of each other.

[0216] Optionally, the second storage directory where the second Docker daemon resides may include the version information of the second Docker daemon. For example, if the version of the second Docker daemon is 20.10.4, its second storage directory may be " / usr / local / bin / docker-20.10.4 / dockerd-20.10.4"; if the version of the second Docker daemon is 27.0.0, its second storage directory may be " / usr / local / bin / docker-27.0.0 / dockerd-27.0.0".

[0217] S302, configure independent running parameters for the first Docker daemon and the second Docker daemon respectively.

[0218] The first runtime parameters configured for the first Docker daemon include the first data storage path and the first socket file path corresponding to the first Docker daemon; the second runtime parameters configured for the second Docker daemon include the second data storage path and the second socket file path corresponding to the second Docker daemon.

[0219] In this embodiment, since two Docker daemons are installed on the same computing node (i.e., the same machine), the containers started by these two Docker daemons will compete for network resources. To avoid network resource contention, the task processing method provided in this embodiment further includes a first network resource in the running parameters configured for the first Docker daemon. The first network resource is used to enable network communication for the first Docker daemon within the computing node. Similarly, the running parameters configured for the second Docker daemon may include a second network resource, which is used to enable network communication for the second Docker daemon within the computing node.

[0220] For example, a Kubernetes cluster can also configure an independent bridge for the second Docker daemon in each compute node or directly start a container in host network mode by default, based on the network requirements configured by the user. This avoids network conflicts caused by two Docker daemons in the same compute node sharing the same bridge or being in the same network mode, thereby improving network stability.

[0221] A system service manager (such as Systemd) can run on the compute node. This system service manager can manage the first and second Docker daemons on the compute node. The system service manager can configure independent running parameters for the first and second Docker daemons on the compute node.

[0222] The following section uses Systemd as an example to explain in detail the process by which the system service manager configures independent running parameters for the first and second Docker daemons in this compute node.

[0223] 1. Configure the first runtime parameters for the first Docker daemon using Systemd.

[0224] In some embodiments, the compute node can configure a first service configuration file for the first Docker daemon through Systemd according to the configuration requirements of the first Docker daemon input by the user. The first service configuration file may include the path to the first socket file and the path to the first parameter configuration file corresponding to the first Docker daemon. The path to the first parameter configuration file can be used to obtain the first parameter configuration file, and the first parameter configuration file can be used to indicate the parameters of the first Docker daemon during startup and operation.

[0225] Systemd can configure the first data storage path corresponding to the first Docker daemon based on the first parameter configuration file. For example, the first data storage path can be " / var / lib / docker".

[0226] For example, Systemd can configure the first service configuration file corresponding to the first Docker daemon in a preset directory, such as " / usr / lib / systemd / system / docker.service".

[0227] In some embodiments, the first service profile may be used to indicate the following information:

[0228] (1) The executable path of the first Docker daemon, for example, ExecStart= / usr / bin / dockerd;

[0229] (2) The path to the communication socket file used by the first Docker daemon to communicate with Containerd, for example, --containerd= / run / containerd / containerd.sock;

[0230] (3) The path to the first socket file, for example, -H unix: / / / var / run / docker.sock;

[0231] (4) The first parameter is the path to the configuration file, for example, --config-file / etc / docker / daemon.json.

[0232] The first parameter configuration file can also be used to indicate the following parameters for the first Docker daemon:

[0233] (1) Maximum Transmission Unit (MTU) is used to define the maximum byte length of the data packet of the first Docker daemon. For example, the maximum byte length can be 1500 bytes.

[0234] (2) Insecure-registries list, which may include the addresses of multiple image repositories, which may be multiple specific image repositories set by the user according to business needs.

[0235] (3) The storage driver used by the first Docker daemon. For example, the storage driver used by the first Docker daemon can be "overlay2".

[0236] (4) Storage options configured for the storage driver (storage-opts), for example, the storage-opts can be "overlay2.basesize=270G", which means that the maximum size of the base image layer is set to 270GB for the overlay2 driver.

[0237] II. Configuring a second runtime parameter for the second Docker daemon using Systemd

[0238] In some embodiments, the compute node can configure a second service configuration file for the second Docker daemon through Systemd according to the configuration requirements of the second Docker daemon input by the user. The second service configuration file may include the path to the second socket file and the path to the second parameter configuration file corresponding to the second Docker daemon. The path to the second parameter configuration file can be used to obtain the second parameter configuration file, and the second parameter configuration file can be used to indicate the parameters of the second Docker daemon during startup and operation.

[0239] Systemd can configure the second data storage path corresponding to the second Docker daemon based on the second parameter configuration file. For example, the first data storage path can be " / var / lib / docker20.10.4".

[0240] Similarly, Systemd can configure the second service configuration file corresponding to the second Docker daemon in the default directory ( / usr / lib / systemd / system / docker.service).

[0241] In some embodiments, the second service profile may be used to indicate the following information:

[0242] (1) The executable path of the second Docker daemon, for example, ExecStart= / usr / local / bin / docker-20.10.4 / dockerd-20.10.4;

[0243] (2) The path to the communication socket file between the second Docker daemon and Containerd, for example, --containerd= / run / containerd / containerd-20.10.4.sock;

[0244] (3) The path to the second socket file, for example, -H unix: / / / var / run / docker-20.10.4.sock;

[0245] (4) The second parameter is the configuration file path, for example, --config-file / etc / docker-20.10.4 / daemon.json.

[0246] The first socket file and the second socket file are independent of each other, and the first data storage path and the second data storage path are independent of each other.

[0247] The second parameter configuration file can be used to indicate the following parameters:

[0248] (1) Container runtime parameters, which may include the name of the container runtime (e.g., local-runc) and the path of the runc executable file corresponding to the container runtime (e.g., / usr / local / bin / docker-20.10.4 / runc).

[0249] (2) The insecure-registries parameter indicates the address of the insecure-registries used.

[0250] (3) Process ID (PID) file (pidfile) parameter, which indicates the PID file path of the second Docker daemon (e.g., / var / run / docker-20.10.4.pid).

[0251] (4) The data root directory of the second Docker daemon is the second data storage path of the second Docker daemon, such as / var / lib / docker20.10.4.

[0252] In the task processing method provided in this application embodiment, each computing node can configure different service configuration files (such as service files) for the two Docker daemons in each computing node through a system service manager (such as Systemd). This allows the two Docker daemons to be associated with different parameter configuration files (such as daemon.json) and socket files, thereby ensuring that the two Docker daemons do not interfere with each other during operation and improving service stability. Furthermore, the system service manager can uniformly manage these two Docker daemons, which helps simplify the startup, shutdown, and monitoring process of the Docker daemon service in the computing node.

[0253] In some embodiments, the method may further include the following steps: configuring a first network resource for a first Docker daemon, the first network resource being used to enable network communication of the first Docker daemon within a compute node; configuring a second network resource for a second Docker daemon, the second network resource being used to enable network communication of the second Docker daemon within a compute node, the second network resource being independent of the first network resource.

[0254] For example, the first network resource may include a first bridge, and the second network resource may include a second bridge, with the first bridge and the second bridge being independent of each other.

[0255] This method avoids network resource conflicts between the two Docker daemons by configuring independent network resources for each Docker daemon, ensuring the stability of data transmission during the operation of each Docker daemon and improving network stability.

[0256] S303, Start the first Docker daemon and the second Docker daemon.

[0257] In some embodiments, a system control tool (such as systemctl) may run on the compute node, which can be used to start a first Docker daemon and a second Docker daemon.

[0258] The task processing method provided in this application decouples the two Docker daemons in the target computing node by deploying them in different storage directories and configuring independent running parameters (including at least one of data storage path, socket file path, and network resources) for the two Docker daemons. This helps ensure the stable operation of the two Docker daemons on the target computing node and also solves the data isolation problem in the "container nested container" scenario, which helps ensure the stability and efficiency of the K8S cluster in the CI / CD process.

[0259] Figure 4 This is the third flowchart illustrating the task processing method provided in this application embodiment. This task processing method can be... Figure 1A The management plane in the Kubernetes cluster interacts with the compute nodes, as shown in the diagram. Please refer to [link / reference]. Figure 4 The method may include the following steps:

[0260] S401. Deploy and start the first and second Docker daemons on the target compute node.

[0261] In a "container-nested-container" scenario, the Docker commands within the build process of the Pod corresponding to a pipeline task may rely on a specific version of the Docker daemon (such as dockerd) for execution. The Kubernetes cluster can deploy different versions of a second Docker daemon across multiple compute nodes based on the build requirements of different pipeline tasks configured by the user. This build requirement information can include the actual version of the Docker daemon required by the Docker commands within the build tasks of each pipeline task.

[0262] For example, a Kubernetes cluster includes 100 compute nodes, each deploying a first Docker daemon (dockerd1) and a second Docker daemon (dockerd2). Based on the user-configured build requirements, assume that some pipeline tasks' Docker commands depend on dockerd version 20, while others depend on dockerd version 27. Of these 100 compute nodes, 50 nodes can have dockerd1 configured to version 18.09.1 ​​and dockerd2 configured to version 20.10.1; the other 50 nodes can have dockerd1 configured to version 18.00.0 and dockerd2 configured to version 27.0.0.

[0263] For any one of the multiple computing nodes, the execution process of steps S301 to S303 can be referred to to deploy and start the first Docker daemon and the second Docker daemon on that computing node.

[0264] In this method, the Kubernetes cluster can obtain build requirement information for multiple pipeline tasks configured by the user, and deploy a first Docker daemon and a second Docker daemon on each compute node based on this information. The build requirement information may include the actual version requirements of the Docker commands within the build tasks of each pipeline task for the Docker daemon version. By deploying different versions of the second Docker daemon on multiple compute nodes, the Kubernetes cluster can adapt to the version requirements of the Docker commands in different pipeline tasks, resolving version mismatch issues. Furthermore, it eliminates the need to deploy multiple different versions of the second Docker daemon on the same compute node, reducing the resource consumption of the second Docker daemon on the compute node. The Kubernetes cluster can dynamically allocate target compute nodes that meet the version requirements of the Docker commands in each pipeline task, based on the version requirements of the Docker commands within each pipeline task, thus resolving the version compatibility issue between the Docker daemon on the compute node and the Docker daemon that the Docker commands depend on in a "container nested container" scenario.

[0265] S402. The management plane configures corresponding node labels for multiple computing nodes.

[0266] The management plane can configure corresponding node labels for multiple compute nodes based on the version information and mapping relationship of the second Docker daemon deployed in multiple compute nodes.

[0267] The mapping relationship can include multiple version information and the node label corresponding to each version information. Among the multiple version information is the version information corresponding to the second Docker daemon in each compute node.

[0268] Based on the version information of the second Docker daemon deployed on each compute node, the management plane can configure a corresponding node label for each compute node through command-line tools, so as to indicate the version information of the second Docker daemon in each compute node through the node label.

[0269] For example, the command-line tool could be kubectl.

[0270] For example, a Kubernetes cluster may contain 100 compute nodes. Among these, 50 compute nodes have dockerd1 configured with version 18.09.1 ​​and dockerd2 configured with version 20.10.1. According to the mapping relationship, the node label corresponding to version 20.10.1 is dc=20.10.1. The node label of these 50 compute nodes can be configured by kubectl as: dc=20.10.1.

[0271] In the other 50 compute nodes, dockerd1 is configured with version 18.00.0 and dockerd2 is configured with version 27.0.0. According to the mapping relationship, the node label corresponding to version 27.0.0 is dc=27.0.0. The node label of the other 50 compute nodes can be configured by kubectl as: dc=27.0.0.

[0272] S403, Management plane obtains task processing requests.

[0273] It should be noted that the specific execution process of this step can be referred to the specific execution process of step S201, and will not be repeated here.

[0274] The number of task processing requests can be one or more.

[0275] For example, a Kubernetes cluster can receive two task processing requests. Task processing request 1 can be used to request the Kubernetes cluster to allocate pipeline task 1 to a compute node with node label dc=27.0.0 for execution; task processing request 2 can be used to request the Kubernetes cluster to allocate pipeline task 2 to a compute node with node label dc=20.10.1 for execution.

[0276] Pipeline task 1 may include build task 1, which may include docker command 1.

[0277] Pipeline task 2 may include build task 2, which may include docker command 2.

[0278] After receiving a task processing request, the management plane can dynamically allocate and adapt the target computing node for the pipeline task based on the target node tag corresponding to the pipeline task carried in the task processing request. This enables the second Docker daemon in the target computing node to meet the execution requirements of the Docker commands within the pipeline task, thereby solving the version compatibility problem in the "container nested container" scenario.

[0279] The following section, in conjunction with steps S404 and S405, explains the matching process between the computing nodes executed by the management plane and the Docker commands.

[0280] S404. When the task processing request includes the target version information corresponding to the docker command, the management plane determines the target node label based on the target version information.

[0281] The version information of the second Docker daemon corresponding to the target node label matches the target version information.

[0282] Optionally, the management plane can determine the target node label based on the target version information and the mapping relationship. The mapping relationship can include multiple version information entries and the node label corresponding to each version entry. The multiple version information entries include the version information corresponding to the second Docker daemon process on each of the multiple compute nodes.

[0283] In some embodiments, such as Figure 1A As shown, continuous integration systems (such as Jenkins) can configure pipeline tasks according to user needs. If a pipeline task includes Docker commands, and the type of Docker commands is to create and manage task containers and image resources within a Pod, it means that the pipeline task may rely on a specific version of a second Docker daemon for processing during execution. The continuous integration system can configure target node labels for the pipeline task based on the mapping relationship and the target version information corresponding to that specific version.

[0284] For example, the Docker commands in a pipeline task might rely on a second Docker daemon of version 20.10.1 for processing during execution. In the mapping relationship, the node label corresponding to version 20.10.1 is dc=20.10.1, and the continuous integration system can configure the target node label for this pipeline task as dc=20.10.1.

[0285] Once the pipeline task is configured in the continuous integration system, the system can respond to trigger commands by generating a task processing request through built-in cluster plugins (such as Kubernetes plugins) and sending the request to the Kubernetes cluster. Figure 1A As shown, the continuous integration system can send task processing requests to the API Server of the K8S cluster based on a pre-configured Pod template.

[0286] S405. The management plane determines the target computing node based on the target node label and the node labels of multiple computing nodes.

[0287] The management plane can match the target node label with the node labels of multiple computing nodes, and identify the successfully matched computing node as the target computing node.

[0288] For example, multiple compute nodes include compute node 1 and compute node 2, where compute node 1 has the node label dc=27.0.0 and compute node 2 has the node label dc=20.10.1. The node label corresponding to the docker command 1 in task processing request 1 is dc=27.0.0, which matches the node label of compute node 1. Therefore, the target compute node for task processing request 1 is compute node 1. Similarly, the node label corresponding to the docker command 2 in task processing request 2 is dc=20.10.1, which matches the node label of compute node 2. Therefore, the target compute node for task processing request 2 is compute node 2.

[0289] In some embodiments, the management plane can also match the target version information with the version information corresponding to the second Docker daemon in multiple computing nodes, and determine the computing node that is successfully matched as the target computing node.

[0290] S406. When the docker command type is "Start and manage Pod", the management plane configures volume mount parameters for the target compute node.

[0291] It should be noted that the content of the volume mounting parameters in step S406 can be referred to the content of the volume mounting parameters in step S203, and will not be repeated here.

[0292] For example, the management plane of the Kubernetes cluster can configure volume mount parameter 1 for compute node 1. This volume mount parameter 1 can be used to instruct compute node 1 to mount the second socket file path 1 of its second Docker daemon 1 to the communication path of Pod 1 during the process of starting Pod 1 through its first Docker daemon 1. This allows the processes in Pod 1 to determine the second socket file 1 through the second socket file path 1 and establish communication with its second Docker daemon 1 based on the second socket file 1, so as to use its second Docker daemon 1 to process docker commands.

[0293] For example, the volume mount parameter 1 can be "-v / var / run / docker-27.0.0.sock: / var / run / docker.sock", which means: mount the second socket file path 1 ( / var / run / docker-27.0.0.sock) of the second Docker daemon 1 on compute node 1 to the communication path ( / var / run / docker.sock) of Pod 1.

[0294] The management plane of the Kubernetes cluster can configure volume mount parameter 2 for compute node 2. This volume mount parameter 2 can be used to instruct compute node 2, during the process of starting Pod 2 through its own first Docker daemon 2, to mount the second socket file path 2 of its own second Docker daemon 2 to the communication path of Pod 2. This allows the processes within Pod 2 to determine the second socket file 2 through the second socket file path 2, and establish communication with its own second Docker daemon 2 based on the second socket file 2, so as to use its own second Docker daemon 2 to process docker commands.

[0295] For example, the volume mount parameter 2 can be "-v / var / run / docker-20.10.4.sock: / var / run / docker.sock", which means: mount the second socket file path 2 ( / var / run / docker-20.10.4.sock) of the second Docker daemon 2 on compute node 2 to the communication path ( / var / run / docker.sock) of Pod 2.

[0296] S407. The management plane sends a task processing request to the target computing node.

[0297] The task processing request may include volume mount parameters configured by the management plane for the target compute node.

[0298] It should be noted that the specific execution process of this step can be referred to the specific execution process of step S203, and will not be repeated here.

[0299] S408. When the target compute node executes the docker command using the first Docker daemon, provided that the docker command type is "Start and manage container group Pod".

[0300] In some embodiments, the first running parameters configured for the first Docker daemon may also include a first network resource; the management plane may build a first communication network environment in the computing node based on the first network resource, and use the first Docker daemon to execute Docker commands in the first communication network environment.

[0301] In the first communication network environment, the target computing node can obtain the first socket file of the first Docker daemon according to the first socket file path, and call the first Docker daemon to process the docker command based on the first socket file; obtain the first processing data generated by the first Docker daemon in the process of processing the docker command, determine the first storage space according to the first data storage path, and store the first processing data in the first storage space.

[0302] S409. When the target compute node uses a second Docker daemon to execute Docker commands, provided that the type of Docker command is to create and manage task containers and image resources within a Pod.

[0303] In some embodiments, the second running parameters configured for the second Docker daemon may also include a second network resource; the management plane may build a second communication network environment in the compute node based on the second network resource, and use the second Docker daemon to execute Docker commands in the second communication network environment.

[0304] In the second communication network environment, the target computing node can obtain the second socket file of the second Docker daemon according to the second socket file path, and call the second Docker daemon to process the docker command based on the second socket file; obtain the second processing data generated by the second Docker daemon in the process of processing the docker command, determine the first storage space according to the second data storage path, and store the second processing data in the first storage space; after the docker command is executed, delete the second processing data in the second storage space.

[0305] The first network resource and the second network resource are independent of each other, and the first communication network environment and the second communication network environment are isolated from each other.

[0306] In this method, by configuring independent network resources for two Docker daemons on the compute node, the two Docker daemons can build independent communication network environments based on their respective network resources. As a result, the two Docker daemons can independently execute the corresponding Docker commands in their respective communication network environments, avoiding competition for network resources between the two Docker daemons on the compute node and improving the network stability of each compute node in processing Docker commands.

[0307] The task processing method provided in this application can pre-deploy independent second Docker daemons and first Docker daemons for each of multiple computing nodes. Based on the target version information or target node tag corresponding to the Docker command carried in each task processing request, the method dynamically allocates and adapts the target computing node for each task processing request. This ensures that the second Docker daemon in the target computing node meets the execution requirements of the Docker command in the task processing request, thus solving the version compatibility problem in the "container nested container" scenario. Furthermore, by configuring the second Docker daemon and the first Docker daemon in each computing node to be independent in terms of execution (at least one of data storage path, socket file path, and network resources), this method prevents accidental deletion of data in the K8S cluster when each computing node executes Docker commands within a Pod. Moreover, after the Docker command execution is complete, the second processing data generated by the second Docker daemon during the Docker command execution can be thoroughly cleaned up to prevent this second processing data from occupying the K8S cluster's storage space for an extended period.

[0308] Below, in order to facilitate understanding of the task processing method provided in the embodiments of this application, in conjunction with Figure 5 This paper describes a task processing procedure involved in an embodiment of the present application.

[0309] Figure 5 This is a schematic diagram of a task processing procedure provided in an embodiment of this application. Please refer to [link / reference]. Figure 5 The Kubernetes cluster consists of 100 compute nodes, each with two independent Docker daemons: a first Docker daemon and a second Docker daemon. These two daemons are isolated from each other through independent runtime parameter configurations, which include at least one of the following: data storage path, socket file path, or network resources.

[0310] For any given compute node, an agent component (such as kubelet) can be deployed. Within this compute node, a first Docker daemon can respond to calls from the agent component, starting and managing Pods within the compute node; a second Docker daemon can handle Docker commands issued from within the Pods. These Docker commands can include, but are not limited to, at least one of the following instructions: image building (docker build) instructions, image saving (dockersave) instructions, and container creation and startup (docker run) instructions.

[0311] Of the 100 compute nodes, the version of the first Docker daemon in compute nodes 1 to 50 can be configured to 18.00.0, and the version of the second Docker daemon can be configured to 27.0.0. The node label for these 50 compute nodes can be configured using kubectl as: dc=27.0.0. For the other 50 compute nodes (compute nodes 51 to 100), the version of the first Docker daemon can be configured to 18.09.1, and the version of the second Docker daemon can be configured to 20.10.1. The node label for these other 50 compute nodes can be configured using kubectl as: dc=20.0.0.

[0312] exist Figure 5 In continuous integration systems (such as Jenkins), pipeline task 1 (job1) and pipeline task 2 (job2) can be configured according to user needs. Specifically:

[0313] In pipeline task 1, the docker command 1 needs to use the Docker client inside the Pod during execution. The Docker client instructions rely on the Docker daemon version 27.0.0 for processing. The continuous integration system can configure the node label for pipeline task 1 as dc=27.0.0.

[0314] The docker command 2 in pipeline task 2 also needs to use the Docker client inside the Pod during execution. The Docker client instructions rely on the Docker daemon version 20.10.1 for processing. The continuous integration system can configure the node label for pipeline task 2 as dc=20.0.0.

[0315] Once pipeline task 1 and pipeline task 2 are configured in the continuous integration system, the system can respond to trigger commands by generating task processing request 1 and task processing request 2 through its built-in Kubernetes plugin, and sending these requests to the Kubernetes cluster management plane. Task processing request 1 can be used to request the Kubernetes cluster to allocate pipeline task 1 to the compute node with node label dc=27.0.0 for execution; task processing request 2 can be used to request the Kubernetes cluster to allocate pipeline task 2 to the compute node with node label dc=20.0.0 for execution.

[0316] The management plane of the Kubernetes cluster can allocate pipeline task 1 to compute node 1 of the Kubernetes cluster for execution, and allocate pipeline task 2 to compute node 51 of the Kubernetes cluster for execution, based on node label matching rules, task processing request 1, and task processing request 2.

[0317] The node label matching rule can be to allocate each pipeline task to the computing node that matches its node label for execution, based on the node label corresponding to each pipeline task.

[0318] The Kubernetes cluster management plane can configure volume mount parameter 1 for compute node 1 and send this parameter to compute node 1. Compute node 1 can then use this parameter to start Pod 1 via the first Docker daemon process 1, and execute the docker command 1 in pipeline task 1. Pod 1 can obtain the second socket file corresponding to the second Docker daemon process 1 based on the second socket file path 1, and then use the second Docker daemon process 1 to process the docker command 1.

[0319] The second processing data 1 generated by the second Docker daemon 1 during the execution of docker command 1 in Pod 1 will be independently stored in the second storage space 1-2 corresponding to the second data storage path 1 (e.g., " / var / lib / docker27.0.0"), which is isolated from the first storage space 1-1 corresponding to the first data storage path 1 of the first Docker daemon 1 in compute node 1 (e.g., " / var / lib / docker") (which stores the first processing data 1 generated by the first Docker daemon 1). After the execution of docker command 1 in Pod 1 is completed, compute node 1 can delete the second processing data 1 generated by the second Docker daemon 1 during the execution of docker command 1 (i.e., the data stored in the second storage space 1-2).

[0320] The Kubernetes cluster management plane can configure volume mount parameter 2 for compute node 51 and send this parameter to compute node 51. Compute node 51 can then start Pod2 via the first Docker daemon 51 based on volume mount parameter 2, and execute docker command 2 in pipeline task 2 via Pod2. Pod2 can obtain the second socket file 51 corresponding to the second Docker daemon 51 based on the second socket file path 51, and call the second Docker daemon 51 to process docker command 2 based on the second socket file 51.

[0321] The second processing data 2 generated by the second Docker daemon 51 during the execution of docker command 2 in Pod2 will be independently stored in the second storage space 51-2 corresponding to the second data storage path 51 (e.g., " / var / lib / docker27.0.0"), isolated from the first storage space 51-1 (which stores the first processing data 2 generated by the first Docker daemon 51) corresponding to the first data storage path 51 of the first Docker daemon 51 in compute node 51 (e.g., " / var / lib / docker"). After the execution of docker command 2 in Pod2 is completed, compute node 51 can delete the second processing data 2 generated by the second Docker daemon 51 during the execution of docker command 2 (i.e., the data stored in the second storage space 51-2).

[0322] Figure 6 For a schematic diagram of a task processing device provided in an embodiment of this application, please refer to [link / reference]. Figure 6 The task processing unit 600 can be applied to Figure 1A The management plane of the Kubernetes cluster shown includes multiple compute nodes; the task processing device 600 includes:

[0323] The transceiver module 601 is used to obtain task processing requests, which include Docker commands.

[0324] Processing module 602 is used to determine the target computing node among multiple computing nodes;

[0325] The transceiver module 601 is also used to send task processing requests to the target computing node; wherein, the target computing node has a first Docker daemon and a second Docker daemon deployed; when the type of the Docker command is to start and manage the container group Pod, the first Docker daemon is used to execute the Docker command; when the type of the Docker command is to create and manage task containers and image resources inside the Pod, the second Docker daemon is used to execute the Docker command.

[0326] The task processing apparatus provided in this application embodiment can execute the technical solution of the task processing method executed by the management plane described above, and its beneficial effects are similar, so they will not be described again here.

[0327] In one possible implementation, the processing module 602 is specifically used for:

[0328] If the task processing request includes the target version information corresponding to the docker command, the target node label is determined based on the target version information; the version information of the second Docker daemon corresponding to the target node label matches the target version information.

[0329] The target computing node is determined based on the target node label and the node labels of multiple computing nodes.

[0330] In one possible implementation, when the type of the docker command is to start and manage a Pod, the processing module 602 is also used to configure volume mount parameters;

[0331] The transceiver module 601 is also used to send volume mount parameters to the target computing node; wherein, the volume mount parameters are used to instruct the target computing node to mount the socket file path of the second Docker daemon to the communication path of the Pod during the process of starting the Pod through the first Docker daemon; the socket file path is used to obtain the socket file of the second Docker daemon, and the socket file is used for the process in the Pod to establish communication with the second Docker daemon.

[0332] Figure 7 For a schematic diagram of another task processing device provided in an embodiment of this application, please refer to [link / reference]. Figure 7 The task processing device 700 can be applied to compute nodes in a Kubernetes cluster; the Kubernetes cluster includes multiple compute nodes; a first Docker daemon and a second Docker daemon are deployed on the compute nodes; the first Docker daemon is used to start and manage container groups (Pods) on the compute nodes, and the second Docker daemon is used to handle Docker commands issued from within the Pods; the task processing device 700 includes:

[0333] The transceiver module 701 is used to receive task processing requests sent by the management plane in the K8S cluster, wherein the task processing requests include Docker commands;

[0334] Processing module 702 is used to execute docker commands using the first Docker daemon when the type of the docker command is to start and manage a container group Pod;

[0335] Processing module 702 is also used to execute docker commands using a second Docker daemon when the type of docker command is to create and manage task containers and image resources inside a Pod.

[0336] The task processing apparatus provided in this application embodiment can execute the technical solution of the task processing method executed by the computing node described above, and its beneficial effects are similar, so they will not be described again here.

[0337] In one possible implementation, the processing module is further configured to:

[0338] On the compute nodes, the first Docker daemon and the second Docker daemon are deployed in different storage directories respectively;

[0339] Configure independent running parameters for the first Docker daemon and the second Docker daemon respectively; wherein, the first running parameters configured for the first Docker daemon include the first data storage path and the first socket file path corresponding to the first Docker daemon, and the second running parameters configured for the second Docker daemon include the second data storage path and the second socket file path corresponding to the second Docker daemon;

[0340] Start the first Docker daemon and the second Docker daemon.

[0341] In one possible implementation, the processing module 702 is specifically used for:

[0342] The first socket file is obtained based on the path of the first socket file, and the first Docker daemon is called to process the docker command based on the first socket file. The first socket file is used to establish communication with the first Docker daemon.

[0343] Obtain the first processing data generated by the first Docker daemon during the processing of Docker commands, determine the first storage space based on the first data storage path, and store the first processing data in the first storage space.

[0344] In one possible implementation, the processing module 702 is further configured to:

[0345] The second socket file path is used to obtain the second socket file of the second Docker daemon, and communication is established with the second Docker daemon based on the second socket file. The second Docker daemon is also invoked to process docker commands. The second socket file path is independent of the first socket file path.

[0346] The second processing data generated by the second Docker daemon during the processing of Docker commands is obtained, and the second storage space is determined according to the second data storage path. The second processing data is stored in the second storage space, and the second data storage path is independent of the first data storage path.

[0347] After the docker command completes execution, delete the second processing data in the second storage space.

[0348] In one possible implementation, the first operating parameter further includes a first network resource; the processing module 702 is specifically used for:

[0349] Based on the first network resources, a first communication network environment is built in the computing node, and the first Docker daemon is used to execute Docker commands in the first communication network environment;

[0350] The second operating parameter also includes the second network resource; the processing module 702 is specifically used for:

[0351] A second communication network environment is built on the computing node based on the second network resources, and the second Docker daemon is used to execute Docker commands in the second communication network environment;

[0352] Among them, the first network resource and the second network resource are independent of each other, and the first communication network environment and the second communication network environment are isolated from each other.

[0353] In one possible implementation, the transceiver module 701 is further configured to receive volume mount parameters sent by the management plane when the type of the docker command is to start and manage a Pod.

[0354] The processing module 702 is also used to mount the second socket file path of the second Docker daemon to the communication path of the Pod during the process of starting the Pod using the first Docker daemon, according to the volume mount parameters; the second socket file path is used to obtain the second socket file of the second Docker daemon, and the second socket file is used for the process in the Pod to establish communication with the second Docker daemon.

[0355] Figure 8 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application. Please refer to [link / reference]. Figure 8 The computing device 800 can be a computing node or management plane as described in the above method embodiments. The computing device 800 may include a processor 801 and a memory 802, which are coupled together. The processor 801 and the memory 802 can communicate; for example, the processor 801 and the memory 802 communicate via a communication bus 803.

[0356] Memory 802 is used to store program instructions;

[0357] The processor 801 is used to execute program instructions to perform the technical solutions as shown in the above method embodiments.

[0358] Optionally, the processor mentioned above can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0359] This application provides a computer-readable storage medium storing computer-executable instructions; when executed by a processor, the computer-executable instructions are used to implement the task processing method shown in the above embodiments.

[0360] This application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it causes the computer to perform the task processing method shown in the above embodiments.

[0361] All or part of the steps in the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above-described method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0362] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable device, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0363] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0364] These computer program instructions may also be loaded onto a computer or other programmable device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable device, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0365] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of this application, and are not intended to limit them. Although the embodiments of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A task processing method, characterized in that, The method is applied to the management plane in a Kubernetes cluster; the Kubernetes cluster includes multiple compute nodes; the method includes: Obtain a task processing request, wherein the task processing request includes docker commands; Determine the target computing node from among the multiple computing nodes; The task processing request is sent to the target computing node; wherein, the target computing node has a first Docker daemon and a second Docker daemon deployed; when the type of the Docker command is to start and manage a container group Pod, the first Docker daemon executes the Docker command; when the type of the Docker command is to create and manage task containers and image resources inside the Pod, the second Docker daemon executes the Docker command.

2. The method according to claim 1, characterized in that, Based on the task processing request, the target computing node is determined from the plurality of computing nodes, including: If the task processing request includes target version information corresponding to the docker command, a target node label is determined based on the target version information; the version information of the second Docker daemon corresponding to the target node label matches the target version information. The target computing node is determined based on the target node label and the node labels of the multiple computing nodes.

3. The method according to claim 1 or 2, characterized in that, When the type of the docker command is to start and manage a Pod, the method further includes: Configure volume mount parameters and send the volume mount parameters to the target compute node; wherein, the volume mount parameters are used to instruct the target compute node to mount the socket file path of the second Docker daemon to the communication path of the Pod during the process of starting the Pod through the first Docker daemon; the socket file path is used to obtain the socket file of the second Docker daemon, and the socket file is used for the process in the Pod to establish communication with the second Docker daemon.

4. A task processing method, characterized in that, The method is applied to compute nodes in a Kubernetes cluster, wherein a first Docker daemon and a second Docker daemon are deployed on the compute node; the first Docker daemon is used to start and manage container groups (Pods) on the compute node, and the second Docker daemon is used to process Docker commands issued from within the Pods; the method includes: Receive a task processing request sent by the management plane in the K8S cluster, wherein the task processing request includes docker commands; When the type of the docker command is to start and manage a Pod, the docker command is executed using the first Docker daemon. When the type of the docker command is to create and manage task containers and image resources inside the Pod, the docker command is executed using the second Docker daemon.

5. The method according to claim 4, characterized in that, The method further includes: In the computing node, the first Docker daemon and the second Docker daemon are deployed in different storage directories respectively; Configure independent running parameters for the first Docker daemon and the second Docker daemon respectively; wherein, the first running parameters configured for the first Docker daemon include the first data storage path and the first socket file path corresponding to the first Docker daemon, and the second running parameters configured for the second Docker daemon include the second data storage path and the second socket file path corresponding to the second Docker daemon; Start the first Docker daemon and the second Docker daemon.

6. The method according to claim 5, characterized in that, Executing the docker command using the first Docker daemon includes: The first socket file of the first Docker daemon is obtained according to the first socket file path, and the first Docker daemon is called to process the docker command based on the first socket file. The first socket file is used to establish communication with the first Docker daemon. The system obtains the first processing data generated by the first Docker daemon during the processing of the Docker command, determines the first storage space based on the first data storage path, and stores the first processing data in the first storage space.

7. The method according to claim 5 or 6, characterized in that, Executing the docker commands using the second Docker daemon includes: The second socket file of the second Docker daemon is obtained according to the second socket file path, and communication is established with the second Docker daemon based on the second socket file, and the second Docker daemon is invoked to process the docker command. The second socket file path is independent of the first socket file path. The process obtains the second processing data generated by the second Docker daemon during the processing of the Docker command, determines the second storage space according to the second data storage path, and stores the second processing data in the second storage space, wherein the second data storage path is independent of the first data storage path. After the docker command is executed, the second processed data is deleted from the second storage space.

8. The method according to claim 5, characterized in that, The first operating parameters also include the first network resource; executing the Docker command using the first Docker daemon includes: Based on the first network resources, a first communication network environment is constructed in the computing node, and the first Docker daemon is used to execute the Docker command in the first communication network environment; The second operating parameters also include a second network resource; executing the docker command using the second Docker daemon includes: Based on the second network resources, a second communication network environment is constructed in the computing node, and the second Docker daemon is used to execute the Docker command in the second communication network environment; The first network resource and the second network resource are independent of each other, and the first communication network environment and the second communication network environment are isolated from each other.

9. The method according to any one of claims 4-8, characterized in that, The method further includes: When the type of the Docker command is to start and manage a Pod, the volume mount parameters sent by the management plane are received; According to the volume mount parameters, during the process of starting the Pod using the first Docker daemon, the second socket file path of the second Docker daemon is mounted to the communication path of the Pod; the second socket file path is used to obtain the second socket file of the second Docker daemon, and the second socket file is used for the process in the Pod to establish communication with the second Docker daemon.

10. A computing device, characterized in that, include: Processor and memory; The processor and the memory are coupled; The memory is used to store program instructions; The processor is used to execute the program instructions to implement the method as described in any one of claims 1 to 3, or any one of claims 4 to 9.

Images