Kubernetes v1.36 把發布說明變作戰手冊

Kubernetes v1.36 可以直接拿來當叢集升級清單，我把它拆成你真的會用的動作。

我看 Kubernetes release notes 看很多年了，老實說，大多數版本都長得差不多：stable、beta、alpha 一字排開，語氣很客氣，內容也很容易滑過去。看完你會點頭，然後什麼都沒做。v1.36 讓我停下來的原因，是它不像在秀功能，反而像在畫壓力圖。它明明白白告訴我，這版要你注意的不是某個炫技新玩意，而是調度、政策、儲存、觀測、授權，還有那些升級時最容易咬人的邊角。

我自己在幫團隊做 Kubernetes 升級時，最怕的從來不是版本號，而是「看完 release notes 以為沒事」。真正會出事的，通常是 rollout 之後才冒出來的那種：某個 controller 要不要改、某個 policy 會不會卡住、某個 chart 會不會在半夜炸掉。v1.36 這版剛好很適合拿來做一次方法論拆解，因為它給的訊號夠多，夠你把 release notes 變成決策表，而不是心情筆記。

這篇的起點是官方 Kubernetes blog：Kubernetes v1.36: ハル (Haru)。我也會順手拉到文內連結的 feature posts，因為 release post 本身只是地圖，不是整塊地。這點很重要。

別把 release notes 當廣告文案看

Similar to previous releases, the release of Kubernetes v1.36 introduces new stable, beta, and alpha features.

翻譯一下就是：Kubernetes 還是在分層交付，release notes 不是叫你全吞，而是叫你判斷每一層該信多少。stable 是可以放進 production 規範的東西；beta 是我會開始排 migration 的東西；alpha 則是實驗室儀器，能看、能學，但別急著把整個平台押上去。

我以前很常犯一個錯：把 release notes 當採購清單。看到有新東西就想撿，結果最後不是 feature gate 沒人管，就是團隊會議上每個人都很興奮，真正要落地時沒人知道誰負責。這種事我看多了，真的很煩。

v1.36 給我的第一個訊號不是「功能很多」，而是「這版仍然在成熟與探索之間拉扯」。這很正常。重點是，你要先做分類，不要先做幻想。分類做不好，升級計畫就會變成半成品。

• stable：寫進標準、文件、預設值。
• beta：進 staging，量化影響，再決定要不要上。
• alpha：隔離、加 gate、別拿來當核心依賴。

我實際會怎麼做？我會在升級筆記裡開三欄：safe to enable、pilot in staging、ignore for now。每個 v1.36 項目先丟進這三欄，再談要不要讓團隊興奮。這招很土，但土的方法通常最少出事。

調度還是 Kubernetes 最會出題的地方

Advancing Workload-Aware Scheduling

白話就是，Kubernetes 持續把調度從單純的 CPU、memory 配置器，往更懂 workload 的方向推。scheduler 不再只是 bin-packer，而是開始變成一個有意見的 policy engine，會考慮 workload 形狀、資源壓力、placement tradeoff。

我遇過一個很典型的場景：團隊一直問，為什麼某些 pods 會「亂」跑到看起來沒問題、實際上很爛的 node。其實不是亂跑，是 scheduler 照著我們的規則在做事。問題通常不是工具壞掉，而是我們腦中的模型太簡單。你以為你在要 placement，實際上你需要的是帶 context 的 placement。

這就是 workload-aware scheduling 真正重要的地方。它不是單一功能，而是訊號：Kubernetes 想讓 operator 更精準地表達 intent。如果我在跑 latency-sensitive service、batch job、混合型 workload，共用 node 的時候，我就會希望 scheduler 知道哪些 pod 不能互換。

我會直接檢查三件事：node labels 跟 affinity 有沒有堆成一坨例外、taints 有沒有變成沒人解釋得清楚的歷史包袱、topology rules 還是不是跟實際故障模式對得上。只要有一項答案是「大概吧」，那就是這版逼你整理現況的時候。

• 盤點 node labels 與 affinity。
• 確認 placement 規則是否對應 SLO。
• 寫清楚哪些 workload 可以彈性，哪些不行。

如果要往下看，我會先看 kube-scheduler，再補 scheduling and eviction。重點不是背旗標，是別再把調度當魔法。

政策不是越多越安全，是越清楚越安全

Declarative Validation Graduates to GA

