A container image pre-warming method, system, device and storage medium
By introducing PreloadImageJob CRD and controller into the Kubernetes cloud-native cluster, automated preheating of container images is achieved, solving the problem of time-consuming image pulling and improving container startup speed and ease of operation.
Patent Information
- Application Number
- CN202411373124.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-29
- Publication Date
- 2025-11-21
- Estimated Expiration
- 2044-09-29
AI Technical Summary
In Kubernetes cloud-native clusters, the time-consuming process of pulling container images leads to slow container startup. Existing technologies lack automated image warm-up mechanisms and are difficult to integrate with CICD systems, making the operation cumbersome.
By introducing PreloadImageJob CRD and controller, the image preheating process is automated through the collaborative work of api-server, controller and agent, and the target node is selected and the image is pulled by the workloadSelector mechanism.
Significantly reduces container startup time, optimizes image pull time by over 70%, simplifies operation process, is suitable for complex deployment scenarios, and supports rapid image preheating.
Smart Images

Figure CN119336446B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of operation control of software application, more particularly, it relates to a container image preheating method, system, device and storage medium. BACKGROUND
[0002] In the Kubernetes cloud native cluster, after the container group resource is created, the image is pulled after the scheduling, volume mounting, network allocation and other operations. That is to say, the optimization of the startup time of a container group is key to the optimization of two parts of time, one part is the configuration time of storage and network, and the other part is the image pulling time. If the image of the sidecar container and the base image of the business container can be pulled in advance on the node, the Pod (container group) creation process can be greatly shortened, and the time consumption of image pulling can be optimized by more than 70%.
[0003] In the current Kubernetes cloud native cluster, Kubernetes itself does not provide any image-oriented operation capability. Only by manually running the image pulling operation in advance on the node can the problem of slow container startup caused by time-consuming image pulling be solved.
[0004] In the current standard Kubernetes cluster, in order to preheat the image of some workloads to the corresponding node in advance, the nodeselector and nodename fields of the workloads need to be extracted first, and then the node that is likely to run is determined, and then the corresponding node is logged in to run the image pulling operation. This set of operations is relatively cumbersome, and cannot achieve the purpose of rapid preheating combined with the CICD (Continuous Integration, Continuous Deployment) system. SUMMARY
[0005] The technical problem to be solved by the present application is to solve the above-mentioned deficiencies of the prior art. The first object of the present application is to provide a container image preheating method, which can automatically preheat the image to the node corresponding to the workload, simplify the user operation, and achieve the purpose of pulling the image in advance on the node, greatly reducing the startup time of the container.
[0006] The second object of the present application is to provide a container image preheating system.
[0007] The third object of the present application is to provide a computer device.
[0008] The fourth object of the present application is to provide a computer storage medium.
[0009] In order to achieve the first object, the present application provides a container image preheating method, comprising the following steps:
[0010] Step 1. Load and run the api-server on the Kubernetes cloud-native cluster, making the api-server the control entry point of the Kubernetes cloud-native cluster, and accept control requests through the api-server;
[0011] Step 2. Add a new resource controller to the Kubernetes cloud-native cluster. The controller listens to the PreloadImageJob resource and populates the status field according to the specific configuration of the PreloadImageJob resource. Add an agent to each node. The agent can interact with CRI to perform specific image pull operations.
[0012] Step 3. After the api-server receives a creation request of type PreloadImageJob and the controller detects that a PreloadImageJob resource has been created, it identifies the workloadSelector field of the PreloadImageJob resource and obtains the kind and name fields contained under the workloadSelector field.
[0013] Step 4. Select the corresponding workload based on the kind and name fields. The controller extracts the nodeSelector, affinity, and tolerations fields of the workload and then selects the nodes. All possible node names are then written into the status.node field.
[0014] Step 5. Listen to the status.node field of PreloadImageJob through the agent on the selected node. If a corresponding node is written, perform the image retrieval operation. Specifically, retrieve the corresponding image based on the spec.image field in the PreloadImageJob resource.
[0015] As a further improvement, a Master Node is used as the control node. The control node is not responsible for running workloads, but is responsible for running the api-server, Controller Manager, and Scheduler. Worker Nodes are used as worker nodes, and each worker node runs the Kubelet component and multiple container groups as workloads.
[0016] Furthermore, the api-server is connected to the distributed database etcd for configuring various resources and storing state within the cluster.
[0017] Furthermore, each node contains a Kubelet component, which acts as a proxy for communication between the node and the Kubernetes cloud-native cluster, and as a management component for workload container groups on the management node; among them, the api-server, as the control component of the Kubernetes cloud-native cluster, can receive requests for adding, modifying, deleting, and listening to Node type resources, and reflect the modifications in etcd.
[0018] To achieve the second objective mentioned above, the present invention provides a container image preheating system, comprising:
[0019] The startup module is used to load and run the api-server in the Kubernetes cloud-native cluster, making the api-server the control entry point of the Kubernetes cloud-native cluster and accepting control requests through the api-server.
[0020] A new module is added to add a new type of resource controller in the Kubernetes cloud-native cluster. The controller listens to the PreloadImageJob resource and populates the status field according to the specific configuration of the PreloadImageJob resource. A new agent is added to each node, which can interact with CRI to perform specific image pull operations.
[0021] The field recognition module is used to identify the workloadSelector field of the PreloadImageJob resource after the api-server receives a creation request of type PreloadImageJob and the controller listens for the creation of PreloadImageJob resource, and obtain the kind and name fields contained under the workloadSelector field.
[0022] The node selection module is used to select the corresponding workload based on the kind and name fields. The controller extracts the nodeSelector, affinity, and tolerations fields of the workload and then selects the node, and writes all possible node names into the status.node field.
[0023] The pull module is used to listen to the status.node field of PreloadImageJob through the agent on the selected node. If a corresponding node is written, the image pull operation is performed. Specifically, the corresponding image is pulled according to the spec.image field in the PreloadImageJob resource.
[0024] To achieve the above-mentioned objective three, the present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-mentioned container image preheating method.
[0025] To achieve the fourth objective mentioned above, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described container image preheating method.
[0026] Beneficial effects
[0027] Compared with the prior art, the advantages of this invention are as follows:
[0028] 1. This invention can automate image preheating. By introducing PreloadImageJobCRD and the corresponding controller, the image preheating process is automated. Users only need to create PreloadImageJob resources, and the system can automatically preheat the image on the relevant nodes, which greatly simplifies the operation process.
[0029] 2. This invention uses a workloadSelector mechanism, which allows users to flexibly select the workloads that need to be warmed up, making it suitable for various complex deployment scenarios.
[0030] 3. This invention can improve container startup speed. By pre-pulling images on nodes that may run workloads, this invention significantly reduces the image pull time during container startup, optimizing image pull time by more than 70%, and greatly improving container startup speed. Attached Figure Description
[0031] Figure 1 Architecture diagram for warming up container images based on Kubernetes cloud-native clusters;
[0032] Figure 2 This is an architecture diagram of the control node and worker nodes. Detailed Implementation
[0033] The present invention will be further described below with reference to specific embodiments shown in the accompanying drawings.
[0034] See Figures 1-2 A container image warm-up method includes the following steps:
[0035] Step 1. Load and run the api-server (Application Programming Interface Server) in the Kubernetes cloud-native cluster, making the api-server the control entry point of the Kubernetes cloud-native cluster, and accept control requests through the api-server;
[0036] Step 2. Add a new resource controller to the Kubernetes cloud-native cluster. The controller listens to the PreloadImageJob resource and populates the status field according to the specific configuration of the PreloadImageJob resource. Add an agent to each node. The agent can interact with CRI (Container Runtime Interface) to perform specific image pull operations.
[0037] Step 3. After the api-server receives a creation request of type PreloadImageJob and the controller detects that a PreloadImageJob resource has been created, it identifies the workloadSelector field of the PreloadImageJob resource and obtains the kind and name fields contained under the workloadSelector field.
[0038] Step 4. Select the corresponding workload based on the kind and name fields. The controller extracts the nodeSelector, affinity, and tolerations fields of the workload and then selects the nodes. All possible node names are then written into the status.node field.
[0039] Step 5. Listen to the status.node field of PreloadImageJob through the agent on the selected node. If a corresponding node is written, perform the image pull operation. Specifically, pull the corresponding image according to the spec.image field in the PreloadImageJob resource. That is, the agent interacts with CRI (Container Runtime Interface) to implement the specific image pull operation.
[0040] like Figure 1 , Figure 2As shown, three Master Nodes are used as control nodes, which are not responsible for running workloads. The control nodes are responsible for running the API server, Controller Manager, and Scheduler. N Worker Nodes are used as worker nodes, each running the Kubelet component and multiple container groups as workloads.
[0041] Each Master Node's api-server connects to the distributed database etcd for configuring various resources and storing state within the cluster.
[0042] Each node contains a Kubelet component, which acts as a proxy for communication between the node and the Kubernetes cloud-native cluster, and as a management component for workload container groups on the management node. Among them, the api-server, as the control component of the Kubernetes cloud-native cluster, can receive requests for adding, modifying, deleting, and listening to Node type resources, and reflect the modifications in etcd.
[0043] In this embodiment, as Figure 1 As shown, for example, a PreloadImageJob resource is submitted to the api-server to specify the corresponding workload, which is Deployment-0 in this embodiment, and the image names that need to be preheated, namely image-0 and image-1.
[0044] The controller detects the creation of the PreloadImageJob resource and obtains the nodeSelector field from the specified workload Deployment-0.
[0045] The hostname of the workload, node-0, is matched with the node's tag and written to the status field of PreloadImageJob.
[0046] When the agent component on node-0 detects an update to the status of the PreloadImageJob resource, and obtains the status.node field as node-0, which matches the name of this node.
[0047] The agent component on node-0 obtains the spec.image of PreloadImageJob as image-0 and image-1, and sends a request to CRI to pull images image-0 and image-1.
[0048] The corresponding runtime will implement the CRI pull image interface and perform the pull image operation. At this point, the preheating of images image-0 and image-1 is completed on node-0.
[0049] A container image preheating system, comprising:
[0050] The startup module is used to load and run the api-server in the Kubernetes cloud-native cluster, making the api-server the control entry point of the Kubernetes cloud-native cluster and accepting control requests through the api-server.
[0051] A new module is added to add a new type of resource controller in the Kubernetes cloud-native cluster. The controller listens to the PreloadImageJob resource and populates the status field according to the specific configuration of the PreloadImageJob resource. A new agent is added to each node, which can interact with CRI to perform specific image pull operations.
[0052] The field recognition module is used to identify the workloadSelector field of the PreloadImageJob resource after the api-server receives a creation request of type PreloadImageJob and the controller listens for the creation of PreloadImageJob resource, and obtain the kind and name fields contained under the workloadSelector field.
[0053] The node selection module is used to select the corresponding workload based on the kind and name fields. The controller extracts the nodeSelector, affinity, and tolerations fields of the workload and then selects the node, and writes all possible node names into the status.node field.
[0054] The pull module is used to listen to the status.node field of PreloadImageJob through the agent on the selected node. If a corresponding node is written, the image pull operation is performed. Specifically, the corresponding image is pulled according to the spec.image field in the PreloadImageJob resource.
[0055] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the above-described container image preheating method.
[0056] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described container image warm-up method.
[0057] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention, and these will not affect the effectiveness of the implementation of the present invention or the practicality of the patent.
Claims
1. A container image preheating method, characterized in that, Includes the following steps: Step 1. Load and run the api-server on the Kubernetes cloud-native cluster, making the api-server the control entry point of the Kubernetes cloud-native cluster, and accept control requests through the api-server; Step 2. Add a resource controller in the Kubernetes cloud-native cluster. The controller listens to the PreloadImageJob resource and populates the status field according to the specific configuration of the PreloadImageJob resource. Add an agent on each node and interact with CRI through the agent to realize the specific image pull operation. Step 3. After the api-server receives a creation request of type PreloadImageJob and the controller detects that a PreloadImageJob resource has been created, it identifies the workloadSelector field of the PreloadImageJob resource and obtains the kind and name fields contained under the workloadSelector field. Step 4. Select the corresponding workload based on the kind and name fields. The controller extracts the nodeSelector, affinity, and tolerations fields of the workload, selects nodes, and writes the obtained node names into the status.node field. Step 5. Listen to the status.node field of PreloadImageJob through the agent on the selected node. If a corresponding node is written, perform the image retrieval operation. Specifically, retrieve the corresponding image based on the spec.image field in the PreloadImageJob resource.
2. The container mirror preheating method according to claim 1, characterized in that, The Master Node is used as the control node. The control node is not responsible for running the workload. The control node is responsible for running the api-server, ControllerManager, and Scheduler. The Worker Node is used as the worker node. Each worker node runs the Kubelet component and multiple container groups as workloads.
3. The container mirror preheating method according to claim 1, characterized in that, The api-server is connected to the distributed database etcd and is used for various resource configurations and state storage within the cluster.
4. The container mirror preheating method according to claim 3, characterized in that, Each node contains a Kubelet component, which acts as a proxy for communication between the node and the Kubernetes cloud-native cluster, and as a management component for workload container groups on the management node. Among them, the api-server, as the control component of the Kubernetes cloud-native cluster, can receive requests for adding, modifying, deleting, and listening to Node type resources, and reflect the modifications in etcd.
5. A container mirror preheating system, characterized in that, include: The startup module is used to load and run the api-server in the Kubernetes cloud-native cluster, making the api-server the control entry point of the Kubernetes cloud-native cluster and accepting control requests through the api-server. A new module is added to add resource controllers in Kubernetes cloud-native clusters. The controllers listen to the PreloadImageJob resource and populate the status field according to the specific configuration of the PreloadImageJob resource. An agent is added to each node to interact with CRI to perform specific image pull operations. The field recognition module is used to identify the workloadSelector field of the PreloadImageJob resource after the api-server receives a creation request of type PreloadImageJob and the controller listens for the creation of PreloadImageJob resource, and obtain the kind and name fields contained under the workloadSelector field. The node selection module is used to select the corresponding workload based on the kind and name fields. The controller extracts the nodeSelector, affinity, and tolerations fields of the workload, selects the node, and writes the obtained node name into the status.node field. The pull module is used to listen to the status.node field of PreloadImageJob through the agent on the selected node. If a corresponding node is written, the image pull operation is performed. Specifically, the corresponding image is pulled according to the spec.image field in the PreloadImageJob resource.
6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements a container image preheating method according to any one of claims 1-4.
7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements a container image preheating method according to any one of claims 1-4.
Citation Information
Patent Citations
Container mirror image preheating method, electronic equipment and storage medium
CN116781719A
Service-managed containers for container orchestration service
US11392422B1