跳至內容
使用 AWS re:Post 即表示您同意 AWS re:Post 使用條款
AWS re:Postre:Post
關於 re:Post

如何規劃 Amazon EKS 叢集的升級？

3 分的閱讀內容
0

我希望在升級 Amazon Elastic Kubernetes Service (Amazon EKS) 叢集時遵循最佳實務。

解決方法

了解升級的效果

Kubernetes 的新版本可能會為您的 Amazon EKS 叢集帶來重大變化。升級叢集後，您無法降級叢集。

如果您升級到較新的 Kubernetes 版本，則不需要執行就地叢集升級。而是可以遷移到新的叢集。如果您遷移到新的叢集，那麼最佳實務是使用叢集備份和還原工具，例如 Velero。如需詳細資訊，請參閱 GitHub 網站上的 Velero。

如需了解目前及先前版本的 Kubernetes，請參閱 Amazon EKS Kubernetes 發行行事曆。

滿足升級要求

若要升級叢集，您必須滿足以下要求：

查看 Amazon EKS 和 Kubernetes 的主要更新

請執行下列動作：

  • 查看升級版本的所有記錄的變更，然後記下所需的升級步驟。
  • 查看針對 Amazon EKS 受管叢集所特定的要求或程序。

有關 Amazon EKS 叢集平台版本和 Kubernetes 版本重大更新的資訊，請參閱以下文件：

有關 Kubernetes 上游版本和主要更新的資訊，請參閱以下文件：

了解並檢查已停用的 API

當 Kubernetes 升級 API 時，Kubernetes 也會移除先前的 API。

若要管理已停用的 API，請執行下列操作：

  • 若要了解 Kubernetes 如何在較新版本的 Kubernetes 中停用 API，請參閱 Kubernetes 網站上的 Kubernetes 棄用政策。
  • 若要檢查叢集中已停用的 API 版本，請使用 Kube No Trouble (kubent) 工具。如需詳細資訊，請參閱 GitHub 網站上的 kube-no-trouble。如果您使用已停用的 API 版本，請在升級 Kubernetes 叢集之前，升級您的工作負載。
  • 若要在不同的 API 版本之間轉換 Kubernetes 資訊清單檔案，請使用 kubectl convert 外掛程式。如需詳細資訊，請參閱 Kubernetes 網站上的安裝 kubectl convert 外掛程式。

了解 Kubernetes 升級時預期會發生什麼事

如果您升級叢集，則 Amazon EKS 將使用升級後的 Kubernetes 版本啟動新的 API 伺服器節點，以取代現有節點。Amazon EKS 也會執行一系列內部檢查。如果檢查失敗，Amazon EKS 將會回復基礎架構部署，而您的叢集保持在舊版 Kubernetes 上。回復不會影響正在執行的應用程式，並且您可以恢復叢集。

**注意：**在升級過程中，您可能會遇到輕微的服務中斷。

升級控制平面和資料平面

若要升級叢集，您必須更新控制平面和資料平面。

若要更新平面，請選擇以下其中一個方法：

  • 就地叢集升級
  • 藍/綠或 Canary 升級
  • 受管節點群組升級

就地叢集升級

**重要：**對於就地升級，您只能升級到 Kubernetes 的下一個最新次要版本。如果您的目前叢集版本和目標版本之間存在多個版本，則必須依序升級至每個版本。

對於每個就地 Kubernetes 叢集升級，請完成以下步驟：

  1. 更新 Kubernetes 資訊清單和已停用的 API。
  2. 升級叢集控制平面。
  3. 升級叢集中的節點。
  4. 更新您的 Kubernetes 附加元件和自訂控制器。

如需詳細資訊，請參閱使用 Amazon EKS 規劃 Kubernetes 升級中的在 Amazon EKS 中規劃和執行 Kubernetes 版本升級一節。另請參閱叢集升級的最佳實務。

藍綠色升級或 Canary 升級

