A containerized resource elastic scheduling method and system in a cloud computing environment

Abstract

This application provides a method and system for elastic scheduling of containerized resources in a cloud computing environment, relating to the field of elastic scheduling technology for containerized resources. This application generates detailed data recording the resource competition relationships between tenants by acquiring various resource contention events; identifies preset high-frequency conflict patterns through in-depth data analysis, determining specific tenant groups with strong resource mutual exclusion effects; dynamically estimates the probability level of resource conflicts between new containers and specific tenant groups by combining historical contention information and real-time resource load status; generates a dynamic isolation scheduling strategy based on the conflict risk indicated by the probability level; and configures and adjusts independent conflict buffer resource pools for designated key tenants. This enables the identification of tenant resource conflict patterns and the implementation of dynamic isolation scheduling and buffer resource configuration, improving the resource utilization efficiency and system stability of multi-tenant containers in a cloud computing environment.

Description

Technical Field

[0001] This application relates to the field of containerized resource elastic scheduling technology, and in particular to a containerized resource elastic scheduling method and system in a cloud computing environment. Background Technology

[0002] In today's cloud computing environment, with the widespread adoption of containerization technology, multi-tenant shared infrastructure has become the norm. When container workloads from different tenants share physical resources, they are highly susceptible to interference due to resource contention, leading to performance fluctuations, service quality degradation, and even business interruptions. Therefore, how to efficiently and stably manage and schedule these containerized resources, ensure service performance isolation for each tenant, and maximize resource utilization is a key technical challenge for cloud computing platforms and an urgent need to improve user experience and operational efficiency.

[0003] To address the aforementioned technical requirements, existing solutions generally employ scheduling strategies based on resource quotas and static isolation. For example, some platforms define fixed resource boundaries for each tenant or container through preset resource limits and attempt to deploy containers from different tenants onto different physical nodes or virtual machines to achieve physical-level isolation. This approach aims to avoid resource conflicts at the source, ensuring that each tenant has its own dedicated resource share and guaranteeing its service performance.

[0004] However, this static isolation and fixed quota approach has significant drawbacks. First, due to the dynamic and unpredictable nature of workloads, static resource quotas often fail to accurately match actual demand. This leads to a situation where resource allocation is too conservative, resulting in a large amount of idle resources, while insufficient allocation fails to meet sudden peak demand, resulting in low resource utilization. Second, complete physical isolation is costly and difficult to achieve in large multi-tenant environments, and in most cases, some resources still need to be shared. In this shared model, static isolation cannot effectively cope with fine-grained, transient resource contention, especially when multiple tenants simultaneously request the same scarce resource, which can still cause severe performance interference, affecting service stability. Furthermore, it is difficult to dynamically adjust to adapt to constantly changing business needs and resource competition. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for elastic scheduling of containerized resources in a cloud computing environment, so as to solve the problems of insufficient resource utilization efficiency and system stability of multi-tenant containers in the existing cloud computing environment.

[0006] To address the aforementioned technical problems, firstly, this application provides a method for elastic scheduling of containerized resources in a cloud computing environment, comprising:

[0007] The system acquires resource contention events between tenant containers in a cloud computing environment, including CPU preemption, memory access conflicts, and network bandwidth contention, and generates relational data that records the resource contention relationships between tenants based on these resource contention events.

[0008] The relationship data is analyzed to identify preset high-frequency conflict patterns, and based on the high-frequency conflict patterns, specific tenant groups with strong resource mutual exclusion effects are identified. The high-frequency conflict patterns are tenant combinations that frequently compete for resources under specific loads.

[0009] By combining historical contention information obtained from the relational data with the real-time resource load status of the current environment, a probability level of resource conflict with the specific tenant group is dynamically estimated for the new container to be deployed.

[0010] Based on the conflict risk indicated by the probability level, a dynamic isolation scheduling strategy is generated, which distributes containers with high conflict risk into independent physical resource domains.

[0011] While executing the dynamic isolation scheduling strategy, an independent conflict buffer resource pool is configured for the designated key tenant, and the reserved capacity of the conflict buffer resource pool is dynamically adjusted according to the real-time operating needs of the key tenant.

[0012] Optionally, the analysis of the relational data to identify preset high-frequency conflict patterns, and based on these high-frequency conflict patterns, determining specific tenant groups with strong resource mutual exclusion effects, wherein the high-frequency conflict patterns are tenant combinations that frequently engage in resource contention under specific loads, including:

[0013] The relational data is decomposed according to resource type to form multiple independent competition sequences. Each competition sequence is divided according to a preset time window to obtain a series of resource competition segments based on time.

[0014] Within each resource contention segment, the frequency of concurrent conflicts for different tenant combinations is statistically analyzed. Tenant combinations whose frequency exceeds a preset threshold are selected as candidate conflict units, and a corresponding resource contention intensity is calculated for each candidate conflict unit.

[0015] Aggregate all candidate conflict units that repeatedly appear within a continuous time window, and weight and accumulate the resource contention intensity among the aggregated candidate conflict units to quantify the long-term mutual exclusion relationship between different tenants. Then, select the combination with the highest mutual exclusion relationship to construct a specific tenant group.

[0016] Optionally, based on the conflict risk indicated by the probability level, a dynamic isolation scheduling strategy is generated. This dynamic isolation scheduling strategy distributes containers with high conflict risk across independent physical resource domains, including:

[0017] Using topology information as an index, all available physical resource domains in the cloud computing environment are first obtained, and each physical resource domain is labeled to indicate the tenant container currently being carried and the specific tenant group to which the tenant container belongs.

[0018] When deploying the new container, all physical resource domains are divided into preferred deployment domains, alternative deployment domains, and risky deployment domains based on the probability level. The risky deployment domains specifically refer to physical resource domains that have already hosted specific tenant groups with a high risk of conflict with the new container.

[0019] After excluding the risky deployment domains, the target deployment domain is selected from the remaining preferred deployment domains and the alternative deployment domains by further evaluating the remaining resource reserves and the balance of resource allocation in each domain, and a dynamic isolation scheduling strategy is generated based on the target deployment domain.

[0020] Optionally, the step of combining historical contention information obtained from the relational data with the real-time resource load status of the current environment to dynamically estimate a probability level of resource conflict with the specific tenant group for the planned deployment of new containers includes:

[0021] An initial resource profile is constructed based on the resource declaration of the new container. At the same time, historical conflict records that match the initial resource profile are retrieved from the relational data. The historical conflict records contain the specific load conditions when the conflict occurred.

[0022] The current activity characteristics of the specific tenant group are compared with the specific load conditions recorded in the historical conflict records to find the historical conflict scenario that is closest to the current operating state, and the conflict result corresponding to the historical conflict scenario is obtained.

[0023] By comprehensively considering the initial resource profile of the new container and the conflict results, and introducing the real-time resource load status of the current environment as a dynamic correction factor, a probability level is generated.

[0024] Optionally, while executing the dynamic isolation scheduling strategy, configuring an independent conflict buffer resource pool for a designated critical tenant, and dynamically adjusting the reserved capacity of the conflict buffer resource pool according to the real-time operational needs of the critical tenant, includes:

[0025] According to the relevant agreement on service level, a designated key tenant is identified from all tenants, and a conflict buffer resource pool in an initial state is configured in the physical resource domain where the key tenant is located, with reference to the peak value of the historical resource usage of the key tenant.

[0026] During system operation, the actual resource consumption rate of the critical tenant is continuously monitored, and the frequency and duration of resource contention events between the critical tenant and other tenant containers are recorded simultaneously.

[0027] The actual resource consumption rate is comprehensively evaluated in conjunction with the frequency and duration. If the evaluation result exceeds a preset stability threshold, the reserved capacity of the conflict buffer resource pool is increased and adjusted.

[0028] Optionally, within each resource contention segment, the frequency of concurrent conflicts for different tenant combinations is statistically analyzed, and tenant combinations with frequencies exceeding a preset threshold are selected as candidate conflict units. A corresponding resource contention intensity is calculated for each candidate conflict unit, including:

[0029] Iterate through each contention event recorded within the resource contention segment, extract and initiate the tenant identity identifier of the conflict, and accumulate the number of times the tenant identity identifiers appear together in the same time window in the form of tenant pairs to form a raw statistical data of concurrent conflict frequency.

[0030] The raw statistical data is compared with a preset threshold. Any tenant combination whose conflict frequency exceeds the preset threshold is identified as a candidate conflict unit. At the same time, an initial weight is assigned to each candidate conflict unit based on the duration of the contention event and the type of resource involved.

[0031] The concurrent conflict frequency of the candidate conflict unit is multiplied by the corresponding initial weight to obtain a quantitative value that can characterize the intensity of the conflict. This quantitative value is used as the resource competition intensity.

[0032] Optionally, after excluding the risky deployment domains, the step of selecting a target deployment domain from the remaining preferred and alternative deployment domains by further evaluating the remaining resource reserves and resource allocation balance of each domain, and generating a dynamic isolation scheduling strategy based on the target deployment domain, includes:

[0033] For the preferred deployment domain and the alternative deployment domain, the current total load and total capacity in multiple dimensions such as central processing unit, memory and network bandwidth are statistically analyzed. The remaining resource margin is quantified by calculating the difference between the current total load and total capacity values.

[0034] Within each domain, the load distribution among the subordinate physical nodes is examined. By calculating the degree of dispersion of the load distribution of each node, the balance of resource allocation is specifically measured. A lower degree of dispersion indicates a better balance.

[0035] Different evaluation weights are assigned to the remaining resource margin and the balance degree, and they are weighted and combined to form a deployment adaptation score. The domain with the highest deployment adaptation score is taken as the target deployment domain, and a dynamic isolation scheduling strategy is generated based on the target deployment domain.

[0036] Secondly, this application provides a containerized resource elastic scheduling system in a cloud computing environment, comprising:

[0037] The acquisition module is used to acquire resource contention events between tenant containers in the cloud computing environment. The resource contention events include CPU preemption, memory access conflicts and network bandwidth competition. Based on the resource contention events, relational data that records the resource competition relationship between tenants is generated.

[0038] The analysis module is used to analyze the relationship data to identify preset high-frequency conflict patterns, and based on the high-frequency conflict patterns, to determine specific tenant groups with strong resource mutual exclusion effects. The high-frequency conflict patterns are tenant combinations that frequently compete for resources under specific loads.

[0039] The estimation module is used to combine historical contention information obtained from the relational data with the real-time resource load status of the current environment to dynamically estimate a probability level of resource conflict with the specific tenant group for the new container to be deployed.

[0040] The generation module is used to generate a set of dynamic isolation scheduling strategies based on the conflict risk indicated by the probability level. The dynamic isolation scheduling strategies will distribute containers with high conflict risk in independent physical resource domains.

[0041] The configuration module is used to configure an independent conflict buffer resource pool for a designated critical tenant while executing the dynamic isolation scheduling strategy, and to dynamically adjust the reserved capacity of the conflict buffer resource pool according to the real-time operating needs of the critical tenant.

[0042] Thirdly, this application provides an electronic device, comprising:

[0043] Memory, used to store computer programs;

[0044] A processor, configured to execute the computer program, implements the steps of a containerized resource elastic scheduling method in a cloud computing environment as described in the first aspect above.

[0045] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps of a containerized resource elastic scheduling method in a cloud computing environment as described in the first aspect above.

[0046] The containerized resource elastic scheduling method provided in this application acquires resource contention events between tenant containers in the cloud computing environment. These resource contention events include CPU preemption, memory access conflicts, and network bandwidth competition. Based on these events, relational data recording the resource competition relationships between tenants is generated. This method can acquire and record various resource contention events between tenant containers in real time, constructing a dynamic dataset that comprehensively reflects the resource competition relationships between tenants, providing a data foundation for subsequent analysis. By analyzing the relational data, preset high-frequency conflict patterns are identified. Based on these high-frequency conflict patterns, specific tenant groups with strong resource mutual exclusion effects are determined. The high-frequency conflict patterns are tenant combinations that frequently engage in resource competition under specific loads. The method can analyze the relational data to identify high-frequency conflict patterns and determine strongly mutually exclusive tenant groups, accurately locating resource competition hotspots and providing key basis for scheduling decisions. By combining historical contention information obtained from the relational data with the real-time resource load status of the current environment, it provides... The system dynamically estimates the probability level of resource conflicts that new containers planned for deployment may have with a specific tenant group. By combining historical contention information and real-time load data, it estimates the probability of new container conflicts, enabling proactive prediction of potential resource conflicts and enhancing the predictability of the scheduling system. Based on the conflict risk indicated by the probability level, a dynamic isolation scheduling strategy is generated. This strategy distributes containers with high conflict risk across independent physical resource domains, effectively reducing resource interference between tenants and improving overall system stability. Furthermore, by configuring an independent conflict buffer resource pool for designated critical tenants while executing the dynamic isolation scheduling strategy, and dynamically adjusting the reserved capacity of the conflict buffer resource pool according to the real-time operational needs of the critical tenants, a dynamically adjustable conflict buffer resource pool can be configured for critical tenants. This ensures the quality of service for critical businesses and enhances the system's ability to handle sudden load increases.

[0047] Furthermore, the relationship data is first decomposed into multiple competition sequences according to resource type, and then segmented into resource competition segments according to time windows. Within each segment, the frequency of concurrent conflicts among tenant combinations is counted, high-frequency conflict units are selected, and their competition intensity is calculated. Finally, repeatedly occurring conflict units within continuous time windows are aggregated, and long-term mutual exclusion relationships are quantified through weighted accumulation to construct specific tenant groups. This method, through multi-dimensional and fine-grained resource competition analysis, can accurately identify tenant combinations with long-term resource mutual exclusion relationships, providing precise target groups for dynamic isolation scheduling. It effectively reduces the frequency and intensity of resource conflicts among multiple tenants in cloud computing environments, significantly improving resource utilization and system stability. Attached Figure Description

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

[0049] Figure 1 A flowchart illustrating a containerized resource elastic scheduling method in a cloud computing environment, provided as an embodiment of this application;

[0050] Figure 2 This is a schematic diagram of the structure of a containerized resource elastic scheduling system in a cloud computing environment, provided as an embodiment of this application. Detailed Implementation

[0051] Existing scheduling strategies based on static resource quotas and physical isolation exhibit significant limitations when facing the dynamic nature of containerized workloads and the complexity of multi-tenant shared resources in cloud computing environments. Their inherent rigidity leads to low resource utilization and an inability to effectively handle sudden resource contention. Especially when multiple tenant containers share underlying physical resources, performance interference is unavoidable, severely impacting service stability and user experience. Therefore, an innovative method is urgently needed that can dynamically adapt to resource contention and achieve fine-grained isolation and efficient scheduling.

[0052] To address the aforementioned challenges, this application proposes a containerized resource elastic scheduling method in a cloud computing environment. This method constructs a dynamic competition relationship graph by real-time monitoring and analysis of resource contention events among tenants, accurately identifying high-frequency conflict patterns and strongly exclusive tenant groups. Based on this, the method dynamically estimates the conflict probability of new containers by combining historical data and real-time load, and generates an intelligent dynamic isolation scheduling strategy accordingly, distributing high-risk containers across different locations. Simultaneously, it configures and dynamically adjusts conflict buffer resource pools for critical tenants to cope with instantaneous resource contention. This method abandons the traditional static allocation model, fundamentally solving the problems of low resource utilization, severe performance interference, and lack of elastic adaptability in existing technologies through deep insight and dynamic response to resource contention, significantly improving resource scheduling efficiency, system stability, and service quality in multi-tenant cloud computing platforms.

[0053] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] The core of this application is to provide a method for elastic scheduling of containerized resources in a cloud computing environment, and a flowchart of one specific implementation is shown below. Figure 1 As shown, the method includes:

[0055] S101. Obtain resource contention events between tenant containers in the cloud computing environment. The resource contention events include CPU preemption, memory access conflict and network bandwidth competition. Based on the resource contention events, generate relationship data that records the resource competition relationship between tenants.

[0056] In the above scheme, the cloud computing environment refers to a virtualized platform that provides computing resources, storage space, and application services over a network. A tenant container refers to a lightweight, isolated application execution unit deployed and run by different users or organizations within the cloud computing environment. Resource contention events refer to performance interference that occurs when multiple tenant containers simultaneously attempt to use limited computing resources. Specifically, this includes CPU preemption (one container is forcibly interrupted by another while using the processor); memory access conflicts (multiple containers simultaneously reading and writing to the same memory region or competing for memory bandwidth); and network bandwidth contention (multiple containers simultaneously transmitting data, causing a decrease in network transmission speed). Relationship data refers to a structured record formed by collecting and analyzing these resource contention events, clearly demonstrating the mutual influence and competitive relationships between different tenant containers in resource usage.

[0057] In this embodiment, firstly, the system continuously acquires real-time operational monitoring data of tenant containers from the underlying infrastructure of the cloud computing environment, such as CPU utilization, memory usage, and network throughput. Secondly, the system analyzes this monitoring data to identify and determine whether resource contention events exist, for example, by detecting abnormal increases in CPU scheduling latency, memory page fault rate, or network packet loss rate to determine preemption, memory conflict, or network contention. Finally, once a resource contention event is identified, the system extracts key information such as the tenant container identifier, resource type, timestamp, duration, and contention intensity involved in the event, and stores it in a structured manner to generate "relationship data" that records the resource contention relationships between tenants. This data provides a foundation for subsequent analysis and scheduling decisions.

[0058] S102. Analyze the relationship data to identify preset high-frequency conflict patterns, and based on the high-frequency conflict patterns, determine specific tenant groups with strong resource mutual exclusion effects. The high-frequency conflict patterns are tenant combinations that frequently compete for resources under specific loads.

[0059] Optionally, step S102 may specifically include the following steps:

[0060] S1021. The relationship data is decomposed according to resource type to form multiple independent competition sequences. Each competition sequence is divided according to a preset time window to obtain a series of resource competition segments based on time.

[0061] S1022. Within each resource contention segment, the frequency of concurrent conflicts for different tenant combinations is statistically analyzed, and tenant combinations whose frequency exceeds a preset threshold are selected as candidate conflict units. A corresponding resource contention intensity is calculated for each candidate conflict unit.

[0062] Specifically, step S1022 may include the following process: traversing each contention event recorded within the resource contention segment, extracting and initiating the tenant identity identifiers of the conflict, and accumulating the number of times the tenant identity identifiers co-occur within the same time window in the form of tenant pairs to form a raw statistical data set of concurrent conflict frequency; comparing the raw statistical data set with a preset threshold, and identifying any tenant combination whose conflict frequency exceeds the preset threshold as a candidate conflict unit; simultaneously, assigning an initial weight to each candidate conflict unit based on the duration of the contention event and the type of resource involved; multiplying the concurrent conflict frequency of the candidate conflict unit with the corresponding initial weight to obtain a quantitative value that can characterize the intensity of the conflict, and using the quantitative value as the resource contention intensity.

[0063] S1023. Aggregate all candidate conflict units that repeatedly appear within a continuous time window, and perform weighted accumulation of the resource contention intensity among the aggregated candidate conflict units to quantify the long-term mutual exclusion relationship between different tenants, and select the combination with the highest mutual exclusion relationship to construct a specific tenant group.

[0064] In the above scheme, the high-frequency conflict pattern refers to the phenomenon in a cloud computing environment where certain tenant groups frequently compete for resources under specific workloads, resulting in performance impacts on each other. This pattern reveals the inherent and recurring resource competition relationships between tenants. A specific tenant group refers to a set of tenants identified as having a strong mutual exclusion effect in resource usage. Due to their work characteristics or resource demand patterns, these tenants are highly prone to conflicts when sharing resources, requiring special attention and handling. Relationship data refers to the detailed records of resource contention events between tenant containers obtained and structured from step S101, including information such as which tenants, when, and on which resources conflicts occurred. A competition sequence refers to the independent, time-ordered lists of resource contention events formed after classifying and organizing the relationship data according to different resource types. A resource contention segment refers to the set of all inter-tenant resource contention events occurring within a specific time window for a certain type of resource. Concurrent conflict frequency refers to the number of times a specific tenant group simultaneously competes for resources within a resource contention segment; this value reflects the intensity of resource conflicts for that tenant group within a short period. Candidate conflict units refer to tenant combinations whose concurrent conflict frequency exceeds a preset threshold within a certain resource contention segment. These combinations are potential sources of resource conflicts that require further analysis. Resource contention intensity is a quantitative indicator used to measure the intensity of resource competition among tenants within a candidate conflict unit. It considers not only the number of conflicts but may also incorporate the severity of each conflict.

[0065] In this embodiment, firstly, in step S1021, the system receives and processes relationship data collected from continuous monitoring. This data records in detail contention events occurring in different tenant containers on various resources such as CPU, memory, and network. To analyze these complex contention relationships more precisely, the system performs a key decomposition operation: based on the resource type involved in each contention event, the original relationship data is decomposed into multiple independent competition sequences. This means that CPU contention forms a dedicated sequence, memory contention forms another sequence, and so on, ensuring that the contention analysis of each resource does not interfere with each other. Furthermore, to capture the dynamics of contention within different time periods, the system performs a segmentation operation on each independent competition sequence. This segmentation is based on a pre-set time window. For example, if the time window is set to 5 minutes, each competition sequence will be divided into a series of consecutive 5-minute segments, each of which constitutes a resource contention fragment. The purpose of this is to transform long-term, continuous resource contention data into a series of discrete, easily analyzable short snapshots, enabling focus on resource contention behavior within a specific time period.

[0066] Next, in step S1022, the system performs detailed statistics and filtering for each newly defined resource contention segment. Within each segment, the system iterates through all recorded resource contention events and accurately counts the specific number of concurrent conflicts between different tenant combinations; this is called the concurrent conflict frequency. For example, if tenant A and tenant B simultaneously contend for CPU resources 10 times within a 5-minute CPU contention segment, their concurrent conflict frequency is 10. After completing the statistics, the system filters based on a pre-set threshold. Only tenant combinations with concurrent conflict frequencies exceeding this threshold are identified and filtered out as candidate conflict units. This means that only tenant combinations with sufficiently frequent conflicts are included in subsequent in-depth analysis. For each filtered candidate conflict unit, the system further calculates a resource contention intensity value. This intensity value considers not only the number of conflicts but also the severity of each conflict; for example, if a conflict leads to a significant performance degradation, its intensity value will be higher. This intensity value aims to quantify the intensity of resource contention for that tenant combination within the current time window.

[0067] Finally, in step S1023, to identify tenants with long-standing and persistent mutual influence, the system performs an aggregation and weighted accumulation operation. The system tracks and aggregates all candidate conflict units that repeatedly appear within multiple consecutive time windows. This means that if tenant A and tenant B exhibit high-frequency conflict in every 5-minute time window over the past hour, they will be aggregated together. Among these aggregated candidate conflict units, the system weights and accumulates their calculated resource contention intensity across different time windows. The purpose of weighted accumulation is to more accurately reflect the severity of long-term mutual exclusion relationships between tenants, typically giving higher weight to recently occurring conflicts to reflect their current impact. Through this weighted accumulation, the system can quantify persistent and strong resource mutual exclusion relationships between different tenants, and based on these quantification results, identify and determine specific tenant groups that truly have strong resource mutual exclusion effects. These groups are the targets that the system needs to focus on and optimize scheduling for, as they are the main causes of system instability and low resource utilization.

