Method, device, equipment and medium for preserving container status in Kubernetes Pod

Abstract

The present invention relates to the field of the Internet, and provides a method, device, equipment and medium for preserving the state of containers in a Pod of Kubernetes. Wherein, the method includes: when a Pod is submitted to a Kubernetes API Server, determining the Pod as a target Pod, and determining a target node, starting at least one container of the target Pod on the target node, and running the at least one container, when it is detected that a container in the at least one container exits abnormally, determining the detected container as a target container, and determining the restart strategy of the target container, when the parameter of the restart strategy of the target container is Never, obtaining the state of the sandbox container and the state of the business container in the target container, and restarting the target container according to the state of the sandbox container and the state of the business container. The present invention can determine the state of the abnormally exited container in combination with the restart strategy, and restart the container according to the container state, so that the state of the container is preserved.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, and in particular to a method, device, equipment and medium for preserving container status in a Pod of Kubernetes. Background Art

[0002] Kubernetes natively implements a workload type called statefulset, which is a stateful application. The purpose of this implementation is to manage the deployment and scaling of a set of Pods and provide persistent storage and persistent identifiers for these Pods. Each Pod in Statefulset has a persistent identifier and network ID, and the Pods are created and deleted in reverse order according to their labels.

[0003] Currently, the existing native implementation of Kubernetes cannot maintain the state of the container in the Pod. That is, when a container in the Pod exits, Kubernetes will abandon it and create a new container for the Pod to use. This means that when a container in a Pod exits, all the files in the container will be lost. When the Pod resumes running again, it will be a brand new environment created by the container image.

[0004] Therefore, in the existing Kubernetes implementation process, the containers in the Pod are one-time and stateless. The native Kubernetes implementation cannot meet the user's demand to save the container environment after the Pod recovers from an abnormality. Summary of the invention

[0005] In view of the above, it is necessary to provide a method, device, equipment and medium for preserving the state of containers in Kubernetes Pod, aiming to solve the problem that the state of containers in Kubernetes Pod cannot be preserved.

[0006] A method for preserving container status in a Pod of Kubernetes, the method comprising:

[0007] When a Pod is submitted to the Kubernetes API Server, the Pod is determined to be the target Pod, and the target node is determined;

[0008] Start at least one container of the target Pod on the target node and run the at least one container;

[0009] When it is detected that a container in the at least one container exits abnormally, the detected container is determined as a target container, and a restart strategy for the target container is determined;

[0010] When the parameter of the restart strategy of the target container is Never, obtaining the status of the sandbox container and the status of the business container in the target container;

[0011] The target container is restarted according to the state of the sandbox container and the state of the business container.

[0012] According to a preferred embodiment of the present invention, determining the target node includes:

[0013] Get the reported status of each node of the Kubernetes API Server;

[0014] Obtain the nodes in the available state from each node of the Kubernetes API Server to build a first candidate node set;

[0015] Obtain requested resources of the target Pod, and obtain available resources of each first candidate node in the first candidate node set;

[0016] Filter out nodes whose available resources are greater than the requested resources from the first candidate node set, and construct a second candidate node set;

[0017] An additional condition is obtained, and a second candidate node satisfying the additional condition is selected from the second candidate node set as the target node.

[0018] According to a preferred embodiment of the present invention, the initial state of the target Pod is a waiting state, and starting at least one container of the target Pod on the target node and running the at least one container includes:

[0019] Starting the scheduler of the Kubernetes API Server, and using the scheduler to schedule the target Pod to the target node;

[0020] Using the Kubernetes Agent on the target node to start at least one container of the target Pod;

[0021] The at least one container is run, and the state of the target Pod is updated from the waiting state to the running state.

[0022] According to a preferred embodiment of the present invention, restarting the target container according to the state of the sandbox container and the state of the business container includes:

[0023] When the state of the sandbox container is exited and the state of the business container is not exited, starting the sandbox container;

[0024] After detecting that the sandbox container has been started, restarting the business container.

[0025] According to a preferred embodiment of the present invention, restarting the target container according to the state of the sandbox container and the state of the business container further includes:

[0026] When the status of the sandbox container and the status of the business container are both exited, starting the sandbox container;

