Expression-based NodeClass config (#8742/#9461) is kubelet-only — nothing covers blockDeviceMappings / per-instance-type EBS

Description

The Expression-Based NodeClass Configuration feature — tracked in #8742, implemented in #9461, documented in #9508 — is scoped strictly to spec.kubelet.*. There is currently no mechanism to configure blockDeviceMappings (EBS) per instance type, whether via CEL expressions or otherwise.

This gap matters because #8507 ("Override Block Device Mapping per Instance Type") was closed as completed in favor of #8742 with the comment "Sounds like something CEL expressions can solve." However, the delivered CEL work does not, in fact, extend to blockDeviceMappings — so the use case #8507 described remains unaddressed.

What the CEL/expression feature covers today

• CEL expressions are accepted only on three kubelet fields: maxPods (via maxPodsExpression), kubeReserved, and systemReserved.
• Expressions are evaluated from instance-shape variables (instance_type, vcpus, memory_mib, default_enis, ips_per_eni, etc.).
• The feature is Alpha, behind the NodeClassCEL feature gate.
• #8742's scope, and the #9461/#9508 implementation, never reference blockDeviceMappings, EBS, volumeSize, volumeType, iops, or throughput.

The gap

• There is no volumeSizeExpression (or any expression-capable field) anywhere under blockDeviceMappings.
• blockDeviceMappings remains a static, per-EC2NodeClass value, applied uniformly to every instance type a NodePool launches.
• Consequently there is no way to size EBS proportionally to the instance (e.g. give larger instances larger or higher-performance volumes) within a single NodePool. Users must either over-provision small instances or under-provision large ones — or fracture into multiple EC2NodeClasses, one per instance-type band, which is exactly the fragmentation the expression feature was meant to avoid.

Ask

1. Please confirm the assessment above — that expression-based config is kubelet-only today and does not support per-instance-type blockDeviceMappings / EBS.
2. Is there any planned work (PR, design doc, or roadmap item) to extend CEL expressions — or any other mechanism — to blockDeviceMappings, enabling dynamic per-instance-type EBS volumeSize / volumeType / iops / throughput? If so, please link it so this can be tracked.

Use case

A single NodePool spanning a range of instance sizes (e.g. large → 4xlarge) where the ideal EBS volume size scales with the instance. Today this requires one EC2NodeClass per size band; expression-based blockDeviceMappings would collapse that back to a single NodeClass, mirroring what maxPodsExpression already does for kubelet.

References

• Tracking issue: #8742
• Implementation PR: #9461
• Docs PR: #9508
• Closed-in-favor-of: #8507