[0068] In practical applications, assume there are tenants A, B, and C, with a time window set to 1 minute and a preset threshold of 3 times. The following CPU contention events are extracted from the relational data: 00:00:10: Tenant A and Tenant B engage in CPU contention; 00:00:25: Tenant A and Tenant C engage in CPU contention; 00:00:30: Tenant A and Tenant B engage in CPU contention; 00:00:45: Tenant B and Tenant C engage in CPU contention; 00:00:50: Tenant A and Tenant B engage in CPU contention; 00:01:15: Tenant A and Tenant B engage in CPU contention; 00:01:30: Tenant A and Tenant C engage in CPU contention; 00:01:40: Tenant A and Tenant B engage in CPU contention. Through step S1021, the system extracts all CPU contention events from the relational data, forming an independent CPU contention sequence. Then, the system divides this CPU contention sequence into 1-minute time windows. For example, the first time window is 00:00:00-00:00:59, forming a resource competition segment; the second time window is 00:01:00-00:01:59, forming another resource competition segment.

[0069] In step S1022, within the first resource contention segment (00:00:00-00:00:59), the system counts the frequency of concurrent conflicts: Tenant A and Tenant B have 3 conflicts (00:00:10, 00:00:30, 00:00:50). Tenant A and Tenant C have 1 conflict (00:00:25). Tenant B and Tenant C have 1 conflict (00:00:45). Since the preset threshold is 3 conflicts, only the conflict frequency between Tenant A and Tenant B reaches or exceeds the threshold; therefore, "Tenant A - Tenant B" is selected as a candidate conflict unit for the first time window. Assuming the resource contention intensity is calculated as: conflict frequency * average impact factor of each conflict, then the resource contention intensity of "Tenant A - Tenant B" is 3 * 1 = 3. During the second resource contention segment (00:01:00-00:01:59), the system counted the frequency of concurrent conflicts: Tenant A and Tenant B had 2 conflicts (00:01:15, 00:01:40). Tenant A and Tenant C had 1 conflict (00:01:30). In this segment, no tenant combination's conflict frequency reached the preset threshold of 3 times, therefore no new candidate conflict units were selected.

[0070] In step S1023, the system aggregates candidate conflicting units that repeatedly appear within consecutive time windows. Here, "Tenant A-Tenant B" is a candidate conflicting unit in the first time window. Suppose that over a longer time span, the "Tenant A-Tenant B" combination frequently conflicts within multiple time windows. The system weights and accumulates the resource contention intensity of these consecutively appearing "Tenant A-Tenant B" combinations. For example, if the intensity of the first window is 3 and the intensity of the second window is 2, the system might give higher weights to more recent windows, such as a weight of 0.6 for the latest window and 0.4 for the second newest window. Then the weighted cumulative intensity might be 3*0.6 + 2*0.4 = 1.8 + 0.8 = 2.6. In this way, the system quantifies the long-term mutual exclusion relationship between "Tenant A-Tenant B" and identifies "Tenant A-Tenant B" as a "specific tenant group" because it consistently exhibits high-frequency resource contention.

[0071] The overall solution in step S102 above, through in-depth mining and pattern recognition of resource competition relationships among tenants, can accurately identify and quantify tenant combinations that frequently interfere with each other in a shared resource environment. This enables the system to extract key conflict information from massive amounts of operational data, providing a solid data foundation and clear optimization direction for subsequent intelligent scheduling decisions. This solution significantly improves the ability to predict potential resource conflicts, effectively reduces performance fluctuations caused by resource contention in multi-tenant environments, optimizes the rationality of resource allocation, and enhances the stability and reliability of the entire cloud computing platform.

[0072] S103. Combining the historical contention information obtained from the relational data with the real-time resource load status of the current environment, dynamically estimate a probability level of resource conflict with the specific tenant group for the new container to be deployed.

[0073] Optionally, step S103 may specifically include the following steps:

[0074] S1031. Construct an initial resource profile based on the resource declaration of the new container, and retrieve historical conflict records that match the initial resource profile from the relational data. The historical conflict records contain the specific load conditions when the conflict occurred.

[0075] S1032. Compare the current activity characteristics of the specific tenant group with the specific load conditions recorded in the historical conflict record, find the historical conflict scenario that is closest to the current operating state, and obtain the conflict result corresponding to the historical conflict scenario.

[0076] S1033. By comprehensively considering the initial resource profile of the new container and the conflict results, and introducing the real-time resource load status of the current environment as a dynamic correction factor, a probability level is generated.

[0077] In the above scheme, historical contention information refers to detailed records of past resource contention events between tenant containers, collected and stored in the relational data from step S101, including contention time, resource type, and participating tenants. Real-time resource load status refers to the usage and pressure levels of various resources in the current cloud computing environment, obtained through a real-time monitoring system. Probability level is a quantitative indicator used to represent the likelihood of a new container encountering a resource conflict with a specific tenant group, typically categorized as low, medium, and high. Initial resource profile is a profile built based on the new container's resource declaration, describing the container's expected resource demand pattern. Historical conflict records are a set of conflict events extracted from the relational data that occurred during past container deployments similar to the initial resource profile, including specific resource usage at the time of the conflict. Specific load conditions refer to the detailed resource usage status of the cloud computing environment when historical conflicts occurred, including resource utilization rates for each tenant and overall system load. Current activity characteristics are the resource usage behavior patterns of a specific tenant group at the current point in time, derived by analyzing their recent resource monitoring data. Historical conflict scenarios are a set of conflict conditions and their outcomes selected from historical conflict records that are most similar to the current environment. Conflict outcome refers to the actual severity of a conflict in a given historical conflict scenario, such as the magnitude of performance degradation or duration. The dynamic correction factor is an adjustment coefficient calculated based on the current resource load state, used to adjust the historical conflict probability in real time.

[0078] In this embodiment, firstly, through step S1031, the system parses the resource requirement declaration submitted by the new container, extracts key resource indicators such as the number of CPU cores, memory size, and storage space, and combines these indicators into a multi-dimensional resource requirement vector according to a preset weight ratio. This vector is the initial resource profile. Simultaneously, the system queries historical records from the relational database, uses a similarity algorithm to calculate the similarity between the new container's resource requirement vector and historical container deployment records, and filters historical records with similarity exceeding a threshold as matching historical conflict records. These historical records not only contain the conflict event itself but also record in detail the resource usage status of the entire cloud computing platform at the time of the conflict, including specific values ​​such as CPU load, memory pressure, and network bandwidth usage.

[0079] In step S1032, the system collects real-time resource usage data for a specific tenant group, including metrics such as CPU percentage, memory usage, and network throughput, forming a current activity feature vector. The system then compares this current activity feature vector with the specific load condition vectors saved in historical conflict records, calculating their Euclidean distance or similarity score to find the historical conflict scenario with the smallest distance or highest similarity. This matching process comprehensively considers the weight of various resources; for example, matching CPU usage may be more important than matching memory usage. After finding the best-matching historical conflict scenario, the system extracts the conflict outcome data recorded in that scenario, including quantitative metrics such as conflict duration and performance degradation.

[0080] Finally, in step S1033, the system comprehensively analyzes the initial resource profile of the new container and the matched historical conflict results, making appropriate adjustments based on the similarity differences between the two. Simultaneously, the system monitors the overall resource load status of the current environment in real time and calculates a dynamic correction factor. This correction factor is based on a comparison between the current resource availability and the resource availability during historical conflict scenarios; if current resources are more strained, the probability level is increased, and vice versa. The system then maps the adjusted probability values ​​to preset probability level ranges, such as 0-30% for low, 31-70% for medium, and 71-100% for high, outputting an intuitive conflict probability level for scheduling decisions.

[0081] In practical applications, through step S1031, in a multi-tenant public cloud platform, a new container requests 4 CPU cores and 8GB of memory, which the system converts into a resource requirement vector [4,8]. Five deployment records with similar resource requirements are found from the historical database, three of which show conflicts when sharing resources with tenant group X. At the time of the conflict, the system CPU load averaged 85% and memory utilization was 90%. These historical conflict records are extracted for subsequent analysis.