[0027] After detecting that the sandbox container has been started, the business container is started.

[0028] According to a preferred embodiment of the present invention, restarting the target container according to the state of the sandbox container and the state of the business container further includes:

[0029] When the state of the sandbox container is not exited and the state of the business container is exited, the business container is started.

[0030] According to a preferred embodiment of the present invention, the method further comprises:

[0031] When it is detected that a container in the at least one container exits normally, obtaining a restart policy of the detected container;

[0032] When the parameter of the restart policy of the detected container is Always, create a new container;

[0033] After a preset time, the detected container is deleted.

[0034] A device for preserving container status in a Pod of Kubernetes, the device for preserving container status in a Pod of Kubernetes comprising:

[0035] A determination unit, used to determine that a Pod is a target Pod and a target node when a Pod is submitted to the Kubernetes API Server;

[0036] A running unit, configured to start at least one container of the target Pod on the target node and run the at least one container;

[0037] The determining unit is further configured to, when detecting that a container in the at least one container exits abnormally, determine the detected container as a target container, and determine a restart strategy for the target container;

[0038] an acquisition unit, configured to acquire the state of the sandbox container and the state of the business container in the target container when a parameter of the restart strategy of the target container is Never;

[0039] A restart unit is used to restart the target container according to the state of the sandbox container and the state of the business container.

[0040] A computer device, comprising:

[0041] a memory storing at least one instruction; and

[0042] The processor executes the instructions stored in the memory to implement the method for preserving container state in a Pod of Kubernetes.

[0043] A computer-readable storage medium stores at least one instruction, and the at least one instruction is executed by a processor in a computer device to implement the Kubernetes Pod container state preservation method.

[0044] It can be seen from the above technical scheme that in the present invention, when a Pod is submitted to the Kubernetes API Server, the Pod is determined to be a target Pod, and the target node is determined, at least one container of the target Pod is started on the target node, and the at least one container is run. When it is detected that a container in the at least one container exits abnormally, the detected container is determined as the target container, and the restart strategy of the target container is determined. When the parameter of the restart strategy of the target container is Never, the state of the sandbox container and the state of the business container in the target container are obtained, and the target container is restarted according to the state of the sandbox container and the state of the business container. The present invention can determine the state of the abnormally exited container in combination with the restart strategy, and restart the container according to the container state, so that the state of the container is retained. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 It is a flow chart of a preferred embodiment of the method for preserving container status in a Pod of Kubernetes of the present invention.

[0046] Figure 2 It is a functional module diagram of a preferred embodiment of the device for preserving the state of a container in a Pod of Kubernetes of the present invention.

[0047] Figure 3 It is a structural schematic diagram of a computer device of a preferred embodiment of the present invention for implementing a method for preserving container status in a Pod of Kubernetes. DETAILED DESCRIPTION

[0048] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention is described in detail below with reference to the accompanying drawings and specific embodiments.

[0049] like Figure 1 As shown, it is a flow chart of a preferred embodiment of the method for preserving container status in Pod of Kubernetes of the present invention. According to different requirements, the order of the steps in the flow chart can be changed, and some steps can be omitted.

[0050] The method for preserving the container state in the Kubernetes Pod is applied to one or more computer devices, wherein the computer device is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to a microprocessor, an application specific integrated circuit (ASIC), a programmable gate array (FPGA), a digital processor (DSP), an embedded device, etc.

[0051] The computer device may be any electronic product that can perform human-computer interaction with a user, such as a personal computer, a tablet computer, a smart phone, a personal digital assistant (PDA), a game console, an interactive network television (IPTV), a smart wearable device, etc.

[0052] The computer device may also include a network device and / or a user device, wherein the network device includes, but is not limited to, a single network server, a server group consisting of multiple network servers, or a cloud consisting of a large number of hosts or network servers based on cloud computing.

[0053] The server can be an independent server 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 communications, middleware services, domain name services, security services, content delivery networks (CDN), as well as big data and artificial intelligence platforms.

[0054] Among them, Artificial Intelligence (AI) is the theory, method, technology and application system that uses digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain the best results.

