觀點 · 資訊分享
Amazon EKS 升級 Kubernetes 後反悔了？現在 7 天內可以退回上一個版本
AWS 的託管 Kubernetes 服務 EKS 新增「版本回退」：叢集升版後如果發現問題，7 天內可以把控制平面退回前一個次要版本，功能本身不另外收費。
- 發布
- 2026-07-02
- 篇幅
- 約 4 分鐘 · 1,793 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：Amazon EKS 現在可以在升級後 7 天內，把 Kubernetes 叢集退回前一個版本，升級終於有了後悔藥。
先用白話講：升級後悔了怎麼辦？
想像你把手機系統更新到新版，結果常用的 App 全部當機。如果系統提供「一鍵退回舊版」，你會安心很多；如果沒有，你只能硬著頭皮等 App 作者修。
Kubernetes（簡稱 K8s）是專門管理一大堆容器的系統，而 Amazon EKS 是 AWS 幫你代管 K8s 的服務。K8s 會定期推出新的次要版本，叢集得跟著升級。但升級之後才發現舊程式用的功能不相容，以前就只能往前修。
這次 AWS 補上了這張安全網：升級完成後 7 天內，可以把叢集退回上一個次要版本。
發生什麼事
AWS 在 2026 年 7 月 1 日的 What’s New 宣布，EKS 支援 Kubernetes 版本回退：
- 升級後 7 天內，可以退回前一個次要版本
- 可以用 EKS 主控台、AWS CLI 或 AWS SDK 操作
- 退之前，EKS 會先跑一輪「回退準備度」檢查：API 相容性、版本差距、附加元件相容性、叢集健康狀態等
- 如果叢集使用 EKS Auto Mode，EKS 會先自動把工作節點退回去，再退控制平面，而且會遵守你設定的中斷限制
- 所有提供 EKS 的 AWS 區域都能用，不另外收費
哪些會退、哪些不會退？
依 EKS 使用者指南（整理時的現況頁面）：
| 項目 | 會不會自動退 |
|---|---|
| Kubernetes API 伺服器與控制平面 | 會 |
| etcd 資料、你的 Pod 與服務、儲存卷 | 不動，原樣保留 |
| EKS 附加元件（Add-on） | 不會，要自己處理 |
| 受管節點群組 | 不會，要自己呼叫 UpdateNodegroupVersion 退 |
| 自管節點、混合節點 | 不會，要自己處理 |
| Auto Mode 節點 | 會，先退節點再退控制平面 |
給開發者的技術細節
條件有幾個要記：
- 叢集必須是「原地升級」到目前版本的，直接用新版本建立的叢集不能退
- 只能退一個次要版本。例如從 1.31 升到 1.32 再升到 1.33，只能退到 1.32，不能直接退到 1.31
- 叢集狀態要是 ACTIVE，而且沒有其他更新在進行
- 退回到延長支援的版本，要先把升級策略改成 EXTENDED
指令就是原本的更新版本指令，帶上前一個版本號：
aws eks update-cluster-version \
--name my-cluster \
--kubernetes-version 1.30
如果回退準備度檢查出現 ERROR，可以加 --force 略過檢查，但官方明講這樣無法保證安全，而且 7 天期限、只退一版這些前提條件不能靠 --force 繞過。Fargate 的 Pod 不支援回退，要先刪掉跟控制平面同版本的 Fargate Pod 再退。
另外要留意，官方提到從標準支援的版本退回到延長支援的版本，會重新開始計算延長支援費用。
我的看法
我接的案子大多是中小企業的網站與系統，多數還沒到需要 Kubernetes 的規模，用 Docker 搭配單機或 NAS 就夠了。但真的用到 EKS 的團隊，這個功能很實用：升級最怕的不是失敗，而是「升級成功、卻在上線第三天才發現某個元件不相容」。有 7 天的緩衝，等於多了一段可以在真實流量下驗證的時間。
不過別把它當成萬能。控制平面能退，但附加元件和節點還是要自己顧，所以升級前就該先想好「萬一要退，節點版本怎麼跟著退」，並用準備度檢查提早找出會卡住的地方。
名詞小辭典
- Kubernetes（K8s）：管理大量容器的開源系統，負責決定程式跑在哪台機器、掛了怎麼重啟。
- 控制平面（Control Plane）：K8s 的大腦，負責接收指令、安排工作；EKS 由 AWS 代管這一塊。
- 次要版本（Minor Version）：版本號中間那一段，例如 1.32 到 1.33 就是升了一個次要版本。
- 附加元件（Add-on）：裝在叢集裡的輔助功能，例如網路外掛。