[0082] In step S1032, current monitoring shows that tenant group X is using 80% CPU and 75% memory. The system calculates the similarity between this current state and historical conflict scenarios, finding that it is most similar to one historical scenario where CPU usage was 82% and memory usage was 78%, indicating a moderate performance conflict occurred in that scenario. Therefore, the system uses this historical conflict result as a baseline reference value.

[0083] In step S1033, the system detects that the current overall CPU load is 5% lower than in historical conflict scenarios, while memory availability is 10% higher. Therefore, the dynamic correction factor is set to 0.9. Multiplying the base conflict probability of 70% by the correction factor 0.9 yields 63%, which, after mapping to the probability level range, outputs a "Medium" level, indicating to the administrator that attention is needed but immediate isolation is not required. Through the adjustment in step S1033, the system provides an accurate probability assessment that considers both historical patterns and the current state, providing a reliable basis for scheduling decisions.

[0084] The overall solution in step S103 above, by combining historical data and real-time environmental conditions, can intelligently predict the resource conflict risks that may occur after the deployment of new containers, providing a quantitative basis for scheduling decisions. This method avoids the lag and inaccuracy caused by relying solely on static rules or human experience, and achieves dynamic and accurate assessment of the probability of conflicts between multi-tenant containers. Through a dual mechanism of historical pattern matching and real-time correction, it fully utilizes past experience while adapting to environmental changes, significantly improving the predictability and adaptability of resource scheduling in cloud computing environments, and effectively reducing the risk of performance interference and system instability caused by blind deployment.

[0085] S104. Based on the conflict risk indicated by the probability level, generate a set of dynamic isolation scheduling strategies, which distribute containers with high conflict risk in independent physical resource domains.

[0086] Optionally, step S104 may specifically include the following steps:

[0087] S1041. Using topology information as an index, first obtain all available physical resource domains in the cloud computing environment, and mark each physical resource domain to indicate the tenant container it currently carries and the specific tenant group to which the tenant container belongs.

[0088] S1042. When deploying the new container, based on the probability level, all physical resource domains are divided into preferred deployment domains, alternative deployment domains, and risky deployment domains. The risky deployment domains specifically refer to those physical resource domains that have already hosted specific tenant groups with a high risk of conflict with the new container.

[0089] S1043. After excluding the risky deployment domains, from the remaining preferred deployment domains and alternative deployment domains, the target deployment domain is selected by further evaluating the remaining resource reserves and the balance of resource allocation in each domain, and a dynamic isolation scheduling strategy is generated based on the target deployment domain.

[0090] Specifically, step S1043 may include the following processes: For the preferred deployment domain and the alternative deployment domain, the current total load and total capacity in multiple dimensions such as central processing unit, memory and network bandwidth are statistically analyzed. The remaining resource margin is quantified by calculating the difference between the current total load and total capacity values. Within each domain, the load distribution among the subordinate physical nodes is examined. The degree of dispersion of the load distribution of each node is calculated to specifically measure the balance of resource allocation, where a lower degree of dispersion means a better balance. Different evaluation weights are set for the remaining resource margin and the balance, and they are weighted and combined into a deployment adaptation score. The domain with the highest deployment adaptation score is selected as the target deployment domain, and a dynamic isolation scheduling strategy is generated based on the target deployment domain.

[0091] In the above scheme, the dynamic isolation scheduling strategy is an intelligent deployment solution designed to effectively avoid or mitigate resource conflicts and improve system stability and resource utilization efficiency by deploying potentially interfering containers to different physical resource domains. A physical resource domain refers to an independent physical server, host, or compute node in a cloud computing environment. These domains possess their own independent hardware resources such as CPU, memory, and network, forming the foundational environment for container operation. The preferred deployment domain is one with the lowest probability of conflict with the new container, and sufficient and balanced resources; it is the system's primary deployment target. Alternative deployment domains are those with a low probability of conflict with the new container, but may be slightly inferior to the preferred deployment domains in terms of resource availability or load balance; they serve as a second-best option. Risky deployment domains specifically refer to physical resource domains that already host specific tenant groups with a high risk of conflict with the new container to be deployed; the system will try to avoid deploying new containers to these areas. Remaining resource availability refers to the total amount of unallocated and unused CPU, memory, and other resources in a physical resource domain, reflecting the domain's carrying capacity. The target deployment domain is the physical resource domain selected for deploying the new container after comprehensive evaluation.

[0092] In this embodiment, firstly, through step S1041, the system obtains a detailed list of all physical servers by calling the resource management API of the cloud computing platform, including the unique identifier, hardware configuration, network connection topology, and other information for each server. Then, the system queries the container orchestration system's database to obtain a list of all currently running tenant containers on each physical server, and further identifies the specific tenant group to which each container belongs based on the tenant group relationships established in step S102. This information is organized into a structured topology graph, where each physical resource domain node is associated with its container list and corresponding tenant group label. The system continuously monitors changes to this topology graph to ensure the real-time nature of the information.

[0093] In step S1042, when a new container needs to be deployed, the system obtains the conflict probability level between the container and each specific tenant group from step S103. The system traverses each physical resource domain in the topology map and checks the conflict probability between the tenant container running on it and the new container. If a physical resource domain is running tenant group containers with a "high" conflict probability with the new container, the domain is marked as a risk deployment domain; if it only runs group containers with a "low" or "medium" conflict probability, it is further divided into preferred or alternative deployment domains based on resource conditions. This division process considers the overall load of the physical resource domain to ensure that the division result reflects both conflict risk and resource utilization.

[0094] Finally, in step S1043, the system first eliminates all risky deployment domains. Then, among the remaining preferred and alternative deployment domains, it assesses resource availability by calculating indicators such as the remaining CPU cores and remaining memory for each domain. Simultaneously, it analyzes the balance of resource allocation within each domain (e.g., the matching degree of CPU and memory utilization, and the variance of container load). The system calculates a comprehensive score for each candidate domain and prioritizes the domain with the highest score as the target deployment domain. Once selected, the system generates a specific scheduling strategy, including detailed information such as the target physical server's IP address, deployment time window, and resource quota limits, which is then executed by the container orchestration system.

[0095] In practical applications, through step S1041, the system scan reveals that the current cloud platform has 10 physical servers. Servers 1-3 are running containers belonging to "high-conflict group A", servers 4-6 are running containers belonging to "low-conflict group B", and servers 7-10 are not running any containers belonging to any specific group. The system creates a detailed profile for each server, recording its hardware configuration, currently running containers, and their group affiliation.

[0096] In step S1042, when a new container with a "high" probability of conflict with group A and a "low" probability of conflict with group B is deployed, the system marks servers 1-3 as risk deployment domains. Because the container is running in group A, servers 4-6 are classified as candidate deployment domains based on resource status, and servers 7-10 are classified as preferred deployment domains.

[0097] In step S1043, after excluding servers 1-3, the system evaluates the remaining servers: Server 7 has the most remaining resources, with 16 CPU cores / 32GB of memory available, and the most balanced load, and is selected as the target deployment domain; Servers 8-9 are considered as backups. The new container is deployed to server 7 using a generation scheduling policy. Through the execution of step S1043, the new container is successfully deployed to server 7, which has sufficient resources and no high risk of conflict, effectively avoiding resource contention with containers in group A, while ensuring its own performance stability.

[0098] The overall solution in step S104 above achieves effective isolation and deployment of containers with high conflict risk through a systematic physical resource domain classification and intelligent selection mechanism. This method can significantly reduce resource contention in multi-tenant environments and improve overall system stability. The scheduling strategy based on real-time topology information and dynamic evaluation avoids the inefficiency of manual intervention and overcomes the shortcomings of static rules in adapting to environmental changes, providing a smart and efficient resource scheduling solution for cloud computing platforms.

