Pod pre-allocation scheduling method and device and storage medium

Abstract

The invention discloses a Pod pre-allocation scheduling method and device and a storage medium, relates to the technical field of resource scheduling, and discloses a Pod pre-allocation scheduling method comprising the following steps: obtaining load state information of each Pod in a container cluster in response to a creation request of an application instance; determining a target scheduling strategy corresponding to the service type according to the service type of the application instance; determining a target Pod from the container cluster based on the target scheduling strategy and the load state information of each Pod; and distributing the application instance to the target Pod. According to the method, the service type is used as a core basis of scheduling decision, and the real-time load state of the memory cache is combined, so that self-adaptive Pod scheduling based on service awareness is realized, the problems of resource mismatching and hotspot aggregation caused by lack of service awareness are effectively avoided, and the service awareness efficiency is improved. And the load balancing capability and the resource utilization efficiency of the system in a high-concurrency and multi-service-type mixed scene are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of resource scheduling technology, and in particular to a Pod pre-allocation scheduling method, device and storage medium. Background Technology

[0002] In container orchestration systems such as Kubernetes, Pod scheduling typically allocates new Pods to the nodes with the lowest instantaneous load based on the current utilization of resources such as CPU and memory. While this mechanism can reflect the macroscopic resource reserves of a node, it cannot perceive the type of business being carried within the container or its unique resource consumption characteristics.

[0003] In practical applications, resource consumption patterns vary significantly across different business types. Because the current Pod scheduling mechanism cannot identify business types and only makes decisions based on the principle of "lowest load on the current node," it is prone to continuously assigning multiple business instances with the same load type (such as multiple game instances) to the same node. This causes the node to quickly become overloaded due to the aggregation of similar high-load businesses, affecting the overall load balancing effect.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a Pod pre-allocation scheduling method, device and storage medium, which aims to solve the technical problem of single-node overload caused by the current scheduling mechanism being unable to identify the service type, resulting in similar high-load services being concentrated on the same node.

[0006] To achieve the above objectives, embodiments of this application provide a Pod pre-allocation scheduling method, the Pod pre-allocation scheduling method comprising: In response to the application instance creation request, obtain the load status information of each Pod in the container cluster; Based on the service type of the application instance, determine the target scheduling strategy corresponding to the service type; Based on the target scheduling policy and the load status information of each Pod, the target Pod is determined from the container cluster; Assign the application instance to the target Pod.

[0007] In one embodiment, before the step of determining the target scheduling strategy corresponding to the service type of the application instance, the Pod pre-allocation scheduling method further includes: Based on the service type of the application instance, query the pre-configured policy registry to obtain the target scheduling policy associated with the service type; The policy registry stores the mapping relationship between each service type and its corresponding scheduling policy.

[0008] In one embodiment, before the step of obtaining the load status information of each Pod in the container cluster in response to the application instance creation request, the Pod pre-allocation scheduling method further includes: Obtain historical load data of the container cluster, as well as resource usage data of historical application instances corresponding to different business types; Based on the historical load data and the resource usage data, predict the expected resource requirements of each of the aforementioned business types within a future preset time period; Based on the expected resource requirements, schedulable Pod resources in the container cluster are pre-allocated.

[0009] In one embodiment, the step of determining the target Pod from the container cluster based on the target scheduling policy and the load status information of each Pod includes: Based on the load status information of each Pod, a set of candidate Pods that meet the preset resource thresholds is selected. The preset resource thresholds include the remaining CPU capacity, remaining memory capacity, and maximum number of instances that the candidate Pods can support. If the target scheduling strategy is a specific Pod matching strategy, then the dedicated Pod corresponding to the business type of the application instance is selected from the candidate Pod set and used as the target Pod; If the target scheduling strategy is a balanced distribution strategy, then a hash operation is performed based on the identification information of the application instance, and the target Pod is determined from the candidate Pod set according to the operation result; If the target scheduling policy is a randomized perturbation policy, then one of the candidate Pods is randomly selected from the candidate Pod set as the target Pod.

[0010] In one embodiment, the step of randomly selecting a candidate Pod from the candidate Pod set as the target Pod if the target scheduling policy is a randomized perturbation policy includes: Obtain the load status information of each candidate Pod in the candidate Pod set; Based on the load status information of the candidate Pods, the candidate Pod set is sorted, and a preset number of the top-ranked candidate Pods are selected to obtain an optimal subset; One candidate Pod is randomly selected from the preferred subset as the target Pod.

[0011] In one embodiment, if the target scheduling strategy is a balanced distribution strategy, the step of performing a hash operation based on the identification information of the application instance and determining the target Pod from the candidate Pod set according to the operation result includes: Perform a consistent hash operation on the identification information of the application instance to obtain a hash value; Each candidate Pod in the candidate Pod set that matches the business type of the application instance is numbered in a preset order and mapped to the corresponding position on the hash ring; The first corresponding candidate Pod is found clockwise on the hash ring based on the hash value, and this candidate Pod is selected as the target Pod.

[0012] In one embodiment, the step of assigning the application instance to the target Pod includes: Send an application instance mount command to the target Pod to complete the deployment and startup of the application instance on the target Pod; Obtain the resource usage data after the application instance is deployed; Based on the resource usage data, update the load status information of the target Pod.

[0013] In one embodiment, after the step of allocating the application instance to the target Pod, the Pod pre-allocation scheduling method further includes: In response to the release request of the application instance, the resources occupied by the application instance are reclaimed from the load status information of the target Pod.

[0014] This application embodiment also provides a Pod pre-allocation scheduling device, the Pod pre-allocation scheduling device including: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the Pod pre-allocation scheduling method as described above.

[0015] This application embodiment also provides a storage medium, which is a computer-readable storage medium, and stores a computer program on the storage medium. When the computer program is executed by a processor, it implements the steps of the Pod pre-allocation scheduling method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application incorporates the business type of application instances as a decision-making basis during the scheduling process, and dynamically determines the target scheduling strategy accordingly. This enables the scheduling system to distinguish the resource usage characteristics (such as concurrency intensity, duration, resource sensitivity, etc.) of different business types, thereby avoiding the blind allocation of a large number of high-load instances of the same type to the same Pod or local nodes. By combining the target scheduling strategy with the real-time load status information of each Pod, target Pods are jointly selected to ensure that the scheduling results not only match the business semantic intent but also meet the current resource availability constraints. Furthermore, since the scheduling decision is based on the joint judgment of business type and load status, the system can achieve cross-type differentiated distribution in multi-business mixed scenarios, effectively preventing the aggregation of similar high-load businesses due to blind scheduling and significantly reducing the risk of local resource overload. In addition, this mechanism does not rely on frequent external API queries, and can improve scheduling accuracy and overall cluster resource utilization efficiency while ensuring business adaptability, thereby enhancing the system's stability and service quality assurance capabilities in sudden or periodic high-concurrency scenarios. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the Pod pre-allocation and scheduling method of this application in Implementation Example 1. Figure 2 This is a flowchart illustrating Embodiment 2 of the Pod pre-allocation and scheduling method in this application. Figure 3 This is a flowchart illustrating Embodiment 3 of the Pod pre-allocation and scheduling method in this application; Figure 4 This is a flowchart illustrating Embodiment 4 of the Pod pre-allocation and scheduling method in this application; Figure 5 This is a schematic diagram of the structure of the Pod pre-allocation scheduling device in the hardware operating environment involved in the Pod pre-allocation scheduling method in the embodiments of this application.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] In container orchestration systems such as Kubernetes, Pod scheduling typically allocates new Pods to the nodes with the lowest instantaneous load based on the current utilization of resources such as CPU and memory. While this mechanism can reflect the macroscopic resource reserves of a node, it cannot perceive the type of business being carried within the container or its unique resource consumption characteristics.

[0022] In practical applications, resource consumption patterns vary significantly across different business types. Because the current Pod scheduling mechanism cannot identify business types and only makes decisions based on the principle of "lowest load on the current node," it is prone to continuously assigning multiple business instances with the same load type (such as multiple game instances) to the same node. This causes the node to quickly become overloaded due to the aggregation of similar high-load businesses, affecting the overall load balancing effect.

[0023] In view of the above problems, this application proposes a Pod pre-allocation scheduling method, which obtains the load status information of each Pod in the container cluster in response to the application instance creation request; determines the target scheduling strategy corresponding to the business type of the application instance; determines the target Pod from the container cluster based on the target scheduling strategy and the load status information of each Pod; and allocates the application instance to the target Pod.

[0024] This application provides a solution that incorporates the business type of application instances as a decision-making basis during the scheduling process, and dynamically determines the target scheduling strategy accordingly. This enables the scheduling system to distinguish the resource usage characteristics (such as concurrency intensity, duration, resource sensitivity, etc.) of different business types, thereby avoiding the blind allocation of a large number of high-load instances of the same type to the same Pod or local nodes. By combining the target scheduling strategy with the real-time load status information of each Pod, target Pods are jointly screened, ensuring that the scheduling results both match the business semantic intent and meet the current resource availability constraints. Furthermore, since the scheduling decision is based on the joint judgment of business type and load status, the system can achieve cross-type differentiated distribution in multi-business mixed scenarios, effectively preventing the aggregation of similar high-load businesses due to blind scheduling, and significantly reducing the risk of local resource overload. In addition, this mechanism does not rely on frequent external API queries, and can improve scheduling accuracy and overall cluster resource utilization efficiency while ensuring business adaptability, thereby enhancing the system's stability and service quality assurance capabilities in sudden or periodic high-concurrency scenarios.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a server, cloud host, container management node, or cluster scheduling controller, or an electronic device capable of implementing the above functions, any scheduling service node in a distributed system, a Pod pre-allocation scheduling system, etc. The following description uses a Pod pre-allocation scheduling system as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Please refer to the Pod pre-allocation scheduling method proposed in the first embodiment of this application. Figure 1 The method includes steps S10 to S40: Step S10: In response to the application instance creation request, obtain the load status information of each Pod in the container cluster.

[0027] It should be noted that an application instance refers to a computing task unit that is dynamically created in a distributed business system to execute specific business logic, and has an independent running context and lifecycle. Examples include specific execution entities in various business scenarios such as microservice calls, batch processing jobs, real-time interactive sessions, and event-driven tasks.

[0028] Additionally, it should be noted that a Pod is the smallest schedulable computing unit in Kubernetes (K8s), typically encapsulating one or more tightly coupled containers to host specific business logic; load status information includes real-time metrics such as CPU utilization, memory usage, network throughput, the number of currently hosted instances, tags, and whether it is in an allocable state.

[0029] In many practical application scenarios, gaming services, due to their high concurrency, strong real-time requirements, and diverse gameplay types, place high demands on the system's perception capabilities and response accuracy. This embodiment uses a gaming scenario as an example for illustration. In this embodiment, the application instance can be a specific gameplay instance triggered by players or automatically generated by the system, such as a guild war, a dungeon challenge, or a limited-time event battlefield. Its operation typically relies on containerized game map servers and generates predictable resource load peaks within a short period of time.

[0030] Understandably, since different business types (such as different gameplay types in the aforementioned game scenario) often exhibit regular load fluctuations at different times, if scheduling decisions rely solely on general resource metrics (such as instantaneous CPU utilization), it is easy to concentrate a large number of new instances of the same type on the same node during high-concurrency periods, thereby causing local overload or even service degradation. Therefore, proactively pulling a full load status snapshot of each Pod in the container cluster before creating application instances can effectively avoid hotspot aggregation and improve the overall cluster resource utilization and service stability.

[0031] As a feasible implementation, a memory cache structure (RaidPodEntity) can be maintained through the Cache Management Module. This cache structure serves as the core state data source upon which the system's scheduling decisions rely, recording the load status information of each Pod in real time, including but not limited to the number of instances currently hosted by the Pod, CPU and memory resource usage, network resource usage, tags, and whether it is in an allocable state. This cache structure also maintains the mapping relationship between different business types (such as gameplay types) and their corresponding Pods, and provides unified data management capabilities. Based on this, an abstract interface for scheduling strategies oriented towards business types is further defined to standardize and encapsulate the Pod allocation logic corresponding to different business types. Taking a game scenario as an example, this interface can be concretized as an abstract interface for the gameplay instance scheduling mechanism (IRaidPodAllocationHandler), allowing various gameplays (such as guild wars, world bosses, and beginner dungeons) to independently define their scheduling rules through their respective strategy implementation classes, while a unified scheduling framework loads, routes, and executes them, thereby achieving modularity, scalability, and maintainability of the scheduling logic.

