Kubernetes 同步發布三分支修補版：v1.36.4、v1.35.8、v1.34.11
github.com · 2026-08-20
背景：三分支同步修補
Kubernetes 專案於 2026 年 8 月 20 日同時發布三個活躍分支的修補版本：v1.36.4、v1.35.8、v1.34.11。專案目前並行維護三條 minor 分支,一次同步出補丁的情況通常代表其中有跨分支共用的相依套件安全性更新需要一起回補。這次三個分支都各自累積了自上一版以來的修復,但共同點集中在同一組相依套件上。
核心改動
v1.36.4 是三者中修復項目最多的一支,主要集中在排程與 DRA（Dynamic Resource Allocation,讓 GPU 等外接裝置以外掛驅動方式接入排程系統的 beta 機制）相關臭蟲。DRA 的共享計數器快取先前只用 pool 名稱當鍵值,導致多個驅動使用同名 pool 時配置出錯（#140504）；搶占機制的競爭條件會讓 Pod 卡在 Unschedulable 狀態（#140685）；kubelet 端 DRA 的 PrepareResources 重試邏輯會把重複的 CDI device ID 傳給 CRI runtime（#140955）。v1.35.8 只回補了同一個搶占競爭條件（#140637）,並將建置工具鏈升級到 Go 1.26（#140920）；v1.34.11 這次沒有獨立的行為修復,主要是同步 Go 1.26 建置（#140919）。三支都各自把 golang.org/x/net、golang.org/x/text 升級到含安全性修復的版本,三個 release 頁面都只寫「include security updates」,並未在 changelog 中列出對應 CVE 編號。
| 版本 | 獨立行為修復 | 相依套件更新 |
|---|---|---|
v1.36.4 | DRA 共享快取鍵值衝突（#140504）、搶占競爭條件（#140685）、kubelet DRA 重複 CDI device ID（#140955）、client-go FakeCustomStore 補齊介面方法（#141001） | golang.org/x/net、golang.org/x/text 安全性更新（#141226） |
v1.35.8 | 搶占競爭條件（#140637） | 改以 Go 1.26 建置（#140920）；golang.org/x/net、golang.org/x/text 安全性更新（#141225） |
v1.34.11 | （無獨立行為修復) | 改以 Go 1.26 建置（#140919）；golang.org/x/net、golang.org/x/text 安全性更新（#141224） |
影響範圍
受影響的使用者集中在兩群:一是有使用 DRA 掛載多個同名資源池的叢集,v1.36.4 之前的版本在此情境下可能配置到錯誤裝置；二是所有叢集的 API server 與 controller 都會因為 x/net、x/text 更新而需要重新建置與部署。搶占競爭條件影響範圍較廣,凡是排程器頻繁觸發搶占的叢集都可能遇到 Pod 卡住,v1.36.4 與 v1.35.8 都已回補,但 v1.34.11 的 changelog 沒有列出對應項目。
原始來源：Kubernetes v1.36.4、Kubernetes v1.35.8、Kubernetes v1.34.11
Docker Verified Publisher 認證改為自助申請
docker.com · 2026-08-20
核心改動
Docker 於 2026 年 8 月 20 日在官方部落格宣布,Docker Verified Publisher（DVP,已驗證發布者）計畫的申請流程改為自助式。發布者可以直接在 Docker Hub 的 Explore 頁面送出申請,不再需要先聯絡業務團隊。Docker 團隊審核通過後會核發付款連結,完成付費即可取得 Verified 徽章與搜尋排序加權。此外,DVP 涵蓋的內容類型從單純的容器映像檔擴大到 MCP server、模型（model）、sandbox、agent 等新型態內容都能申請掛牌,定價方案也拆成兩種以對應不同成長階段的發布者。
影響範圍
Docker 表示此舉是為了因應「agentic software 時代」——使用者與 agent 篩選軟體的邏輯已經從「這個東西夠不夠紅」變成「我們知道是誰發布的嗎」,因此需要更清楚的信任訊號讓機器也能自動判斷來源可信度。已驗證發布者新增了可查看 pull 次數、採用趨勢與使用公司名單的分析報表,取得比過去更完整的使用數據。既有的 DVP 發布者如 Google、Microsoft、AWS、Datadog、Grafana Labs、n8n 不受此變動影響,徽章維持有效；新流程即日起生效,沒有另外公告過渡期時間表。
原始來源：Docker Blog
從齊默曼電報看雲原生時代的資料主權
cncf.io · 2026-08-20
原本的問題
CNCF 部落格於 2026 年 8 月 20 日刊出這篇文章,作者為 Tyk 的 James Hirst 與 Budhaditya Bhattacharya。文章以 1917 年德國發給墨西哥的齊默曼電報（Zimmermann Telegram）開場：即使訊息已加密並繞經英屬電報線路傳輸,英國「40 號房」的密碼破譯人員仍成功解密內容並公開於美國報紙,間接促成美國參戰。作者藉此點出核心原則:訊息是誰的並不重要,只要它跑在你不掌控的基礎設施上,掌控基礎設施的一方就能讀到它。文中並引用一起近期案例作為現代對照:某美國雲端巨頭被指曾把荷蘭主管機關（負責執行歐盟《數位服務法》）的未經編修文件提供給美國國會,同時提到美國《CLOUD Act》允許美國企業交出存放在海外司法管轄區的資料。
採用的方法/觀點
作者強調一個關鍵區分：資料落地（data residency）不等於資料主權（data sovereignty）——伺服器實體位置所在地,並不能保證資料受到保護,只要營運商的法律管轄權不同,這層保護就可能失效。他們認為這是結構性問題而非特定廠商的過失,任何總部設在美國的雲端供應商都面對相同的法律義務。文章因此建議組織應辨別哪些基礎設施依賴需要真正掌控,哪些只求方便即可,而不是一概而論。
實際效果/意義
作者點名幾個 CNCF 專案作為因應方向：Kubernetes 可讓工作負載一致地部署在公有雲、自有機房與具主權保證的供應商之間；OpenTelemetry 能把可觀測性資料匯出到組織自行掌控的後端；Open Policy Agent（OPA）讓治理政策可以自行管理;符合開放標準的 API gateway 則能在多個部署環境間落實區域性資料主權規則。作者最後主張,透過開源、可自行維運的基礎設施取得營運自由,才能真正掌握資料存取權與供應商關係的主導權,而不是仰賴單一雲端廠商的合約承諾。
原始來源：CNCF Blog