Resource scheduling method, system and equipment of cloud container and storage medium

Abstract

The invention relates to the technical field of intelligent driving, and particularly provides a resource scheduling method, system and device for a cloud container and a storage medium, and the method comprises the steps: obtaining vehicle state data, container operation indexes and environment context data; constructing a space-time diagram with the vehicle as a node and the space-time relation as an edge based on the state data; inputting the time-space diagrams and related data into a combined prediction model, and predicting future container resource demands and cold start risk scores of the vehicles; according to the prediction result, the vehicles are dynamically clustered into cooperative scheduling units, and dynamic priorities are allocated to unit inner containers; and based on the priority, performing resource pre-allocation and shared scheduling among the containers by using a resource bond mechanism, and triggering an active preheating operation on the high cold start risk container. According to the invention, accurate resource demand prediction and cooperative scheduling are realized, the resource utilization rate is effectively improved, and the real-time performance and reliability of intelligent driving service are guaranteed.

Description

Technical Field

[0001] This invention belongs to the field of intelligent driving technology, specifically relating to a resource scheduling method, system, device, and storage medium for cloud containers. Background Technology

[0002] Existing cloud computing resource allocation methods (such as virtual machine-level prediction and scheduling) have significant shortcomings when dealing with real-time demanding scenarios like autonomous driving. These methods typically rely on AI prediction of the overall workload and resource adjustments at the virtual machine level, failing to fully consider the characteristics of autonomous driving applications where containers are the smallest deployment unit. Containers are characterized by startup latency sensitivity, complex replica scheduling, and high-frequency, fine-grained load fluctuations. Existing technologies cannot accurately predict and dynamically allocate resource demands at the container level, resulting in high response latency and making it difficult to meet the stringent real-time requirements of autonomous driving tasks. Furthermore, traditional methods lack collaborative analysis of key factors such as the spatiotemporal relationships between vehicles and the driving environment context. Resource scheduling strategies are passive and isolated, failing to achieve proactive resource planning and cross-vehicle collaborative optimization. Summary of the Invention

[0003] In view of the above-mentioned shortcomings of the prior art, the present invention provides a resource scheduling method, system, device and storage medium for cloud containers to solve the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a resource scheduling method for cloud containers, comprising: Acquire status data, container operation metrics, and environmental context data of multiple vehicles in intelligent driving scenarios; A spatiotemporal graph is constructed based on the state data, where vehicles are nodes and spatial and temporal relationships between vehicles are edges. The spatiotemporal map, container operation indicators, and environmental context data are input into the combined prediction model to predict the container resource requirements and cold start risk scores of each vehicle in the future time period. Based on the container resource requirements and cold start risk score, vehicles are divided into collaborative scheduling units, and priority is assigned to containers within each collaborative scheduling unit. Based on the aforementioned priorities, a resource bond mechanism is used to pre-allocate and share resources among containers, and to trigger proactive preheating operations for containers with high cold start risk.

[0005] In one optional implementation, the status data of multiple vehicles, container operation metrics, and environmental context data in the intelligent driving scenario are acquired, including: Vehicle node characteristics are obtained from the data reported by vehicles in real time. The vehicle node characteristics include: real-time status data, container operation indicators, and driving habit identifiers. Global environmental features are obtained from the cloud-based traffic management and environmental perception system. These global environmental features include: driving environment information, weather conditions, time information, and information about vehicles ahead.

[0006] In an optional implementation, constructing a spatiotemporal graph based on the state data includes: Treat each intelligent vehicle in the current area as a node in the graph; Based on the relative distance, relative speed and driving relationship between vehicles, spatial edges between nodes are dynamically established. If the relative distance between two vehicles is lower than a preset threshold or there is a following or lane-changing relationship, a strong connection spatial edge is established. For each node, its state data sequence at multiple consecutive time steps is associated to form the node's own time edge.

