#10277·autoscaler

externalgrpc: TemplateNodeInfo cannot return ResourceSlices

Author: DespireCreated Sep 11, 2026Updated Sep 11, 2026
Labelsarea/cluster-autoscalerkind/featureneeds-triagearea/provider/externalgrpc

Which component are you using?

/area cluster-autoscaler /area provider/externalgrpc

Is your feature request designed to solve a problem? If so describe the problem this feature should solve.

Cluster Autoscaler's core supports DRA in scale-up simulations. A cloud provider whose TemplateNodeInfo() returns slices can scale a node group from zero for pods that use resourceClaims / resourceClaimTemplateName.

The externalgrpc provider cannot do this. NodeGroupTemplateNodeInfoResponse only has bytes nodeBytes, and externalgrpc_node_group.go builds the template with framework.NewNodeInfo(pbNodeInfo, nil). An external provider has no way to describe the DRA devices a node from an empty group will expose.

Concretely: with --enable-dynamic-resource-allocation=true, a pending pod with a ResourceClaim for gpu.nvidia.com devices, and an externalgrpc node group with zero nodes, produces no expansion option, and no scale-up happens. Once the group has one running node the real node's slices are copied and everything works, so the gap is limited to scale-from-zero.

Describe the solution you'd like.

Extend the protocol so a provider can optionally return node-local ResourceSlices with the template node:

message NodeGroupTemplateNodeInfoResponse {
  bytes nodeBytes = 2;
  // Proto-serialized resource.k8s.io/v1 ResourceSlice objects.
  repeated bytes resourceSliceBytes = 3;
}

and in TemplateNodeInfo() unmarshal them and pass them to framework.NewNodeInfo(pbNodeInfo, slices). Everything downstream already handles them.

The change is backward compatible: an older autoscaler ignores the unknown field, and a newer autoscaler with an older provider receives an empty list and behaves as today.

I am happy to open the PR if maintainers agree with the approach.

Describe any alternative solutions you've considered.

  • Only supporting extended resources via DeviceClass.spec.extendedResourceName. Works today but excludes pods that use ResourceClaims directly.

Additional context. N/A