A container image pulling method, device, electronic device, medium and product

Abstract

The present application discloses a container image pulling method, device, electronic device, medium and product, which relate to the technical field of storage systems. The method includes: first obtaining node data and container image data in response to a user's service creation operation, screening out at least one target node where a service needs to be deployed by analyzing the node data and container image data, and then pulling the required container image to the target node instead of indiscriminately covering all nodes, thereby achieving accurate pulling of container images, avoiding invalid pulling operations of irrelevant nodes, shortening service deployment time, and optimizing storage resource allocation.

Description

Technical Field

[0001] The present application relates to the technical field of storage systems, and in particular to a method, device, electronic device, medium, and product for pulling container images. Background Art

[0002] In a Kubernetes cluster, the proper startup of a container group (Pod) relies on the node agent (kubelet) pulling the container image. Specifically, after the scheduler selects the target node, the kubelet checks the local image cache. If the image is missing, it pulls it from the image repository. Only after this check is complete can the container be started. In practice, in scenarios involving large images, high-concurrency deployments, limited network bandwidth, and cross-region or hybrid cloud deployments, the container image pull phase accounts for 30%-70% of the entire Pod startup time, significantly impacting service deployment efficiency and system response speed, becoming a bottleneck for rapid scaling, fault recovery, and rolling upgrades.

[0003] Currently, static pre-pull techniques are primarily used for pre-fetching container images. For example, users manually pre-pull commonly used images from the image repository on all nodes, or use DaemonSets and InitContainers to execute image pulls (docker pull) on each node. While this method is simple and suitable for small-scale clusters, indiscriminate pre-pull results in wasted storage resources. Summary of the Invention

[0004] The present application provides a container image pulling method, device, electronic device, medium and product to at least solve the problem of storage resource waste caused by static pre-pulling in the related art.

[0005] The present application provides a method for pulling a container image, comprising: in response to a user's service creation operation, obtaining node data of the node where the service is located and container image data corresponding to the service; determining at least one target node for deploying the service from the node where the service is located based on the node data and the container image data; obtaining a container image corresponding to the container image data; and pulling the container image to a matching target node.

[0006] This application also provides a container image pulling device, including:

[0007] A data acquisition module is used to obtain the node data of the node where the service is located and the container image data corresponding to the service in response to the user's service creation operation;

[0008] A node determination module is used to determine at least one target node for deploying a service from among the nodes where the service is located based on the node data and the container image data;

[0009] A container image acquisition module is used to obtain the container image corresponding to the container image data;

[0010] The pull module is used to pull the container image to the matching target node.

[0011] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned container image pulling methods when executing the computer program.

[0012] The present application also provides a non-volatile computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned container image pulling methods are implemented.

[0013] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned container image pulling methods when the computer program is executed by a processor.

[0014] In response to the user's service creation operation, this application first obtains node data and container image data, screens out at least one target node where the service needs to be deployed by analyzing the node data and container image data, and then pulls the required container image to the target node instead of indiscriminately covering all nodes, thereby achieving accurate pulling of container images, avoiding invalid pulling operations of irrelevant nodes, shortening service deployment time, and optimizing storage resource allocation. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0016] Figure 1 A schematic diagram of the hardware architecture for executing a container image pulling method provided in an embodiment of the present application;

[0017] Figure 2 A schematic diagram of a process for pulling a container image provided in an embodiment of the present application;

[0018] Figure 3 A schematic diagram of pulling a container image provided in an embodiment of the present application;

[0019] Figure 4 A schematic diagram of the structure of a device for pulling container images provided in an embodiment of the present application;

[0020] Figure 5A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0021] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0022] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0023] In order to more clearly illustrate the embodiments of the present application, the following briefly introduces the technical terms used in the embodiments:

[0024] Kubernetes (K8s) is an open-source container orchestration engine for automating the deployment, scaling, and management of containerized applications. It organizes multiple containers and their dependencies into logical units, enabling resource scheduling, service discovery, load balancing, and fault recovery, helping enterprises manage distributed applications more efficiently.

[0025] Harbor is an open-source container image repository management platform for storing, distributing, and managing container images, including Docker images. It provides image upload and download capabilities, version management, permission control, vulnerability scanning, and replication, supporting secure image management in private cloud environments.

[0026] A pod is the smallest scheduling unit in Kubernetes. It consists of one or more closely related containers, typically sharing network and storage resources. Each pod represents an independent application instance and can contain multiple containers working together.

[0027] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0028] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the container image pulling method depends, the specific application environment architecture or specific hardware architecture is described here.

[0029] Application environment architecture: Container orchestration and scheduling system, image repository system, and service discovery and configuration management components. The container orchestration platform receives user service creation requests and obtains node data and container image data. It supports node selection strategies to determine target nodes and provides image pull lifecycle management. The image repository stores container image data and provides an Application Programming Interface (API) for image pull. The pull method obtains image layer data through image repository authentication and supports optimization mechanisms such as breakpoint resumption and incremental pull. Distributed key-value storage is used to store dynamic information such as node status and image metadata, ensuring that the pull method can obtain node health status and image version information in real time.

[0030] The hardware architecture includes: compute node hardware configuration, network architecture and bandwidth, and image repository node hardware. The central processing unit (CPU) and memory must meet basic container runtime requirements and support resource scheduling when pulling multiple images in parallel. Local disks must have sufficient capacity to store image layer data, and high-speed storage should be used to reduce image decompression and loading time. Volume sharing is supported. If the target node pulls images via network storage, low latency and high bandwidth must be ensured for the storage network. Nodes must communicate via a Layer 2 / Layer 3 network to ensure that the target node can access the image repository. Image pull requests must be distributed using a load balancer to avoid overloading a single repository node. The image repository node must be configured with high-IOPS storage to support concurrent reads of a large number of image layers. The CPU and memory must be sufficient to handle multiple pull requests simultaneously, avoiding slowdowns due to repository node performance bottlenecks.

