CN116048618A - Probe processing method, system, electronic device and readable storage medium - Google Patents
Probe processing method, system, electronic device and readable storage medium Download PDFInfo
- Publication number
- CN116048618A CN116048618A CN202211711772.7A CN202211711772A CN116048618A CN 116048618 A CN116048618 A CN 116048618A CN 202211711772 A CN202211711772 A CN 202211711772A CN 116048618 A CN116048618 A CN 116048618A
- Authority
- CN
- China
- Prior art keywords
- probe
- container
- application
- pod
- management module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/76—Adapting program code to run in a different environment; Porting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
Abstract
The application discloses a probe processing method, a system, an electronic device and a readable storage medium, wherein the method comprises the following steps: sending a probe inspection message to an application container, wherein the application container is obtained by containerizing an application program, and the application program is provided with a probe which is used for responding after receiving the probe inspection message; the application container is positioned in the container bin Pod; determining the detection result of the probe according to the response condition of the probe; and reporting the checking result to a probe management module, wherein the probe management module is configured outside the Pod, and the probe management module is used for maintaining a probe strategy and determining the operation to be executed on the application container according to the probe strategy and the checking result. The method and the device solve the problem that normal operation of the containerized application is affected due to the fact that the container bin where the container is located is required to be rebuilt when the probe strategy is modified in the platform for managing the containerized application, and further enable the operation of the application container to be more stable.
Description
Technical Field
The present application relates to the field of software, and in particular, to a probe processing method, a system, an electronic device, and a readable storage medium.
Background
Application programs (APP, chinese, etc.) need to be supported by an operating environment such as an operating system during the running process, and in order to enable the Application to run in different environments, the Application may be containerized. A so-called container is a software package that provides a complete runtime environment for an application, and may include, for example: code for an application, related configuration files, libraries, dependencies required to run the application, and the like.
In the related art, some platforms may provide a function of containerizing an application. These platforms may be referred to as platforms for managing containerized applications. In these platforms, where a large number of containers are running, the inventors have found that problems often arise due to probe failure (e.g., resulting in improper restarting of the containers), which is often caused by improper configuration of the probe strategy, which requires rebuild of the container bin (Pod) in which the container resides, which can have an impact on the application that uses the container to provide the service.
Disclosure of Invention
The embodiment of the application provides a probe processing method, a system, electronic equipment and a readable storage medium, which are used for at least solving the problem that normal operation of a containerized application is affected due to the fact that a container bin where a container is located is required to be rebuilt when a probe strategy is modified in a platform for managing the containerized application.
According to one aspect of the present application, there is provided a probe treatment method including: sending a probe checking message to an application container, wherein the application container is obtained by containerizing an application program, the application program is provided with a probe, and the probe is used for responding after receiving the probe checking message; the application container is positioned in a container bin Pod, and at least one container is included in the Pod; determining the detection result of the probe according to the response condition of the probe; and reporting the checking result to a probe management module, wherein the probe management module is configured outside the Pod, and the probe management module is used for maintaining a probe strategy and determining the operation executed on the application container according to the probe strategy and the checking result.
According to another aspect of the present application, there is also provided a probe treatment method including: the probe management module receives a detection result of a probe, wherein the probe is configured in an application program and is used for responding after receiving a probe detection message, and the detection result is determined according to the response condition of the probe after sending the probe detection message to the probe; the application program is containerized to obtain an application container, wherein the application container is positioned in a container bin Pod, and the Pod comprises at least one container; the probe management module determines an operation performed on the application container according to a pre-configured probe policy and the inspection result, wherein the probe management module is configured outside the Pod.
According to another aspect of the present application, there is also provided a probe processing system including: the probe agent module is used for executing the method, and the probe management module is used for executing the method.
According to another aspect of the present application, there is also provided an electronic device including a memory and a processor; wherein the memory is configured to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to perform the method steps described above.
According to another aspect of the present application, there is also provided a readable storage medium having stored thereon computer instructions which when executed by a processor perform the above-mentioned method steps
In the embodiment of the application, a probe check message is sent to an application container, wherein the application container is obtained by containerizing an application program, the application program is provided with a probe, and the probe is used for responding after receiving the probe check message; the application container is positioned in a container bin Pod, and at least one container is included in the Pod; determining the detection result of the probe according to the response condition of the probe; and reporting the checking result to a probe management module, wherein the probe management module is configured outside the Pod, and the probe management module is used for maintaining a probe strategy and determining the operation executed on the application container according to the probe strategy and the checking result.
Considering that the probe configuration information in the existing platform is configured in the Pod, the configuration of the probe must be adjusted through the reconstruction of the Pod. In this step, a probe management module is introduced outside the Pod for maintaining the probe policy and obtaining an arbitration result according to the probe policy and the inspection result. Therefore, the configuration of the probe does not need to be managed any more, the configuration information of the probe can not be stored in the POD, and an arbitration result is obtained by using the probe management module, so that the maintenance of the probe strategy can be ensured to be separated from the POd, and the probe strategy can be dynamically adjusted. After the probe strategy can be dynamically adjusted, if the abnormal restarting of the application container occurs, the probe strategy can be adjusted at any time, so that the probability of the abnormal restarting of the application container again occurs is reduced. The method and the device solve the problem that normal operation of the containerized application is affected due to the fact that the container bin where the container is located is required to be rebuilt when the probe strategy is modified in the platform for managing the containerized application, and further enable the operation of the application container to be more stable.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application, illustrate and explain the application and are not to be construed as limiting the application. In the drawings:
FIG. 1 is a flow diagram of a containerized application according to the related art;
FIG. 2 is a flow chart diagram of a probe processing method according to an embodiment of the present application;
FIG. 3 is a second flowchart of a probe processing method according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a probe processing flow after joining a probe agent according to an embodiment of the present application; the method comprises the steps of,
fig. 5 is a schematic diagram of a plurality of containers configured with different probes according to an embodiment of the present application.
Detailed Description
It should be noted that, in the case of no conflict, the embodiments and features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.
It should be noted that the steps illustrated in the flowcharts of the figures may be performed in a computer system such as a set of computer executable instructions, and that although a logical order is illustrated in the flowcharts, in some cases the steps illustrated or described may be performed in an order other than that illustrated herein.
In the following embodiments, description will be given first of all of technical terms related to the following embodiments, which relate to the containerized application and a software platform for managing the containerized application.
Containerized applications
Application programs (APP, chinese, etc.) need to be supported by an operating environment such as an operating system during the running process, and in order to enable the Application to run in different environments, the Application may be containerized. A so-called container is a software package that provides a complete runtime environment for an application, and may include, for example: code for an application, related configuration files, libraries, dependencies required to run the application, and the like. Containerization is a method of application or system distribution that isolates applications or systems and their dependencies from the underlying infrastructure. It is an operating system level virtualization that allows users to deploy and run applications in a container without the need to launch an entire virtual machine for each application.
Fig. 1 is a schematic flow chart of a containerized application according to the related art, as shown in fig. 1, the flow chart includes the steps of:
and (1) writing Application (APP) codes.
Step (2) a container file (Dockerfile) is created, which contains the description of the current application, the dependencies and how the application is run. In the following embodiments, the container may be implemented by using a container (Docker) technology, or may be implemented by using a container (container) technology. It should be noted that there are various implementations in container technology, for example, the implementation may be performed by Docker or by containerd, and although translation into chinese is a container, these two technologies are different. The following embodiments are applicable to various container technologies, and the differences between the various container technologies do not affect the implementation of the following embodiments, and are not described in detail herein.
And (3) executing a build container mirror (Docker image build) command on the Dockerf file.
Step (4), pushing the Docker mirror image to a container Host (Docker Host).
Step (5), the Docker mirror image on the container host operates as a container or as a service.
Kubernetes
kubernetes is abbreviated as K8s, an abbreviation in which 8 replaces the 8 characters "ubernete" in the middle of the name. K8s is an application for managing containerization on multiple hosts in a cloud platform. In the following, some embodiments will be described with reference to K8s, but the present invention is applicable to other platforms for managing containerized applications.
Pod
A Pod (Pod) is a minimum dispatch unit of a platform (simply referred to as a platform) that manages containerized applications, in which one or more containers can be run, wherein running one container in one Pod is a common usage manner in which the Pod can be thought of as a single container enclosure. Multiple containers may also be run simultaneously in one Pod, and a Pod running simultaneously may be a container that needs to be tightly coupled to cooperate with each other, sharing resources between them. The platform may also assign each Pod a network protocol (Internet Protocol) IP address, referred to as Pod IP, with multiple containers in one Pod sharing the Pod IP address. Communication can be performed between any two Pod. The most numerous container types that are run in Pod are application containers, which are containers that will carry applications.
Node
The platform operates by placing containers in a Pod that operates on a Node (Node). A node may be a virtual machine or a physical machine, depending on the cluster configuration in which it is located. Each node contains the services required to run the Pod. In K8s, the components on the node comprise kubelet, container runtime and kube-proxy, wherein kubelet is used for managing Pod in the node and containers in the Pod, and the Pod running state on the working node is maintained; the container runtime is the software module responsible for running the container, kube-proxy is the network agent running on each node.
sidecar container
The sidecar container is a container in the Pod, the sidecar is interpreted as a sidecar, the sidecar is a seat which is added beside a two-wheeled motorcycle and is added on the basis of the third tire, and the two-wheeled motorcycle is changed into a motor tricycle through the sidecar, so that the aim of expanding functions can be fulfilled, for example, the running is more stable, and more passengers or cargoes can be pulled. The sidecar container achieves the separation of control and logic by adding a "sidecar" to the application container. For example, the sidecar container may be used to do control capabilities such as log collection, service registration, service discovery, throttling, authentication, etc. that do not require the application host service to implement. Thus, typically the sidecar container does not contain application hosting service related processes to provide specific management capabilities.
Probe with a probe tip
Probes are understood to be the means by which a program is detected as operating properly. In a platform for managing a containerized application, whether the application is running normally is a concern of a user, but if the running state of the container is simply checked, it is difficult to determine whether the application is running, because at some time, the container is not running normally on behalf of the application, and thus, a probe function is provided in some platforms, and the user can develop the probe function by himself/herself for platforms not provided with the probe function. In a platform that manages containerized applications, a user may use various types of probes that the platform provides or that are self-developing. For example, ready Probe (ready Probe): it is determined whether the container is ready and if not, the container will be in the ready state. Survival Probe (Liveness Probe): judging whether the application program in the container is normal or not, and restarting the container by the platform if the application program in the container is abnormal. Start Probe (start Probe): it is determined whether the application within the container is complete and the ready probe and the surviving probe will not execute until the start probe is successful.
Among the three probes described above, startup probe: during start-up of the container, the probe will pause the other probes during operation and restart the container when the probe detects no pass. Liveness probe: when the probe is not passed, the container is restarted. Readiness probe: working in the normal operating state of the container, when the probe detects that the probe does Not pass, the Pod will enter an Not Ready (Not Ready) state for which the platform will Not forward traffic.
Probes can be probed in a variety of ways, for example, exec: the status code returned upon command exit is determined by executing a specified command within the container, which may be referred to as an executable mode (exec) if a 0 indicates normal. For another example, the Get request is sent by way of an IP address, port, and Uniform Resource Locator (URL) path to the container, and if the status code of the response is between 200 and 399, this indicates normal. This mode is called a hypertext transfer protocol (Hyper Text Transfer Protocol, http) Get mode. For another example, by checking the IP address of the container and designating the port, a transmission control protocol (Transmission Control Protocol, abbreviated TCP) check is performed, and if the port is opened, this means that the mode is normally called a TCP Socket mode. Of course, the probe may be detected in other ways, which will not be described in detail herein.
If a plurality of containers are operated in one Pod, each container corresponds to one process, and a probe is configured in the container for detecting whether the process corresponding to the container is operated normally. The probes themselves are provided to enhance the usability of the application, provide a certain fault isolation and self-healing capability, but may cause the restarting of the container after some types of probes (Startup probe and Liveness probe) fail, and improper use easily produces unexpected results, which adversely affect stability. During Pod operation, improper restarting of many containers is caused by the presence of problems with probe configuration. The following is described by way of two examples.
In example 1, there is a dependent service in this example, where the operation of one service depends on another service, such as an application including A, B and C three services, each running in a container, a depends on B, B depends on C, and probes are configured in both a and B, and if the probe results of a and B are configured to be affected by the dependent service (i.e., C service), then when C service is unavailable, the probe results will cause a and B container to restart. In this case, the a-container and the B-container need not be restarted and only wait for the C-service to return to normal.
Example 2 the configuration parameters available for the probe may include, but are not limited to, the following:
initial delay seconds (initial delay seconds): the delay time of the first sending out of the survival probe detection request, namely how long after the container is started, the first detection operation is started, and the delay attribute is displayed; defaulting to 0 seconds, i.e., the container is detected immediately after start-up; the parameter value should be greater than the maximum initial duration of the container to avoid that the program can never be started.
Time out seconds (timeoutSeconds): the timeout duration of the surviving probe is displayed as a timeout attribute, the default value is 1 second, and the minimum value is 1 second; a reasonable value should be set for this parameter to avoid Pod restart due to response delay when the application load is large.
Cycle seconds (periodSeconds): the frequency of surviving probes, shown as period attribute, is 10 seconds by default, and 1 second by minimum; it should be noted that too high a frequency would impose a large overhead on the pod objects, while too low a frequency would make the response to the errors untimely.
Number of successes (success Threshold): in the failure state, the success of the probing operation at least for a number of consecutive times is considered to be detected, and is shown as a # success attribute, and only a value of 1 can be taken.
Number of failures (failureThreshold): in the successful state, the failure of the detection operation at least for a plurality of times is considered as the failure of the detection, and the failure is displayed as a # failure attribute, the default value is 3, and the minimum value is 1.
If the probe is too sensitive when the probe is configured, the restart may occur during the start-up process or normal operation of the application.
In the case of the above problem, the probe needs to be reconfigured, but since the probe is configured in the container, and the container is operated in the Pod, and the configuration of the probe in the Pod cannot be dynamically modified, the configuration of the probe can only be modified by reconstructing the Pod, but the reconstruction of the Pod brings risks to the application, which should be avoided as much as possible. Therefore, the user has no way to modify the probe configurations without reconstructing the Pod, which results in the probe configurations being used all the time, and thus an abnormal restart phenomenon may occur.
In view of the above situation that the application container is abnormally restarted due to the failure to dynamically modify the probe configuration, a probe processing method is provided in the following embodiment, fig. 2 is a flowchart of the probe processing method according to the embodiment of the present application, and as shown in fig. 2, the steps involved in the method in fig. 2 are described below.
Step S202, sending a probe checking message to an application container, wherein the application container is obtained by containerizing an application program, the application program is provided with a probe, and the probe is used for responding after receiving the probe checking message; the application container is located within a container Pod, which includes at least one container therein.
In this step, the platform providing the Pod will send a probe inspection message to the application container according to the configuration information of the probe, and a software module for maintaining the Pod will be configured in the platform, and this module will be referred to as a Pod management module (also referred to as a module for managing the Pod) in the following embodiment, for example, the management module is kubelet in K8 s. In the following alternative embodiments, kubelet is taken as an example, and these alternative embodiments are applicable to Pod management modules of other platforms. The probe functionality is typically provided in a platform for managing application containers, and a Pod management module may be used to send probe inspection messages for inspecting probes while the probe functionality is in use. Thus, steps S202 to S206 may be implemented by the Pod management module, so that no additional software modules (or called software components) are needed, but considering that this processing manner needs to be modified on the management module, it may affect the application scope of the following embodiments, and thus it may also be considered to add an additional software module to implement the steps in fig. 2. In short, no matter which software module the implementation subject of the steps in fig. 2 is, the solution of the technical problem is not affected.
Step S204, determining the detection result of the probe according to the response condition of the probe.
In this step, the determination of the inspection result according to the situation should be made in an existing manner, for example, if the probe does not answer within a predetermined period of time, the inspection result is regarded as failure to inspect the probe.
And step S206, reporting the inspection result to a probe management module (abbreviated as probe management), where the probe management module is configured outside the Pod (for example, the probe management module may be a software component), and the probe management module is configured to maintain a probe policy, and determine an operation performed on the application container according to the probe policy and the inspection result. The probe strategy can comprise configuration information of a probe which can be configured on a platform or combination of the configuration information of the probe, or can be a probe processing strategy which is self-formulated by a user according to the requirement of an application program. The probe strategy herein may be preconfigured to perform various operations on the container based on different probe results. The probe policy may be configured according to the probe parameters in the above example 2, for example, the failure times may be related to the above example 2, and the probe policy may be formulated as follows: if the detection result of the probe reaches the failure number, the container is restarted. Of course, other strategies may be formulated according to actual needs, and will not be described in detail herein.
Considering that the probe configuration information in the existing platform is configured in the Pod, the configuration of the probe must be adjusted through the reconstruction of the Pod. In this step, a probe management module is introduced outside the Pod for maintaining the probe policy and obtaining an arbitration result according to the probe policy and the inspection result. Therefore, the configuration of the probe does not need to be managed any more, the configuration information of the probe can not be stored in the POD, and an arbitration result is obtained by using the probe management module, so that the maintenance of the probe strategy can be ensured to be separated from the POd, and the probe strategy can be dynamically adjusted. After the probe strategy can be dynamically adjusted, if the abnormal restarting of the application container occurs, the probe strategy can be adjusted at any time, so that the probability of the abnormal restarting of the application container again occurs is reduced. Therefore, the problem that the normal operation of the containerized application is affected due to the fact that the container bin where the container is located is required to be rebuilt when the probe strategy is modified in the platform for managing the containerized application is solved through the steps, and the operation of the application container is further stable.
In the above embodiment, it has been discussed that the probe processing method shown in fig. 2 may be performed by a Pod management module, or may also be performed by a newly added software module, and in an alternative embodiment, a probe agent module (simply referred to as a probe agent) may be newly added to perform the method steps shown in fig. 2, where the probe agent module is a software component configured within the Pod.
After the probe agent module is added, the Pod management module on the original platform still sends the probe check message, and as the probe agent module also sends the probe check message, the probe check message may be repeated. To solve this problem, the Pod management module may be modified so that the Pod management module no longer transmits probe inspection messages. The scope of application of the modified Pod management module restriction scheme has been described hereinabove, and thus, in another alternative embodiment, this problem may be solved by a probe agent that receives a probe inspection message from the Pod management module through a predetermined network port, wherein the received probe inspection message is used to inspect probes configured on the application; after the predetermined network port receives the probe check message, the probe agent module sends a response message to the source of the probe check message. By this alternative embodiment, the probe inspection message is responded to by the probe agent without modifying the module in the existing platform that sent the probe inspection message.
For the probe agent module, the timing of sending the probe request message to the application container may also be determined according to the timing of sending the probe check message by the Pod management module in the platform, and in this alternative embodiment, sending the probe check message to the application container may include the following steps: the probe agent sends a probe check message to the application container after the predetermined network port receives the probe check message. In another alternative embodiment, the probe policy maintained in the probe management module may also include a manner that the probe agent module sends a probe request message to the application container, and the probe management module may send the probe request message to the probe agent module, and then the probe agent module may send the probe request message according to the manner in which the probe request message is sent in the probe policy.
In order to facilitate better communication between the probe agent module and the application container, the probe agent module may be configured in the Pod, for example, the probe agent module may be directly configured in the application container, however, such a configuration may have a risk, for example, when the application container is under a relatively high load, the processing of the probe agent module may be affected. In order to avoid the impact of the load of the application container on the probe agent module, in another alternative embodiment, the probe agent module is located in a container (e.g., may be located in a separate sidecar container), the container in which the probe agent module is located in the same Pod as the application container, and the container in which the probe agent module is located is independent of the computing resources used by the application container. In this alternative embodiment, the container in which the probe agent module is located is different from the application container, so that the influence of the load of the application container on the probe agent module is avoided.
The above alternative embodiment is described from the perspective of the probe agent module, and the following description is made from the perspective of the probe management module.
Fig. 3 is a second flowchart of a probe processing method according to an embodiment of the present application, and as shown in fig. 3, steps involved in the method in fig. 3 are described below.
Step S302, a probe management module receives a detection result of a probe, wherein the probe is configured in an application program and is used for responding after receiving a probe detection message, and the detection result is determined according to the response condition of the probe after sending the probe detection message to the probe; and the application program is containerized to obtain an application container, wherein the application container is positioned in a container bin Pod, and the Pod comprises at least one container.
In step S304, the probe management module determines an operation performed on the application container according to a pre-configured probe policy and the inspection result, where the probe management module is configured outside the Pod.
In the step, a probe management module is introduced outside the Pod and is used for maintaining the probe strategy and obtaining an arbitration result according to the probe strategy and the checking result, so that the maintenance of the probe strategy can be ensured to be separated from the Pod, and the probe strategy can be dynamically adjusted. After the probe strategy can be dynamically adjusted, if the abnormal restarting of the application container occurs, the probe strategy can be adjusted at any time, so that the probability of the abnormal restarting of the application container again occurs is reduced. In another aspect, the reason for the abnormal restart of the application container is also that the platform is default to restarting the application container for processing after the probe failure, and in fact, in some cases, the problem of probe failure can be solved without restarting the application container.
To solve this problem, in an alternative embodiment, the user may be allowed to configure the operation to be performed after the probe fails by himself, that is, the probe management module determines the operation performed on the application container according to the pre-configured probe policy and the inspection result, and may include the following steps: after the probe management module determines that the probe fails according to the probe strategy and the checking result, the probe management module executes operations performed on the probe failure, wherein the operations performed on the probe failure are preconfigured by a user. By the alternative implementation mode, not only the probe strategy can be configured, but also the operation performed after the probe fails can be configured, so that the flexibility of user configuration is improved.
As another alternative, the operation after probe failure may also employ the operation of the platform default configuration. Whether a particular user is self-configuring the application container to be operated after the probe failure may be determined based on the user-configured application container. For example, for an A application container, a default configuration operation is employed after probe failure, and for a B application container, a user configured operation is employed after probe failure.
The probe management module can also flexibly maintain the probe strategy, for example, the probe management module receives a request for maintaining the probe strategy from a user; the probe management module is used for maintaining the probe strategy according to the request, wherein the maintenance comprises at least one of the following steps: adding, modifying and deleting.
The probe strategy may also include various strategies, for example, the probe strategy includes at least one of: stopping sending probe inspection messages to the application container in the condition that the application container continuously fails for a preset time period, considering that the probe inspection is passed no matter how the inspection result is, limiting the restarting times of the application container and/or Pod caused by the failure of the probe inspection in the preset time period, and limiting the restarting number of the application container and/or Pod caused by the failure of the probe inspection in the preset time period.
The dynamic adjustment of the probe strategy can be realized through the embodiment, and the method can be applied to various platforms. The following description will take an application to K8s as an example. In the following embodiment, the probe controls are also broken down into two modules: a probe management module and a probe agent module, which are described below.
And a probe management module: an independently running component (which runs independently of the Pod in which the application container resides) is responsible for arbitrating the results of the probe according to a user-configured probe policy and triggering the probe failure process.
The probe agent module: the module may be a sidecar (sidecar) container associated with the Pod in which the application container is located. Considering that there is a module or process in the platform that needs to be checked for probes in the application container, the module may be referred to as a module or process for managing Pod or container (for short, the management module or process is kubrelet, for example in K8s, and will be described below by taking kubrelet as an example), after adding the probe agent module, the probe agent module may be used to cope with the probe check of kubrelet, for example, the probe agent module may provide a fixed http interface for the kubrelet check. In addition to providing a fixed interface for kubelet to check, the probe agent module may also check the tcp port or the http interface of the application container (i.e. check the probe configured in the application container) according to the probe operation configured by the user, and report the result to the probe management module.
The probe management module can be used for independent configuration strategies of the probes from Pod, so that the user can directly modify the probe strategies, the Pod is not required to be reconstructed by the modification, and dynamic adjustment of the probe strategies is realized.
Fig. 4 is a schematic diagram of a probe processing flow after a probe agent is added according to an embodiment of the present application, as shown in fig. 4, step 1, a user configures a probe on an application, and then proceeds to step 2, and is divided into two steps in step 2: step 2a and step 2b, in step 2a, a module (e.g. deviyment) for load balancing is created, which is also used for managing Pod. The probe is peeled off and then an application container for the application is created in the pod. Creating a sidecar container as a probe agent, injecting configuration information of the probes on the application into the probe agent, and checking the probes by the probe agent. In step 2b, the policy corresponding to the probe is synchronized to a probe management module, wherein the probe management module communicates with the probe agent outside the Pod where the application container is located. In step 3, the sidecar container provides a fixed http interface that provides a probe inspection to the module or process (e.g., kubelet) that the platform uses to maintain the pod and/or container. Step 4, the sidecar container as a probe agent initiates a probe inspection message to the application container, and after receiving the probe inspection result, the process proceeds to step 5. And 5, reporting the probe inspection result to a probe management module by the probe agent, wherein two functions of result arbitration and failure processing can be executed in the probe management module, and the result arbitration is to obtain an arbitration result according to the probe inspection result and a pre-configured strategy, wherein the arbitration result is used for indicating a processing mode corresponding to the probe inspection result. If it is determined that the probe is failed according to the probe inspection result, step 6 is entered. And 6, executing failure processing of the probe, wherein the failure processing of the probe is performed according to a pre-configured mode, and is not described in detail herein. Step 7, after the module or process (e.g., kubelet) of the platform for maintaining the pod and/or container fails to check the fixed http interface provided by the sidecar container, the Kubelet re-launches the application container.
The user can modify the probe policy by the probe management module, and the policy of the probe can be modified using steps 1 to 2b shown in fig. 4. Thus, the probe results can be interfered with. For example, the number of failures may be configured to indicate how many times the probe inspection is failed at least continuously while the inspection probe is in a successful state is considered to be failed in the inspection, the value being set to 3 at the maximum. If the number of failures is set to 3, the inspection is considered not to pass after the inspection of the probe 3 times of failures, and the probe policy is a policy executed when the inspection does not pass, and the container in which the probe is located is restarted. It was found during use of this strategy that the setting to 3 value was still small and still causes unnecessary reboots. However, in the setting of the platform, the maximum value of the parameter is 3, and there is no way to tune the value more. In this case, this can be solved by configuring a probe strategy in which the restarting of the container can be performed after receiving no two subsequent checks. It is known from the probe policy that after 3 times of failure of the inspection probe, the inspection is considered to be failed, and if two consecutive times of inspection are considered to be failed, the inspection probe has been inspected for 6 times of failure. By the mode of configuring the probe strategy, the failure times of the car detection probe can be increased, and the restarting times are controlled. Of course, the policy may also be adjusted, for example, the number of failed checks may also be adjusted to 1 or 3, and the adjustment of the policy does not require reconstruction of Pod.
In fig. 4, the module for managing the POD is a module that is originally present and is used for performing the probe inspection, and in an alternative embodiment, the probe inspection function in the module may be deleted, so that the module does not perform the probe inspection any more and does not restart the container according to the probe inspection result. So that all probe checks and restarting actions after the checks can be performed by the probe management module.
However, the deletion of the probe inspection function for managing the POD module is not easy to implement, which may cause other problems, and thus, in the above embodiment, the probe inspection function for managing the POD module is not deleted, but an additional probe (i.e., the interface in the above step 3) is provided through the sidecar container, exclusively for use in managing the POD module to inspect, so that the probe in the real application container is no longer inspected by the management POD module, and the probe in the real application container is inspected and processed by the probe management module accordingly.
In another example, a probe switch may also be configured in the probe strategy, through which the probe may be turned off. The probe can always pass the inspection no matter how the probe agent reports the result; when the probe needs to be opened, the probe is opened again. In addition to turning off the probe, when the probe failure occurs continuously in the application container, the probe may be quiesced for a period of time (the duration of this period of silence may also be configurable) to enable normal start-up.
In the above examples, a probe policy for one Pod may be shown in fig. 5, which is a schematic diagram illustrating a process of configuring different probes by using a plurality of containers according to an embodiment of the present application, as shown in fig. 5, software modules required for providing a web service may be packaged into an application container 1, software modules required for providing a database service may be packaged into an application container 2, and then the application container 1 and the application container 2 may be configured on a container platform, so that the application container 1 may provide the web service to the outside and the application container 2 may provide the database service to the outside. The application container 1 and the application container 2 can be provided with probes, and the probe management module can adopt different strategies for managing the probes in the application container 1 and the application container 2. Meanwhile, the user can also modify the probe policy of the application container 1 and the application container 2 at any time through the probe management module, which have been described in the above embodiments and are not described herein.
Of course the probe strategy may also be for multiple Pod. The probe strategy for multiple Pod is also helpful for stability of the application and platform.
For example, in the case of comparing service pressures provided by application containers in Pod (i.e. when service is under pressure), failure of probe detection may cause restart of some Pod, during which original service requests may be shared to other Pod in a period of time, thereby causing more Pod restart, and the whole process is like avalanche. Such avalanche process is more dangerous for applications in specific programming languages, such as applications written in Java, and the restarting Pod has poor performance for a period of time due to the slow start characteristic of Java, and the probe is more likely to check failure, resulting in that the whole start process is elongated or even unsuccessful. In this case, even if the Pod is expanded, the same problem is faced, because a new Pod is repeatedly restarted within a period of time, so that the service pressure cannot be timely allocated, and a relatively long time is required to solve the problem. The reason for this problem is that kubelet is resolved based on the detection result of a single probe, and this single resolution approach cannot be globally controlled, and cannot eliminate the system avalanche problem caused by many Pod restarts. After the probe management module is introduced, a probe strategy for a plurality of Pod can be configured, for example, an application is configured in the Pod to provide service, the probe strategy can limit the number of restarting times or the number of Pod restarted or the number of container restarted caused by failed probe inspection in a period of time to be within a numerical value, and in this way, the number of restarting simultaneously in a period of time can be controlled, so that avalanche of the application can be avoided.
In the alternative embodiment described above, it is also contemplated that the probe is maintained and the probe strategy is performed using kubelet through modification of kubelet, i.e., kubelet performs the function of the probe management module. However, given that modifying kubelet may be invasive to the platform, its applicability may be poor, the independent probe management module used in the alternative embodiment described above.
In the alternative embodiment, the probe agent is configured in the side car container, but may be configured in the application container, but there is a problem in the configuration in the application container that after the probe agent is embedded in the application container, the resources between the probe agent and the application container are not isolated, and when the application container loses response (for example, the CPU usage of the container reaches the upper threshold), the probe agent cannot work normally. Thus, configuring the probe agent in other containers in the Pod than the application container is a better implementation to achieve resource isolation.
Therefore, the kubelet does not need to be modified, no upgrading burden exists, and any platform and cluster for managing the containerized application can be suitable. In addition, the sidecar container is isolated from the application container in resource, and when the application container loses response, the probe agent can still work normally, so that the stability of the probe work is improved.
By the alternative embodiment, a scheme for dynamically controlling the probe is provided, which is valuable for improving service stability. And moreover, the probe control strategy is easy to expand through the independent probe management module, so that rich control strategies can be customized, and the overall stability control is realized. In addition, the failure processing module can trigger the steps designated by the user, so that the automatic workflow after the probe failure is realized.
In this embodiment, there is provided an electronic device including a memory in which a computer program is stored, and a processor configured to run the computer program to perform the method in the above embodiment.
The above-described programs may be run on a processor or may also be stored in memory (or referred to as computer-readable media), including both permanent and non-permanent, removable and non-removable media, and information storage may be implemented by any method or technique. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
These computer programs may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks and/or block diagram block or blocks, and corresponding steps may be implemented in different modules.
Such a system is provided in one embodiment. The system may be referred to as a probe handling system, comprising: the probe agent module and the probe management module in the above alternative embodiments.
Optionally, the system may further include: and the Pod management module is used for managing the Pod, and is also used for providing a preset network port for the probe agent module to send a probe check message and restarting the application container under the condition that the probe agent module does not send a response to the probe check message.
In one embodiment, an apparatus, referred to as a probe handling apparatus, may also be provided, comprising: a sending unit, configured to send a probe inspection message to an application container, where the application container is obtained by containerizing an application program, where the application program is configured with a probe, and the probe is configured to respond after receiving the probe inspection message; the application container is positioned in a container bin Pod, and at least one container is included in the Pod; a determining unit for determining the inspection result of the probe according to the response condition of the probe; and the reporting unit is used for reporting the checking result to a probe management module, wherein the probe management module is configured outside the Pod, and the probe management module is used for maintaining a probe strategy and determining the operation executed on the application container according to the probe strategy and the checking result.
Optionally, the above apparatus is implemented in a probe agent module, wherein the probe agent module is a software component configured within the Pod.
Optionally, the method further comprises: a receiving unit, configured to receive a probe inspection message through a predetermined network port, where the received probe inspection message is used to inspect a probe configured on the application program; and the second sending unit is used for sending a response message to the source side of the probe check message after the predetermined network port receives the probe check message.
Optionally, the sending unit is configured to send a probe check message to the application container after the predetermined network port receives the probe check message.
Optionally, the probe agent module is located in a container, the container in which the probe agent module is located and the application container are located in the same Pod, and the container in which the probe agent module is located and the computing resource used by the application container are independent from each other.
In one embodiment, an apparatus, referred to as a probe handling apparatus, located in a probe management module may also be provided, comprising: a second receiving unit for receiving a result of inspection of a probe, wherein the probe is configured in an application program, the probe is used for responding after receiving a probe inspection message, and the result of inspection is determined according to the response condition of the probe after sending the probe inspection message to the probe; the application program is containerized to obtain an application container, wherein the application container is positioned in a container bin Pod, and the Pod comprises at least one container; and a second determining unit, configured to determine an operation performed on the application container according to a pre-configured probe policy and the inspection result, where the probe management module is configured outside the Pod.
Optionally, the second determining unit is configured to perform an operation performed on the probe failure after determining that the probe fails according to the probe policy and the inspection result, where the operation performed on the probe failure is preconfigured by a user.
Optionally, the method further comprises: a third receiving unit, configured to receive a request for maintaining a probe policy from a user; a maintenance unit, configured to perform maintenance on the probe policy according to the request, where the maintenance includes at least one of: adding, modifying and deleting.
Optionally, the probe strategy comprises at least one of: stopping sending probe inspection messages to the application container in the condition that the application container continuously fails for a preset time period, considering that the probe inspection is passed no matter how the inspection result is, limiting the restarting times of the application container and/or Pod caused by the failure of the probe inspection in the preset time period, and limiting the restarting number of the application container and/or Pod caused by the failure of the probe inspection in the preset time period.
The system or the device is used for realizing the functions of the method in the above embodiment, and each unit in the system or the device corresponds to each step in the method, which has been described in the method, and will not be described herein.
The problem that normal operation of the containerized application is affected due to the fact that the container bin where the container is located is required to be rebuilt when the probe strategy is modified in the platform for managing the containerized application is solved through the optional implementation mode, and therefore the operation of the application container is more stable.
The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and changes may be made to the present application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims of the present application.
Claims (13)
1. A probe treatment method comprising:
sending a probe checking message to an application container, wherein the application container is obtained by containerizing an application program, the application program is provided with a probe, and the probe is used for responding after receiving the probe checking message; the application container is positioned in a container bin Pod, and at least one container is included in the Pod;
determining the detection result of the probe according to the response condition of the probe;
and reporting the checking result to a probe management module, wherein the probe management module is configured outside the Pod, and the probe management module is used for maintaining a probe strategy and determining the operation executed on the application container according to the probe strategy and the checking result.
2. The method of claim 1, wherein the probe processing method is performed by a probe agent module, wherein the probe agent module is a software component configured within the Pod.
3. The method of claim 2, further comprising:
the probe agent module receives a probe check message through a preset network port, wherein the received probe check message is used for checking probes configured on the application program;
after the predetermined network port receives the probe check message, the probe agent module sends a response message to the source of the probe check message.
4. The method of claim 3, wherein sending the probe inspection message to the application container comprises:
the probe agent sends a probe check message to the application container after the predetermined network port receives the probe check message.
5. The method of any of claims 2 to 4, wherein the probe agent module is located in a container, the container in which the probe agent module is located in the same Pod as the application container, and the container in which the probe agent module is located is independent of computing resources used by the application container.
6. A probe treatment method comprising:
the probe management module receives a detection result of a probe, wherein the probe is configured in an application program and is used for responding after receiving a probe detection message, and the detection result is determined according to the response condition of the probe after sending the probe detection message to the probe; the application program is containerized to obtain an application container, wherein the application container is positioned in a container bin Pod, and the Pod comprises at least one container;
the probe management module determines an operation performed on the application container according to a pre-configured probe policy and the inspection result, wherein the probe management module is configured outside the Pod.
7. The method of claim 6, wherein the probe management module determining the operations performed on the application container according to a pre-configured probe policy and the inspection result comprises:
after the probe management module determines that the probe fails according to the probe strategy and the checking result, the probe management module executes operations performed on the probe failure, wherein the operations performed on the probe failure are preconfigured by a user.
8. The method of claim 6, further comprising:
the probe management module receives a request for maintaining a probe strategy from a user;
the probe management module is used for maintaining the probe strategy according to the request, wherein the maintenance comprises at least one of the following steps: adding, modifying and deleting.
9. The method of any one of claims 6 to 8, the probe strategy comprising at least one of: stopping sending probe inspection messages to the application container in the condition that the application container continuously fails for a preset time period, considering that the probe inspection is passed no matter how the inspection result is, limiting the restarting times of the application container and/or Pod caused by the failure of the probe inspection in the preset time period, and limiting the restarting number of the application container and/or Pod caused by the failure of the probe inspection in the preset time period.
10. A probe handling system, comprising: a probe agent module for performing the method of any one of claims 1 to 5 and a probe management module for performing the method of any one of claims 6 to 9.
11. The system of claim 10, further comprising: and the Pod management module is used for managing the Pod, providing a preset network port for the probe agent module, sending a probe check message, and restarting the application container under the condition that the probe agent module does not send a response to the probe check message.
12. An electronic device includes a memory and a processor; wherein the memory is for storing one or more computer instructions, wherein the one or more computer instructions are executable by the processor to implement the method steps of any one of claims 1 to 5 or the method steps of any one of claims 6 to 9.
13. A readable storage medium having stored thereon computer instructions, wherein the computer instructions, when executed by a processor, implement the method steps of any of claims 1 to 5 or the method steps of any of claims 6 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211711772.7A CN116048618A (en) | 2022-12-29 | 2022-12-29 | Probe processing method, system, electronic device and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211711772.7A CN116048618A (en) | 2022-12-29 | 2022-12-29 | Probe processing method, system, electronic device and readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116048618A true CN116048618A (en) | 2023-05-02 |
Family
ID=86117600
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211711772.7A Pending CN116048618A (en) | 2022-12-29 | 2022-12-29 | Probe processing method, system, electronic device and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116048618A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117376105A (en) * | 2023-09-15 | 2024-01-09 | 珠海横琴悠租云科技有限公司 | Application diagnosis method, device, equipment and computer readable storage medium |
-
2022
- 2022-12-29 CN CN202211711772.7A patent/CN116048618A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117376105A (en) * | 2023-09-15 | 2024-01-09 | 珠海横琴悠租云科技有限公司 | Application diagnosis method, device, equipment and computer readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108551487B (en) | Application deployment method, device, server and storage medium of PaaS platform | |
| CN106817411B (en) | Service access request processing method and related equipment | |
| CN109788068B (en) | Heartbeat state information reporting method, device and equipment and computer storage medium | |
| CN109614167B (en) | Method and system for managing plug-ins | |
| CN109597631B (en) | Process upgrading method and device and electronic equipment | |
| CN113407383B (en) | Main and standby system switching method and device, server and main and standby system | |
| CN112148315A (en) | Software deployment method, device, server and storage medium | |
| CN116048618A (en) | Probe processing method, system, electronic device and readable storage medium | |
| CN110674043B (en) | Processing method and server for application debugging | |
| CN115150419A (en) | Configuration and access method and system for hybrid cloud object storage | |
| CN109939441B (en) | Application multi-disk verification processing method and system | |
| US20170270031A1 (en) | Information processing apparatus, test execution method, and computer-readable recording medium | |
| CN112564956A (en) | Remote upgrading method, equipment and device for client and storage medium | |
| CN111158872B (en) | Method and device for submitting and guarding spark task | |
| CN112698979A (en) | Method and device for processing zookeeper double nodes, storage medium and processor | |
| CN115643168B (en) | Node super-fusion upgrading method, device, equipment and storage medium | |
| CN111563009A (en) | File synchronization method, system and storage medium based on dual-computer redundancy system | |
| CN114647489A (en) | Drill method and system applied to chaotic engineering | |
| CN112685063B (en) | Feature library updating method, device, network equipment and readable storage medium | |
| CN111597021B (en) | Method, device, system and related equipment for realizing application program operation | |
| CN113938527A (en) | Extension processing method of API gateway, computing equipment and storage medium | |
| CN110266762B (en) | Data uploading method, system, device and storage medium | |
| CN111435320B (en) | Data processing method and device | |
| CN110727652B (en) | Cloud storage processing system and method for realizing data processing | |
| CN108255820B (en) | Method and device for data storage in distributed system and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |