A Kubernetes-based efficient container resource pool management method and device

Abstract

The application belongs to the field of container arrangement, and is a high-efficiency container resource pool management method and device based on Kubernetes, comprising the following steps: S1: obtaining configuration parameters, performing resource proportioning, constructing a proportioning model, generating idle containers, and preloading high-frequency dependencies, creating a Namespace to complete isolation initialization and entering metadata; S2: matching idle containers through an adaptive model, binding an app and granting minimum permissions according to a preset; S3: verifying a release request of the app, recovering permissions of the app, preloading high-frequency dependencies, and synchronizing to metadata; S4: collecting pool load data, predicting a load condition, executing expansion and contraction strategies, and synchronizing instance quantity and state; S5: defining multi-state flow rules of containers, monitoring and verifying legality of changes in real time, and if illegal, intercepting, persisting state data, and providing a query service; and S6: obtaining container state data and synchronously feeding back to a life cycle management and control module after changing the container state.

Description

Technical Field

[0001] This invention belongs to the field of container orchestration, and in particular, it relates to a method and apparatus for efficient container resource pool management based on Kubernetes. Background Technology

[0002] With the rise of cloud computing and microservice architectures, Kubernetes, as the de facto standard in container orchestration, is widely used in the deployment and management of large-scale distributed systems. However, in practical applications, especially in the big data field, the scheduling and management of container resources have the following characteristics:

[0003] 1. It usually takes several minutes to start up computing resources, with a large amount of time spent on the container creation process, such as image download, Pod creation, and container startup.

[0004] 2. Typically, cloud-based business workloads, especially periodic scheduled tasks and OLAP queries in big data scenarios, exhibit significant periodic fluctuations or random discrete fluctuations, and may even have long business gaps where resources are idle. How to share or reuse these idle resources is one of the core technological evolution directions of cloud computing.

[0005] The current industry practice is to release the corresponding business container resources when there are no business requests or loads for a period of time; and to restart the business container resources when new business loads arrive.

[0006] However, restarting the business container often takes tens of seconds or even minutes, which limits the efficiency of scaling and greatly affects the user experience.

[0007] 3. In the big data field, spot instances are commonly used due to cost considerations. At the same time, stability needs to be ensured by proportionally allocating demand instances and spot instances and dynamically adjusting the balance in real time. However, computing resources are usually a group of containers managed by Kubernetes workloads or operators. This workload management method does not support heterogeneous machine types, especially heterogeneous resources.

[0008] In the above scenarios, managing and scheduling container resources efficiently is a challenge, especially when facing scenarios with heterogeneous machine types and resources. Traditional Kubernetes workload or operator-based management methods are difficult to meet the requirements. Summary of the Invention

[0009] This invention proposes an efficient container resource pool management method based on Kubernetes.

[0010] An efficient container resource pool management method based on Kubernetes includes the following steps:

[0011] S1: Includes an initialization module, which obtains configuration parameters, performs resource allocation based on historical data, builds an allocation model, generates idle containers, preloads high-frequency dependencies, creates a namespace to complete isolation initialization, and enters metadata.

[0012] S2: Includes a scheduling module that accepts resource requests from apps, matches idle containers using an adaptation model, binds the app and grants the minimum permissions according to a preset, updates the container status to allocated, and records the binding relationship.

[0013] S3: Includes a release module, which verifies the app's release request. If valid, it changes the container state from the release state to the idle state, reclaims the app's permissions, preloads high-frequency dependencies, and synchronizes them to metadata.

[0014] S4: Includes a scaling module, which collects pool load data, predicts load conditions using an LSTM model, executes scaling up and down strategies based on app priority, and synchronizes instance count and status.

[0015] S5 includes a lifecycle management module that defines the multi-state transition rules of containers, monitors and verifies the legality of changes in real time, intercepts illegal changes, persists state data and provides query services; it also includes a state synchronization mechanism that pushes container state data to the failover module of S6 in real time.

[0016] S6: Includes a failover module, which acquires container status data, changes the container status, and synchronously feeds back to the lifecycle management module; monitors the health status of containers in real time, marks them as invalid when abnormal according to presets, requests a new container, requests the release of the old container from the app, and cleans up residual resources.

[0017] Preferably, S1 includes intelligent initialization and heterogeneous configuration of container pools, including intelligent allocation of heterogeneous resources, which includes: allocating resources based on historical allocation data, constructing an allocation model, and determining the initial allocation of resources of each specification by combining the historical allocation frequency of containers of each specification, average usage time, and average resource utilization rate of each specification.

[0018] Preferably, S2 includes intelligent resource scheduling and secure isolation allocation, which includes the following sub-steps:

[0019] S21: Intelligent Heterogeneous Resource Matching: Construct an AI adaptation model, input app resource requirements, container specifications and historical matching data, use a multi-dimensional non-linear priority sorting algorithm to calculate container matching weights, and filter out suitable idle containers based on the weights.

[0020] S22: Container security isolation: Implement container isolation within the pool based on the Namespace created during the container pool initialization phase, configure dynamic resource quota management, and adjust the isolation threshold according to the importance level of the app;

[0021] S23: Dynamic permission control: When the container is bound to the app, the minimum set of permissions is automatically granted according to the app's functional requirements; when the container is released, the permission revocation process is triggered based on the release request of S3, all granted permissions are revoked and permission change logs are recorded.

[0022] Preferably, the S2 and S3 include a resource scheduling and release loop optimization mechanism. The scheduling module records the app resource usage duration data and associates it with the container identifier ID, and feeds it back to the release module. The release module sorts the containers into the release process according to the resource usage duration of the containers. The released containers are based on the resource usage duration data and historical scheduling records. Before the container state changes to the idle state, the dependency images of high-frequency apps are counted and preloaded.

[0023] Preferably, the S2 and S4 include a linkage optimization mechanism for scheduling and scaling, including: the scheduling module pushes the number of used containers and app priority data to the scaling module, and the scaling module dynamically adjusts the expansion threshold; new container instances created by the scaling module are automatically added to the scheduling candidate pool through the state synchronization interface and enter S2.

[0024] Preferably, S3 and S1 include a collaborative update mechanism for release and initialization, including: feeding back the resource specifications and release frequency of the returned container to the initialization module, and adjusting the allocation ratio of the resource of that specification when the release frequency of a container of a certain specification reaches a preset threshold.

[0025] Preferably, step S4 includes the following processing steps:

[0026] S41: AI Resource Demand Prediction: Using a pre-set LSTM model, input time series load data, output predicted load for future time moments, and train to minimize weighted prediction error;

[0027] S42: Differentiated scaling strategy: A core app identifier list is preset. When expanding, container specification instances corresponding to the apps in the list are created first. The expansion quantity is determined by the total capacity of the container pool and the preset expansion redundancy coefficient. When shrinking, idle containers corresponding to non-core apps are destroyed first. The containers are destroyed in order of idle time and the number of containers destroyed is determined by the preset shrinkage safety coefficient.

[0028] S43: Cross-pool resource scheduling linkage: Collect load data from several container pools. When the idle resource ratio of a container pool meets the preset conditions, mark the redundant resources of the container pool as cross-pool schedulable and synchronize them to the resource scheduling center. When the load of other container pools reaches the preset load threshold, the resource scheduling center matches suitable containers from the cross-pool schedulable resources, performs cross-pool allocation according to the allocation strategy in S2, and updates the metadata of the relevant container pools synchronously.

[0029] Preferably, step S6 includes the following processing steps:

[0030] S61: Fault prediction and early backup: Real-time collection of container health indicators, calculation of container health index based on preset weight coefficients, and creation of container instance of the same specification when the health index meets preset conditions and marking it as standby status, and continuous monitoring of the main container status.

[0031] S62: Multi-active container redundancy deployment: For container instances corresponding to the core app, deploy at least one redundant replica on different physical or virtual nodes in the same container pool. The replica configuration is completely consistent with the main container. The redundant replica is in standby state by default and only occupies basic resources. When the main container fails and triggers the failover process, the redundant replica is activated and converted to an allocated state and bound to the app.

[0032] S63: Resource self-healing after fault recovery: After the faulty container is replaced, the destruction process of the old container in an invalid state is initiated to release the resources it occupies and clean up the network configuration and mount directory associated with the container; after self-healing is completed, the status data of the new container is synchronized to the full lifecycle status management module to update the status data and associated metadata.

[0033] Preferably, S6 and S2 include a failover and scheduling resource reservation linkage mechanism, including: the failover module reserves preset resources as backup containers when the container pool is initialized, and the scheduling module avoids the reserved backup containers when allocating; when the backup containers are used, an expansion request is sent to supplement new reserved resources, and the supplemented container instances are added to the scheduling candidate pool of S2 to ensure that the reserved resources are dynamically replenished.

[0034] This invention also discloses a high-efficiency container resource pool management device based on Kubernetes, which applies the above-mentioned high-efficiency container resource pool management method based on Kubernetes, including:

[0035] Container pool initialization module: used to execute the container pool initialization operation of S1, realize heterogeneous resource allocation, container creation, preloading and metadata management;

[0036] Resource scheduling module: used to perform the resource scheduling and allocation operations of S2, including adaptation model matching, permission granting and status updating;

[0037] Release optimization module: used to perform the resource release optimization operation of S3, including release verification, state transition and dependency preloading;

[0038] Elastic scaling module: used to perform the dynamic elastic scaling operation of S4, including load acquisition, prediction and scaling strategy execution;

[0039] Lifecycle management module: used to perform the full lifecycle management operations of the S5, including state definition, verification, persistence and inspection;

[0040] Failover module: Used to perform the failover processing operations of S6, including health monitoring, backup creation, fault switching and resource self-healing;

[0041] Module collaboration unit: used to realize data interaction and linkage between various modules.

[0042] This application also discloses a computer-readable storage medium storing a program that, when executed by a processor, implements the above-described efficient container pooling management method based on Kubernetes.

[0043] The present invention has the following beneficial effects:

[0044] 1. By pooling containers, releasing them to an idle state without destroying them, and using LSTM load prediction for elastic scaling and cross-application sharing, the high latency of traditional container creation is solved, idle resource waste is reduced, and resource costs in the cloud computing environment are effectively optimized.

[0045] 2. By predicting faults and implementing cross-node multi-active redundancy, service interruptions caused by faults are avoided, core business switching responses are rapid, and the high service continuity requirements of big data, e-commerce and other scenarios are met. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of the architecture of an efficient container resource pool management method based on Kubernetes according to the present invention. Detailed Implementation

[0047] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions in the embodiments of this invention will be clearly described below in conjunction with the examples.

[0048] like Figure 1 As shown, this invention proposes a method and apparatus for efficient container resource pool management based on Kubernetes, the core features of which are:

[0049] 1. Container Pooling and Elastic Mechanism: When an app releases container resources, the container is returned to the container pool, and its state changes from ACTIVE to FREE instead of being directly destroyed. Simultaneously, the container instances are elastically scaled based on changes in the container pool load; this ensures low latency in resource allocation and improves resource utilization through cross-application container sharing.

[0050] 2. Heterogeneous within the same pool: The container pool supports pods with different CPU, memory, and even image specifications. It provides a declarative API with only two core fields: poolName and replicas, shielding the internal implementation of the heterogeneous resource pool.

[0051] 3. Extended Container Lifecycle: Compared to native Kubernetes container states, pooled containers extend the states to ACTIVE, RELEASING, and FREE. ACTIVE indicates the container has been assigned to an app (i.e., a business application), FREE indicates the container is idle, and RELEASING indicates an intermediate state during resource release.

[0052] 4. Personalized failover mechanism: In addition to the basic failover process, a graceful container replacement process has been developed: first, apply for resources, then inquire with the app about the availability of old resources, and finally complete the replacement, further ensuring uninterrupted service operation.

[0053] Its structure includes:

[0054] 1. Pool manager:

[0055] a. Layered structure of container pools: Each different machine type or heterogeneous resource is managed by a group of pods by a workload cloneset, and multiple clonesets managing heterogeneous resources and multiple groups of pods of heterogeneous machine types constitute a pool.

[0056] b. Tiered Elasticity Strategy: A tiered elasticity strategy can be configured on the container pool, triggering expansion when the utilization limit is reached and shrinking when the utilization falls below the lower limit. Additionally, the pool-manager monitors the cloneset utilization in real time and triggers cloneset expansion or shrinking accordingly.

[0057] 2. Container pool-based scheduler:

[0058] a. The scheduling algorithm supports basic scheduling strategies such as CPU resource spreading, nodeSelector, blacklist, affinity, anti-affinity, and topologySpread.

[0059] b. Optimize topologySpread scheduling strategy to support proportional distribution, and support application-specific allocation of on-demand and spot instance scenarios.

[0060] 3. Container pool-based workload (peaset):

[0061] a. Responsible for application-based container pool resource management, including resource allocation and release, and ensuring eventual consistency of resource changes.

[0062] b. Responsible for the application's customized failover process, such as: the replacement process first requests resources, then asks the user if the old resources can be released, and then completes the replacement.

[0063] c. Periodically and gracefully rebalance container resources to meet the topologySpread scheduling strategy.

[0064] 4. The daemon (supervisor) of the pooled container:

[0065] a. Responsible for managing and executing pooled containers: start, stop, and restart commands, as well as container health checks.

[0066] b. Periodically report heartbeats to the scheduler and execute container management commands initiated by the scheduler.

[0067] c. Monitoring metrics such as CPU and memory usage of proxy pool containers.

