Container management method and device, computer equipment, computer readable storage medium and computer program product

Abstract

The invention relates to a container management method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: monitoring a memory use condition of a first container instance in which a target application runs; if it is detected that the memory use condition meets a preset abnormal condition, determining the number of candidate available container resources corresponding to the target application; if the quantity of the candidate available container resources meets a preset quantity condition, setting the first container instance to be in an isolated state and creating a second container instance; wherein the isolation state represents that receiving of the new service request is stopped; forwarding the historical processing data of the first container instance and the new service request for the first container instance to a second container instance, so that the second container instance processes the new service request; and deleting the first container instance. By adopting the method, the memory overflow risk of the container can be effectively processed on the basis of guaranteeing the user experience.

Description

Technical Field

[0001] This application relates to the field of container technology, and in particular to a container management method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Technology

[0002] With the widespread adoption of cloud computing and microservice architectures, containerization technology has become a core standard for modern application deployment and operation. Applications running within containers typically have memory usage limits configured to prevent a single application from consuming host node resources without restraint. Runtime crashes caused by memory exhaustion can result in instantaneous service interruptions and a degraded user experience. Handling the risk of memory overflow in containerized applications presents challenges such as passive fault response and service interruptions, which negatively impact user experience. Summary of the Invention

[0003] Therefore, it is necessary to provide a container management method, device, computer equipment, computer-readable storage medium, and computer program product that can guarantee user experience in response to the above-mentioned technical problems.

[0004] Firstly, this application provides a container management method, the method comprising:

[0005] Monitor the memory usage of the first container instance on which the target application runs;

[0006] If the memory usage is detected to meet a preset abnormal condition, the number of candidate available container resources corresponding to the target application is determined.

[0007] If the number of candidate available container resources meets a preset quantity condition, the first container instance is set to an isolated state and a second container instance is created; wherein, the isolated state indicates that new service requests are no longer received;

[0008] The historical processing data of the first container instance and the new service request for the first container instance are forwarded to the second container instance so that the second container instance can process the new service request.

[0009] Delete the first container instance.

[0010] In some embodiments, the target application has a built-in memory status detection interface; monitoring the memory usage of the first container instance in which the target application runs includes:

[0011] The memory usage of the target application is periodically detected through the memory status detection interface;

[0012] If the memory usage is detected to meet a preset abnormal condition, the number of candidate available container resources corresponding to the target application is determined, including:

[0013] The memory status detection interface compares the amount of memory used with the pre-configured amount of memory for the target application to determine whether the memory usage indicates the preset abnormal condition.

[0014] If the memory usage indicates the preset abnormal condition, the response status code of the memory status detection interface is modified from the first status code indicating normal to the second status code indicating that it can be isolated through the memory status detection interface.

[0015] The memory status detection interface is periodically called to obtain the response status code. If the number of times the response status code is the second status code meets a preset threshold, it is determined that the memory usage of the first container instance meets the preset abnormal condition.

[0016] In some embodiments, determining the number of candidate available container resources corresponding to the target application if the memory usage is detected to meet a preset abnormal condition includes:

[0017] Query the network address of the first container instance to obtain the identity identifier of the first container instance;

[0018] The application instance group to which the target application belongs is determined based on the identity of the first container instance;

[0019] Count the total number of container instances that are currently in a serviceable state in the application instance group;

[0020] The number of candidate available container resources is determined based on the total number of container instances and the number of the first container instances.

[0021] In some embodiments, the preset quantity condition includes the number of candidate available container instances being greater than or equal to 1; the step of setting the first container instance to an isolated state and creating a second container instance if the number of candidate available container resources meets the preset quantity condition includes:

[0022] If the number of available container instances meets a preset quantity condition, modify the tag information of the first container instance so that the first container instance is removed from the container control of the application instance group;

[0023] The second container instance is created based on the expected number of instances in the application instance group.

[0024] In some embodiments, after setting the first container instance to an isolated state and creating a second container instance based on the available container instances if the number of available container instances meets a preset quantity condition, the method includes:

[0025] Perform a memory dump operation on the target application;

[0026] In response to the completion of the memory dump operation, the target application modifies the response status code of the memory status detection interface from the second status code to the third status code indicating the completion of the memory dump.

[0027] Deleting the first container instance includes:

[0028] Periodically query the response status code of the memory status detection interface;

[0029] If the response status code is detected to change from the second status code to the third status code, delete the first container instance;

[0030] And / or, if the response status code is detected to have not changed to the third status code within a preset time period, the first container instance is deleted.

[0031] In some embodiments, the method is based on a pre-configured script, which is loaded into the system corresponding to the first container instance by mounting a storage volume when the first container instance starts.

[0032] The preset duration is less than the termination grace time corresponding to the first container instance; the termination grace time is used to define the maximum waiting interval between initiating the request to delete the first container instance and the termination of the first container instance.

[0033] Secondly, this application also provides a container management device, the device comprising:

[0034] The monitoring module is used to monitor the memory usage of the first container instance on which the target application runs;

[0035] The determination module is used to determine the number of candidate available container resources corresponding to the target application if the memory usage is detected to meet a preset abnormal condition;

[0036] The configuration module is used to set the first container instance to an isolated state and create a second container instance if the number of candidate available container resources meets a preset quantity condition; wherein, the isolated state indicates that new service requests are no longer received;

[0037] The forwarding module is used to forward the historical processing data of the first container instance and the new service request for the first container instance to the second container instance, so that the second container instance can process the new service request.

[0038] The delete module is used to delete the first container instance.

[0039] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0040] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0041] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0042] The aforementioned container management methods, devices, computer equipment, computer-readable storage media, and computer program products proactively warn and intervene in memory overflow risks by monitoring memory usage and triggering processes when preset abnormal conditions are met, transforming fault handling from passive response to proactive prevention. Secondly, by only performing isolation and creating new instances when preset conditions are met, it ensures that at least one available instance is always available to handle traffic during instance replacement, thus achieving smooth hot replacement without user awareness and completely avoiding service interruptions. Utilizing the characteristic that the isolated state allows the old instance to continue running before deletion provides a time window for operations such as memory dumping, enabling container management of insufficient memory without the user's awareness. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a diagram illustrating the application environment of a container management method in one embodiment;

