**帮助改进此页面**
要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。
# 从 Amazon Linux 2 升级到 Amazon Linux 2023
**警告**
Amazon EKS 已于 2025 年 11 月 26 日停止发布 EKS 优化型 Amazon Linux 2（AL2）AMI。基于 AL2023 和 Bottlerocket 的 Amazon EKS AMI 适用于所有支持的 Kubernetes 版本（包括 1.33 和更高版本）。
AL2023 是一款基于 Linux 的操作系统，旨在为云应用程序提供安全、稳定和高性能的环境。它是 Amazon Web Services 推出的下一代 Amazon Linux，适用于所有支持的 Amazon EKS 版本。
AL2023 比 AL2 提供了多项改进。有关完整比较，请参阅《Amazon Linux 2023 用户指南》**中的[比较 AL2 和 Amazon Linux 2023](https://docs.amazonaws.cn/linux/al2023/ug/compare-with-al2.html)。已在 AL2 中添加、升级和移除了多个程序包。强烈建议在升级之前使用 AL2023 测试您的应用程序。有关 AL2023 中所有程序包更改的列表，请参阅《Amazon Linux 2023 发行说明》**中的 [Amazon Linux 2023 的程序包更改](https://docs.amazonaws.cn/linux/al2023/release-notes/compare-packages.html)。
除了这些更改之外，您还应了解以下事项：
+ AL2023 引入了使用 YAML 配置架构的新节点初始化流程 `nodeadm`。如果您使用的是自行管理的节点组或带有启动模板的 AMI，则在创建新节点组时，现在需要明确提供其它集群元数据。以下是最低必需参数的[示例](https://awslabs.github.io/amazon-eks-ami/nodeadm/)，其中 `apiServerEndpoint`、`certificateAuthority` 和服务 `cidr` 是必需的：
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
在 AL2 中，来自这些参数的元数据是从 Amazon EKS `DescribeCluster` API 调用中发现的。使用 AL2023，这种行为发生了变化，因为在大型节点纵向扩展期间，额外的 API 调用有节流风险。如果您使用的是没有启动模板的托管节点组或者 Karpenter，则此更改不会对您产生影响。有关 `certificateAuthority` 和服务 `cidr` 的更多信息，请参阅《Amazon EKS API 参考》**中的 [https://docs.amazonaws.cn/eks/latest/APIReference/API_DescribeCluster.html](https://docs.amazonaws.cn/eks/latest/APIReference/API_DescribeCluster.html)。
+ 对于 AL2023，`nodeadm` 也可以使用 [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec) 来更改格式，将参数应用于每个节点的 `kubelet`。而在 AL2 中，这通过 `--kubelet-extra-args` 参数完成。这通常用于向节点添加标签和污点。以下示例显示了如何将 `maxPods` 和 `--node-labels` 应用于节点。
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: test-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
maxPods: 110
flags:
- --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test
```
+ AL2023 需要 Amazon VPC CNI 版本 `1.16.2` 或更高版本。
+ 默认情况下，AL2023 需要 `IMDSv2`。`IMDSv2` 有多项益处，可助于改善安全状况。它使用面向会话的身份验证方法，需要在简单的 HTTP PUT 请求中创建密钥令牌才能启动会话。会话令牌的有效时间可以介于 1 秒到 6 小时之间。有关如何从 `IMDSv1` 转换到 `IMDSv2` 的更多信息，请参阅[转换到使用实例元数据服务版本 2](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) 和[获取 IMDSv2 的全部优势并在 Amazon 基础设施中禁用 IMDSv1](https://www.amazonaws.cn/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure)。如果您想使用 `IMDSv1`，则您仍然可以通过使用实例元数据选项启动属性手动覆盖设置来做到这一点。
**注意**
对于使用 AL2023 的 `IMDSv2`，托管节点组的默认跳数可能会有所不同：
不使用启动模板时，默认值设置为 `1`。这意味着，容器无法使用 IMDS 访问节点的凭证。如果您需要容器访问节点的凭证，仍然可以通过使用[自定义 Amazon EC2 启动模板](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html)来实现。
在启动模板中使用自定义 AMI 时，默认 `HttpPutResponseHopLimit` 设置为 `2`。您可以手动覆盖启动模板中的 `HttpPutResponseHopLimit`。
或者，您可以使用 [Amazon EKS 容器组身份](pod-identities.md)来提供凭证，而不是 `IMDSv2`。
+ AL2023 采用下一代统一控制组层次结构 (`cgroupv2`)。`cgroupv2` 用于实施容器运行时，并由 `systemd` 实施。虽然 AL2023 仍然包含可以使用 `cgroupv1` 使系统运行的代码，但这不是建议或支持的配置。此配置将在未来的 Amazon Linux 主要版本中完全移除。
+ `eksctl` 需要 `eksctl` 版本 `0.176.0` 或更高版本才能支持 AL2023。
对于以前存在的托管节点组，您可以执行就地升级或蓝/绿升级，具体取决于您所使用的启动模板的方式：
+ 如果您在托管节点组中使用自定义 AMI，则可以通过交换启动模板中的 AMI ID 来执行就地升级。在执行此升级策略之前，您应确保您的应用程序和所有用户数据首先传输到 AL2023。
+ 如果您将托管节点组与标准启动模板或未指定 AMI ID 的自定义启动模板结合使用，则需要使用蓝/绿策略升级。蓝/绿升级通常更复杂，需要创建一个全新的节点组，在其中指定 AL2023 作为 AMI 类型。然后，需要小心配置新的节点组，以确保来自 AL2 节点组的所有自定义数据都与新操作系统兼容。在应用程序中对新节点组进行测试和验证后，容器组（pod）可以从旧节点组迁移到新的节点组。迁移完成之后，您就可以删除旧节点组。
如果您使用的是 Karpenter 且希望使用 AL2023，则需使用 AL2023 修改 `EC2NodeClass` `amiFamily` 字段。默认情况下，偏差在 Karpenter 中启用。这意味着，`amiFamily` 字段更改后，Karpenter 会自动将 Worker 节点更新为最新的 AMI（如果有）。
## 有关 nodeadm 的其他信息
在使用 EKS 优化的 Amazon Linux 2023 AMI 或通过 amazon-eks-ami GitHub 官方存储库中提供的 Packer 脚本构建自定义 EKS Amazon Linux 2023 AMI 时，应避免在 EC2 用户数据中或作为自定义 AMI 的一部分明确运行 nodeadm init。
如果您想在用户数据中生成动态 NodeConfig，可以将该配置写入到 `/etc/eks/nodeadm.d` 中的嵌入式 yaml 或 json 文件中。这些配置文件在启动过程后期 nodeadm init 自动启动时被合并并应用于您的节点。例如：
```
cat > /etc/eks/nodeadm.d/additional-node-labels.yaml << EOF
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
kubelet:
flags:
- --node-labels=foo=bar
EOF
```
经 EKS 优化的 Amazon Linux 2023 AMI 会通过两个独立的 systemd 服务分两个阶段自动执行 nodeadm init 操作：nodeadm-config 在用户数据执行之前运行，而 nodeadm-run 则在之后运行。nodeadm-config 服务在用户数据运行之前为 containerd 和 kubelet 建立基准配置。nodeadm-run 服务运行选定的系统进程守护程序，并在用户数据执行后完成所有最终配置。如果通过用户数据或自定义 AMI 再次运行 nodeadm init 命令，可能会破坏关于执行顺序的假设，从而导致意想不到的结果，包括配置错误的 ENI。