You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the func of estimatedUsedByResource estimates the resource usage of the Pod, if the pod's request is less than the limit, then use the limit as the estimated value. If the request is equal to the limit, then use the limit * scalingFactor (scalingFactor is a preset value, the default In this case, the scalingFactor of the CPU is 85%) as an estimate. According to the QoS category and corresponding operation quality requirements, shouldn't the larger the estimate in the Guaranteed case, and the buffer estimate in the Burstable case, the higher the stability of the final scheduling result? But looking at the implementation, it seems to be exactly the opposite. I haven’t seen any design and implementation documentation for this in the community.
The text was updated successfully, but these errors were encountered:
When the func of estimatedUsedByResource estimates the resource usage of the Pod, if the pod's request is less than the limit, then use the limit as the estimated value. If the request is equal to the limit, then use the limit * scalingFactor (scalingFactor is a preset value, the default In this case, the scalingFactor of the CPU is 85%) as an estimate. According to the QoS category and corresponding operation quality requirements, shouldn't the larger the estimate in the Guaranteed case, and the buffer estimate in the Burstable case, the higher the stability of the final scheduling result? But looking at the implementation, it seems to be exactly the opposite. I haven’t seen any design and implementation documentation for this in the community.
The text was updated successfully, but these errors were encountered: