Kubernetes 3 個支援窗口看懂升級時機

Kubernetes 只支援最新三個次版本，每個版本大約有 14 個月的支援窗口。

看懂 endoflife.date 上的 Kubernetes 版本表，能讓你在 3 個支援分支之間快速判斷：現在該維持哪個版本、哪個分支已進入維護期、以及什麼時候必須安排升級。

項目	主動支援	維護支援	最新修補版
1.36	2027-04-28 結束	2027-06-28 結束	1.36.2
1.35	2026-12-28 結束	2027-02-28 結束	1.35.6
1.34	2026-08-27 結束	2026-10-27 結束	1.34.9
1.33	2026-04-28 結束	2026-06-28 結束	1.33.13

1. 只看最新三個次版本就夠了

Kubernetes 採用 N-2 規則，也就是只維護最新的 3 個 minor version。這代表安全修補與錯誤修正只會回補到 1.36、1.35、1.34 這三條分支，舊版本即使還能跑，也不再算受支援。

這個規則是整份支援表的核心。你不需要逐列背日期，只要先確認自己的叢集是否落在這 3 個版本內，就能知道自己是站在支援範圍裡，還是已經踩到升級紅線。

• 目前受支援：1.36、1.35、1.34
• 1.33 與更早版本已不在主動支援範圍
• 修補通常只回補到這 3 條分支

2. 15 週一版，版本很快就會往前推

Kubernetes 的 minor release 大約每 15 週發一次，所以支援窗口不是固定不動，而是持續往前滑。這也是為什麼你在 Kubernetes 生態裡，常常會看到新版本剛出來不久，舊版就開始進入尾聲。

對維運團隊來說，這個節奏意味著不能等到版本過老才處理。只要錯過幾個 release cycle，叢集就可能從主動支援滑進維護期，接著很快失去修補來源。

• minor version 約每 15 週發佈一次
• 支援狀態會隨新版本推出而往前移
• 補丁版會在受支援分支上持續釋出

3. 14 個月窗口，才是升級排程的基準

每個 minor version 的總支援期大約是 14 個月，拆成 12 個月主動支援，再加 2 個月的升級緩衝。這個數字最適合拿來排內部升級計畫，因為它直接對應到可延後的時間有多少。

以表格來看，1.36 還在主動支援，1.33 已經結束主動支援，而更舊的版本則更早退出。你可以把這個窗口當成最後期限，不是提醒而已，而是實際的排程依據。

支援期 = 12 個月主動支援 + 2 個月升級緩衝

4. 修補回補只會發生在受支援分支

不是每個修正都要等下一個 minor release。Kubernetes 會依嚴重性與可行性，把安全修補和 bug fix 回補到受支援的 3 條分支，這讓穩定叢集可以在不大幅跳版的情況下維持安全。

這也是為什麼最新 patch version 通常最值得跟進。若你還停在較舊的 patch，雖然同屬一個 minor branch，但安全與穩定性可能已經落後一截。

• 回補只限於受支援分支
• 是否回補取決於嚴重性與可行性
• patch release 可能是例行，也可能是緊急修補

5. 升級時別忽略版本相容性

Kubernetes 是 client-server 架構，版本相容性會影響 kubectl、控制平面與節點的升級順序。也就是說，不能只看 control plane 是否升級完成，還要一起確認工具端與節點端是否仍符合版本差異規則。

實務上，升級前先檢查版本相容性，能避免「叢集還能運作，但管理起來很卡」的情況。這一步看似瑣碎，卻常常是升級成功與失敗的分水嶺。

kubectl version

怎麼挑最適合你的版本

如果你要最穩的預設，選最新的受支援 minor version，再跟上該分支的最新 patch。若你的團隊升級頻率高，15 週發版節奏比單一日期更重要；如果你在管舊叢集，表格裡的主動支援結束日就是該啟動遷移的訊號。

多數讀者最適合的做法，是維持在最新受支援版本並盡量貼近最新修補版。需要規劃升級的人，則應先看 3 條支援分支的剩餘時間，再決定是立即升級、排入下一季，還是已經過了安全線。