Application upgrade method and device based on cluster container

Abstract

The present invention can be used in the field of big data technology. The present invention provides an application upgrade method and device based on cluster containers. The application upgrade method based on cluster containers includes: receiving a native load balancing model and a target image version of the application to be upgraded; determining a pod list corresponding to the native load balancing model; and modifying the image file in the pod file to the target image version according to the pod list. The present invention can implement in-place upgrades of containers in cluster containers based on native workload deployment. Compared with implementing in-place upgrades of containers in cluster containers based on newly added custom workloads, it can save migration workload, avoid risks brought by migration, save time for rescheduling cluster containers, and speed up upgrades.

Description

Technical Field

[0001] The present invention belongs to the technical field of big data, and in particular relates to an application upgrading method and device based on a cluster container. Background Art

[0002] In the existing technology, with the rapid development of DOKCER container technology, KUBERNETES has become the de facto standard for container orchestration management. More and more companies use KUBERNETES to manage cluster containers for application release and deployment. Currently, most applications use KUBERNETES' native DEPLOYMENT workload to deploy and run containers. During the application image upgrade process, DEPLOYMENT will trigger the new version of REPLICASET to create a cluster container and delete the old version of the cluster container. During the upgrade process, the original cluster container is deleted and a new cluster container is created. The new cluster container will be scheduled to be recreated on another host. The re-creation process involves calculating new nodes and pulling images on the new host, which takes a long time.

[0003] In response to the cluster container rescheduling phenomenon that occurs every time the cluster container image version is upgraded in the current DEPLOYMENT, the industry's open source OPENKRUSIE software provides a custom WORKLOAD controller based on the Kubernetes extension mechanism, such as CLONESET, which can realize the in-place upgrade of the container in CLONESET (that is, the image version corresponding to the container is upgraded, but it will not be scheduled to the new host machine).

[0004] The existing technical solution uses a newly added custom WORKLOAD, and does not propose an in-place upgrade solution for Kubernetes native WORKLOADs such as DEPLOYMENT. For important applications that have deployed a large number of containers using DEPLOYMENT in the production environment, if the existing technical solution is used, it is necessary to use a new WORKLOAD such as CLONESET to redeploy the application, which is time-consuming and risky. Summary of the invention

[0005] The present invention belongs to the field of big data technology. The cluster container-based application upgrade method and device provided by the present invention can realize in-place upgrade of containers in the cluster container based on native workload deployment. Compared with realizing in-place upgrade of containers in the cluster container based on newly added custom workload, it can save migration workload, avoid risks brought by migration, save time for rescheduling cluster containers, and speed up the upgrade speed.

[0006] In order to solve the above technical problems, the present invention provides the following technical solutions:

[0007] In a first aspect, the present invention provides an application upgrade method based on a cluster container, comprising:

[0008] Receive the native load balancing model and target image version of the application to be upgraded;

[0009] Determine the pod list corresponding to the native load balancing model;

[0010] Modify the image file in the pod file to the target image version according to the pod list.

[0011] In one embodiment, determining the pod list corresponding to the native load balancing model includes:

[0012] In the cluster container, query the pod list corresponding to the native load balancing model.

[0013] In one embodiment, the cluster container-based application upgrade method further includes:

[0014] The pod list is saved in the mapping information of the host IP to update the mapping information.

[0015] In one embodiment, the cluster container-based application upgrade method further includes:

[0016] Compare the mapping information before and after the update to identify the pod files whose IP information has changed and the pod files whose IP information has not changed;

[0017] The pod file whose IP information has changed and the pod file whose IP information has not changed are sent to the user.

[0018] In one embodiment, modifying the image file in the pod file to the target image version according to the pod list includes:

[0019] Call the patch api file according to the pod list;

[0020] Modify the spec.container*.image file in the pod file to the target image version according to the patch api file.

[0021] In a second aspect, the present invention provides an application upgrade device based on a cluster container, comprising:

[0022] Model receiving module, which is used for the native load balancing model and target image version of the application to be upgraded;

