Enhanced Load-Aware Scheduling for batch pod dispatch

### What is the problem you're trying to solve Current usage-based scheduling in Volcano faces three critical challenges in production environments: - The "Monitoring Blind Spot" (Herd Effect): Metrics collected from Prometheus or Metrics-Server typically have a delay of 30s–60s. During bulk Pod creation or heavy re-deployment, the scheduler remains "blind" to the load of recently dispatched Pods. This causes the scheduler to stack too many Pods onto the same node before the metrics update, leading to severe node hotspots. - Static & Inflexible Estimation: Current plugins often use a fixed ratio of Request or Limit to estimate load. This fails to balance resource packing and system stability. There is no non-linear mechanism to become "more conservative" as a node approaches its saturation point. - Scheduling Throughput Bottlenecks: In large-scale clusters (5000+ nodes), performing complex floating-point calculations (like Sigmoid or multi-resource weighting) during the NodeOrder phase for every single Pod results in high CPU overhead and drops in scheduling Pods-per-second (PPS). ### Describe the solution you'd like I would like to enhance the usage plugin in the Volcano scheduler to transition from a purely reactive, monitoring-based model to a proactive, state-aware dispatching model. The proposed solution consists of four core components: 1. Session-Scoped Shadow Load Cache Introduce a ShadowLoadCache within the scheduling session. This cache tracks the estimated resource consumption of Pods that have been allocated by the scheduler but are not yet reflected in the Prometheus metrics (the "monitoring blind spot"). OnSessionOpen: Identify Pods in the "blind spot" (StartTime < MetricsInterval) and initialize the cache. Allocate/Deallocate: Update the cache in real-time as scheduling decisions are made. 2. Dynamic Sigmoid Estimation Model: Replace static resource estimation with a non-linear, adaptive model. This allows the scheduler to be "aggressive" when nodes are underutilized and "exponentially cautious" as they approach a target watermark.Formula: $\sigma_{dynamic} = \sigma_{base} + \frac{1 - \sigma_{base}}{1 + e^{-k(CurrentLoad - SoftTarget)}}$ Goal: This ensures the scheduler can maintain a stable node resource utilization (e.g., 60%) by dynamically scaling the risk weight between Request and Limit. 3. Batch Scoring Performance OptimizationTo support large-scale clusters, implement the BatchNodeOrderFn interface to avoid redundant calculations.Pre-calculated Scores: At the start of a session, calculate the base score for all nodes.Dirty Node Updates: Only re-calculate the score for a specific node when an Allocate or Deallocate event occurs on that node.Complexity: This reduces the scoring phase from $O(M \times N)$ to effectively $O(1)$ lookup per Pod during the dispatching loop. 4. Symmetric Lifecycle Consistency To prevent "resource leakage" in the shadow cache, implement a strict symmetric lifecycle: sessionTaskEstimations: A temporary mapping to track exactly how much load each task contributed during Allocate. Deallocate Handling: Ensure that if a task is preempted or fails to bind, the exact same amount of shadow load is rolled back, restoring the node's capacity and score accuracy immediately. ### Additional context _No response_ ### Documentation Updates - [x] This feature requires design or user documentation changes. - [ ] If documentation changes are required, I will ensure the relevant documents are updated and published to the Volcano official website (https://volcano.sh) via the [volcano-sh/website](https://github.com/volcano-sh/website) repository.