從 Amazon Linux 2 升級到 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 採用了下一代統一控制組層次結構 (cgroupv2)。cgroupv2 用於實現容器執行時期，並由 systemd 執行。雖然 AL2023 仍然包含可以讓系統使用 cgroupv1 運行的程式碼，但這不是建議建議組態或受支援組態。此組態將在未來的 Amazon Linux 主要版本中完全移除。

eksctl 需要 eksctl 版本 0.176.0 或以上才能支援 AL2023。

若您對受管節點群組使用自訂 AMI，可透過交換啟動範本中的 AMI ID 來執行就地升級。在執行此升級策略前，您應確保應用程式和任何使用者資料都能移轉到 AL2023。

如果您使用帶有標準啟動範本或未指定 AMI ID 的自訂啟動範本的受管節點群組，則需要使用藍綠策略進行升級。藍綠升級通常更複雜，涉及建立一個全新的節點群組，並在其中指定 AL2023 作為 AMI 類型。然後需要仔細設定新的節點群組，以確保來自 AL2 節點群組的所有自訂資料都與新的作業系統相容。一旦新的節點群組經過您的應用程式測試和驗證，Pod 可以從舊節點群組移轉到新節點群組。移轉完成後，您可刪除舊的節點群組。