[0023] A list determination module, used to determine a pod list corresponding to the native load balancing model;

[0024] The image file modification module is used to modify the image file in the pod file to the target image version according to the pod list.

[0025] In one embodiment, the list determination module is specifically used to query the pod list corresponding to the native load balancing model in the cluster container.

[0026] In one embodiment, the cluster container-based application upgrade device further includes:

[0027] A mapping information update module, used to save the mapping information of the pod list to the host IP to update the mapping information;

[0028] The mapping information comparison module is used to compare the mapping information before and after the update to determine the pod files whose IP information has changed and the pod files whose IP information has not changed;

[0029] Send the pod file whose IP information has changed and the pod file whose IP information has not changed to the user;

[0030] The image file modification module includes:

[0031] A file calling unit, used to call the patch API file according to the pod list;

[0032] The image file modification unit is used to modify the spec.container*image file in the cluster container definition file to a target image version according to the patch api file.

[0033] In a third aspect, the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, steps of a cluster container-based application upgrade method are implemented.

[0034] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a cluster container-based application upgrade method.

[0035] From the above description, it can be seen that the application upgrade method and device based on cluster container provided by the embodiment of the present invention first receives the native load balancing model and target image version of the application to be upgraded; determines the pod list corresponding to the native load balancing model; and modifies the image file in the pod file to the target image version according to the pod list. The present invention can perform in-place upgrade of containers based on Kubernetes native workload, without migrating applications deployed based on Kubernetes native load model to custom load model, saving the workload of application migration and avoiding the risks brought by migration. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0037] Figure 1 The following is a schematic diagram of the application upgrade method based on the cluster container in an embodiment of the present invention. Figure 1 ;

[0038] Figure 2 1 is a flow chart of step 100 in the cluster container-based application upgrade method in an embodiment of the present invention;

[0039] Figure 3 The following is a schematic diagram of the application upgrade method based on the cluster container in an embodiment of the present invention. Figure 2 ;

[0040] Figure 4 The following is a schematic diagram of the application upgrade method based on the cluster container in an embodiment of the present invention. Figure 3 ;

[0041] Figure 5 This is a flow chart of step 300 in the cluster container-based application upgrade method in an embodiment of the present invention;

[0042] Figure 6 It is a schematic diagram of the process of an application upgrade method based on a cluster container in a specific application example of the present invention;

[0043] Figure 7 The structure of the application upgrade device based on the cluster container in the specific application example of the present invention is shown as follows Figure 1 ;

[0044] Figure 8 The structure of the application upgrade device based on the cluster container in the specific application example of the present invention is shown as follows Figure 2 ;

[0045] Fig. 9 It is a structural block diagram of the image file modification module 30 in an embodiment of the present invention;

[0046] Fig.10 It is a schematic diagram of the structure of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0048] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0049] It should be noted that the terms "including" and "having" and any variations thereof in the specification and claims of the present application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or apparatus comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or apparatuses.

[0050] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0051] The embodiment of the present invention provides a specific implementation of an application upgrade method based on a cluster container, see Figure 1 , the method specifically includes the following contents:

[0052] Step 100: Receive the native load balancing model and target image version of the application to be upgraded.

[0053] Specifically, obtain the name of the native load balancing model that the user wants to upgrade and the target image version that the user wants to upgrade. When the user's access volume is too large, there are too many requests for computer resources on a single machine, resulting in excessive load, so a native load balancing model is needed, which is used to distribute the load among multiple computers (computer clusters), network connections, CPUs, disk drives or other resources to achieve the purpose of optimizing resource utilization, maximizing throughput, minimizing response time, and avoiding overload. Server load balancing is divided into four-layer server load balancing and seven-layer load balancing according to the message level processed by the LB device. The four-layer processes the IP header of the IP packet and does not parse the payload of the message above the four layers (L4 SLB); the seven-layer processes the message payload part, such as HTTP, RTSP, SIP message header, and sometimes also includes the message content part (L7 SLB).

