5 個 GKE 支援重點

這篇整理 5 個 GKE 支援重點，幫你判斷版本何時到期、升級要多早準備，還有哪種管理方式最省事。

If you manage GKE clusters, these five facts help you read the support schedule, spot upgrade deadlines, and avoid surprises. 例如 1.35 的 active support 到 2027-02-28，這就是你排程的起點。

1. GKE 有兩種操作模式

Google Kubernetes Engine 分成 Standard 與 Autopilot，差別不只在介面，而是誰負責底層維運。Standard 讓你掌握節點與基礎設施，Autopilot 則把節點管理交給 Google。

• Standard：你可管理節點與 node pool。
• Autopilot：節點會自動升級到 control plane 對應版本。
• 兩種模式下，control plane 升級都不能關閉。

這代表「代管」不等於完全不用管。只要你的工作負載對相容性敏感，就還是要先看版本計畫。

2. Release channel 會決定升級節奏

GKE 提供 Rapid、Regular、Stable 三種 release channel。Regular 是預設值，三者都屬於正式可用。只要把叢集加入 channel，GKE 就會替你安排版本與節奏。

• Rapid：最快拿到新版本。
• Regular：多數叢集的平衡選擇。
• Stable：節奏較慢，適合想多觀察一段時間的團隊。

重點是，channel 會改變你何時升級，但不會改變版本的支援截止日。支援時鐘還是照版本走。

3. 每個 minor version 只有 14 個月支援

GKE 對每個 Kubernetes minor version 提供總共 14 個月支援，這是排程時最重要的數字。只要版本進入 Regular channel，支援窗口就開始倒數。

例如 1.35 的 active support 到 2027-02-28，1.34 則到 2026-08-30。若你只落後一個 minor version，通常已經在升級期限內。

4. Version skew 只允許落後兩個 minor version

GKE 採用 Kubernetes version skew policy，node 與 node pool 最多只能比 control plane 落後兩個 minor version。這給你一點緩衝，但空間不大。

• control plane 可以先升，node 再跟上。
• 落後超過兩個 minor version 就超出政策。
• 就算是 Static cluster，也還是要用受支援版本。

對常延後維護的團隊來說，這條規則最容易踩線。叢集可能還能跑，但很快就會掉出支援範圍。

5. Static cluster 代表升級責任在你

No Channel，也就是 Static，表示叢集沒有加入 release channel。這種情況下，你要自己規劃升級節奏，雖然 Google 在某些安全或相容性情境下仍可能處理節點更新。

• No Channel 不會有 channel 的自動節奏。
• 你仍然必須維持在受支援的 GKE 版本。
• 安全公告會和 release 資訊一起發布。

如果你要的是完全掌控排程，Static 很適合；如果你想少管維運，通常還是 channel 方案比較省事。

怎麼挑

想把節點維運交給平台，就選 Autopilot。需要更多基礎設施控制、或有自訂節點需求，就選 Standard。若你最在意升級節奏，先選 release channel，再依風險偏好決定 Rapid、Regular 或 Stable。

如果你用的是 No Channel，請把版本到期日當成自己的責任。最安全的做法，是盯住 14 個月 minor-version 窗口、提早看 active support 結束日，並在 version skew 變成問題前完成升級。