[0031] like Figure 1 As shown, Figure 1 Schematic diagram of the hardware architecture of the method for executing container image pulling provided in an embodiment of the present application. A data acquisition module is used to obtain container image data, service data, and node data. A node acquisition and analysis module is used to derive at least one target node where the container image service may run based on the node data and container image data. A container image pulling module is used to pre-pull container images from at least one image repository or local node, and dynamically set the concurrency when pulling from at least one image repository. A monitoring and feedback module is used to monitor container image pre-pull tasks, image repositories, and node status.

[0032] An embodiment of the present application provides a method for pulling a container image. The method is described in detail in conjunction with the execution flow of the method for pulling a container image.

[0033] like Figure 2 As shown, Figure 2 A flowchart of a method for pulling a container image provided in an embodiment of the present application is provided. The method includes the following steps S201 to S204:

[0034] S201. In response to a user's service creation operation, obtain node data of the node where the service is located and container image data corresponding to the service.

[0035] In some embodiments, users can create services on the inference platform. In response to the service creation operation, the inference platform stores service data in a database. Service data includes, but is not limited to, service identifiers (IDs), service names, namespaces, status, container images, resource information, launch time, last used time, total number of requests, and user information. The database can be a distributed database, such as a relational (Structured Query Language, MySQL) cluster database or a distributed key-value store.

[0036] After a service is created, the inference platform instantiates a container group (Pod) based on a container orchestration framework like Kubernetes. A service can have multiple container groups, which determines which container group the service data corresponds to. Multiple container groups can run on different nodes, so the node where the service resides is determined based on the service's container group. There are multiple nodes where a service resides. Node data for these service nodes is then obtained.

[0037] In the above embodiment, when a user creates a service on the inference platform, node data is obtained in response to the service creation operation to ensure that the service is deployed to a suitable node and to avoid node overload.

[0038] In some embodiments, in response to the user's container image upload operation, the inference platform stores the container image data uploaded by the user; some container image data is stored in the database, and the container image data uploaded by the user is added to the database as an increment. The container image data and service data are stored correspondingly in the database. The container image data corresponding to the service created by the user is obtained from the database, which may include the original container image data in the database and the data of the container image uploaded this time. Among them, the container image data includes: container image label, container image id, container image name, container image size, upload completion time, pre-pull status, user information, etc. In the above embodiment, the container image data and service data are independently created in the table to avoid data redundancy, and also support independent expansion to cope with high concurrency scenarios.

[0039] S202: Determine at least one target node for deploying the service from the nodes where the service is located based on the node data and the container image data.

[0040] Based on the node data of multiple service nodes and the container image data corresponding to the services, at least one target node that may deploy the service is selected from the multiple nodes. Filtering out nodes where the service will not be deployed helps reduce service startup time.

[0041] In some embodiments, when executing step S202, a service deployment probability is first calculated based on the node data of the server node and the container image data corresponding to the service. The service deployment probability represents the probability of deploying the service on a particular node. Then, nodes whose deployment probabilities satisfy preset conditions among the service nodes are selected as target nodes. The number of target nodes is greater than or equal to one.

[0042] Based on the node data of the server node and the corresponding container image data for the service, we quantitatively analyze the compatibility of node resources with service operation requirements, and construct a probabilistic model to guide service deployment on the node. Calculating the service deployment probability provides a weighted score for the compatibility between the node and the service. For example, if a node's remaining CPU resources reach 120% of the service demand, the corresponding deployment probability will be significantly higher than that of a node nearing resource saturation. Once the probability calculation is complete, nodes with probability values ​​exceeding a preset threshold are selected as target nodes. These nodes must simultaneously meet multiple conditions, including resource availability, compatibility, and load balancing.

[0043] The above embodiment calculates the service deployment probability by combining the node data of the service's node with the container image data corresponding to the service. Nodes whose deployment probabilities meet pre-set conditions are selected as target nodes. This optimizes resource allocation, improves utilization, and reduces costs. Compared to traditional methods, it can better balance load, match hardware requirements, and reduce network latency.

[0044] Based on the above embodiment, the service deployment probability is calculated based on the container image tag in the container image data and the matching tag in the node data. The method includes: first determining whether the container image data includes the container image tag; if so, further determining whether the node data includes a matching tag, where a matching tag refers to a tag that matches the container image tag. If no tag in the node data matches the container image tag, then determining the service deployment probability to be a first probability value.

[0045] It is understood that when a container image tag is detected in the container image data, a further check is performed to determine whether a matching tag exists in the node data. A matching tag here refers to the node tag that corresponds to the container image tag. If the node data does not contain a matching tag, the probability of deploying the service on that node is determined to be the first probability value.

[0046] Specifically, the embodiment of the present application sets the LABEL field value of the container image. In the case where the container image data includes container image labels, the LABEL field value is set to nodeSelector to determine whether the node data of the node where a service is located includes a matching label. If not, it means that the container image will not be pulled to the current node, and the service deployment probability S i is the first probability value, for example, S i = 0. The zero-probability setting forms a clear deployment blocking mechanism, avoiding subsequent failures caused by environmental incompatibility, enhancing the reliability of service deployment and the standardization of cluster management.

[0047] The above embodiment first determines whether the container image data contains a label. If so, it further checks whether the node data contains a matching label. If the node does not have a matching label, the service deployment probability is set to a first probability value of 0. This mechanism enables accurate service and node label matching and screening. This prevents services from being deployed to nodes that do not support their label requirements. By quickly filtering invalid nodes through labels, invalid deployment attempts are reduced and deployment efficiency is improved. Enforced label matching rules ensure consistency in the service deployment environment.

[0048] If the container image data includes a container image tag, and the node data includes a matching tag, it means that the node where the current service is located has a tag that matches the container image tag, and the service deployment probability of the node can be determined to be the second probability value. The container image will pull the current node, and the service deployment probability S i = 1. Then, the node with the service deployment probability of the second probability value among the nodes where the service is located is selected as the target node. The selected target nodes meet the label compatibility requirements and form a set of candidate nodes for scheduling.

[0049] It can be understood that when the system detects that the container image data contains a container image label, such as the nodeSelector field defined by the LABEL instruction of the Dockerfile, and there is a corresponding matching label in the node data, the service deployment probability of the node is assigned to the second probability value (such as Si=1), which means that the node meets the basic conditions for service deployment and the container image can be pulled to the node and run.

