使用 AWS re:Post 即表示您同意 AWS re:Post 使用條款
AWS re:Postre:Post

如何為 Amazon EKS 叢集規劃升級策略？

3 分的閱讀內容
0

當我升級 Amazon Elastic Kubernetes Service (Amazon EKS) 叢集時，我想遵循最佳實務。

簡短描述

新的 Kubernetes 版本為 Amazon EKS 叢集引入了重大的變更。升級叢集之後，您無法降級叢集。升級至較新的 Kubernetes 版本時，您可以遷移到新的叢集，而不執行就地叢集升級。如果選擇遷移到新的叢集，則諸如 VMware 的 Velero 等叢集備份和還原工具可以幫助您遷移。如需詳細資訊，請參閱 GitHub 網站上的 Velero。

若要查看可用於 Amazon EKS 的 Kubernetes 的目前及過去版本，請參閱 Amazon EKS Kubernetes 版本行事曆。

解決方法

準備升級

在開始叢集升級之前，請注意下列要求：

檢閱 Amazon EKS 和 Kubernetes 的主要更新

檢閱所有記錄的升級版本變更，並記下所有必要的升級步驟。此外，請記下 Amazon EKS 受管叢集特定的任何要求或程序。

如需 Amazon EKS 叢集平台版本和 Kubernetes 版本的任何主要更新，請參閱下列資源：

如需 Kubernetes 上游版本和主要更新的詳細資訊，請參閱下列文件：

了解 Kubernetes 停用政策

升級 API 時，舊版 API 會被停用並最終移除。若要瞭解如何在較新版本的 Kubernetes 中停用 API，請閱讀 Kubernetes 網站上的停用政策。

若要檢查您是否在叢集中使用停用的 API 版本，請使用 GitHub 網站上的 Kube No Trouble (kubent)。如果您使用已停用的 API 版本，請在升級 Kubernetes 叢集之前升級工作負載。

若要在不同的 API 版本之間轉換 Kubernetes 資訊清單檔案，請使用 kubectl convert 外掛程式。如需詳細資訊，請參閱 Kubernetes 網站上的安裝 kubectl convert 外掛程式。

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

當您升級叢集時，Amazon EKS 會啟動升級 Kubernetes 版本的新 API 伺服器節點，以取代現有節點。如果這些檢查中的任何一項失敗，Amazon EKS 將會回復基礎架構部署，而您的叢集保持在舊版 Kubernetes 上。但是，此回復不影響任何正在執行的應用程式，您可以根據需要復原任何叢集。在升級過程中，您可能會遇到輕微的服務中斷。

升級控制平面和資料平面

若要升級 Amazon EKS 叢集，您必須更新兩個主要元件：控制平面和資料平面。升級這些元件時，請記住以下考量事項。

就地 Amazon EKS 叢集升級

對於就地升級，只能升級到下一個最高的 Kubernetes 次要版本。如果您目前的叢集版本和目標版本之間有多個版本，則必須依序升級到每個版本。對於每個就地 Kubernetes 叢集升級，請完成下列工作：

  • 視需要更新您的 Kubernetes 資訊清單，並更新已停用或移除的 API。
  • 升級叢集控制平面。
  • 升級叢集中的節點。
  • 視需要更新 Kubernetes 附加元件和自訂控制器。

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

藍/綠或 Canary Amazon EKS 叢集遷移

藍/綠或 Canary 升級策略可能更複雜，但是該策略允許升級具有容易回復能力，而且沒有停機時間。針對藍/綠或 Canary 升級，請參閱無狀態 ArgoCD 工作負載的藍/綠或 Canary Amazon EKS 叢集遷移。

升級 Amazon EKS 受管的節點群組

**重要：**節點的 kubelet 不能比 kube-apiserver 更新。也不能比 kube-apiserver 早兩個以上的次要版本。例如，假設 kube-apiserver 的版本為 1.24。在這種情況下，僅 1.24、1.23 和 1.22 版本支援 kubelet。

若要完全升級您的受管節點群組，請完成下列步驟：

  1. 將 Amazon EKS 叢集控制平面元件升級至最新版本。
  2. 更新受管節點群組中的節點。

遷移至 Amazon EKS 受管的節點群組

如果您使用自我管理的節點群組，則可以將工作負載遷移至 Amazon EKS 受管的節點群組，且沒有停機時間。如需詳細資訊，請參閱將工作負載從 EKS 自我管理節點群組無縫遷移到 EKS 受管的節點群組。

識別和升級下游相依項 (附加元件)

叢集通常包含外部產品，例如輸入控制器、連續交付系統、監控工具和其他工作流程。更新 Amazon EKS 叢集時，您還必須更新附加元件和第三方工具。確保您了解附加元件如何與您的叢集搭配使用以及如何更新它們。

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

檢閱下列常用附加元件範例和相關升級文件：

升級 AWS Fargate 節點

若要更新 Fargate 節點，請刪除該節點代表的 Pod。然後，在更新控制平面之後，重新部署該 Pod。您在 Fargate 上啟動的任何新 Pod 都具有與您的叢集版本相符的 kubelet 版本。現有的 Fargate Pod 不變。

**注意：**為確保 Fargate Pod 安全，Amazon EKS 必須定期修補它們。Amazon EKS 嘗試以減少其效果的方式更新 Pod。但是，如果 Pod 無法成功移出，Amazon EKS 就會刪除它們。若要將中斷降至最低，請參閱 Fargate OS 修補。

升級 Karpenter 建立的無群組節點

為 ttlSecondsUntilExpired 設定值時，此值會啟動節點到期日。在節點達到定義的時間 (以秒為單位) 之後，Amazon EKS 會刪除它們。即使節點正在使用中，也會刪除。此處理程序可讓您以新佈建的執行個體取代節點，因此升級它們。取代節點時，Karpenter 會使用最新的 Amazon EKS 最佳化 AMI。如需詳細資訊，請參閱 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 不會自動為此值加入抖動。如果您在短時間內建立多個執行個體，這些執行個體將會在相同時間到期。為防止過度的工作負載中斷，請定義 Pod 中斷預算。如需詳細資訊，請參閱 Kubernetes 網站上的為應用程式指定中斷預算。

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

相關內容