CN117931369A

CN117931369A - Method and device for processing abnormal pod based on Kubernetes, electronic equipment and storage medium

Info

Publication number: CN117931369A
Application number: CN202410029106.8A
Authority: CN
Inventors: 王伟阳; 展波; 盛国军
Original assignee: Karos Iot Technology Co ltd; Cosmoplat Industrial Intelligent Research Institute Qingdao Co Ltd
Current assignee: Karos Iot Technology Co ltd; Cosmoplat Industrial Intelligent Research Institute Qingdao Co Ltd
Priority date: 2024-01-08
Filing date: 2024-01-08
Publication date: 2024-04-26

Abstract

The invention discloses a method and a device for processing abnormal pod based on Kubernetes, electronic equipment and a storage medium, and relates to the technical field of industrial Internet. The method comprises the following steps: acquiring state data of the pod in the target nacespace in the target time period from a pod database according to a preset time interval; wherein, the state data at least comprises restarting times and restarting time; determining at least one target pod based on the status data; determining a prompt strategy of the at least one target pod according to the state data of the at least one target pod, and prompting a user according to the prompt strategy. The method can timely find out the abnormal pod in the Kubernetes cluster, and makes a corresponding prompt strategy to prompt a user, so that the Kubernetes cluster can keep a healthy running state in the running process, the working efficiency of the Kubernetes cluster is improved, and the user experience is further improved.

Description

Method and device for processing abnormal pod based on Kubernetes, electronic equipment and storage medium

Technical Field

The invention relates to an industrial internet technology, in particular to a Kubernetes-based abnormal pod processing method, a Kubernetes-based abnormal pod processing device, electronic equipment and a storage medium.

Background

The industrial Internet is based on a network, a platform is a center, data is an element and safety is guaranteed, and the industrial Internet is an infrastructure for industrial digitization, networking and intelligent transformation, is an application mode for the deep integration of Internet, big data, artificial intelligence and entity economy, and is a new state and industry, and the enterprise morphology, the supply chain and the industry chain are remodeled. Kubernetes is an important application tool in the field of industrial internet technology, and is an open-source container cluster management system for automatically deploying, expanding and managing containerized applications. In Kubernetes clusters, many Pod's are running, carrying a lot of traffic. However, during the actual Kubernetes cluster operation, it often happens that some services are in unhealthy state. This may be due to service failures, insufficient resources, configuration errors, etc. In order to discover and handle these unhealthy services in a timely manner, technicians need to take some monitoring and management measures.

The existing processing method of the abnormal pod mostly finds out the pod with abnormal state through a manual investigation mode after the pod has abnormal state. The method can not automatically discover the abnormal pod in time, so that some services of the Kubernetes cluster are always in an unhealthy state in the running process, the working efficiency of the Kubernetes cluster is reduced, and the user experience is affected.

Disclosure of Invention

The invention provides a Kubernetes-based abnormal pod processing method, a Kubernetes-based abnormal pod processing device, electronic equipment and a storage medium, which can timely find abnormal pods in a Kubernetes cluster, and formulate a corresponding prompting strategy to prompt a user, so that the Kubernetes cluster can keep a healthy running state in the running process, the working efficiency of the Kubernetes cluster is improved, and the user experience is further improved.

In a first aspect, the present invention provides a Kubernetes-based abnormal pod processing method, the method comprising:

Acquiring state data of the pod in the target nacespace in the target time period from a pod database according to a preset time interval; wherein, the state data at least comprises restarting times and restarting time;

Determining at least one target pod based on the status data;

determining a prompt strategy of the at least one target pod according to the state data of the at least one target pod, and prompting a user according to the prompt strategy.

In a second aspect, the present invention provides an abnormal pod processing apparatus based on Kubernetes, the apparatus comprising:

The data acquisition module is used for acquiring the state data of the pod in the target nacespace in the target time period from the pod database according to the preset time interval; wherein, the state data at least comprises restarting times and restarting time;

A target determination module for determining at least one target pod based on the status data;

And the prompt module is used for determining a prompt strategy of the at least one target pod according to the state data of the at least one target pod and prompting a user according to the prompt strategy.

In a third aspect, the present invention further provides an electronic device, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, where the processor implements the Kubernetes-based abnormal pod processing method according to any one of the embodiments of the present invention when executing the program.

In a fourth aspect, the present invention also provides a computer readable storage medium, on which a computer program is stored, which when executed by a processor implements the method for processing abnormal pod based on Kubernetes according to any one of the embodiments of the present invention.

According to the invention, the state data of the pod in the target nacespace in the target time period is acquired from the pod database according to the preset time interval; wherein, the state data at least comprises restarting times and restarting time; determining at least one target pod based on the status data; determining a prompt strategy of the at least one target pod according to the state data of the at least one target pod, and prompting a user according to the prompt strategy. In the invention, abnormal pod in the Kubernetes cluster can be found in time, and a corresponding prompt strategy is formulated to prompt a user, so that the Kubernetes cluster can keep a healthy running state in the running process, the working efficiency of the Kubernetes cluster is improved, and the user experience is further improved.

Drawings

In order to more clearly illustrate the technical solutions of the present invention, the drawings that are needed in the embodiments will be briefly described below, it being understood that the following drawings only illustrate some embodiments of the present invention and should not be considered as limiting the scope, and that other related drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a first flow chart of a Kubernetes-based abnormal pod processing method according to the present invention;

FIG. 2 is a schematic diagram of a second flow of the method for processing abnormal pod based on Kubernetes according to the present invention;

FIG. 3 is a block diagram of the abnormal pod processing device based on Kubernetes provided by the invention;

Fig. 4 is a schematic structural diagram of an electronic device according to the present invention.

Detailed Description

The invention is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting thereof. It should be further noted that, for convenience of description, only some, but not all of the structures related to the present invention are shown in the drawings.

In order that those skilled in the art will better understand the present invention, a technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.

It should be noted that the terms "first," "second," and the like in the description and the claims of the present invention and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the invention described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Fig. 1 is a schematic flow chart of a Kubernetes-based abnormal pod processing method provided by the invention, which can timely find abnormal pods in a Kubernetes cluster and formulate a corresponding prompting strategy to prompt a user, so that the Kubernetes cluster can keep a healthy running state in the running process, the working efficiency of the Kubernetes cluster is improved, and the user experience is further improved. The method can be executed by the abnormal pod processing device based on the Kubernetes, and the device can be realized in a software and/or hardware mode. In a specific embodiment, the apparatus may be integrated in an electronic device, which may be a server, for example. The following embodiments will be described taking the example of the integration of the apparatus in an electronic device, and referring to fig. 1, the method may specifically include the following steps:

Step 101, acquiring the state data of the pod in the target nacespace in the target time period from the pod database according to the preset time interval.

Wherein, the status data at least comprises the restarting times and the restarting time. Namespace is a mechanism for logically grouping and isolating resource objects. It can divide different Pod into different namespaces, thereby realizing isolation and management of resources. The target naspace is the naspace that requires exception analysis of the pod it includes.

The pod database is used to store state data for all pods in Kubernetes. In this scenario, the Pod database is stored with a pre-defined WatchedPod structure, watchedPod is a data set consisting of key-value pairs whose keys are Pod names and are unique throughout WatchedPod. The value of the key value pair is the state data of the Pod corresponding to the key, including the restart times of the Pod, the time of each restart, and the like. The key value pair values are stored with a pre-defined RestartRecord structure, i.e. the number of restarts per pod running-in event per restart, etc. is recorded in RestartRecord.

In this embodiment, optionally, before acquiring the state data of the pod in the target nacespace in the target time period, the method further includes: acquiring state data of all Pod in Kuberntes at the current moment, and recording the state data of all Pod into a restarting record table; the data in the restart record table is added to the pod database in chronological order.

The restart record table in this embodiment may be RestartRecord, where status data of all pod is recorded in the restart record table. In an alternative embodiment, the server may monitor all Pod in Kuberntes in real time, and obtain the status information of the Pod through the interface of Kuberntes. When the pod is restarted, the restarting information, restarting time and other information of the pod are stored in a restarting record table. After obtaining the restarting information, extracting the restarting time of the pod in the state data, and sequentially adding the state data of the pod into a pod database one by one according to the time sequence.