[0050] By judging the label in the container image data and the matching label in the node data, when both exist, the node service deployment probability is set to the second probability value such as S i = 1 and uses it as the target node. This mechanism enables precise matching of services and nodes for deployment. This ensures that container images are pulled to the appropriate node based on label matching, avoiding deployment failures due to environmental incompatibility. Setting the deployment probability directly to 1 creates a strong priority deployment strategy, ensuring that core services are quickly located on the optimal node, improving deployment efficiency.

[0051] In the above embodiment, if a container image defines a container image tag, the tag matching mechanism enables categorized management of cluster resources, facilitating precise service scheduling based on characteristics and optimizing resource utilization. Services are allowed to be deployed to nodes matching the tag; otherwise, the probability of service deployment is zero. This clear probability assignment rule simplifies the deployment decision-making process, enabling the system to quickly select target nodes and enhancing the real-time and reliability of cluster scheduling.

[0052] In other embodiments, the service deployment probability is calculated based on the container image label in the container image data, and the number of node container groups and node resource indicators in the node data, including: when the container image data does not include the container image label and the node data does not include the number of node container groups, it means that there is no container group at the node, and the service deployment probability is calculated based on the node resource indicators.

[0053] It is understandable that if the container image data does not contain any container image labels for node screening, and the node data does not include the number of node container groups, it means that the node is not currently running any container groups and is in a resource-idle state. The feasibility is evaluated by quantifying the degree of match between node resources and service resource requirements. If the node's remaining CPU resources reach 150% of the service demand and there is sufficient memory, the deployment probability may be assigned a higher value; conversely, if the resources are close to saturation, the probability is correspondingly reduced. The numerical probability value converts the node resource availability into a comparable scheduling basis, ensuring that when there are no additional conditions such as label matching, the service can still be deployed to the appropriate node based on the principle of resource optimization, avoiding deployment blindness due to missing information.

[0054] The process of calculating the service deployment probability based on the node resource index includes: first, calculating the average resource utilization of the node based on the node resource index, and then calculating the service deployment probability based on the average resource utilization and the first weight coefficient. The corresponding average resource utilization can be calculated according to each node resource index, and then the service deployment probability is calculated based on the average resource utilization and its corresponding first weight coefficient. Optionally, the node resource index includes the available central processing unit and the total amount of central processing unit of the node, the available node memory, the total node memory, the available node storage and the total node storage. Node resources may also include other resources, which are not specifically limited in this application.

[0055] From a resource adaptation perspective, different services have varying resource requirements. For example, database services have high storage and memory requirements, while compute-intensive services rely more heavily on the CPU. By calculating average utilization based on each node's resource metrics and combining weights for different resource types, we can precisely match services with node resource characteristics, fully leveraging node resource advantages and improving service efficiency.

[0056] It is also possible to calculate the resource utilization of all node resource indicators and then average them to obtain the average resource utilization, and then calculate the service deployment probability in combination with the pre-set first weight coefficient. In this way, when the container image has no label and the node has no container group, the idleness of the node resources is quantified, and then the node deployment service probability is calculated by weighted average. Among them, the first weight coefficient can be determined according to the number of types of node resource indicators. Differentiated priorities are given to different resource types by weight coefficients, and resources can be concentratedly allocated to the services that need them most. For example, for big data analysis services, the CPU and memory weights are increased, and nodes with sufficient resources of this type are preferentially allocated to the service, so as to achieve refined resource management and avoid low utilization due to resource mismatch, thereby improving the resource utilization of the entire system.

[0057] The above embodiment calculates the average node resource utilization, accurately reflecting the load status of each node. This avoids the problem of some nodes being resource-constrained or idle due to traditional static allocation, achieves a dynamic and balanced distribution of services within the cluster, and effectively improves the overall stability and reliability of the cluster.

[0058] Optionally, calculate the service deployment probability according to the following formula (1): S i :

[0059] (1)

[0060] In formula (1), C i-available is the CPU availability of node i, C i-totalis the total number of CPUs, M i-available is the amount of available node memory, M i-total is the total amount of node memory, D i-available is the available storage capacity of the node, D i-total is the total amount of node storage. Service deployment probability S i A larger value indicates that the node resources are more idle and more suitable for deploying services.

[0061] Formula (1) gives equal weight scores to the node's central processing unit, node memory, and node storage resources, indicating that the node with the highest average utilization of these three resources is preferred for service deployment. This avoids overloading other resources by only considering a single resource. Nodes with a service deployment probability greater than a preset probability value are then selected as target nodes. The preset probability value can be 0.67 to filter out nodes with insufficient resources, ensuring that there are sufficient resources to run the service after deployment, and reducing service anomalies caused by resource exhaustion. This application does not specifically limit this.

[0062] The above calculation combines container image labels, the number of node container groups, and resource indicators to calculate the service deployment probability. When there are no labels and no container groups, the availability of CPU, memory, and storage is weighted according to the formula to achieve multi-dimensional resource balanced scheduling.

[0063] If the container image data does not include a container image tag and the node data includes the number of container groups, the service deployment probability is calculated based on the number of container groups and node resource metrics. If the container image does not include a container image tag for node selection, and the node data explicitly includes the number of container groups, the service deployment probability calculation logic integrates the node's current load and basic resource metrics. The absence of a container image tag for node selection means that the service has no specific requirements for the node's hardware model, software environment, or other requirements and can be deployed on any node that meets the basic resource requirements. The number of container groups on a node directly reflects the number of container groups currently running on a node and is a core indicator of node load. The greater the number of container groups, the higher the percentage of node resources occupied, and the greater the risk of deploying new services. Services can be preferentially deployed to nodes with fewer container groups and sufficient resources to avoid imbalanced node load within the cluster.

[0064] Optionally, in the process of calculating the service deployment probability based on the number of node container groups and the node resource indicators, the container group density is first calculated based on the number of node container groups and the total number of container groups in the cluster to which the node belongs, and then the average resource utilization of the node is calculated based on the node resource indicators. Finally, the service deployment probability is calculated based on the container group density, the average resource utilization and the second preset weight coefficient.