[0007] In an optional implementation, the combined prediction model includes multiple modules connected in sequence: The spatiotemporal graph convolutional network module is used to receive the spatiotemporal graph, perform spatial convolution on the nodes in the graph to aggregate the features of neighboring vehicles, and perform temporal convolution to capture the short-term change patterns of the nodes themselves, thereby outputting spatiotemporal dependent features. The Long Short-Term Memory (LSTM) network module is used to receive the historical container operation index sequence of each vehicle, learn long-term time dependencies, and output temporal dependency features. The attention fusion module is used to receive the spatiotemporal dependent features, the temporal dependent features, and the environmental context vector encoded by the environmental context data, calculate the weight of each feature, perform weighted fusion, and output a comprehensive feature vector. The integrated feature vector is input to a fully connected output layer to predict the container resource requirements and the cold start risk score.

[0008] In an optional implementation, the spatiotemporal map, container operation metrics, and environmental context data are input into a combined prediction model to predict the container resource requirements and cold start risk scores for each vehicle in future time periods, including: The constructed spatiotemporal graph is input into the spatiotemporal graph convolutional network module in the combined prediction model to extract the spatiotemporal dependency features between vehicles; The historical sequence of container operation indicators for each vehicle is input into the long short-term memory network module in the combined prediction model to extract long-term temporal dependency features. The spatiotemporal dependency features, the long-term temporal dependency features, and the encoded environmental context data are concatenated. The weights of each part in the spliced ​​features are calculated by the attention fusion module in the combined prediction model and then weighted and fused to generate a comprehensive feature vector. The integrated feature vector is input into the fully connected network of the output layer, and regression prediction is used to obtain the container resource requirements of each vehicle in the next 5 to 60 seconds and a cold start risk score between 0 and 1.

[0009] In an optional implementation, vehicles are divided into collaborative scheduling units based on the container resource requirements and cold start risk scores, and priorities are assigned to containers within each collaborative scheduling unit, including: Vehicle nodes with connection strengths higher than a preset threshold in the spatiotemporal graph are dynamically clustered to form at least one collaborative scheduling unit, wherein the connection strength is determined based on the relative distance and relative speed between vehicles. For each collaborative scheduling unit, the predicted resource demand of all vehicles within it within the future time window is aggregated to generate a unit-level resource demand curve, and the cold start risk score timeline of each vehicle is integrated. Based on the cold start risk score timeline and the unit-level resource demand curve, a dynamic priority score is calculated for the container corresponding to each vehicle in the unit according to the preset priority calculation formula, for use in subsequent resource scheduling decisions.

[0010] In an optional implementation, based on the priority, a resource bond mechanism is used to pre-allocate and share resources among containers, and to trigger an active preheating operation for containers with high cold start risk, including: Based on the predicted resource demand curves of each container within the collaborative scheduling unit, container pairs with mismatched peak resource demand times are identified, and resource bonds are generated for these container pairs. These bonds stipulate that the demand-side container can borrow the reserved resources of the supply-side container during peak times. When scheduling or rescheduling containers, container pairs with the aforementioned resource debt relationship are preferentially deployed to the same physical node or adjacent nodes directly connected via high-speed network to reduce resource allocation latency. For containers with dynamic priority higher than a preset risk threshold, an active preheating instruction is generated and issued. The execution of the instruction includes: pre-pulling the container image to the target node, preloading the associated model data into memory, or creating a container copy in a hot standby state on the target node.

[0011] Secondly, the present invention provides a resource scheduling system for cloud containers, comprising: The data acquisition module is used to acquire status data of multiple vehicles, container operation indicators, and environmental context data in intelligent driving scenarios. The graph construction module is used to construct a spatiotemporal graph based on the state data, where vehicles are nodes and spatial and temporal relationships between vehicles are edges. The demand forecasting module is used to input the spatiotemporal map, container operation indicators and environmental context data into the combined forecasting model to predict the container resource demand and cold start risk score of each vehicle in the future time period. The priority allocation module is used to divide vehicles into collaborative scheduling units based on the container resource requirements and cold start risk scores, and to assign priorities to containers within each collaborative scheduling unit. The resource scheduling module is used to pre-allocate and share resources among containers based on the priority and using a resource bond mechanism, and to trigger an active preheating operation for containers with high cold start risk.