[0055] AI basic technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, mechatronics, etc. AI software technologies mainly include computer vision technology, robotics technology, biometrics technology, speech processing technology, natural language processing technology, and machine learning / deep learning.

[0056] The network where the computer device is located includes but is not limited to the Internet, a wide area network, a metropolitan area network, a local area network, a virtual private network (VPN), etc.

[0057] S10, when a Pod is submitted to the Kubernetes API Server, the Pod is determined to be a target Pod, and a target node is determined.

[0058] In this embodiment, Kubernetes is a portable, extensible, and open source platform for managing containerized workloads and services, supporting declarative configuration and automation. Kubernetes has a huge and rapidly growing ecosystem that provides a wide range of services, support, and tools.

[0059] In this embodiment, the Kubernetes API Server is a Kubernetes application programming interface server used to verify and configure data for API (Application Programming Interface) objects.

[0060] In this embodiment, a Pod is the smallest deployable computing unit that can be created and managed in Kubernetes. A Pod is a group of (one or more) containers that share storage, networking, and declarations on how to run them. The contents of a Pod are always collocated and scheduled together to run in a shared context. A Pod models an application-specific "logical host" that contains one or more application containers that are relatively tightly coupled together. In a non-cloud environment, these containers run on the same physical or virtual machine, similar to cloud applications running on the same logical host.

[0061] In this embodiment, the Pod may be submitted by a user, which is not limited by the present invention.

[0062] In this embodiment, determining the target node includes:

[0063] Get the reported status of each node of the Kubernetes API Server;

[0064] Obtain the nodes in the available state from each node of the Kubernetes API Server to build a first candidate node set;

[0065] Obtain requested resources of the target Pod, and obtain available resources of each first candidate node in the first candidate node set;

[0066] Filter out nodes whose available resources are greater than the requested resources from the first candidate node set, and construct a second candidate node set;

[0067] An additional condition is obtained, and a second candidate node satisfying the additional condition is selected from the second candidate node set as the target node.

[0068] The additional conditions may include: having a preset label, etc.

[0069] Through the above implementation, the most suitable node can be selected from a large number of nodes according to the priority, so as to facilitate the execution of the task.

[0070] S11, start at least one container of the target Pod on the target node, and run the at least one container.

[0071] In this embodiment, the initial state of the target Pod is a pending state, which means that the target Pod has not met the conditions for being scheduled and is in a stage of waiting for scheduling.

[0072] Further, starting at least one container of the target Pod on the target node and running the at least one container includes:

[0073] Starting the scheduler of the Kubernetes API Server, and using the scheduler to schedule the target Pod to the target node;

[0074] Using the Kubernetes Agent on the target node to start at least one container of the target Pod;

[0075] The at least one container is run, and the state of the target Pod is updated from the waiting state to the running state.

[0076] The Kubernetes Agent is Kubelet.

[0077] After running the at least one container, the state of the target Pod is updated to a running state (Running), indicating that the target Pod is running.

[0078] S12: When it is detected that a container in the at least one container exits abnormally, the detected container is determined as a target container, and a restart policy (RestartPolicy) of the target container is determined.

[0079] In this embodiment, when a container among the at least one container exits abnormally, the exited container will enter a Failed state.

[0080] For example, if the memory exceeds the limit, the machine restarts abnormally, or it is manually killed, the container may be forced to exit abnormally.

[0081] In this embodiment, the restart strategy is a strategy that already exists in Kubernetes, and its parameters include: Never and Always.

[0082] Never means no restart, and Always means re-creating the container.

[0083] S13: When the parameter of the restart strategy of the target container is Never, the state of the sandbox container (pause) and the state of the business container in the target container are obtained.

[0084] In this embodiment, the sandbox container is a special container running in the Pod, and the other containers are the business containers.

[0085] The business container shares the network stack and volume mount of the sandbox container, making the communication and data exchange between the sandbox container and the business container more efficient.

[0086] S14: restart the target container according to the state of the sandbox container and the state of the business container.

[0087] In this embodiment, if the sandbox container has been exited, it is necessary to start the sandbox container first, and then process the business container.