In the steps, the state data of the pod can be managed according to the time sequence, and a foundation is laid for subsequently improving the exception handling efficiency of the pod.

In an alternative embodiment, the server may periodically screen the pod database for status data of pods in the target Namespace in the near future (target time period). For example, the preset time interval and the target time period are all one week, and the server obtains the state data of the pod of all target nacespace in monday to sunday of the week from the pod database at 24 times of the week. In this scheme, in order to facilitate management of data in the pod database, after acquiring state data of pods in a target nacespace in a target time period from the pod database at preset time intervals, state data of all pods in a non-target time period stored in the pod database is deleted. In this way, the server may periodically obtain the Pod restart information for subsequent statistics and judgment.

Step 102, determining at least one target pod based on the status data.

Where Pod is the smallest deployable and extensible computing unit in Kubernetes. The target pod is a pod in which an abnormality exists, such as a pod with an excessive number of restarts. In an alternative embodiment, after acquiring the status data of the pod in the target nano space, analyzing the status data of the pod, and when at least one pod with the restart number of times greater than the first preset threshold value exists in all the pods in the target nano space, determining that the at least one pod is at least one target pod.

Step 103, determining a prompt strategy of at least one target pod according to the state data of the at least one target pod, and prompting a user according to the prompt strategy.

The prompt strategy is used for indicating the server to prompt the user that the target pod has an abnormality. In an alternative embodiment, after determining the target pod, if the number of restarting times of at least one target pod is greater than the second preset threshold, determining a hint policy of at least one target pod is: closing the service; if the restart number of the at least one target pod is less than or equal to a second preset threshold, determining that the prompt policy of the at least one target pod is: the user is prompted. Determining whether at least one target pod has a corresponding controller; and if the corresponding controller exists in the at least one target pod, sending the prompt strategy to the corresponding controller of the at least one target pod, so that the controller sends the prompt strategy to the user.

According to the technical scheme, state data of the pod in the target nacespace in the target time period are obtained from a pod database according to a preset time interval; wherein, the state data at least comprises restarting times and restarting time; determining at least one target pod based on the status data; determining a prompt strategy of the at least one target pod according to the state data of the at least one target pod, and prompting a user according to the prompt strategy. According to the technical scheme, abnormal pod in the Kubernetes cluster can be found in time, and a corresponding prompt strategy is formulated to prompt a user, so that the Kubernetes cluster can keep a healthy running state in the running process, the working efficiency of the Kubernetes cluster is improved, and the user experience is further improved.

Fig. 2 is a second flow chart of the Kubernetes-based abnormal pod processing method provided by the present invention, and a specific method may be shown in fig. 2, where the method may include the following steps:

Step 201, obtain a configuration file of Kubernetes, determine types of each nacespace based on the configuration file, and determine a target nacespace based on the types of each nacespace.

The Kubernetes configuration file is a file for managing cluster access information, and contains relevant configurations required for connecting and authenticating Kubernetes clusters. In this scheme, the Kubernetes configuration file includes information such as characteristics, importance and functions of each nacespace. Different types of nasspace have different characteristics and different importance. Depending on the type of the nacespace, it may be determined which nacespace is the target nacespace.

Specifically, kubernetes is a cluster composed of multiple namespaces, but not all the pod in the namespaces need to be monitored, some of the very important namespaces themselves are always maintained by professionals, and no server is required to detect and process the anomalies. In this scheme, the types of namesapace are classified into a general type and a special type, and the special types are some special nasspace (kube-system, monitoring and logging, etc.) in Kubernetes. The pod in a particular type of nasspace does not require the server to detect and handle its anomaly. The pod in the common type of nasspace requires the server to detect and process its anomaly. Therefore, before the exception detection and processing are performed on the pod of the Kubernetes, the type of each nacespace can be determined according to the configuration file of the Kubernetes, and if the type of the nacespace is a common type, the nacespace is determined as the target nacespace.

Step 202, acquiring the state data of the pod in the target nacespace in the target time period from the pod database according to the preset time interval.

Wherein, the status data at least comprises the restarting times and the restarting time.

Step 203, when there is a pod with the number of restarting times of at least one pod being greater than the first preset threshold value in all the pods in the target nacispace, determining that the at least one pod is at least one target pod.

The first preset threshold is a value which is predetermined by the server according to the big data of the field and the like and is used for judging whether the pod has an abnormality, and when the restarting time of the pod is larger than the first preset threshold, the pod is determined as a target pod if the pod possibly has the abnormality. In this solution, the first preset threshold may be set to 80.

Step 204, if the number of restarting times of the at least one target pod is greater than the second preset threshold, determining that the hint strategy of the at least one target pod is: the service is closed.

Wherein the second preset threshold is greater than the first preset threshold. The second preset threshold is a value predetermined by the server according to the big data of the domain and the like, and is used for judging whether the pod needs to be closed or not. The target pod is a pod in which the number of restarts in the target naspace exceeds a first preset threshold. When the restart times of the target pod exceed the second preset threshold, which indicates that the pod has more serious abnormality, the prompt policy may be determined to close the pod service according to the restart times of the pod. In this solution, the second preset threshold may be set to 100. In an alternative embodiment, upon determining that the hint strategy is: after the service is turned off, the number of copies of the controller of the pod can be set to 0, thereby turning off the pod.

Step 205, if the number of restarting times of the at least one target pod is less than or equal to the second preset threshold, determining that the hint strategy of the at least one target pod is: the user is prompted.

The target pod is a pod with the restart times exceeding a first preset threshold in the target naspace. When the restart number of the target pod is less than or equal to the second preset threshold, it indicates that the pod has an abnormality, but it does not need to be closed immediately. The server may create a Kubernetes Event, an Event notification mechanism that is natively supported by Kubernetes. The user can subscribe Event through the third party application to acquire the Event happening in the Kubernetes cluster, and timely know the execution/running condition of the work/task. Further, when the restart time of the target pod is less than or equal to the second preset threshold, the server may send the information of the target pod to the third party application through the Event, so that the user may view the restart information of the pod through the third party application.

Step 206, prompting the user according to the prompting strategy.

The prompt strategy is used for indicating the server to prompt the user that the target pod has an abnormality. In this embodiment, optionally, prompting the user according to a prompting policy includes: determining whether at least one target pod has a corresponding controller; and if the corresponding controller exists in the at least one target pod, sending the prompt strategy to the corresponding controller of the at least one target pod, so that the controller sends the prompt strategy to the user.

Specifically, pod is the smallest deployable unit in Kubernetes. Pod is typically managed by a controller. The controller is a resource type provided by Kubernetes for managing creation, updating, and deletion of a set of Pod. The controller is responsible for managing the lifecycle of the Pod according to defined rules and policies, ensuring the correct operation of the application.

Kubernetes provides multiple types of controllers, each having different uses and features for meeting application requirements in different scenarios. For example, deployment controller (Deployment): for managing deployment of stateless applications. Stateful set controller (StatefulSet): for managing deployment of stateful applications. Daemon set controller (DaemonSet): ensuring that each node in the cluster runs one Pod copy is commonly used to deploy some infrastructure components such as log collectors, monitoring agents, etc. Task controller (Job): for running disposable tasks or timed tasks. Timing task controller (CronJob): for running tasks on a regular basis. Each controller has different characteristics and applicable scenes, and the proper controller type can be selected according to application requirements.

In this scheme, one controller can manage many Pod, if one Pod has an abnormality, then it is highly likely that other Pod on the controller also has an abnormality. Thus, after determining the hint strategy of the target pod, the hint strategy can be sent to the controller of the target pod, so that the controller sends the hint strategy to the user. If the target pod does not have a corresponding controller, the prompt strategy is directly sent to the pod and then sent to a third party application of the user by the server.

In the above steps, sending the event notification to the controller can implement unified processing on the whole group. When a problem occurs in a certain Pod, the controller can take corresponding measures according to event notification to ensure the usability and stability of the Kubernetes. Meanwhile, the complexity of Kubernetes management can be simplified, and the management efficiency is improved.

In this embodiment, a configuration file of Kubernetes is acquired, types of each of the namespaces are determined based on the configuration file, and a target namespace is determined based on the types of each of the namespaces. Acquiring state data of the pod in the target nacespace in the target time period from a pod database according to a preset time interval; wherein, the state data at least comprises restarting times and restarting time; and when at least one pod in all the pods in the target nasspace has the number of restarting times greater than the first preset threshold value, determining the at least one pod as at least one target pod. If the restart number of the at least one target pod is greater than the second preset threshold, determining that the prompt policy of the at least one target pod is: closing the service; if the restart number of the at least one target pod is less than or equal to a second preset threshold, determining that the prompt policy of the at least one target pod is: the user is prompted. And prompting the user according to the prompting strategy. According to the technical scheme, abnormal pod in the Kubernetes cluster can be found in time, and a corresponding prompt strategy is formulated to prompt a user, so that the Kubernetes cluster can keep a healthy running state in the running process, the working efficiency of the Kubernetes cluster is improved, and the user experience is further improved.

Fig. 3 is a block diagram of a Kubernetes-based abnormal pod processing apparatus provided by the present invention, where the apparatus is adapted to execute the Kubernetes-based abnormal pod processing method provided by the present invention. As shown in fig. 3, the apparatus may specifically include:

A data acquisition module 301, configured to acquire, from a pod database at a preset time interval, status data of a pod in a target nacespace in a target time period; wherein, the state data at least comprises restarting times and restarting time;

a target determination module 302 for determining at least one target pod based on the status data;

And the prompting module 303 is configured to determine a prompting policy of the at least one target pod according to the state data of the at least one target pod, and prompt a user according to the prompting policy.

Optionally, before acquiring the status data of the pod in the target nacespace in the target time period from the pod database at preset time intervals, the data acquiring module 301 is specifically configured to: acquiring a configuration file of the Kubernetes, and determining the type of each nacespace based on the configuration file;

The target nascent is determined based on the type of each nascent.

Optionally, before acquiring the status data of the pod in the target nacespace in the target time period from the pod database at preset time intervals, the data acquiring module 301 is further configured to: acquiring state data of all Pod in Kuberntes at the current moment, and recording the state data of all Pod into a restarting record table;

and adding the data in the restart record table to the pod database according to the time sequence.

Optionally, the target determining module 302 is specifically configured to: and when at least one pod in all pods in the target nacispace has the pod with the restarting times larger than the first preset threshold value, determining the at least one pod as the at least one target pod.

Optionally, the prompting module 303 is specifically configured to: if the restart times of the at least one target pod are greater than a second preset threshold, determining that the prompt policy of the at least one target pod is: closing the service;

If the restart times of the at least one target pod are smaller than or equal to the second preset threshold, determining that the prompt policy of the at least one target pod is: the user is prompted.

Optionally, the prompting module 303 is further configured to: determining whether the at least one target pod has a corresponding controller;

And if the at least one target pod has a corresponding controller, sending the prompt strategy to the controller corresponding to the at least one target pod, so that the controller sends the prompt strategy to the user.

Optionally, after acquiring the status data of the pod in the target nacespace in the target time period from the pod database at preset time intervals, the data acquiring module 301 is further configured to: and deleting the state data of all the pod in the non-target time period stored in the pod database.

The abnormal pod processing device based on the Kubernetes provided by the embodiment of the invention can execute the abnormal pod processing method based on the Kubernetes provided by any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method. Reference is made to the description of any method embodiment of the invention for details not described in this embodiment.

Fig. 4 is a schematic structural diagram of an electronic device according to the present invention, where, as shown in fig. 4, the electronic device 10 includes at least one processor 11, and a memory communicatively connected to the at least one processor 11, such as a read-only memory (ROM) 12, a Random Access Memory (RAM) 13, etc., where the memory stores a computer program executable by the at least one processor, and the processor 11 may perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the Random Access Memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 may also be stored. The processor 11, the ROM 12 and the RAM 13 are connected to each other via a bus 14. An input/output (I/O) interface 15 is also connected to bus 14.

