Custom Compute Class: pods aren't bin-packed onto a shared node even when they'd fit, and unclear consolidation vs. initial-scheduling behavior

Google Cloud Compute Infrastructure
1

Environment: GKE Standard, version 1.34, cloud.google.com/v1 ComputeClass

Behavior observed:

Multiple pods requesting the same ComputeClass (via nodeSelector: cloud.google.com/compute-class: ), submitted around the same time, each get provisioned onto a separate new node rather than being bin-packed onto one — even in cases where their combined resource requests would comfortably fit on a single node of the smallest listed priorities[].machineType.

Is initial pod placement onto autoprovisioned ComputeClass nodes bin-packing-aware across multiple simultaneously pending pods of the same class, or does each pending pod trigger an independent scale-up decision? If the latter, is there a way to batch/delay evaluation so concurrent pods are considered together? Is autoscalingPolicy.consolidationThreshold/consolidationDelayMinutes the only lever for retroactively repacking pods from underutilized nodes onto fewer nodes, or is there a setting that affects initial placement density too? When whenUnsatisfiable: ScaleUpAnyway falls back because no listed priority tier can be satisfied, what determines the actual fallback machine type (e.g., why e2-standard-2 specifically)? Is this documented anywhere? Is priorityScore a supported field under spec.priorities[] (as an alternative/supplement to list-order-based priority)? I haven’t been able to confirm this against the published CRD reference.

Questions:

Is initial pod placement onto autoprovisioned ComputeClass nodes bin-packing-aware across multiple simultaneously pending pods of the same class, or does each pending pod trigger an independent scale-up decision? If the latter, is there a way to batch/delay evaluation so concurrent pods are considered together?

Is autoscalingPolicy.consolidationThreshold/consolidationDelayMinutes the only lever for retroactively repacking pods from underutilized nodes onto fewer nodes, or is there a setting that affects initial placement density too?

2

Custom ComputeClasses influence autoscaler provisioning, while pod placement is still handled by the Kubernetes scheduler. During rapid concurrent scale-up, separate pending pods can result in multiple nodes being provisioned before the scheduler has a chance to place them densely. There is no documented batching or initial-placement-density setting for ComputeClasses. The consolidationThreshold and consolidationDelayMinutes fields apply after provisioning, allowing GKE to consolidate underutilized nodes; they do not directly control initial bin-packing.

3

Interesting discussion. The difference between initial scheduling and consolidation behavior can definitely be confusing, especially when pods appear to fit but still aren’t bin-packed onto a shared node. Topics like this highlight why hands-on practice is just as important as documentation. For anyone taking an online course or exploring cloud infrastructure through online learning, real-world scenarios like this are great examples of how Kubernetes scheduling decisions can be more complex than they first appear. Thanks for bringing up such a valuable question.