View a markdown version of this page

叢集版本復原的最佳實務 - Amazon EKS
了解共同責任模型如何套用至轉返以復原為考量來規劃升級在轉返之前檢閱轉返整備洞見準備非自動模式節點以進行復原管理復原的 Amazon EKS Auto Mode 中斷控制監控轉返進度將基礎設施處理為程式碼 (IaC) 受管叢集使用復原做為安全網路，而非例行工作流程回復可減少藍綠升級的需求相關資源

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

叢集版本復原的最佳實務

透過 Amazon Elastic Kubernetes Service (Amazon EKS) 版本復原，您可以在就地升級後 7 天內將叢集的 Kubernetes 控制平面還原至先前的次要版本。此頁面說明規劃、執行和操作復原作為升級工作流程一部分的最佳實務。

如需先決條件詳細資訊、step-by-step程序和 API 參考，請參閱將叢集轉返至先前的 Kubernetes 版本。

了解共同責任模型如何套用至轉返

當您啟動叢集版本轉返時，Amazon EKS 會管理轉返控制平面。您必須負責資料平面、附加元件和應用程式相容性。下列概述了責任：

  • Amazon EKS 管理：復原 Kubernetes API 伺服器和控制平面元件。對於自動模式叢集，Amazon EKS 也會管理轉返工作者節點。

  • 您負責：轉返受管節點群組、自我管理節點和混合節點。您也必須驗證附加元件相容性，並確保您的應用程式、自訂控制器和第三方工具能正確搭配舊版使用。

如需升級的共同責任模型的詳細資訊，請參閱了解共同責任模型如何套用至叢集升級。

以復原為考量來規劃升級

當您的升級工作流程設計為保持轉返視窗開啟時，版本轉返效果最佳。

  • 個別控制平面和資料平面升級 （非自動模式叢集）。對於使用受管節點群組或自我管理節點的叢集，請考慮先升級控制平面，並在升級工作者節點之前允許製作期間。當節點保持在 N-1 上時，kubelet 版本扭曲洞見會保持在 PASSING 狀態。這可讓復原路徑保持清除，而不需要先復原節點。

  • 將附加元件升級至跨相容版本。升級控制平面之前，請確保所有附加元件 （受管和自我管理） 都與目前和目標 Kubernetes 版本相容。這可讓升級和復原的附加元件相容性洞見保持清晰。

    • 使用 Amazon EKS 受管附加元件，從自動檢查附加元件版本相容性的復原整備洞察中獲益。

    • 避免自我管理受管附加元件 （例如，在 EKS 附加元件生命週期之外覆寫版本）。在復原期間，洞見會將受管附加元件組態視為事實來源，而不會偵測您引進的版本偏離。

  • 避免在製作期間使用版本特定的 APIs。如果您建立的資源使用 APIs 或僅在 7 天時段內新版本中可用的功能，則必須在轉返之前將其移除。限制採用new-version-only APIs，直到您確信升級穩定為止。

  • 升級較快，而不是較晚。提供轉返功能後，您可以放心地在新版本發行後立即升級，而不必等到延長的支援截止日期。稍早升級可讓您有更多時間來驗證和減少延長的支援費用。

  • 請注意延伸支援轉返限制。如果您的叢集在延伸支援結束時自動升級，則無法復原至先前的版本。如果您在標準支援結束時自動升級，您可以復原，但必須先將升級政策變更為 EXTENDED。

如需一般升級規劃指引，包括棄用政策、版本備註和附加元件相容性，請參閱叢集升級的最佳實務。

在轉返之前檢閱轉返整備洞見

Amazon EKS 會在叢集洞察中的 ROLLBACK_READINESS類別下顯示point-in-time復原準備度洞察。這些檢查是您評估復原安全性的主要工具。

  • 升級後立即檢閱洞見。請勿等到發生錯誤。升級之後，請檢查轉返整備洞見，以便了解目前的轉返狀態。

  • 主動處理錯誤洞見。如果洞見在升級後不久顯示 ERROR 狀態，請在 7 天時段仍開啟時提早解決。等待時間越長，叢集狀態差異和新封鎖程式出現的可能性就越高。

  • 了解哪些洞察可以和不涵蓋。Insights 會檢查 Amazon EKS 受管附加元件版本、API 用量、版本扭曲和叢集運作狀態。它們不會檢查自我管理的附加元件、自訂控制器或應用程式層級相容性。維護自我管理附加元件的相容性驗證 （例如，叢集自動擴展器、輸入控制器、自訂運算子、監控代理程式）。

如需洞見檢查和狀態行為的完整清單，請參閱將叢集轉返至先前的 Kubernetes 版本。

準備非自動模式節點以進行復原