[0012] Thirdly, a device is provided, comprising: Storage, used to store the resource scheduler for cloud containers; The processor, when executing the resource scheduler of the cloud container, implements the steps of the resource scheduling method for the cloud container as provided in the first aspect.

[0013] Fourthly, a computer-readable storage medium is provided, on which a resource scheduler for a cloud container is stored, wherein when the resource scheduler for the cloud container is executed by a processor, the resource scheduler implements the steps of the resource scheduling method for the cloud container provided in the first aspect.

[0014] The beneficial effects of this invention are as follows: the cloud container resource scheduling method, system, device, and storage medium provided by this invention significantly improve the accuracy and foresight of container resource demand prediction by integrating a collaborative prediction mechanism that combines vehicle spatiotemporal correlation and environmental context; the introduction of a dynamic priority and resource bond mechanism based on risk and correlation enables cross-vehicle and cross-container resource collaborative scheduling and peak shaving, greatly improving cloud resource utilization; and the proactive preheating and hot standby replica mechanism for cold start risk effectively eliminates container startup delay, ensuring high real-time performance and high reliability of intelligent driving services, and improving the overall service quality and resource efficiency of the system in dynamic and complex environments. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0017] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0021] The cloud container resource scheduling method provided in this embodiment of the invention is executed by a computer device, and correspondingly, the cloud container resource scheduling system runs on the computer device.

[0022] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The executing entity can be a cloud-based container resource scheduling system. Depending on different requirements, the order of the steps in this flowchart can be changed, and some steps can be omitted.

[0023] like Figure 1 As shown, the method includes: S1. Obtain status data, container operation indicators, and environmental context data of multiple vehicles in the intelligent driving scenario; S2. Construct a spatiotemporal graph based on the state data, where vehicles are nodes and spatial and temporal relationships between vehicles are edges; S3. Input the spatiotemporal diagram, container operation indicators and environmental context data into the combined prediction model to predict the container resource requirements and cold start risk scores of each vehicle in the future time period. S4. Based on the container resource requirements and cold start risk score, divide the vehicles into collaborative scheduling units and assign priorities to the containers within each collaborative scheduling unit; S5. Based on the aforementioned priority, a resource bond mechanism is used to pre-allocate and share resources among containers, and to trigger an active preheating operation for containers with high cold start risk.

[0024] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0025] S101. Vehicle Node Feature Collection: This step aims to acquire feature data characterizing the state and load of individual vehicles. Specifically, three types of key information are collected and reported in real time through agents or onboard edge computing units deployed on each intelligent vehicle. First, real-time status data, including but not limited to the vehicle's latitude and longitude position, instantaneous speed, acceleration, and heading angle obtained by sensors such as GPS and IMU. Second, container operation indicators, obtained by monitoring intelligent driving applications (such as perception and decision-making modules) running onboard or edge containers, mainly including CPU utilization, memory usage, and average latency and throughput of model inference tasks. Third, driving habit identifiers, which are multi-dimensional vector codes generated through clustering or sequence model learning of historical driving behavior data (such as acceleration change frequency, following distance preference, and lane-changing style). These identifiers are used to quantitatively distinguish between different driving styles, such as aggressive and conservative, serving as a long-term personalized basis for predicting resource demand patterns.

[0026] S102. Global Environmental Feature Integration: This step focuses on acquiring macro-contextual information affecting the entire vehicle group or a specific area. The system obtains structured environmental features in real time through API interaction or data stream subscription with cloud-based or roadside traffic management and environmental perception systems. These features mainly include: driving environment information, such as the current road type (highway, urban road), real-time traffic congestion index or events (accidents, construction); weather conditions, such as the type and intensity of sunny, rainy, snowy, and foggy conditions; time information, such as whether the current time is daytime, nighttime, or a specific peak period; and crucial information about vehicles ahead, including not only the identification of the vehicles ahead, but more importantly, the relative distance and relative speed obtained through V2V or roadside perception. This information directly constitutes the core input for subsequently constructing the vehicle-to-vehicle interaction relationship graph.