[0088] Specifically, restarting the target container according to the state of the sandbox container and the state of the business container includes:

[0089] When the state of the sandbox container is exited and the state of the business container is not exited, starting the sandbox container;

[0090] After detecting that the sandbox container has been started, restarting the business container.

[0091] Furthermore, restarting the target container according to the state of the sandbox container and the state of the business container further includes:

[0092] When the status of the sandbox container and the status of the business container are both exited, starting the sandbox container;

[0093] After detecting that the sandbox container has been started, the business container is started.

[0094] Furthermore, restarting the target container according to the state of the sandbox container and the state of the business container further includes:

[0095] When the state of the sandbox container is not exited and the state of the business container is exited, the business container is started.

[0096] Through the above implementation, the abnormally exited container can be restarted according to the specific status of the sandbox container and the business container inside the container, so that the status of the Pod container can be retained.

[0097] In this embodiment, the method further includes:

[0098] When it is detected that a container in the at least one container exits normally, obtaining a restart policy of the detected container;

[0099] When the parameter of the restart policy of the detected container is Always, create a new container;

[0100] After a preset time, the detected container is deleted.

[0101] The preset duration may be customized according to actual needs or may be based on a default value, which is not limited by the present invention.

[0102] For example, when the exit error code of container A is detected to be 0, it can be determined that container A exits normally, and the corresponding state of the target Pod is updated to Succeed state. When it is further determined that the parameter of the restart strategy of container A is Always, a new container is directly created according to the spec of the target Pod, and container A is deleted after the preset time.

[0103] Through the above implementation, the startup process of the container in the Pod can be further improved.

[0104] It should be noted that the traditional solution uses Pod as the smallest granularity and cannot save the status of the container inside the Pod. The files in the container will be lost after the container exits. It can only rely on the persistent storage volume PersistenVolume to save the files that need to be persisted.

[0105] The minimum granularity in this embodiment is a container, which can save the state of the container.

[0106] It can be seen from the above technical scheme that in the present invention, when a Pod is submitted to the Kubernetes API Server, the Pod is determined to be a target Pod, and the target node is determined, at least one container of the target Pod is started on the target node, and the at least one container is run. When it is detected that a container in the at least one container exits abnormally, the detected container is determined as the target container, and the restart strategy of the target container is determined. When the parameter of the restart strategy of the target container is Never, the state of the sandbox container and the state of the business container in the target container are obtained, and the target container is restarted according to the state of the sandbox container and the state of the business container. The present invention can determine the state of the abnormally exited container in combination with the restart strategy, and restart the container according to the container state, so that the state of the container is retained.

[0107] like Figure 2 As shown, it is a functional module diagram of a preferred embodiment of the Kubernetes Pod container state retention device of the present invention. The Kubernetes Pod container state retention device 11 includes a determination unit 110, an operation unit 111, an acquisition unit 112, and a restart unit 113. The module / unit referred to in the present invention refers to a series of computer program segments that can be executed by a processor 13 and can complete fixed functions, which are stored in a memory 12. In this embodiment, the functions of each module / unit will be described in detail in subsequent embodiments.

[0108] When a Pod is submitted to the Kubernetes API Server, the determination unit 110 determines that the Pod is a target Pod and determines a target node.

[0109] In this embodiment, Kubernetes is a portable, extensible, and open source platform for managing containerized workloads and services, supporting declarative configuration and automation. Kubernetes has a huge and rapidly growing ecosystem that provides a wide range of services, support, and tools.

[0110] In this embodiment, the Kubernetes API Server is a Kubernetes application programming interface server used to verify and configure data for API (Application Programming Interface) objects.

[0111] In this embodiment, a Pod is the smallest deployable computing unit that can be created and managed in Kubernetes. A Pod is a group of (one or more) containers that share storage, networking, and declarations on how to run them. The contents of a Pod are always collocated and scheduled together to run in a shared context. A Pod models an application-specific "logical host" that contains one or more application containers that are relatively tightly coupled together. In a non-cloud environment, these containers run on the same physical or virtual machine, similar to cloud applications running on the same logical host.

[0112] In this embodiment, the Pod may be submitted by a user, which is not limited by the present invention.

[0113] In this embodiment, the determining unit 110 determines the target node including:

[0114] Get the reported status of each node of the Kubernetes API Server;

[0115] Obtain the nodes in the available state from each node of the Kubernetes API Server to build a first candidate node set;

[0116] Obtain requested resources of the target Pod, and obtain available resources of each first candidate node in the first candidate node set;

[0117] Filter out nodes whose available resources are greater than the requested resources from the first candidate node set, and construct a second candidate node set;

[0118] An additional condition is obtained, and a second candidate node satisfying the additional condition is selected from the second candidate node set as the target node.

[0119] The additional conditions may include: having a preset label, etc.

[0120] Through the above implementation, the most suitable node can be selected from a large number of nodes according to the priority, so as to facilitate the execution of the task.

[0121] The running unit 111 starts at least one container of the target Pod on the target node and runs the at least one container.

[0122] In this embodiment, the initial state of the target Pod is a pending state, which means that the target Pod has not met the conditions for being scheduled and is in a stage of waiting for scheduling.

[0123] Further, the running unit 111 starts at least one container of the target Pod on the target node, and running the at least one container includes:

[0124] Starting the scheduler of the Kubernetes API Server, and using the scheduler to schedule the target Pod to the target node;

[0125] Using the Kubernetes Agent on the target node to start at least one container of the target Pod;

[0126] The at least one container is run, and the state of the target Pod is updated from the waiting state to the running state.

[0127] The Kubernetes Agent is Kubelet.

[0128] After running the at least one container, the state of the target Pod is updated to a running state (Running), indicating that the target Pod is running.

[0129] When it is detected that a container in the at least one container exits abnormally, the determining unit 110 determines the detected container as a target container, and determines a restart policy (RestartPolicy) of the target container.

[0130] In this embodiment, when a container among the at least one container exits abnormally, the exited container will enter a Failed state.

[0131] For example, if the memory exceeds the limit, the machine restarts abnormally, or it is manually killed, the container may be forced to exit abnormally.

[0132] In this embodiment, the restart strategy is a strategy that already exists in Kubernetes, and its parameters include: Never and Always.

[0133] Never means no restart, and Always means re-creating the container.

[0134] When the parameter of the restart strategy of the target container is Never, the acquisition unit 112 acquires the state of the sandbox container (pause) and the state of the business container in the target container.

[0135] In this embodiment, the sandbox container is a special container running in the Pod, and the other containers are the business containers.

[0136] The business container shares the network stack and volume mount of the sandbox container, making the communication and data exchange between the sandbox container and the business container more efficient.

[0137] The restart unit 113 restarts the target container according to the state of the sandbox container and the state of the business container.

[0138] In this embodiment, if the sandbox container has been exited, it is necessary to start the sandbox container first, and then process the business container.

[0139] Specifically, the restarting unit 113 restarts the target container according to the state of the sandbox container and the state of the business container, including:

[0140] When the state of the sandbox container is exited and the state of the business container is not exited, starting the sandbox container;

[0141] After detecting that the sandbox container has been started, restarting the business container.

[0142] Furthermore, the restarting unit 113 restarts the target container according to the state of the sandbox container and the state of the business container, and further includes:

[0143] When the status of the sandbox container and the status of the business container are both exited, starting the sandbox container;

[0144] After detecting that the sandbox container has been started, the business container is started.

[0145] Furthermore, the restarting unit 113 restarts the target container according to the state of the sandbox container and the state of the business container and further includes:

[0146] When the state of the sandbox container is not exited and the state of the business container is exited, the business container is started.

[0147] Through the above implementation, the abnormally exited container can be restarted according to the specific status of the sandbox container and the business container inside the container, so that the status of the Pod container can be retained.

[0148] In this embodiment, when it is detected that a container in the at least one container exits normally, a restart strategy of the detected container is obtained;

[0149] When the parameter of the restart policy of the detected container is Always, create a new container;

[0150] After a preset time, the detected container is deleted.

[0151] The preset duration may be customized according to actual needs or may be based on a default value, which is not limited by the present invention.

[0152] For example, when the exit error code of container A is detected to be 0, it can be determined that container A exits normally, and the corresponding state of the target Pod is updated to Succeed state. When it is further determined that the parameter of the restart strategy of container A is Always, a new container is directly created according to the spec of the target Pod, and container A is deleted after the preset time.

[0153] Through the above implementation, the startup process of the container in the Pod can be further improved.

[0154] It should be noted that the traditional solution uses Pod as the smallest granularity and cannot save the status of the container inside the Pod. The files in the container will be lost after the container exits. It can only rely on the persistent storage volume PersistenVolume to save the files that need to be persisted.

[0155] The minimum granularity in this embodiment is a container, which can save the state of the container.

[0156] It can be seen from the above technical scheme that in the present invention, when a Pod is submitted to the Kubernetes API Server, the Pod is determined to be a target Pod, and the target node is determined, at least one container of the target Pod is started on the target node, and the at least one container is run. When it is detected that a container in the at least one container exits abnormally, the detected container is determined as the target container, and the restart strategy of the target container is determined. When the parameter of the restart strategy of the target container is Never, the state of the sandbox container and the state of the business container in the target container are obtained, and the target container is restarted according to the state of the sandbox container and the state of the business container. The present invention can determine the state of the abnormally exited container in combination with the restart strategy, and restart the container according to the container state, so that the state of the container is retained.

[0157] like Figure 3 , which is a schematic diagram of the structure of a computer device of a preferred embodiment of the method for preserving the container state in a Pod of Kubernetes implemented by the present invention.

[0158] The computer device 1 may include a memory 12, a processor 13 and a bus, and may also include a computer program stored in the memory 12 and executable on the processor 13, such as a Kubernetes Pod container state retention program.

[0159] Those skilled in the art will appreciate that the schematic diagram is merely an example of the computer device 1 and does not constitute a limitation on the computer device 1. The computer device 1 may be a bus-type structure or a star-type structure. The computer device 1 may also include more or less other hardware or software than shown in the diagram, or a different arrangement of components. For example, the computer device 1 may also include input and output devices, network access devices, etc.

[0160] It should be noted that the computer device 1 is only an example, and other existing or future electronic products that are suitable for the present invention should also be included in the protection scope of the present invention and included here by reference.

[0161] Among them, the memory 12 includes at least one type of readable storage medium, and the readable storage medium includes flash memory, mobile hard disk, multimedia card, card-type memory (for example: SD or DX memory, etc.), magnetic memory, disk, optical disk, etc. In some embodiments, the memory 12 can be an internal storage unit of the computer device 1, such as a mobile hard disk of the computer device 1. In other embodiments, the memory 12 can also be an external storage device of the computer device 1, such as a plug-in mobile hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (SecureDigital, SD) card, a flash card (Flash Card), etc. equipped on the computer device 1. Further, the memory 12 can also include both an internal storage unit of the computer device 1 and an external storage device. The memory 12 can not only be used to store application software and various types of data installed on the computer device 1, such as the code of the container state retention program in the Pod of Kubernetes, but also can be used to temporarily store data that has been output or is to be output.

[0162] In some embodiments, the processor 13 may be composed of an integrated circuit, for example, a single packaged integrated circuit, or a plurality of packaged integrated circuits with the same or different functions, including one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and combinations of various control chips. The processor 13 is the control core (Control Unit) of the computer device 1, and uses various interfaces and lines to connect the various components of the entire computer device 1, and executes or executes programs or modules stored in the memory 12 (for example, executing the Kubernetes Pod container status retention program, etc.), and calls the data stored in the memory 12 to execute various functions of the computer device 1 and process data.

[0163] The processor 13 executes the operating system of the computer device 1 and various installed applications. The processor 13 executes the application to implement the steps in the above-mentioned Kubernetes Pod container state preservation method embodiments, such as Figure 1 Steps shown.

[0164] Exemplarily, the computer program may be divided into one or more modules / units, which are stored in the memory 12 and executed by the processor 13 to complete the present invention. The one or more modules / units may be a series of computer-readable instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program in the computer device 1. For example, the computer program may be divided into a determination unit 110, an operation unit 111, an acquisition unit 112, and a restart unit 113.