[0065] Container group density reflects the relative concentration of container groups on a node. This improves dynamic node load perception. When the container group density on a node is too high, even if average resource utilization is low, this metric reduces the probability of service deployment. This prevents excessive concentration of new services on a small number of nodes and prevents the emergence of hot nodes. By balancing the distribution of container groups across the cluster, service load is effectively dispersed, improving overall cluster load balancing and ensuring stable service operation.

[0066] The second preset weight coefficient can be a sequence of weight coefficients that include container group density and the average utilization of various types of resources. Different types of services have different requirements for resources and container group deployment environments. For distributed services that require high levels of collaborative work with container groups, nodes with moderate container group density and sufficient resources tend to be selected; lightweight independent services can be deployed on nodes with low container group density and reasonable resource utilization. By combining the second weight coefficient to perform differentiated weighting of container group density and average resource utilization, it is possible to flexibly adapt to the characteristics of various services, improve the matching degree between services and node resources, give full play to the effectiveness of node resources, and improve service operation efficiency.

[0067] In the above embodiment, when container image data does not include container image tags and node data includes the number of node container groups, the node status is comprehensively evaluated from two dimensions: container group distribution and resource utilization. The service deployment probability is determined based on the node's actual load capacity. Comprehensively considering container group density and average resource utilization can more efficiently utilize cluster resources. The container group density indicator can promptly reflect the load pressure on the node, and deployment strategies can be adjusted in conjunction with resource utilization to ensure stable service deployment and operation.

[0068] Here, the node resource indicators may include the node's available CPU and total CPU capacity, the node's available memory and total memory capacity, the node's available storage and total storage capacity, and the total number of container groups in the cluster to which the node belongs. The second preset weight coefficient may be [1, 3, 2, 1], representing the weight ratio of each computing element.

[0069] Optionally, the service deployment probability is calculated according to the following formula (2):

[0070] (2)

[0071] In formula (2), D i is the number of node container groups, is a node i The total number of container groups in the cluster.

[0072] Formula (2) indicates that as the cluster load increases, the remaining resources of the nodes where services have been deployed are gradually utilized to improve resource utilization. Nodes with fewer container groups are prioritized to avoid resource fragmentation or scheduling congestion caused by too many container groups on a single node. When a node has container groups, the CPU, memory, and storage weights are allocated in a 3:2:1 ratio, prioritizing the availability of computing resources and adapting to compute-intensive services. At the same time, by standardizing the number of container groups, the scheduling policy is linked to the global cluster load.

[0073] In the above embodiment, when a container image has no labels but a node has container groups, this mechanism calculates the deployment probability by combining the number of node container groups with resource indicators such as CPU, memory, and storage. This mechanism can achieve load balancing of cluster resources and control the density of container groups. This ensures a multi-dimensional dynamic balance of node resources for deployed services, avoids single-point overload, prioritizes unloaded nodes, and progressively fills loaded nodes. This quantitative formula avoids subjective bias in manual scheduling, improving cluster resource utilization and service stability.

[0074] Based on the above embodiment, the service deployment probability can be calculated according to the following formula (3):

[0075] (3)

[0076] In formula (3), fi is calculated as follows (4).

[0077] (4)

[0078] By combining formulas (3) and (4) to calculate the service deployment probability, this mechanism constructs a multi-dimensional hierarchical scheduling strategy, achieving progressive node screening from label matching to resource balancing. When the image has a label but the node does not have a matching label, the deployment probability is directly set to 0 to avoid deploying the service to an incompatible environment, eliminating startup failures or performance anomalies caused by the lack of environment from the source. When the image label matches the node label, the resource calculation is skipped and the subsequent probability calculation is directly entered, improving scheduling efficiency. Through quantitative formulas, resource utilization and container group density are converted into comparable probability values. Combined with preset thresholds such as probability > 0.67, the target node is selected to ensure that there are sufficient resources to support the operation of the service after deployment, reducing service avalanches caused by resource exhaustion. From the strongly constrained scenario of label matching to the dynamic balance based on resources and container group density when there are no labels, a standardized scheduling process is formed to reduce the cost of manual intervention.

[0079] The above embodiment determines at least one target node where the service needs to be deployed, and only then will these nodes pull the container image. Avoiding pulling the container image to all nodes can reduce resource waste and improve service deployment efficiency.

[0080] In some embodiments, at least one target node may be selected based on the node resources included in the node data and the resource amount of the service request, or based on the service configuration rule.

[0081] S203: Obtain the container image corresponding to the container image data.

[0082] In some embodiments, container images are pre-pulled from image repositories and / or nodes that have already pulled the same container image. There can be at least one image repository harbor. It is understood that multiple container image repositories and nodes that have already pulled the same container image can serve as sources for pulling a particular container image. This multi-source pull mechanism can significantly improve container deployment efficiency and cluster stability.

[0083] Before a container image is pulled to the first target node, if the container image has been pulled to the second target node, the second target node can be used as the source of the container image, and the container image can be obtained from the second target node.

[0084] Exemplarily, the container image image1 has been pulled to the second target node node1, and the container image file of the container image image1 can be transferred to other target nodes node3 and node4, so that node3 and node4 load the container image file and complete the pre-pulling of the container image image1.

[0085] In the above embodiment, if another node in the cluster where the target node is located has already pulled the same container image, it will be directly pulled from the local node, realizing local node cache reuse, shortening transmission time, and improving image pulling speed; there is no need to repeatedly pull from the remote image repository, reducing cross-network traffic and optimizing network bandwidth resources. At the same time, the local container image can be shared by multiple services, avoiding the repeated storage of the same container image in the cluster to which the node belongs. It is also suitable for scenarios where the image repository is unavailable, avoiding service deployment failures and enhancing the reliability of service deployment.

[0086] In some embodiments, pre-pulling container images corresponding to container image data from an image repository includes: first submitting a pre-pull task for a preset number of container images to the image repository, obtaining a preset number of container images returned by the image repository, and determining a pulling speed for the preset number of container images, then determining a target number of pre-pull tasks based on the pulling speed, and then submitting the target number of pre-pull tasks to the image repository, obtaining the target number of container images returned by the image repository, until all container images are pulled.