[0099] S105. While executing the dynamic isolation scheduling strategy, configure an independent conflict buffer resource pool for the designated key tenant, and dynamically adjust the reserved capacity of the conflict buffer resource pool according to the real-time operation requirements of the key tenant.

[0100] Optionally, step S105 may specifically include the following steps:

[0101] S1051. Based on the relevant agreement on service level, identify the designated key tenant from all tenants, and with reference to the peak value of the historical resource usage of the key tenant, configure an initial conflict buffer resource pool in the physical resource domain where the key tenant is located.

[0102] S1052. During system operation, continuously monitor the actual resource consumption rate of the critical tenant, and synchronously record the frequency and duration of resource contention events between the critical tenant and other tenant containers.

[0103] S1053. The actual resource consumption rate is comprehensively evaluated in conjunction with the frequency and duration. If the evaluation result exceeds a preset stability threshold, the reserved capacity of the conflict buffer resource pool is increased and adjusted.

[0104] In the above scheme, the conflict buffer resource pool is a pre-defined set of additional resources reserved for critical tenants. Independent of regular resource allocation, it aims to rapidly provide additional computing, storage, or network resources to avoid performance degradation or service interruption when critical tenants face resource contention or sudden increases in demand. Peak historical resource usage refers to the highest level of resource consumption ever reached by a critical tenant over a past period; this data is used to estimate its potential maximum resource demand. Actual resource consumption rate refers to the actual rate at which a critical tenant uses various resources during real-time operation; this is a dynamically changing metric. Reserved capacity refers to the amount of resources currently reserved for critical tenants in the conflict buffer resource pool; this capacity can be dynamically adjusted according to actual needs.

[0105] In this embodiment, firstly, through step S1051, the system classifies and identifies all tenants according to predefined business service level agreements. These agreements typically include explicit provisions regarding business importance, performance requirements, and availability guarantees. The system automatically filters out key tenants marked as high-priority or core businesses by analyzing tenant business types, contract terms, or preset tags. After identifying key tenants, the system further queries and analyzes their historical resource usage data over a period of time, including the consumption of various resources such as CPU, memory, network bandwidth, and storage I / O, accurately calculating the peak of their historical resource usage in different time periods. This peak represents the upper limit of the tenant's resource demand during the busiest period. Based on this historical peak, the system intelligently allocates and configures a dedicated initial conflict buffer resource pool within the physical resource domain currently deployed by the key tenant. This resource pool is independent of regular resource allocation, and its initial capacity is reasonably estimated based on the key tenant's historical peak, aiming to provide additional resource guarantees to cope with potential future resource competition. For example, if a critical tenant's historical peak CPU usage is 10 cores, the system may configure a conflict buffer resource pool with an initial capacity of 2 cores for it.

[0106] In step S1052, throughout the entire system operation, the system continuously and in real-time monitors the actual resource consumption rate of critical tenants. This includes fine-grained collection and analysis of various indicators such as CPU utilization, memory usage, network throughput, and disk I / O of the applications run by critical tenants. The monitoring process is high-frequency and uninterrupted, ensuring that subtle changes in resource consumption can be captured. Simultaneously, the system also records in parallel the frequency and duration of resource contention events that occur between critical tenant applications and other tenant applications when sharing physical resources. This is typically achieved by monitoring the competition for underlying resources.

[0107] Finally, in step S1053, the system comprehensively evaluates the actual resource consumption rate data acquired in real time in step S1052 and the frequency and duration data of resource contention events. This evaluation process uses an intelligent analysis algorithm to perform correlation analysis on the two types of data to determine whether the current resource usage of the critical tenant is healthy and whether the degree of resource contention interference it is experiencing is within an acceptable range. The purpose of the evaluation is to identify potential resource bottlenecks or performance risks. Once the evaluation results show that the critical tenant's resource consumption or level of interference exceeds the pre-set stability threshold, it indicates that the existing resources may be insufficient to ensure the stable operation of the critical tenant, or its performance has been significantly affected. For example, if the evaluation finds that the critical tenant's CPU utilization is consistently higher than 90%, and more than 10 memory contention events, each lasting more than 1 second, have occurred in the past 5 minutes, this may exceed the stability threshold. In this case, the system will immediately trigger an expansion adjustment operation on the reserved capacity of the conflict buffer resource pool.

[0108] In practical applications, through step S1051, a large cloud computing platform identifies critical tenants, such as online financial trading systems, based on service level agreements (SLAs) with customers. These systems have extremely high requirements for transaction latency, and any resource bottleneck could lead to significant losses. The platform analyzes the tenant's resource usage records over the past year and finds that its CPU utilization reached 95% and memory usage reached 90% during peak holiday periods. Based on these historical peaks, the platform reserves a conflict buffer resource pool with an initial capacity of 10 CPU cores and 16GB of memory within the physical server cluster where the tenant resides, as a precaution.

[0109] In step S1052, during daily operations, the platform continuously monitors the resource usage of online financial trading system tenants in real time. For example, it collects the CPU utilization, memory usage, network I / O, and disk I / O of their containers every second. Simultaneously, the system uses kernel-level event tracing and resource scheduler log analysis to accurately record resource contention events between the tenant's trading process and other tenants' processes on the same physical machine. For example, it records events such as a 50-millisecond pause in the financial trading process due to CPU scheduling or a 100-millisecond delay in data packets due to network bandwidth contention, and calculates the frequency and duration of these events.

[0110] In step S1053, the platform comprehensively evaluates the actual resource consumption rate of the online financial trading system tenant and the resource contention event data monitored in real time. The platform's preset stability threshold is: when the CPU utilization exceeds 90% for one consecutive minute or when there are more than 10 CPU scheduling delay events within 5 minutes, each lasting more than 50 milliseconds, expansion is triggered. Since the frequency / 15 times and duration / 80 milliseconds of the current CPU scheduling delay events both exceed the threshold, the system determines that this critical tenant faces potential performance risks. Therefore, the system immediately expands the conflict buffer resource pool of the online financial trading system tenant, increasing its reserved capacity from 10 CPU cores and 16GB memory to 20 CPU cores and 32GB memory to ensure the smooth operation of its trading business.

[0111] The overall solution in step S105 above significantly improves the resource guarantee capability and operational stability of critical services by configuring and dynamically adjusting independent conflict buffer resource pools for critical tenants. It effectively copes with sudden resource contention and demand growth, reducing performance fluctuations and interruption risks caused by insufficient resources in critical services. This solution optimizes the flexibility and response speed of resource allocation, ensures the service quality of critical services in a multi-tenant shared environment, and improves the overall system reliability and user satisfaction.

[0112] The following is a complete embodiment for steps S101 to S105:

[0113] In step S101, within a large public cloud container cluster, the platform continuously deploys and runs tens of thousands of tenant containers, which share the underlying physical server resources. To accurately detect resource contention, the platform deploys a series of lightweight monitoring agents that penetrate the operating system kernel and virtualization layer to capture resource events between containers in real time. For example, when tenant A's web service container and tenant B's database container simultaneously attempt to write to the same shared storage, the system records this memory access conflict event, including the time of occurrence, the container IDs involved, the conflict type, and the duration. Similarly, when tenant C's AI training task container suddenly and explosively consumes a large number of CPU cores, causing CPU scheduling delays in tenant D's online game service container, the system records this as a CPU preemption event. Furthermore, when tenant E's live video streaming container and tenant F's file transfer container simultaneously perform large data transfers, causing physical network card bandwidth saturation, the system records this as a network bandwidth contention event. All of these captured raw event data, after initial processing, will be integrated into structured relational data, such as a database record containing source container ID, target container ID, conflict type, conflict intensity, and occurrence timestamp, clearly depicting the complex resource competition relationships between tenant containers.

