Oracle OKE 的 Kubernetes 支援節奏

Oracle OKE 目前只支援 3 個 Kubernetes 版本做新叢集，舊版會在新版本推出後依序退場。

說真的，這份支援表不是參考用。它會直接影響你能不能升級，還有能不能新建叢集。

Oracle 的 Kubernetes Engine 文件把規則寫得很清楚。新版本一上線，舊版本就開始倒數。

現在的版本範圍橫跨 1.32 到 1.36。裡面還藏了 preview、node image、cgroups v2 這些實務坑點。

OKE 的支援窗很短，這是設計好的

Oracle 說得很直白。OKE 只支援 3 個 Kubernetes 版本做新叢集。當它宣布支援新版本後，舊的第四版只會再撐至少 30 天。

這種節奏對維運團隊很現實。你不是想升才升，而是得跟著支援窗跑。拖太久，常會碰到不支援的 node image，或是升級路徑被卡住。

Oracle 也建議，新叢集直接用最新支援版。舊叢集則要在新版本公告後盡快規劃升級。這句話很樸素，但很有用。

• OKE 新叢集只支援 3 個 Kubernetes 版本。
• 新版本公告後，第四舊版至少再支援 30 天。
• 1.36.0 是 preview，不適合直接上正式環境。
• 目前文件涵蓋 1.32 到 1.36。

1.35 最大的變化，是 cgroups v2

真正麻煩的點，在 Kubernetes 1.35。從這版開始，Kubernetes 需要 cgroups v2 來做容器資源管理。

這不是小改動。它會直接影響 worker node 用什麼 image。Oracle 明講，OKE OL8 image 若 build number 是 1367 以上，預設就開 cgroups v2。

如果你還在用 OL7 image，就不能直接升到 1.35。Oracle 也說，OL7 platform image 和基於 OL7 的 custom image 都不行。

"Starting with Kubernetes version 1.35, Kubernetes requires cgroups v2 for container resource management." — Oracle Cloud Infrastructure documentation

講白了就是，1.35 不是單純換版本號。你要先看 node image，還要看底層作業系統。

如果你是從 OKE OL7 升上來，這次通常得做 out-of-place upgrade。也就是先準備 OL8，再切過去。

• 1.35 需要 OL8 或更新版本。
• OKE OL8 build 1367 以上預設啟用 cgroups v2。
• OL7 image 不支援 1.35。
• OL7 不能直接原地升級到 1.35。

Preview 版本能試，但別拿去賭 production

Oracle 把 1.36.0、1.35.0、1.34.0、1.33.0 都標成 preview。這些版本只在 OC1 realm 提供。

這代表什麼？代表你可以測，但別太早把它當正式版。Oracle 也一直提醒，最好等後續的 production release。

像是 1.36.0 之後，Oracle 期待你看的是 1.36.1。1.35.0 也是一樣，重點會落到 1.35.1。

1.34.1 的說明更細。Oracle 提到上游問題在 1.34.2 會修掉。如果那些問題會影響你，直接升 1.34.1 可能不是好主意。

這裡的訊息很清楚。不是每個 patch 都一樣穩。文件其實是在幫你避坑，不是在叫你盲升。

• 1.36.0、1.35.0、1.34.0、1.33.0 都是 preview。
• preview 只提供在 OC1 realm。
• Oracle 常建議等下一個 production 版本。
• 1.34.2 被點名用來修 1.34.1 的上游問題。

Patch note 裡的細節，才是維運地雷

1.34.1 還有一個很實際的變更。CRI-O 預設開始強制完整 image name。

意思很簡單。你如果只寫 nginx，有些情況會出事。Oracle 直接建議寫成 docker.io/nginx 這種完整格式。

這種改動最煩。因為它不一定立刻炸，但一炸就是 pull image 失敗，而且訊息還不一定看得懂。

• 1.34.1 預設啟用 CRI-O 完整 image name 檢查。
• 短名稱可能因 registry 模糊而失敗。
• Oracle 提供 cloud-init workaround。
• 若受上游問題影響，1.34.2 比 1.34.1 更保險。

我覺得這份文件最有價值的地方，不是版本表本身。

而是它把升級風險講得很務實。你要看版本，也要看 node image、OS、runtime 行為。

這份支援表背後，是 Oracle 的升級邏輯

Oracle 的做法很像很多雲服務商。它不想讓你長期卡在舊版。因為舊版會拖累支援成本，也會增加相容性問題。

對開發團隊來說，這代表版本治理要更早做。不要等到 EOL 前一個月才補文件。那時候通常只剩救火。

你也可以把這份表當成排程工具。現在如果你還在 1.32 或 1.33，就該先看 node image，再看應用相依套件。

另外，preview 和 production 的界線也很重要。很多團隊會把測試環境升很快，正式環境卻拖太久。最後就是兩邊版本差太多，問題更難重現。

這也是為什麼 Oracle 反覆強調 newest supported version。它不是在講理想，而是在講維運成本。

• 舊版拖越久，升級成本通常越高。
• 測試環境和正式環境版本差距不能太大。
• node image 要和 Kubernetes 版本一起看。
• 版本治理最好提早排進維運節奏。

現在最實際的做法，是先查三件事

如果你有 OKE 叢集，先查目前 Kubernetes minor version。再查 worker node 用的是 OL7 還是 OL8。

最後看有沒有用到 short image name，或是依賴 preview 版本。這三件事，通常就能抓出大部分風險。

我的判斷很直接。只要你的叢集還沾到 OL7，1.35 這條線就不能亂碰。

接下來的升級策略，也很明確。先把測試環境拉到接近 production，再處理 node image，最後才動 Kubernetes 版本。

如果你現在正在排 OKE 升級，我會先問一句：你的 node image 已經準備好升到 OL8 了嗎？