[0068] This invention provides a method for efficient container resource pool management based on Kubernetes, comprising the following steps:

[0069] S1. Intelligent initialization and heterogeneous configuration of container pool: Obtain pool name, number of container instance replicas and heterogeneous resource specifications, build a matching model based on historical data, generate preloaded FREE idle containers with high frequency dependencies, create namespace to complete isolation initialization and record metadata.

[0070] S2, Intelligent Resource Scheduling and Secure Isolation Allocation: Receives app resource requests, matches FREE containers through AI adaptation models, binds the app and grants minimum permissions, updates the status to ACTIVE and records the binding relationship;

[0071] S3, Intelligent Release and Status Optimization of Container Resources: Verify the legality of the app's release request, change the status to FREE during the RELEASING release, reclaim permissions and preload high-frequency dependencies, and synchronize to metadata;

[0072] S4. Dynamic Elastic Scaling and Resource Prediction: Collect pool load data, predict load through LSTM model, trigger differentiated strategies of prioritizing expansion of core apps and prioritizing shrinkage of idle containers of low-priority apps, and synchronize instance count and status.

[0073] S5, Intelligent Management and Control of the Entire Lifecycle Status: Defines multi-state transition rules, monitors and intercepts illegal changes, persists status data and makes it available for querying by various modules;

[0074] S6. Personalized failover and service continuity assurance: Monitor container health indicators, mark INVALID as invalid when abnormal, request a new container and ask the app to release the old container, and replace and clean up residual resources after confirmation.

[0075] The step S1, intelligent initialization and heterogeneous configuration of the container pool, also includes S1-1, intelligent allocation of heterogeneous resources, specifically: constructing an allocation model based on historical allocation data, and inputting the historical allocation counts of containers of each specification. Average usage time Average resource utilization rate Output the initial allocation ratio of heterogeneous resources, using the following formula:

[0076] in Let k be the resource allocation ratio of the k-th specification. Total number of specifications Let be the average resource utilization rate of the k-th type of container, with a value ranging from 0 to 1. The specification adaptation correction factor is dynamically set according to the pooling scenario, with a value range of 0.8-1.2. The core business adaptation specification is set to 1.2, and the ordinary specification is set to 1.0.

[0077] With the goal of maximizing the synergistic effect of resource utilization and allocation efficiency, the following is introduced: Reflecting the actual efficiency of specifications in use, Convert utilization rate into a positive contribution factor to avoid low-utilization specifications occupying too much of the allocation; The specifications are prioritized to suit different business scenarios, and the overall allocation ratio is ensured through normalization. The derivation process first calculates the basic contribution. Then through The final contribution is obtained after adjustment. The proportion is the ratio of the final contribution of a single specification to the total contribution.

[0078] The step S2 intelligent resource scheduling and secure isolation allocation also includes S2-1 intelligent heterogeneous resource matching, specifically: constructing an AI adaptation model, inputting app resource requirements, container specifications, and historical matching data, and employing a multi-dimensional nonlinear priority ranking algorithm with the following weight formula:

[0079] in Match weights to the i-th container. For dynamic adjustment factors and satisfying , Let be the historical average CPU utilization of the i-th container, with a value ranging from 0 to 1. Let represent the memory matching degree between the i-th container and the app, with a value ranging from 0 to 1, where 1 represents a complete match. Let be the compatibility coefficient between the i-th container image and the app, where 1 represents compatibility and 0 represents incompatibility. This is the normalized idle time value of the i-th container, ranging from 0 to 1. The shorter the idle time, the closer it is to 1.

[0080] Breaking through the traditional linear weighting model, introducing Strengthen the matching priority of low-load containers. Build interactive contributions that are memory-matching and image-compatible. Prioritize the scheduling of recently idle containers; initial settings When mirror incompatibility causes a matching failure rate exceeding 20%, dynamically adjust... By iteratively optimizing the factors using the gradient descent method, the matching success rate is stabilized at over 90%, and the factor summation constraint is always satisfied during the adjustment process.

[0081] Step S2 further includes S2-2 container security isolation, specifically: implementing container isolation within the pool based on the Namespace created in S1, configuring dynamic resource quota management, adjusting the isolation threshold according to the importance level of the app, increasing the upper limit of the container quota for core apps by 30% compared to the base value, and decreasing the upper limit of the container quota for low-priority apps by 20% compared to the base value, with the quota management scope covering CPU usage, memory usage, and network bandwidth.

[0082] Step S2 also includes dynamic permission management in S2-3, specifically: when the container is bound to the app, the minimum permission set is automatically granted according to the app's functional requirements. The permission set includes container start and stop permissions, access permissions to specified directories, and limited Kubernetes API call permissions; when the container is released, the permission revocation process is triggered based on the release request in S3, all granted permissions are revoked and permission change logs are recorded.

[0083] Step S4, Dynamic Elastic Scaling and Resource Prediction, also includes S4-1, AI Resource Demand Prediction, specifically: constructing a prediction model using a Long Short-Term Memory (LSTM) network model, and inputting time-series load data. ,in Let be the container pool load value at time t, ranging from 0 to 1, with pool capacity saturation set to 1, and n be the time window length set to 12. Output the predicted load at time t+1 in the future. The model training objective is to minimize the weighted prediction error.

[0084] in The number of training samples, This is the time decay factor, with a value ranging from 0.8 to 0.95, and a default value of 0.9. This represents the actual load value at time t=i+1. The predicted load value at time t=i+1.

[0085] To address the issue of insufficient weighting of recent data by traditional mean squared error, a new approach is introduced... Give higher weight to recent samples. The closer the value is to 1, the more significant the weighting advantage of recent data becomes; based on the time-series dependency of the load, the LSTM model uses an input gate... Forgotten Gate Cell state Output gate Generate prediction results Using the weighted mean squared error as the loss function, the Adam optimizer iteratively optimizes the model parameters until the loss function value is less than 0.05, ensuring that the prediction accuracy meets the requirements of scalable decision-making.

[0086] Step S4 further includes S4-2, a differentiated scaling strategy, specifically: a pre-defined core app identifier list is used; during scaling, container instance instances corresponding to the apps in the list are created first, and the number of instances created is determined by the specified parameters. ,in The total capacity of the container pool The redundancy factor for expansion ranges from 1.1 to 1.3, with 1.3 for the core app pool. During scaling down, non-core app-related FREE containers are destroyed first, in descending order of idle time, with the number of containers destroyed determined by this factor. ,in This is the safety factor for reduced capacity, with a value ranging from 0.8 to 1.0, and a default value of 0.9.

