Kubernetes v1.36 Mixed Version Proxy 升至 Beta：滾動升級不再出現假 404
Kubernetes Blog · 2026-05-15
Kubernetes v1.36 將 Mixed Version Proxy（MVP） 功能從 Alpha 升級至 Beta，並預設啟用。MVP 解決了高可用控制平面在滾動升級期間，新舊 API Server 混存時用戶端收到錯誤 404 Not Found 的問題。
原本的問題
K8s HA 叢集升級時，控制平面通常以滾動方式更新，某段時間內同時存在多個版本的 API Server。用戶端請求可能落在一台尚未升級的舊版 API Server 上，若該請求涉及只有新版 API Server 才支援的資源（例如新 API 版本或新 CRD），舊版 Server 無法處理，回傳 404。這個假 404 會導致 controller 誤判資源不存在，觸發不必要的 GC（垃圾回收）、阻塞 namespace 刪除，甚至讓升級流程卡死。
採用的方法
MVP 在收到本機無法處理的 API 請求時，查詢已快取的 peer API Server 能力表，找出能處理該請求的同儕節點，代理轉發請求並將回應返回給用戶端。整個流程對用戶端透明。
Beta 版相較 Alpha（v1.28）有兩項重要改動：
- 發現機制：從依賴 StorageVersion API 改為使用 Aggregated Discovery，解決了前者不支援 CRD 與 aggregated APIs 的限制
- Peer-Aggregated Discovery（新功能）：API Server 回應 discovery 請求時，合併本機 API 清單與所有 peer 的 API 清單，回傳一個統一排序的全叢集 API 視圖，用戶端不再因連接的節點版本不同而看到不一致的 API 集合
規格細節
啟用條件：設定 --peer-ca-file flag。Feature gate 為 UnknownVersionInteroperabilityProxy，v1.36 已預設開啟。已代理的請求會帶上內部追蹤 header x-kubernetes-peer-proxied。如需查看單一節點的本機 API（而非合併視圖），可在請求中加入對應的抑制 header。
影響範圍
對維運「多版本混合控制平面」的團隊（例如使用 GKE、EKS、AKS 的受管叢集，或自建 HA 叢集進行滾動升級）影響最直接。Beta 預設開啟意味著 v1.36+ 的使用者無需額外操作即可受益。需注意 Peer-Aggregated Discovery 的啟用依賴 --peer-ca-file 的設定，未設定時仍退回到只顯示本機 API 的行為。
原始來源：Kubernetes Blog
Kubernetes v1.36 CCM 新增路由同步指標 route_controller_route_sync_total
Kubernetes Blog · 2026-05-15
Kubernetes v1.36 在 Cloud Controller Manager（CCM） 的 Route Controller 中新增 Alpha 計數器指標 route_controller_route_sync_total，讓維運人員能夠觀察路由同步作業的成敗情況與同步頻率。
核心改動
Route Controller 負責在雲端平台上為每個 Node 創建或刪除對應的路由規則，確保跨節點的 Pod-to-Pod 網路連通性。過去這個同步迴圈缺乏可觀測性——若路由同步失敗（例如雲端 API 限速、IAM 權限不足），只能靠 controller manager 的日誌追蹤，Prometheus 層面完全無法量測。
route_controller_route_sync_total 為 counter 型指標，帶有兩個 label：
sync_type：區分create、delete、no-op三種操作result：success或error
目前標記為 Alpha，需透過 --feature-gates=RouteControllerMetrics=true 啟用（或在 v1.36 中設定 ComponentConfig 的對應欄位）。
影響範圍
使用非 Flannel/Cilium 等 CNI overlay 的雲端 K8s 叢集（例如 GCE 的 native route mode）才會執行 Route Controller，這個指標對這類環境有直接意義。維運團隊可利用它建立 Prometheus alert，在路由同步錯誤率上升時及早收到通知，避免路由黑洞造成的網路中斷。
原始來源：Kubernetes Blog
Docker Custom MCP Catalogs 與 Profiles 正式 GA：組織治理與個人工作流分離
Docker Blog · 2026-05-15
Docker Desktop 4.63 正式釋出 Custom MCP Catalogs 與 MCP Profiles 兩項功能的正式版（GA），讓企業可以集中管理核准的 MCP 伺服器集合，同時讓開發者自由維護個人工作流的伺服器組合。
核心改動
Custom Catalogs 是一個 OCI artifact，包含核准的 MCP 伺服器清單（可混合內部自建伺服器與 Docker 官方 MCP Catalog 中的公開伺服器）。Catalog 以不可變版本發佈到容器映像倉庫，確保審計可追溯：
docker mcp catalog push myorg/our-catalogMCP Profiles 是以工作流為單位的伺服器組合與設定快照，例如 coding、planning、data-analysis。Profile 同樣以 OCI artifact 形式共享：
docker mcp profile push coding myorg/coding-profile兩者的設計分離了兩個關注點：Catalog 是組織層的治理工具（IT/Security 核准哪些伺服器），Profile 是個人層的效率工具（開發者在不同任務間一鍵切換工具組合），不互相干擾，也不依賴特定廠商格式。
影響範圍
這兩個功能需要 Docker Desktop 4.63 以上版本，並依賴 Docker 的 MCP Gateway 基礎設施（需登入 Docker 帳號）。對已在採用 MCP 工具鏈的工程組織而言，Custom Catalogs 提供了將 MCP 納入 IT 採購管控流程的標準方式，解決企業安全審計的合規需求。
原始來源：Docker Blog