如何升级EKS 1.32：从bootstrap.sh切换到nodeadm

从EKS版本1.31升级到1.32带来了亚马逊弹性Kubernetes服务（EKS）集群管理方式的重大转变，尤其是在节点引导流程方面。多年来用于配置工作节点的旧版bootstrap.sh脚本将被全新工具nodeadm完全取代。这一变化不仅是工具层面的，更与操作系统从Amazon Linux 2（AL2）AMI向Amazon Linux 2023（AL2023）和Bottlerocket AMI的底层迁移密切相关。此外，2025年11月26日之后，亚马逊将停止发布EKS优化的AL2 AMI，使得此次升级成为许多团队的关键截止日期。 当前运行EKS 1.31或更早版本且基于AL2的节点组在升级时将面临兼容性问题。由于AL2023中不存在bootstrap.sh及相关文件（如/etc/eks/bootstrap.sh和/etc/eks/eni-max-pods.txt），节点将无法加入集群，除非更新用户数据脚本。这意味着依赖旧方法的自动化或Terraform模板将失效，需重写以适应nodeadm的新声明式风格。 nodeadm不仅是替代品，更根本改变了集群信息的提供方式。与bootstrap.sh通过Amazon EKS DescribeCluster API自动发现集群元数据不同，nodeadm要求显式输入API服务器端点、证书颁发机构和服务CIDR等参数。此前通过--kubelet-extra-args进行的节点配置自定义，现在需使用基于YAML的NodeConfigSpec。此举旨在提升可扩展性并减少大规模部署时的API限流。 迁移前，必须识别受影响的集群。团队应使用AWS CLI命令检查节点组的AMI类型，并审查用户数据脚本中是否引用bootstrap.sh。选择AL2023还是Bottlerocket作为未来AMI也是重要步骤。AL2023提供更多操作系统级定制，默认启用SELinux宽容模式和仅IMDSv2，而Bottlerocket则专注于容器原生、最小攻击面设计，具备自动更新和安全合规性。 另一个关键准备工作是使用kubent或pluto等工具扫描已弃用的Kubernetes API。由于Kubernetes常在新版本中移除beta或弃用API，此举有助于避免升级后工作负载中断。备份同样重要，因为EKS集群升级后不支持降级。团队应拍摄etcd快照，使用Velero等工具备份集群配置，并记录节点特定设置和IAM角色，尤其是受nodeadm迁移影响的部分。 实施nodeadm并切换到AL2023镜像后，团队应预期初期调试工作。新组件和节点初始化流程的变化意味着故障排除方法将不同于以往版本。然而，通过遵循最佳实践并理解架构变更，升级过程可顺利进行，为未来改进和更好扩展性奠定基础。