aws-eks: `addAutoScalingGroupCapacity` lacks support for Amazon Linux 2023

[isker]

Describe the feature

addAutoScalingGroupCapacity allows the user to select a MachineImageType, but this only includes AL2 or Bottlerocket. AL2023 is missing.

https://github.com/aws/aws-cdk/blob/v2.139.0/packages/aws-cdk-lib/aws-eks/lib/cluster.ts#L2468-L2480

Use Case

I want to use a newer kernel than is available in AL2 on my EKS ASGs.

Proposed Solution

No response

Other Information

AL2023 support has been added for managed node groups but not for ASGs. See #29546 #29334. cc @pahud as you've handled those issues.

Acknowledgements

• [ ] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

CDK version used

2.139.0

Environment details (OS name and version, etc.)

N/A

[pahud]

Yes we could have a PR for that. But I am wondering why you opt in addAutoScalingGroupCapacity rather than addNodeGroupCapacity? Is there any feature not supported in the managed nodegroups?

[isker]

https://github.com/aws/containers-roadmap/issues/608

[pahud]

@isker Is it because Nodegroup currently does not support tagging ASG? This would be a huge tradeoff. In CDK, you still can create a managed nodegroup and a custom resource to tag the ASG behind the nodegroup. Would this be something you expect?

check https://github.com/aws/aws-cdk/issues/29280#issuecomment-1967683280 and https://github.com/aws/aws-cdk/issues/29280#issuecomment-1971460918

Feel free to chat with me on cdk.dev if you need.

[isker]

Thanks for that information. I'll take a look.

CDK should support AL2023 on EKS ASGs.

[awsdataarchitect]

Similar issue exists on eks blueprints #1006

[xy795]

Any updates here? We got to the point where AL2 is no longer supported for EKS nodegroups by AWS, so deploying groups by calling addAutoScalingGroupCapacity with parameter AL2 (the default) as MachineImageType will cause an error:

failed: ValidationError: Unable to fetch parameters [/aws/service/eks/optimized-ami/1.33/amazon-linux-2/recommended/image_id] from parameter store for this account.

We have a cdk setup relying on some of the "ec2" functionality exposed by addAutoScalingGroupCapacity and can't upgrade to the latest EKS version because of this.

[AposLaz]

Any updates here? We need the addAutoScalingGroupCapacity feature because we rely on alerts to dynamically resize the node group.

[talalong]

Same issue here. if AL2 does not support EKS 1.33, why is the default image parameter amazon-linux-2 attached to it? Would it make our life easier if cdk uses AL2023 automatically? So we dont have to touch our 'addAutoScalingGroupCapacity'

[pahud]

Same issue here. if AL2 does not support EKS 1.33, why is the default image parameter amazon-linux-2 attached to it? Would it make our life easier if cdk uses AL2023 automatically? So we dont have to touch our 'addAutoScalingGroupCapacity'

Yes definitely. Let's create a PR to make it better and move this path forward.

[talalong]

@pahud thank you for your response. Just to clarify — are you suggesting that I should open the PR? I’m happy to help, but I’m not sure I have enough knowledge to do it correctly. For example, adding a new constant AL2023 to MachineImageType isn’t enough on its own, right?

[pahud]

@talalong I would say anyone of us can submit a PR to move this path forward. The idea of writing up a PR is not just about fix the code and make it right, the most important is we need to prove it deploys with correct expected behavior. In this sense, we generally need to update or even add a new integ test and get it deployed to generate snapshots. This ensures it does deploys as a proof and submit both the changed code as well as the integ tests assets.