[0027] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0028] After obtaining state data from multiple vehicles, the system enters the spatiotemporal graph construction phase. The core objective of this phase is to map the dynamic, interconnected group of vehicles in the physical world into a structured graph data model containing spatiotemporal relationships, enabling efficient feature learning in subsequent models. The specific implementation includes the following key operations: First, define the graph nodes. The system abstracts each intelligent vehicle within the currently focused area (e.g., the geographical area covered by an edge computing node, or a logical fleet) as a node in the graph G=(V,E). Each node The system includes real-time status data of the vehicle, container operation indicators, and driving habit identifiers collected in step S101, which serve as the initial feature vector of the node.

[0029] Secondly, spatial edges are dynamically constructed. Used to characterize vehicles and The intensity of interaction in the spatial dimension is constructed dynamically and based on rules. The system calculates the relative distance between each pair of vehicles. and relative velocity Set a distance threshold. (For example, 150 meters), if If the two vehicles are considered to be within a potential interaction range, a preliminary connection is established. Further, by analyzing motion trajectories and intentions (e.g., by judging the difference in heading angle and relative speed direction), specific driving relationships are identified, such as stable following, lane changing, or overtaking. If a strong interaction relationship such as "following" or "lane changing" is identified, a strong spatial edge is established regardless of whether the distance slightly exceeds a threshold, and this edge is assigned a high weight value to explicitly encode this close mutual influence relationship. The edge weight can be quantified based on factors such as the reciprocal of the relative distance or the absolute value of the relative speed.

[0030] Finally, temporal edges are associated to form a spatiotemporal graph. To introduce the temporal dimension, the system associates each node... The feature vectors from multiple consecutive historical time steps (e.g., the past 5 seconds, one sampling point per second) are arranged chronologically to form the time series of a node. In graph representation, this is equivalent to establishing an intrinsic temporal edge connecting each node to its own state at different time steps, thus expanding the static spatial graph into a spatiotemporal graph. This spatiotemporal graph completely encapsulates the "spatial snapshot" of vehicles within a certain time region and their respective "historical state sequences," providing a basic data structure for the model to simultaneously capture spatial interactions and temporal evolution.

[0031] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0032] The combined prediction model consists of multiple modules connected in sequence: The spatiotemporal graph convolutional network module is used to receive the spatiotemporal graph, perform spatial convolution on the nodes in the graph to aggregate the features of neighboring vehicles, and perform temporal convolution to capture the short-term change patterns of the nodes themselves, thereby outputting spatiotemporal dependent features. The Long Short-Term Memory (LSTM) network module is used to receive the historical container operation index sequence of each vehicle, learn long-term time dependencies, and output temporal dependency features. The attention fusion module is used to receive the spatiotemporal dependent features, the temporal dependent features, and the environmental context vector encoded by the environmental context data, calculate the weight of each feature, perform weighted fusion, and output a comprehensive feature vector. The integrated feature vector is input to a fully connected output layer to predict the container resource requirements and the cold start risk score.