[0054] Four-layer server load balancing: The client sends a request to the load balancing device at the front end of the server group. The virtual service on the load balancing device receives the client request, selects a real server through the scheduling algorithm, and then rewrites the target address of the request message with the real server address through network address translation, and then sends the request to the selected real server; when the response message of the real server passes through the load balancing device, the source address of the message is restored to the VSIP of the virtual service, and then returned to the client, completing the entire load scheduling process. The message interaction process is as follows: (1) The host sends a service request message, with the source IP being the HostIP and the destination IP being the VSIP; (2) After receiving the request message, the LB Device uses the scheduling algorithm to calculate which server the request should be distributed to; (3) The LB Device uses DNAT technology to distribute messages, with the source IP being the Host IP and the destination IP being the ServerIP; (4) The server receives and processes the request message, and returns a response message, with the source IP being the Server IP and the destination IP being the Host IP; (5) The LB Device receives the response message, converts the source IP and forwards it, with the source IP being the VSIP and the destination IP being the Host IP;

[0055] Seven-layer server load balancing: Compared with four-layer load balancing, seven-layer load balancing only has different load balancing basis. After selecting a certain real server, the processing is basically the same. The following takes HTTP application load balancing as an example to explain. Since the real request content of HTTP cannot be obtained during the TCP handshake stage, the client's TCP handshake message cannot be directly forwarded to the server. The load balancing device must first complete the TCP handshake with the client, and then select the server after receiving enough seven-layer content. The load balancing device and the selected server establish a TCP connection. There is a significant difference between the seven-layer load balancing network and the four-layer load balancing network: in the four-layer load balancing, each virtual service corresponds to a real service group, and all real servers in the real service group provide the same service; in the seven-layer load balancing, each virtual service corresponds to multiple real service groups, and each group of real servers provides the same service. Select the corresponding real service group according to the message content, and then select a real server according to the real service group scheduling algorithm.

[0056] Step 200: Determine a pod list corresponding to the native load balancing model.

[0057] It is understandable that Docker is an open source application container engine that allows developers to package their applications and dependent packages into a portable image, and then publish them to any popular Linux or Windows machine, and can also achieve virtualization. Containers use a sandbox mechanism completely, and there will be no interface between them. Similar to a lightweight sandbox (because Docker is a virtual technology based on the Linux kernel, it consumes very few resources), Docker uses containers to run and isolate applications. Containers are application running instances created from images, which can be started, started, stopped, and deleted, and these containers are isolated and invisible to each other. Each container can be regarded as a simplified version of the Linux system environment (including root user permissions, process space, user space, and network space), as well as an application box packaged with the application running in it.

[0058] A complete Docker consists of the following parts: DockerClient; Docker Daemon; Docker Image; DockerContainer. Docker uses the client-server (C / S) architecture mode and uses remote APIs to manage and create Docker containers. Docker containers are created through Docker images. The relationship between containers and images is similar to that between objects and classes in object-oriented programming.

[0059] Docker uses a client / server architecture. Docker daemon is the server that accepts requests from clients and processes these requests (creating, running, and distributing containers). The client and server can run on the same machine or communicate through sockets or RESTful APIs. Docker daemon usually runs in the background of the host host, waiting to receive messages from the client. The Docker client provides users with a series of executable commands, which users use to interact with the Docker daemon.

[0060] Here we use Kubernetes to explain containers, pods, and cluster containers: When pods are deployed in Kubernetes, they are basically packaging or houses for individual containers. In a sense, containers of containers. A pod is a logical packaging entity used to execute containers on a K8s cluster. You can think of each pod as a transparent package that provides a slot for a container. Pod is the smallest deployable unit of Kubernetes. "A pod is a group of one or more containers with shared storage / network resources and specifications for how to run containers." So, in the simplest terms, a pod is a mechanism for how a container is "used" in Kubernetes. The cluster is at the core of the basic architecture of Kubernetes: if you run Kubernetes, then you run at least one cluster (there is no Kubernetes deployment without a cluster).

[0061] Step 300: modify the image file in the pod file to the target image version according to the pod list.

[0062] The image file in step 300 is similar to the image of a virtual machine. It can be understood as a read-only template for the Docker engine, including a file system. When a container is started from the image, Docker will create a writable layer on the top of the image, and the image itself will remain unchanged. Just like after installing the system with ISO, there is no change in ISO.

[0063] As one of the core components of Docker technology, the image repository is mainly responsible for the storage and distribution of image content. In terms of the scope of use, Docker image repositories are divided into "public image repositories" and "private image repositories". Public image repositories can be used by anyone, such as the online repository Docker Hub maintained by Docker and the online Docker image library provided by some cloud service providers (such as Alibaba Cloud), which all belong to the category of public image repositories. Private image repositories refer to image repositories deployed within a company or organization for the storage and distribution of its own application Docker images. In the process of building an automated release system for internal use in a company, from a security perspective, the packaged images of applications are generally only stored in private image repositories, and the connection points of the CI / CD process are also completed by uploading and pulling images to private image repositories.

[0064] From the above description, it can be seen that the application upgrade method based on cluster containers provided by the embodiment of the present invention first receives the native load balancing model and the target image version of the application to be upgraded; determines the pod list corresponding to the native load balancing model; and modifies the image file in the pod file to the target image version according to the pod list. The present invention can perform in-place upgrades of containers based on Kubernetes native workloads, without the need to migrate applications deployed based on the Kubernetes native load model to a custom load model, saving the workload of application migration and avoiding the risks brought by migration.

[0065] In one embodiment, see Figure 2 , step 200 comprises:

[0066] Step 201: In the cluster container, query the pod list corresponding to the native load balancing model.

[0067] In one embodiment, see Figure 3 , the application upgrade method based on cluster container also includes:

[0068] Step 400: Save the pod list to the mapping information of the host IP to update the mapping information.

[0069] Specifically, query the pod list corresponding to the native load balancing model and save the mapping information of each pod to the corresponding host IP.

[0070] In one embodiment, see Figure 4 , the application upgrade method based on cluster container also includes:

[0071] Step 500: Compare the mapping information before and after the update to determine the pod files whose IP information has changed and the pod files whose IP information has not changed;

[0072] Step 600: Send the pod file whose IP information has changed and the pod file whose IP information has not changed to the user.

[0073] After the modification is completed, query the pod list corresponding to the native load model again, save the mapping information of each pod to the corresponding host IP, compare the existing mapping relationship with the old mapping saved in the second step, record the pods whose IP information has changed and the pods that have not changed, and feedback to the user.

[0074] In one embodiment, see Figure 5 , step 300 comprises:

[0075] Step 301: calling the patch API file according to the pod list;

[0076] Step 302: modify the spec.container*.image file in the pod file to the target image version according to the patch api file.

[0077] Specifically, according to the pod list, the patch API provided by Kubernetes is called in a loop to modify spec.container[*].image in the pod definition file one by one to the target image version.

[0078] To further illustrate this solution, the present invention takes Kubernetes as an example to provide a specific application example of an application upgrade method based on a cluster container. Figure 6 , the method specifically comprises the following steps:

[0079] Kubernetes, or K8s for short, is an abbreviation that replaces the eight characters in "ubernete" with "8". It is an open source containerized application management platform for multiple hosts. The goal of Kubernetes is to make the deployment of containerized applications simple and powerful. Kubernetes provides a mechanism for application deployment, planning, updating, and maintenance.

[0080] The traditional way of deploying applications is to install them through plug-ins or scripts. The disadvantage of this is that the operation, configuration, management, and entire life cycle of the application will be bound to the current operating system, which is not conducive to application upgrades / rollbacks. Of course, some functions can be implemented by creating virtual machines, but virtual machines are very heavy and not conducive to portability.

[0081] The new approach is to deploy containers. Each container is isolated from each other, each container has its own file system, and the processes between containers will not affect each other, and computing resources can be distinguished. Compared with virtual machines, containers can be deployed quickly. Since containers are decoupled from the underlying facilities and machine file systems, they can be migrated between different clouds and different versions of operating systems.

