Amazon EKS 近期推出了一項針對 Kubernetes 版本升級的回滾（Rollback）功能。簡單來說，如果工程團隊在升級 EKS 叢集版本後發現系統不穩定或出現 Bug，現在可以在升級後的 7 天內，將控制平面（Control Plane）恢復到之前的版本。
理解升級的痛點：單向門禁
對於維運工程師來說，升級 Kubernetes 控制平面一直被視為一個單向門禁（One-way Door），意指一旦執行升級且完成後，就無法簡單地原路返回。由於 Kubernetes 每年發布三個次要版本（Minor Version），對於管理數百個叢集的大型企業，尤其是受法規監管的環境，升級壓力極大。
如果升級後發生不可預期的故障，缺乏原生回滾機制會導致團隊陷入恐慌：要麼花費大量時間手動修復，要麼必須從備份重建整個叢集。這種風險導致許多團隊選擇延遲升級，進而錯過重要的安全性補丁，甚至導致叢集版本過舊而失去官方支援。
回滾功能的技術實作與範圍
這次 EKS 提供的回滾功能主要針對控制平面，包括 Kubernetes API Server 等核心元件。在執行回滾時，EKS 會保留所有的 etcd 資料（Kubernetes 的狀態儲存庫）、工作負載（Workloads）以及持久化磁碟（Persistent Volumes），確保資料不會因為版本回退而遺失。
針對不同模式的處理方式有所不同。對於使用 EKS Auto Mode（自動化管理模式）的叢集，EKS 會先自動處理工作節點（Worker Nodes）的回滾，隨後才恢復控制平面。此外，為了防止回滾的安全性，EKS 會先執行叢集分析（Cluster Insights），檢查是否存在節點版本不匹配或插件（Add-on）依賴問題。雖然可以使用強制指令跳過檢查，但建議遵循系統提示以確保穩定性。
回滾的限制與操作邏輯
這項功能並非萬能，它遵循與升級相同的漸進路徑，也就是一次只能回滾一個次要版本。此外，回滾的時間視窗被限制在升級後的 7 天內。
為了給予維運人員更多掌控權，AWS 同時推出了取消 API（Cancel API）。如果工程師發現節點回滾過程過慢，或者決定改變恢復策略，可以隨時中斷回滾程序，並透過調整中斷預算（Disruption Budgets）來加速或更改處理路徑。
為什麼這對工程實務很重要
在原生回滾功能出現之前，業界通常採取兩種昂貴的替代方案。第一種是藍綠部署（Blue/Green Deployment），即建立一個完全相同的新版本叢集，將流量切換過去，成功後才刪除舊叢集。這雖然安全，但在升級期間會導致基礎設施成本翻倍。第二種是依賴手動快照（Manual Snapshots），這不僅耗費人力，且在恢復後的資料一致性上缺乏保證。
原生回滾功能的加入，將升級過程從一次高風險的賭博，轉變為具有安全墊（Safety Net）的常態化操作。這能顯著縮短升級週期，讓團隊敢於更頻繁地更新版本，從而維持系統的安全性與效能。
目前該功能已在所有 EKS 可用區域上線，且不收取額外費用。控制平面回滾適用於所有 EKS 叢集，而節點回滾則僅限於 EKS Auto Mode 模式。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。