[0033] The combined prediction model, as the core of this method, employs an innovative multi-module collaborative architecture, aiming to deeply integrate spatial interaction, temporal evolution, and environmental context information. Its implementation process is as follows: First, model input and parallel feature extraction. The constructed spatiotemporal graph is input into the spatiotemporal graph convolutional network module. At each time step, this module first performs spatial graph convolution: for each vehicle node in the graph, it aggregates the features of all its neighboring nodes (such as the vehicle in front and the vehicle to the side) connected by spatial edges. This operation directly encodes the instantaneous impact of interactions such as sudden braking or lane merging by the vehicle in front on the vehicle's resource demand. Subsequently, a one-dimensional temporal convolution is performed along the temporal edge of each node to capture short-term load change patterns caused by behaviors such as acceleration and continuous turning. After multiple layers are stacked, this module outputs a spatiotemporal dependency feature vector containing complex spatiotemporal dependencies between vehicles. At the same time, the independent, long-term historical container operation index sequence of each vehicle (such as CPU and memory usage over the past 5 minutes) is input into the long short-term memory network module. The LSTM learns the long-term periodicity and trend patterns in the sequence through its gating mechanism, such as the regular fluctuations of container load under specific driving habits, and outputs a temporal dependency feature vector representing the long-term behavior of an individual. In addition, the global environmental features obtained from the cloud are compressed into an environmental context vector through an independent fully connected encoder to represent the overall scene such as "sunny day on the highway" or "evening rush hour in the city on a rainy day".

[0034] Secondly, context-aware feature fusion is performed. The three feature vectors mentioned above—spatiotemporally dependent features, temporally dependent features, and environmental context vectors—are concatenated into a single comprehensive feature. Then, the attention fusion module begins its work. This module internally employs a small feedforward neural network that receives the concatenated features and calculates an attention weight (summing to 1) for each of the three sources. The weight calculation depends on the current overall context. For example, at a busy, frequently interacting urban intersection, the model might assign a higher weight to the "spatiotemporally dependent features"; while under adverse weather conditions, the "environmental context vector" and the "temporally dependent features" representing the vehicle's robustness might receive more attention. Finally, the three feature vectors are weighted and summed according to their respective attention weights to generate a comprehensive feature vector. This mechanism ensures that the model can dynamically and adaptively determine the relative importance of different information sources in different scenarios.

[0035] Finally, resource requirements and risk quantification prediction are performed. The generated comprehensive feature vector is fed into the final fully connected output layer. This output layer is a regression network, and its output dimension corresponds to the number of indicators to be predicted. After calculation, the model generates a set of quantified prediction values ​​for each vehicle within the next 5 to 60 seconds (adjustable according to configuration), specifically including: CPU core requirements (e.g., 0.5 Cores), memory requirements (e.g., 2.1 GB), network bandwidth requirements (e.g., 50 Mbps), and a cold start risk score between 0 and 1. This score comprehensively evaluates the burstiness of the predicted load, current resource availability, and historical startup latency. A higher score indicates a greater risk of task delays due to insufficient resources or replica scaling in the near future, providing a key decision-making basis for the next stage of proactive scheduling.

[0036] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0037] S401. Dynamic Clustering to Form Cooperative Scheduling Units: Based on the spatiotemporal graph constructed in the previous stage, the system dynamically clusters vehicle nodes according to the weights (i.e., connection strengths) of spatial edges in the graph. Connection Strength It is a comprehensive quantitative indicator, usually composed of relative distance. and relative velocity Calculations, for example, using formulas ,in and This is a normalized parameter. The system sets a connection strength threshold w. thresh All interconnection strength The nodes (vehicles) will be clustered into the same collaborative scheduling unit. For example, a closely following convoy will have very high connectivity between its vehicles, thus naturally being grouped into a single unit. This process is dynamic; the unit members are updated in real time as vehicle positions and speeds change.

[0038] S402, Unit-Level Demand and Risk View Aggregation: For each defined collaborative scheduling unit, the system performs internal data integration. First, it sums the predicted future resource demands (CPU, memory, etc.) of all vehicles within the unit along the time dimension to generate a resource demand curve for the entire unit, clearly identifying the peaks and troughs of resource demand within a future time window (e.g., the next 30 seconds). Simultaneously, it extracts the cold start risk score timeline for each vehicle within the unit and arranges them along the vehicle dimension to form a two-dimensional risk matrix, thereby identifying which vehicles face high risk at what times.

