Kubernetes 1.36.1 與多條分支補丁更新
Kubernetes 釋出 v1.36.1，並同步更新 1.35、1.34、1.33 分支。這次重點是維持支援版本的補丁節奏，方便叢集按計畫升級。
Kubernetes 釋出 v1.36.1，並同步更新 1.35、1.34、1.33 分支，重點是維持支援版本的補丁節奏。
Kubernetes 在 5 月 12 日丟出一批新版本。主角是 v1.36.1。同批還有 1.35、1.34、1.33 的補丁版。這種更新很樸素，但很重要。叢集要穩，靠的就是這種例行維護。
這次 GitHub release 頁面沒有長篇故事。它更像一張公告牌。官方把讀者導去 kubernetes-announce 和 changelog。講白了就是，版本號先給你，細節自己去查。對 Kubernetes 這種跨平台、跨部署方式的專案，這種做法很合理。
| Release | Date | Type | GitHub reactions |
|---|---|---|---|
| v1.36.1 | May 12, 16:39 | Patch | 18 |
| v1.35.5 | May 12, 15:37 | Patch | 6 |
| v1.34.8 | May 12, 15:35 | Patch | 1 |
| v1.33.12 | May 12, 14:09 | Patch | 8 |
| v1.36.0 | Apr 22, 17:57 | Minor release | 74 |
這批更新到底在做什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這次最醒目的就是 Kubernetes v1.36.1。另外還有 v1.35.5、v1.34.8、v1.33.12。四個版本都在同一天上線，而且時間只差幾個小時。
這種節奏對營運團隊很有感。很多公司不是只跑一個版本。常見情況是，主叢集在新版本，邊緣環境或舊客戶還卡在前一版。補丁同步發佈，代表你可以分批修，不用每次都硬切大版本。
如果你有在管生產環境，這種 release 才是日常。不是每次都會有新功能可以吹。更多時候，真正值錢的是少一個 bug，少一次停機，少一個凌晨兩點的 alert。
- v1.36.1 在 5 月 12 日 16:39 發佈
- v1.35.5 在 15:37 發佈
- v1.34.8 在 15:35 發佈
- v1.33.12 在 14:09 發佈
為什麼 release 頁面這麼簡短
Kubernetes 的 release notes 一直都不愛講廢話。GitHub 頁面只放最基本資訊。真正的變更細節，通常要去 changelog 看。這讓頁面看起來很冷靜，也很工程師。你要的是版本資訊，不是公關稿。
這種寫法也有代價。對剛接觸 Kubernetes 的人來說，release 頁面幾乎像謎語。你知道有新版本，但不知道它修了什麼。要判斷要不要升級，還是得回頭查 Kubernetes changelog。
我覺得這很符合開源專案的現實。Kubernetes 不是單一 SaaS。它是很多公司一起維護的基礎設施專案。公告要短，文件要準，版本要穩。這三件事缺一個，整個社群就會開始痛苦。
“The Kubernetes project is built by dozens of companies and hundreds of individual contributors.” — Dan Kohn, CNCF
這句話到現在還很貼切。Kubernetes 的更新不是某一家廠商拍腦袋就能做完。它是協作結果。你在 GitHub 上看到的每一個 patch，背後都是一堆人一起對齊、測試、簽核。
所以別把這種 release 當成小事。對雲端平台來說，穩定補丁比華麗功能更實際。尤其是跑在 production 的 cluster，少一個安全修補或相容性修正，後面就是一串麻煩。
這批版本怎麼比
從數字看，最新的 minor line 最受關注。v1.36.0 有 74 個 reactions，明顯比 patch 版高很多。這很正常。新 minor release 通常會吸引更多人點進去看。
但 patch 版也不是沒人理。v1.36.1 還是拿到 18 個 reactions。v1.33.12 也有 8 個。這表示舊支援線還有實際使用者，不是發完就放生。
對維運團隊來說，這裡的重點不是 reaction 數字本身，而是支援面。你如果還在 1.33、1.34、1.35，代表你有一條自己的升級路線。patch release 就是讓你可以慢慢走，不用一次搬整座山。
- v1.36.0：74 reactions，熱度最高
- v1.36.1：18 reactions，最新補丁仍有關注
- v1.35.5：6 reactions，支援線還在動
- v1.34.8：1 reaction，低調但仍有更新
- v1.33.12：8 reactions，老版本還沒被丟掉
如果你把 Kubernetes 跟其他平台比，差異很明顯。很多商用平台只照顧少數版本。Kubernetes 這邊則是多條分支一起維護。這很累，但也很符合大型基礎設施的現實。
另外，GitHub 還能看到前一版的 release candidate，像 v1.36.0-rc.1 和 v1.36.0-rc.0。這代表正式版前，還是走完了完整的測試流程，不是隨便打包就丟上來。
對台灣團隊有什麼影響
如果你在台灣管雲端服務，這種 release 你應該要盯。不是因為它很熱鬧，而是因為它很實際。Kubernetes 的 patch release 常常牽涉到安全修補、相容性調整，還有一些你平常不會注意，但出事就很痛的細節。
很多團隊會把升版排在固定維護窗。這很合理。問題是，有些人只看 minor version，忘了 patch 版。結果就是，叢集明明在支援範圍內，卻一直沒吃到修正。這種做法我真的不推，因為最後常常是事故來教你做人。
比較務實的做法，是先看自己的版本矩陣，再對照 changelog。先確認控制平面、node pool、CNI、Ingress controller、CSI driver 這幾塊有沒有相依風險。升級不是按一顆按鈕。它是整串軟體一起動。
你現在該做什麼
如果你的叢集還在 1.33、1.34 或 1.35，先別急著衝。先查你用的雲端供應商版本支援表，再看對應 patch 的 changelog。把風險列出來，比盲升版更省時間。
我的建議很簡單。把 patch release 當成例行維護，不要等到事故才看。你可以先在 staging 跑一次，再觀察 node、API server、controller manager 的狀態。這種事沒什麼浪漫，但很有效。
說到底，Kubernetes 這次的更新沒有花俏戲碼。它做的事很基本：讓支援中的版本繼續能用，讓維運團隊有空間安排升級。接下來你要做的，就是檢查自己的版本，別把補丁當空氣。