Default scheduler schedules pods based on their requests and what is available on nodes. Developers  are known to grossly over-provision  resources for their containers to avoid under-provisioning risks (pod evictions due to OOM and performance  issues, etc.)

Use Case 1: TargetLoadPacking

Current

• Nodes have varied utilization (<10%, >90%)
• More nodes are provisioned than actually needed

Expect

• High utilization on all running nodes. All running nodes have around x% utilization. Other nodes have 0% utilization and can be powered off.
• Maintain a safe margin when there are enough resources. No nodes exceed x% utilization when there are nodes with < x%.

Use Case 2: LoadVariationRiskBalancing

Current

• The variation of load on nodes varies significantly.
• Some nodes have on average low utilization but will evict pods or have performance issues due to CPU throttling at peak usage.

Expect

• The usage variations on nodes are considered when scheduling pods.
• The scheduler is able to balance the risk of having pod evictions or performance issues on all nodes.

Use Case 3: LoadRiskAwareCommitment

Current

• The cluster has very low utilization (<10%)
• There are no available allocatable resources to schedule new pods.

Expect

• High utilization in the cluster. All running nodes have around x% utilization.
• New pods can be taken if the cluster is not fully utilized. Being able to schedule new pods as long as the actual usage of the cluster is not 100%.