**協助改進此頁面**
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 使用最佳化的 Amazon Linux AMI 建立節點
Amazon Elastic Kubernetes Service (Amazon EKS) 提供專門的 Amazon Machine Image (AMIs)，針對執行 Kubernetes 工作者節點進行最佳化。這些 EKS 最佳化 Amazon Linux (AL) AMIs 已預先設定基本元件，例如 `kubelet`、AWS IAM Authenticator 和 `containerd`，以確保叢集內的無縫整合和安全性。本指南詳細說明可用的 AMI 版本，並概述加速運算和 Arm 型架構的特殊選項。
## 考量事項
+ 您可以透過選擇所需版本的標籤，在 [Amazon Linux 安全中心](https://alas.aws.amazon.com/)追蹤 Amazon Linux 的安全或隱私權事件。您也可以訂閱適用的 RSS 摘要。安全與隱私權事件包含問題的概觀、哪些套件受到影響，以及如何更新您的執行個體以修正問題。
+ 部署加速或 Arm AMI 之前，請先檢閱 [Amazon EKS 最佳化加速 Amazon Linux AMIs ](#gpu-ami)和 中的資訊[Amazon EKS 最佳化 Arm Amazon Linux AMIs](#arm-ami)。
+ Amazon EC2 `P2` 執行個體在 Amazon EKS 上不受支援, 因為它們需要 `NVIDIA` 驅動程式版本 470 或更早版本。
+ 在版本 `1.30` 或更新版本的叢集中，任何新建立的受管節點群組將自動預設使用 AL2023 作為節點作業系統。
## Amazon EKS 最佳化加速 Amazon Linux AMIs
Amazon EKS 最佳化加速 Amazon Linux (AL) AMIs 是以標準 EKS 最佳化 Amazon Linux AMIs 為基礎建置。它們已設定為 Amazon EKS 節點的選用映像，用以支援以 GPU、[Inferentia](https://aws.amazon.com/machine-learning/inferentia/) 和 [Trainium](https://aws.amazon.com/machine-learning/trainium/) 為基礎的工作負載。
如需詳細資訊，請參閱[針對 GPU 執行個體使用 EKS 最佳化AMIs](ml-eks-optimized-ami.md)。
## Amazon EKS 最佳化 Arm Amazon Linux AMIs
Arm 執行個體可為擴增和 Arm 型應用程式節省大量的成本，例如 Web 伺服器、容器化微型服務、快取機群和分散式資料存放區。將 Arm 節點新增至叢集時，請檢閱下列考量事項。
+ 如果叢集是在 2020 年 8 月 17 日之前部署，您必須對重要的叢集附加元件資訊清單進行一次性升級。如此一來，Kubernetes 就可以為叢集中使用中的每個硬體架構提取正確的映像。如需更新叢集附加元件的詳細資訊，請參閱 [步驟 1：準備升級](update-cluster.md#update-existing-cluster)。如果您在 2020 年 8 月 17 當天或之後部署叢集，則 CoreDNS、`kube-proxy` 和 Kubernetes 專用 Amazon VPC CNI 外掛程式已經具有多架構能力。
+ 部署至 Arm 節點的應用程式必須針對 Arm 進行編譯。
+ 如果您在現有叢集中部署了 DaemonSet，或者您想將它們部署到您也想在其中部署 Arm 節點的新叢集，請確認您的 DaemonSet 是否可以在您叢集中的所有硬體架構上執行。
+ 您可以在相同的叢集中執行 Arm 節點群組和 x86 節點群組。如果您這麼做，請考慮將多架構容器映像部署到容器儲存庫 (例如 Amazon Elastic Container Registry)，然後將節點選取器新增至資訊清單，以便 Kubernetes 知道 Pod 可以部署到哪些硬體架構。如需詳細資訊，請參閱《Amazon ECR 使用者指南》**中的[推送多架構映像](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-multi-architecture-image.html)和[適用於 Amazon ECR 的多架構容器映像簡介](https://aws.amazon.com/blogs/containers/introducing-multi-architecture-container-images-for-amazon-ecr)部落格一文。
## 其他資訊
如需使用 Amazon EKS 最佳化 Amazon Linux AMIs 的詳細資訊，請參閱下列章節：
+ 若要將 Amazon Linux 與受管節點群組搭配使用，請參閱 [透過受管節點群組來簡化節點生命週期](managed-node-groups.md)。
+ 若要啟動自我管理的 Amazon Linux 節點，請參閱 [擷取建議的 Amazon Linux AMI ID](retrieve-ami-id.md)。
+ 如需版本資訊，請參閱[擷取 Amazon Linux AMI 版本資訊](eks-linux-ami-versions.md)。
+ 若要擷取 Amazon EKS 最佳化 Amazon Linux AMIs 的最新 IDs，請參閱 [擷取建議的 Amazon Linux AMI ID](retrieve-ami-id.md)。
+ 如需用於建置 Amazon EKS 最佳化 AMIs開放原始碼指令碼，請參閱 [建置自訂 EKS 最佳化的 Amazon Linux AMI](eks-ami-build-scripts.md)。
# 從 Amazon Linux 2 升級到 Amazon Linux 2023
**警告**
Amazon EKS 已於 2025 年 11 月 26 日停止發佈 EKS 最佳化的 Amazon Linux 2 (AL2) AMIs。適用於 Amazon EKS 的 AL2023 和 Bottlerocket 型 AMIs 適用於所有支援的 Kubernetes 版本，包括 1.33 和更新版本。
AL2023 是以 Linux 為基礎的作業系統，旨在為您的雲端應用程式提供安全、穩定且高效能的環境。它是 Amazon Web Services 推出的下一代 Amazon Linux，適用於所有受支援的 Amazon EKS 版本。
相較於 AL2，AL2023 提供了多項改進。有關完整的比較，請參閱《*Amazon Linux 2023 使用者指南*》中的[比較 AL2 和 Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html)。已從 AL2 新增、升級和移除數個套件。強烈建議在升級前，使用 AL2023 測試您的應用程式。有關 AL2023 中所有套件變更的清單，請參閱《[Amazon Linux 2023 版本備註](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html)》中的 *Amazon Linux 2023 中的套件變更*。
除了上述變更，您還應注意以下事項：
+ AL2023 引入了新的節點初始化程序 `nodeadm`，該程序使用 YAML 組態結構描述。如果您使用自我管理節點群組或具有啟動範本的 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.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/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.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html)和[取得 IMDSv2 的完整優點，以及在整個 AWS 基礎設施中停用 IMDSv1](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure)。若您仍想使用 `IMDSv1`，可以透過使用執行個體中繼資料選項啟動屬性，手動覆寫設定來實現。
**注意**
對於 AL2023 的 `IMDSv2`，受管節點群組的預設跳數可能有所不同：
當不使用啟動範本時，預設值設為 `1`。這意味著容器將無法使用 IMDS 存取節點的憑證。若您的容器需要存取節點的憑證，您仍可透過使用[自訂的 Amazon EC2 啟動範本](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html)來實現。
當在啟動範本中使用自訂 AMI 時，預設的 `HttpPutResponseHopLimit` 設為 `2`。您可以在啟動範本中手動覆寫 `HttpPutResponseHopLimit`。
或者，您可使用 [Amazon EKS Pod 身分識別](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，需要修改 `EC2NodeClass` `amiFamily` 欄位為 AL2023。預設情況下，Karpenter 啟用了偏離。這意味著一旦 `amiFamily` 欄位被更改，Karpenter 將在最新 AMI 可用時自動更新您的工作節點。
## 有關 nodeadm 的其他資訊
使用 EKS 最佳化 Amazon Linux 2023 AMI 或透過官方 amazon-eks-ami GitHub 儲存庫中提供的 Packer 指令碼建置自訂 EKS Amazon Linux 2023 AMI 時，您應該避免在 EC2 使用者資料內或作為自訂 AMI 的一部分明確執行 nodeadm init。
如果您想要在使用者資料中產生動態 NodeConfig，您可以將該組態寫入 中的插入式 yaml 或 json 檔案`/etc/eks/nodeadm.d`。當 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 AMIs 會透過單獨的系統化服務，以兩個階段自動執行 nodeadm init：Nodeadm-config 會在使用者資料執行之前執行，而 nodeadm-run 會在之後執行。nodeadm-config 服務會在使用者資料執行之前建立容器化和 kubelet 的基準組態。nodeadm-run 服務會執行選取系統協助程式，並在使用者資料執行後完成任何最終組態。如果透過使用者資料或自訂 AMI 再執行一次 nodeadm init 命令，可能會破壞有關執行排序的假設，導致非預期的結果，包括設定ENIs。
# 擷取 Amazon Linux AMI 版本資訊
Amazon EKS 最佳化 Amazon Linux AMI 是由 Kubernetes 版本和 AMI 發行日期進行版本化，格式如下：
```
k8s_major_version.k8s_minor_version.k8s_patch_version-release_date
```
每個 AMI 發行版本均包含 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)、Linux 核心和 [containerd](https://containerd.io/) 的各種版本。加速的 AMI 亦包括 NVIDIA 驅動程序的各種版本。您現在可以在 GitHub 上的[變更日誌](https://github.com/awslabs/amazon-eks-ami/blob/main/CHANGELOG.md)找到此版本資訊。
# 擷取建議的 Amazon Linux AMI ID
您在部署節點時，可針對預先建置的 Amazon EKS 最佳化 Amazon Machine Image (AMI) 指定 ID。若要擷取符合您所需組態的 AMI ID，請查詢 AWS Systems Manager 參數存放區 API。使用此 API 無需手動查詢 Amazon EKS 最佳化的 AMI ID。如需詳細資訊，請參閱 [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html)。您使用的 [IAM 主體](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)必須擁有 `ssm:GetParameter` IAM 許可，才能擷取 Amazon EKS 最佳化 AMI 中繼資料。
您可透過以下命令擷取最新建議的 Amazon EKS 最佳化 Amazon Linux AMI 的映像檔 ID，這會使用子參數 `image_id`。視需要對命令進行下列修改，然後執行修改後的命令：
+ 使用 [Amazon EKS 支援的版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)來取代 ``。
+ 使用以下其中一個選項來取代 *ami-type*。若要了解 Amazon EC2 執行個體類型的相關詳細資訊，請參閱 [Amazon EC2 執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。
+ 若是 Amazon Linux 2023 (AL2023) `x86` 型執行個體，則使用 *amazon-linux-2023/x86\$164/standard*。
+ 若是 AL2023 ARM 執行個體，例如 [AWS Graviton](https://aws.amazon.com/ec2/graviton/) 型執行個體，則使用 *amazon-linux-2023/arm64/standard*。
+ 若是最近核准的 AL2023 NVIDIA `x86` 型執行個體，則使用 *amazon-linux-2023/x86\$164/nvidia*。
+ 若是最近核准的 AL2023 NVIDIA `arm64` 型執行個體，則使用 *amazon-linux-2023/arm64/nvidia*。
+ 若是最近的 AL2023 [AWS Neuron](https://aws.amazon.com/machine-learning/neuron/) 執行個體，則使用 *amazon-linux-2023/x86\$164/neuron*。
+ `` 將 取代為您想要 AMI ID 的 [Amazon EKS 支援 AWS 區域](https://docs.aws.amazon.com/general/latest/gr/eks.html)。
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami///recommended/image_id \
--region --query "Parameter.Value" --output text
```
下面介紹了取代預留位置之後的命令範例。
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.31/amazon-linux-2023/x86_64/standard/recommended/image_id \
--region us-west-2 --query "Parameter.Value" --output text
```
範例輸出如下。
```
ami-1234567890abcdef0
```
# 建置自訂 EKS 最佳化的 Amazon Linux AMI
**警告**
Amazon EKS 已於 2025 年 11 月 26 日停止發佈 EKS 最佳化的 Amazon Linux 2 (AL2) AMIs。適用於 Amazon EKS 的 AL2023 和 Bottlerocket 型 AMIs 適用於所有支援的 Kubernetes 版本，包括 1.33 和更新版本。
Amazon EKS 在 [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami) 儲存庫中提供開放原始碼建置指令碼，可用來檢視 的組態`kubelet`、執行時間、適用於 Kubernetes 的 AWS IAM Authenticator，以及從頭開始建置您自己的 AL 型 AMI。
此儲存庫包含[適用於 AL2 的專用引導指令碼](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)，以及[適用於 AL2023 的 nodeadm 工具](https://awslabs.github.io/amazon-eks-ami/nodeadm/)，其會在開機時間執行。這些指令碼會設定您的執行個體的憑證資料、控制平面端點、叢集名稱等。指令碼被視為 Amazon EKS 最佳化 AMI 建置的事實來源，因此您可以遵循 GitHub 儲存庫來監控 AMIs的變更。
使用 EKS 最佳化 AMIs 作為基礎建置自訂 AMIs 時，不建議或支援執行作業系統升級 （即 `dnf upgrade`) 或升級 EKS 最佳化 AMIs 中包含的任何 Kubernetes 或 GPU 套件，因為這會破壞元件相容性。如果您確實升級 EKS 最佳化 AMIs 中包含的作業系統或套件，建議您在部署到生產環境之前，先在開發或預備環境中徹底測試。
為 GPU 執行個體建置自訂 AMIs 時，建議您為要執行的每個執行個體類型產生和系列分別建置自訂 AMIs。EKS 最佳化加速 AMIs 會根據基礎執行個體類型產生和系列，在執行時間選擇性地安裝驅動程式和套件。如需詳細資訊，請參閱[安裝](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/provisioners/install-nvidia-driver.sh)和[執行時間](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/gpu/nvidia-kmod-load.sh)的 EKS AMI 指令碼。
## 先決條件
+ [安裝 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)
+ [安裝 HashiCorp Packer 1.9.4 版及以上](https://developer.hashicorp.com/packer/downloads)
+ [安裝 GNU Make](https://www.gnu.org/software/make/)
## 快速指南
此快速入門會向您顯示在您的 AWS 帳戶中建立自訂 AMI 的命令。要進一步了解可用於自訂 AMI 的組態，請參閱 [Amazon Linux 2023 ](https://awslabs.github.io/amazon-eks-ami/usage/al2023/)頁面上的範本變數。
### 先決條件
安裝所需 [Amazon 外掛程式](https://developer.hashicorp.com/packer/integrations/hashicorp/amazon)。例如：
```
packer plugins install github.com/hashicorp/amazon
```
### 步驟 1. 設定您的環境
複製或分支官方 Amazon EKS AMI 儲存庫。例如：
```
git clone https://github.com/awslabs/amazon-eks-ami.git
cd amazon-eks-ami
```
確認 Packer 已安裝：
```
packer --version
```
### 步驟 2. 建立自訂 AMI
以下是各種自訂 AMI 的範例命令。
**基本 NVIDIA AL2 AMI：**
```
make k8s=1.31 os_distro=al2 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**基本 NVIDIA AL2023 AMI：**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**STIG 合規 Neuron AL2023 AMI：**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=neuron \
enable_fips=true \
source_ami_id=ami-0abcd1234efgh5678 \
kms_key_id=alias/aws-stig
```
執行這些命令後，Packer 將執行以下操作：\$1 啟動一個臨時 Amazon EC2 執行個體。\$1 安裝 Kubernetes 元件、驅動程式和組態。\$1 在 AWS 帳戶中建立 AMI。
預期的輸出應類似以下：
```
==> Wait completed after 8 minutes 42 seconds
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
```
### 步驟 3。檢視預設值
要檢視預設值和其他選項，請執行以下命令：
```
make help
```