[0087] Optionally, in determining the target number of pre-pull tasks based on the pull speed, a speed ratio is first calculated based on the pull speeds of historical pre-pull tasks that are adjacent in time sequence; and then, if the speed ratio is greater than or equal to a preset ratio, the target number is calculated based on the speed ratio. The preset ratio may be 1.

[0088] When pre-pulling container images from an image repository, a smaller, preset number of images can be pulled initially. After submitting multiple pre-pulling tasks for a preset number of container images to the image repository, these pre-pulling tasks become temporally linked. To dynamically adjust the number of pre-pulling tasks, the pull speeds of the pre-pulling tasks immediately preceding the current pre-pulling task are obtained. These pre-pulling tasks can be the previous pre-pulling task and the pre-pulling task before the previous pre-pulling task. The pull speed ratio of these two pre-pulling tasks is then calculated. This speed ratio is then compared with a preset ratio. If the speed ratio is greater than or equal to the preset ratio, the container image pull speed has increased, indicating that the image repository load is light. The number of pre-pulling tasks can be increased to fully utilize resources. For example, if the pull speed of a particular task increases significantly, exceeding the preset speed ratio, adding pre-pulling tasks can enable more images to be pulled to the node in advance, optimizing the efficiency of container image pre-pulling.

[0089] The above embodiment dynamically adjusts the number of pre-pull tasks (container images) based on historical speed ratios. When the speed ratio exceeds a preset ratio, indicating excellent performance of network, storage, and other resources, increasing the target number of pre-pull tasks can fully utilize idle resources. By dynamically adjusting the number of pre-pull tasks, image transfers can be accelerated when network conditions are favorable.

[0090] If the speed ratio is less than the preset ratio, the target number is calculated based on the difference between the previous pre-pull task number and the preset task number. It can be understood that if the speed ratio of the adjacent historical preset pull tasks is less than the preset ratio, indicating a decrease in pull speed, the current pre-pull task number is calculated by subtracting the preset task number from the previous pre-pull task number, i.e., the target number. For example, if the preset task number is 1, the target number is calculated by subtracting 1 from the previous pre-pull task number. The current pre-pull task number is reduced to reduce the load.

[0091] In the above embodiment, when the speed ratio is less than the preset ratio, it means reducing the amount of tasks when resources are tight, avoiding resource competition caused by too many tasks, achieving dynamic adaptation of resources and task volume, and significantly improving the overall utilization efficiency of cluster resources. Specifically, submit a pre-pull task of a preset number t container images, and determine the pull speed to be a t , the tth submission of pre-pull task, the number of corresponding container images is t, and the calculated pull speed is marked as a t. For example, the first time a pre-pull task of 1 container image is submitted, the pull speed is determined to be marked as a1; the second time a pre-pull task of 2 container images is submitted, the pull speed is determined to be marked as a2. The pre-pull task of determining the target data volume according to the pull speed includes: comparing the pull speed a1 with the pull speed a2, and calculating the ratio of the pull speeds. If a2 / a1≥1, it means that increasing the number of container images can improve the overall speed. At this time, the parallelism is increased proportionally, and a pre-pull task of [a2 / a1]*2+1 container images is submitted to avoid idle bandwidth. If a2 / a1<1, it means that the number of container images exceeds the bandwidth carrying capacity and the parallelism needs to be reduced, then a pre-pull task of 1 container image is submitted to avoid resource competition. Similarly, the pre-pull task of j container images is submitted for the i-1th time, and the pull speed a is determined. i -1, if a i-1 / a i-2 ≥1, then submit [a i-1 / a i-2 ]*j+1 container image pre-pull tasks, increase concurrency, and make full use of bandwidth to accelerate the pre-pull of container images; if a i-1 / a i-2 <1, then submit j-1 container image pre-pull tasks to reduce network contention for pre-pull of a single container image, making task execution more stable. Match the degree of parallelism with the current bandwidth capacity to avoid bandwidth lag or waste caused by a fixed concurrency until all container images are pre-pulled from the image repository.

[0092] The above embodiment monitors the pulling speed in real time and adaptively adjusts the number of pre-pulled container images to avoid pulling failures or timeouts caused by the inability of the fixed concurrency strategy to adapt to network changes, thereby achieving rational utilization of the image repository bandwidth resources and improving the pulling efficiency of container images.

[0093] In some embodiments, pre-pulling container images corresponding to container image data from image repositories includes: determining a number of container image pre-pulling tasks for each image repository based on the number of image repositories and the amount of container image data. Optionally, evenly distributing the container image pre-pulling tasks corresponding to each image repository based on the number of image repositories.

[0094] For example, assume there are three image repositories, harbor1, harbor2, and harbor3, and four container image pre-pull tasks, image1_node1, image2_node2, image3_node1, and image4_node3. The container image pre-pull tasks for each image repository can be: harbor1 for image1_node1 and image4_node3, harbor2 for image2_node2, and harbor3 for image3_node1.

[0095] During the pre-pulling of container images corresponding to the container image data from the image repository, the status of the image repository is monitored in real time. If any image repository fails, the container image is obtained from another healthy image repository or a node that has already pulled the same container image. This prevents container image pre-pulling from being stuck due to failures and affecting service deployment.

[0096] S204: Pull the container image to the matching target node.

[0097] In the scenario of pulling multiple container images in a short time, each container image corresponds to at least one target node. It can be understood that each container image corresponds to a target node list. For example, image1: [node1, node3, node4] means that the container image image1 corresponds to the target nodes node1, target node node3, and target node node4; image2: [node2, node4, node5] means that the container image image2 corresponds to the target nodes node2, target node node2, and target node node5; image3: [node1, node4, node5] means that the container image image3 corresponds to the target nodes node1, target node node4, and target node node5; image4: [node3, node2, node5] means that the container image image4 corresponds to the target nodes node2, target node node3, and target node node5. The target node list can be sorted according to the upload time of the container image. Each container image is pulled to the target node that matches it.

[0098] In some embodiments, an image pulling order of at least one target node is determined based on the service deployment probability, and then the container image is pulled to the matching target node based on the image pulling order.

[0099] For example, container image image1 corresponds to target nodes node1, node3, and node4 in descending order of service deployment probability, and is pulled to each target node in this order.

