Container mirror image processing method and device, equipment, storage medium and product

Abstract

The invention provides a container mirror image processing method and device, equipment, a storage medium and a product. The method comprises the following steps: in response to a mirror image pulling request for a target container mirror image, determining a first service node from a node cluster; the node cluster comprises a plurality of service nodes, and the plurality of service nodes share container mirror image resources in the mirror image warehouse; the container mirror image resources are stored in a local file system of the service node; calling a container group in the first service node, and determining a target storage position of the target container mirror image from a local file system of the first service node; obtaining a target container mirror image from the target storage position; and sending the obtained target container mirror image to a client corresponding to the mirror image pulling request. According to the method and the device, the container mirror image can be prevented from being downloaded from the remote mirror image warehouse, the pulling speed of the container mirror image is improved, even if any service node fails, the container mirror image resource can still be obtained, and the reliability and the stability of the container mirror image pulling service are ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a container image processing method, apparatus, device, storage medium, and product. Background Technology

[0002] With the booming development of the internet industry, the deep integration of the internet and traditional industries has become a trend. In such a rapidly changing technological environment, the continuous innovation and iteration of business models have placed an urgent demand on application software to quickly adapt to new needs. Therefore, container images have become an indispensable part of system development; in a containerized environment, creating corresponding container images according to business needs and running these container images is a common development process.

[0003] However, large-scale system development requires the creation and management of a large number of container images. When all these container images are stored in a remote public image repository, the public image repository may face enormous pressure due to frequent access and large amounts of data storage during container image pulls. Furthermore, multiple terminals concurrently retrieve images from the image repository via the public network. Due to the high cost of public network bandwidth, this may lead to a decrease in processing speed and resource constraints in the public image repository, resulting in slow speed and poor stability when pulling container images using related technologies. Summary of the Invention

[0004] This application provides a container image processing method, apparatus, device, storage medium, and product. This application can distribute requests among multiple service nodes in a node cluster and utilize locally stored container image resources, thereby avoiding the need to download container images from a remote image repository, reducing network latency, and improving the speed and response time of container image retrieval. Furthermore, by sharing container image resources in the image repository among multiple service nodes, it ensures that even if a service node fails, it can still obtain container image resources from other nodes that are running normally, thus guaranteeing the reliability and stability of the container image retrieval service.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] This application provides a container image processing method, the method comprising: in response to an image pull request for a target container image, determining a first service node from a node cluster; the node cluster includes multiple service nodes, the multiple service nodes sharing container image resources in an image repository; the container image resources being stored in the local file system of the service node; invoking a container group in the first service node to determine the target storage location of the target container image from the local file system of the first service node; obtaining the target container image from the target storage location; and sending the obtained target container image to the client corresponding to the image pull request.

[0007] This application provides a container image processing apparatus, comprising: a request response module, configured to respond to an image pull request for a target container image and determine a first service node from a node cluster; the node cluster includes multiple service nodes, which share container image resources in an image repository; the container image resources are stored in the local file system of the service node; a container group invocation module, configured to invoke a container group in the first service node and determine the target storage location of the target container image from the local file system of the first service node; a container image acquisition module, configured to acquire the target container image from the target storage location; and a container image sending module, configured to send the acquired target container image to the client corresponding to the image pull request.

[0008] In the above scheme, the request response module is further configured to: respond to an image pull request for a target container image, parse the domain name system configuration file of the node cluster to obtain a list of network addresses of all service nodes in the node cluster; obtain the target network address from the list of network addresses; and determine the service node corresponding to the target network address as the first service node.

[0009] In the above scheme, the request response module is further configured to: sequentially traverse the network addresses in the network address list; when the current running state of the service node corresponding to the current network address is abnormal, continue traversing the next network address adjacent to the current network address in the network address list; when the current running state of the service node corresponding to the current network address is normal, determine the service node corresponding to the current network address as the target network address and stop the traversal.

[0010] In the above scheme, the container group invocation module is further configured to: invoke the container group in the first service node to find the mapping configuration information corresponding to the target container image; the mapping configuration information includes the metadata of the container image and the storage information of the container image; and determine the target storage location in the local file system of the first service node according to the mapping configuration information.

[0011] In the above scheme, the container group invocation module is further configured to: access the image repository interface service of the container group through the first service node by accessing it via a domain name; the container group is located in the network namespace of the first service node; and invoke the image repository interface service to find the mapping configuration information corresponding to the target container image.

[0012] In the above scheme, the device further includes: a container group creation module, used to create a new container group on the service node corresponding to the container group when the current running state of any container group in the node cluster is abnormal.

[0013] In the above scheme, the device further includes: an image push module, used to determine a second service node from the node cluster in response to an image push request; the image push request includes a newly created container image; and to call the container group in the second service node to store the newly created container image in the local file system of the second service node.

[0014] In the above scheme, the device further includes: a file synchronization module, used to detect the local file system of each service node in the node cluster through the file system event detection interface; when a change in container image resources is detected in the local file system of the service node, the changed container image is synchronized to the local file system of other service nodes in the node cluster except the service node through the file synchronization component.

[0015] In the above scheme, the container group is a file management virtual machine used to manage the local file system. The device further includes: a virtual machine maintenance module, used to determine the current running status of the file management virtual machines in the service nodes of the node cluster; based on the current running status of the file management virtual machines in the service nodes, determine the number of file management virtual machines in normal state in all service nodes; when the number of virtual machines is less than a preset threshold, determine the current node running status of each service node in the node cluster and the number of service nodes whose current node running status is normal; when the number of service nodes in normal state is greater than the number of virtual machines, create a file management virtual machine in any service node that does not have the file management virtual machine and whose current node running status is normal.

[0016] This application provides an electronic device, which includes: a memory for storing computer-executable instructions; and a processor for executing the computer-executable instructions stored in the memory to implement the container image processing method provided in this application.

[0017] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implements the container image processing method provided in this application.

[0018] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the container image processing method provided in this application.

[0019] The embodiments of this application have the following beneficial effects:

[0020] This application embodiment avoids the need to download container images from a remote image repository by distributing requests among multiple service nodes in a node cluster and utilizing locally stored container image resources. This reduces network latency and improves the speed and response time of container image retrieval. Furthermore, by sharing container image resources in the image repository among multiple service nodes, it ensures that even if a service node fails, it can still obtain container image resources from other nodes that are running normally, thereby guaranteeing the reliability and stability of the container image retrieval service. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the container image processing system provided in the embodiments of this application;

[0022] Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0023] Figure 3A This is a flowchart illustrating the container image processing method provided in an embodiment of this application;

[0024] Figure 3B This is a schematic diagram of the process for determining the first service node provided in an embodiment of this application;

[0025] Figure 3C This is a schematic diagram of the process for obtaining the target network address provided in an embodiment of this application;

[0026] Figure 3D This is a schematic diagram of the process for determining the target storage location provided in an embodiment of this application;

[0027] Figure 3EThis is a flowchart illustrating the process of determining mapping configuration information provided in an embodiment of this application;

[0028] Figure 4 This is a schematic diagram of the deployment structure of the mirror repository provided in the embodiments of this application;

[0029] Figure 5 This is a schematic diagram of the structure of the client performing container image operations provided in the embodiments of this application;

[0030] Figure 6 This is a schematic diagram of the structure of any service node in the node cluster provided in the embodiments of this application;

[0031] Figure 7 This is a schematic diagram of the data synchronization structure of service nodes in a node cluster provided in an embodiment of this application;

[0032] Figure 8 This is a schematic diagram of the domain name resolution structure provided in the embodiments of this application;

[0033] Figure 9 This is a schematic diagram of the data synchronization structure when a service node fails, as provided in an embodiment of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0036] If the application documents contain similar descriptions such as "first / second / third", the following explanation shall be added: In the following description, the terms "first / second / third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0037] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0038] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0039] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0040] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0041] 1) In response to, used to indicate the conditions or states on which the operation performed depends. When the conditions or states on which it depends are met, one or more operations performed may be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0042] 2) An image registry is a service for storing and distributing container images, similar to a code repository. It is responsible for storing and distributing container images. A public image registry is an open, publicly accessible location where container image resources are centrally stored. Anyone can access and download container images from a public image registry. Developers typically use public image registries to share open-source projects or general-purpose tools.

[0043] 3) A container image, also known as an image or container image resource, is a lightweight, executable, standalone software package. A container image contains all the code, libraries, environment variables, and configuration files required to run a containerized application. Container images are the foundation of containers and are used to create and run containers.

[0044] 4) A container is a running instance created from a container image. Containers allow applications and their dependencies to run in an isolated environment without consuming additional resources of the service node's operating system. Containers are similar to virtual machines (VMs), but they run directly on the service node's kernel instead of a complete operating system.

[0045] 5) Containerization is a process of deploying a program (application). Containerization involves packaging the program (application) and its dependent environment into a container image so that the program (application) can run efficiently and consistently in different computing environments.

[0046] 6) A Kubernetes cluster (K8s) is a container orchestration platform used to automate the deployment, scaling, and management of computer software.

[0047] 7) A container group is a collection of containers on a service node. Containers in a container group share lifecycles, resources, local network, and storage volumes.

[0048] 8) A Pod is the smallest unit of deployment (container group) that can be created and managed in a Kubernetes cluster. A Pod is the basic building block of a Kubernetes cluster; it is an instance of an application and can be viewed as a virtual logical host running one or more processes of the application. The Kubernetes cluster manages the lifecycle of a Pod, including creation, deletion, and restarting as needed.

[0049] 9) Local file systems are file management systems that are directly installed on service nodes (such as servers or virtual machines), such as the fourth-generation extended file system (EXT4), the new technology file system (NTFS), and the extended file system (X File System, XFS). They are used to store and organize files and directories in a structured way and are the basis for the interaction between the operating system and user data.

[0050] 10) Lsyncd is a synchronization tool that can detect changes to the local file system and synchronize data between the local file system and the local file systems of other service nodes. Lsyncd detects changes to the local file system through the Inotify event system and uses Rsync for synchronization.

[0051] 11) Inotify is a Linux kernel event notification system that allows applications to detect changes in the local file system, such as file creation, modification, and deletion.

[0052] 12) Rsync is a file synchronization tool that can synchronize data between a local file system and the local file systems of other service nodes. Rsync performs synchronization operations via network protocols (such as SSH) and supports compression and encryption.

[0053] 13) CoreDNS rules are DNS server rules in a Kubernetes cluster. Kubernetes cluster administrators can customize DNS records and rules to serve service nodes and Pods in the Kubernetes cluster.

[0054] 14) Image Pull refers to the process of obtaining a container image from an image repository, which is a prerequisite for running a container.

[0055] 15) Image Push refers to the process of pushing container images to an image repository, which is a key step in image version control and distribution updates.

[0056] 16) Cloud Native is a methodology and philosophy for building and running applications, specifically designed for cloud platforms to fully leverage the advantages of cloud computing technologies. Cloud Native emphasizes the use of a range of technologies and practices, such as containerization, microservice architecture, immutable infrastructure, declarative APIs and automated operations and maintenance, as well as continuous integration and delivery processes, to build resilient, scalable, maintainable, and loosely coupled services.

[0057] 17) An Application Programming Interface (API) is a set of defined rules and standards that allow different software or hardware components to communicate and interact.

[0058] 18) A Service is an abstraction layer in a Kubernetes cluster that defines the logical entry point for a network service and is responsible for routing requests to backend services.

[0059] 19) Ingress is a method in Kubernetes clusters for routing external HTTP and HTTPS requests to services within the cluster. It provides an entry point for external access to services within the cluster and can route requests based on rules such as domain names and paths.

[0060] 20) The `hostNetwork` configuration item is an optional configuration item in the definition of a Pod in a Kubernetes cluster. If the `hostNetwork` configuration item is set to "true", the Pod will use the network namespace of the host machine (service node) instead of the isolated network namespace created by the Kubernetes cluster for the Pod.