[0045] Figure 2 This is a flowchart illustrating a container management method in one embodiment;

[0046] Figure 3 This is a structural block diagram of a container management device in one embodiment;

[0047] Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0049] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0050] Explanation of related terms:

[0051] Containers: A lightweight, portable, and self-contained software packaging technology that packages an application and all its dependencies (such as code, runtime, system tools, libraries, configuration files, etc.) together to ensure that the application runs consistently in any container-enabled environment.

[0052] Kubernetes: An open-source container orchestration system for automating the deployment, scaling, and management of containerized applications.

[0053] Deployment: Abbreviated as Deploy, it is a controller object used to declaratively manage Pods and their lifecycle.

[0054] Pod: The smallest deployable compute unit in Kubernetes. A Pod represents one (or more) tightly coupled container instances running in a Kubernetes cluster.

[0055] Node: A physical or virtual machine in a Kubernetes cluster used to run workloads (Pods). It is the unit of work in a Kubernetes cluster, and all containerized applications ultimately run on a Node.

[0056] Kubelet is a core node-level agent component in a Kubernetes cluster. It runs on each worker node and is responsible for managing the lifecycle of Pods and containers on that node.

[0057] Prestop: In Kubernetes, it is used to perform custom operations before a container is terminated.

[0058] YAML is a data serialization standard, particularly suitable for scenarios such as configuration files and data description files.

[0059] API: A software-to-software interface that enables developers to build applications that can interoperate with each other.

[0060] REST API: Based on the HTTP protocol, it uses stateless, Uniform Resource Identifiers (URIs) and standard HTTP methods to manipulate resources. It is also one of the most popular API design styles today.

[0061] Shell scripts are script files written in the Shell programming language used to automate the execution of a series of commands. They are widely used in Linux, macOS, and Unix-like systems for system administration, task scheduling, software deployment, and other scenarios.

[0062] Before describing the embodiments of the present invention, the related technologies and their existing problems will be further explained:

[0063] For memory-sensitive applications (such as services written in languages ​​like Java and Go), under specific workloads, memory usage may gradually increase until it reaches the configured limit, eventually triggering a memory overflow error and causing the process to be forcibly terminated by the operating system. This runtime crash caused by memory exhaustion results in instantaneous service interruption, impaired user experience, and after the container is restarted or cleaned up, critical diagnostic information such as the memory state at the time of the failure is lost, making it difficult to trace the root cause of the problem.

[0064] Mechanisms to address this type of memory overflow risk can include relying on the basic monitoring and restart mechanisms of the container orchestration platform, integrating health checks into the application, and configuring liveness probes externally. Specifically, the platform automatically restarts the container when it detects that memory usage exceeds limits or the process crashes. However, this approach has significant drawbacks: First, the failure is sudden, lacking warning between near memory exhaustion and process crash, making preventative measures impossible; second, service interruption is unavoidable, the restart process causes all requests being processed by the instance to fail, and the startup of a new instance takes time, resulting in decreased service availability; finally, the failure scenario cannot be preserved, the crashed container and its internal state are directly erased, and operations personnel lack firsthand data for analyzing memory leaks or performance bottlenecks.

[0065] When an application malfunctions due to memory issues, a failed health check triggers a container restart. However, this approach doesn't solve the interruption problem; it merely implements automatic restart, and the service remains unavailable during the restart process. Furthermore, it lacks global resource-level decision-making, potentially leading to a situation where, under extreme cluster resource pressure, an instance is recklessly terminated without the ability to immediately schedule a new instance, resulting in a completely unavailable service.

[0066] Therefore, when dealing with the risk of memory overflow in containerized applications, related technologies suffer from problems such as passive fault response, obvious service interruption, loss of fault information, and lack of intelligent isolation decision-making under the premise of ensuring service continuity.

[0067] The container management method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. Server 104 monitors the memory usage of a first container instance on which the target application on terminal 102 runs; if the memory usage meets a preset abnormal condition, server 104 determines the number of candidate available container resources corresponding to the target application; if the number of candidate available container resources meets a preset quantity condition, server 104 sets the first container instance to an isolated state and creates a second container instance; wherein, the isolated state indicates that new service requests are no longer received; the historical processing data of the first container instance and the new service request for the first container instance are forwarded to the second container instance so that the second container instance can process the new service request; server 104 deletes the first container instance. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0068] In one exemplary embodiment, such as Figure 2 As shown, a container management method is provided, which can be applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0069] Step 202: Monitor the memory usage of the first container instance on which the target application is running.

[0070] The target application refers to the business logic program running in a container environment. Specifically, the target application can include the following: Java Virtual Machine (JVM) applications, such as web services developed using the Spring Boot framework. JVM applications configure maximum heap memory at startup using the -Xmx parameter, so the memory usage of such applications can be characterized by heap memory occupancy. Backend services written in Go can obtain real-time memory allocation statistics at runtime through interfaces such as runtime.MemStats.

[0071] A container instance refers to the smallest scheduling unit in a container orchestration system (such as Kubernetes) that hosts the execution of an application; it is essentially a Pod. A target application can be deployed as multiple replicas, meaning it runs on multiple independent and identical container instances to achieve load balancing and high availability. For example, a Java application named order-service can have its Kubernetes Deployment configured with replicas: 3. This means that at any given time, three independent container instances are running the order-service application simultaneously, collectively processing user order requests.

[0072] Memory usage refers to the proportion or absolute value of the memory resources used by a target application during runtime relative to its preset limit. Specifically, memory usage can include memory utilization rate, which can be calculated as: (Currently used memory / Configured maximum memory limit) * 100%. Memory usage can reflect the urgency with which an application is at risk of triggering an Out Of Memory (OOM) error.