[0165] The above-mentioned integrated unit implemented in the form of a software function module can be stored in a computer-readable storage medium. The above-mentioned software function module is stored in a storage medium, and includes a number of instructions for enabling a computer device (which can be a personal computer, a computer device, or a network device, etc.) or a processor to execute a portion of the method for preserving the state of a container in a Pod of Kubernetes described in various embodiments of the present invention.

[0166] If the module / unit integrated in the computer device 1 is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware devices through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by a processor, the steps of each of the above-mentioned method embodiments can be implemented.

[0167] The computer program includes computer program code, which may be in source code form, object code form, executable file or some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory, etc.

[0168] Furthermore, the computer-readable storage medium may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function, etc.; the data storage area may store data created according to the use of the blockchain node, etc.

[0169] The blockchain referred to in this invention is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0170] The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The bus is represented by only one straight line, but it does not mean that there is only one bus or one type of bus. The bus is configured to realize the connection and communication between the memory 12 and at least one processor 13, etc.

[0171] Although not shown, the computer device 1 may also include a power source (such as a battery) for supplying power to each component. Preferably, the power source may be logically connected to the at least one processor 13 through a power management device, so that the power management device can realize functions such as charging management, discharging management, and power consumption management. The power source may also include any components such as one or more DC or AC power sources, recharging devices, power failure detection circuits, power converters or inverters, power status indicators, etc. The computer device 1 may also include a variety of sensors, Bluetooth modules, Wi-Fi modules, etc., which will not be repeated here.

[0172] Furthermore, the computer device 1 may also include a network interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a WI-FI interface, a Bluetooth interface, etc.), which is usually used to establish a communication connection between the computer device 1 and other computer devices.

[0173] Optionally, the computer device 1 may further include a user interface, which may be a display, an input unit (such as a keyboard), or a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touch device. The display may also be appropriately referred to as a display screen or a display unit, which is used to display information processed in the computer device 1 and to display a visual user interface.

[0174] It should be understood that the embodiment is for illustration only and the scope of the patent application is not limited to this structure.

[0175] Figure 3 Only the computer device 1 having components 12-13 is shown, and it can be understood by those skilled in the art that Figure 3 The structure shown does not constitute a limitation on the computer device 1, and may include fewer or more components than shown in the figure, or combine certain components, or arrange the components differently.

[0176] Combination Figure 1 , the memory 12 in the computer device 1 stores a plurality of instructions to implement a method for preserving container status in a Pod of Kubernetes, and the processor 13 can execute the plurality of instructions to implement:

[0177] When a Pod is submitted to the Kubernetes API Server, the Pod is determined to be the target Pod, and the target node is determined;

[0178] Start at least one container of the target Pod on the target node and run the at least one container;

[0179] When it is detected that a container in the at least one container exits abnormally, the detected container is determined as a target container, and a restart strategy for the target container is determined;

[0180] When the parameter of the restart strategy of the target container is Never, obtaining the status of the sandbox container and the status of the business container in the target container;

[0181] The target container is restarted according to the state of the sandbox container and the state of the business container.

[0182] Specifically, the specific implementation method of the processor 13 for the above instructions can refer to Figure 1 The description of the relevant steps in the corresponding embodiments will not be repeated here.

[0183] It should be noted that the data involved in this case were all obtained legally.

[0184] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative, for example, the division of the modules is only a logical function division, and there may be other division methods in actual implementation.

[0185] The present invention can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. The present invention can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present invention can also be practiced in distributed computing environments, in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0186] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0187] In addition, each functional module in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional modules.

[0188] It is obvious to those skilled in the art that the present invention is not limited to the details of the above exemplary embodiments, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0189] Therefore, no matter from which point of view, the embodiments should be regarded as illustrative and non-restrictive, and the scope of the present invention is limited by the appended claims rather than the above description, so it is intended that all changes falling within the meaning and scope of the equivalent elements of the claims are included in the present invention. Any attached figure mark in the claims should not be regarded as limiting the claims involved.

[0190] In addition, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in the present invention can also be implemented by one unit or device through software or hardware. The words first, second, etc. are used to indicate names, and do not indicate any particular order.