[0061] 21) HostPath: HostPath is a volume type in Kubernetes that allows you to mount container files or directories in a Pod to files or directories on the host machine, enabling containers to access specific files or directories on the host machine's file system.

[0062] 22) The Deployment Controller is an API object in a Kubernetes cluster that is used to automatically manage the deployment of Pods. It is responsible for creating, updating, and deleting Pods to maintain the desired deployment state of the Pods.

[0063] 23) Toleration Seconds is a Pod configuration option in a Kubernetes cluster. It defines the length of time a Pod can tolerate being unschedulable to a service node due to conditions such as disk pressure or memory pressure. If this time limit is exceeded, the Pod on that service node will be destroyed.

[0064] In related technologies, public image repositories may face enormous pressure due to frequent access and large amounts of data storage when pulling container images. Furthermore, multiple terminals concurrently retrieve images from the image repository via the public network. Due to the high cost of public network bandwidth, this may lead to a decrease in processing speed and a shortage of public image repository resources. As a result, related technologies suffer from slow speed and poor stability when pulling container images.

[0065] Based on at least one of the aforementioned problems in related technologies, this application provides a container image processing method. By allocating requests among multiple service nodes in a node cluster and utilizing locally stored container image resources, the need to download container images from a remote image repository can be avoided, thereby reducing network latency and improving the speed and response time of container image retrieval. Furthermore, by sharing container image resources in the image repository among multiple service nodes, it is ensured that even if a service node fails, it can still obtain container image resources from other nodes that are running normally, thus guaranteeing the reliability and stability of the container image retrieval service.

[0066] Before explaining the container image processing method of the embodiments of this application, an exemplary application of the container image processing device of the embodiments of this application will first be described. The container image processing device is an electronic device used to implement the container image processing method. In one implementation, the container image processing device (i.e., electronic device) provided in the embodiments of this application can be implemented as a server. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. Multiple servers can be directly or indirectly connected through wired or wireless communication, which is not limited in the embodiments of this application. The electronic device provided in the embodiments of this application can also be implemented as a terminal device. The terminal device can be various types of terminals such as laptops, tablets, desktop computers, smartphones, smartwatches, smart TVs, and in-vehicle terminals. The electronic device provided in the embodiments of this application can also be implemented as a combination of a terminal device and a server.

[0067] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the container image processing system 10 provided in this application embodiment. The client (client 200-1 and client 200-2 are schematically shown in the figure) and the node cluster 100 (including service node 110-1 and service node 110-2 are schematically shown in the figure) can connect and interact via network 300. The client can provide a user interface, receive and send image pull requests from users, and pull the target container image to the local machine for user use. The node cluster 100 can respond to image pull requests through service nodes and send the target container image to the client. Network 300 can be a wide area network (WAN), a local area network (LAN), or a combination of both.

[0068] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device 400 provided in the embodiments of this application. Figure 2 The illustrated electronic device 400 includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the electronic device 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 440.

[0069] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0070] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0071] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0072] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0073] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0074] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks.

[0075] The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including Bluetooth, WiFi, and Universal Serial Bus (USB).

[0076] Presentation module 453 enables the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., a display screen, a speaker, etc.).

[0077] The input processing module 454 is used to detect and translate user input or interaction from one or more input devices 432.

[0078] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A container image processing apparatus 455 stored in memory 450 is shown. This apparatus can be software in the form of programs and plug-ins, and includes the following software modules: a request-response module 4551, a container group invocation module 4552, a container image acquisition module 4553, and a container image sending module 4554. These modules are logically linked and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0079] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the container image processing method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0080] See Figure 3A , Figure 3A This is an optional flowchart illustrating the container image processing method provided in this application embodiment. The following will combine... Figure 3A The steps shown are explained as follows: Figure 3A As shown, taking the node cluster as the execution subject of the container image processing method as an example, the method includes the following steps 101 to 104:

[0081] Step 101: In response to the image pull request for the target container image, determine the first service node from the node cluster; the node cluster includes multiple service nodes, and the multiple service nodes share the container image resources in the image repository; the container image resources are stored in the local file system of the service node.

[0082] In some embodiments, a request to pull a target container image is a request sent by a client to a node cluster to obtain the specified target container image. A node cluster is a collection of at least two service nodes connected together via a local network to jointly manage container images and provide services such as storage and access to them. A service node is a separate compute node within the node cluster; each service node is a physical computing unit with its own operating system, storage resources, and network connectivity, possessing independent computing, storage, and network capabilities. The first service node refers to a service node selected from the node cluster when responding to an image pull request; this first service node may be selected based on load balancing, geographical location, or other optimization strategies.

[0083] Container image resources refer to container images stored in an image repository. These resources include application code, dependency libraries, and configuration files, packaged together to run in any container-enabled environment. The local file system is the file system on the service node, providing the ability to store and access files on that node. It can also be understood as the service node's own hard disk storage space, storing all container images acquired by that service node. Multiple service nodes sharing container image resources in an image repository means that all service nodes in the cluster store complete and identical container image resources on their respective local file systems.

[0084] For example, when a Kubernetes cluster is used as a node cluster consisting of multiple service nodes, when the Kubernetes cluster receives a pull request for a specific container image, it can select the most suitable worker node as the first service node based on factors such as the current load, network latency, and normal running status of each service node in the Kubernetes cluster.

[0085] By selecting the first service node from the node cluster to respond to the image pull request in step 101, load balancing can be achieved, improving the overall performance and reliability of container image pull. At the same time, since the container image resources are stored in the local file system of the service node, the read and write performance advantages of local storage can be fully utilized to improve the speed and efficiency of container image pull. In addition, through the distributed storage and sharing of the node cluster, high availability and fault tolerance of container image data can also be achieved.

[0086] In some embodiments, see Figure 3B , Figure 3A Step 101 shown can be implemented through steps 1011 to 1013, as explained in detail below.