[0114] In step S102, the platform periodically performs in-depth analysis on the massive amount of relationship data generated in step S101 to identify recurring and significantly impactful high-frequency conflict patterns. This is typically achieved through techniques such as clustering analysis and association rule mining. For example, the system might discover that whenever the containers of online advertising tenants and real-time data analytics tenants are deployed on the same physical server, severe network bandwidth contention and CPU preemption events always occur during the peak batch processing period from 2 AM to 4 AM daily, leading to a significant decline in the performance of both services. This combination of online advertising tenants and real-time data analytics tenants under specific loads is identified as a high-frequency conflict pattern. Based on these identified patterns, the platform can further determine specific tenant groups with strong resource mutual exclusion effects—that is, tenant combinations that are highly prone to resource conflicts once co-deployed. For example, the system will explicitly mark online advertising tenants and real-time data analytics tenants as a pair of mutually exclusive groups and record their conflict characteristics to provide a basis for subsequent intelligent scheduling.

[0115] In step S103, when a new container requests deployment, the platform first constructs an initial resource profile based on its resource declaration. The system then combines historical contention information accumulated in steps S101 and S102, particularly high-frequency conflict patterns and specific tenant group data related to online advertising tenants. Simultaneously, the system acquires real-time resource load status of each physical server in the current cluster, including CPU utilization, remaining memory, and network I / O. Through a complex predictive model, which comprehensively considers the new container's resource requirements, historical conflict patterns, and the real-time load of the target physical server, the system dynamically estimates the probability level of resource conflict between the new container deployed on a specific physical server and existing specific tenant groups. For example, if the server where the new container is planned to be deployed already has containers belonging to real-time data analytics tenants, and the server's CPU utilization has reached 80%, the model might estimate a probability level of 0.85 for high-intensity CPU contention.

[0116] In step S104, the platform intelligently generates a dynamic isolation scheduling strategy based on the conflict risk indicated by the probability level estimated for the new container in step S103. The core of this strategy is to prevent containers with high conflict risk from being deployed to physical resource domains that may cause performance issues. First, the system obtains the topology information of the entire cloud computing environment and meticulously labels each physical resource domain. Then, based on the conflict probability level between the new container and the existing tenant group, the system divides these physical resource domains into three categories: preferred deployment domains / extremely low conflict probability, suitable for deployment; alternative deployment domains / medium conflict probability, worth considering for deployment; and risky deployment domains / high conflict probability, should be avoided. For example, if the conflict probability level between the new advertising service container and the real-time data analytics tenant exceeds 0.7, then the physical server containing the real-time data analytics tenant container and experiencing high load will be marked as a risky deployment domain. After excluding all risky deployment domains, the system will further evaluate the remaining resource reserves and resource allocation balance of the remaining preferred and alternative deployment domains to select one or more target deployment domains and generate specific scheduling instructions to ensure that new containers are deployed to the most suitable physical location that can effectively avoid resource contention.

[0117] In step S105, while executing the aforementioned dynamic isolation scheduling strategy, the platform also configures an independent conflict buffer resource pool for those identified as critical tenants. This resource pool acts like a dedicated reserve vault, pre-allocating a certain amount of CPU, memory, and other resources within the physical resource domain where the critical tenant resides. The system continuously monitors the actual resource consumption rate of the critical tenant and synchronously records the frequency and duration of resource contention events between it and other tenant containers in the cluster. If the evaluation result exceeds a pre-set stability threshold, the system immediately triggers an expansion adjustment of the reserved capacity of the conflict buffer resource pool. This means that the system dynamically adds additional resources to the critical tenant's buffer pool from the cluster's idle resources, ensuring that even under extreme resource contention or sudden load increases, critical services can obtain sufficient resource guarantees, avoiding performance degradation or service interruption, and ensuring the continuous and stable operation of its core business.

[0118] The containerized resource elastic scheduling method provided in this application for a cloud computing environment constructs a comprehensive and intelligent resource scheduling and management mechanism through deep insights into resource competition relationships among tenants, intelligent identification of high-frequency conflict patterns, accurate prediction of new container conflict risks, flexible formulation of dynamic isolation scheduling strategies, and dynamic protection of critical tenant conflict buffer resource pools. This significantly improves the predictability and adaptability of resource scheduling in multi-tenant shared cloud environments, effectively reduces performance interference and system instability risks caused by resource contention, optimizes resource utilization efficiency, ensures service quality for various businesses, and enhances user experience and overall platform reliability.

[0119] Figure 2 This is a schematic diagram illustrating a specific implementation of a containerized resource elastic scheduling system in a cloud computing environment, as provided in this application embodiment. (Refer to...) Figure 2 The system may include:

[0120] The acquisition module 21 is used to acquire resource contention events between tenant containers in the cloud computing environment. The resource contention events include CPU preemption, memory access conflict and network bandwidth competition. Based on the resource contention events, relational data that records the resource competition relationship between tenants is generated.

[0121] Analysis module 22 is used to analyze the relational data to identify preset high-frequency conflict patterns, and based on the high-frequency conflict patterns, to determine specific tenant groups with strong resource mutual exclusion effects. The high-frequency conflict patterns are tenant combinations that frequently compete for resources under specific loads.

[0122] The estimation module 23 is used to combine historical contention information obtained from the relational data with the real-time resource load status of the current environment to dynamically estimate a probability level of resource conflict with the specific tenant group for the new container to be deployed.

[0123] The generation module 24 is used to generate a set of dynamic isolation scheduling strategies based on the conflict risk indicated by the probability level. The dynamic isolation scheduling strategies will distribute containers with high conflict risk in independent physical resource domains.

[0124] The configuration module 25 is used to configure an independent conflict buffer resource pool for a designated key tenant while executing the dynamic isolation scheduling strategy, and to dynamically adjust the reserved capacity of the conflict buffer resource pool according to the real-time operating needs of the key tenant.

[0125] The containerized resource elastic scheduling system in the cloud computing environment of this application embodiment is used to implement the aforementioned containerized resource elastic scheduling method in the cloud computing environment. Therefore, the specific implementation of the containerized resource elastic scheduling system in the cloud computing environment can be found in the embodiment section of the containerized resource elastic scheduling method in the cloud computing environment above. The specific implementation can be referred to the description of the corresponding embodiments, and will not be repeated here.

[0126] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the containerized resource elastic scheduling method in the cloud computing environment described above.

[0127] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the above-described containerized resource elastic scheduling methods in a cloud computing environment.

[0128] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory, random access memory, portable hard drives, magnetic disks, or optical disks.

[0129] Embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the containerized resource elastic scheduling method in a cloud computing environment.

[0130] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0131] The above provides a detailed description of a containerized resource elastic scheduling method and system in a cloud computing environment. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for elastic scheduling of containerized resources in a cloud computing environment, characterized in that, include: The system acquires resource contention events between tenant containers in a cloud computing environment, including CPU preemption, memory access conflicts, and network bandwidth contention, and generates relationship data that records the resource contention relationships between tenants based on the resource contention events. The relationship data is analyzed to identify preset high-frequency conflict patterns, and based on the high-frequency conflict patterns, specific tenant groups with strong resource mutual exclusion effects are identified. The high-frequency conflict patterns are tenant combinations that frequently compete for resources. By combining historical contention information obtained from the relational data with the real-time resource load status of the current environment, a probability level of resource conflict with the specific tenant group is dynamically estimated for the new container to be deployed. Based on the conflict risk indicated by the probability level, a dynamic isolation scheduling strategy is generated, which distributes containers with high conflict risk into independent physical resource domains. While executing the dynamic isolation scheduling strategy, an independent conflict buffer resource pool is configured for the designated key tenant, and the reserved capacity of the conflict buffer resource pool is dynamically adjusted according to the real-time operating needs of the key tenant. Based on the conflict risk indicated by the probability level, a dynamic isolation scheduling strategy is generated. This strategy distributes containers with high conflict risk across independent physical resource domains, including: Using topology information as an index, all available physical resource domains in the cloud computing environment are first obtained, and each physical resource domain is labeled to indicate the tenant container currently hosted thereand the specific tenant group to which the tenant container belongs. When deploying the new container, all physical resource domains are divided into preferred deployment domains, alternative deployment domains, and risky deployment domains based on the probability level. After excluding the risky deployment domains, the remaining preferred deployment domains and alternative deployment domains are further evaluated to determine the target deployment domains, and a dynamic isolation scheduling strategy is generated based on the target deployment domains. The analysis of the relational data identifies preset high-frequency conflict patterns, and based on these patterns, determines specific tenant groups exhibiting strong resource exclusivity effects. These high-frequency conflict patterns are tenant combinations that frequently engage in resource contention, including: The relationship data is decomposed according to resource type to form multiple independent competition sequences. Each competition sequence is divided according to a preset time window to obtain a series of resource competition segments based on time. Within each resource contention segment, the frequency of concurrent conflicts for different tenant combinations is statistically analyzed. Tenant combinations with frequencies exceeding a preset threshold are selected as candidate conflict units, and a corresponding resource contention intensity is calculated for each candidate conflict unit. Aggregate all candidate conflict units that repeatedly appear within a continuous time window, and weight and accumulate the resource contention intensity among the aggregated candidate conflict units to quantify the long-term mutual exclusion relationship between different tenants. Then, select the combination with the highest mutual exclusion relationship to construct a specific tenant group.

2. The method according to claim 1, characterized in that, The step of combining historical contention information obtained from the relational data with the real-time resource load status of the current environment to dynamically estimate a probability level of resource conflict with the specific tenant group for the planned deployment of new containers includes: An initial resource profile is constructed based on the resource declaration of the new container. At the same time, historical conflict records that match the initial resource profile are retrieved from the relational data. The historical conflict records contain the specific load conditions when the conflict occurred. The current activity characteristics of the specific tenant group are compared with the specific load conditions recorded in the historical conflict records to find the historical conflict scenario with the highest similarity to the current running state, and the conflict result corresponding to the historical conflict scenario is obtained. By comprehensively considering the initial resource profile of the new container and the conflict results, and introducing the real-time resource load status of the current environment as a dynamic correction factor, a probability level is generated.

3. The method according to claim 1, characterized in that, While executing the dynamic isolation scheduling strategy, a separate conflict buffer resource pool is configured for designated critical tenants, and the reserved capacity of the conflict buffer resource pool is dynamically adjusted according to the real-time operational needs of the critical tenants, including: According to the relevant agreement on service level, a designated key tenant is identified from all tenants, and a conflict buffer resource pool in an initial state is configured in the physical resource domain where the key tenant is located, with reference to the peak value of the historical resource usage of the key tenant. During system operation, the actual resource consumption rate of the critical tenant is continuously monitored, and the frequency and duration of resource contention events between the critical tenant and other tenant containers are recorded simultaneously. The actual resource consumption rate is comprehensively evaluated in conjunction with the frequency and duration. If the evaluation result exceeds a preset stability threshold, the reserved capacity of the conflict buffer resource pool is increased and adjusted.

4. The method according to claim 1, characterized in that, Within each resource contention segment, the frequency of concurrent conflicts for different tenant combinations is statistically analyzed. Tenant combinations with frequencies exceeding a preset threshold are selected as candidate conflict units, and a corresponding resource contention intensity is calculated for each candidate conflict unit, including: Iterate through each contention event recorded within the resource contention segment, extract and initiate the tenant identity identifier of the conflict, and accumulate the number of times the tenant identity identifiers appear together in the same time window in the form of tenant pairs to form a raw statistical data of concurrent conflict frequency. The raw statistical data is compared with a preset threshold. Any tenant combination whose conflict frequency exceeds the preset threshold is identified as a candidate conflict unit. At the same time, an initial weight is assigned to each candidate conflict unit based on the duration of the contention event and the type of resource involved. The concurrent conflict frequency of the candidate conflict unit is multiplied by the corresponding initial weight to obtain a quantitative value that can characterize the intensity of the conflict. This quantitative value is used as the resource competition intensity.

5. The method according to claim 1, characterized in that, After excluding the risky deployment domains, the remaining preferred and alternative deployment domains are further evaluated by assessing the remaining resource reserves and resource allocation balance of each domain to select a target deployment domain. A dynamic isolation scheduling strategy is then generated based on the target deployment domain, including: For the preferred deployment domain and the alternative deployment domain, the current total load and total capacity in multiple dimensions such as central processing unit, memory and network bandwidth are statistically analyzed. The remaining resource margin is quantified by calculating the difference between the current total load and total capacity values. Within each domain, the load distribution among the subordinate physical nodes is examined, and the degree of dispersion of the load distribution of each node is calculated to specifically measure the balance of resource allocation. Different evaluation weights are assigned to the remaining resource margin and the balance, and they are weighted and combined to form a deployment adaptation score. The domain with the highest deployment adaptation score is taken as the target deployment domain, and a dynamic isolation scheduling strategy is generated based on the target deployment domain.

6. A containerized resource elastic scheduling system in a cloud computing environment, characterized in that, include: The acquisition module is used to acquire resource contention events between tenant containers in the cloud computing environment. The resource contention events include CPU preemption, memory access conflicts and network bandwidth competition. Based on the resource contention events, relational data that records the resource contention relationship between tenants is generated. The analysis module is used to analyze the relationship data to identify preset high-frequency conflict patterns, and based on the high-frequency conflict patterns, to determine specific tenant groups with strong resource mutual exclusion effects. The high-frequency conflict patterns are tenant combinations that frequently engage in resource competition. The estimation module is used to combine historical contention information obtained from the relational data with the real-time resource load status of the current environment to dynamically estimate a probability level of resource conflict with the specific tenant group for the new container to be deployed. The generation module is used to generate a set of dynamic isolation scheduling strategies based on the conflict risk indicated by the probability level. The dynamic isolation scheduling strategies will distribute containers with high conflict risk in independent physical resource domains. The configuration module is used to configure an independent conflict buffer resource pool for a specified key tenant while executing the dynamic isolation scheduling strategy, and to dynamically adjust the reserved capacity of the conflict buffer resource pool according to the real-time operating needs of the key tenant. Based on the conflict risk indicated by the probability level, a dynamic isolation scheduling strategy is generated. This strategy distributes containers with high conflict risk across independent physical resource domains, including: Using topology information as an index, all available physical resource domains in the cloud computing environment are first obtained, and each physical resource domain is labeled to indicate the tenant container currently hosted thereand the specific tenant group to which the tenant container belongs. When deploying the new container, all physical resource domains are divided into preferred deployment domains, alternative deployment domains, and risky deployment domains based on the probability level. After excluding the risky deployment domains, the remaining preferred deployment domains and alternative deployment domains are further evaluated to determine the target deployment domains, and a dynamic isolation scheduling strategy is generated based on the target deployment domains. The analysis of the relational data identifies preset high-frequency conflict patterns, and based on these patterns, determines specific tenant groups exhibiting strong resource exclusivity effects. These high-frequency conflict patterns are tenant combinations that frequently engage in resource contention, including: The relationship data is decomposed according to resource type to form multiple independent competition sequences. Each competition sequence is divided according to a preset time window to obtain a series of resource competition segments based on time. Within each resource contention segment, the frequency of concurrent conflicts for different tenant combinations is statistically analyzed. Tenant combinations with frequencies exceeding a preset threshold are selected as candidate conflict units, and a corresponding resource contention intensity is calculated for each candidate conflict unit. Aggregate all candidate conflict units that repeatedly appear within a continuous time window, and weight and accumulate the resource contention intensity among the aggregated candidate conflict units to quantify the long-term mutual exclusion relationship between different tenants. Then, select the combination with the highest mutual exclusion relationship to construct a specific tenant group.

7. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the containerized resource elastic scheduling method in a cloud computing environment as described in any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, enables the implementation of the containerized resource elastic scheduling method in a cloud computing environment as described in any one of claims 1 to 5.

Images