[0032] When an application instance creation request is received, the scheduler core (calBestPod) uniformly calls the Pod allocation interface (calBestPod API) to efficiently read the real-time status data of all current Pods from the memory cache structure, thereby initiating the scheduling decision process. This mechanism avoids directly accessing the Kubernetes API Server during each scheduling, significantly reducing scheduling latency and improving the overall throughput and response efficiency of the system.

[0033] It's important to note that the scheduler core is the central coordinator of the entire scheduling process. Its function is to organize and drive the complete decision-making chain from request reception to the return of the target Pod: After receiving a creation request containing information such as business type and application instance identifier, it first obtains a snapshot of the status of all Pods in the current cluster from the cache management module. Then, it queries the policy registry based on the business type to determine the corresponding target scheduling policy. Subsequently, it calls the specific implementation of the target scheduling policy to execute the allocation logic and finally outputs the optimal Pod. At the same time, if there are no available Pods, insufficient resources, or policy execution anomalies during the scheduling process, the scheduler core is also responsible for triggering preset degradation mechanisms, such as falling back to a general load balancing policy, selecting a suboptimal candidate node, or returning a clear scheduling failure response, to ensure the availability and stability of the system in abnormal scenarios.

[0034] The core responsibilities of the cache management module include: providing a complete CRUD (create, read, update, delete) interface for the RaidPodEntity cache, especially optimized for the high-frequency read requirements of the scheduler core and the state write requirements driven by replica lifecycle events; managing concurrent access control of the cache, ensuring data consistency in high-concurrency scenarios such as application instance creation and destruction through locking mechanisms or lock-free concurrent structures; and implementing state storage using a pure in-memory mechanism, that is, initializing it when the service starts (pulling the initial Pod list) and maintaining it at runtime, without relying on any external persistent components, to ensure that scheduling decisions are always based on the current real runtime state and to avoid interference from historical residual data to the scheduling logic.

[0035] As an example, during the service startup phase, the cache management module can proactively pull an initial Pod list from the Kubernetes API or service discovery and initialize the RaidPodEntity. Subsequently, all Pod state changes (including new instance allocation, instance release, and abnormal Pod exit) can be captured in real-time by the Instance LifecycleManager via an event-driven approach, and the updated information is pushed to the cache management module, thereby dynamically maintaining the load status and allocation relationships of each Pod in the RaidPodEntity. This mechanism ensures that scheduling decisions are always based on the latest and most accurate cluster operating state, avoiding scheduling deviations caused by state lag.

[0036] It should be noted that the Instance Lifecycle Manager is a core component in the system responsible for listening to and responding to application instance creation and destruction events. Its main responsibility is to trigger corresponding state synchronization operations at key nodes in the instance lifecycle (such as successful creation, running, and destruction completion).

[0037] This implementation adopts a memory-based management mechanism without any persistent storage, actively avoiding scheduling deviations caused by system restarts, node anomalies, or historical data residues. It forces the scheduler core to always make decisions based on the "real" operating state at this moment, thereby ensuring the accuracy and timeliness of scheduling results in a dynamically changing business environment.

[0038] Step S20: Determine the target scheduling strategy corresponding to the service type based on the service type of the application instance.

[0039] It should be noted that business type refers to a classification label used to characterize application instances in terms of functional semantics, resource demand patterns, service quality requirements, or runtime context. This label can originate from request metadata, configuration files, or service registration information. Different business types typically correspond to different resource consumption characteristics (such as CPU-intensive, memory-sensitive, high-concurrency short-term, etc.), SLA (Service-Level Agreement) levels, or scheduling preferences. The target scheduling strategy refers to the predefined Pod allocation rules for a specific business type. Its implementation must follow a unified scheduling strategy abstraction interface (such as IRAidPodAllocationHandler) to support the dynamic selection and execution of the strategy.

[0040] Traditional container schedulers (such as the default Kubernetes scheduler) primarily rely on real-time resource usage of nodes (e.g., CPU utilization, memory usage) for scheduling decisions. They lack the ability to perceive upper-layer business semantics (e.g., business type, service level, load characteristics), making it difficult to provide fine-grained resource matching for different businesses with varying resource requirements, concurrency characteristics, or service quality requirements. In contrast, this embodiment uses business type as a key input for scheduling decisions, enabling the system to dynamically route to the most suitable allocation logic. This ensures service quality while improving the overall resource utilization efficiency and scheduling consistency of the cluster.

[0041] As a possible implementation, before step S20, the method includes: querying a pre-configured policy registry according to the service type of the application instance to obtain the target scheduling policy associated with the service type; wherein, the policy registry stores the mapping relationship between each service type and the corresponding scheduling policy.

[0042] In this implementation, during the system startup phase, the Strategy Factory and Registry automatically scan and load all implementation classes of the IRaidPodAllocationHandler interface. Based on this, they associate business types with their corresponding policy handlers, thus constructing a policy registry. This policy registry can be understood as a mapping table with business types as keys and policy instances as values. When the scheduler core receives an instance creation request containing the business type, it can quickly find the matching target scheduling policy based on this policy registry and call its allocation logic to complete the scheduling decision, thereby achieving dynamic routing and decoupled management of policies.

[0043] Specifically, the system supports a variety of scalable scheduling strategies to adapt to the needs of different business scenarios. The scheduling strategies include: (1) Affinity Strategy: This strategy directs application instances to dedicated pods with corresponding attributes based on predefined tags or pod identifiers. For example, in a game scenario, high-value gameplay (such as limited-time paid event instances) can be forcibly routed to pods with specific tags to ensure their resource exclusivity and service quality.

[0044] (2) Balancing Strategy: This strategy aims to evenly distribute similar service instances across multiple Pods to avoid localized overload. It is implemented using two modes: hash-based balancing and group-based balancing. Hash balancer: This method deterministically assigns an instance to a specific Pod by hashing the unique identifier of the application instance (such as a replica ID) and then taking the modulo of the current number of available Pods (i.e., hash(RaidID)%PodCount). This method maintains a relatively stable allocation result even after the service restarts, which is beneficial for cache reuse and state locality.