[0082] Containers take up less resources and are quick to deploy. Each application can be packaged into a container image. The one-to-one relationship between each application and the container also gives containers greater advantages. Using containers, you can create container images for applications during the build or release phase, because each application does not need to be combined with the rest of the application stack, nor does it rely on the production environment infrastructure, which enables a consistent environment from R&D to testing and production. Similarly, containers are lighter and more "transparent" than virtual machines, which makes them easier to monitor and manage.

[0083] The specific application example of the present invention also provides a system for in-situ upgrading of containers in Kubernetes, which specifically includes: a front-end module and an upgrade module.

[0084] The front-end module calls the API provided by Kubernetes to query and display all workload information in the Kubernetes cluster. At the same time, the front-end module calls the API of the image repository to query and display all image information and corresponding version information in the current repository; the image repository is used by the Kubernetes cluster. At the same time, based on the displayed information, the front-end module receives user input and obtains the name of the native load that the user wants to upgrade and the target image version that the user wants to upgrade. The front-end module transmits the obtained native load name and target image version to the upgrade module.

[0085] The upgrade module obtains the name of the native load and the target image version from the front-end module. The pod list corresponding to the native load is queried according to the native load name, and the mapping relationship between each pod and the deployed host IP is saved. The upgrade module calls the patch API provided by Kubernetes to modify the spec.container[*].image of the target image in the pod definition file one by one to the target image and the corresponding version. After the modification is completed, the upgrade module calls the Kubernetes API again to query the corresponding pod list according to the native load name, and saves the mapping information of each pod to the corresponding host IP. The upgrade module compares the existing mapping relationship with the old mapping saved in the second step, records the pods whose IP information has changed and the pods that have not changed, and transmits them to the front-end module for display to inform the user of the upgrade results.

[0086] Based on the above-mentioned system for in-place upgrading of containers in Kubernetes, the cluster container-based application upgrading method provided by the specific application example of the present invention includes the following steps:

[0087] S1: Obtain the name of the native load model that the user wants to upgrade and the target image version that the user wants to upgrade.

[0088] S2: Query the pod list corresponding to the native load balancing model and save the mapping information of each pod to the corresponding host IP.

[0089] S3: Based on the pod list, call the patch API provided by Kubernetes in a loop to modify spec.container[*].image in the pod definition file one by one to the target image version.

[0090] S4: After the modification is completed, query the pod list corresponding to the native load model again, save the mapping information of each pod to the corresponding host IP, compare the existing mapping relationship with the old mapping saved in the second step, record the pods whose IP information has changed and the pods that have not changed, and feedback to the user.

[0091] From the above description, it can be seen that the application upgrade method based on cluster containers provided by the embodiment of the present invention first receives the native load balancing model and the target image version of the application to be upgraded; determines the pod list corresponding to the native load balancing model; and modifies the image file in the pod file to the target image version according to the pod list. The present invention can perform in-place upgrades of containers based on Kubernetes native workloads, without the need to migrate applications deployed based on Kubernetes native load models to custom load models, saving the workload of application migration and avoiding the risks brought by migration. On the other hand, the present invention saves the time of rescheduling pods and speeds up upgrades.

[0092] Based on the same inventive concept, the embodiments of the present application also provide an application upgrade device based on a cluster container, which can be used to implement the method described in the above embodiments, such as the following embodiments. Since the principle of solving the problem by the application upgrade device based on a cluster container is similar to that of the application upgrade method based on a cluster container, the implementation of the application upgrade device based on a cluster container can refer to the implementation of the application upgrade method based on a cluster container, and the repeated parts will not be repeated. As used below, the term "unit" or "module" can be a combination of software and / or hardware that implements a predetermined function. Although the system described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceived.

[0093] The embodiment of the present invention provides a specific implementation of a cluster container-based application upgrade device capable of implementing a cluster container-based application upgrade method, see Figure 7 The application upgrade device based on the cluster container specifically includes the following contents:

[0094] Model receiving module 10, for the native load balancing model of the application to be upgraded and the target image version;

[0095] A list determination module 20, used to determine a pod list corresponding to the native load balancing model;

[0096] The image file modification module 30 is used to modify the image file in the pod file to a target image version according to the pod list.

[0097] In one embodiment, the list determination module is specifically used to query the pod list corresponding to the native load balancing model in the cluster container.

[0098] In one embodiment, see Figure 8 The application upgrade device based on the cluster container also includes:

[0099] A mapping information updating module 40 is used to save the mapping information of the pod list to the host IP to update the mapping information;

[0100] A mapping information comparison module 50 is used to compare the mapping information before and after the update to determine the pod files whose IP information has changed and the pod files whose IP information has not changed;

[0101] The file sending module 60 is used to send the pod file whose IP information has changed and the pod file whose IP information has not changed to the user;

[0102] In one embodiment, see Fig. 9 , the image file modification module 30 includes:

[0103] A file calling unit 301 is used to call the patch API file according to the pod list;

[0104] The image file modification unit 302 is used to modify the spec.container*image file in the cluster container definition file to a target image version according to the patch api file.

[0105] From the above description, it can be seen that the application upgrade device based on cluster containers provided by the embodiment of the present invention first receives the native load balancing model and the target image version of the application to be upgraded; determines the pod list corresponding to the native load balancing model; and modifies the image file in the pod file to the target image version according to the pod list. The present invention can perform in-place upgrades of containers based on Kubernetes native workloads, without the need to migrate applications deployed based on Kubernetes native load models to custom load models, saving the workload of application migration and avoiding the risks brought by migration. On the other hand, the present invention saves the time of rescheduling pods and speeds up upgrades.

[0106] Reference below Fig.10 , which shows a structural schematic diagram of an electronic device 600 suitable for implementing an embodiment of the present application.

[0107] like Fig.10 As shown, electronic device 600 includes a central processing unit (CPU) 601, which can perform various appropriate operations and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. In RAM 603, various programs and data required for the operation of system 600 are also stored. CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to bus 604.

[0108] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed as needed as the storage section 608.

[0109] In particular, according to an embodiment of the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present invention includes a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the above-mentioned method for determining the distance between people in a data center scenario are implemented, and the steps include:

[0110] Step 100: Receive the native load balancing model and target image version of the application to be upgraded;

[0111] Step 200: Determine a pod list corresponding to the native load balancing model;

[0112] Step 300: modify the image file in the pod file to the target image version according to the pod list.

[0113] In such an embodiment, the computer program may be downloaded and installed from a network via the communication section 609 , and / or installed from the removable medium 611 .

[0114] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0115] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0116] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0117] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, commodity or device including the element.

[0118] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0119] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A cluster container-based application upgrade method, characterized in that: include: Receive the native load balancing model and target image version of the application to be upgraded; Determine the pod list corresponding to the native load balancing model; Modify the image file in the pod file to the target image version according to the pod list; wherein the native load balancing model is used to distribute the load among multiple computers, network connections, CPUs, disk drives or other resources to optimize resource usage, maximize throughput, minimize response time, and avoid overload; specifically, server load balancing is divided into four-layer server load balancing and seven-layer load balancing according to the message level processed by the LB device. The four-layer processes the IP header of the IP packet and does not parse the payload above the four-layer of the message; the seven-layer processes the message payload part, which includes HTTP, RTSP, SIP message headers and message content; For the four-layer server load balancing: the client sends a request to the load balancing device at the front end of the server group, the virtual service on the load balancing device receives the client request, selects a real server through a scheduling algorithm, and then rewrites the target address of the request message with the real server address through network address translation, and then sends the request to the selected real server; when the response message of the real server passes through the load balancing device, the source address of the message is restored to the VSIP of the virtual service, and then returned to the client, completing the entire load scheduling process. Specifically, the message interaction process is as follows: (1) The host sends a service request message, with the source IP being the host IP and the destination IP being the VSIP; (2) After receiving the request message, the LB Device uses the scheduling algorithm to calculate the target server to which the request should be distributed; (3) LB Device uses DNAT technology to distribute messages, with the source IP being the host IP and the destination IP being the server IP; (4) The server receives and processes the request message and returns a response message with the source IP being the server IP and the destination IP being the host IP; (5) The LB Device receives the response message, converts the source IP, and then forwards it. The source IP is the VSIP and the destination IP is the host IP. Modifying the image file in the pod file to the target image version according to the pod list includes: Call the patch api file according to the pod list; Modify the spec.container*.image file in the pod file to the target image version according to the patch api file.