[0073] In this context, container orchestration systems monitor the overall resource usage of the container, making it difficult to precisely differentiate the usage of different memory regions within an application, such as heap memory, stack memory, and direct memory. The target application itself can call dedicated interfaces of its runtime (e.g., JVM, Go Runtime) to obtain the most accurate and granular memory usage data, especially heap memory usage, which is most sensitive to OutOfMemoryError (OOM) risks, thus enabling earlier and more accurate warnings. Furthermore, external monitoring systems typically have limited data collection cycles (e.g., 30 seconds) and data processing latency. In scenarios with rapid memory growth, external monitoring may fail to capture risks in the very short time before an OOM occurs. Monitoring by the application itself at a higher frequency (e.g., per second) can minimize the latency of risk perception, buying valuable time for subsequent handling processes. Moreover, the judgment of abnormal memory states (e.g., whether 95% has been reached) depends on the application's own configured memory limits (e.g., JVM's -Xmx). Having the application perform the calculations and judgments itself avoids the complexity and coupling caused by exposing internal configuration information to external systems, making the monitoring logic more cohesive and self-contained.

[0074] Therefore, in this embodiment of the invention, memory monitoring is performed by the target application itself, rather than relying entirely on basic resource monitoring provided by a container orchestration system (such as Kubernetes). By detecting memory usage by the target application itself, proactive and real-time awareness of memory risks is achieved, providing raw data for preventative intervention. Specifically, a lightweight memory monitoring thread or periodic task can be integrated into the target application. This monitoring logic performs the following operations at fixed intervals (e.g., per second):

[0075] First, the memory query interface provided by the application runtime environment is called. For Java applications, HeapMemoryUsage and NonHeapMemoryUsage can be obtained through java.lang.management.MemoryMXBean; for Go applications, the runtime.ReadMemStats function can be called.

[0076] The current memory usage (such as heap memory usage used) is then compared with the maximum memory limit configured when the application starts (such as the JVM's -Xmx value or the container's memory resource limit limits.memory) to calculate the real-time memory usage rate.

[0077] Finally, the calculated memory usage is compared with a pre-set first threshold. This first threshold can be configured as a high percentage, such as 95%. When the memory usage reaches the first threshold, the application can still run normally, but it is in a critical risk state where it is highly likely to trigger an OutOfMemoryError (OOM) due to subsequent minor memory allocation failures. By setting a first threshold, a window of time can be gained to proactively address the issue before a crash occurs. For example, for a Java service configured with a maximum heap memory of 2 GiB, its built-in monitoring thread finds that the current heap memory usage has reached 1.9 GiB, which is a memory usage of 96%, greater than the first threshold of 95%. Therefore, it meets the preset exception condition, indicating that the instance has entered a state where it may be interrupted due to insufficient memory.

[0078] Step 204: If the memory usage is detected to meet the preset abnormal conditions, determine the number of candidate available container resources corresponding to the target application.

[0079] The number of candidate available container resources refers to the number of other container instances running the same target application as the first container instance at the current moment, and whose current state is determined by the container orchestration system to be healthy and capable of receiving traffic (e.g., a Pod in Kubernetes is in the Running and Ready state). The number of candidate available container resources represents the scale of standby instances in the service cluster that can immediately take over the workload if the current first container instance becomes unavailable.

[0080] Specifically, the number of candidate available container resources can be determined using a proxy service or management script with cluster query permissions. The determination process is as follows: Obtain the identification information of the first container instance, typically its Pod IP address or Pod name. Based on this identification, query the container orchestration system's API to determine the application instance group (in Kubernetes, this is its Deployment or StatefulSet) to which the first container instance belongs. Query all container instances managed under this application instance group, filter out instances with a status of "serviceable," and count their total number. Subtract the number of the first container instance from the total number of serviceable instances to obtain the number of candidate available container resources.

[0081] For example, suppose there is a Deployment named `payment-gateway` configured with 3 replicas. Assume that the 3 Pods (named pod-a, pod-b, and pod-c) are currently in the Ready state. When pod-a detects abnormal memory usage, the system queries and finds that the `payment-gateway` application currently has 3 Ready Pods. Therefore, for pod-a, the number of candidate available container resources = 3 (total) - 1 (its own) = 2. Thus, even if pod-a is isolated, pod-b and pod-c still have two instances that can continue to handle all requests.

[0082] This allows for an assessment of the entire service cluster's redundant resources to perform hot swapping without interrupting services before deciding to isolate container instances with memory risks (such as the first container instance). As a result, the management of container instances is externally transparent, ensuring a smooth user experience.

[0083] Step 206: If the number of candidate available container resources meets the preset quantity condition, set the first container instance to an isolated state and create a second container instance; wherein, the isolated state indicates that new service requests are no longer received.

[0084] The preset quantity condition is used to characterize whether the current service cluster has the redundancy processing capability to maintain uninterrupted service after isolating problematic instances. Specifically, this condition can be defined as the number of candidate available container resources being greater than or equal to 1.

[0085] Considering that isolating the first container instance with memory risks must be done while ensuring that the overall processing capacity of the service does not decrease, it is necessary to create new instances while isolating the old ones. However, the successful execution of creating new instances depends on whether the container orchestration cluster has sufficient idle resources (CPU, memory). In extreme scenarios where cluster resources are saturated, new instances may not be able to be scheduled and started immediately.

[0086] Therefore, by setting the preset quantity condition (>1) to establish a security decision valve, if the condition is met (candidate quantity ≥ 1): it means that at least one other healthy container instance (B) is running. In this case, even if the creation of a new instance (C) is delayed or fails due to insufficient resources, the existing healthy instance (B) can still independently handle all traffic, and the service will not be interrupted. The system can safely perform isolation operations. If the condition is not met (candidate quantity = 0): it means that the first container instance is the only available instance for the current service. In this case, if it is rashly isolated, and a new instance cannot be created due to insufficient resources, the service will immediately become completely unavailable. Therefore, the system will prohibit the isolation operation, and the first container instance will continue to run (despite the risk of OOM), thus prioritizing the most basic availability of the service. This precise trade-off between pursuing fault prevention (isolating risky instances) and ensuring service continuity (avoiding interruptions) ensures the robustness of the container management strategy.

[0087] The isolated state indicates that the container instance has been removed from the service traffic load balancer pool and the autoscaling and management scope of its application instance group, but its container process itself has not been terminated immediately and can still run and complete the processing of received requests or perform internal cleanup tasks.