[0087] The expansion quantity is calculated by multiplying the difference between the predicted load and the current load by the total capacity to obtain the base value, and then applying a redundancy factor. The adjusted value is rounded up to ensure it can handle sudden load increases; the reduction amount is calculated by multiplying the difference between the current load and the predicted load by the total capacity to obtain a base value, which is then adjusted using a safety factor. The adjusted size is rounded down to the nearest integer to avoid excessive shrinkage leading to resource shortages. and The value is dynamically adapted based on the app's importance level.

[0088] Step S4 also includes S4-3 cross-pool resource scheduling linkage, specifically: collecting load data from multiple container pools. , where n is the total number of container pools, and the percentage of idle resources in a certain container pool p is... At that time, redundant resources will be allocated. Marked as cross-pool schedulable and synchronized to the resource scheduling center, where The total capacity of container pool p. This is a cross-pool scheduling coefficient, ranging from 0.6 to 0.8, to avoid exhausting local resources; when the load of other container pools q... At that time, the scheduling center matches the adapted container from the cross-pool schedulable resources, uses the AI ​​adaptation model of S2-1 to complete the cross-pool allocation, and updates the metadata of container pools p and q after allocation, where the schedulable resource amount of container pool p is reduced by the allocation amount, and the used resource amount of container pool q is added to the allocation amount.

[0089] Step S6, personalized failover and service continuity assurance, also includes S6-1 fault prediction and advance backup, specifically: real-time collection of container CPU utilization. Response delay Memory leak rate Indicators for calculating health index:

[0090] in The weighting coefficients are and satisfy the following conditions: , , This is a CPU-intensive identifier; 1 indicates CPU-intensive, and 0 indicates non-CPU-intensive. , This is a memory-intensive identifier; 1 indicates memory-intensive, and 0 indicates non-memory-intensive. ; , , All have been normalized, and the formula is: The value range is 0-1, where These are the original indicator values. The minimum value of the indicator. This is a threshold value; exceeding it will directly indicate a fault.

[0091] The health index uses a "full score deduction" model to highlight the negative impact of abnormal indicators; it also introduces... and Enhance the sensitivity of key indicators, dynamically adjust the weight coefficients according to container type, increase the weight of CPU / memory intensive containers, and adjust the weight of response latency accordingly; normalization ensures that the dimensions of each indicator are consistent, the health index ranges from 0 to 100, when HI is below 60 for 3 consecutive monitoring cycles, create a container instance of the same specification and mark it as STANDBY, and continuously monitor the status of the main container.

[0092] Step S6 further includes S6-2 multi-active container redundancy deployment, specifically: the container instance corresponding to the core app is deployed across nodes, and at least one replica is deployed on each different physical node or virtual node within the same container pool. The replica configuration is completely consistent with the main container. The redundant replica is in STANDBY state by default, only occupying basic resources, with CPU utilization ≤10% and memory usage ≤20%. When the main container triggers the failover process of S6, the redundant replica is immediately activated and switched to ACTIVE state and bound to the app, with an activation response time ≤1 second.

[0093] Step S6 also includes resource self-healing after fault recovery in S6-3, specifically: after the faulty container is replaced, the destruction process of the old container in the INVALID state is started to release CPU, memory and storage resources, and clean up the network configuration and mount directory associated with the container; after self-healing is completed, the status data of the new container is synchronized to the full life cycle status management module of S5, and the status record and associated metadata are updated with a synchronization delay of ≤2 seconds.

[0094] A scheduling-scaling linkage optimization mechanism is established between steps S2 and S4, specifically: the scheduling module in S2 pushes the number of used containers to the scaling module in S4 in real time. app priority data The scaling module dynamically adjusts the expansion threshold based on this data. ,in The base expansion threshold is 0.7 by default. The priority coefficient is 1 for core apps and 0 for ordinary apps. New container instances created by the scaling module are automatically added to the scheduling candidate pool of S2 through the state synchronization interface for matching with the intelligent heterogeneous resources of S2-1, ensuring that scaling resources can quickly participate in scheduling with a synchronization delay of ≤3 seconds.

[0095] A release-initialization collaborative update mechanism is established between step S3 and step S1, specifically: the release module in step S3 feeds back the resource specifications of the returned container to the initialization module in step S1. Release frequency , For the k-th specification, the number of releases. For the allocation count of the k-th specification, the initialization module counts the release frequency of each specification. At that time, the proportion of this specification is adjusted according to the proportioning formula in S1-1. At the same time, the proportion of other low-release-frequency specifications is reduced proportionally to ensure that the total proportion is 1; the optimized proportion parameters are synchronized to the container generation process of S1 to update the specification distribution and quantity of the initial containers.

[0096] A lifecycle-failover state synchronization mechanism is established between steps S5 and S6, specifically: the lifecycle module in S5 pushes container status data to the failover module in S6 through real-time data flow. When the failover module detects a container anomaly, it sends a state change request to S5, marking the failed container's state as INVALID. After the fault is recovered, S6 sends a state rollback request to S5, updating the standby container in the STANDBY state to the ACTIVE state, and S5 records the state change trajectory. , For the initial state time, The current state time is used and synchronized to the metadata database.

[0097] A scheduling-release resource loop optimization mechanism is established between steps S2 and S3, specifically: the scheduling module in S2 records the app resource usage duration data. Associate this data with the container identifier. This feedback is then sent to the release module in S3, which is triggered first. A container that has been in use for a few minutes enters the release process; the release of the container in step S3 is based on the usage duration data and historical scheduling records, and a set of high-frequency apps is statistically analyzed. , For apps that have been used for more than 60 minutes and rank in the top 20% of allocations, the dependency images of these high-frequency apps are preloaded. The preloading process is completed before the container state is switched to FREE, and the preloading time is ≤5 seconds.

[0098] A scaling-lifecycle dynamic adaptation mechanism is established between steps S4 and S5. Specifically, the new container generated by the scaling module in S4 sends a status registration request to the lifecycle module in S5, and its initial status is marked as FREE after verification. When the scaling-down process in S4 is triggered, the container status data in S5 is queried, and FREE-status containers without associated tasks or permission bindings are prioritized for destruction, with the following filtering criteria: , Associating the number of tasks with the container, Bind an identifier to container permissions; the duration for which S5 monitors the container in a FREE state. When the container is not scheduled for an hour, send a scaling-down suggestion to S4, including the container identifier. and specifications This is for S4 to use in scaling down decisions, and a sending cycle of 30 minutes is recommended.

[0099] A failover-scheduling resource reservation linkage mechanism is established between step S6 and step S2, specifically: the failover module in step S6 reserves resources during container pool initialization. The resources are used as backup containers, and the scheduling module of S2 queries the identifier of the reserved resources. When allocating resources, the reserved resources are avoided; after the backup container is used, S6 sends an expansion request to S4, requesting the replenishment of reserved resources. The supplementary container instances are added to the scheduling candidate list through the scheduling candidate pool synchronization process of S2, ensuring that the reserved resources are dynamically replenished and the replenishment completion time is ≤10 seconds.