[0087] Step 1011: In response to the image pull request for the target container image, parse the domain name system configuration file of the node cluster to obtain a list of network addresses of all service nodes in the node cluster.

[0088] In some embodiments, the Domain Name System (DNS) can translate human-readable domain names into machine-readable IP addresses, facilitating communication between network devices. A DNS configuration file is a file used to define and manage these translation rules; it records the mapping relationship between domain names and their corresponding IP addresses.

[0089] The network address list is obtained by resolving the Domain Name System (DNS) configuration file and represents the set of IP addresses or other connectable addresses of all service nodes in the network. This network address list is dynamically generated and reflects the network information of all service nodes within the node cluster.

[0090] For example, in a Kubernetes cluster, the DNS configuration file can be either a Core DNS or a Kubernetes DNS configuration file. This DNS configuration file defines the mapping between domain names within the Kubernetes cluster and the IP addresses of service nodes. When a pull request for a target container image is received, this DNS configuration file is parsed to obtain a list of IP addresses of service nodes that can provide that target container image.

[0091] Step 1012: Obtain the target network address from the network address list.

[0092] In some embodiments, see Figure 3C , Figure 3B Step 1012 shown can be implemented through steps 10121 to 10123, as explained in detail below.

[0093] Step 10121: Iterate through the network addresses in the network address list.

[0094] In some embodiments, the network addresses in the network address list may be randomly ordered, and each network address may be read one by one, starting from the first network address in the network address list.

[0095] Step 10122: When the current running state of the service node corresponding to the current network address is abnormal, continue to traverse the network address list to the next network address adjacent to the current network address.

[0096] In some embodiments, the running status of the service node corresponding to the currently traversed network address can be checked. If the running status of the current service node is abnormal (such as downtime, high load, or network failure), the network address of the service node in the current abnormal state is skipped, and the next network address adjacent to the current address in the network address list is continued to be traversed.

[0097] Step 10122 enables the automatic skipping of service nodes in abnormal states when traversing the network address list, and the continued search for the next available service node. This improves the fault tolerance and stability when responding to mirror pull requests, ensuring that service requests can be processed and responded to in a timely manner. At the same time, skipping abnormal service nodes can also reduce unnecessary resource waste and performance loss, thereby improving the overall service quality and user experience.

[0098] Step 10123: When the current running status of the service node corresponding to the current network address is normal, determine the service node corresponding to the current network address as the target network address and stop traversing.

[0099] In some embodiments, during the traversal of the network address list, the current operating status of the service node corresponding to the currently traversed network address is checked; if the current operating status of the service node is normal (e.g., the load is within an acceptable range and the network connection is normal), the service node corresponding to the currently traversed network address with a normal status is determined as the target network address; once the target network address is determined, the traversal of the network address list will stop to avoid unnecessary waste of resources.

[0100] Step 10123 enables the rapid identification of service nodes in a healthy state when traversing the network address list, and identifies them as target network addresses. This reduces unnecessary traversal operations and improves efficiency and response speed when responding to mirror pull requests. At the same time, by identifying service nodes in a healthy state as target network addresses, it ensures that mirror pull requests are sent to reliable service nodes, thereby improving service availability and stability.

[0101] Next, see Figure 3B The following will be an explanation following step 1012 above.

[0102] Step 1013: Determine the service node corresponding to the target network address as the first service node.

[0103] In some embodiments, the service node corresponding to the target network address can be found according to the mapping relationship between the target network address and the service node, and the service node can be determined as the first service node.

[0104] For example, in a Kubernetes cluster, each service node has a unique network address. Once the target network address is determined, the service node corresponding to that target network address can be found and that service node can be used as the first service node.

[0105] Step 1013 allows for the precise location of the service node corresponding to the target network address, which is then designated as the first service node. This improves the efficiency and accuracy of the mirror pull operation and reduces unnecessary network latency and resource waste.

[0106] Next, see Figure 3A The following will be an explanation following step 101 above.

[0107] Step 102: Invoke the container group in the first service node to determine the target storage location of the target container image from the local file system of the first service node.

[0108] In some embodiments, a container group is the smallest deployable unit in a node cluster such as a Kubernetes cluster; a container group is a collection of one or more containers that can run on a service node in a node cluster. The target storage location is the specific storage path of the target container image in the local file system of the service node; each container image has a unique storage location in the file system, and this unique storage location contains all the resource data of the container image.

[0109] For example, if the target service node is a service node in a Kubernetes cluster, then the Pod (container group) can be managed by the Kubernetes cluster controller [such as a DaemonSet or StatefulSet], and the query of the local file system can involve searching directories such as / var / lib / docker or / var / lib / containerd that store container images to find the storage path of the target container image.

[0110] Step 102 allows for precise location of the target container image's storage location on the service node, providing a foundation for subsequent operations.

[0111] In some embodiments, see Figure 3D , Figure 3A Step 102 shown can be implemented through steps 1021A to 1022A, as explained in detail below.

[0112] Step 1021A: Invoke the container group in the first service node to find the mapping configuration information corresponding to the target container image; the mapping configuration information includes the metadata of the container image and the storage information of the container image.

[0113] In some embodiments, mapping configuration information is a data structure or record that associates a container image with its storage location in the local file system. The mapping configuration information may include metadata about the container image and corresponding storage information. The container image's metadata contains detailed information about the container image, such as its name, version, creation time, and build history. The storage information includes the container image's storage location in the service node's local file system, including its storage path and other storage details, such as the storage method and size.

[0114] For example, in a Kubernetes cluster, a Pod can be configured with a hostPath field to access the underlying file system of the service node. This allows the Pod to directly mount the local file system directory of the service node, enabling the Pod to access files and directories on the service node and reflect changes to container image resources in real time.

[0115] In some embodiments, see Figure 3E , Figure 3D Step 1021A shown can be implemented through steps 10211 to 10212, as explained in detail below.

[0116] Step 10211: Access the container group's image repository interface service via the first service node using a domain name; the container group is located in the network namespace of the first service node.