[0088] Specifically, isolation of the first container instance can be achieved by modifying its metadata tags through the container orchestration system's management API. For example, in Kubernetes, a key tag on the Pod corresponding to the first container instance that matches the `.spec.selector` of the Deployment corresponding to the first container instance can be removed. For instance, a Pod managed by the `app=nginx` selector might have its tag changed from `app: nginx` to `app: nginx-isolated`. Considering that services or ingress controllers route traffic based on tag selectors, the tag mismatch will prevent the service or ingress controller from distributing any new service requests to the Pod corresponding to the first container instance. Furthermore, the Deployment controller to which the first container instance belongs will no longer include the Pod with the modified tag when calculating the number of available replicas it manages, thus treating the first container instance as unmanaged.

[0089] Correspondingly, when the first container instance detaches from the management of its Deployment by modifying its label, the Deployment controller detects its status in real time. If the number of ready Pods it currently manages, with matching labels (e.g., decreasing from 3 to 2), is lower than its declared desired number of replicas (spec.replicas: 3), the Deployment controller immediately and automatically triggers a scheduling process to find a suitable node in the cluster, create and start a completely new Pod with a label that exactly matches the selector—the second container instance. Optionally, the second container instance can run the exact same application image as the first container instance.

[0090] Step 208: Forward the historical processing data of the first container instance and the new service request for the first container instance to the second container instance, so that the second container instance can process the new service request.

[0091] Since the first container instance is isolated, all new service requests destined for the application will be automatically distributed to the remaining healthy instances (including other existing healthy instances and the newly created second container instance) that match the tags, according to the rules of the service or load balancer. The second container instance will begin receiving this new traffic once it passes the health check and enters the ready state. Optionally, to achieve seamless integration at the business level, especially for stateful services (such as user sessions in progress), context transfer is required.

[0092] The historical processing data of the first container instance refers to the incomplete transaction state or user session data being processed by the target application within the first container instance before it was isolated. This data is typically stored in the instance's memory and will be lost if the instance is directly deleted, leading to service interruption or data inconsistency. Therefore, in this embodiment of the invention, to achieve seamless service state migration rather than a simple stateless restart, after the first container instance is set to an isolated state, the target application should persist its critical session or transaction state in memory to a shared storage service in the cluster, such as Redis, a database, or a distributed configuration center. Subsequently, after the application in the second container instance starts and completes initialization, it reads and loads this historical processing data from the same shared storage, thereby restoring the business context and continuing to provide services to users.

[0093] For example, in a Java service for an online shopping cart, a user's shopping cart data might be temporarily stored in the memory of the first container instance. Before setting isolation, the application can persist the session data in memory (such as the shopping cart item list) to an external Redis cache or database. After the second container instance starts, the application logic loads the user's session context from this shared storage, thus enabling it to continue processing the user's shopping process. This achieves a seamless instance switch without the user's awareness, smooth migration of service data, and thereby ensures a good service experience for the target application.

[0094] Step 210: Delete the first container instance.

[0095] In particular, if the memory exception is triggered by a specific code path or data state of the application, directly deleting the instance will result in the permanent loss of the fault scene (such as the heap memory state before the OOM), making subsequent problem diagnosis and root cause analysis extremely difficult.

[0096] Therefore, in this embodiment of the invention, the deletion of the first container instance is not performed immediately after it is set to an isolated state; that is, a controllable waiting window is introduced between the isolated state and the final deletion. During this period, the first container instance (although it has stopped receiving new traffic) can still perform the following key cleanup tasks: 1. Memory Dump: Trigger the target application to generate a complete heap memory snapshot file. This file contains information about all objects in memory just before the OOM (Out of Memory) error, which is the most critical data for diagnosing memory leaks and analyzing the usage of large objects. 2. Data Persistence Finishing: Ensure that all "historical processing data" has been successfully synchronized to shared storage. 3. Graceful Connection Closure: Complete the normal handshake to close existing long-lived network connections, avoiding reset (RST) errors on the client.

[0097] Specifically, a graceful exit of the first container instance can be achieved through a handler (such as a shell script executed in a prestop hook). This handler can include: triggering the target application within the first container instance to perform a memory dump, saving a snapshot of the heap memory before the OutOfMemoryError (OOM) to a persistent volume for subsequent fault analysis; polling the application's health check interface, waiting for it to report the completion of operations such as the memory dump; and when a completion status is detected, or a preset maximum waiting time is reached (this time can be configured to be less than the Pod's termination grace period seconds to ensure cleanup is completed before the system is forcibly terminated), the handler calls the container orchestration system's API to safely delete the Pod resources corresponding to the first container instance, completely releasing the CPU, memory, and network port resources it occupied.

[0098] This invention transforms the traditional passive, crude, and easily interrupted container OOM (Out of Memory) handling method into a proactive, refined, and smooth automated hot-swap process. This significantly improves service availability without the user's awareness.

[0099] In some embodiments, the target application has a built-in memory status detection interface; monitoring the memory usage of the first container instance in which the target application runs includes:

[0100] The memory usage of the target application is periodically detected through the memory status detection interface;

[0101] If the memory usage is detected to meet a preset abnormal condition, the number of candidate available container resources corresponding to the target application is determined, including:

[0102] The memory status detection interface compares the amount of memory used with the pre-configured amount of memory for the target application to determine whether the memory usage indicates the preset abnormal condition.

[0103] If the memory usage indicates the preset abnormal condition, the response status code of the memory status detection interface is modified from the first status code indicating normal to the second status code indicating that it can be isolated through the memory status detection interface.

[0104] The memory status detection interface is periodically called to obtain the response status code. If the number of times the response status code is the second status code meets a preset threshold, it is determined that the memory usage of the first container instance meets the preset abnormal condition.

[0105] The memory status detection interface can be a functional endpoint provided by the target application to query its internal memory status. This interface can be a logical module integrated into the application's health check or management API, providing a standardized way for external systems (such as container health check probes or internal management threads) to obtain accurate memory usage data perceived by the application itself.

[0106] Specifically, the target application initializes and exposes this memory status monitoring interface upon startup. This interface encapsulates memory query logic for different runtime environments. For example, for Java applications, the implementation of this interface calls `java.lang.management.ManagementFactory` to obtain a `MemoryMXBean` instance; for Go applications, it calls the `runtime.ReadMemStats` function. When the interface is called, it performs memory data collection and returns structured memory usage information, typically including at least two key values: current memory usage and the configured maximum memory limit.

[0107] This refers to repeatedly calling the aforementioned interface at fixed time intervals. Optionally, the call cycle of the memory status monitoring interface can be shorter than the basic monitoring cycle of the container orchestration system, for example, set to 1 second. This periodic call is executed by a monitoring thread or scheduled task within the target application. This monitoring thread is independent of the application's main business logic to ensure that memory monitoring does not block normal request processing.

[0108] The pre-configured memory amount is the target application's known memory limit, which can be derived from startup parameters or container resource limitations. For example, the -Xmx parameter in a Java application (such as -Xmx2048m), or the value of the resources.limits.memory field in a Kubernetes Pod configuration (such as 2Gi).

[0109] In each periodic check, the monitoring thread obtains the current memory usage (denoted as Used) through the memory status detection interface and compares it with the pre-configured memory amount (denoted as Max).

[0110] The preset abnormal condition marks a high-risk warning line. When memory usage reaches this level, although the application is still running normally, its available memory (only 5% remaining) is very limited. Any small memory allocation request (such as processing a new user request or loading a piece of data) may trigger an Out Of Memory Error due to insufficient memory. Therefore, this threshold essentially defines a critical state where an OOM is about to occur but has not yet happened, providing the system with a brief window for proactive intervention.

[0111] To enable critical communication of internal application state to the outside world, the target application maintains an external health status, represented by a unified response status code, which can be returned by a memory status monitoring interface or other health check interfaces. Specifically, the response status code may include a first status code, typically the HTTP status code 200 OK, or other agreed-upon codes indicating memory health. The first status code can be a default value, indicating that the application is running normally and memory usage is within safe limits. Correspondingly, the second status code can be a custom signal indicating a specific anomaly. In this embodiment of the invention, the extended semantics of HTTP status codes can be borrowed, using 450 as the second status code to explicitly indicate excessively high memory usage and recommend isolation for this specific health condition.

[0112] When the monitoring thread determines that the memory usage indicates a preset abnormal condition (such as a usage rate ≥ 95%), it atomically modifies the response status code returned by the memory status detection interface (and the associated health check interface) from 200 to 450, thereby making the memory risk flag visible and allowing it to be detected by external health check mechanisms.

[0113] The memory status detection interface can be periodically invoked through the node agent component (Kubernetes Kubelet) of the container orchestration system where the first container instance resides. Based on the liveness probe configured in the Pod definition, Kubelet periodically (e.g., every 10 seconds) sends an HTTP GET request to the target container's health check endpoint (which integrates memory status detection functionality). Kubelet receives and parses the response status code for each probe. Instead of immediately taking action upon receiving a 450 status code for the first time, a preset threshold (e.g., 3) is introduced. This threshold corresponds to the failureThreshold field in the liveness probe configuration. Considering that application memory usage may experience brief spikes or fluctuations, a single detection of high usage might only be a transient phenomenon. Introducing a threshold instead of a single detection prevents false positives. By requiring multiple consecutive confirmations, occasional, self-recovering memory fluctuations can be effectively filtered out, ensuring that only persistent, genuine high-pressure memory risks trigger the costly instance replacement process, improving the accuracy and stability of system decisions.

[0114] This invention securely transmits the fine-grained memory state of the application to the container infrastructure through standardized interfaces and protocols (status codes). At the same time, it utilizes the infrastructure's probe mechanism to increase the robustness of the confirmation process, providing accurate and reliable input signals for subsequent intelligent isolation decisions based on global resource assessment.

[0115] In some embodiments, determining the number of candidate available container resources corresponding to the target application if the memory usage is detected to meet a preset abnormal condition includes:

[0116] Query the network address of the first container instance to obtain the identity identifier of the first container instance;

[0117] The application instance group to which the target application belongs is determined based on the identity of the first container instance;

[0118] Count the total number of container instances that are currently in a serviceable state in the application instance group;

[0119] The number of candidate available container resources is determined based on the total number of container instances and the number of the first container instances.

[0120] The identity identifier is used to uniquely identify a container instance within the container orchestration cluster. Considering that in a dynamic container environment, the name of a container instance (Pod) may change due to a restart, but its IP address within the cluster network is relatively stable over its lifecycle, the network address (Pod IP) of the first container instance can be used as its identity identifier. Specifically, the network address of the first container instance can be obtained by dynamically acquiring the client IP from which the request originated through the Kubernetes agent, i.e., the server. This network address serves as an accurate, non-maintainable query key for subsequent cluster API queries, avoiding query failures due to the use of potentially changing Pod names.

[0121] An application instance group is a logical abstraction and management unit in a container orchestration system for a group of container instances running the same application and performing the same service role. In Kubernetes, it can refer to a collection of Pods managed by a Deployment or StatefulSet controller. An application instance group defines the desired state of an application, including the container image used, the number of replicas, and the tag selector used to select the Pods it manages. After obtaining the Pod IP of the first container instance through a proxy service or processing script, a query request can be sent to the cluster API server. This request uses the Pod IP as a filter to query the resource objects of all Pods in the cluster. The API server returns the complete resource definition (YAML / JSON description) of the Pods matching that IP. From the returned Pod resource definition, the Pod's metadata, such as container instance tags and its owner reference information, can be parsed. By analyzing this information, it is possible to determine which Deployment (or StatefulSet) controller created and manages the Pod. Specifically, you can check the `metadata.ownerReferences` field of the Pod, which points to the parent controller resource that manages the Pod (such as a ReplicaSet, which is managed by a Deployment); or you can find the Deployment that manages the Pod by matching the Pod's tag with the `.spec.selector` field of all Deployments in the cluster. Thus, the application instance group (i.e., its Deployment) to which the first container instance belongs can be determined.

[0122] The serviceable state is a composite state. In Kubernetes, this is specifically represented by the Pod's phase being "Running" and all container readiness probes passing, meaning the Pod's Ready condition is True. Only Pods in this state are included in the service's load balancing endpoint list to receive external traffic. The query request targets all Pods managed by the aforementioned application instance group (Deployment). The API server returns a list of all Pods created by the ReplicaSet corresponding to that Deployment, along with their detailed statuses. Using this Pod list, the status field of each Pod is checked, filtering out all Pods that satisfy "status.phase == "Running" and whose status.conditions contain "type: Ready" and "status: "True", and then a count is made. This count value represents the total number of container instances currently in the serviceable state, denoted as N_total.

[0123] Understandably, the first container instance is the specific instance currently detected with a memory anomaly, and its quantity is 1. The number of candidate available container resources refers to the number of healthy instances remaining in the application instance group after excluding the first container instance itself. The formula for calculating the number of candidate available container resources is: N_available = N_total - 1. Here, N_total represents the actual processing capacity of the service at the current moment. N_available represents the processing capacity that the service would still retain if the first container instance failed immediately. By using N_available > 0, we determine whether the subsequent preset quantity conditions are met, and assess whether the remaining cluster capacity can still carry all traffic after losing the current problematic node. This dynamic calculation based on real-time cluster status is more adaptable to the elastic changes of the cluster (such as automatic scaling up and down, failure of other nodes) than static configuration or empirical thresholds, ensuring the situational adaptability and security of isolation decisions.

[0124] In some embodiments, the preset quantity condition includes the number of candidate available container instances being greater than or equal to 1; the step of setting the first container instance to an isolated state and creating a second container instance if the number of candidate available container resources meets the preset quantity condition includes:

[0125] If the number of available container instances meets a preset quantity condition, modify the tag information of the first container instance so that the first container instance is removed from the container control of the application instance group;

[0126] The second container instance is created based on the expected number of instances in the application instance group.

[0127] The tag information can be key-value pairs attached to resource objects (such as Pods) in the container orchestration system, used to identify and select resources. Application instance groups (such as Deployments) continuously discover and manage Pods that match them through a tag selector. For example, a Deployment named frontend might be configured with the selector app: frontend, which will manage all Pods with the tag app=frontend.

[0128] Modifying label information refers to removing or changing key labels on the first container instance (Pod) that precisely match the label selector of its Deployment. This can be executed by a proxy service or processing script with the appropriate permissions. The entity calls the container orchestration cluster's API to update the Pod resources corresponding to the first container instance. For example, in Kubernetes, a PATCH request can modify the Pod's `metadata.labels` field by changing the label value of the matching selector to indicate isolation, such as changing `app: frontend` to `app: frontend-isolated`. This causes the first container instance's labels to no longer satisfy the selector conditions of its original Deployment.

[0129] Based on container-based management mechanisms, the Deployment controller will no longer consider the Pod corresponding to the first container instance as part of the "replica count" managed by it in subsequent coordination loops. Similarly, Kubernetes Service objects build their load-balanced endpoint lists based on label selectors. Due to a label mismatch, the Service immediately removes the first container instance from its endpoint list. Thereafter, new service requests will no longer be routed to the first container instance.

[0130] This invention, by modifying the label rather than directly deleting the Pod, ensures that the process of the first container instance continues to run, and its network stack and file system remain intact. It can continue to process connections established before isolation and perform cleanup operations such as memory dumps, but it no longer receives new traffic and is no longer out of the management lifecycle such as automatic scaling, thus creating conditions for graceful exit and preservation of the fault scene.

[0131] The expected number of instances is a core field (spec.replicas) defined in the application instance group (Deployment) specification, which declares the number of serviceable replicas that the application expects to maintain. For example, replicas: 3 means that the Deployment expects to always have 3 healthy Pods running.

[0132] When the Deployment controller detects that the number of its managed, tagged, ready Pods (which becomes N_total - 1 after isolation occurs) is lower than its declared expected number of instances (spec.replicas), the Deployment controller performs the following process to fill this replica count gap caused by isolation:

[0133] Based on the Pod template defined in the Deployment, a new Pod resource definition is generated. The scheduling request for the new Pod is submitted to the cluster scheduler, which selects a suitable worker node based on resource constraints, affinity, and other policies. On the target node, the Kubelet receives the Pod definition, pulls the required image, and starts the container. This newly started Pod is the second container instance. After starting, this second container instance passes the readiness probe check and is then added to the endpoint list by the Service, beginning to receive and process new service requests.

[0134] In this embodiment of the invention, the proxy service (or script) is only responsible for performing a lightweight, deterministic operation: modifying the label to trigger isolation. It does not need to concern itself with the complex processes of creating, scheduling, and starting new instances. This leverages the strong consistency guarantee of the native Kubernetes controller to ensure the successful creation of new instances and avoids errors that might be introduced by self-developed mechanisms.

[0135] In some embodiments, after setting the first container instance to an isolated state and creating a second container instance based on the available container instances if the number of available container instances meets a preset quantity condition, the method includes:

[0136] Perform a memory dump operation on the target application;

[0137] In response to the completion of the memory dump operation, the target application modifies the response status code of the memory status detection interface from the second status code to the third status code indicating the completion of the memory dump.

[0138] Deleting the first container instance includes:

[0139] Periodically query the response status code of the memory status detection interface;

[0140] If the response status code is detected to change from the second status code to the third status code, delete the first container instance;

[0141] And / or, if the response status code is detected to have not changed to the third status code within a preset time period, the first container instance is deleted.

[0142] Memory dumping refers to the operation of completely and persistently storing the memory contents of a target application in a specific format to a storage medium during runtime. By performing a memory dump, the memory state at the moment of failure is captured after the application is isolated due to a memory anomaly but before it is ultimately deleted, generating a diagnostic snapshot (such as a Java Heap Dump file) that can be used for post-event analysis. This file records in detail the type, reference relationships, and size of all objects in the heap memory, and is crucial data for analyzing memory leaks, identifying large objects, and locating the root cause of OutOfMemoryErrors (OOM).

[0143] Memory dump operations can be performed by the target application within the first isolated container instance. This can be triggered after the application has been marked as "isolated" (second status code, such as 450) and its Pod has been tagged as unmanaged. Memory dumps can be initiated through pre-defined management interfaces or signal handlers within the application. For example, for Java applications, this can be triggered by calling the jmap tool, using the dumpHeap method of HotSpotDiagnosticMXBean, or receiving a specific signal (such as SIGUSR1); for Go applications, it can be triggered by writing to the debug / pprof / heap endpoint or calling relevant functions in the runtime / debug package to generate a memory profile.