[0100] In one feasible embodiment, the following real-time steps and examples are also included:

[0101] Deployment components: pool-manager, peaset, scheduler

[0102] Create a pool:

[0103] The administrator initiates the createPool command;

[0104] The pool-manager listens for the createPool command and executes the creation of a cloneset.

[0105] After the cloneset creates and starts the pod, the supervisor performs a health check and sends a heartbeat to the scheduler to report the container status (resource version number).

[0106] The scheduler adds new containers to the container pool's FREE list, awaiting scheduling.

[0107] Launch the app:

[0108] The app update changed the corresponding peasetreplicas from 0 to 3;

[0109] Peaset requests three copies of the container resource from the scheduler device;

[0110] The scheduler allocates three FREE containers from the FREE list of the container pool, updates the status to ACTIVE, and notifies the peaset that the resource allocation was successful.

[0111] Peaset updates the current replica count to 3 and notifies the app that resource allocation was successful;

[0112] The app is running normally.

[0113] Release app:

[0114] The app update changed the corresponding peasetreplicas from 3 to 0;

[0115] peaset releases container resources to the scheduler device;

[0116] The scheduler sets the status of containers to be released to RELEASING, refreshes the container resource version number, and notifies the corresponding container supervisor of the resource version number change and resource release.

[0117] The supervisor initiates the resource recycling process;

[0118] Perform resource reclamation actions, such as restarting or sending signals to the container process;

[0119] Update local resource version numbers;

[0120] Notify the scheduler after completing the resource recycling process;

[0121] When the scheduler receives a notification from the supervisor, it aligns the version number and changes the container status from RELEASING to FREE.

[0122] Container replacement:

[0123] The app detects an anomaly in container A and initiates a process to replace container A with peaset.

[0124] Peaset adds a revision change and executes the revision: it requests 1 replica from the scheduler.

[0125] The scheduler notifies peaset after allocating resources;

[0126] Peaset records the allocated resources in Revison and periodically polls app container A to see if it can be released;

[0127] After the app returns that container A can be released, peaset updates the list of allocated resources, replaces container A with newly allocated resources, and then notifies the app.

[0128] peaset releases container A until successful.

[0129] Example 2

[0130] A Kubernetes-based intelligent container pooling management method—specific to e-commerce platforms in a microservice architecture.

[0131] This embodiment addresses the core requirements of microservice architecture in e-commerce platforms, including high-concurrency resource scheduling, high availability assurance for core services, and dynamic optimization of non-core service resources. It combines solutions such as cross-pool resource scheduling linkage, multi-active redundant deployment, and dynamic hierarchical permission control in the main and sub-methods to achieve intelligent and highly available management of container pooling in e-commerce scenarios. The specific technical implementation process is as follows:

[0132] A container pooling management system dedicated to e-commerce is built on a Kubernetes cluster. This system includes a container pool initialization module, an e-commerce-specific resource scheduling module, a release optimization module, a peak sales promotion elastic scaling module, a lifecycle management module, and a core service failover module. Each module achieves cross-module data interaction and command transmission through RESTful APIs and gRPC interfaces. Specifically, the container pool initialization module optimizes heterogeneous configurations to address the differences in resource requirements between core and non-core e-commerce services; the peak sales promotion elastic scaling module enhances peak load prediction and cross-region container pool linkage; and the core service failover module supports multi-active redundant deployment across availability zones.

[0133] S1. Intelligent initialization of container pools and heterogeneous configuration for e-commerce scenarios

[0134] The container pool initialization module receives configuration parameters from e-commerce platform operations and maintenance personnel via the management console. These parameters include the container pool name (named according to service type), the number of replicas in each container pool, heterogeneous resource specifications (core service container specifications, non-core service container specifications), and image type (core service dedicated image, non-core service general image). Simultaneously, the initialization module extracts container allocation records from the e-commerce platform's historical database for a preset period, filters valid data, and obtains the historical allocation frequency, average usage duration, and average resource utilization rate for each container specification.

[0135] To address the characteristics of e-commerce scenarios, a unique heterogeneous resource intelligent allocation model is constructed. The allocation ratio of resources of various specifications is calculated through a preset formula. The specification adaptation correction coefficient is dynamically adjusted according to the priority of e-commerce services. The coefficient for core transaction services is set to a higher value, while the coefficient for non-core services is set to a lower value, thereby strengthening the priority of resource allocation for core transaction services.

[0136] Based on the calculated allocation ratio and number of replicas, the initial number of containers of each specification is determined. The initialization module calls the relevant Kubernetes APIs to create container instances and configures a unique identifier ID for each container instance, including the service type identifier.

[0137] Based on the dependency characteristics of e-commerce services, high-frequency application dependency images are preloaded. The high-frequency images are selected according to the deployment frequency of e-commerce services within a preset period to ensure that the image retrieval time is shortened in high-concurrency scenarios.

[0138] To achieve secure isolation and hierarchical access control for e-commerce services, the initialization module calls the Kubernetes Namespace API to create an independent namespace for each container pool. Within each namespace, a dedicated e-commerce resource quota is configured. The quota limit for core service container pools is set to the higher value, while the quota limit for non-core service container pools is set to the normal value. Simultaneously, network policies are configured in the core service namespace to allow only access requests from the front-end gateway service, ensuring the security of core data.

[0139] After the container instance is created and configured, the initialization module marks all container states as FREE and enters metadata such as container ID, poolName, service type, specification parameters, namespace name, preloaded image list, creation time, and specification adaptation correction coefficient value into the e-commerce dedicated container pool metadata database to support high-concurrency access.

[0140] S2, E-commerce-specific intelligent resource scheduling and hierarchical security isolation allocation

[0141] Each microservice on the e-commerce platform initiates resource requests through the system's dedicated e-commerce API. Request data includes poolName, service type, required CPU cores, required memory size, target image type, unique service identifier, and security level (core security level and general security level). Upon receiving the request data, the e-commerce-specific resource scheduling module first performs an e-commerce-specific validity check. This check verifies whether the poolName matches the service type, whether the resource specifications corresponding to the security level conform to preset rules, and whether the request time falls within a specific business period, including various promotional periods. If the check passes, it filters container instances with a FREE status, compatible image type, and matching service type from the container pool metadata database, forming a candidate container list.

[0142] The candidate container list and service resource application data are input into the e-commerce-specific AI adaptation model. A multi-dimensional non-linear priority ranking algorithm is used to calculate the matching weight of each candidate container. The dynamic adjustment factor in the formula is dynamically adjusted according to the service type. Core services are given a stronger weight for image compatibility and memory matching, while non-core services are given a stronger weight for CPU load and idle time. The historical average of container CPU utilization is also considered, with longer period data for core services and regular period data for non-core services. For memory matching, a higher matching threshold is used for core services and a regular matching threshold is used for non-core services. For image compatibility coefficient, core services must meet dependency integrity. The normalized value of idle time is given a higher weight during specific business periods.

