Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EKS: EKS uses AL2_x86_64 AmiType in AWS::EKS::Nodegroup instead of AL2023_x86_64_STANDARD #32211

Open
1 task
markusl opened this issue Nov 20, 2024 · 3 comments
Labels
@aws-cdk/aws-eks Related to Amazon Elastic Kubernetes Service bug This issue is a bug. effort/medium Medium work item – several days of effort p2

Comments

@markusl
Copy link
Contributor

markusl commented Nov 20, 2024

Describe the bug

EKS: EKS uses AL2_x86_64 AmiType in AWS::EKS::Nodegroup instead of AL2023_x86_64_STANDARD

Regression Issue

  • Select this option if this issue appears to be a regression.

Last Known Working CDK Version

No response

Expected Behavior

I would expect the latest AMI to be used instead of the old one. Once a cluster is deployed, a message is shown in AWS console: "New AMI release version is available for this node group."

Terraform module also suggests that "Starting on 1.30, AL2023 is the default AMI type for EKS managed node groups"
https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/20.29.0

Current Behavior

The following template is generated:

  "EksClusterNodegroupDefaultCapacityE6D932C8": {
   "Type": "AWS::EKS::Nodegroup",
   "Properties": {
    "AmiType": "AL2_x86_64",
...

Reproduction Steps

      const cluster = new eks.Cluster(this, 'EksGpuCluster', {
        vpc: vpc,
        vpcSubnets: [{ subnetType: ec2.SubnetType.PUBLIC }],
        version: eks.KubernetesVersion.V1_31,
        defaultCapacity: 2,
        defaultCapacityInstance: new ec2.InstanceType('m5.xlarge'),
        kubectlLayer: new KubectlV31Layer(this, 'KubectlLayer'),
        outputConfigCommand: true,
        outputClusterName: true,
        authenticationMode: eks.AuthenticationMode.API_AND_CONFIG_MAP,
      });

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.167.1 (build d681b12)

Framework Version

No response

Node.js Version

20

OS

Mac

Language

TypeScript

Language Version

No response

Other information

No response

@markusl markusl added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Nov 20, 2024
@github-actions github-actions bot added the @aws-cdk/aws-eks Related to Amazon Elastic Kubernetes Service label Nov 20, 2024
@pahud pahud self-assigned this Nov 20, 2024
@pahud
Copy link
Contributor

pahud commented Nov 20, 2024

Yes

amiType: props.launchTemplateSpec ? props.amiType : (props.amiType ?? possibleAmiTypes[0]),

If props.amiType is not specified, the first element of possibleAmiTypes would be picked, which is AL2_X86_64.

We'll have to shift the order here and this would cause breaking changes and requires a feature flag.

We welcome community PRs.

@pahud pahud added p2 effort/medium Medium work item – several days of effort and removed needs-triage This issue or PR still needs to be triaged. labels Nov 20, 2024
@pahud pahud removed their assignment Nov 20, 2024
@markusl
Copy link
Contributor Author

markusl commented Nov 20, 2024

@pahud Yes, I noticed amiType for addNodegroupCapacity. However, the defaultCapacity and defaultCapacityInstance properties of eks.Cluster do not seem to make it possible to specify AL2023 / Bottlerocket. Is there a workaround for that?

@pahud
Copy link
Contributor

pahud commented Nov 22, 2024

@markusl

I am afraid not. That defaultCapacity is an opinionated design. I would suggest to set it to 0 in the cluster props and

cluster.addNodegroupCapacity() to create a customized nodegroup capacity instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-eks Related to Amazon Elastic Kubernetes Service bug This issue is a bug. effort/medium Medium work item – several days of effort p2
Projects
None yet
Development

No branches or pull requests

2 participants