How to Upgrade EKS 1. 32: Making the Switch from bootstrap. sh to nodeadm

Moving from EKS version 1.31 to 1.32 brings a major shift in how Kubernetes clusters on Amazon’s Elastic Kubernetes Service are managed, especially regarding node bootstrap processes. The old, familiar bootstrap.sh script that’s been used for years to configure worker nodes is being fully replaced by a new tool called nodeadm. This change isn’t just about tooling—it’s tied closely to the underlying operating system transition from Amazon Linux 2 (AL2) AMIs to Amazon Linux 2023 (AL2023) and Bottlerocket AMIs. What's more, after November 26, 2025, Amazon will stop publishing EKS-optimized AL2 AMIs, making this upgrade a critical deadline for many teams. Clusters currently running on EKS 1.31 or earlier with AL2-based node groups face immediate compatibility issues when upgrading. Since bootstrap.sh and related files like /etc/eks/bootstrap.sh and /etc/eks/eni-max-pods.txt won't exist in AL2023, nodes won’t join the cluster unless user-data scripts are updated. This means any automation or Terraform templates relying on the old method will break and need to be rewritten to adapt to nodeadm’s new declarative style. Nodeadm isn’t just a drop-in replacement; it fundamentally changes how cluster information is provided. Unlike bootstrap.sh, which automatically discovered cluster metadata via the Amazon EKS DescribeCluster API, nodeadm demands explicit input of parameters such as the API server endpoint, certificate authority, and service CIDR. Node configuration customization, previously handled via --kubelet-extra-args, now requires using a YAML-based NodeConfigSpec. This shift is aimed at improving scalability and reducing API throttling during large deployments. Before starting the migration, it's essential to identify which clusters are affected by this shift. Teams should check their node groups’ AMI types using AWS CLI commands and review user-data scripts for references to bootstrap.sh. Deciding between AL2023 and Bottlerocket for future AMIs is another important step. AL2023 offers more OS-level customization with SELinux permissive mode and IMDSv2-only enabled by default, while Bottlerocket focuses on a container-native, minimal attack surface design with automatic updates and security compliance out-of-the-box. Another critical preparation task is scanning for deprecated Kubernetes APIs with tools like kubent or pluto. Since Kubernetes often removes beta or deprecated APIs in new versions, this helps avoid workload breakage post-upgrade. Backups are also crucial because once an EKS cluster is upgraded, downgrading isn’t supported. Teams should take etcd snapshots, back up cluster configurations with tools like Velero, and document node-specific settings and IAM roles, especially those impacted by the nodeadm migration. After implementing nodeadm and moving to AL2023 images, teams should anticipate some initial debugging. The new components and altered node initialization flow mean troubleshooting methods will differ from previous versions. However, by following best practices and understanding the architecture changes, the upgrade can be smooth and set clusters up for future improvements and better scalability.