[0100] like Figure 3 As shown, container images a and n are pre-pulled from image repository habor1. Container image a is first pulled to the target node with the highest service deployment probability. Nodes with high service deployment probability are prioritized to obtain images, ensuring efficient deployment of core services. Container image a is then pulled to other nodes in the target node list based on the order of service deployment probability. The pulling process for container image n is similar. The pre-pulling process for image repository i is not further described. Pulling images in order of probability allows nodes with high-priority services to complete image loading first, ensuring business process continuity.

[0101] This strategy achieves intelligent scheduling of image distribution by determining the image pull order for target nodes based on service deployment probability and pulling images to the corresponding nodes in descending order of probability. Pulling images in probabilistic order dynamically aligns image distribution with node resource status. Pulling images sequentially rather than in parallel controls peak image pull traffic and avoids network bandwidth or disk I / O congestion caused by multiple nodes pulling images simultaneously. When pulling images sequentially, the first node pulled can serve as the image source for subsequent nodes, reducing duplicate requests to the image repository and improving overall pull efficiency.

[0102] In some embodiments, the pulling status of the container image on the matching target node is monitored in real time. After the container image is pulled to the matching target node, check whether the container image exists on the target node. Specifically, execute the command docker images on the target node to view the list of images existing on the target node. If the container image pulled this time does not exist in the image list, the pull failure is recorded and the container image is pulled again to the target node. Avoid the situation where the pull operation is completed but the image is missing. Retry the container image pull to cover occasional failure scenarios and improve the success rate of image pulling. If the pull still fails after repeating the operation a preset number of times, a log is generated for technical personnel to intervene to avoid infinite retries and consume system resources.

[0103] This mechanism builds a complete image pull reliability assurance system by monitoring the container image pull status in real time, checking the image existence after pulling, performing failure retries, and setting a retry limit.

[0104] In summary, the embodiments of the present application provide a method for pulling container images, which calculates the service deployment probability based on multi-dimensional data such as container image labels, node resource indicators, and container group density, realizes balanced resource scheduling and precise environment matching, and avoids deployment failures caused by single resource overload or environment incompatibility; pre-pull images from multiple sources of image warehouses and pulled nodes to accelerate the pulling speed and reduce the warehouse load, and determine the pulling order based on the service deployment probability, giving priority to ensuring the availability of high-probability node images; monitors the image pulling status in real time, and ensures the final consistency of image pulling through existence checks, failure retries, and limited retry mechanisms, thereby blocking fault propagation and reducing resource waste. At the same time, logs are generated to assist in fault location, realizing unattended automated operation and maintenance, and improving the stability, resource utilization, and business continuity of cluster deployment.

[0105] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0106] The embodiment of the present application also provides a container image pulling device, such as Figure 4 As shown, the device includes:

[0107] The data acquisition module 401 is used to obtain the node data of the node where the service is located and the container image data corresponding to the service in response to the user's service creation operation;

[0108] A node determination module 402 is configured to determine at least one target node for deploying a service from among the nodes where the service is located based on the node data and the container image data;

[0109] The container image acquisition module 403 is used to obtain the container image corresponding to the container image data;

[0110] The pulling module 404 is used to pull the container image to a matching target node.

[0111] As an optional implementation provided in an embodiment of the present application, the data acquisition module 401 is specifically used to: store the service data in a database in response to a service creation operation; determine the container group of the service corresponding to the service data; determine the node where the service is located based on the container group; and obtain the node data of the node where the service is located.

[0112] When a user creates a service on the inference platform, node data is obtained in response to the service creation operation to ensure that the service is deployed to the appropriate node and to avoid node overload.

[0113] As an optional implementation provided in an embodiment of the present application, the data acquisition module 401 is specifically used to: store the container image data uploaded by the user in a database in response to the user's container image upload operation; and obtain the container image data corresponding to the service from the database.

[0114] Separate tables are created for container image data and service data to avoid data redundancy and support independent expansion to cope with high-concurrency scenarios.

[0115] As an optional implementation provided in an embodiment of the present application, the node determination module 402 is specifically used to: calculate the service deployment probability based on the node data and the container image data, where the service deployment probability represents the probability of deploying the service on the node; and determine, from the nodes where the service is located, a node whose service deployment probability meets the preset conditions as the target node.

[0116] Based on the node data of the server and the corresponding container image data of the service, we quantitatively analyze the compatibility of node resources with service operation requirements and build a probabilistic model to guide node service deployment. Once the probability calculation is complete, we select nodes with probability values ​​exceeding a preset threshold as target nodes. These nodes must meet multiple criteria, including resource availability, compatibility, and load balancing.

[0117] As an optional implementation provided in an embodiment of the present application, the node determination module 402 is specifically used to: when the container image data includes a container image tag but the node data does not include a matching tag, determine the service deployment probability to be a first probability value; when the container image data includes a container image tag and the node data includes a matching tag, determine the service deployment probability to be a second probability value.

[0118] When a container image tag is detected in the container image data, the node data is further checked for a matching tag. A matching tag here refers to the node tag that corresponds to the container image tag. If the node data does not contain a matching tag, the probability of deploying the service on that node is determined to be the first probability value.

[0119] As an optional implementation provided in an embodiment of the present application, the node determination module 402 is specifically configured to: select a node whose service deployment probability is equal to the second probability value as a target node.

[0120] When the system detects that the container image data contains a container image tag and that the node data contains a corresponding matching tag, it assigns the service deployment probability of the node to the second probability value, indicating that the node meets the basic conditions for service deployment and the container image can be pulled to the node and run. This mechanism enables accurate matching and screening of services and node labels. It prevents services from being deployed to nodes that do not support their label requirements, quickly filters invalid nodes through labels, reduces invalid deployment attempts, and improves deployment efficiency; mandatory label matching rules ensure the consistency of the service deployment environment.

[0121] As an optional implementation provided in an embodiment of the present application, the node determination module 402 is also used to: when the container image data does not include a container image label and the node data does not include the number of node container groups, calculate the service deployment probability based on the node resource indicators included in the node data; and use the node whose service deployment probability is greater than or equal to a preset probability value as the target node.