[0143] When incompatibility between images during a specific business period causes the matching failure rate to exceed a preset value, the dynamic adjustment factor corresponding to the core service is automatically optimized to ensure that the matching success rate of the core service meets the preset requirements. The resource scheduling module sorts the candidate container list in descending order according to the matching weight. When a core service requests a container, it selects the containers with the highest weights as candidates. When a non-core service requests a container, it selects the container with the highest weight as the target container.

[0144] After matching is complete, the scheduling module calls the relevant Kubernetes API to associate and bind the target container with the service identifier, and simultaneously sends a permission configuration request to the e-commerce-specific permission management submodule. The permission management submodule implements tiered permission control based on the e-commerce service security level: the permission set for core security level services includes core operation permissions and limited data access permissions, while the permission set for ordinary security level services includes basic operation permissions and regular data access permissions, prohibiting access to core service-related data and directories. Permission configuration is implemented through Kubernetes Role, RoleBinding, and ServiceAccount. The ServiceAccount for core services is associated with a preset high-privilege role, and the ServiceAccount for ordinary services is associated with a preset regular-privilege role. The access token validity period is set according to preset rules and automatically refreshed.

[0145] After the permission configuration is completed, the scheduling module updates the target container's status to ACTIVE, synchronously updates the relevant fields in the container pool metadata database, and pushes the container connection information to the e-commerce service registry through a message queue. The service registry then synchronizes this information to the corresponding microservice, which uses the connection information to deploy business services and process user requests.

[0146] S3, Intelligent Release of Container Resources and Optimization for Major Sales Events in E-commerce Scenarios

[0147] When the e-commerce microservice completes its business task or ends a specific business period, it sends a resource release request to the release optimization module via an e-commerce-specific API. The request data includes the service identifier, container ID, release type (including normal release or release after a specific period), and task completion status. After receiving the request, the release optimization module performs e-commerce-specific release verification, verifying whether the service identifier and container binding are consistent, whether the core service release occurs during a non-peak business period, and whether critical data has been backed up for release after a specific period. Once the verification passes, the resource release process is triggered.

[0148] The release optimization module calls the relevant Kubernetes APIs to mark the container status as RELEASING and performs differentiated release operations based on the characteristics of the e-commerce service: core service containers execute a graceful release process, first stopping accepting new requests and waiting for the current transaction request to complete; non-core service containers execute a fast release process, directly terminating the business process. Simultaneously, the permission management submodule is notified to reclaim the container's permission set, delete the corresponding RoleBinding and ServiceAccount, and refresh the access token to invalidate it.

[0149] After resource release, the container status is updated from RELEASING to FREE and returned to the container pool. Preloading strategies are optimized for specific business scenarios: core service containers used frequently during specific business periods preload dedicated dependency images, while non-core service containers preload daily operational dependency images. A differentiated network strategy is used during the preloading process: core service containers use parallel fetching, while non-core service containers use asynchronous background fetching.

[0150] The release optimization module feeds back data such as the container's resource specifications, release frequency, release type, and service type to the container pool initialization module. Container data released after a specific period is separately marked for subsequent resource allocation optimization in specific business scenarios. Simultaneously, the release optimization module synchronizes release records to the e-commerce platform's operation log database for operational analysis and troubleshooting.

[0151] S4, Dynamic Elastic Scaling and Cross-Regional Pool Linkage for E-commerce Promotions

[0152] The e-commerce-specific elastic scaling module for major promotional events uses Kubernetes' metrics-server in conjunction with the e-commerce platform's monitoring system to collect container pool load data at preset intervals. The collected data includes: the number of containers in use, total CPU utilization, total memory usage, requests per second (QPS), and transaction success rate. Based on this data, a container pool load value specifically for e-commerce scenarios is calculated, incorporating QPS and transaction success rate metrics to ensure the load value accurately reflects the operational status of e-commerce businesses.

[0153] The time-series load data, including the load values ​​at the current moment and a preset number of historical moments, is input into a dedicated LSTM resource demand prediction model for major promotional events. This model incorporates a feature engineering module for specific business periods. Input features include whether it is a specific business period and historical load data for the same period in the past. The output is a load prediction value for a preset duration in the future, with the prediction duration extended for specific business periods to reserve resources in advance. The model training objective is to minimize the weighted prediction error, with the time decay coefficient taking a higher value for specific business periods. The training samples include historical load data for specific business periods and daily load data to ensure that the model has good prediction accuracy in different scenarios.

[0154] The elastic scaling module for major sales events triggers differentiated scaling strategies based on predicted load values ​​and e-commerce scenario-specific thresholds:

[0155] Large-scale expansion: When the predicted load value exceeds the expansion threshold, i.e., the core service container pool threshold is set to a lower value and the non-core service container pool threshold is set to a normal value, the expansion quantity is calculated. The expansion redundancy coefficient is dynamically adjusted according to the specific business period stage. Different coefficients are used before, on, and after the specific business. When expanding, core service containers are created first. If the local container pool resources are insufficient, cross-regional container pool linkage is triggered. Load data of container pools in multiple regions are collected, the proportion of idle resources in each region is calculated, and cross-regional schedulable resources are synchronized to the e-commerce resource scheduling center. The core service container pool matches cross-regional available containers through the scheduling center and uses the e-commerce-specific AI adaptation model of S2 to complete cross-regional allocation.

[0156] Massive promotion scaling down: When the predicted load value is lower than the scaling down threshold, i.e., the threshold for the core service container pool is taken as a higher value, and the threshold for the non-core service container pool is taken as a normal value, the scaling down quantity is calculated. The scaling down safety factor is taken as a higher value during the specific business period. When scaling down, containers temporarily expanded during the specific business period are destroyed first. The scaling down of core service containers is only performed after the specific business period ends, and the number of scaling down each time does not exceed the preset proportion of the total capacity.

[0157] During cross-regional container pool collaboration, data is transmitted through a dedicated high-speed network channel for e-commerce, with latency controlled within a preset range. Container instances allocated across regions are automatically added to the scheduling candidate list of the local container pool, and business requests are intelligently routed to the nearest container instance to ensure minimal user access latency.

[0158] S5, E-commerce Service Container Full Lifecycle Status Management

[0159] The lifecycle management module expands the container state set to suit the characteristics of e-commerce services, adding a PROMOTION state specific to a particular business period. This state is used to mark containers that are temporarily expanded during a specific business period. The state transition rules are supplemented with specific rules for the specific business period on the basis of the basic rules, prohibiting containers specific to the specific business period from participating in daily scheduling.