這句話翻成台灣開發者聽得懂的版本，就是 Kubernetes 繼續把驗證和政策從零散腳本，往內建的 declarative control 推。這對曾經被 admission webhook 搞到懷疑人生的人來說，算是好消息。

我對這件事很有怨氣，因為我真的活過 webhook 地獄。先是一條驗證規則，接著第二條、第三條，然後不同團隊各自加一層。到最後，沒人知道是哪個 webhook 擋掉物件，擋掉的原因是政策還是實作 bug，也沒人說得準。你以為你在做 governance，其實你只是在堆 folklore。

GA 的價值不是「又多一個功能」，而是讓你少養一個自製服務。政策如果能放進原生機制，就不要硬塞進 controller、webhook、CI pipeline 三套系統一起檢查。那不是 defense in depth，那叫重複勞動。

我會這樣落地：先列出平台團隊最常看到的前五種 object-level 錯誤，再一條一條判斷，哪些應該用原生 Kubernetes 機制擋掉，哪些留給外部 policy，哪些其實只是文件沒寫清楚。很多所謂治理問題，最後都只是溝通問題穿了安全外套。

如果你在用 admission controllers，或者已經有 Kyverno、OPA Gatekeeper，這版很適合回頭砍重複規則，不要只會加。

儲存真正要的是一致性，不是更多名詞

Moving Volume Group Snapshots to GA

這句話的意思是，storage 團隊終於可以比較放心地把 group snapshot 放進正式設計，不用再把它當某個 vendor 的 side quest。Volume group snapshots 進 GA，代表 Kubernetes 對相關 volumes 的協調式快照處理更穩了，這對非單一 volume 的應用很重要。

我看過太多備份計畫翻車，原因都差不多：大家假設資料庫、sidecar、支援資料會各自獨立失敗或恢復。現實不是這樣。你只 snapshot 一部分，技術上叫成功，實際上叫把壞掉的應用備份得很完整。

GA 在這裡不是新鮮感，而是信心。它表示 API 與行為已經穩定到可以拿來設計，而不是只在測試環境裡玩一玩。對需要可重複 recovery story 的 operator 來說，這差很多。

我會直接回頭檢查 disaster recovery 流程：如果你用 CSI storage，備份工具有沒有真的吃到 group snapshot semantics？如果你沒有做過 app-level restore test，那你沒有備份策略，你只有 storage 帳單。

這裡可以對照 Kubernetes storage 與 CSI docs。另外也要看 storage provider 自己的 support matrix，因為 Kubernetes 進 GA，不代表每個 backend 都會乖。

• 只測 snapshot 建立不算數，restore 一定要測。
• 確認多 volume 的一致性。
• 寫清楚哪些 workload 能從 point-in-time snapshot 還原。

觀測不是加更多圖，是承認壓力真的存在

PSI Metrics for Kubernetes Graduates to GA

白話就是，Kubernetes 把 pressure signal 正式變成平台可見性的一部分，而不是只留給少數人調校用。PSI，也就是 pressure stall information，能讓你知道 node 什麼時候在承受 CPU 以外的壓力。

我喜歡這個方向，因為「CPU 只有 40%」這種話騙過我太多次了。node 看起來不忙，不代表 latency 不會爛；memory pressure、I/O contention、scheduler churn 都可能在背後咬你。PSI 至少能讓你知道問題在哪一側，不會只盯著一個漂亮數字自我安慰。

只要 metrics 進 GA，我就會開始想 dashboard、alert、runbook，不是因為我愛看圖，而是因為穩定訊號值得進 incident response。PSI 如果已經是平台的一部分，那它就不該躺在角落沒人看，而是要進 capacity planning 跟 node health debugging。

我會直接問：我們的 alert 反映的是 pressure，還是只是 utilization？這兩件事差很多。你如果曾經看過 node 明明「正常」，pods 卻開始 throttle，那你就知道這版在解什麼問題。

實作上我會先看 resource management。如果你在 Linux 環境，kernel PSI 的文件也值得補一下。重點是別再拿單一指標當 cluster health 的替身。

授權收緊，才是真的在降風險

Fine-Grained Kubelet API Authorization Graduates to GA

這句話的意思是，Kubernetes 持續把 access 的 blast radius 縮小。kubelet 這種元件很容易被人因為它是「內部的」就放鬆警戒，但 internal 不等於 harmless。更細的授權，就是讓你可以更準確地控制誰能碰哪些 API。

