**帮助改进此页面** 要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。 # EKS AL2 和 AL2 加速型 AMI 过渡功能指南 **警告** Amazon EKS 已于 2025 年 11 月 26 日停止发布 EKS 优化型 Amazon Linux 2（AL2）AMI。基于 AL2023 和 Bottlerocket 的 Amazon EKS AMI 适用于所有支持的 Kubernetes 版本（包括 1.33 和更高版本）。 AWS 将于 2025 年 11 月 26 日终止对 EKS AL2 优化型和 AL2 加速型 AMI 的支持。尽管您可以在终止支持（EOS）日期（2025 年 11 月 26 日）之后继续使用 EKS AL2 AMI，但在该日期之后，EKS 将不再为 AL2 AMI 发布任何新的 Kubernetes 版本或更新，包括次要版本、补丁和错误修复。我们建议升级到 Amazon Linux 2023（AL2023）或 Bottlerocket AMI： + AL2023 启用了默认安全方法，包括预配置的安全策略、允许模式下的 SELinux、默认启用仅 IMDSv2 模式、优化的启动时间以及改进的程序包管理，增强了安全性和性能，非常适合需要大量自定义（例如直接操作系统级访问或大量节点更改）的基础设施。要了解更多信息，请参阅 [AL2023 常见问题](https://aws.amazon.com/linux/amazon-linux-2023/faqs/)，或查阅我们的详细迁移指引（[从 Amazon Linux 2 升级到 Amazon Linux 2023](al2023.md)）。 + Bottlerocket 采用专门构建的容器优化设计，可增强安全性、缩短启动时间和缩小攻击面，从而提高效率，非常适合节点自定义极少的容器原生方法。要了解更多信息，请参阅 [Bottlerocket 常见问题](https://aws.amazon.com/bottlerocket/faqs/)，或查阅我们的详细迁移指引（[使用优化版 Bottlerocket AMI 创建节点](eks-optimized-ami-bottlerocket.md)）。 另外，您可以在 EOS 日期（2025 年 11 月 26 日）之前，[构建自定义 EKS 优化版 Linux AMI](eks-ami-build-scripts.md)。此外，您可以在 Amazon Linux 2 EOS 日期（2026 年 6 月 30 日）之前，使用 Amazon Linux 2 基础实例构建自定义 AMI。 ## 迁移和支持常见问题 ### 如何从 AL2 迁移到 AL2023 AMI？ 我们建议您制定和实施迁移计划，其中应包括全面的应用程序工作负载测试和正式记录的回滚程序，然后按照 EKS 官方文档中[从 Amazon Linux 2 升级到 Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/al2023.html) 中的分步说明进行操作。 ### 我能否在 EKS 终止支持（EOS）日期之后用 EKS 优化型 AL2 AMI 构建自定义 AL2 AMI？ 虽然我们建议迁移到官方支持和发布的 EKS 优化型 AL2023 或 Bottlerocket AMI，不过您可以在 AL2 AMI EOS 日期（2025 年 11 月 26 日）之前构建自定义 EKS AL2 优化型和 AL2 加速型 AMI。您也可以在 Amazon Linux 2 EOS 日期（2026 年 6 月 30 日）之前使用 Amazon Linux 2 基础实例构建自定义 AMI。有关构建自定义 EKS AL2 优化型和 AL2 加速型 AMI 的分步说明，请参阅 EKS 官方文档中的[构建自定义 Amazon Linux AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-build-scripts.html)。 ### EKS Kubernetes 版本支持政策是否适用于 Amazon Linux 发行版？ 否。EKS AL2 优化型和 AL2 加速型 AMI 的 EOS 日期与 EKS 对 Kubernetes 版本的标准支持和扩展支持时间表无关。即使您使用 EKS 扩展支持，也需要迁移到 AL2023 或 Bottlerocket。 ### 从 cgroupv1 迁移到 cgroupv2 会如何影响我们的迁移？ [Kubernetes 社区](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/4569-cgroup-v1-maintenance-mode/README.md)已将（AL2 使用的）`cgroupv1` 支持改为维护模式，这意味着不会添加任何新功能，只会提供关键的安全和重要错误修复。要在 Kubernetes 中采用 `cgroupv2`，需要确保操作系统、内核、容器运行时和 Kubernetes 组件之间兼容。这需要使用默认启用 `cgroupv2` 的 Linux 发行版，例如 AL2023、Bottlerocket、Red Hat Enterprise Linux（RHEL）9\$1、Ubuntu 22.04\$1 或 Debian 11\$1。这些发行版附带的内核版本 ≥5.8，即在 Kubernetes 中支持 `cgroupv2` 的最低要求。要了解详情，请参阅 [About cgroup v2](https://kubernetes.io/docs/concepts/architecture/cgroups/)。 ### 如果我的自定义 AL2 AMI 需要使用 Neuron，该怎么办？ 您无法在基于 AL2 的 AMI 上以原生方式运行完全由 Neuron 驱动的应用程序。要在 AL2 AMI 上使用 AWS Neuron，您必须使用支持 Neuron 且具有非 AL2 Linux 发行版（例如 Ubuntu 22.04、Amazon Linux 2023 等）的容器对应用程序进行容器化，然后将这些容器部署到安装了 Neuron Driver (`aws-neuronx-dkms`) 的 AL2 AMI 上。 ### EKS AL2 AMI EOS 日期（2025 年 11 月 26 日）之后，我是否应该切换到原生 Amazon Linux 2 基础实例？ 切换至原生 Amazon Linux 2 基础实例，会缺失官方 EKS AL2 优化版 AMI 与 AL2 加速型 AMI 所提供的专属优化、容器运行时配置及定制化内容。若必须继续使用基于 AL2 的方案，建议通过[构建自定义 EKS 优化版 Linux AMI](eks-ami-build-scripts.md) 或 [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami) 中的 EKS AMI 构建模板，来制作自定义 AMI。此举可确保与现有工作负载的兼容性，并可在 Amazon Linux 2 EOS 日期（2026 年 6 月 30 日）前，持续获取 AL2 内核更新。 ### 在 EKS AL2 AMI EOS 日期（2025 年 11 月 26 日）之后，若通过 EKS AMI GitHub 存储库构建自定义 AL2 AMI，来自 amzn2-core 与 amzn2extra-docker 等软件源的软件包可获得何种支持？ [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami) 中的 EKS AMI 构建模板，会通过 YUM 工具从 [amzn2-core](https://docs.aws.amazon.com/linux/al2/ug/managing-software.html)、[amzn2extra-docker](https://docs.aws.amazon.com/linux/al2/ug/managing-software.html) 等标准 Amazon Linux 2 软件源拉取软件包。在 EKS AL2 AMI EOS 日期（2025 年 11 月 26 日）之后，上述软件源仍会持续提供支持，直至 Amazon Linux 2 的整体 EOS 日期（2026 年 6 月 30 日）。需注意，此期间的支持范围仅限内核更新，意即需手动管理并应用其他软件包更新、安全补丁及所有非内核依赖项，以保障系统的安全性与兼容性。 ### 在搭载 AL2023 的 Amazon EKS 上运行且使用旧版 JDK8 的 Java 应用，为何可能出现内存不足（OOM）异常与容器组（pod）重启问题？该如何解决此问题？ 在 Amazon EKS AL2023 节点上运行时，依赖 `jdk8u372` 之前版本 JDK 8 的 Java 应用，可能会引发 OOM 异常与容器组（pod）重启，原因在于这些版本的 JVM 与 `cgroupv2` 不兼容。此问题的具体成因是：在 Amazon Linux 2023 的默认配置下，JVM 无法通过 `cgroupv2` 机制识别容器的内存限制。因此，JVM 会基于节点的总内存进行堆内存分配，而非基于容器组（pod）中定义的内存限制。该问题的根源是 `cgroupv2` 变更了内存限制数据的存储路径，导致旧版 Java 无法正确读取可用内存信息，误将节点级别的资源当作容器可用资源。以下是几种可行的解决办法： + **升级 JDK 版本**：升级到 `jdk8u372` 或更高版本，或升级到完全支持 `cgroupv2` 的新版 JDK，即可解决此问题。有关完全兼容 `cgroupv2` 的 Java 版本列表，请参阅[关于 cgroup v2](https://kubernetes.io/docs/concepts/architecture/cgroups/)。 + **构建自定义 AMI**：若必须继续使用基于 AL2 的方案，可通过[构建自定义 EKS 优化版 Linux AMI](eks-ami-build-scripts.md) 或 [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami)，构建基于 AL2 的自定义 AMI（支持至 2025 年 11 月 26 日）。例如，您可构建基于 AL2 的 v1.33 AMI（支持到 2025 年 11 月 26 日）。Amazon EKS 会在 EKS AL2 EOS 日期（2025 年 11 月 26 日）之前，持续提供基于 AL2 的 AMI。在 EOS 日期（2025 年 11 月 26 日）之后，您需自行构建 AMI。 + **启用 cgroupv1**：若必须继续使用 `cgroupv1`，可在 EKS AL2023 AMI 上启用 `cgroupv1`。执行命令 `sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"`，重启系统（例如运行 Amazon Linux 2023 的 EC2 实例或节点），即可完成启用。此操作会修改系统的启动参数（例如，在 GRUB 配置中添加内核参数 systemd.unified\$1cgroup\$1hierarchy=0，指示 systemd 使用传统的 `cgroupv1` 层级架构），从而启用 `cgroupv1`。需注意，执行该 grubby 命令后，系统内核的启动配置会被修改为启用 `cgroupv1` 且禁用 `cgroupv2`。节点上仅会采用其中一种 cgroup 版本进行活跃的资源管理。此模式与“启用 `cgroupv2` 并兼容 `cgroupv1` API 向后兼容”的模式并不相同。 **警告** 我们不建议继续使用 `cgroupv1`，而是推荐迁移到 `cgroupv2`。Kubernetes 社区已将 `cgroupv1` 的支持（即 AL2 所采用的版本）调整为维护模式。这意味着该版本将不再新增功能或推送更新，仅会针对严重安全漏洞与重大程序缺陷提供修复补丁。`cgroupv1` 的支持功能预计将在后续版本中被完全移除，不过官方尚未公布具体的移除日期。若在使用 `cgroupv1` 时遇到相关问题，AWS 将无法提供技术支持，同时会建议升级到 `cgroupv2`。 ## 兼容性与版本 ### AL2 AMI 支持的 Kubernetes 版本 Kubernetes 版本 1.32 是 Amazon EKS 将为其发布 AL2（Amazon Linux 2）AMI 的最后一个版本。对于不高于 1.32 的[受支持](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) Kubernetes 版本，EKS 将在 2025 年 11 月 26 日之前继续发布 AL2 AMI（AL2\$1ARM\$164、AL2\$1x86\$164）和 AL2 加速型 AMI（AL2\$1x86\$164\$1GPU）。在该日期之后，EKS 将停止为所有 Kubernetes 版本发布 AL2 优化型和 AL2 加速型 AMI。请注意，EKS AL2 优化型和 AL2 加速型 AMI 的 EOS 日期与 EKS 对 Kubernetes 版本的标准支持和扩展支持时间表无关。 ### AL2、AL2023 和 Bottlerocket AMI 支持的驱动程序和 Linux 内核版本比较 | 组件 | EKS AL2 AMI | EKS AL2023 AMI | EKS Bottlerocket AMI | | --- | --- | --- | --- | | 基础操作系统兼容性 | RHEL7/CentOS 7 | Fedora/CentOS 9 | 不适用 | | [CUDA 用户模式驱动程序](https://docs.nvidia.com/deploy/cuda-compatibility/why-cuda-compatibility.html#why-cuda-compatibility) | 12.x | 12.x、13.x | 12.x、13.x | | NVIDIA GPU 驱动程序 | R570 | R580 | R570、R580 | | AWS Neuron 驱动程序 | 2.20\$1 | 2.20\$1 | 2.20\$1 | | Linux 内核 | 5.10 | 6.1、6.12 | 6.1、6.12 | 有关 NVIDIA 驱动程序及 CUDA 兼容性的更多信息，请参阅 [NVIDIA 文档](https://docs.nvidia.com/datacenter/tesla/drivers/index.html#supported-drivers-and-cuda-toolkit-versions)。 ### AWS Neuron 与 AL2 AMI 的兼容性 从 [AWS Neuron 版本 2.20](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/release-notes/prev/rn.html#neuron-2-20-0-whatsnew) 起，基于 EKS AL 的 AMI 所用 Neuron 运行时 (`aws-neuronx-runtime-lib`) 不再支持 Amazon Linux 2（AL2）。Neuron 驱动程序 (`aws-neuronx-dkms`) 现在是唯一支持 Amazon Linux 2 的 AWS Neuron 程序包。这意味着您无法在基于 AL2 的 AMI 上以原生方式运行由 Neuron 驱动的应用程序。要在 AL2023 AMI 上安装 Neuron，请参阅 [AWS Neuron 安装](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/index.html#setup-guide-index)指南。 ### Kubernetes 与 AL2 AMI 的兼容性 Kubernetes 社区已将（AL2 使用的）`cgroupv1` 支持改为维护模式。这意味着不会添加任何新功能，只会提供关键的安全和重要错误修复。任何依赖于 cgroupv2 的 Kubernetes 功能（例如 MemoryQoS 和增强的资源隔离），都不支持 AL2。此外，Amazon EKS Kubernetes 1.32 版本是最后一个支持 AL2 AMI 的版本。为保持与最新 Kubernetes 版本的兼容性，我们建议迁移到 AL2023 或 Bottlerocket，因为其已默认启用 `cgroupv2`。 ### Linux 版本与 AL2 AMI 的兼容性 在终止支持（EOS）日期（2026 年 6 月 30 日）之前，AWS 将为 Amazon Linux 2（AL2）提供支持。但随着 AL2 的过时，整个 Linux 社区对新应用程序和功能的支持变得越来越少。AL2 AMI 基于 [Linux 内核 5.10](https://docs.aws.amazon.com/linux/al2/ug/kernel.html)，而 AL2023 使用 [Linux 内核 6.1](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html)。与 AL2023 不同，整个 Linux 社区对 AL2 的支持十分有限。这意味着许多上游 Linux 程序包和工具需要向后移植才能兼容 AL2 使用的早期内核版本；同时由于内核版本过时，无法支持某些现代 Linux 功能和安全改进，许多开源项目已弃用或限制了对较早内核版本（如 5.10）的支持。 ### AL2023 中未包含已弃用的程序包 AL2023 中未包含或已更改的一些最常见程序包包括： + Amazon Linux 2023 不再包含 [Amazon Linux 2 中的某些源二进制包](https://docs.aws.amazon.com/linux/al2023/release-notes/removed-AL2023.6-AL2.html) + Amazon Linux 在 AL2023 中更改了支持不同版本程序包（例如 [amazon-linux-extras system](https://repost.aws/questions/QUWGU3VFJMRSGf6MDPWn4tLg/how-to-resolve-amazon-linux-extras-in-al2023)）的方式 + AL2023 不支持[适用于 Enterprise Linux 的附加程序包（EPEL）](https://docs.aws.amazon.com/linux/al2023/ug/epel.html) + AL2023 不支持 [32 位应用程序](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2.html#deprecated-32bit-rpms) 要了解更多信息，请参阅 [Comparing AL2 and AL2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html)。 ### AL2、AL2023 和 Bottlerocket 的 FIPS 验证方式比较 Amazon Linux 2（AL2）、Amazon Linux 2023（AL2023）和 Bottlerocket 提供了对《联邦信息处理标准》（FIPS）合规性的支持。 + AL2 通过了 FIPS 140-2 认证，AL2023 通过了 FIPS 140-3 认证。要在 AL2023 上启用 FIPS 模式，请在您的 Amazon EC2 实例上安装必要的程序包，然后按照 [Enable FIPS Mode on AL2023](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html) 中的说明完成配置步骤即可。要了解更多信息，请参阅 [AL2023 常见问题](https://aws.amazon.com/linux/amazon-linux-2023/faqs)。 + Bottlerocket 提供了特别针对 FIPS 构建的专用变体，将内核和用户空间组件限制为使用已提交给 FIPS 140-3 加密模块验证计划的加密模块。 ### EKS AMI 驱动程序和版本更改日志 有关所有 EKS AMI 组件及其版本的完整列表，请参阅 GitHub 上的 [Amazon EKS AMI Release Notes](https://github.com/awslabs/amazon-eks-ami/releases)。