[0160] The lifecycle management module monitors Kubernetes Pod events and e-commerce service registry status change notifications to obtain container status update requests in real time. It then verifies the legitimacy of the changes using an e-commerce-specific status verification submodule. This submodule incorporates an e-commerce service status rule library, including scenario-based rules such as release restrictions during peak core service periods and container status change restrictions during specific business periods. If verification passes, the status update is executed; otherwise, an e-commerce-specific error code is returned and pushed to the operations and maintenance alarm system.

[0161] Container state data is persistently stored in a master-slave database. Core service containers use multi-replica storage and cross-region backup for their state data, while non-core service containers use dual-replica storage. A gRPC interface provides state query services to various e-commerce modules. Query requests from core services have higher priority than those from non-core services, and the interface response time meets the preset requirements for different services. Simultaneously, the lifecycle management module periodically inspects container states. Core services have shorter inspection cycles, while non-core services have longer cycles. If a container dedicated to a specific business period is not released within a preset timeframe after the period ends, a cleanup process is automatically triggered. If the transaction success rate of an ACTIVE core service container falls below a preset value, it is marked as INVALID, and the failover module is notified.

[0162] In addition, the lifecycle management module records the entire lifecycle trajectory of the e-commerce service container. The trajectory data includes e-commerce-specific fields such as specific business time period markers, cross-regional markers, and changes in transaction success rate. It is stored in the e-commerce audit log database, and the retention time meets e-commerce compliance requirements.

[0163] S6, Personalized Failover and Active-Active Support for Core E-commerce Services

[0164] The core service failover module addresses the high availability requirements of e-commerce core services by employing a full-process fault handling mechanism of "real-time monitoring - advance backup - cross-availability zone switching - resource self-healing," specifically implemented as follows:

[0165] The monitoring system, in conjunction with an e-commerce-specific monitoring plugin, collects operational metrics for core service containers at preset intervals. These metrics include CPU utilization, response latency, memory leak rate, transaction success rate, and database connection count. After collection, the metrics undergo e-commerce-specific normalization. The preset thresholds for core service metrics are more stringent; exceeding these thresholds results in an immediate fault assessment.

[0166] The core service container health index is calculated based on normalized indicators. The formula adds transaction success rate weight and database connection number weight. The values ​​of each weight highlight the impact of transaction success rate on the health status of core services, which is in line with the operating characteristics of e-commerce core services.

[0167] The core service failover module executes a three-level fault handling strategy based on health indices:

[0168] Level 1 warning, health index in the first range of 60-80: The container is determined to be in a sub-healthy state, triggering the early backup process. Create a container instance of the same specifications in another availability zone and mark it as STANDBY. Preload the core service dependency images and encrypted configurations, associate it with the service identifier of the original container, and set the STANDBY container as a "standby node" through the e-commerce service registry center to synchronize the business data of the original container in real time.

[0169] Level 2 fault, health index in the second range of 40-60: The container is judged to be in a minor fault state, triggering a traffic switching process. User requests from the container are gradually diverted to the STANDBY container through the e-commerce gateway, with the diversion ratio gradually increasing. At the same time, the load and transaction success rate of the STANDBY container are monitored. After the diversion is completed, the original faulty container is marked as INVALID and the repair process is executed. If the repair is successful, it is switched to the STANDBY state. If the repair fails, the destruction process is triggered.

[0170] Level 3 Fault: Health index below the second range or container crash: The container is determined to be in a critical fault state, triggering an immediate switchover process. The e-commerce gateway immediately cuts off all requests to the original faulty container and routes all traffic to the STANDBY container. At the same time, it notifies the resource scheduling module to urgently create a new STANDBY container to supplement backup resources. The original faulty container is marked as INVALID and then performs a deep cleanup process, deleting temporary transaction data, cleaning up database connections, revoking permission configurations, and destroying the container after the cleanup is completed.

[0171] For core e-commerce services, the failover module also supports cross-availability zone multi-active redundancy deployment: Container instances of core services are deployed with at least one replica in each of multiple availability zones. The replica containers are configured identically to the primary container and are in STANDBY state by default. Business data is synchronized in real time through a dedicated e-commerce data synchronization component, with data synchronization latency meeting preset requirements. When the primary availability zone container pool fails entirely, the failover module quickly activates the STANDBY container in the backup availability zone, and the e-commerce gateway automatically switches routing rules to ensure the availability of core services meets preset standards.

[0172] After the failover is completed, the e-commerce-specific resource self-healing process is triggered: the failover module notifies the release optimization module to clean up the residual resources of the INVALID container, notifies the lifecycle management module to update the container status trajectory and metadata, and notifies the e-commerce operation platform to record the fault information for fault root cause analysis and service optimization.

[0173] E-commerce scenario module interaction and data flow

[0174] Each module achieves deep collaboration based on the characteristics of e-commerce business, and the core interaction process is as follows:

[0175] After the container pool initialization module completes S1, it synchronizes the heterogeneous configuration data and metadata of each container pool to the e-commerce dedicated resource scheduling module, the large-scale promotion elastic scaling module, and the lifecycle management module respectively. The metadata of core services is marked as "high priority" and synchronized first.

[0176] When the e-commerce dedicated resource scheduling module executes S2, it queries the container status from the lifecycle management module, obtains the service security level from the e-commerce service registry, and pushes the binding information of the core service container to the core service failover module after execution.

[0177] When the release optimization module executes S3, it verifies the transaction completion status of the core service from the e-commerce platform database. After execution, it feeds back the type of resources released to the big promotion elastic scaling module to provide a basis for scaling decisions.

[0178] When the elastic scaling module executes S4 during a major promotion, it obtains QPS and transaction success rate data from the e-commerce platform monitoring system, queries cross-regional container pool resources from the resource scheduling center, and synchronizes resource allocation optimization suggestions for specific business periods to the container pool initialization module after scaling up / down.

[0179] The lifecycle management module receives status update requests from each module in real time. Status changes of core services are handled first. In case of abnormal status, the core service failover module is triggered immediately, and alarm information is pushed to the e-commerce operation and maintenance platform.

[0180] When the core service failover module executes S6, it collects core metrics from the e-commerce-specific monitoring plugin, obtains traffic routing rules from the e-commerce gateway, and synchronizes the fault handling results to the e-commerce operation platform after the switch is executed for business review.

[0181] This invention also provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements a high-efficiency container resource pool management device based on Kubernetes as described in the above embodiments.