[0039] S403. Dynamic Priority Calculation Based on Multi-Dimensional Dimensions: Based on this aggregated view, the system calculates a dynamic priority score for the container Pod corresponding to each vehicle within the unit. This score is determined by the following formula:

[0040] in, It is the cold start risk score of vehicle i at time t; It is the normalized predicted CPU demand; This refers to its spatiotemporal correlation with other high-priority vehicles within the unit, which can be obtained by calculating the average connection strength between it and the N vehicles temporarily ranked in priority within the unit. Weighting coefficient. , , Adjustable, typically with the α value set to maximum, reflecting a risk-driven principle. This dynamic priority score directly determines the order during resource contention or pre-scheduling, realizing a shift from coarse-grained QoS levels to fine-grained, context-aware scheduling.

[0041] In one embodiment of the present invention, based on step S5, a possible embodiment will be given below, and its specific implementation will be described in a non-limiting manner.

[0042] S501. Generation and Agreement of Resource Bonds: The system deeply analyzes the predicted resource demand curves of all container Pods within each collaborative scheduling unit. Its core is identifying Pod pairs with temporally complementary demand patterns. For example, Pod A is predicted to experience a CPU demand peak at t+15 seconds, while Pod B is at its demand trough at t+15 seconds but has its own peak at t+30 seconds. The system will generate a resource bond for (Pod A, Pod B). This bond is a structured scheduling metadata that explicitly stipulates that at t+15 seconds, Pod A has the right to temporarily borrow a portion of the reserved but idle CPU resources (e.g., 0.5 cores) under Pod B's name. The bond records the creditor (Pod A), the debtor (Pod B), the resource type and quantity, the effective time window, and the expected repayment time (e.g., after Pod A's peak). This mechanism transforms static resource reservation into a dynamic, commitment-based resource sharing protocol.

[0043] S502. Cooperative Deployment Based on Bond Affinity: During initial scheduling or rescheduling to address node failures, the scheduler considers not only the resource availability of nodes but also the resource bond relationship graph. For Pod pairs with bond relationships, the scheduler attempts to apply a mandatory "node affinity" rule, prioritizing scheduling them to the same physical node. If this is not possible due to node resource fragmentation, the scheduler uses cluster network topology awareness to schedule them to adjacent nodes directly connected via RDMA or high-speed Ethernet. This "co-location" or "proximity" strategy aims to minimize the data copying or memory access latency involved in resource borrowing, ensuring efficient execution of the bond mechanism and truly achieving fine-grained resource "peak shaving and valley filling" across Pods.

[0044] S503, Risk-Driven Proactive Warm-up Instruction Execution: The system continuously monitors the dynamic priority scores (P) of all Pods. score Once a Pod's P score If the risk threshold is exceeded, the resource scheduling controller immediately triggers a high-level preheating process. This process automatically generates and sends a series of precise proactive preheating instructions to the target edge nodes: Image and data preloading: The instruction requires the node to pull the container image required by the Pod from the image repository in advance, and may further preload large AI model weight files into memory or GPU memory.

[0045] Create a hot standby replica: This command instructs the node to start a Pod replica with an identical configuration, but place it in a special "hot standby" state. This replica has completed all initialization (including the image pull and model loading mentioned above), the process is started but not bound to a service port or handling real requests, maintaining only a minimal heartbeat. Its resource consumption is marked as "compressible." When real-time traffic spikes or the primary replica fails, the system can switch this hot standby replica to an active state within milliseconds, almost completely eliminating the cold start latency caused by container startup, image pull, and model loading, thereby ensuring the service SLA.

[0046] In some embodiments, the cloud container resource scheduling system may include multiple functional modules composed of computer program segments. The computer programs of each program segment in the cloud container resource scheduling system may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1 (Description) The function of resource scheduling for cloud containers.