[0117] In some embodiments, by configuring container group settings, the container group can be placed within the network namespace of the first service node, allowing the first service node to access the container group via domain name. The network namespace is the virtual network environment of the container group, containing its IP address, port, and routing rules. The Registry API service is a service process that provides an interface for interacting with image repositories.

[0118] For example, in a Kubernetes cluster, a Pod (container group) contains multiple containers, one of which acts as a Registry API service (image repository interface service), providing the Kubernetes cluster with the ability to manage container images through the Pod. By setting the hostNetwork field to true, the Pod shares the network of the service node, allowing the service node to directly access the Registry API service provided by the Pod when accessing the domain name.

[0119] Step 10212: Call the image repository interface service to find the mapping configuration information corresponding to the target container image.

[0120] In some embodiments, a request carrying a unique identifier of the target container image can be constructed and sent to the image repository interface service via protocols such as HTTP or gRPC. After receiving the request, the image repository interface service will return mapping configuration information that matches the container image in the request.

[0121] By calling the image repository interface service in step 10212 to find the mapping configuration information corresponding to the target container image, the detailed information of the target container image can be accurately obtained, including storage location, access permissions, etc. The management by the dedicated interface service can ensure the consistency and integrity of the image and avoid problems caused by image version confusion or corruption.

[0122] Next, see Figure 3D The following will be an explanation following step 1021A above.

[0123] Step 1022A: Determine the target storage location in the local file system of the first service node based on the mapping configuration information.

[0124] In some embodiments, mapping configuration information is first parsed, which contains the storage path, file name or other identifier of the container image; then, based on the parsed information, the local file system of the first service node is traversed or queried to find the specific storage location corresponding to the container image specified in the mapping configuration information.

[0125] For example, in a Kubernetes cluster, the mapping configuration information can be a YAML or JSON file containing the storage path of the container image. First, this mapping configuration file can be read to obtain the storage path of the container image, such as / var / lib / docker / registry / my-image; then, this path can be located in the local file system of the first service node to determine the specific storage location of the target container image.

[0126] By directly referencing the mapping configuration information in step 1022A, the image storage location can be determined automatically and accurately, eliminating the need for manual intervention, reducing configuration errors and search time, and improving the overall efficiency of responding to image pull requests.

[0127] Next, see Figure 3A The following will be an explanation following step 102 above.

[0128] Step 103: Obtain the target container image from the target storage location.

[0129] In some embodiments, standard file I / O operations provided by the operating system of the service node can be used to access and obtain target container image data stored in the local file system.

[0130] Step 104: Send the obtained target container image to the client corresponding to the image pull request.

[0131] In some embodiments, after reading the container image resources, the container image data can be divided into chunks or packaged into a data stream via HTTP, HTTPS or other reliable network protocols, and then directly transmitted to the client that initiated the image pull request.

[0132] Step 104 enables clients to reduce their reliance on external image repositories, improving image pull speed in private environments or restricted networks. Furthermore, transferring images directly from service nodes to clients, compared to downloading from public image repositories, allows for better control over data transfer bandwidth usage and reduces potential external access latency, further optimizing container image pull efficiency and user experience.

[0133] In some embodiments, the container image processing method may further include: when the current running state of any container group in the node cluster is abnormal, creating a new container group on the service node corresponding to the container group.

[0134] Whether a container group is currently running normally or abnormally can be determined based on its resource usage, network connectivity, and other factors. The new container group uses the same configuration as the original one, allowing it to seamlessly replace the previously abnormal container group and maintain service stability and consistency.

[0135] By creating new container groups, a rapid response can be achieved when the container group is in an abnormal state, ensuring the continuity and availability of the image repository service and preventing users from perceiving service downtime.

[0136] In some embodiments, the container image processing method may further include: in response to an image push request, determining a second service node from the node cluster; the image push request includes a newly created container image; and invoking the container group in the second service node to store the newly created container image in the local file system of the second service node.

[0137] An image push request is a request sent by a client to the node cluster to push a newly created container image to the image repository. This image push request can include metadata about the new container image (such as image name, tags, version, etc.) as well as data about the new container image itself. A new container image refers to a new container image built or created by the user in the client.

[0138] The second service node can be any service node in the node cluster. It can be selected from the cluster based on various strategies (such as load balancing, resource utilization, geographical location, etc.) to respond to image push requests and store the container image. The second service node can be the same as the first service node, or it can be two different service nodes.

[0139] By storing newly created container images in the local file system of the second service node, the persistence and reliability of container image data can be ensured. At the same time, this local storage method can also improve the efficiency of container image push due to the reduction of network transmission overhead. In addition, since the container group service has high-efficiency file I / O performance, this storage method also helps to improve the reading speed of container images.

[0140] In some embodiments, the container image processing method may further include: for each service node in the node cluster, detecting the local file system of the service node through the file system event detection interface; when a change in container image resources is detected in the local file system of the service node, synchronizing the changed container image to the local file system of other service nodes in the node cluster, excluding the service node, through a file synchronization component.

[0141] To ensure the consistency of container images stored across all service nodes in a node cluster, real-time monitoring of the local file system of each service node can be performed. This can be achieved, for example, by calling a file system event detection interface installed on each service node. This interface can capture various events on the local file system of that service node, such as file creation, modification, and deletion. Once a change in container image resources is detected in the local file system of a service node through the file system event detection interface, the file synchronization component is triggered. The file synchronization component then copies the changed container image data to the local file systems of all other service nodes in the cluster. Changes to container image resources refer to changes to resources related to the container image (such as image files and metadata files) in the local file system of the service node. These changes can include updates, deletions, or additions of container images.

[0142] For example, in a Kubernetes cluster, the Inotify tool can be used as a file system event detection interface, and Rsync can be used as a file synchronization component to detect the local file system of the service node and synchronize changes in container image resources.

[0143] By detecting the local file system of service nodes and synchronizing changed container images to other service nodes in the cluster, the speed and consistency of container image resource distribution and synchronization can be enhanced, ensuring high availability and fault tolerance of the entire node cluster. Automated file system event detection interface and file synchronization greatly reduce the operation and maintenance burden, reduce manual intervention and configuration errors, and improve the automation level and performance of container image management.

