**協助改進此頁面**
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 從 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。