[0047] In this embodiment, the cloud container resource scheduling system can be divided into multiple functional modules based on its functions, such as... Figure 2As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0048] The data acquisition module is used to acquire status data of multiple vehicles, container operation indicators, and environmental context data in intelligent driving scenarios. The graph construction module is used to construct a spatiotemporal graph based on the state data, where vehicles are nodes and spatial and temporal relationships between vehicles are edges. The demand forecasting module is used to input the spatiotemporal map, container operation indicators and environmental context data into the combined forecasting model to predict the container resource demand and cold start risk score of each vehicle in the future time period. The priority allocation module is used to divide vehicles into collaborative scheduling units based on the container resource requirements and cold start risk scores, and to assign priorities to containers within each collaborative scheduling unit. The resource scheduling module is used to pre-allocate and share resources among containers based on the priority and using a resource bond mechanism, and to trigger an active preheating operation for containers with high cold start risk.

[0049] Figure 3 The cloud container resource scheduling method provided in the embodiments of this application can be applied to devices. Those skilled in the art will understand that the device structure involved in the embodiments of this invention does not constitute a limitation on the device. A device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this invention, the device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0050] The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0051] The memory 320 can be used to store execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the device 300 is able to perform some or all of the steps in the above method embodiments.

[0052] The processor 310 serves as the control center of the storage device, connecting various parts of the electronic device via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0053] The communication unit 330 is used to establish a communication channel, enabling the storage device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.

[0054] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0055] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, a server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0056] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0057] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or modules may be electrical, mechanical, or other forms.

[0058] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0059] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0060] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A resource scheduling method for cloud containers, characterized in that, include: Acquire status data, container operation metrics, and environmental context data of multiple vehicles in intelligent driving scenarios; A spatiotemporal graph is constructed based on the state data, where vehicles are nodes and spatial and temporal relationships between vehicles are edges. The spatiotemporal map, container operation indicators, and environmental context data are input into the combined prediction model to predict the container resource requirements and cold start risk scores of each vehicle in the future time period. Based on the container resource requirements and cold start risk score, vehicles are divided into collaborative scheduling units, and priority is assigned to containers within each collaborative scheduling unit. Based on the aforementioned priorities, a resource bond mechanism is used to pre-allocate and share resources among containers, and to trigger proactive preheating operations for containers with high cold start risk.

2. The method according to claim 1, characterized in that, Acquire status data, container operation metrics, and environmental context data of multiple vehicles in an intelligent driving scenario, including: Vehicle node characteristics are obtained from the data reported by vehicles in real time. The vehicle node characteristics include: real-time status data, container operation indicators, and driving habit identifiers. Global environmental features are obtained from the cloud-based traffic management and environmental perception system. These global environmental features include: driving environment information, weather conditions, time information, and information about vehicles ahead.

3. The method according to claim 1, characterized in that, Constructing a spatiotemporal graph based on the aforementioned state data includes: Treat each intelligent vehicle in the current area as a node in the graph; Based on the relative distance, relative speed and driving relationship between vehicles, spatial edges between nodes are dynamically established. If the relative distance between two vehicles is lower than a preset threshold or there is a following or lane-changing relationship, a strong connection spatial edge is established. For each node, its state data sequence at multiple consecutive time steps is associated to form the node's own time edge.

4. The method according to claim 1, characterized in that, The combined prediction model comprises multiple modules connected in sequence: The spatiotemporal graph convolutional network module is used to receive the spatiotemporal graph, perform spatial convolution on the nodes in the graph to aggregate the features of neighboring vehicles, and perform temporal convolution to capture the short-term change patterns of the nodes themselves, thereby outputting spatiotemporal dependent features. The Long Short-Term Memory (LSTM) network module is used to receive the historical container operation index sequence of each vehicle, learn long-term time dependencies, and output temporal dependency features. The attention fusion module is used to receive the spatiotemporal dependent features, the temporal dependent features, and the environmental context vector encoded by the environmental context data, calculate the weight of each feature, perform weighted fusion, and output a comprehensive feature vector. The integrated feature vector is input to a fully connected output layer to predict the container resource requirements and the cold start risk score.

