平台與維運 2026 年 5 月 2 日

2026-05-02 — K8s v1.36 Pod 層級就地縮放 Beta、Cloudflare Fail Small 完成、Docker 代理艦隊

Kubernetes v1.36:Pod 層級資源就地垂直縮…

Kubernetes v1.36:Pod 層級資源就地垂直縮放晉升 Beta,cgroup v2 動態調整無需重啟容器

Kubernetes Blog · 2026-04-30

Kubernetes v1.36 宣布 In-Place Pod-Level Resources Vertical Scaling 晉升 Beta(feature gate InPlacePodLevelResourcesVerticalScaling 預設啟用),允許在 Pod 仍在運行的情況下動態調整 Pod 層級的資源配額,在多數情境下無需重啟容器。

特性背景

v1.34 引入 Pod-Level Resources(Pod 層級的 spec.resources),讓管理者可為整個 Pod 設定資源上限,各容器在此共享池中自由使用。v1.35 將容器層級的就地垂直縮放晉升 GA。v1.36 則結合兩者,在 Pod 層級啟用就地調整。

API 使用方式

kubectl patch pod shared-pool-app --subresource resize \
  --patch '{"spec":{"resources":{"limits":{"cpu":"4"}}}}'

Pod 的 status 新增三個欄位追蹤進度:allocatedResources(節點已核准的配置)、resources(已實際套用至 cgroup 的值)、以及兩個狀態條件 PodResizePending / PodResizeInProgress

調整策略

各容器透過 resizePolicy 宣告每種資源的重啟策略:

  • NotRequired:Kubelet 直接透過 CRI 的 UpdateContainerResources 更新 cgroup 限制,不重啟容器。
  • RestartContainer:需要重啟容器才能套用新限制(例如記憶體 JVM heap 等需要重新初始化的資源)。

調整順序有安全性保障:增加資源時先擴展 Pod 層級 cgroup,再擴展各容器 cgroup(防止容器先使用超出舊上限的資源);減少資源時先縮減各容器 cgroup,再縮減 Pod 層級 cgroup。

環境要求

需要 cgroup v2(聚合資源執行需要 cgroup v2 的精確計量)、containerd v2.0+ 或 CRI-O(支援 UpdateContainerResources)、以及 Linux 平台。需同時啟用四個 feature gate:PodLevelResourcesInPlacePodVerticalScalingInPlacePodLevelResourcesVerticalScalingNodeDeclaredFeatures

未來路徑

Vertical Pod Autoscaler(VPA)計畫整合此功能,在偵測到資源使用不足或超量時,直接觸發 Pod 層級的就地調整,而不是刪除重建 Pod。

原始來源:Kubernetes Blog — v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta


Cloudflare Code Orange Fail Small 計畫完成:Snapstone 漸進式設定部署、流量分段隔離

Cloudflare Blog · 2026-05-01

Cloudflare 宣布「Fail Small」基礎設施韌性計畫完成,這是 2025 年 11 月與 12 月兩次重大中斷後啟動的系統性改造,以設定部署安全、優雅失效模式與流量分段為三大支柱。

Snapstone:設定部署的健康閘控系統

Snapstone 是新建的內部元件,負責管理設定部署並持續監控健康指標。其核心能力:設定變更被打包成一個「快照」,以漸進式釋出方式在網路中部署,從免費層客戶開始,逐步擴展至付費客戶——與軟體釋出的 Canary 部署模式相同。若部署期間健康指標惡化,Snapstone 自動回滾至最後一個已知良好快照。這一機制使設定變更不再需要手動協調,自動獲得與程式碼部署相同等級的安全保護。

優雅失效模式

各服務現在以三種模式之一應對依賴失效:fail stale(使用最後已知的良好設定繼續運作)、fail open(在不確定時允許流量通過,適用於安全策略不如可用性關鍵的場景)、fail closed(在不確定時拒絕流量,適用於安全性優先的場景)。各服務根據自身的業務語義選擇最合適的模式。

流量分段

服務現在被切分為多個獨立副本,每個副本處理不同的客戶群組(cohort)。單一元件的故障只影響對應 cohort 的客戶,而非整個網路。設定變更依 cohort 漸進部署,進一步縮小「爆炸半徑」(blast radius)。

The Codex:AI 強制規則集

Codex 是一個 AI 強制執行的程式碼審查規則集,阻止已知的危險模式——例如在測試以外使用 .unwrap()(Rust panic 潛在來源)、未驗證上游依賴就使用其輸出等。

原始來源:Cloudflare Blog — Code Orange: Fail Small is complete


Docker Coding Agent Sandboxes:以代理艦隊加速出貨的虛擬工程師團隊架構

Docker Blog · 2026-05-01

Docker 的 Coding Agent Sandboxes 團隊發文描述如何以 AI 代理艦隊(fleet of agents)作為「虛擬工程師團隊」,加速自身功能開發週期。核心架構是以 Docker Sandboxes 作為代理的隔離執行環境。

代理艦隊架構

Docker Sandboxes 讓每個代理在隔離的 microVM 環境中執行,代理可以安裝套件、執行程式碼、執行測試,並以真實的 CI/CD 工作流程驗證輸出——不影響宿主環境,也不受其他代理的副作用干擾。多個代理並行執行不同任務,比依序人工處理顯著縮短週期時間。

安全性設計

microVM 隔離確保即使代理執行了惡意程式碼或下載了不可信依賴,也無法逃逸至宿主系統——Docker 稱之為「YOLO mode」(讓代理完全自由地行動,同時以架構保障安全)。每個 sandbox 在任務完成後銷毀,無持久狀態殘留。

工作流程整合

代理艦隊整合至 Docker 的 CI/CD 管線:拉取 PR、執行代理修復、提交修改、觸發 CI 驗證。人工工程師的角色轉變為任務設計、代理輸出審查,以及處理代理無法自主解決的複雜架構決策。

原始來源:Docker Blog — A Virtual Agent Team at Docker


End of article
0
Would love your thoughts, please comment.x
()
x