[0144] In some embodiments, the container image processing method may further include: determining the current running status of the file management virtual machine in the service nodes of the node cluster; determining the number of virtual machines in the normal state of the file management virtual machine in all service nodes based on the current running status of the file management virtual machine in the service nodes; when the number of virtual machines is less than a preset threshold, determining the current node running status of each service node in the node cluster and the number of service nodes whose current node running status is normal; when the number of service nodes in the normal state is greater than the number of virtual machines, creating a file management virtual machine in any service node that does not have a file management virtual machine and whose current node running status is normal.

[0145] Container groups can be file management virtual machines used to manage local file systems. The node cluster can periodically send heartbeats or query requests to collect response data from the file management virtual machines in the service nodes to determine their current running status. It then aggregates and analyzes the running status information of the file management virtual machines in each service node, filters out those in a normal state, and calculates the total number. If this total is less than a preset threshold, the current running status of each service node is determined, and the number of service nodes in a normal state is counted. When the number of service nodes in a normal state is sufficient (i.e., greater than the number of file management virtual machines), new file management virtual machines are automatically deployed and started on service nodes that currently have no file management virtual machines and are running normally. The preset threshold refers to the expected number of file management virtual machines set by the node cluster administrator.

[0146] For example, in a Kubernetes cluster, there are 5 service nodes, 2 of which have Pods for file management in normal state. However, the preset threshold is 3. In this case, a new Pod for file management needs to be created on one of the service nodes in normal state so that the number of service nodes in normal state meets the preset threshold requirement.

[0147] By monitoring the running status of file management virtual machines in the node cluster and promptly replenishing them when the number of virtual machines is insufficient, the elasticity and stability of cluster file management resources are ensured, storage access bottlenecks caused by insufficient file management virtual machines are prevented, and storage efficiency and risk resistance are improved.

[0148] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0149] This application proposes a method for constructing an image repository, so as to implement the above-mentioned container image processing method through the constructed image repository.

[0150] Related technologies utilize public image repositories such as Docker Hub, GitHub Container Registry, and Google Container Registry to achieve remote management of container images. However, the remote management process of container images has potential problems such as poor security, high cloud service costs, poor network connectivity (requiring public network connection), and low bandwidth speed. Alternatively, private image repositories can be built by deploying open-source image repository building technologies (such as Harbor). However, the installation and deployment process is complex, the operation and maintenance costs are high, and the high availability is poor. In addition, the related technologies use ordinary processes or containers to deploy image repositories, which lack rapid self-healing capabilities and high availability after the process or container runtime status becomes abnormal.

[0151] This application's embodiments utilize components such as Kubernetes clusters, Pods, Lsyncd, and local file systems to implement a localized image repository construction solution for cloud-native Kubernetes clusters. It features localization, containerized Pod deployment, real-time file synchronization, unified domain name access, automatic high-availability failover, and low operational costs, solving problems such as poor security, poor network connectivity, high cloud service costs, poor high availability, and high operational costs inherent in related technologies. Based on these characteristics, this application's embodiments can serve as an image repository construction solution for enterprise-internal private container services, or as a self-built image repository method for local development and testing environments.

[0152] In related technologies, image repositories can be divided into externally public types and internally private types. Externally public image repositories generally require public network access, which poses a security risk for internal enterprise applications, as these applications typically do not have external network access and are network isolated. However, this application's embodiment deploys a localized private image repository, eliminating the need to push container images to a remote image repository. This achieves network security isolation for business container images, reduces remote repository costs, and improves local operation and maintenance management capabilities. Figure 4 As shown, in this embodiment of the application, both the client and the local private image repository 600 are network isolated from the external public image repository 500. After the images (such as images 20-1, 20-2, and 20-3) are pushed to the local private image repository 600, the clients (such as clients 200-1, 200-2, 200-3, and 200-4) can pull the images through the container groups (such as container groups 601-1, 601-2, 601-3, and 601-4) of the service nodes in the Kubernetes cluster 700.

[0153] After deploying an image repository locally, business developers only need to pull images from the local image repository (ImagePull) and run containers. When a newly built container image is available, it can be published to the local image repository via an Image Push request, meeting the business's need for rapid container image pull and push capabilities. Furthermore, a local image repository no longer relies on public network bandwidth for image downloads, saving public network bandwidth costs. Typically, enterprise internal network speeds can reach tens or hundreds of MB / s, significantly improving the efficiency of container image pull and push. In an internal network environment, such as... Figure 5 As shown, the client can pull images through container group 601, which has already been containerized and deployed as an image repository management service in Kubernetes cluster 700.

[0154] The image repository constructed in this embodiment is itself a server process, provided to clients for access via an API. Related technologies typically deploy image repositories using processes or containers, which lack rapid self-healing capabilities and high availability after a process or container malfunctions. In contrast, this embodiment uses Pods within a Kubernetes cluster for containerized deployment of the image repository component. This allows for flexible control over the number of Pods on service nodes. When a Pod or service node fails, the Kubernetes cluster automatically starts a new Pod and continuously monitors the number of Pods running normally to ensure that the number of Pods in a normal running state meets the expected number (e.g., 3), thus achieving high availability for container images.

[0155] This application embodiment deploys the image repository using Pod containerization. By setting the hostNetwork configuration item to "true", the Pod shares the service node's network. This allows the service node to directly access the Registry API service (image repository interface service) provided by the Pod image repository when accessing via domain name. The container image resources stored by the Pod are shared with the service node in real time via host path. Figure 6 As shown, in the Kubernetes cluster 700 of this application embodiment, the container image resources 603 and the file detection and synchronization tool 604 (such as the Lsyncd tool) in the service node 602 are managed by the container group 601.