Various components in the electronic device 10 are connected to the I/O interface 15, including: an input unit 16 such as a keyboard, a mouse, etc.; an output unit 17 such as various types of displays, speakers, and the like; a storage unit 18 such as a magnetic disk, an optical disk, or the like; and a communication unit 19 such as a network card, modem, wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

The processor 11 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various processors running machine learning model algorithms, digital Signal Processors (DSPs), and any suitable processor, controller, microcontroller, etc. The processor 11 performs the various methods and processes described above, such as the abnormal pod processing method based on Kubernetes.

In some embodiments, the Kubernetes-based exception pod processing method may be implemented as a computer program tangibly embodied on a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and/or installed onto the electronic device 10 via the ROM 12 and/or the communication unit 19. When a computer program is loaded into RAM 13 and executed by processor 11, one or more of the steps of the Kubernetes-based exception pod processing method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to perform the Kubernetes-based exception pod processing method in any other suitable manner (e.g., by means of firmware).

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit systems, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.

A computer program for carrying out methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the computer programs, when executed by the processor, cause the functions/acts specified in the flowchart and/or block diagram block or blocks to be implemented. The computer program may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present invention, a computer-readable storage medium may be a tangible medium that can contain, or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. The computer readable storage medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, the computer readable storage medium may be a machine readable signal medium. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) through which a user can provide input to the electronic device. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), blockchain networks, and the internet.

The computing system may include clients and servers. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also called a cloud computing server or a cloud host, and is a host product in a cloud computing service system, so that the defects of high management difficulty and weak service expansibility in the traditional physical hosts and VPS service are overcome.

It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps described in the present invention may be performed in parallel, sequentially, or in a different order, so long as the desired results of the technical solution of the present invention are achieved, and the present invention is not limited herein.

The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.

Note that the above is only a preferred embodiment of the present invention and the technical principle applied. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, while the invention has been described in connection with the above embodiments, the invention is not limited to the embodiments, but may be embodied in many other equivalent forms without departing from the spirit or scope of the invention, which is set forth in the following claims.

Claims

1. An abnormal pod processing method based on Kubernetes, which is characterized by comprising the following steps:

Determining at least one target pod based on the status data;

2. The method of claim 1, wherein prior to obtaining status data of the pod in the target nacespace within the target time period from the pod database at preset time intervals, the method further comprises:

Acquiring a configuration file of the Kubernetes, and determining the type of each nacespace based on the configuration file;

The target nascent is determined based on the type of each nascent.

3. The method of claim 1, wherein prior to obtaining status data of the pod in the target nacespace within the target time period from the pod database at preset time intervals, the method further comprises:

Acquiring state data of all Pod in Kuberntes at the current moment, and recording the state data of all Pod into a restarting record table;

4. A method according to claim 3, wherein determining at least one target pod based on the status data comprises:

And when at least one pod in all pods in the target nacispace has the pod with the restarting times larger than the first preset threshold value, determining the at least one pod as the at least one target pod.

5. The method of claim 1, wherein determining a hint policy for the at least one target pod based on the status data of the at least one target pod comprises:

if the restart times of the at least one target pod are greater than a second preset threshold, determining that the prompt policy of the at least one target pod is: closing the service;

6. The method of claim 5, wherein prompting the user according to the prompting policy comprises:

determining whether the at least one target pod has a corresponding controller;

7. The method of claim 1, wherein after acquiring status data of the pod in the target nacespace within the target time period from the pod database at preset time intervals, the method further comprises: and deleting the state data of all the pod in the non-target time period stored in the pod database.

8. An abnormal pod processing device based on Kubernetes, the device comprising:

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the Kubernetes-based exception pod processing method of any of claims 1 to 7 when the program is executed by the processor.

10. A computer-readable storage medium, on which a computer program is stored, characterized in that the program, when executed by a processor, implements the Kubernetes-based abnormal pod processing method according to any one of claims 1 to 7.