5. The method according to claim 4, characterized in that, The spatiotemporal map, container operation indicators, and environmental context data are input into a combined prediction model to predict the container resource requirements and cold start risk scores of each vehicle in future time periods, including: The constructed spatiotemporal graph is input into the spatiotemporal graph convolutional network module in the combined prediction model to extract the spatiotemporal dependency features between vehicles; The historical sequence of container operation indicators for each vehicle is input into the long short-term memory network module in the combined prediction model to extract long-term temporal dependency features. The spatiotemporal dependency features, the long-term temporal dependency features, and the encoded environmental context data are concatenated. The weights of each part in the spliced ​​features are calculated by the attention fusion module in the combined prediction model and then weighted and fused to generate a comprehensive feature vector. The integrated feature vector is input into the fully connected network of the output layer, and regression prediction is used to obtain the container resource requirements of each vehicle in the next 5 to 60 seconds and a cold start risk score between 0 and 1.

6. The method according to claim 1, characterized in that, Based on the container resource requirements and cold start risk scores, vehicles are divided into collaborative scheduling units, and priorities are assigned to containers within each collaborative scheduling unit, including: Vehicle nodes with connection strengths higher than a preset threshold in the spatiotemporal graph are dynamically clustered to form at least one collaborative scheduling unit, wherein the connection strength is determined based on the relative distance and relative speed between vehicles. For each collaborative scheduling unit, the predicted resource demand of all vehicles within it within the future time window is aggregated to generate a unit-level resource demand curve, and the cold start risk score timeline of each vehicle is integrated. Based on the cold start risk score timeline and the unit-level resource demand curve, a dynamic priority score is calculated for the container corresponding to each vehicle in the unit according to the preset priority calculation formula, for use in subsequent resource scheduling decisions.

7. The method according to claim 1, characterized in that, Based on the aforementioned priorities, a resource bond mechanism is used to pre-allocate and share resources among containers, and to trigger proactive preheating operations for containers with high cold start risk, including: Based on the predicted resource demand curves of each container within the collaborative scheduling unit, container pairs with mismatched peak resource demand times are identified, and resource bonds are generated for these container pairs. These bonds stipulate that the demand-side container can borrow the reserved resources of the supply-side container during peak times. When scheduling or rescheduling containers, container pairs with the aforementioned resource debt relationship are preferentially deployed to the same physical node or adjacent nodes directly connected via high-speed network to reduce resource allocation latency. For containers with dynamic priority higher than a preset risk threshold, an active preheating instruction is generated and issued. The execution of the instruction includes: pre-pulling the container image to the target node, preloading the associated model data into memory, or creating a container copy in a hot standby state on the target node.

8. A resource scheduling system for cloud containers, characterized in that, include: The data acquisition module is used to acquire status data of multiple vehicles, container operation indicators, and environmental context data in intelligent driving scenarios. The graph construction module is used to construct a spatiotemporal graph based on the state data, where vehicles are nodes and spatial and temporal relationships between vehicles are edges. The demand forecasting module is used to input the spatiotemporal map, container operation indicators and environmental context data into the combined forecasting model to predict the container resource demand and cold start risk score of each vehicle in the future time period. The priority allocation module is used to divide vehicles into collaborative scheduling units based on the container resource requirements and cold start risk scores, and to assign priorities to containers within each collaborative scheduling unit. The resource scheduling module is used to pre-allocate and share resources among containers based on the priority and using a resource bond mechanism, and to trigger an active preheating operation for containers with high cold start risk.

9. A resource scheduling device for cloud containers, characterized in that, include: Storage, used to store the resource scheduler for cloud containers; A processor, configured to implement the steps of the resource scheduling method for a cloud container as described in any one of claims 1-7 when executing the resource scheduler of the cloud container.

10. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a resource scheduler for a cloud container, which, when executed by a processor, implements the steps of the resource scheduling method for a cloud container as described in any one of claims 1-7.

Images