[0191] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solution of the present invention can be modified or replaced by equivalents without departing from the spirit and scope of the technical solution of the present invention.

Claims

1. A method for preserving container status in a Kubernetes Pod, characterized in that: The method for preserving container status in the Kubernetes Pod includes: When a Pod is submitted to the Kubernetes API Server, the Pod is determined to be the target Pod, and the target node is determined; Start at least one container of the target Pod on the target node and run the at least one container; When it is detected that a container in the at least one container exits abnormally, the detected container is determined as a target container, and a restart strategy for the target container is determined; When the parameter of the restart strategy of the target container is Never, the state of the sandbox container and the state of the business container corresponding to the target container are obtained; wherein the business container shares the network stack and Volum mounted volume of the sandbox container; The target container is restarted according to the state of the sandbox container and the state of the business container.

2. The method for preserving container status in a Pod of Kubernetes as claimed in claim 1, characterized in that: Determining the target node includes: Get the reported status of each node of the Kubernetes API Server; Obtain the nodes in the available state from each node of the Kubernetes API Server to build a first candidate node set; Obtain requested resources of the target Pod, and obtain available resources of each first candidate node in the first candidate node set; Filter out nodes whose available resources are greater than the requested resources from the first candidate node set, and construct a second candidate node set; An additional condition is obtained, and a second candidate node satisfying the additional condition is selected from the second candidate node set as the target node.

3. The method for preserving container status in a Pod of Kubernetes as claimed in claim 1, characterized in that: The initial state of the target Pod is a waiting state, and starting at least one container of the target Pod on the target node and running the at least one container includes: Starting the scheduler of the Kubernetes API Server, and using the scheduler to schedule the target Pod to the target node; Using the Kubernetes Agent on the target node to start at least one container of the target Pod; The at least one container is run, and the state of the target Pod is updated from the waiting state to the running state.

4. The method for preserving container status in a Pod of Kubernetes as claimed in claim 1, characterized in that: The restarting of the target container according to the state of the sandbox container and the state of the business container includes: When the state of the sandbox container is exited and the state of the business container is not exited, starting the sandbox container; After detecting that the sandbox container has been started, restarting the business container.

5. The method for preserving container status in a Pod of Kubernetes as claimed in claim 1, characterized in that: The restarting of the target container according to the state of the sandbox container and the state of the business container further includes: When the status of the sandbox container and the status of the business container are both exited, starting the sandbox container; After detecting that the sandbox container has been started, the business container is started.

6. The method for preserving container status in a Pod of Kubernetes as claimed in claim 1, characterized in that: The restarting of the target container according to the state of the sandbox container and the state of the business container further includes: When the state of the sandbox container is not exited and the state of the business container is exited, the business container is started.

7. The method for preserving container status in a Pod of Kubernetes as claimed in claim 1, characterized in that: The method further comprises: When it is detected that a container in the at least one container exits normally, obtaining a restart policy of the detected container; When the parameter of the restart policy of the detected container is Always, create a new container; After a preset time, the detected container is deleted.

8. A Kubernetes Pod container status retention device, characterized in that: The Kubernetes Pod container state retention device includes: A determination unit, used to determine that a Pod is a target Pod and a target node when a Pod is submitted to the Kubernetes API Server; A running unit, configured to start at least one container of the target Pod on the target node and run the at least one container; The determining unit is further configured to, when detecting that a container in the at least one container exits abnormally, determine the detected container as a target container, and determine a restart strategy for the target container; An acquisition unit, used for acquiring the state of the sandbox container and the state of the business container corresponding to the target container when the parameter of the restart strategy of the target container is Never; wherein the business container shares the network stack and Volum mounted volume of the sandbox container; A restart unit is used to restart the target container according to the state of the sandbox container and the state of the business container.

9. A computer device, characterized in that: The computer device comprises: a memory storing at least one instruction; and A processor executes instructions stored in the memory to implement the method for preserving container status in a Pod of Kubernetes as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one instruction, and the at least one instruction is executed by a processor in a computer device to implement the method for preserving container status in a Pod of Kubernetes as described in any one of claims 1 to 7.

Images