[0182] The computer-readable storage medium can be an internal storage unit of any data processing device as described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device of any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of any data processing device. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0183] It should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for efficient container resource pool management based on Kubernetes, characterized in that, Includes the following steps: S1: Includes an initialization module, which obtains configuration parameters, performs resource allocation based on historical data, builds an allocation model, generates idle containers, preloads high-frequency dependencies, creates a namespace to complete isolation initialization, and enters metadata. S2: Includes a scheduling module that accepts resource requests from apps, matches idle containers using an adaptation model, binds the app and grants the minimum permissions according to a preset, updates the container status to allocated, and records the binding relationship. S3: Includes a release module, which verifies the app's release request. If valid, it changes the container state from the release state to the idle state, reclaims the app's permissions, preloads high-frequency dependencies, and synchronizes them to metadata. S4: Includes a scaling module, which collects pool load data, predicts load conditions using an LSTM model, executes scaling up and down strategies based on app priority, and synchronizes instance count and status. S5 includes a lifecycle management module that defines the multi-state transition rules of containers, monitors and verifies the legality of changes in real time, intercepts illegal changes, persists state data and provides query services; it also includes a state synchronization mechanism that pushes container state data to the failover module of S6 in real time. S6: Includes a failover module, which acquires container status data, changes the container status, and synchronously feeds it back to the lifecycle management module; monitors the health status of containers in real time, marks them as invalid when abnormal according to presets, requests a new container, requests the release of the old container from the app, and cleans up residual resources; The S2 and S3 include a resource scheduling and release cycle optimization mechanism. The scheduling module records the app resource usage duration data and associates it with the container identifier ID, and feeds it back to the release module. The release module sorts the containers into the release process according to the resource usage duration of the containers. The released containers are based on the resource usage duration data and historical scheduling records. Before the container state changes to the idle state, the dependency images of high-frequency apps are counted and preloaded.

2. The efficient container resource pool management method based on Kubernetes according to claim 1, characterized in that, S1 includes intelligent initialization and heterogeneous configuration of container pools, including intelligent allocation of heterogeneous resources, which includes: allocating resources based on historical allocation data, constructing an allocation model, and determining the initial allocation of resources for each specification by combining the historical allocation frequency of containers of each specification, average usage time, and average resource utilization rate of each specification.

3. The efficient container resource pool management method based on Kubernetes according to claim 1, characterized in that, S2 includes intelligent resource scheduling and secure isolation allocation, which includes the following sub-steps: S21: Intelligent Heterogeneous Resource Matching: Construct an AI adaptation model, input app resource requirements, container specifications and historical matching data, use a multi-dimensional non-linear priority sorting algorithm to calculate container matching weights, and filter out suitable idle containers based on the weights. S22: Container security isolation: Implement container isolation within the pool based on the namespace created during the container pool initialization phase, configure dynamic resource quota management, and adjust the isolation threshold according to the importance level of the app; S23: Dynamic permission control: When the container is bound to the app, the minimum set of permissions is automatically granted according to the app's functional requirements; when the container is released, the permission revocation process is triggered based on the release request of S3, all granted permissions are revoked and permission change logs are recorded.

4. The efficient container resource pool management method based on Kubernetes according to claim 1, characterized in that, The S2 and S4 include a linkage optimization mechanism for scheduling and scaling, including: the scheduling module pushes the number of used containers and app priority data to the scaling module, and the scaling module dynamically adjusts the expansion threshold; new container instances created by the scaling module are automatically added to the scheduling candidate pool through the state synchronization interface and enter S2.

5. The efficient container resource pool management method based on Kubernetes according to claim 1, characterized in that, The S3 and S1 include a collaborative update mechanism for release and initialization, which includes: feeding back the resource specifications and release frequency of the returned container to the initialization module; and adjusting the allocation ratio of the resource specification when the release frequency of a container of a certain specification reaches a preset threshold.

6. A method for efficient container resource pool management based on Kubernetes according to claim 1 or 3, characterized in that, S4 includes the following processing steps: S41: AI Resource Demand Prediction: Using a pre-set LSTM model, input time series load data, output predicted load for future time moments, and train to minimize weighted prediction error; S42: Differentiated scaling strategy: A core app identifier list is preset. When expanding, container specification instances corresponding to the apps in the list are created first. The expansion quantity is determined by the total capacity of the container pool and the preset expansion redundancy coefficient. When shrinking, idle containers corresponding to non-core apps are destroyed first. The containers are destroyed in order of idle time and the number of containers destroyed is determined by the preset shrinkage safety coefficient. S43: Cross-pool resource scheduling linkage: Collect load data from several container pools. When the idle resource ratio of a container pool meets the preset conditions, mark the redundant resources of the container pool as cross-pool schedulable and synchronize them to the resource scheduling center. When the load of other container pools reaches the preset load threshold, the resource scheduling center matches suitable containers from the cross-pool schedulable resources, performs cross-pool allocation according to the allocation strategy in S2, and updates the metadata of the relevant container pools synchronously.

7. The efficient container resource pool management method based on Kubernetes according to claim 1, characterized in that, S6 includes the following processing steps: S61: Fault prediction and early backup: Real-time collection of container health indicators, calculation of container health index based on preset weight coefficients, and creation of container instance of the same specification when the health index meets preset conditions and marking it as standby status, and continuous monitoring of the main container status. S62: Multi-active container redundancy deployment: For container instances corresponding to the core app, deploy at least one redundant replica on different physical or virtual nodes in the same container pool. The replica configuration is completely consistent with the main container. The redundant replica is in standby state by default and only occupies basic resources. When the main container fails and triggers the failover process, the redundant replica is activated and converted to an allocated state and bound to the app. S63: Resource self-healing after fault recovery: After the faulty container is replaced, the destruction process of the old container in an invalid state is initiated to release the resources it occupies and clean up the network configuration and mount directory associated with the container; after self-healing is completed, the status data of the new container is synchronized to the full lifecycle status management module to update the status data and associated metadata.

8. The efficient container resource pool management method based on Kubernetes according to claim 1, characterized in that, The S6 and S2 include a failover and scheduling resource reservation linkage mechanism, which includes: the failover module reserves preset resources as backup containers when the container pool is initialized, and the scheduling module avoids the reserved backup containers when allocating; when the backup containers are used, an expansion request is sent to supplement new reserved resources, and the supplemented container instances are added to the scheduling candidate pool of S2 to ensure that the reserved resources are dynamically replenished.

9. A high-efficiency container resource pool management device based on Kubernetes, applying the high-efficiency container resource pool management method based on Kubernetes as described in claims 1-8, characterized in that, include: Container pool initialization module: used to execute the container pool initialization operation of S1, realize heterogeneous resource allocation, container creation, preloading and metadata management; Resource scheduling module: used to perform the resource scheduling and allocation operations of S2, including adaptation model matching, permission granting and status updating; Release optimization module: used to perform the resource release optimization operation of S3, including release verification, state transition and dependency preloading; Elastic scaling module: used to perform the dynamic elastic scaling operation of S4, including load acquisition, prediction and scaling strategy execution; Lifecycle management module: used to perform the full lifecycle management operations of the S5, including state definition, verification, persistence and inspection; Failover module: Used to perform the failover processing operations of S6, including health monitoring, backup creation, fault switching and resource self-healing; Module collaboration unit: used to realize data interaction and linkage between various modules.

Images