[0045] It should be noted that RaidID refers to the replica ID.

[0046] Group balancing: Real-time statistics are collected on the number of similar instances already hosted on each Pod, and the Pod with the lowest current load (e.g., fewest instances) is prioritized for allocation, ensuring that the distribution of similar services across the cluster is as balanced as possible. For example, the number of replicas of the same type of gameplay is kept roughly equal on different Pods, thereby avoiding local overload caused by centralized scheduling of a certain type of high-concurrency gameplay due to a small number of nodes.

[0047] (3) Randomized Strategy: This is not used independently, but rather as a supplementary mechanism to the strategies mentioned above. When the balanced distribution strategy selects multiple optimal candidate Pods with comparable loads, the system introduces random selection (e.g., through a pseudo-random number generator, Random) into a subset of candidate Pods to randomly select one candidate Pod as the final target Pod. This design effectively breaks the "herding effect" that may be caused by purely deterministic scheduling—that is, a large number of concurrent requests will concentrate on the same node due to the same judgment logic, thereby improving the overall robustness and anti-burst capability of scheduling.

[0048] As an example, in a gaming scenario, business types can be specifically embodied in gameplay types such as "new player tutorial," "world boss," "cross-server competition," and "guild wars." Among these, "high-value gameplay" (such as limited-time paid events) can be associated with a specific Pod matching strategy (Affinity Strategy), forcibly scheduling to dedicated Pods with specific tags; while "ordinary daily dungeons" adopt a balanced distribution strategy (Balancing Strategy) to ensure that similar instances are evenly distributed across multiple Pods. In non-gaming scenarios, such as "flash sale tasks" and "ordinary order processing" during e-commerce promotions, high-priority affinity strategies and load balancing strategies can be respectively applied, demonstrating the general applicability of this embodiment.

[0049] This embodiment achieves a decoupled design between business semantics and scheduling logic. The core of the scheduler does not hardcode any specific strategy, but implements plug-and-play strategies through interface abstraction and registration mechanisms. This allows the system to only extend the strategy implementation and register when faced with new business types, without modifying the main scheduling process, which significantly improves the maintainability and scalability of the architecture.

[0050] Step S30: Based on the target scheduling policy and the load status information of each Pod, determine the target Pod from the container cluster.

[0051] It should be noted that the target Pod refers to the Pod node that is most suitable for hosting the current application instance after being selected through a comprehensive evaluation of the target scheduling strategy.

[0052] Understandably, if scheduling relies solely on a single metric (such as minimum CPU utilization) or static rules, it can easily trigger a "herding effect" in high-concurrency scenarios, where a large number of requests simultaneously flood the same momentarily low-load node, leading to local overload or even service avalanche. This implementation combines real-time load status with business-driven strategy logic and introduces random perturbations within the candidate subset, effectively distributing scheduling pressure and improving system robustness and fairness.

[0053] In this embodiment, the specific strategy implementation can combine various filtering and sorting logics according to business needs: for example, the balanced distribution strategy first filters out the candidate Pod set that meets the tag matching and resource threshold, then sorts them in ascending order according to the current number of supported instances, and selects the candidate Pod with the lowest load as the target Pod; if there are multiple optimal candidate Pods with the same load, a randomized perturbation strategy is further introduced, and a Pod is randomly selected from the subset as the target Pod by using pseudo-random numbers, thus breaking the aggregation risk that deterministic allocation may bring.

[0054] As an example, in gaming scenarios, for gameplay that emphasizes session consistency (such as team dungeons), a deterministic distribution based on replica ID hashes can be used to improve cache locality and player experience. For high-concurrency, stateless gameplay (such as world events), the Pod with the fewest current instances is prioritized, and random perturbations are used to prevent extreme load skew. Similar logic can be applied to other areas, such as scheduling real-time video transcoding tasks to nodes with abundant GPU resources and low network latency, while avoiding multiple tasks being concentrated on the same physical machine.

[0055] Step S40: Assign the application instance to the target Pod.

[0056] It should be noted that the allocation operation refers to establishing a binding relationship between the application instance's metadata (including unique identifier, business type, resource configuration requirements, lifecycle expectations, etc.) and the target Pod, and notifying the underlying container orchestration system (such as Kubernetes) to execute actual scheduling instructions or state synchronization.

[0057] It is understandable that if the global scheduling view is not updated in a timely manner after allocation, subsequent scheduling requests may make incorrect judgments based on outdated Pod load information, thereby causing resource over-allocation or allocation imbalance. Therefore, this embodiment also needs to form a closed loop with the state recycling mechanism to ensure that the internal state of the scheduling system is always synchronized with the actual external operating state.

[0058] As a feasible implementation method, after successfully identifying the target Pod, the replica lifecycle manager immediately calls the write interface of the cache management module to write the mapping relationship between the application instance and the target Pod into the memory cache structure RaidPodEntity, and synchronously updates the instance count, resource usage estimate and allocable status of the target Pod.

[0059] As an example, in a game scenario, when a "guild war" instance is successfully scheduled to a Pod by calBestPod, the replica lifecycle manager will listen for the scheduling event and notify the cache management module to update the RaidPodEntity, for example, by incrementing the replica count of the Pod and reducing its allocable capacity accordingly. If Kubernetes subsequently reports that the Pod failed to start the instance due to abnormal exit, the replica lifecycle manager will also capture the failure event, actively trigger a state rollback (such as decrementing the replica count by 1), and perform retry (such as rescheduling to the suboptimal Pod) or degradation processing (such as returning a scheduling failure) according to the preset strategy, thereby ensuring that the memory cache state is always consistent with the actual running state.

[0060] As another feasible implementation, step S40 is followed by: in response to the release request of the application instance, reclaiming the resources occupied by the application instance from the load status information of the target Pod.

[0061] It's important to note that application instance release requests are typically triggered by business logic (e.g., replica battle ends, session timeout) or by system anomaly detection mechanisms (e.g., instance crash, health check failure), indicating that the instance is no longer running or is about to terminate. If the resource quota it occupies in the scheduling view is not released in a timely manner, the Pod's load status will be continuously overestimated, affecting the accuracy of subsequent scheduling decisions and potentially leading to resource waste or false overload.