[0144] Considering that memory dump operations can be time-consuming (ranging from seconds to minutes) and consume significant I / O and CPU resources, this embodiment of the invention schedules them after the instance has been isolated (i.e., traffic has been removed). This timing ensures that the memory dump operation does not affect currently served user requests, nor does it exacerbate memory pressure due to resource contention, leading to faster OutOfMemoryError (OOM). The dumped files are typically written to a persistent storage volume (such as hostPath, NFS, or cloud storage volume) mounted on the first container instance to ensure that diagnostic files are preserved after the Pod is deleted.

[0145] The third status code is used to indicate that the pre-defined cleanup work (specifically memory dump) has been completed. In this embodiment of the invention, the semantics of extended HTTP status codes can be used, for example, 451 can be used as the third status code to explicitly indicate that "the memory dump has been completed and the instance can be safely deleted".

[0146] After the target application completes the memory dump operation, it atomically updates the return status code of its externally provided memory status detection or health check interface, changing it from the second status code (450) indicating "memory high risk, can be isolated" to the third status code (451) indicating "cleanup complete, can be deleted". The status code change constructs a clear and externally detectable lifecycle state machine: status code 200 (normal) jumps to status code 450 (memory abnormality, to be isolated), and then jumps to status code 451 (dump complete, to be deleted), thus providing a clear and reliable basis for the advancement of external automated processes.

[0147] After completing the isolation operation (modifying the Pod label), the processing script does not immediately delete the Pod, but instead starts a polling loop. Within each polling cycle (e.g., every 5 seconds), the script sends an HTTP request to the memory state check interface or health check interface of the target application inside the first container instance.

[0148] When the processing script detects a change in the response status code to the third status code (451) during polling, it determines that the target application has completed all pre-defined cleanup operations (at least including memory dump). At this point, there is no longer any need to retain the first container instance, and its occupied resources can be safely released. Therefore, it immediately calls the container orchestration cluster's API (such as Kubernetes' delete Pod interface) to initiate a deletion request for the first container instance (Pod). This deletion operation is the final resource reclamation step.

[0149] Optionally, considering that memory dump operations may fail or be suspended for various reasons, such as a full disk, application deadlock, or the dump process itself being unusually slow, without a timeout mechanism, the processing script may wait indefinitely, causing isolated Pods to occupy resources for an extended period without being released.

[0150] Therefore, the processing script starts a timer simultaneously when it begins polling. The duration of this timer is the preset duration. If the script detects that the status code has changed to 451 before the timer expires, it will proceed with the normal deletion process. If the timer expires, regardless of the currently polled status code (which may still be 450, or the request may have failed), the script will force the deletion operation.

[0151] The preset duration must be less than the termination grace period defined in the Pod where the first container instance resides. This grace period is the maximum time Kubernetes waits before forcibly terminating (SIGKILL) a container after sending a SIGTERM signal. Ensuring that the preset duration is less than this grace period is to guarantee that the forced deletion logic of the processing script can be completed before the Kubernetes system forcibly kills the container, thereby avoiding race conditions or undefined states and ensuring that the entire cleanup process is completed deterministically within the platform's defined lifecycle.

[0152] This embodiment ensures the finality and timeliness of resource release through status code polling and timeout control, avoiding process blockage caused by application malfunctions.

[0153] In some embodiments, the method is based on a pre-configured script program, which is loaded into the system corresponding to the first container instance by mounting a storage volume when the first container instance starts.

[0154] The preset duration is less than the termination grace time corresponding to the first container instance; the termination grace time is used to define the maximum waiting interval between initiating the request to delete the first container instance and the termination of the first container instance.

[0155] A script is a sequence of computer-executable instructions used for automated execution. In this embodiment of the invention, the program can be implemented as a shell script (such as health_check.sh) due to its inherent high compatibility and lightweight nature in Linux container environments. Storage volume mounting is a mechanism provided by container orchestration platforms that allows files or directories in external storage (such as host directories, network file systems (NFS), or configuration dictionaries (ConfigMaps)) to specified paths within the container.

[0156] Specifically, a written shell script (e.g., ` / path / on / host / health_check.sh`) can be stored in a storage location accessible to the target Pod. A typical approach is to use a Kubernetes ConfigMap resource object, defining the script's content as a data item within the ConfigMap. In the target application's Deployment or Pod template definition, a volume is declared, its source pointing to the aforementioned storage location (e.g., referencing the ConfigMap). Then, in the container specification, this volume is mounted to a specific path in the container's file system, such as ` / opt / scripts / `. Thus, when the first container instance (Pod) is created and started, the container orchestration system (Kubelet) performs the volume mount operation. The script file `health_check.sh` will appear as part of the container's internal file system in the specified mount path (e.g., ` / opt / scripts / health_check.sh`) and will have executable permissions.

[0157] Since the script logic is independent of the application's business logic and container image, modifying or upgrading the script only requires updating the ConfigMap and restarting the Pod (or utilizing some dynamic loading mechanism), without needing to rebuild and push a large application image. Furthermore, the same script can be shared by multiple different application instances, simply by configuring the same volume mount in their Pod templates.

[0158] The termination grace period is a key parameter defined by container orchestration platforms for the Pod level. In Kubernetes, this parameter is named `terminationGracePeriodSeconds`, and its default value is typically 30 seconds. When a Pod needs to be deleted, a SIGTERM signal is first sent to each container within the Pod, and then a grace period (i.e., the termination grace period) is waited for the containers to gracefully exit. If the containers have not stopped after the timeout, a forced termination signal SIGKILL is sent.

[0159] The preset duration is the maximum polling time (e.g., 300 seconds) for the processing script to wait for the memory dump to complete. Setting the constraint "preset duration < termination grace period" ensures orderly coordination between user-space cleanup logic and platform-mandated lifecycle management, avoiding unpredictable race conditions or conflicts. When the processing script calls the API to delete the Pod due to timeout, Kubernetes receives the deletion request and begins the Pod termination process. At this time, the timer defined by terminationGracePeriodSeconds starts. Since the preset duration ensures that the entire polling and deletion decision process of the script occurs before the start of this grace period, a complete and undisturbed graceful exit time window is reserved for the containers within the Pod (including the target application and the processing script itself).