[0156] This application embodiment uses the Lsyncd tool to achieve real-time synchronization of the internal file system of the image repository, realizing real-time file synchronization in the image repository composed of multiple service nodes. Client and server roles can be dynamically assigned among the multiple service nodes, and container image resources can be synchronized with each other in real time. Any service node has access to the full set of container image resources. For example... Figure 7 As shown, in the Kubernetes cluster 700 of this application embodiment, service nodes 110-1, 110-2, and 110-3 synchronize container image resources through file detection and synchronization tools 603-1, 603-2, and 603-3, respectively, so that the data files stored in container image resources 602-1, 602-2, and 602-3 are consistent.

[0157] This application embodiment can containerize the Lsyncd component, which is used for real-time synchronization of container image resources, in the Pod. During the first deployment, the Lsyncd container image resources are introduced into the service node in a deployable and pre-configured state, and the Pod can be started and the Lsyncd component can be run.

[0158] This application embodiment enables unified image repository domain name access across Kubernetes cluster service nodes or Pods within those service nodes by customizing CoreDNS rules. CoreDNS rules can be configured with IP lists corresponding to multiple nodes (e.g., Node-1, Node-2, and Node-3) to achieve load balancing across multiple service nodes. When one service node malfunctions, the Domain Name System (DNS) will sequentially try the remaining IP addresses in the IP list. As long as one service node is functioning correctly, high availability access to the domain name will not be affected. Figure 8 As shown, in the Kubernetes cluster 700 of this application embodiment, the domain name 605 (such as "my.registry.com") can be resolved through the domain name system 604, and any service node (such as service node 110-2) can be accessed.

[0159] In this embodiment of the application, unified domain name access is achieved through CoreDNS configuration rules. Alternatively, unified domain name access can also be achieved by directly configuring / etc / hosts and configuring the service node IP corresponding to the domain name on each service node.

[0160] This application embodiment uses multiple (e.g., three) service nodes to form an image repository. If any service node or the Pod managing the image repository becomes abnormal, a new Pod can be automatically restarted, achieving high availability for the image repository. During implementation, when a Pod or node fails, the Kubernetes cluster automatically restarts a new Pod. The Deployment Controller continuously monitors the number of Pods running normally. If the number does not reach a preset threshold, a new Pod is automatically created until the desired number of Pods (e.g., three) is met.

[0161] In this embodiment, after any service node experiences an abnormal operating state, the Pod's tolerance time (Toleration Seconds) can be set to 30. This means that if the service node recovers to a normal state within 30 seconds, a new Pod does not need to be rebuilt; if the service node has not recovered to a normal state after 30 seconds, the Pod on that service node is deleted, and a new Pod is created on a service node that is now in a normal operating state, thus achieving stable high availability of the image repository. Figure 9 As shown, when service node 110-1 in the Kubernetes cluster 700 of this application embodiment fails, file detection and synchronization tool 603-1 becomes ineffective, and file detection and synchronization tools 603-2 and 603-3 no longer perform file synchronization with node 101-1.

[0162] The image repository constructed in this application embodiment can also expose services to the outside world through Service or Ingress, so as to import container images from external image repositories into the local image repository, thereby ensuring flexible operation and maintenance capabilities for different roles.

[0163] This application's embodiments deploy the image repository locally, eliminating the need to push images to a remote image repository. This achieves network security isolation for business images, reduces remote repository costs, and improves local operation and maintenance management capabilities. The image repository component is deployed in a containerized manner using Pods within a Kubernetes cluster, allowing for flexible replica control. When a Pod fails, the Kubernetes cluster automatically starts a new Pod, providing continuous and stable availability. The Lsyncd tool is used to achieve real-time synchronization of the internal file system of the image repository, enabling real-time file synchronization across multiple service nodes. Multiple service nodes act as primary and backup nodes, with each service node having access to all container image resources. By customizing CoreDNS rules in the Kubernetes cluster, a unified image repository domain name can be accessed on service nodes or within container groups (Pods). The repository domain name can be something like "my.registry.com". An image repository is constructed using multiple service nodes (e.g., three). If any service node or the Pod managing the image repository experiences an abnormal running state, a new Pod can be automatically started, providing high availability. The embodiments of this application can serve as a solution for building image repositories for enterprise internal and private container services, satisfying core issues such as business security, network connectivity, cloud service costs, and high availability.

[0164] The following continues to describe the exemplary structure of the container image processing device 455 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2As shown, the software modules stored in the container image processing device 455 in the memory 450 may include: a request response module 4551, used to determine a first service node from the node cluster in response to an image pull request for a target container image; the node cluster includes multiple service nodes, and the multiple service nodes share container image resources in the image repository; the container image resources are stored in the local file system of the service node; a container group invocation module 4552, used to invoke the container group in the first service node to determine the target storage location of the target container image from the local file system of the first service node; a container image acquisition module 4553, used to acquire the target container image from the target storage location; and a container image sending module 4554, used to send the acquired target container image to the client corresponding to the image pull request.

[0165] In some embodiments, the request response module 4551 is further configured to: in response to an image pull request for a target container image, parse the domain name system configuration file of the node cluster to obtain a list of network addresses of all service nodes in the node cluster; obtain the target network address from the list of network addresses; and determine the service node corresponding to the target network address as the first service node.

[0166] In some embodiments, the request response module 4551 is further configured to: sequentially traverse the network addresses in the network address list; when the current running state of the service node corresponding to the current network address is abnormal, continue traversing the next network address adjacent to the current network address in the network address list; when the current running state of the service node corresponding to the current network address is normal, determine the service node corresponding to the current network address as the target network address and stop traversing.

[0167] In some embodiments, the container group invocation module 4552 is further configured to: invoke the container group in the first service node to find the mapping configuration information corresponding to the target container image; the mapping configuration information includes the metadata of the container image and the storage information of the container image; and determine the target storage location in the local file system of the first service node according to the mapping configuration information.

[0168] In some embodiments, the container group invocation module 4552 is further configured to: access the container group's image repository interface service via a domain name access through the first service node; the container group is located in the network namespace of the first service node; and invoke the image repository interface service to find the mapping configuration information corresponding to the target container image.

