[maitreya526]

Description

Adds an AmazonLinux2027 AMI family so self-managed nodegroups can run the AmazonLinux2027 EKS AMI preview with a custom AMI ID.

Problem. AmazonLinux2027 AMIs bootstrap with nodeadm, like AmazonLinux2023, but nodeadm names AmazonLinux2027 nodes by EC2 instance ID (i-0abc...) instead of by private DNS name. eksctl gives self-managed Linux nodegroups an EC2_LINUX access entry, or an aws-auth mapping, with the username system:node:{{EC2PrivateDNSName}}. That doesn't match the node name, so the node authorizer rejects the node:

User "system:node:ip-192-168-54-42.us-west-2.compute.internal" cannot get resource "csinodes" ...
node: can only access CSINode with the same name as the requesting node

Change. For amiFamily: AmazonLinux2027 on self-managed nodegroups (nodeGroups), eksctl now:

• reuses the AmazonLinux2023 nodeadm user data, and defaults to and requires containerd
• creates an EC2 access entry instead of EC2_LINUX, or an aws-auth mapping with the username system:node:{{SessionName}}. The EKS docs describe EC2 as the type for self-managed nodes that use the instance ID as the node name, mapped to system:node:{{SessionName}}.
• requires ami to be an AMI ID, because there is no public SSM parameter for AmazonLinux2027 AMIs yet

Not included, on purpose:

• Managed nodegroups are rejected with a clear error. EKS creates the node access entry for managed nodegroups as EC2_LINUX, so AmazonLinux2027 nodes wouldn't join. This can be lifted once EKS managed nodegroups support AmazonLinux2027.
• eksctl utils migrate-to-access-entry is unchanged. Fargate pod execution roles and hybrid node roles also use system:node:{{SessionName}}, so the migrator can't tell them apart from AmazonLinux2027 node roles, and an access entry's type can't be changed later. It keeps skipping these mappings with a warning and doesn't switch to API mode. Users can create the EC2 access entry for the AmazonLinux2027 node role themselves and rerun the migration.
• SSM / ami: auto lookup, arm64, GPU and Neuron AMIs, Outposts, and Karpenter, until those AMIs and lookup paths exist.

Testing

Unit tests: make unit-test-no-generate passes. New tests cover the access entry type, the aws-auth username, validation (AMI ID required, dockerd rejected, managed nodegroups rejected), the containerd default, the user data, and the migrator skipping {{SessionName}} mappings.

Manual test on a 1.37 cluster (API_AND_CONFIG_MAP) with the public preview AMI ami-0ad72f625c44b33e3 (us-west-2), with no manual steps:

nodeGroups:
  - name: al2027-family
    ami: ami-0ad72f625c44b33e3
    amiFamily: AmazonLinux2027

$ eksctl create nodegroup -f al2027.yaml
[ℹ]  nodegroup "al2027-family" will use "ami-0ad72f625c44b33e3" [AmazonLinux2027/1.37]
[ℹ]  node "i-06c276e23c7f709f3" is ready
[✔]  created 1 nodegroup(s) in cluster "test1"

$ kubectl get nodes -l alpha.eksctl.io/nodegroup-name=al2027-family
NAME                  STATUS   VERSION               OS-IMAGE
i-06c276e23c7f709f3   Ready    v1.37.0-eks-b9510e3   Amazon Linux 2027.0.20261012

$ aws eks describe-access-entry ... --query 'accessEntry.[type,username]'
EC2     system:node:{{SessionName}}

$ kubectl exec al2027-test -- uname -r
7.2.8-7.108.amzn2027.x86_64

A managed nodegroup with amiFamily: AmazonLinux2027 fails validation:

managedNodeGroups[0].amiFamily AmazonLinux2027 is not supported for managed nodegroups yet, use a self-managed nodegroup (nodeGroups) instead

The aws-auth path (CONFIG_MAP clusters) is covered by unit tests. A system:node:{{SessionName}} mapping was also tested by hand on the same cluster and the node joined.

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the userdocs directory)
• Manually tested
• Made sure the title of the PR is a good description that can go into the release notes
• (Core team) Added labels for change area (e.g. area/nodegroup) and kind (e.g. kind/improvement)

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟

[github-actions]

Hello maitreya526 👋 Thank you for opening a Pull Request in eksctl project. The team will review the Pull Request and aim to respond within 1-10 business days. Meanwhile, please read about the Contribution and Code of Conduct guidelines here. You can find out more information about eksctl on our website