[0160] If the preset duration is greater than or equal to the termination grace period, the following situation may occur: the processing script is still polling or about to initiate deletion, but the Pod's grace period has expired, causing the container to be forcibly killed by SIGKILL. This may interrupt the ongoing memory dump operation (resulting in an incomplete dump file), or it may cause the processing script's own logic to be abruptly terminated, thus failing to complete its resource cleanup mission.

[0161] This embodiment improves maintainability and reusability by employing a lightweight, decoupled deployment scheme with script mounting. By precisely defining the numerical constraint relationship between the preset duration and the platform's termination grace period, it cleverly avoids the risks associated with forced platform intervention while leveraging the platform's automation capabilities. This achieves seamless and deterministic integration of user-defined complex lifecycle management logic with the platform's native lifecycle management. This ensures that the entire end-to-end process, from fault detection to resource reclamation, possesses both the flexibility to handle complex situations (waiting for dumping) and the reliability of final completion.

[0162] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0163] Based on the same inventive concept, this application also provides a container management device for implementing the container management method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more container management device embodiments provided below can be found in the limitations of the container management method described above, and will not be repeated here.

[0164] In one exemplary embodiment, such as Figure 3 As shown, a container management device 300 is provided, the device comprising:

[0165] Monitoring module 302 is used to monitor the memory usage of the first container instance on which the target application runs;

[0166] The determination module 304 is used to determine the number of candidate available container resources corresponding to the target application if the memory usage is detected to meet a preset abnormal condition.

[0167] Setting module 306 is configured to, if the number of candidate available container resources meets a preset quantity condition, set the first container instance to an isolated state and create a second container instance; wherein, the isolated state indicates that new service requests are no longer received;

[0168] Forwarding module 308 is used to forward the historical processing data of the first container instance and the new service request for the first container instance to the second container instance, so that the second container instance can process the new service request.

[0169] The deletion module 310 is used to delete the first container instance.

[0170] Each module in the aforementioned container management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0171] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a container management method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0172] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0173] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing container management method embodiments.

[0174] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing container management method embodiments.

[0175] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing container management method embodiments.

[0176] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0177] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0178] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0179] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A container management method, characterized in that, The method includes: Monitor the memory usage of the first container instance on which the target application runs; If the memory usage is detected to meet a preset abnormal condition, the number of candidate available container resources corresponding to the target application is determined. If the number of candidate available container resources meets a preset quantity condition, the first container instance is set to an isolated state and a second container instance is created; wherein, the isolated state indicates that new service requests are no longer received; The historical processing data of the first container instance and the new service request for the first container instance are forwarded to the second container instance so that the second container instance can process the new service request. Delete the first container instance.

2. The method according to claim 1, characterized in that, The target application has a built-in memory status detection interface; monitoring the memory usage of the first container instance in which the target application runs includes: The memory usage of the target application is periodically detected through the memory status detection interface; If the memory usage is detected to meet a preset abnormal condition, the number of candidate available container resources corresponding to the target application is determined, including: The memory status detection interface compares the amount of memory used with the pre-configured amount of memory for the target application to determine whether the memory usage indicates the preset abnormal condition. If the memory usage indicates the preset abnormal condition, the response status code of the memory status detection interface is modified from the first status code indicating normal to the second status code indicating that it can be isolated through the memory status detection interface. The memory status detection interface is periodically called to obtain the response status code. If the number of times the response status code is the second status code meets a preset threshold, it is determined that the memory usage of the first container instance meets the preset abnormal condition.

3. The method according to claim 1, characterized in that, If the memory usage is detected to meet a preset abnormal condition, the number of candidate available container resources corresponding to the target application is determined, including: Query the network address of the first container instance to obtain the identity identifier of the first container instance; The application instance group to which the target application belongs is determined based on the identity of the first container instance; Count the total number of container instances that are currently in a serviceable state in the application instance group; The number of candidate available container resources is determined based on the total number of container instances and the number of the first container instances.

4. The method according to claim 3, characterized in that, The preset quantity condition includes that the number of candidate available container instances is greater than or equal to 1; the step of setting the first container instance to an isolated state and creating a second container instance if the number of candidate available container resources meets the preset quantity condition includes: If the number of available container instances meets a preset quantity condition, modify the tag information of the first container instance so that the first container instance is removed from the container control of the application instance group; The second container instance is created based on the expected number of instances in the application instance group.

5. The method according to claim 2, characterized in that, After setting the first container instance to an isolated state and creating a second container instance if the number of candidate available container resources meets a preset quantity condition, the method includes: Perform a memory dump operation on the target application; In response to the completion of the memory dump operation, the target application modifies the response status code of the memory status detection interface from the second status code to the third status code indicating the completion of the memory dump. Deleting the first container instance includes: Periodically query the response status code of the memory status detection interface; If the response status code is detected to change from the second status code to the third status code, delete the first container instance; And / or, if the response status code is detected to have not changed to the third status code within a preset time period, the first container instance is deleted.

6. The method according to claim 5, characterized in that, The method is based on a pre-configured script program, which is loaded into the system corresponding to the first container instance by mounting a storage volume when the first container instance starts. The preset duration is less than the termination grace time corresponding to the first container instance; The termination grace period is used to define the maximum waiting interval between initiating a request to delete the first container instance and the termination of the first container instance.

7. A container management device, characterized in that, The device includes: The monitoring module is used to monitor the memory usage of the first container instance on which the target application runs; The determination module is used to determine the number of candidate available container resources corresponding to the target application if the memory usage is detected to meet a preset abnormal condition; The configuration module is used to set the first container instance to an isolated state and create a second container instance if the number of candidate available container resources meets a preset quantity condition; wherein, the isolated state indicates that new service requests are no longer received; The forwarding module is used to forward the historical processing data of the first container instance and the new service request for the first container instance to the second container instance, so that the second container instance can process the new service request. The delete module is used to delete the first container instance.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images