[0062] As a feasible implementation, upon detecting an instance release event, the replica lifecycle manager immediately calls the update interface of the cache management module to remove the resource usage corresponding to the instance (such as decrementing the instance count by 1 and rolling back the estimated CPU / memory usage) from the target Pod's load status in the RaidPodEntity. This operation needs to be synchronized with the actual destruction status of the underlying container orchestration system to ensure consistency between "logical reclamation" and "physical release"; for example, the state change is only committed after confirming that the Pod has successfully terminated the container to prevent resource over-allocation due to premature release.

[0063] As an example, after a "guild war" instance ends, the system receives a release request for the application instance. The instance lifecycle manager then triggers a resource reclamation process: decrementing the instance count of the originally allocated Pod by 1 and simultaneously releasing its estimated CPU, memory, and other resources. Subsequently, if the remaining available resources of the Pod after the update meet a preset resource threshold, it can be immediately reinstated into the candidate Pod set for new application instances and participate in subsequent scheduling decisions, thereby significantly improving the utilization of cluster resources.

[0064] This implementation method completes the entire closed loop from strategy decision-making to state implementation. It not only implements the scheduling results, but also provides a reliable state basis for subsequent dynamic correction (such as elastic scaling), real-time monitoring and resource recovery. It is a key link to ensure the long-term stable operation of the entire scheduling system.

[0065] This embodiment effectively solves the problems of traditional schedulers, such as being unaware of business semantics (having no idea whether the business logic running within a Pod is "guild war" or "newbie task"), being prone to hotspot nodes, and having limited scalability, by using business type as the core input for scheduling decisions, combined with a pure memory-based real-time state cache, a pluggable abstract architecture, and an anti-aggregation mechanism that introduces random perturbations. Whether in high-concurrency, multi-type mixed game server clusters or in diverse business scenarios such as e-commerce, finance, and media, this solution can significantly improve the stability of load balancing, resource utilization efficiency, and business carrying capacity elasticity.

[0066] Based on the above embodiments of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Before step S10, the Pod pre-allocation scheduling method further includes steps S101 to S103: Step S101: Obtain the historical load data of the container cluster and the resource usage data of historical application instances corresponding to different business types.

[0067] Step S102: Based on the historical load data and the resource usage data, predict the expected resource requirements of each of the aforementioned business types within a future preset time period.

[0068] Step S103: Based on the expected resource requirements, pre-allocate the schedulable Pod resources in the container cluster.

[0069] It's important to note that historical load data refers to time-series data of resource metrics for nodes or Pods recorded in the container cluster's past runtime cycles, including CPU utilization, memory usage, network throughput, and instance concurrency. Historical application instance resource usage data, on the other hand, refers to the total or peak resources consumed by completed application instances during their lifecycle, categorized by business type. For example, a certain type of gameplay instance might average 0.8 CPU cores and 1.2GB of memory for 5 minutes. This data typically originates from monitoring systems (such as Prometheus), log platforms, or the scheduler's own status logs.

[0070] Additionally, it should be noted that expected resource demand refers to the system's estimation of the total resource consumption or number of concurrent instances that various services may generate within a specific future time period (such as the next 30 minutes, the next hour, or the next activity window) based on historical patterns; pre-allocation refers to reserving or creating Pod resource capacity for different service types in advance at the scheduling level before actual application instances are created, based on the prediction results, rather than creating instances immediately. Its essence is a "resource quota pre-occupancy" mechanism used to guide the priority and distribution strategy of subsequent real-time scheduling.

[0071] Pod scheduling and scaling are typically based on real-time resource load on nodes. When node resource pressure reaches a preset threshold, the system triggers scaling and schedules new Pods according to the current load status of each node. However, this method relies on instantaneous resource status and lacks prediction of business traffic trends. In scenarios with sudden traffic surges, the system must wait until resources are close to the bottleneck before initiating scaling, and the scaling process itself has a delay, causing the system to be unable to allocate sufficient resources in time during periods of rapid traffic growth, thus affecting service response performance. Therefore, this embodiment analyzes historical load data of the container cluster and the resource usage characteristics of historical application instances corresponding to different business types to predict the expected resource requirements of various businesses within a preset time period in the future, and logically pre-allocates schedulable Pod resources accordingly. Although this pre-allocation result does not immediately create physical Pods, it is injected into the scheduling cache (such as RaidPodEntity) in the form of quotas or weights, guiding subsequent real-time scheduling to prioritize resources for high-demand businesses, while providing a pre-trigger signal for the automatic scaling controller. As a result, the system can complete resource preparation before the arrival of traffic peaks, transforming passive response scheduling into proactive planning scheduling, significantly improving the system's capacity to handle sudden or periodic business loads and the level of service quality assurance.

[0072] As a feasible implementation method, the system can integrate time-series forecasting models and analyze historical load data in conjunction with business calendars (such as fixed event schedules in games or e-commerce promotional schedules). For example, if a certain "World Boss" gameplay starts precisely at 20:00 every Friday night, and historical data shows that it generates an average of 200 concurrent replicas per session, the system can automatically predict at 19:50 every Friday that approximately 200 high-load instances will need to be scheduled during that period, and calculate the total amount of Pod resources required accordingly.

[0073] As an example, in the gaming business scenario, different gameplay modes exhibit highly predictable temporal regularities: new player tutorials are concentrated during the initial login period, guild wars are fixed at a specific time each week, and holiday events can be pre-configured according to the operational plan. This regularity makes resource demand prediction based on historical data highly accurate. The system can vectorize features such as the number of historical instances, average resource consumption, and duration for each gameplay type and input them into the time-series prediction model to output the resource demand within the future window.

[0074] Specifically, the system can periodically execute prediction and pre-allocation logic (e.g., triggered every 10 minutes) by acquiring historical cluster load data for the most recent few days (e.g., 7 days) and resource usage records of application instances categorized by business type. Subsequently, the historical cluster load data is aggregated by business type to generate feature snapshots containing dimensions such as instance frequency, average resource consumption, and duration, which are then input into the time series prediction model to output the expected resource requirements for various business types in the next 30 minutes to 2 hours.