對於使用受管節點群組、自我管理節點或 AWS Fargate 的叢集，您有責任確保工作者節點與目標轉返版本相容。

  • 受管節點群組。您必須先將受管節點群組復原至先前的版本，才能復原控制平面。將 UpdateNodegroupVersion操作與先前的 Kubernetes 版本搭配使用。轉返會遵守您設定的更新設定 (maxUnavailable、更新策略）。

  • 自我管理和混合節點。在轉返控制平面之前，更新您的節點 AMIs 或組態以使用先前的 Kubernetes 版本。

  • Fargate。Fargate 工作者節點不支援版本轉返。在啟動復原之前，刪除執行與控制平面相同版本的 Fargate Pod，或使用 --force繞過版本扭曲洞見 （這可能會導致意外行為，直到取代 Pod 為止）。

如需 PodDisruptionBudget 和拓撲分散組態指南，以確保節點更新期間的工作負載可用性，請參閱叢集升級的最佳實務。

管理復原的 Amazon EKS Auto Mode 中斷控制

對於執行 Amazon EKS Auto Mode 的叢集，節點復原階段可以是操作中最長的部分。您的中斷控制會直接判斷復原完成的速度。

  • 在開始轉返之前，請檢閱中斷預算。Amazon EKS 為 NodePool 中斷預算提供復原整備洞察。設為 0 的預算會觸發 ERROR 洞見，無限期地封鎖轉返。限制性預算和 PodDisruptionBudgets (PDBs) 會觸發警告洞察，這可能會減慢轉返速度，但允許轉返進度。在開始轉返之前解決錯誤洞察。

  • 準備好在轉返期間調整預算。如果回復時間超過預期，您可以在進行回復kubectl時調整 NodePool 中斷預算和 PDBs。增加預算允許更多並行節點替換。

  • 從封鎖節點中移除do-not-disrupt註釋。節點上的karpenter.sh/do-not-disrupt註釋會無限期地封鎖轉返。從應取代的節點中移除它。

  • 追蹤節點轉返進度。使用 kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide 來監控哪些節點已取代為舊版 AMI。

  • 如有需要，請使用 CancelUpdate。如果轉返花費的時間太長或造成的問題超過其解決次數，請取消轉返。取消之後，節點會收斂回目前版本，您可以採取不同的方法。

  • 設定適當的逾時。使用 中的 timeoutMinutes 參數rollbackConfig，以符合您的操作期望。預設值為 720 分鐘 (12 小時）。對於具有保守預算的叢集，請考慮增加預算。對於 IaC 受管叢集，請對齊工具的逾時。

如需完整的自動模式轉返程序和CancelUpdate操作，請參閱轉返 Amazon EKS 自動模式叢集。

監控轉返進度

在復原期間，請使用下列項目來追蹤狀態並偵測問題：

  • DescribeUpdate 操作。使用 describe-update 檢查轉返操作的目前狀態 (InProgress、Successful、Failed、Cancelled)。若要追蹤取消進度，請檢查回應中的cancellation物件。

  • 叢集洞察。Amazon EKS 會在繼續控制平面復原 （自動模式的節點復原完成後） 之前重新檢查洞見。監控可能已出現的新錯誤洞見。

  • 叢集狀態。對於自動模式叢集，叢集狀態會在節點復原ACTIVE期間保持，並UPDATING僅在控制平面復原期間變更為 。請勿僅倚賴叢集狀態來了解復原正在進行中，請使用 DescribeUpdate。

  • 節點版本。對於自動模式，請檢查節點 Kubernetes 版本以追蹤節點取代進度。針對受管節點群組，監控節點群組更新狀態。

將基礎設施處理為程式碼 (IaC) 受管叢集

基礎設施即程式碼 (IaC) 工具具有逾時限制，可能與自動模式轉返持續時間衝突。

  • AWS CloudFormation 支援每個資源最多 36 小時。如果轉返超過此值，CloudFormation 會將它視為無操作，這會讓叢集處於偏離狀態，其中範本不會反映實際的叢集版本。預設的回復逾時為 720 分鐘 (12 小時）。

  • Terraform Enterprise/Cloud 有大約 24 小時的逾時，但用戶端逾時會有所不同。

  • timeoutMinutes 與 IaC 工具的逾時保持一致，以防止 IaC 工具在 Amazon EKS 完成轉返之前逾時。

  • 考慮透過具有限制性預算的自動模式叢集的 CLI/API 啟動轉返，而不是透過 IaC。如果 IaC 層逾時，請CancelUpdate直接使用 。

  • AWS CloudFormation 堆疊復原不會觸發版本復原。如果 AWS CloudFormation 堆疊更新失敗，則自動堆疊還原至先前的範本版本不會啟動叢集版本復原。您必須明確啟動版本轉返。

使用復原做為安全網路，而非例行工作流程

版本復原旨在協助您從升級後的問題中復原。它最適合與現有的升級實務結合使用。

  • 轉返補充測試，不會取代它。繼續使用叢集洞察、在非生產環境中預先升級測試，以及階段推展。轉返處理測試無法捕捉的案例：僅出現在生產環境中的問題。

  • 回復可減少手動備份和快照程序做為主要安全機制的需求。使用原生轉返功能時，您不再需要僅倚賴已壓縮的快照或自訂轉返指令碼，以在升級期間進行災難復原。

  • 洞見是最佳努力和point-in-time。當您觸發轉返時，Amazon EKS 會對其進行評估。在該檢查之後所做的變更 （例如，使用新 APIs建立資源） 不會擷取，且可能會在復原完成後造成問題。

  • 回復不保證應用程式復原。Amazon EKS 會安全地還原控制平面，但您的應用程式、組態和相依性是您根據先前版本進行驗證的責任。

回復可減少藍綠升級的需求

先前主要使用藍綠叢集升級的組織現在可以考慮使用版本復原來就地升級。使用轉返進行就地升級可降低基礎設施成本 （沒有重複的叢集）、一致的叢集身分 （相同的 API 端點、OpenID Connect (OIDC) 提供者和彈性網路介面 (ENIs))，以及更簡單的操作。

當您需要一次變更多個版本、廣泛測試工作負載遷移，或在驗證期間維持完整的流量隔離時，仍可能偏好藍綠。如需詳細資訊，請參閱叢集升級最佳實務中的評估藍/綠叢集。