How to controls bottlerocket version for EKS managed node groups?

[Raboo]

Hi,

I am setting up a EKS cluster with terraform and using an EKS manged node group
But how do I control which version of bottlerocket-os to use? My best guess is to specify release_version?

  eks_managed_node_groups = {
    initial = {
      instance_types = ["m6i.large"]
      ami_type = "BOTTLEROCKET_x86_64"
      platform = "bottlerocket"
      # release_version = "something here?"
      create_security_group = false
      min_size     = 2
      max_size     = 3
      desired_size = 2
    }

And if it is release_version, how do I get a list of available versions?

[jpculp]

Hi @Raboo! Although we always recommend running the latest Bottlerocket release, I think the key you're looking for is ami_release_version. For AMI information I would refer to Amazon EKS optimized Bottlerocket AMIs.

[Raboo]

Ok great, so would it be like ami_release_version = v1.13.1 or like ami_release_version = v1.13.1-k8s-1.25 or ami_release_version = 1.25

And default is latest version right. So what happens when a new release is made, does it cluster auto upgrade automagically and if so, how do I revert in case a bug has been found in the new version? Or do I need to execute terraform apply without changes to apply the latest version to the cluster?

Anyway I plan to run latest version. But I want to have it in version control and I want to control when I upgrade the cluster nodes so I can know if something changes, what caused it.

[Azahorscak]

Hi I would really love an answer to this question. I have not been able to find the release_version anywhere in any documentation and it doesn't seem to come from the ssm get-parameter command. Please let me know if anyone has a way to get it, thanks!

[yeazelm]

I believe this maps to the SSM parameters which have several different versions under the hood. You should be able to use ami_release_version = 1.18.0-7452c37e or ami_release_version = 1.18.0 since the specific variant (k8s 1.25 vs another one) is tied to your cluster version. To find this version, you can use Bottlerocket's SSM parameters (https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id-bottlerocket.html) by calling the path /aws/service/bottlerocket/aws-k8s-1.25/x86_64/latest/image_version if you want to find it explicitly.

[Azahorscak]

Awesome, thank you @yeazelm!! That path is exactly what I needed. To pin bottlerocket versions across multiple managed node groups and clusters we have to use the release_version since specifying by ami_id is not allowed when using eks managed node groups.

I also confirmed that when using eks managed node groups and terraform using ami_release_version = 1.18.0 is not valid and the full version is required ie. ami_release_version = 1.18.0-7452c37e

[Raboo]

Ok thanks, so to summarize.

To set a fixed a bottlerocket version.

1. Get the version from Bottlerocket's SSM parameters at path /aws/service/bottlerocket/aws-k8s-${K8S_RELEASE}/x86_64/latest/image_version.

Example:

aws ssm get-parameter --name /aws/service/bottlerocket/aws-k8s-1.29/x86_64/latest/image_version --region eu-north-1 --query "Parameter.Value" --output text

2. Set the output to ami_release_version = ${SSM_OUTPUT}

Example:

  eks_managed_node_groups = {
    initial = {
      instance_types = ["m6i.large"]
      ami_type = "BOTTLEROCKET_x86_64"
      platform = "bottlerocket"
      ami_release_version = "1.19.2-29cc92cc"
      create_security_group = false
      min_size     = 2
      max_size     = 3
      desired_size = 2
    }

[crechandan]

But, this does not answers - if aws will automatically upgrade the nodes in nodegroup even if I have hard coded the ReleaseVersion ??

[Raboo]

I just assumed it won't auto-upgrade if I specify a hardcoded version. Perhaps I should not assume. I guess I need to test this, but right now I don't have a AWS project/budget to test it on.

[paulchambers]

So if i'm specifying for example '1.35.0-af533f46' as my ami release version at what point is that resolved against the kubernetes version to find the right ami.

Because the same ami release version is valid for 1.31 and 1.32 but they both resolve to different AMIs.

So with the cluster on 1.31 it uses bottlerocket-aws-k8s-1.31-x86_64-v1.35.0-af533f46

In my testing when I perform an EKS version upgrade the nodes do not move to the new AMI bottlerocket-aws-k8s-1.32-x86_64-v1.35.0-af533f46

This isn't a big problem as I can just spin up a new nodegroup and that will get the new AMI, but is there a way to explicitly pin to the variant so it's clear from the definition which is expected.

[koooosh]

Hey @paulchambers , can you please clarify what you mean by "explicitly pin to the variant"? Do you mean how to use a specific AMI?

[paulchambers]

@koooosh I'm managing the cluster and nodegroups using CDK. I'm specifying the release version in the nodegroup configuration.

With AL2 the release version includes the k8s version like 1.31.5-20250410 or 1.32.1-20250410

With bottlerocket the release version is something like 1.35.0-af533f46 or 1.36.0-00ef7af1 and then I guess something in AWS takes that and the K8S version and resolves the correct AMI to use.

So with AL2 you can upgrade the cluster and then separately upgrade the nodegroup(s), I'm trying to understand how you would do that with bottlerocket. Upgrading the cluster didn't trigger an upgrade of the nodegroup and because the release version isn't changing i'm not clear on how you would then trigger the nodegroup to upgrade.

[paulchambers]

so what I mean by 'explicitly pin to the variant' is can I make it clear in my IaC that this node group is using bottlerocket-aws-k8s-1.31-x86_64-v1.35.0-af533f46, or is the only way to do that to specify the ami id directly?