這種工作看起來很無聊，實際上常常最值錢。我看過不少 cluster，kubelet access 是歷史包袱一路繼承下來的，因為沒人想拆。結果就是某些 debug tool 或內部帳號，拿到了比它應該知道的更多資訊。這不是方便，這是風險累積。

GA 的訊號很明確：這不再是冷門 hardening 選項，而是主流操作模型的一部分。如果你管的是 multi-tenant cluster 或受管制 workload，這項應該排進你的檢查表。

我會這樣處理：先盤點 kubelet access path，再把仍然過寬的權限縮回來。RBAC 如果還停在「之後再整理」，那現在就是整理的時候，不要等到要對資安交代才開始找設定檔。

背景可以看 authentication and authorization，kubelet 本身則對照 kubelet reference。這些不是教科書，是你排查權限邊界時會真的翻的東西。

Alpha 功能最像路標，不是成品

Pod-Level Resource Managers (Alpha)

這句話的意思是，Kubernetes 還在試著把資源管理從 container 粒度往 pod 粒度拉。這很有意思，因為它暗示未來的資源控制會更貼近真實應用的樣子，而不是只對單一 container 做簡化假設。

我對 alpha 一向很小心，不是因為它們不好，而是因為它們很誠實。它們直接告訴你：我還沒準備好。這種誠實其實很有價值，因為它讓我能看到 project 想解什麼問題，而不是假裝今天就能拿去支撐 production。

Pod-level resource management 之所以值得看，是因為現在很多 workload 根本不是單一 container 的世界。sidecar、init container、helper process、混合資源型態，早就把舊模型弄得很彆扭。如果 Kubernetes 能在 pod 邊界上更自然地管資源，operator 的摩擦會少很多。

但我不會因為它存在就急著上。alpha 的用途是學習，不是穩定生產。你要問的不是「能不能打開」，而是「Kubernetes 想解什麼問題，而我的 workload 真的有這個問題嗎？」

背景可以看 pods 跟 resource requests and limits。如果你想知道更多實作細節，還是要回去翻官方 blog 裡連著的 feature posts。

可抄的模板

# Kubernetes v1.36 版本審查模板

## 版本資訊
- 版本：
- 發布日期：
- 原始來源：
- 負責人：
- 受影響叢集：

## 變更分類
### Stable
- [ ] 項目：
- [ ] 項目：

### Beta
- [ ] 項目：
- [ ] 項目：

### Alpha
- [ ] 項目：
- [ ] 項目：

## 對我們有沒有影響
每個項目都回答：
- 會不會影響 scheduling？
- 會不會影響 policy / security？
- 會不會影響 storage / backup？
- 會不會影響 observability？
- 會不會增加 upgrade risk？

## 採用決策
| 項目 | 狀態 | 原因 | Owner | 截止日 |
|------|------|------|-------|--------|
|      | Adopt |      |       |        |
|      | Test  |      |       |        |
|      | Ignore|      |       |        |

## 升級前檢查
- [ ] 讀完 upstream feature post
- [ ] 確認 feature gate 狀態
- [ ] 驗證跟現有 controller / operator 相容
- [ ] 在 staging 測試
- [ ] 更新 runbook
- [ ] 更新 alerts / dashboards
- [ ] 確認 rollback path

## 升級前必答
- 啟用後會壞什麼？
- 既有 workload 行為會怎麼變？
- 我要盯哪些 metrics？
- rollback 怎麼做？
- 誰負責後續？

## 最終決定
- Approve / Defer / Reject
- 備註：
- 下次追蹤日期：

這就是我會真的拿去開會的版本。它把吵雜的 release notes 變成決策文件，這才是大多數團隊真正需要的東西。

如果我明天就要處理 v1.36，我會先把功能分成 stable、beta、alpha，再把注意力放在 scheduling、policy、storage、observability、auth。真正會影響營運的地方就在這些，不在那些看起來很熱鬧的描述句。

原始來源是 Kubernetes 官方 blog：https://kubernetes.io/blog/2026/04/22/kubernetes-v1-36-release/。這篇的拆解與模板是我根據官方 release post 和相關 feature posts 做出的實務整理，原創的是我的判讀方式，衍生的是對官方內容的操作化翻譯。