[0075] Furthermore, the prediction results will be transformed into logical-level Pod resource quota recommendations. For example, reserving three dedicated Pods with specific tags for "high-value activities," or dynamically allocating a general Pod resource pool accounting for 60% of the cluster for "normal replicas." This quota information does not directly create or lock physical Pods, but is written as metadata into the RaidPodEntity structure maintained by the cache management module as a reference for subsequent real-time scheduling. When selecting target Pods, the scheduler core can prioritize Pod nodes with matching quotas, or perform weighted filtering based on pre-allocation ratios when resources are scarce, thereby improving the foresight and coordination of overall resource utilization while ensuring the carrying capacity of critical business operations.

[0076] It's understandable that pre-allocation is not a physical resource lock-in, but rather a logical scheduling guide. For example, the system can mark certain Pods in a RaidPodEntity as a "high-value usage reserve pool," allowing them to handle low-priority tasks during off-peak hours. However, when a peak is predicted to approach (e.g., 5 minutes in advance), they are automatically switched to "dedicated mode," rejecting scheduling requests for non-target business types. This elastic pre-allocation mechanism avoids resource idleness while ensuring the carrying capacity of critical business operations.

[0077] This embodiment upgrades the originally passive response scheduling mode to a hybrid mode of proactive planning and dynamic correction by introducing a load prediction and resource pre-allocation mechanism based on historical patterns. This not only significantly improves the system's ability to cope with predictable business peaks and reduces decision delays and allocation deviations under sudden scheduling pressure, but also enhances the overall resource planning foresight and service quality assurance level of the cluster. It is especially suitable for scenarios with highly periodic and deterministic business rhythms (such as games, scheduled batch processing, marketing activities, etc.).

[0078] Based on the above embodiments of this application, in the third embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 In the Pod pre-allocation scheduling method, step S30 includes steps S310 to S340: Step S310: Based on the load status information of each Pod, select a set of candidate Pods that meet the preset resource thresholds. The preset resource thresholds include the remaining CPU capacity, remaining memory capacity, and maximum number of instances that the candidate Pods can support.

[0079] It should be noted that the preset resource thresholds refer to the upper limits of resource usage set by the system to ensure the stable operation of Pods. These include the remaining CPU capacity being greater than the capacity threshold (e.g., 0.5 cores), the remaining available memory being greater than the memory threshold (e.g., 512MB), and the number of currently hosted instances not reaching the maximum concurrent capacity configured for the Pod (e.g., a maximum of 10 replicas). These thresholds can be statically configured or dynamically adjusted based on Pod tags or business levels.

[0080] Step S320: If the target scheduling policy is a specific Pod matching policy, then select the dedicated Pod corresponding to the business type of the application instance from the candidate Pod set as the target Pod.

[0081] It should be noted that a dedicated Pod refers to a Pod that is explicitly marked by tags or metadata as serving only a specific business type, such as a Pod with priority: high. These Pods are typically used to host high-value, highly sensitive, or resource-intensive business instances.

[0082] Step S330: If the target scheduling strategy is a balanced distribution strategy, then perform a hash operation based on the identification information of the application instance, and determine the target Pod from the candidate Pod set according to the operation result.

[0083] Step S340: If the target scheduling policy is a randomized perturbation policy, then randomly select one of the candidate Pods from the candidate Pod set as the target Pod.

[0084] In this embodiment, the scheduler core first traverses all Pod state snapshots provided by the cache management module, verifying each one to see if it meets the resource requirements of the current application instance; only Pods that meet the preset resource threshold are included in the candidate set. During the screening process, the RaidPodEntity structure establishes an index or sorted view for key indicators, thereby avoiding the performance overhead of a full linear scan.

[0085] If the target scheduling policy is a specific Pod matching policy, the system will further check whether there are any dedicated tags in the candidate Pod set that match the current business type. If there are multiple matching candidate Pods, the least idle one can be selected in ascending order of load, or any one can be selected directly (because dedicated Pods are usually limited in number and have a clear purpose). This mechanism ensures that high-priority businesses always run in the resource environment reserved for them, improving service isolation and SLA guarantee capabilities.

[0086] Specifically, step S330 includes steps S3310 to S3330: Step S3310: Perform a consistent hash operation on the identification information of the application instance to obtain a hash value.

[0087] Step S3320: Number each candidate Pod in the candidate Pod set that matches the business type of the application instance according to a preset order, and map them to the corresponding positions on the hash ring.

[0088] Step S3330: Based on the hash value, find the first corresponding candidate Pod in a clockwise direction on the hash ring, and use it as the target Pod.

[0089] It should be noted that consistent hashing is a commonly used load balancing algorithm in distributed systems. Its core is to map resources (here, Pods) and requests (here, application instances) together into a virtual circular hash space (i.e., a hash ring), and achieve deterministic binding of requests to resources by searching clockwise.

[0090] In this embodiment, the identification information of the application instance (such as replica ID or session ID, where session ID refers to the unique identifier requested by the user) is calculated by a consistent hash function (such as MD5, SHA-1 or MurmurHash) to obtain an integer value within a fixed range, which serves as its position on the ring; and each candidate Pod is also mapped to one or more virtual node positions on the ring according to its number or unique identifier (such as Pod name or UID).

[0091] Optionally, Pod numbers can be generated based on the lexicographical order of their names (i.e., sorted lexicographically by string order), creation timestamps, or preset configuration order to ensure that the mapping relationship remains stable during multiple scheduling processes. To improve load balancing, multiple virtual nodes can be allocated on the hash ring for each physical Pod, thereby alleviating the problem of uneven instance distribution caused by a small number of actual Pods.

[0092] It is understood that in this embodiment, the balanced distribution strategy adopts a consistent hashing mechanism instead of the aforementioned modulo operation (such as hash(RaidID)%PodCount). Its advantage is that when the number of Pods in the cluster changes (such as scaling up or down, node failure), it only affects the mapping relationship of a local area on the hash ring. The vast majority of existing instances can still maintain the original scheduling result, thereby significantly reducing the overhead of cache invalidation, state migration or connection reconstruction caused by dynamic changes of Pods.

