**協助改進此頁面** 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 將叢集轉返至先前的 Kubernetes 版本 透過 Amazon EKS 版本復原，您可以在執行就地升級後將叢集的 Kubernetes 控制平面還原至先前的次要版本。如果您在升級後遇到問題，例如應用程式不相容、已棄用 API 使用或意外行為，您可以轉返以將叢集還原為已知的良好狀態。 在轉返期間，Amazon EKS 會將 Kubernetes API 伺服器和控制平面元件還原至先前的版本，同時保留所有刻印資料、客戶工作負載和持久性磁碟區。 ## 復原的內容 + Kubernetes API 伺服器版本 + 控制平面元件及其組態 + 平台版本 （還原至舊版 Kubernetes 的最新平台版本） + **EKS Auto Mode 工作者節點**。對於執行 EKS Auto Mode 的叢集，EKS 會在還原控制平面之前自動管理自動模式工作者節點的復原。如需詳細資訊，請參閱[回復 EKS Auto Mode 叢集](rollback-automode.md)。 ## 不會復原的內容 + **等式資料**。所有叢集狀態、資源和組態都會保留。 + **客戶工作負載**。您的 Pod、部署和服務會繼續執行。 + **EKS 附加元件**。附加元件版本保持不變。您可以分別管理這些項目。 + **持久性磁碟區和資料**。所有客戶資料保持不變。 + **自我管理節點和混合節點**。您要負責轉返這些項目。 + **受管節點群組**。您必須使用 UpdateNodegroupVersion API 分別復原這些項目。 ## 先決條件 在您可以復原叢集之前，必須符合下列所有條件： | 需求 | 詳細資訊 | | --- | --- | | **7 天時段** | 必須在升級完成後的 7 天內啟動轉返。7 天後，將無法再轉返。 | | **升級的叢集** | 叢集必須透過就地升級升級至其目前版本。在目前版本建立的叢集無法復原。 | | **僅限單一版本** | 您只能由一個次要版本 (N 轉 N-1) 轉返。如果您從 1.31 升級到 1.32，然後升級到 1.33，您只能轉返到 1.32，不能轉返到 1.31。 | | **支援的版本** | 目前[支援的 EKS 版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar)可使用版本轉返。 | | **延伸支援政策** | 若要轉返至延伸支援的版本，您必須先將叢集的升級政策變更為 `EXTENDED`。 | | **沒有end-of-extended-support自動升級** | 如果您的叢集在延伸支援結束時自動升級，則無法復原至先前的版本。如果您的叢集在標準支援結束時自動升級，您可以復原，但必須先將升級政策變更為 `EXTENDED`。 | | **叢集狀態** | 叢集必須處於 `ACTIVE` 狀態。當另一個更新正在進行時，您無法啟動轉返。 | | **EKS 功能相容性** | 如果舊版不支援在叢集上啟用的 EKS 功能，則轉返請求會失敗。無法使用 略過此檢查`--force`。 | 除了上述要求之外，某些條件即使有 `--force`旗標，也無法復原。這些包括：叢集是在目前版本建立的，自升級以來已超過 7 天，叢集已再次升級至較新的版本，或在目前版本界限中啟用回溯不相容的 EKS 功能。 ## 摘要 Amazon EKS 叢集復原程序的高階摘要如下： 1. 檢閱復原整備洞察，以識別可能影響復原的任何問題。 1. 解決任何封鎖問題 (ERROR 狀態洞察），或使用 `--force`繞過洞察檢查。 1. 確認您的應用程式、自訂控制器和第三方工具與先前的 Kubernetes 版本相容。 1. 如果您的工作者節點執行與控制平面相同的 Kubernetes 版本，請先復原工作者節點。 1. 如果您有執行版本與先前 Kubernetes 版本不相容的附加元件，請將其降級為相容的版本。 1. 啟動控制平面轉返。 1. 監控轉返進度。 **重要** 對於執行 EKS Auto Mode 的叢集，會自動處理步驟 4。當您啟動轉返時，EKS 會在控制平面之前轉返自動模式節點。如需詳細資訊，請參閱[回復 EKS Auto Mode 叢集](rollback-automode.md)。 ## 步驟 1：檢閱轉返整備洞見 Amazon EKS 會根據一組point-in-time復原準備度檢查自動評估您的叢集，並透過 `ROLLBACK_READINESS`類別下的叢集洞見顯示任何問題。這些洞見會在您執行升級後顯示，並在 7 天復原資格時段期間保持可用。 ### 檢視回復整備洞察 ** AWS 主控台：** 1. 開啟 Amazon EKS 主控台。 1. 選取您的叢集。 1. 導覽至**升級洞見**索引標籤。升級後，復原整備洞見會顯示在此處。 1. 檢閱任何具有 ERROR 或 WARNING 狀態的洞見。 ** AWS CLI：** ``` aws eks list-insights \ --cluster-name my-cluster \ --region us-west-2 \ --filter '{"categories": ["ROLLBACK_READINESS"]}' ``` 若要取得特定洞見的詳細資訊： ``` aws eks describe-insight \ --cluster-name my-cluster \ --region us-west-2 \ --id ``` ### 重新整理洞見 EKS 每 24 小時重新整理一次洞見。您可以在使用 Amazon EKS 主控台中的重新整理按鈕或使用 CLI 解決問題後手動觸發**重新整理**： ``` aws eks start-insights-refresh \ --cluster-name my-cluster \ --region us-west-2 ``` **注意** 當您啟動轉返時，EKS 會自動重新整理洞見，以確保針對最新的叢集狀態執行檢查。 ### Insight 狀態行為 | 狀態 | 意義 | 對轉返的影響 | | --- | --- | --- | | **傳遞** | 此檢查未偵測到問題 | 允許轉返 | | **WARNING** | 偵測到潛在問題，未封鎖 | 允許轉返 （僅限諮詢） | | **ERROR (錯誤)** | 偵測到封鎖問題 | 已封鎖轉返直到解決，或使用 `--force`繞過 | | **UNKNOWN** (不明) | 無法判斷狀態 | 已封鎖轉返直到解決，或使用 `--force`繞過 | 具有 **ERROR** 或 **UNKNOWN** 狀態的洞見會封鎖復原。具有 PASSING 或 WARNING 狀態的洞見不會阻止您復原。 ### 轉返準備度檢查 Amazon EKS 會執行一組檢查，做為復原整備洞察的一部分。這些檢查會評估 API 用量相容性 （包括欄位層級變更偵測）、叢集運作狀態、kubelet 版本偏斜、kube-proxy 版本偏斜，以及附加版本相容性。對於執行 EKS Auto Mode 的叢集，其他檢查會評估 NodePool 中斷預算、do-not-disrupt註釋和 PodDisruptionBudget 組態。 ### 使用 --force 旗標 如果復原整備洞察顯示錯誤狀態，而且您想要繼續而不解決問題，您可以使用 `--force`旗標略過所有洞察檢查： ``` aws eks update-cluster-version \ --name my-cluster \ --kubernetes-version 1.30 \ --force \ --region us-west-2 ``` **警告** 使用 會`--force`略過所有洞見檢查 (ERROR、WARNING、UNKNOWN)，並直接進行復原。略過洞見檢查時，EKS 無法保證復原的安全性。您對出現的任何問題承擔全部責任。 `--force` 旗標只會略過洞見檢查。它不會略過先決條件驗證，例如 7 天時段、建立版本檢查或循序轉返檢查。對於自動模式叢集， `--force` 不會覆寫中斷控制。NodePool 中斷預算、PDBs和do-not-disrupt註釋仍然被接受。 ## 步驟 2：準備工作者節點 在復原控制平面之前，請確定您的工作者節點與目標版本相容。Kubernetes 版本扭曲政策要求工作者節點無法執行比控制平面更新的版本。 ### EKS 自動模式 不需要採取行動。當您啟動轉返時，EKS 會在控制平面之前自動轉返自動模式節點。如需詳細資訊，請參閱[回復 EKS Auto Mode 叢集](rollback-automode.md)。 ### 受管節點群組 (MNG) 您必須先將受管節點群組復原至先前的版本，才能復原控制平面。使用 `UpdateNodegroupVersion` API： ``` aws eks update-nodegroup-version \ --cluster-name my-cluster \ --nodegroup-name my-nodegroup \ --kubernetes-version 1.30 \ --region us-west-2 ``` 節點群組更新遵守您設定的更新設定 (`maxUnavailable` 或 `maxUnavailablePercentage`) 和更新策略 （滾動或強制）。 ### 自我管理節點和混合節點 您負責復原自我管理節點和混合節點。在轉返控制平面之前，更新您的節點 AMIs 或組態以使用先前的 Kubernetes 版本。 ### Fargate Fargate 工作者節點不支援版本轉返。您可以復原使用 Fargate 之叢集的控制平面，但執行與控制平面相同 Kubernetes 版本的 Fargate Pod 會觸發具有 ERROR 狀態的 kubelet 版本扭曲洞見。 EKS 無法自動將 Fargate Pod 復原至較舊的 kubelet 版本。 **解決方法：**如果您的 Fargate Pod 執行與控制平面相同的 Kubernetes 版本，請在啟動復原之前刪除這些 Pod。然後復原您的控制平面。當您重新部署時，任何剩餘的 Pod 都會使用復原版本啟動。 或者，使用 `--force` 略過洞見檢查。不過，繼續進行 kubelet 版本扭曲違規可能會導致 Fargate 工作負載發生意外行為，直到這些 Pod 被取代為止。 ## 步驟 3：轉返叢集控制平面 您可以使用 AWS 主控台、 AWS CLI 或 EKS API 啟動轉返。 ### 使用 AWS 主控台轉返叢集 1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。 1. 選取您的叢集。 1. 選擇**動作**下拉式清單。 1. 選擇**轉返叢集版本**。 1. 檢閱復原摘要，包括任何洞見警告。 1. 選擇**轉返版本**。 復原需要幾分鐘的時間才能完成。對於自動模式叢集，節點復原階段可能需要更長的時間。如需詳細資訊，請參閱[回復 EKS Auto Mode 叢集](rollback-automode.md)。 ### 使用 CLI AWS 轉返叢集 使用現有`update-cluster-version`命令搭配先前的 (N-1) Kubernetes 版本： ``` aws eks update-cluster-version \ --name my-cluster \ --kubernetes-version 1.30 \ --region us-west-2 ``` 回應範例： ``` { "update": { "id": "e4091a28-ea14-48fd-a8c7-975aeb469e8a", "status": "InProgress", "type": "VersionRollback", "params": [ { "type": "Version", "value": "1.30" }, { "type": "PlatformVersion", "value": "eks.16" } ], "createdAt": "2026-05-12T16:56:01.082000-04:00", "errors": [] } } ``` **注意** 如果洞見資料過時，EKS 會在執行轉返之前執行洞見重新整理。 ## 步驟 4：監控轉返進度 您可以使用 Amazon EKS 主控台或 AWS CLI 監控叢集轉返的狀態。 ** AWS CLI：** ``` aws eks describe-update \ --name my-cluster \ --region us-west-2 \ --update-id e4091a28-ea14-48fd-a8c7-975aeb469e8a ``` ** AWS 主控台：** 1. 開啟 Amazon EKS 主控台。 1. 選取您的叢集。 1. 導覽至**更新歷史記錄**索引標籤。 1. 找到與復原相關聯的更新 ID，以檢視其目前狀態。 ### 狀態轉換 對於標準叢集 （無自動模式）： ``` InProgress → Successful InProgress → Failed ``` 對於自動模式叢集，叢集狀態會在節點復原`ACTIVE`時保持，並且`UPDATING`只有在控制平面復原開始時才會變更為 。使用 `describe-update` 追蹤整體轉返進度。如需詳細資訊，請參閱[回復 EKS Auto Mode 叢集](rollback-automode.md)。 顯示`Successful`狀態時，復原即完成。 ## 考量事項和警告 ### 洞見是最佳努力和point-in-time 叢集洞察會在觸發轉返時進行評估。如果您在檢查洞見之後但在復原完成之前對叢集進行變更 （例如，使用新 APIs建立資源），這些變更不會由初始洞見檢查擷取，而且可能會在復原完成之後造成問題。 ### 等式資料保留 EKS 會在轉返期間保留已刪除的資料。使用 `--force`旗標略過的不相容資源會保留，不會收集垃圾。 ### 延長支援費用 如果您從標準支援下的版本轉返至延伸支援下的版本，您的叢集會開始產生延伸支援費用。例如，如果您從 1.30 （延伸支援） 升級至 1.31 （標準支援），然後復原至 1.30，則延伸支援費用會繼續。 ### 復原的共同責任模型 EKS 會將 Kubernetes 控制平面復原至所需的版本。作為共同責任模型的一部分，您有責任驗證應用程式與先前版本的相容性： + EKS 負責安全地還原控制平面元件。 + 您有責任確保您的應用程式、組態和相依性與舊版相容。 + 您必須檢閱版本之間的任何不相容、評估叢集是否公開，以及緩解任何問題。 ### CloudFormation 堆疊復原行為 如果 CloudFormation 堆疊更新失敗並觸發堆疊復原，則還原至指定較低 Kubernetes 版本的先前範本版本不會觸發叢集版本復原。必須透過 UpdateClusterVersion API、CLI 或主控台明確啟動版本轉返。 ## 轉返和附加元件 在叢集版本復原期間，EKS 不會自動復原附加元件版本。您必須分別管理附加元件版本。 在轉返控制平面之前： 1. 使用復原整備洞察，檢查附加元件與目標版本的相容性。 1. 如果附加元件版本與先前的 Kubernetes 版本不相容，請先降級： ``` aws eks update-addon \ --cluster-name my-cluster \ --addon-name vpc-cni \ --addon-version v1.12.0-eksbuild.2 \ --region us-west-2 ``` \+ 。 控制平面復原完成後，請確認所有附加元件都正常運作。 **注意** 回復整備洞見只會檢查 EKS 受管附加元件版本。對於自我管理的附加元件，您有責任在復原之前驗證與目標版本的相容性。 ## 相關資源 + [回復 EKS Auto Mode 叢集](rollback-automode.md) + [將現有叢集更新至全新 Kubernetes 版本](update-cluster.md) + [利用叢集洞見為 Kubernetes 版本升級做好準備，並為錯誤組態進行故障診斷](cluster-insights.md) + [了解 EKS 上的 Kubernetes 版本生命週期](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) + [更新受管節點群組](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html) + [叢集升級的最佳實務](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)