[0169] In some embodiments, the apparatus further includes a container group creation module, configured to create a new container group on the service node corresponding to the container group when the current running state of any container group in the node cluster is an abnormal state.

[0170] In some embodiments, the apparatus further includes: an image push module, configured to determine a second service node from the node cluster in response to an image push request; the image push request includes a newly created container image; and invoke the container group in the second service node to store the newly created container image in the local file system of the second service node.

[0171] In some embodiments, the apparatus further includes: a file synchronization module, used to detect the local file system of each service node in the node cluster through a file system event detection interface; when a change in container image resources is detected in the local file system of a service node, the changed container image is synchronized to the local file system of other service nodes in the node cluster, excluding the service node, through the file synchronization component.

[0172] In some embodiments, the container group is a file management virtual machine for managing a local file system. The apparatus further includes: a virtual machine maintenance module, configured to: determine the current running state of the file management virtual machines in the service nodes of the node cluster; determine the number of virtual machines in normal state among all service nodes based on the current running state of the file management virtual machines in the service nodes; when the number of virtual machines is less than a preset threshold, determine the current node running state of each service node in the node cluster and the number of service nodes whose current node running state is normal; when the number of service nodes in normal state is greater than the number of virtual machines, create a file management virtual machine in any service node that does not have a file management virtual machine and whose current node running state is normal.

[0173] This application provides a computer program product including a computer program or computer-executable instructions stored in a computer-readable storage medium. An electronic device's processor reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the container image processing method described above in this application.

[0174] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the container image processing method provided in this application. For example, ... Figure 3A The container image processing method is shown.

[0175] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0176] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0177] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0178] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located in one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0179] In summary, by distributing requests among multiple service nodes in a node cluster and utilizing locally stored container image resources, the need to download container images from a remote image repository can be avoided, thereby reducing network latency and improving the speed and response time of container image retrieval. Furthermore, by sharing container image resources within the image repository among multiple service nodes, it is ensured that even if a service node fails, it can still obtain container image resources from other nodes that are running normally, thus guaranteeing the reliability and stability of the container image retrieval service.

[0180] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A container image processing method, characterized in that, include: In response to an image pull request for the target container image, determine the first service node from the node cluster; The node cluster includes multiple service nodes, and the multiple service nodes share container image resources in the image repository; The container image resources are stored in the local file system of the service node; Invoke the container group in the first service node to determine the target storage location of the target container image from the local file system of the first service node; Obtain the target container image from the target storage location; The obtained target container image is sent to the client corresponding to the image pull request.

2. The method according to claim 1, characterized in that, The step of determining the first service node from the node cluster in response to an image pull request for the target container image includes: In response to an image pull request for the target container image, the domain name system configuration file of the node cluster is parsed to obtain a list of network addresses of all service nodes in the node cluster. Obtain the target network address from the network address list; The service node corresponding to the target network address is determined as the first service node.

3. The method according to claim 2, characterized in that, Obtaining the target network address from the network address list includes: Iterate through the network addresses in the network address list in sequence; When the current running state of the service node corresponding to the current network address is abnormal, continue to traverse the network address list to the next network address adjacent to the current network address; When the current running status of the service node corresponding to the current network address is normal, the service node corresponding to the current network address is determined as the target network address, and the traversal is stopped.

4. The method according to claim 1, characterized in that, The step of invoking the container group in the first service node to determine the target storage location of the target container image from the local file system of the first service node includes: The container group in the first service node is invoked to find the mapping configuration information corresponding to the target container image; the mapping configuration information includes the metadata of the container image and the storage information of the container image. Based on the mapping configuration information, the target storage location in the local file system of the first service node is determined.

5. The method according to claim 4, characterized in that, The step of calling the container group in the first service node to find the mapping configuration information corresponding to the target container image includes: The container group's image repository interface service is accessed via a domain name through the first service node; the container group resides in the network namespace of the first service node. Call the image repository interface service to find the mapping configuration information corresponding to the target container image.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: When the current running state of any container group in the node cluster is abnormal, a new container group is created on the service node corresponding to the container group.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: In response to the image push request, a second service node is determined from the node cluster; the image push request includes the creation of a new container image; The container group in the second service node is invoked to store the newly created container image in the local file system of the second service node.

8. The method according to any one of claims 1 to 5, characterized in that, The method further includes: For each service node in the node cluster, the local file system of the service node is detected through the file system event detection interface; When a change in container image resources is detected in the local file system of the service node, the changed container image is synchronized to the local file systems of other service nodes in the node cluster, excluding the service node itself, through a file synchronization component.

9. The method according to any one of claims 1 to 5, characterized in that, The container group is a file management virtual machine used to manage the local file system; the method further includes: Determine the current running status of the file management virtual machine in the service node of the node cluster; Based on the current running status of the file management virtual machine in the service node, determine the number of file management virtual machines in normal status across all service nodes. When the number of virtual machines is less than a preset threshold, determine the current running status of each service node in the node cluster and the number of service nodes whose current running status is normal. When the number of service nodes in normal state is greater than the number of virtual machines, a file management virtual machine is created in any service node that does not have a file management virtual machine and whose current node is in normal state.

10. A container image processing device, characterized in that, The device includes: The request-response module is used to respond to an image pull request for a target container image and determine a first service node from the node cluster; the node cluster includes multiple service nodes, and the multiple service nodes share container image resources in the image repository; the container image resources are stored in the local file system of the service node; The container group invocation module is used to invoke the container group in the first service node and determine the target storage location of the target container image from the local file system of the first service node. A container image acquisition module is used to acquire the target container image from the target storage location; The container image sending module is used to send the acquired target container image to the client corresponding to the image pull request.

11. An electronic device, characterized in that, include: Memory is used to store executable instructions for a computer; A processor, when executing computer-executable instructions stored in the memory, implements the container image processing method according to any one of claims 1 to 9.

12. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the container image processing method according to any one of claims 1 to 9 is implemented.

13. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the container image processing method according to any one of claims 1 to 9 is implemented.

Images