[0093] Optionally, the balanced distribution strategy can also adopt group balancing logic, which counts the number of similar instances already hosted on each Pod in real time, and prioritizes the Pod with the lowest current load (e.g., the fewest number of instances) for allocation, so as to ensure that the distribution of similar services in the cluster is as balanced as possible.

[0094] Specifically, step S340 includes steps S3410 to S3430: Step S3410: Obtain the load status information of each candidate Pod in the candidate Pod set.

[0095] Step S3420: Sort the candidate Pod set according to the load status information of the candidate Pods, and select a preset number of candidate Pods with the highest sorting to obtain an optimal subset.

[0096] Step S3430: Randomly select one of the candidate Pods from the preferred subset as the target Pod.

[0097] It should be noted that the sorting here can be based on comprehensive load indicators, such as ascending order of the number of currently supported instances and descending order of remaining CPU / memory, or using a weighted scoring model to quantitatively evaluate the multi-dimensional resource status; the preset number (such as the top 3 or top 5) can be dynamically configured according to the cluster size or business sensitivity to ensure that the preferred subset has both low load advantages and sufficient random space.

[0098] In this embodiment, the randomization perturbation strategy is not an independent master strategy, but rather a supplementary mechanism to the balanced distribution strategy or other deterministic strategies. When multiple Pods have similar resource usage levels (e.g., the same number of instances, and the difference in remaining resources is less than a preset tolerance threshold), if a completely deterministic selection method is still used (e.g., always choosing the first one), a large number of concurrent requests may be concentrated on the same node due to the same input, causing local overload. By introducing the above two-stage mechanism, a preset number of optimal candidate Pods are first selected, and then random decisions are made within them. The system can ensure that the selected Pods are in a low-load state as a whole, and can effectively break the determinism of the scheduling path, significantly mitigating the "herding effect".

[0099] As an example, in a high-concurrency replica creation scenario, if 10 Pods all meet the resource threshold and have 5 instances each, the top 3 are sorted and selected as the preferred subset. Then, one Pod is randomly selected from these subsets for instance allocation. This avoids all requests flooding the first Pod and ensures that a node with significantly higher load is not mistakenly selected. This design maintains scheduling quality while enhancing the system's load distribution capability and stability under sudden traffic surges.

[0100] As another feasible implementation, the system can also adopt a policy-first scheduling order. This means that instead of pre-filtering all Pods with uniform resource thresholds, it first directly determines a preliminary candidate set or target Pod based on the semantics of the target scheduling policy. Then, it determines whether the target Pod or candidate set can support the current instance based on its real-time load status information. For example, when the target scheduling policy is a specific Pod matching policy, the system can directly locate the dedicated Pod list bound to the business type and only check the resource availability of Pods in that dedicated Pod list. If the target scheduling policy is a balanced distribution policy, the theoretical target Pod can be determined first through hash calculation, and then its current remaining CPU, memory, and instance capacity can be verified to meet the requirements. If not, it falls back to other Pods in the same group or triggers expansion. The advantage of this approach is that it avoids a global scan of irrelevant Pods, significantly reducing computational overhead in dedicated scheduling or deterministic allocation scenarios. Furthermore, for dedicated Pod clusters with clear labels and sufficient resource reservations, there is no need to overly rely on dynamic threshold judgments.

[0101] This embodiment first establishes a security scheduling baseline through unified resource filtering, and then dynamically routes to different allocation logics based on business semantics. The entire process is executed entirely based on the real-time state in the memory cache, without the need for external I / O, resulting in low decision latency. Furthermore, the paths of each strategy are orthogonal to each other and can be combined and extended.

[0102] Based on the above embodiments of this application, in the fourth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4In the Pod pre-allocation scheduling method, step S40 includes steps S410 to S430: Step S410: Send an application instance mount command to the target Pod to complete the deployment and startup of the application instance on the target Pod.

[0103] It's important to note that the application instance mount command is a control command used to guide the target Pod in deploying and starting the application instance. Specifically, it includes key parameters such as the configuration information required by the application instance, the container image address, and environment variables, ensuring that the application can run correctly in the specified environment.

[0104] As a feasible implementation, before sending the application instance mount command to the target Pod, the system first verifies whether the target Pod is ready to accept the new application instance, including checking its network connectivity, storage resources, and any unhandled faults. Once confirmed, the system sends the application instance mount command via the Kubernetes API or a similar interface, triggering the automated deployment process within the target Pod.

[0105] Step S420: Obtain resource usage data after the application instance is deployed.

[0106] It should be noted that resource usage data refers to the amount of various computing resources consumed by an application instance after it has been deployed and running on the target Pod for a period of time. These mainly include metrics such as CPU utilization, memory usage, disk I / O operation frequency, and network bandwidth usage.

[0107] In this embodiment, resource usage data of application instances can be collected in real time by integrating monitoring tools such as Prometheus and Grafana. Alternatively, relevant information can be obtained directly from the cluster level using Kubernetes' built-in resource monitoring API.

[0108] Step S430: Update the load status information of the target Pod based on the resource usage data.

[0109] In this embodiment, after each new resource usage data is obtained, the new load state of the target Pod is immediately calculated and updated to the state cache of the scheduler core.

[0110] This embodiment enables real-time tracking and closed-loop feedback of resource usage for application instances from deployment to operation, significantly improving the transparency of resource usage within a single Pod. By collecting actual resource usage data immediately after an application instance starts and updating the load status information of the target Pod to a memory cache (such as RaidPodEntity) in real time, subsequent scheduling decisions can be based on the latest and most accurate cluster operating status. This avoids new instances being incorrectly assigned to overloaded nodes due to reliance on outdated or estimated data, effectively preventing excessive resource concentration, local overload, and the resulting service quality degradation or request failures. This mechanism not only enhances the accuracy and timeliness of the scheduling system but also provides stronger stability and elastic scaling capabilities for high-concurrency, dynamically changing business environments.

[0111] This application provides a Pod pre-allocation scheduling device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the Pod pre-allocation scheduling method in the above embodiment 1.