[0122] If the container image data does not contain any container image labels for node screening, and the node data does not involve the number of node container groups, it means that the node is not currently running any container groups and is in a resource-idle state. In this case, the node resource availability is converted into a comparable scheduling basis through the numerical probability value. This ensures that when there are no additional conditions such as label matching, the service can still be deployed to the appropriate node based on the principle of resource optimization, avoiding deployment blindness caused by missing information.

[0123] As an optional implementation provided in an embodiment of the present application, the node determination module 402 is specifically used to: calculate the average resource utilization of the node based on the node resource indicator; and calculate the service deployment probability based on the average resource utilization and the first weight coefficient.

[0124] By calculating the average utilization rate based on the resource indicators of each node and combining the weight coefficients of different resource types, the service and node resource characteristics can be accurately matched, the node resource advantages can be fully utilized, and the service operation efficiency can be improved. As an optional implementation method provided by the embodiment of the present application, the node determination module 402 is also used to: when the container image data does not include the container image label, but the node data includes the number of node container groups, calculate the service deployment probability based on the number of node container groups and the node resource indicators; and use the node with a service deployment probability greater than or equal to the preset probability value as the target node.

[0125] When a container image doesn't include a container image tag for node selection, and the node data explicitly includes the number of container groups, the service deployment probability calculation logic integrates the node's current load and underlying resource metrics. The greater the number of container groups, the higher the percentage of node resources occupied, and the greater the risk of deploying new services. Services can be preferentially deployed to nodes with fewer container groups and more abundant resources to avoid load imbalance among nodes within the cluster.

[0126] As an optional implementation provided in an embodiment of the present application, the node determination module 402 is specifically used to: calculate the container group density based on the number of node container groups and the total number of container groups of the cluster to which the node belongs; calculate the average resource utilization of the node based on the node resource index; and calculate the service deployment probability based on the container group density, the average resource utilization, and the second weight coefficient.

[0127] Among them, the container group density reflects the relative concentration of the number of container groups on the node. When the container group density of a node is too high, even if the average resource utilization is low, the probability of service deployment will be reduced due to the influence of this indicator, thereby avoiding excessive concentration of new services on a few nodes and preventing the emergence of hot nodes. By balancing the distribution of container groups in the cluster, the service load is effectively dispersed, the overall load balancing level of the cluster is improved, and the stable operation of the service is guaranteed. As an optional implementation method provided in an embodiment of the present application, the node resource indicators include: the available CPU of the node, the total CPU amount, the available node memory, the total node memory, the available node storage and the total node storage.

[0128] As an optional implementation provided in an embodiment of the present application, the pulling module 404 is specifically used to: determine the image pulling order of at least one target node according to the service deployment probability; and pull the container image to the matching target node according to the image pulling order.

[0129] This strategy enables intelligent scheduling of image distribution by determining the image pull order for target nodes based on service deployment probability and pulling images to corresponding nodes in descending order of probability. Pulling images in probabilistic order dynamically aligns image distribution with node resource status. Pulling images sequentially rather than in parallel controls peak image pull traffic and avoids network bandwidth or disk I / O congestion caused by multiple nodes pulling images simultaneously. When pulling images sequentially, the first node pulled can serve as the image source for subsequent nodes, reducing duplicate requests to the image repository and improving overall pull efficiency.

[0130] As an optional implementation provided in an embodiment of the present application, the container image acquisition module 403 is specifically configured to pre-pull the container image from an image repository and / or a node that has already pulled the same container image.

[0131] Multiple container image repositories and nodes that have already pulled the same container image can serve as sources for pulling a specific container image. This multi-source pull mechanism can significantly improve container deployment efficiency and cluster stability.

[0132] As an optional implementation provided by an embodiment of the present application, the container image acquisition module 403 is specifically used to: submit a pre-pull task of a preset number of container images to the image repository, obtain a preset number of container images returned by the image repository, and determine the pulling speed of the preset number of container images; determine a target number of pre-pull tasks based on the pulling speed; submit a target number of pre-pull tasks to the image repository, obtain a target number of container images returned by the image repository, until the container image corresponding to the container image data is pulled.

[0133] By real-time monitoring of the pulling speed, the number of pre-pulled container images can be adaptively adjusted to avoid pull failures or timeouts caused by the fixed concurrency strategy being unable to adapt to network changes, thereby achieving rational utilization of image repository bandwidth resources and improving the efficiency of container image pulling.

[0134] As an optional implementation provided in an embodiment of the present application, the container image acquisition module 403 is specifically used to: calculate a speed ratio based on the pulling speeds of historical pre-pull tasks that are adjacent in time sequence; and when the speed ratio is greater than or equal to a preset ratio, calculate the target quantity based on the speed ratio.

[0135] The above embodiment dynamically adjusts the number of pre-pull tasks (container images) based on historical speed ratios. When the speed ratio exceeds a preset ratio, indicating excellent network and storage resource performance, increasing the target number of pre-pull tasks can fully utilize idle resources. By dynamically adjusting the number of pre-pull tasks, image transfers can be accelerated when network conditions are favorable.

[0136] As an optional implementation provided in an embodiment of the present application, the container image acquisition module 403 is further configured to: when the speed ratio is less than a preset ratio, calculate the target number based on the difference between the previous pre-pull task number and the preset task number.

[0137] In the above embodiment, when the speed ratio is less than the preset ratio, it means reducing the amount of tasks when resources are tight, avoiding resource competition caused by too many tasks, achieving dynamic adaptation of resources and task amounts, and significantly improving the overall utilization efficiency of cluster resources.

[0138] In summary, an embodiment of the present application provides a container image pulling device, which calculates the service deployment probability based on multi-dimensional data such as container image labels, node resource indicators and container group density, realizes balanced resource scheduling and precise environment matching, and avoids deployment failure caused by single resource overload or environment incompatibility; pre-pull images from multiple sources of image warehouses and pulled nodes to accelerate the pulling speed and reduce the warehouse load, and determines the pulling order based on the service deployment probability, giving priority to ensuring the availability of high-probability node images; monitors the image pulling status in real time, and ensures the final consistency of image pulling through existence checks, failure retries and limited retry mechanisms, blocks fault propagation and reduces resource waste, and generates logs to assist in fault location, realizes unattended automated operation and maintenance, and improves the stability, resource utilization and business continuity of cluster deployment.