2. The cluster container-based application upgrade method according to claim 1, characterized in that: Determining the pod list corresponding to the native load balancing model includes: In the cluster container, query the pod list corresponding to the native load balancing model.

3. The cluster container-based application upgrade method according to claim 1, characterized in that: Also includes: The pod list is saved in the mapping information of the host IP to update the mapping information.

4. The cluster container-based application upgrade method according to claim 3, characterized in that: Also includes: Compare the mapping information before and after the update to identify the pod files whose IP information has changed and the pod files whose IP information has not changed; The pod file whose IP information has changed and the pod file whose IP information has not changed are sent to the user.

5. An application upgrade device based on a cluster container, characterized in that: include: Model receiving module, which is used for the native load balancing model and target image version of the application to be upgraded; A list determination module, used to determine a pod list corresponding to the native load balancing model; The image file modification module is used to modify the image file in the pod file to the target image version according to the pod list; wherein the native load balancing model is used to distribute the load among multiple computers, network connections, CPUs, disk drives or other resources to optimize resource usage, maximize throughput, minimize response time, and avoid overload; specifically, server load balancing is divided into four-layer server load balancing and seven-layer load balancing according to the message level processed by the LB device. The four-layer processes the IP header of the IP packet and does not parse the payload above the four-layer of the message; the seven-layer processes the message payload part, and the message payload part includes HTTP, RTSP, SIP message header and message content; For the four-layer server load balancing: the client sends a request to the load balancing device at the front end of the server group, the virtual service on the load balancing device receives the client request, selects a real server through a scheduling algorithm, and then rewrites the target address of the request message with the real server address through network address translation, and then sends the request to the selected real server; when the response message of the real server passes through the load balancing device, the source address of the message is restored to the VSIP of the virtual service, and then returned to the client, completing the entire load scheduling process. Specifically, the message interaction process is as follows: (1) The host sends a service request message, with the source IP being the host IP and the destination IP being the VSIP; (2) After receiving the request message, the LB Device uses the scheduling algorithm to calculate the target server to which the request should be distributed; (3) LB Device uses DNAT technology to distribute messages, with the source IP being the host IP and the destination IP being the server IP; (4) The server receives and processes the request message and returns a response message with the source IP being the server IP and the destination IP being the host IP; (5) The LB Device receives the response message, converts the source IP, and then forwards it. The source IP is the VSIP and the destination IP is the host IP. The image file modification module includes: A file calling unit, used to call the patch API file according to the pod list; The image file modification unit is used to modify the spec.container*image file in the cluster container definition file to a target image version according to the patch api file.

6. The cluster container-based application upgrade device according to claim 5, characterized in that: The list determination module is specifically used to query the pod list corresponding to the native load balancing model in the cluster container.

7. The cluster container-based application upgrade device according to claim 5, characterized in that: Also includes: A mapping information update module, used to save the mapping information of the pod list to the host IP to update the mapping information; The mapping information comparison module is used to compare the mapping information before and after the update to determine the pod files whose IP information has changed and the pod files whose IP information has not changed; The pod file whose IP information has changed and the pod file whose IP information has not changed are sent to the user.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the cluster container-based application upgrade method according to any one of claims 1 to 4 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the cluster container-based application upgrade method described in any one of claims 1 to 4 are implemented.

Images