When EKS Nodegroup is deployed using Bottlerocket AMI type, update call fails

[sudohikumar]

Describe the bug
When EKS Nodegroup is deployed using Bottlerocket AMI type, update call fails with version mismatch error.

Steps to reproduce
Applied the following

apiVersion: eks.services.k8s.aws/v1alpha1
kind: Nodegroup
metadata:
  name: eks-test
spec:
  amiType: BOTTLEROCKET_x86_64
  releaseVersion: 1.47.0-6154605b
  launchTemplate:
    name: eks-lt
    version: "1"
  capacityType: ON_DEMAND
  clusterRef:
    from:
      namespace: example
  instanceTypes:
  - m5.2xlarge
  - m6a.2xlarge
  - m6i.2xlarge
  - m7i.2xlarge
  - m7a.2xlarge
  - m5a.2xlarge
  labels:
    nodegroup: eks-test
  name: eks-test
  nodeRole: <Redacted>
  scalingConfig:
    desiredSize: 0
    maxSize: 1
    minSize: 0
  subnets:
  - subnet-1
  taints:
  - effect: NO_SCHEDULE
    key: nodegroup-test
    value: eks-test
  updateConfig:
    maxUnavailable: 1

it got synced successfully but controller changes the spec field as follows

apiVersion: eks.services.k8s.aws/v1alpha1
kind: Nodegroup
metadata:
  annotations:
    eks.services.k8s.aws/force-update-version: "true"
    kubectl.kubernetes.io/last-applied-configuration: |
      -----
  creationTimestamp: "2025-09-29T14:09:49Z"
  finalizers:
  - finalizers.eks.services.k8s.aws/Nodegroup
  generation: 3
  name: eks-test
spec:
  amiType: BOTTLEROCKET_x86_64
  releaseVersion: 1.47.0-6154605b
  launchTemplate:
    name: eks-lt
    version: "1"
  capacityType: ON_DEMAND
  clusterRef:
    from:
      namespace: example
  instanceTypes:
  - m5.2xlarge
  - m6a.2xlarge
  - m6i.2xlarge
  - m7i.2xlarge
  - m7a.2xlarge
  - m5a.2xlarge
  labels:
    nodegroup: eks-test
  name: eks-test
  nodeRole: <Redacted>
  scalingConfig:
    desiredSize: 0
    maxSize: 1
    minSize: 0
  subnets:
  - subnet-1
  taints:
  - effect: NO_SCHEDULE
    key: nodegroup-test
    value: eks-test
  updateConfig:
    maxUnavailable: 1
  version: "1.32"

Notice the version at the end added.
But the resource goes into terminal condition as follows (tried to update launch template version)

status:
  ackResourceMetadata:
    arn: <ARN>
    ownerAccountID: <AccountID>
    region: <Region>
  conditions:
  - lastTransitionTime: "2025-09-29T14:11:11Z"
    status: "True"
    type: ACK.ReferencesResolved
  - lastTransitionTime: "2025-09-29T14:11:11Z"
    status: "True"
    type: ACK.ResourceSynced
  - message: 'version and release version do not match: 1.32 and 1.47'
    status: "True"
    type: ACK.Terminal
  createdAt: "2025-09-29T14:09:52Z"
  desiredSize: 0
  health: {}
  modifiedAt: "2025-09-29T14:10:39Z"
  resources:
    autoScalingGroups:
    - name: <ASG Name>
  status: ACTIVE

The error comes from https://github.com/aws-controllers-k8s/eks-controller/blob/main/pkg/resource/nodegroup/hook.go#L345-L349. I feel the check here is not correct for Bottlerocket kind of AMIs since bottlerocket version is not aligned with k8s version (for example, for version 1.32, bottlerocket version can be 1.47.xxxxxx). Hence, this will keep on failing.

Expected outcome
Update is triggered.

Environment

• Kubernetes version - 1.32
• Using EKS (yes/no), if so version? - Yes
• AWS service targeted (S3, RDS, etc.) - EKS Nodegroup

[github-actions]

Hello @sudohikumar 👋 Thank you for opening an issue in ACK! A maintainer will triage this issue soon.

We encourage community contributions, so if you're interested in tackling this yourself or suggesting a solution, please check out our Contribution and Code of Conduct guidelines.

You can find more information about ACK on our website.

[knottnt]

@sudohikumar Just left comments on your PR. Noticed that when running through steps to reproduce this bug with your fix we actually run into a second issue related to updating the LaunchTemplate. I've created #2645 to track that issue.

[sudohikumar]

Hey @knottnt
I also hit the issue mentioned above. Probably we should fix the mentioned issue as well in v1.9.3 release. Otherwise, this issue fix is not the complete solution.

[knottnt]

@sudohikumar The fix you provided does resolve the issue in other scenarios. For example, making the below update to releaseVersion and/or version would have failed before your fix. Given this I'm inclined to release v1.9.3 so that we don't delay fixing these scenarios and then provide a fix for #2645 in a v1.9.4 release.

apiVersion: eks.services.k8s.aws/v1alpha1
kind: Nodegroup
metadata:
  name: eks-test
spec:
  amiType: BOTTLEROCKET_x86_64
  releaseVersion: "1.47.0-6154605b"
  capacityType: ON_DEMAND
  clusterName: test-cluster
  instanceTypes:
  - t3.medium
  labels:
    nodegroup: eks-test-2
  name: eks-test
  nodeRole: xxx
  scalingConfig:
    desiredSize: 0
    maxSize: 1
    minSize: 0
  subnets:
  - subnet-1
  taints:
  - effect: NO_SCHEDULE
    key: nodegroup-test
    value: eks-test
  updateConfig:
    maxUnavailable: 1
  version: "1.31"

apiVersion: eks.services.k8s.aws/v1alpha1
kind: Nodegroup
metadata:
  name: eks-test
spec:
  amiType: BOTTLEROCKET_x86_64
  releaseVersion: "1.48.0-b13a9fcb" # Updated Bottlerocket release version
  capacityType: ON_DEMAND
  clusterName: test-cluster
  instanceTypes:
  - t3.medium
  labels:
    nodegroup: eks-test-2
  name: eks-test
  nodeRole: xxx
  scalingConfig:
    desiredSize: 0
    maxSize: 1
    minSize: 0
  subnets:
  - subnet-1
  taints:
  - effect: NO_SCHEDULE
    key: nodegroup-test
    value: eks-test
  updateConfig:
    maxUnavailable: 1
  version: "1.32" # Updated k8s version

[sudohikumar]

Sure @knottnt . Makes sense.
I have a PR raised for other issue as well. Please have a review.