[0112] The following is for reference. Figure 5 This diagram illustrates a structural schematic of a Pod pre-allocation scheduling device suitable for implementing embodiments of this application. The Pod pre-allocation scheduling device in embodiments of this application may include various hardware and software components for implementing the Pod pre-allocation scheduling method. Figure 5 The Pod pre-allocation scheduling device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0113] like Figure 5As shown, the Pod pre-allocation scheduling device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the Pod pre-allocation scheduling device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the Pod pre-allocation scheduling device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows Pod pre-allocation scheduling devices with various systems, it should be understood that implementation or having all of the systems shown is not required. More or fewer systems may be implemented alternatively.

[0114] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0115] The Pod pre-allocation scheduling device provided in this application, employing the Pod pre-allocation scheduling method in the above embodiments, can solve the technical problem of single-node overload caused by the current scheduling mechanism's inability to identify service types, resulting in the concentrated deployment of similar high-load services on the same node. Compared with the prior art, the beneficial effects of the Pod pre-allocation scheduling device provided in this application are the same as those of the Pod pre-allocation scheduling method provided in the above embodiments, and other technical features in this Pod pre-allocation scheduling device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0116] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0117] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0118] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the Pod pre-allocation scheduling method in the above embodiments.

[0119] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0120] The aforementioned computer-readable storage medium may be included in the Pod pre-allocation scheduling device; or it may exist independently and not be assembled into the Pod pre-allocation scheduling device.

[0121] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the Pod pre-allocation scheduling device, the Pod pre-allocation scheduling device: in response to an application instance creation request, obtains the load status information of each Pod in the container cluster; determines a target scheduling policy corresponding to the business type of the application instance; determines a target Pod from the container cluster based on the target scheduling policy and the load status information of each Pod; and allocates the application instance to the target Pod.

[0122] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0125] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described Pod pre-allocation scheduling method. This solves the technical problem of single-node overload caused by the current scheduling mechanism's inability to identify service types, leading to the concentrated deployment of similar high-load services on the same node. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the Pod pre-allocation scheduling method provided in the above embodiments, and will not be elaborated upon here.

[0126] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the Pod pre-allocation scheduling method described above.

[0127] The computer program product provided in this application can solve the technical problem of single-node overload caused by the current scheduling mechanism's inability to identify service types, resulting in the concentrated deployment of similar high-load services on the same node. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the Pod pre-allocation scheduling method provided in the above embodiments, and will not be repeated here.

[0128] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

[0129] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0130] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0131] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A Pod pre-allocation scheduling method, characterized in that, The Pod pre-allocation scheduling method includes: In response to the application instance creation request, obtain the load status information of each Pod in the container cluster; Based on the service type of the application instance, determine the target scheduling strategy corresponding to the service type; Based on the target scheduling policy and the load status information of each Pod, the target Pod is determined from the container cluster; Assign the application instance to the target Pod.

2. The Pod pre-allocation scheduling method as described in claim 1, characterized in that, Before the step of determining the target scheduling strategy corresponding to the service type based on the service type of the application instance, the Pod pre-allocation scheduling method further includes: Based on the service type of the application instance, query the pre-configured policy registry to obtain the target scheduling policy associated with the service type; The policy registry stores the mapping relationship between each service type and its corresponding scheduling policy.

3. The Pod pre-allocation scheduling method as described in claim 1, characterized in that, Before the step of obtaining the load status information of each Pod in the container cluster in response to the application instance creation request, the Pod pre-allocation scheduling method further includes: Obtain historical load data of the container cluster, as well as resource usage data of historical application instances corresponding to different business types; Based on the historical load data and the resource usage data, predict the expected resource requirements of each of the aforementioned business types within a future preset time period; Based on the expected resource requirements, schedulable Pod resources in the container cluster are pre-allocated.

4. The Pod pre-allocation scheduling method as described in claim 1, characterized in that, The step of determining the target Pod from the container cluster based on the target scheduling policy and the load status information of each Pod includes: Based on the load status information of each Pod, a set of candidate Pods that meet the preset resource thresholds is selected. The preset resource thresholds include the remaining CPU capacity, remaining memory capacity, and maximum number of instances that the candidate Pods can support. If the target scheduling strategy is a specific Pod matching strategy, then the dedicated Pod corresponding to the business type of the application instance is selected from the candidate Pod set and used as the target Pod; If the target scheduling strategy is a balanced distribution strategy, then a hash operation is performed based on the identification information of the application instance, and the target Pod is determined from the candidate Pod set according to the operation result; If the target scheduling policy is a randomized perturbation policy, then one of the candidate Pods is randomly selected from the candidate Pod set as the target Pod.

5. The Pod pre-allocation scheduling method as described in claim 4, characterized in that, If the target scheduling policy is a randomized perturbation policy, the step of randomly selecting a candidate Pod from the candidate Pod set as the target Pod includes: Obtain the load status information of each candidate Pod in the candidate Pod set; Based on the load status information of the candidate Pods, the candidate Pod set is sorted, and a preset number of the top-ranked candidate Pods are selected to obtain an optimal subset; One candidate Pod is randomly selected from the preferred subset as the target Pod.

6. The Pod pre-allocation scheduling method as described in claim 4, characterized in that, If the target scheduling strategy is a balanced distribution strategy, then the step of performing a hash operation based on the identification information of the application instance and determining the target Pod from the candidate Pod set according to the operation result includes: Perform a consistent hash operation on the identification information of the application instance to obtain a hash value; Each candidate Pod in the candidate Pod set that matches the business type of the application instance is numbered in a preset order and mapped to the corresponding position on the hash ring; The first corresponding candidate Pod is found clockwise on the hash ring based on the hash value, and this candidate Pod is selected as the target Pod.

7. The Pod pre-allocation scheduling method as described in claim 1, characterized in that, The step of assigning the application instance to the target Pod includes: Send an application instance mount command to the target Pod to complete the deployment and startup of the application instance on the target Pod; Obtain the resource usage data after the application instance is deployed; Based on the resource usage data, update the load status information of the target Pod.

8. The Pod pre-allocation scheduling method as described in claim 1, characterized in that, After the step of allocating the application instance to the target Pod, the Pod pre-allocation scheduling method further includes: In response to the release request of the application instance, the resources occupied by the application instance are reclaimed from the load status information of the target Pod.

9. A Pod pre-allocation scheduling device, characterized in that, The Pod pre-allocation scheduling device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the Pod pre-allocation scheduling method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the Pod pre-allocation scheduling method as described in any one of claims 1 to 8.

Images