從 Amazon Linux 2 升級到 Amazon Linux 2023 - Amazon EKS
有關 nodeadm 的其他資訊

協助改進此頁面

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的在 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。已從 AL2 新增、升級和移除數個套件。強烈建議在升級前，使用 AL2023 測試您的應用程式。有關 AL2023 中所有套件變更的清單，請參閱《Amazon Linux 2023 版本備註》中的 Amazon Linux 2023 中的套件變更。

除了上述變更，您還應注意以下事項：

  • AL2023 引入了新的節點初始化程序 nodeadm，該程序使用 YAML 組態結構描述。如果您使用自我管理節點群組或具有啟動範本的 AMI，則在建立新節點群組時，需要明確提供額外的叢集中繼資料。以下連結展示了一個包含最低必要參數的範例，其中 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 參考》中的 DescribeCluster。

  • 對於 AL2023，nodeadm 也更改了使用 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 版的轉換和取得 IMDSv2 的完整優點，以及在整個 AWS 基礎設施中停用 IMDSv1。若您仍想使用 IMDSv1，可以透過使用執行個體中繼資料選項啟動屬性，手動覆寫設定來實現。

    注意

    對於 AL2023 的 IMDSv2，受管節點群組的預設跳數可能有所不同：

    • 當不使用啟動範本時，預設值設為 1。這意味著容器將無法使用 IMDS 存取節點的憑證。若您的容器需要存取節點的憑證，您仍可透過使用自訂的 Amazon EC2 啟動範本來實現。

    • 當在啟動範本中使用自訂 AMI 時，預設的 HttpPutResponseHopLimit 設為 2。您可以在啟動範本中手動覆寫 HttpPutResponseHopLimit。

    或者，您可使用 Amazon EKS Pod 身分識別來提供憑證，而非使用 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。