[0139] For descriptions of features in the embodiments corresponding to the container image pulling device, please refer to the relevant descriptions of the embodiments corresponding to the container image pulling method, which will not be repeated here.

[0140] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-mentioned container image pulling method embodiments.

[0141] An embodiment of the present application further provides a non-volatile computer-readable storage medium, which stores a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned container image pulling method embodiments when running.

[0142] In an exemplary embodiment, the non-volatile computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0143] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned container image pulling method embodiments are implemented.

[0144] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned container image pulling method embodiments are implemented.

[0145] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0146] The above is a detailed introduction to the container image pulling method, device, electronic device, medium and product provided by this application. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A method for pulling a container image, characterized in that: include: In response to a user's service creation operation, obtain node data of the node where the service is located and container image data corresponding to the service; Determine at least one target node for deploying the service from the nodes where the service is located according to the node data and the container image data; Obtaining the container image corresponding to the container image data; Pull the container image to the matching target node; The determining, from the nodes where the service is located, at least one target node for deploying the service based on the node data and the container image data includes: calculating a service deployment probability based on at least one of a matching tag, a number of node container groups, and a node resource indicator included in the node data, and a container image tag included in the container image data, wherein the service deployment probability represents a probability of deploying the service on a node; and determining, from the nodes where the service is located, a node whose service deployment probability satisfies a preset condition as the target node.

2. The method according to claim 1, characterized in that In response to the user's service creation operation, the node data of the node where the service is located is obtained, including: In response to the service creation operation, storing the service data in a database; Determine a container group of a service corresponding to the service data; Determine the node where the service is located according to the container group; Obtain the node data of the node where the service is located.

3. The method according to claim 2, characterized in that Get the container image data corresponding to the service, including: In response to a user's container image upload operation, storing the container image data uploaded by the user in the database; Obtain container image data corresponding to the service from the database.

4. The method according to claim 1, wherein The calculating the service deployment probability according to the node data and the container image data includes: When the container image data includes a container image tag but the node data does not include a matching tag, determining that the service deployment probability is a first probability value; When the container image data includes a container image tag and the node data includes a matching tag, the service deployment probability is determined to be a second probability value.

5. The method according to claim 4, characterized in that The determining, from the nodes where the service is located, a node whose service deployment probability meets a preset condition as the target node includes: The node whose service deployment probability is equal to the second probability value is used as the target node.

6. The method according to claim 1, characterized in that The method further comprises: When the container image data does not include a container image tag and the node data does not include the number of node container groups, calculating the service deployment probability according to the node resource indicator included in the node data; The node whose service deployment probability is greater than or equal to a preset probability value is used as the target node.

7. The method according to claim 6, characterized in that The calculating the service deployment probability according to the node resource indicator included in the node data includes: Calculate the average resource utilization of the node based on the node resource indicators; The service deployment probability is calculated according to the average resource utilization and a first weight coefficient.

8. The method according to claim 6, characterized in that The method further comprises: When the container image data does not include a container image tag, but the node data includes the number of node container groups, calculating the service deployment probability according to the number of node container groups and the node resource indicator; The node whose service deployment probability is greater than or equal to the preset probability value is used as the target node.

9. The method according to claim 8, characterized in that The calculating the service deployment probability according to the number of node container groups and the node resource indicator includes: Calculate the container group density based on the number of container groups of the node and the total number of container groups of the cluster to which the node belongs; Calculate the average resource utilization of the node according to the node resource indicator; The service deployment probability is calculated according to the container group density, the average resource utilization and a second weight coefficient.

10. The method according to any one of claims 6 to 9, characterized in that: The node resource indicators include: the available amount of the node's central processing unit, the total amount of the central processing unit, the available amount of the node's memory, the total amount of the node's memory, the available amount of the node's storage, and the total amount of the node's storage.

11. The method according to claim 1, wherein The method further comprises: Determining an image pulling order for the at least one target node according to the service deployment probability; Pull the container image to a matching target node according to the image pulling order.

12. The method according to claim 1, characterized in that The obtaining of the container image corresponding to the container image data includes: Pre-pull the container image from the image repository and / or a node that has already pulled the same container image.

13. The method according to claim 12, characterized in that Pre-pull the container image from the image repository, including: Submitting a pre-pull task of a preset number of container images to the image repository, obtaining the preset number of container images returned by the image repository, and determining a pulling speed for the preset number of container images; Determining a target number of pre-pulling tasks according to the pulling speed; Submit the target number of pre-pull tasks to the image repository, obtain the target number of container images returned by the image repository, and complete the pulling of the container images corresponding to the container image data.

14. The method according to claim 13, characterized in that The determining of a target number of pre-pulling tasks according to the pulling speed includes: Calculate the speed ratio based on the pull speed of the historical pre-pull tasks that are adjacent in time sequence; When the speed ratio is greater than or equal to a preset ratio, the target quantity is calculated according to the speed ratio.

15. The method according to claim 14, characterized in that The method further comprises: When the speed ratio is less than the preset ratio, the target quantity is calculated based on the difference between the last pre-pulling task number and the preset task number.

16. A container image pulling device, characterized in that: include: A data acquisition module is used to obtain the node data of the node where the service is located and the container image data corresponding to the service in response to the user's service creation operation; a node determination module, configured to determine, based on the node data and the container image data, at least one target node for deploying the service from among the nodes where the service is located; A container image acquisition module, configured to acquire the container image corresponding to the container image data; A pulling module, configured to pull the container image to a matching target node; The node determination module is specifically used to determine at least one target node for deploying the service from the nodes where the service is located based on the node data and the container image data, including: calculating the service deployment probability based on at least one of the matching label, the number of node container groups, and the node resource indicator included in the node data, and the container image label included in the container image data, where the service deployment probability represents the probability of deploying the service on the node; and determining, from the nodes where the service is located, a node whose service deployment probability meets a preset condition as the target node.

17. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the container image pulling method according to any one of claims 1 to 15 when executing the computer program.

18. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the container image pulling method according to any one of claims 1 to 15 are implemented.

19. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method for pulling a container image according to any one of claims 1 to 15 are implemented.

Images