CN111506388B - Container performance detection method, container management platform and computer storage medium - Google Patents

Container performance detection method, container management platform and computer storage medium Download PDF

Info

Publication number
CN111506388B
CN111506388B CN202010209996.2A CN202010209996A CN111506388B CN 111506388 B CN111506388 B CN 111506388B CN 202010209996 A CN202010209996 A CN 202010209996A CN 111506388 B CN111506388 B CN 111506388B
Authority
CN
China
Prior art keywords
container
detection
detection mode
service request
target
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.)
Active
Application number
CN202010209996.2A
Other languages
Chinese (zh)
Other versions
CN111506388A (en
Inventor
赵贝
刘云冲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Juhaokan Technology Co Ltd
Original Assignee
Juhaokan Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Juhaokan Technology Co Ltd filed Critical Juhaokan Technology Co Ltd
Priority to CN202010209996.2A priority Critical patent/CN111506388B/en
Publication of CN111506388A publication Critical patent/CN111506388A/en
Application granted granted Critical
Publication of CN111506388B publication Critical patent/CN111506388B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45591Monitoring or debugging support
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815Virtual

Abstract

The application discloses a container performance detection method, a container management platform and a computer storage medium, and belongs to the technical field of Internet. In the present application, the container is probed in a first probing mode for probing whether the container is ready for a service request. If the detection result in the first detection mode is successful, continuing to determine whether the container is currently in a state of failure detection in the second detection mode, wherein the second detection mode is used for detecting whether the container is in a normal state, and if the container is currently in the state of failure detection in the second detection mode, indicating that the moment of success of the detection result in the first detection mode is a pre-restart period, at the moment, the container will not be added to the target container list, and the container will not receive a service request. Therefore, the method provided by the application can avoid the situation that the ready detection is successful and the service request is sent to the container, but the container cannot respond to the service request.

Description

Container performance detection method, container management platform and computer storage medium
Technical Field
The present disclosure relates to the field of internet technologies, and in particular, to a container performance detection method, a container management platform, and a computer storage medium.
Background
A container refers to a separate process running on a server, where one or more applications and the resources required by the one or more applications to run are deployed so that the container can execute the services provided by the one or more applications. The different containers are independent of each other so as to realize the isolation between the containers. Prior to use of the container, performance testing of the container is typically required to ensure that the container is in a healthy condition.
In the related art, the detection of a container includes two aspects: on the one hand, survival (liveness) probes and on the other hand ready (readness) probes. The survival detection refers to detecting whether the container is in a normal state or not, and if the container is not in the normal state, marking that the current detection fails. When the number of detection failures reaches the reference number, determining that the container needs to be restarted (kill) and starting timing, and restarting the container when the timing duration reaches the reference duration. The period of time from the start of the timer to the restart of the container is referred to as the pre-restart (prestop) period. Readiness to continue the probe refers to detecting whether the container is ready to receive and process a service request, and if so, allowing the container to receive the service request.
The two probing processes are separately performed in the related art, so that the container is allowed to receive the service request if the ready probe is performed and the ready probe is successful during the pre-restart period. However, if the pre-restart period ends before the container receives the service request, a condition occurs in which the ready probe is successful, but the container cannot respond to the service request, resulting in a service interruption.
Disclosure of Invention
The embodiment of the application provides a container performance detection method, a container management platform and a computer storage medium, which can avoid the situation that the container cannot respond to a service request when the container is ready to be detected successfully in a pre-restarting period, thereby causing service interruption. The technical scheme is as follows:
in one aspect, a method for detecting container performance is provided, the method comprising:
detecting a container in a first detection mode, wherein the first detection mode is used for detecting whether the container is ready for a service request, and the service request is used for requesting the container to execute a service;
if the detection result in the first detection mode is successful, determining whether the container is currently in a state of failure detection in a second detection mode, wherein the second detection mode is used for detecting whether the container is in a normal state, and the normal state refers to a state without restarting;
if the container is currently in the state of failure detection in the second detection mode, the container is not added to a target container list, and one or more containers for executing services are included in the target container list.
In a second aspect, there is provided a container management platform comprising a processing module for:
detecting a container in a first detection mode, wherein the first detection mode is used for detecting whether the container is ready for a service request, and the service request is used for requesting the container to execute a service;
if the detection result in the first detection mode is successful, determining whether the container is currently in a state of failure detection in a second detection mode, wherein the second detection mode is used for detecting whether the container is in a normal state, and the normal state refers to a state without restarting;
if the container is currently in the state of failure detection in the second detection mode, the container is not added to a target container list, and one or more containers for executing services are included in the target container list.
In a third aspect, there is provided a container management platform comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor executes executable instructions in the memory to perform any of the methods of the first aspect described above.
In a fourth aspect, there is provided a computer readable storage medium having stored thereon instructions which when executed by a processor perform the steps of any of the methods of the first aspect described above.
The beneficial effects that technical scheme that this application embodiment provided include at least:
in the present application, the container is probed in a first probing mode for probing whether the container is ready for a service request. If the detection result in the first detection mode is successful, the container is not directly added to the target container list at the moment, so that the container is forbidden to receive the service request, but whether the container is in a state of failure detection in the second detection mode currently is determined, the second detection mode is used for detecting whether the container is in a normal state, and if the container is in the state of failure detection in the second detection mode currently, the container is not added to the target container list. Thus, if the time when the detection result in the first detection mode is successful is the pre-restart period, which indicates that the container is currently in the state of failure detection in the second detection mode, the container will not be added to the target container list, and the container will not receive the service request. Therefore, the method provided by the application can avoid the situation that the ready detection is successful and the service request is sent to the container, but the container cannot respond to the service request.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram of a container performance detection system according to an embodiment of the present application;
FIG. 2 is a flow chart of a method for detecting container performance according to an embodiment of the present application;
FIG. 3 is a flow chart of another method for detecting container performance provided by an embodiment of the present application;
FIG. 4 is a schematic structural diagram of a container management platform according to an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of a server according to an embodiment of the present application.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the present invention more apparent, the embodiments of the present invention will be described in further detail with reference to the accompanying drawings.
All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present application, are intended to be within the scope of the present application based on the exemplary embodiments shown in the present application. Furthermore, while the disclosure has been presented in terms of an exemplary embodiment or embodiments, it should be understood that various aspects of the disclosure can be practiced separately from the disclosure in a complete subject matter.
It should be understood that the terms "first," "second," "third," and the like in the description and in the claims and in the above-described 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 as where appropriate, for example, implementations other than those illustrated or described in accordance with embodiments of the present application.
Furthermore, the terms "comprise" and "have," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a product or apparatus that comprises a list of elements is not necessarily limited to those elements expressly listed, but may include other elements not expressly listed or inherent to such product or apparatus.
The term "module" as used in this application refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and/or software code that is capable of performing the function associated with that element.
Before explaining the embodiments of the present application in detail, application scenarios related to the embodiments of the present application are described.
There may be multiple containers running on one server at present, so for a server cluster there will be a large number of containers running on the server cluster. As such, when an external client triggers a service request, how to forward the service request to one of the number of containers so that the container handles the service request is a matter of current concern.
Based on the above scenario, a container management platform may also be configured in these container networks, for unified management of a large number of containers running in a server cluster. Specific management includes aspects of how to forward the service request to one of the plurality of containers to cause the container to process the service request, perform performance testing on the container, and the like. For example, kubernetes, abbreviated as K8s, is a container management platform.
The container performance detection method provided by the embodiment of the application can be applied to a scene of detecting the performance of the container by K8s, and can also be applied to a scene of detecting the performance of the container by other container management platforms.
Fig. 1 is a schematic diagram of a container performance detecting system architecture according to an embodiment of the present application. As shown in fig. 1, the system 100 includes a container management platform 101, a container 102, and a client 103. Wherein the container 102 and the client 103 are connected to the container management platform 101 by a wired or wireless manner for communication.
The container management platform 101 is configured to perform performance detection on the container 103, and allow a service request triggered by the client 103 to be forwarded to the container 102 after the performance of the container 103 is detected to be normal, so that the container 102 processes the service request.
In addition, the container management platform 101 may be K8s, or may be another type of container management platform. The container may run on a physical machine, a virtual machine, or a public cloud host, which is not particularly limited in this embodiment of the present application.
Furthermore, the system of FIG. 1 is illustrated by way of example only as a single container, and the system may include a plurality of containers 101 as shown in FIG. 1, and embodiments of the present application are not limited in number.
The method for detecting the performance of the container provided by the embodiment of the application is described next.
Fig. 2 is a flowchart of a method for detecting performance of a container according to an embodiment of the present application. The method can be applied to a server, for example, to the container management platform shown in fig. 1. As shown in fig. 2, the method comprises the steps of:
step 201: the container management platform detects a container in a first detection mode, wherein the first detection mode is used for detecting whether the container is ready for a service request, and the service request is used for requesting the container to execute service.
The container management platform may perform a first detection mode of detection of the container based on the detection instructions. That is, when the container management platform detects a detection instruction for the container, the operation in step 201 is performed. Optionally, the container management platform may also periodically automatically trigger the detection of the container in the first detection mode. The embodiment of the application does not limit the scenario in which the container management platform performs the detection of the first detection mode on the container.
In one possible implementation, the container management platform may implement the detection of the container in the first detection mode based on the first detection pointer. The first detection pointer is a software module, and the container can be detected in the first detection mode through the first detection pointer.
Furthermore, to facilitate distinguishing between ready and non-ready containers, if one container is ready, that container is added to the target container list. That is, the containers in the target container list refer to containers that are allowed to receive service requests, and the target container list may also be labeled as an endpoint. Therefore, the container management platform performs the first detection mode of the container specifically refers to: it is determined whether the container is in the target container list. If not, determining that the detection result in the first detection mode is failed, and if so, determining that the detection result in the first detection mode is successful.
Step 202: if the detection result in the first detection mode is successful, the container management platform determines whether the container is currently in a state of failure detection in the second detection mode, and the second detection mode is used for detecting whether the container is in a normal state, wherein the normal state refers to a state without restarting.
In the embodiment of the application, in order to avoid the situation that the ready detection is successful, the service request is sent to the container, but the container cannot respond to the service request, if the detection result in the first detection mode is successful, the container is not directly added to the target container list at this time, so that the container is forbidden to receive the service request. But determines whether the container is currently in a state of failed detection in a second detection mode for detecting whether the container is in a normal state. It is then determined whether the container needs to be added to the target container list based on the detection result in the second detection mode.
The first detection mode is also referred to as ready detection and the second detection mode is also referred to as survival detection.
In addition, in order to facilitate quick determination of whether the container is currently in the state of failure to detect in the second detection mode, the container management platform configures the state of the container to be currently in the state of failure to detect in the second detection mode if the detection result in the second detection mode is failure every time the container is detected in the second detection mode, so as to facilitate determination of whether the container is currently in the state of failure to detect in the second detection mode in step 202.
In one possible implementation manner, after each detection of the container in the second detection mode, the container management platform may configure a status tag for the container according to the detection result, where the status tag is used to indicate whether the container is currently in a state of failure detection in the second detection mode. At this time, in step 202, the implementation manner of the container management platform in determining whether the container is currently in the state of failure detection in the second detection mode may be: and acquiring a state label of the container, and if the label value of the state label is a first label value, determining that the container is in a state of failure detection in a second detection mode currently. If the label value of the state label is the second label value, determining that the container is in a state of successful detection in the second detection mode.
The first tag value and the second tag value may be set according to requirements. For example, the first tag value may be set to 0 and the second tag value may be set to 1.
Step 203: if the container is currently in a state of failure to detect in the second detection mode, the container management platform does not add the container to a target container list that includes one or more containers ready to perform the service.
If the container is currently in the state of failure detection in the second detection mode, which indicates that the container is currently in the state of failure detection and before restarting in the second detection mode, the container is not added to the target container list at this time, and the container will not start to receive the service request, so that the situation that the container is ready to detect successfully and send the service request to the container, but the container cannot respond to the service request can be avoided.
Accordingly, if the container is currently in a state of successful detection in the second detection mode, the container is added to the target container list.
Based on step 202, the container management platform may configure a status tag for the container according to the detection result after detecting the container in the second detection mode. Thus, in one possible implementation, if the tag value of the status tag is the first tag value, then the container is not added to the target container list. And if the label value of the state label is the second label value, adding the container to the target container list.
In addition, since service requests initiated by clients are all required to be distributed to corresponding containers by the container management platform for processing. When the container management platform distributes the service request to a certain container, the destination address of the service request needs to be replaced by the address of the container to realize the distribution of the service request to the container. Therefore, before the container is added to the target container list by the container management platform, an identifier conversion rule may be configured for the container, where the identifier conversion rule is used to indicate a correspondence between an identifier of the container and an identifier of a service that can be executed by the container, so that a service request that needs to be processed by the container is sent to the container based on the correspondence. The identity transformation rule may also be an iptable rule.
The implementation manner of sending the service request to the container based on the identifier conversion rule may be: the container management platform receives a target service request, wherein the target service request carries a target service identifier; if the target service identifier is the identifier of one service in the identifier conversion rule, replacing the destination address of the target service in the target service request with the identifier of the container, and sending the processed identifier of the target service request to the container so that the container executes the service indicated by the target service identifier.
The steps 201 to 203 are further described below by taking the container management platform K8s as an example through the flowchart shown in fig. 3.
As shown in fig. 3, K8s may create a container, after which the container is created successfully, the container returns a create success message to K8s to inform K8s that the container was created successfully. During use of the container, K8s may trigger a survival probe (i.e. a probe in the second probe mode) and a readiness probe (i.e. a probe in the first probe mode) based on actual requirements. The two probes may be performed independently by the two tasks, and may or may not be performed synchronously.
And in the process of carrying out survival detection, if the detection results after a plurality of times of survival detection are all failed and the number of times of failure reaches a failure number threshold, determining that the container is required to be restarted currently, starting timing, and restarting the container after the timing time length reaches the reference time length. It should be noted that, the reason why the setting of the reference time period delays restarting the container is that: to ensure smooth stopping of the service, a pre-restart period is added before each container stops, i.e. after a command to restart the container is issued for K8s, the container can also execute the service, ensuring continuous availability of the service.
In the pre-restart period, if the detection result of the ready detection on the container is successful, at this time, whether the container is in a state of survival detection failure at present is firstly judged, and if so, the container is not added to the target container list, that is, the container is not ready for processing a server request. Accordingly, the identity transformation rule (i.e., iptables rule) is not configured for the container. External service requests are not allocated to the container at this time.
At the end of the pre-restart period, K8s will close the container, at which time external service requests will not be allocated to the container as well.
In an embodiment of the present application, the container is probed in a first probing mode, where the first probing mode is used to probe whether the container is ready for a service request. If the detection result in the first detection mode is successful, the container is not directly added to the target container list at this time, so that the container is prevented from receiving the service request, but whether the container is currently in a state of failure detection in the second detection mode is determined, the second detection mode is used for detecting whether the container is in a normal state, and if the container is currently in the state of failure detection in the second detection mode, the container is not added to the target container list. Thus, if the time when the detection result in the first detection mode is successful is the pre-restart period, which indicates that the container is currently in the state of failure detection in the second detection mode, the container will not be added to the target container list, and the container will not receive the service request. Therefore, the method provided by the embodiment of the application can avoid the situation that the readiness detection is successful and the service request is sent to the container, but the container cannot respond to the service request.
Next, a description will be given of a container management platform provided in an embodiment of the present application.
Referring to fig. 4, an embodiment of the present application provides a container management platform 400, where the container management platform 400 includes a processing module 401, and the processing module 401 is configured to:
detecting a container in a first detection mode, wherein the first detection mode is used for detecting whether the container is ready for a service request, and the service request is used for requesting the container to execute a service;
if the detection result in the first detection mode is successful, determining whether the container is currently in a state of failure detection in a second detection mode, wherein the second detection mode is used for detecting whether the container is in a normal state, and the normal state refers to a state without restarting;
if the container is currently in the state of failure to detect in the second detection mode, the container is not added to a target container list, which includes one or more containers ready to execute a service.
Optionally, the processing module is further configured to:
if the container is currently in the state of successful detection in the second detection mode, the container is added to the target container list.
Optionally, the processing module is further configured to:
configuring an identification conversion rule for the container, wherein the identification conversion rule is used for indicating the corresponding relation between the identification of the container and the identification of the service which can be executed by the container;
correspondingly, the processing module is further configured to:
receiving a target service request, wherein the target service request carries a target service identifier;
if the target service identifier is the identifier of one service in the identifier conversion rule, replacing the destination address of the target service request with the identifier of the container;
and sending the processed target service request to the container so that the container executes the service indicated by the target service identifier.
Optionally, the processing module is further configured to:
detecting the container in the second detection mode;
if the detection result in the second detection mode is failure, the state of the container is configured to be in a state of failure detection in the second detection mode.
In an embodiment of the present application, the container is probed in a first probing mode, where the first probing mode is used to probe whether the container is ready for a service request. If the detection result in the first detection mode is successful, the container is not directly added to the target container list at this time, so that the container is prevented from receiving the service request, but whether the container is currently in a state of failure detection in the second detection mode is determined, the second detection mode is used for detecting whether the container is in a normal state, and if the container is currently in the state of failure detection in the second detection mode, the container is not added to the target container list. Thus, if the time when the detection result in the first detection mode is successful is the pre-restart period, which indicates that the container is currently in the state of failure detection in the second detection mode, the container will not be added to the target container list, and the container will not receive the service request. Therefore, the method provided by the embodiment of the application can avoid the situation that the readiness detection is successful and the service request is sent to the container, but the container cannot respond to the service request.
It should be noted that: the container management platform provided in the above embodiment only illustrates the division of the above functional modules when performing performance detection on the container, and in practical application, the above functional allocation may be performed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above. In addition, the embodiments of the container management platform and the container performance detection method provided in the foregoing embodiments belong to the same concept, and specific implementation processes of the embodiments of the method are detailed in the method embodiments, which are not repeated herein.
Fig. 5 is a schematic structural diagram of a server 500 according to an embodiment of the present application. The functions of the container management platform in the above embodiment can be implemented by the server shown in fig. 5. The server may be a server in a backend server cluster. Specifically, the present invention relates to a method for manufacturing a semiconductor device.
The server 500 includes a Central Processing Unit (CPU) 501, a system memory 504 including a Random Access Memory (RAM) 502 and a Read Only Memory (ROM) 503, and a system bus 505 connecting the system memory 504 and the central processing unit 501. The server 500 also includes a basic input/output system (I/O system) 506, and a mass storage device 507 for storing an operating system 513, application programs 514, and other program modules 515, for transferring information between various devices within the computer.
The basic input/output system 506 includes a display 508 for displaying information and an input device 509, such as a mouse, keyboard, etc., for user input of information. Wherein both the display 508 and the input device 509 are coupled to the central processing unit 501 via an input output controller 510 coupled to the system bus 505. The basic input/output system 506 may also include an input/output controller 510 for receiving and processing input from a number of other devices, such as a keyboard, mouse, or electronic stylus. Similarly, the input output controller 510 also provides output to a display screen, a printer, or other type of output device.
The mass storage device 507 is connected to the central processing unit 501 through a mass storage controller (not shown) connected to the system bus 505. The mass storage device 507 and its associated computer readable media provide non-volatile storage for the server 500. That is, the mass storage device 507 may include a computer readable medium (not shown) such as a hard disk or CD-ROM drive.
Computer readable media may include computer storage media and communication media without loss of generality. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. Of course, those skilled in the art will recognize that computer storage media are not limited to the ones described above. The system memory 504 and mass storage device 507 described above may be collectively referred to as memory.
According to various embodiments of the present application, the server 500 may also operate by a remote computer connected to the network through a network, such as the Internet. I.e., server 500 may be connected to network 512 via a network interface unit 511 coupled to system bus 505, or other types of networks or remote computer systems (not shown) may be coupled to using network interface unit 511.
The memory also includes one or more programs, one or more programs stored in the memory and configured to be executed by the CPU. The one or more programs include instructions for performing the container performance detection methods provided by embodiments of the present application.
The present embodiments also provide a non-transitory computer readable storage medium, which when executed by a processor of a server, enables the server to perform the container performance detection method provided by the above embodiments.
The present embodiments also provide a computer program product containing instructions which, when run on a computer, cause the computer to perform the container performance detection method provided by the above embodiments.
It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program for instructing relevant hardware, where the program may be stored in a computer readable storage medium, and the storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.
The foregoing description of the preferred embodiments of the present invention is not intended to limit the invention, but rather, the invention is to be construed as limited to the appended claims.

Claims (8)

1. A method of detecting container performance, the method comprising:
when an external client triggers a first service request, detecting a first container in a first detection mode, wherein the first container is any container in a plurality of containers running on a server, the first detection mode is used for detecting whether the first container is ready for the first service request, and the first service request is used for requesting the first container to execute a first service;
if the detection result in the first detection mode is successful, determining whether the first container is currently in a state of failure detection in a second detection mode, wherein the second detection mode is used for detecting whether the first container is in a normal state, and the normal state refers to a state without restarting;
if the first container is currently in the state of failure detection in the second detection mode, not adding the first container to a target container list so that the first container does not receive the first service request; if the first container is currently in the state of successful detection in the second detection mode, adding the first container to the target container list so that the first container receives the first service request; the target container list includes one or more containers ready to execute a service.
2. The method of claim 1, wherein prior to adding the first container to the target container list, further comprising:
configuring an identification conversion rule for the first container, wherein the identification conversion rule is used for indicating the corresponding relation between the identification of the first container and the identification of the service which can be executed by the first container;
accordingly, after the first container is added to the target container list, the method further includes:
receiving a target service request, wherein the target service request carries a target service identifier;
if the target service identifier is the identifier of one service in the identifier conversion rule, replacing the destination address of the target service request with the identifier of the first container;
and sending the processed target service request to the first container so that the first container executes the service indicated by the target service identifier.
3. The method of claim 1, wherein the method further comprises:
detecting the first container in the second detection mode;
and if the detection result in the second detection mode is failure, configuring the state of the first container to be the state of the detection failure in the second detection mode currently.
4. A container management platform, the container management platform comprising a processing module for:
when an external client triggers a first service request, detecting a first container in a first detection mode, wherein the first container is any container in a plurality of containers running in a server, the first detection mode is used for detecting whether the first container is ready for the first service request, and the first service request is used for requesting the first container to execute a first service;
if the detection result in the first detection mode is successful, determining whether the first container is currently in a state of failure detection in a second detection mode, wherein the second detection mode is used for detecting whether the first container is in a normal state, and the normal state refers to a state without restarting;
if the first container is currently in the state of failure detection in the second detection mode, not adding the first container to a target container list so that the first container does not receive the first service request; if the first container is currently in the state of successful detection in the second detection mode, adding the first container to the target container list so that the first container receives the first service request; the target container list includes one or more containers ready to execute a service.
5. The container management platform of claim 4, wherein the processing module is further to:
configuring an identification conversion rule for the first container, wherein the identification conversion rule is used for indicating the corresponding relation between the identification of the first container and the identification of the service which can be executed by the first container;
correspondingly, the processing module is further configured to:
receiving a target service request, wherein the target service request carries a target service identifier;
if the target service identifier is the identifier of one service in the identifier conversion rule, replacing the destination address of the target service request with the identifier of the first container;
and sending the processed target service request to the first container so that the first container executes the service indicated by the target service identifier.
6. The container management platform of claim 4, wherein the processing module is further to:
detecting the first container in the second detection mode;
and if the detection result in the second detection mode is failure, configuring the state of the first container to be the state of the detection failure in the second detection mode currently.
7. A container management platform, the container management platform comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor executes executable instructions in the memory to perform the steps of the method of any of the preceding claims 1-3.
8. A computer readable storage medium having stored thereon instructions which, when executed by a processor, perform the steps of the method of any of the preceding claims 1-3.
CN202010209996.2A 2020-03-23 2020-03-23 Container performance detection method, container management platform and computer storage medium Active CN111506388B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010209996.2A CN111506388B (en) 2020-03-23 2020-03-23 Container performance detection method, container management platform and computer storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010209996.2A CN111506388B (en) 2020-03-23 2020-03-23 Container performance detection method, container management platform and computer storage medium

Publications (2)

Publication Number Publication Date
CN111506388A CN111506388A (en) 2020-08-07
CN111506388B true CN111506388B (en) 2023-04-25

Family

ID=71872625

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010209996.2A Active CN111506388B (en) 2020-03-23 2020-03-23 Container performance detection method, container management platform and computer storage medium

Country Status (1)

Country Link
CN (1) CN111506388B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112084004A (en) * 2020-09-02 2020-12-15 中国电力科学研究院有限公司 Container detection and maintenance method and system for container application
CN112165517B (en) * 2020-09-22 2022-09-20 成都知道创宇信息技术有限公司 Return source detection method and device, storage medium and electronic equipment

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110162381A (en) * 2019-04-04 2019-08-23 北京升鑫网络科技有限公司 Proxy executing method in a kind of container
CN110659106A (en) * 2019-09-12 2020-01-07 北京浪潮数据技术有限公司 Container state inspection method and device

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101860529B (en) * 2010-04-23 2012-10-31 哈尔滨工程大学 Regular detection system of P2P node survivability and method
CN109558260B (en) * 2018-11-20 2022-06-07 北京京东尚科信息技术有限公司 Kubernetes fault elimination system, method, equipment and medium
CN110532075A (en) * 2019-08-09 2019-12-03 济南浪潮数据技术有限公司 The implementation method and device of stateful load
CN110502397A (en) * 2019-08-16 2019-11-26 浪潮电子信息产业股份有限公司 A kind of processing method, device, electronic equipment and the medium of cloud platform functional module
CN110825490A (en) * 2019-10-25 2020-02-21 桂林东信云科技有限公司 Kubernetes container-based application health check method and system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110162381A (en) * 2019-04-04 2019-08-23 北京升鑫网络科技有限公司 Proxy executing method in a kind of container
CN110659106A (en) * 2019-09-12 2020-01-07 北京浪潮数据技术有限公司 Container state inspection method and device

Also Published As

Publication number Publication date
CN111506388A (en) 2020-08-07

Similar Documents

Publication Publication Date Title
CN110311831B (en) Container cloud-based system resource monitoring method and related equipment
EP3291499A1 (en) Method and apparatus for network service capacity expansion
WO2019184164A1 (en) Method for automatically deploying kubernetes worker node, device, terminal apparatus, and readable storage medium
US10846119B2 (en) Virtualized network function management apparatus, virtual machine management apparatus, method for allocating resources to virtual network function, and program
TWI344090B (en) Management of a scalable computer system
US10541862B2 (en) VNF processing policy determining method, apparatus, and system
CN110661647A (en) Life cycle management method and device
CN108874549B (en) Resource multiplexing method, device, terminal and computer readable storage medium
US9600318B2 (en) Method and system for closing application programs of an application system
CN111506388B (en) Container performance detection method, container management platform and computer storage medium
US10884880B2 (en) Method for transmitting request message and apparatus
CN113268312A (en) Application migration method and system
WO2016116013A1 (en) Software upgrade method and system
EP4006725A1 (en) Virtual machine migration processing and strategy generation method, apparatus and device, and storage medium
CN111835809B (en) Work order message distribution method, work order message distribution device, server and storage medium
US20220229689A1 (en) Virtualization platform control device, virtualization platform control method, and virtualization platform control program
CN108833532B (en) Service processing method, device and system based on Internet of things
CN108228272B (en) WEB container generation processing method, equipment and server
CN114610446A (en) Method, device and system for automatically injecting probe
JP2006228093A (en) Selection of calculation node in pc cluster computer, start of selected calculation node, and method and apparatus for distribution scheduling processing of program
CN109144788B (en) Method, device and system for reconstructing OSD
US20150134806A1 (en) Start-up control program, device, and method
US10528397B2 (en) Method, device, and non-transitory computer readable storage medium for creating virtual machine
CN117376194B (en) Network detection method, system, electronic device and computer readable storage medium
CN113965576B (en) Container-based big data acquisition method, device, storage medium and 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
GR01 Patent grant
GR01 Patent grant