若要完成藍綠或 Canary 升級，請參閱對無狀態 ArgoCD 工作負載的藍綠或 Canary Amazon EKS 叢集遷移。

受管節點群組升級

**重要：**節點的 kubelet 不能晚於 kube-apiserver。另外，kubelet 的版本也不能比 kube-apiserver 落後超過兩個次要版本。例如，如果 kube-apiserver 為 1.24 版本，則 Amazon EKS 僅支援 1.24、1.23 和 1.22 版本的 kubelet。

若要升級受管節點群組，請更新受管節點群組中的節點。

遷移到 Amazon EKS 受管節點群組

如果您使用自我管理的節點群組，則可以將工作負載遷移到 Amazon EKS 受管節點群組，且無需停機。

識別並升級下游相依性

叢集可以包含第三方附加元件和工具，例如輸入控制器、連續交付系統、監控工具和其他工作流程。如果您更新叢集，那麼您還必須更新附加元件和第三方工具。確保您了解附加元件如何與您的叢集協同工作，以及如何更新附加元件。

**注意：**最佳實務是使用受管附加元件，而不是自我管理附加元件。

查看以下常見附加元件和升級文件的範例：

升級 Fargate 節點

若要更新 AWS Fargate 節點，請完成以下步驟：

  1. 刪除您的節點所代表的 Pod。
  2. 更新您的控制平面。
  3. 重新部署 Pod。

您現在在 Fargate 上啟動的新 Pod，其 kubelet 版本將與您的叢集版本相符。您的升級不會影響現有的 Fargate Pod。

**注意：**Amazon EKS 必須定期修補 Fargate Pod，以確保這些 Pod 的安全。在更新 Pod 時，Amazon EKS 會盡量將修補作業的影響降到最低。如果 Amazon EKS 無法移除 Pod，則 Amazon EKS 會刪除 Pod。如需將中斷降到最低，請參閱為 AWS Fargate 作業系統修補事件設定動。

升級由 Karpenter 建立的非受管節點

您為 ttlSecondsUntilExpired 設定的值會啟動節點過期機制。當節點達到指定的時間 (以秒為單位) 後，Amazon EKS 將刪除該節點。即使 Amazon EKS 工作負載或應用程式正在使用這些節點，仍會進行刪除。使用 ttlSecondsUntilExpired 將節點替換為新佈建的執行個體，讓您可以升級執行個體。Karpenter 使用最新的 Amazon EKS 最佳化 Amazon Machine Image (AMI) 來取代節點。如需進一步了解 Karpenter 如何中斷節點，請參閱 Karpenter 網站上的中斷。

下列範例顯示了使用 ttlSecondsUntilExpired 取消佈建的節點，然後取代為升級的執行個體：

apiVersion: karpenter.sh/v1alpha5kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type         # optional, set to on-demand by default, spot if both are listed
      operator: In
      values: ["spot"]
  limits:
    resources:
      cpu: 1000                               # optional, recommended to limit total provisioned CPUs
      memory: 1000Gi
  ttlSecondsAfterEmpty: 30                    # optional, but never scales down if not set
  ttlSecondsUntilExpired: 2592000             # optional, nodes are recycled after 30 days but never expires if not set
  provider:
        subnetSelector:
      karpenter.sh/discovery/CLUSTER_NAME: '*'
    securityGroupSelector:
      kubernetes.io/cluster/CLUSTER_NAME: '*'

**注意：**Karpenter 不會自動為 ttlSecondsUntilExpired 值加入抖動。如果您在短時間內建立多個執行個體，則這些執行個體將同時到期。為了防止過多的工作負載中斷，請設定 Pod 中斷預算。如需詳細資訊，請參閱 Kubernetes 網站上的為應用程式指定中斷預算。

主題
Containers
標籤
Amazon Elastic Kubernetes Service
語言
中文 (繁體)
AWS 官方已更新 6 個月前
沒有評論

相關內容