Cloudflare Code Orange：Fail Small 工程計畫完成，網路韌性系統性重構
Cloudflare Blog · 2026-05-01
Cloudflare 的「Code Orange：Fail Small」是一項跨越兩季的大規模工程計畫，起因於 2025 年 11 月與 12 月的重大中斷事故。計畫目標是系統性地改變基礎設施在配置異動與服務故障時的行為模式。
Snapstone：健康介導的配置部署
核心變更是建立 Snapstone 系統，讓配置異動採用與軟體發布相同的漸進式部署機制。一項配置更改被打包為一個「套件」（package），依序推送至不同的客戶群組（免費用戶先行，關鍵客戶最後），每個階段都進行實時健康監測，發現異常可自動回滾。過去配置更改是立即全域生效的，這導致一個錯誤配置可以在秒級內影響全球所有客戶。
優雅降級（Graceful Failure Modes）
各產品團隊依業務特性重新設計了故障策略：服務在無法存取最新配置時優先回退到「上一份已知正常配置」（last known good configuration）；僅在特定條件下才採用 fail-open 或 fail-close，且每種策略都需要明確的工程審查。這取代了過去隱含的「無法存取 = 全部失敗」的預設行為。
流程分隔與爆炸半徑控制
服務現在跨不同客戶群組獨立運行，配置更改逐步推進。一個有問題的更改在被自動偵測並回滾前，最多只會影響一小部分流量，而非觸發全域中斷。
The Codex：AI 強制執行的工程規範
Cloudflare 建立了一份強制性的工程規範手冊（The Codex），以 AI 驅動的程式碼審查在合併請求階段自動執行。規則包含禁止特定不安全的 Rust 模式、要求相依性驗證等，將過去只在生產環境中才被發現的問題提前至 PR 階段攔截。組織還為 18 項關鍵服務開發了備用授權路徑，並對 200+ 名工程師進行了全機構演練。
原始來源：Cloudflare Blog
Kubernetes v1.36：Pod 層級資源管理器 Alpha 版發布
Kubernetes Blog · 2026-05-01
Kubernetes v1.36 引入 Pod-Level Resource Managers Alpha 功能（需啟用 PodLevelResourceManagers 與 PodLevelResources 兩個 feature gate），將 kubelet 的 Topology Manager、CPU Manager 與 Memory Manager 從純粹的容器級別擴展至支援 Pod 級別的 .spec.resources 規格。
問題背景
在既有模型中，Guaranteed QoS 的資源排它分配（exclusive allocation）是以容器為單位的。若一個 Pod 有多個容器（主應用程式 + 監控 sidecar），即使 sidecar 實際上只需要少量資源，也必須為其設定 limits 才能被 CPU Manager 接受。這導致開發者被迫要麼為 sidecar 過度分配資源，要麼放棄使用 Guaranteed QoS。
兩種分配模型
新功能引入混合分配模型：
- 排它容器（Exclusive Container）：從 Pod 預算中獲取專屬 CPU/記憶體切片，cgroup 層的 CPU CFS 配額（CFS quota）在容器層級停用，容器不受節點全域資源競爭影響。
- Pod 共享池（Pod Shared Pool）：剩餘資源形成共享池，sidecar 等輔助容器在此池中執行，與排它容器的切片完全隔離，CPU CFS 配額在 Pod 層級強制執行。
典型使用場景
緊耦合資料庫（主 DB 容器獲取排它資源，監控/備份 sidecar 共享池執行）、ML 工作負載（GPU 訓練獲取 NUMA 對齊的排它 CPU，服務網格 sidecar 進入共享池）、低延遲應用程式（主工作負載保證可預測效能，輔助服務同節點並存但隔離）。
原始來源：Kubernetes Blog
Kubernetes v1.36：Pod 層級資源就地垂直擴縮升至 Beta
Kubernetes Blog · 2026-04-30
Kubernetes v1.36 中，In-Place Pod-Level Resources Vertical Scaling 升至 Beta，預設啟用（feature gate：InPlacePodLevelResourcesVerticalScaling），允許在不重啟容器的情況下更新執行中 Pod 的聚合資源預算（.spec.resources）。
cgroup 實作細節
調整由 kubelet 透過 CRI 的 UpdateContainerResources 呼叫完成，需要 containerd v2.0+ 或 CRI-O，且僅支援 Linux cgroup v2。為避免資源超射（overshoot），kubelet 依調整方向決定 cgroup 更新順序：
- 增加資源時：先擴展 Pod 層級 cgroup（創造「空間」），再擴大各容器 cgroup。
- 減少資源時：先收縮容器 cgroup（防止容器使用超額資源），再縮小 Pod 層級 cgroup。
ResizePolicy 與重啟行為
容器層級的 resizePolicy 決定調整是否需要重啟：NotRequired 觸發動態 cgroup 更新無需重啟；RestartContainer 則重啟容器以應用新的聚合邊界。resize 子資源（subresource）的 kubectl 指令為 kubectl patch pod <name> --subresource resize --patch '{"spec":{"resources":{"limits":{"cpu":"4"}}}}'。
前往 GA 的路徑
Beta 階段的限制：尚不支援 Pod 層級 ResizePolicy（kubelet 完全依據各容器的 resizePolicy）；沒有智慧的多容器資源分配邏輯；VPA 整合與 Windows 支援計畫於 GA 前加入。
原始來源：Kubernetes Blog
Docker 的虛擬工程師團隊：以 AI Agent 艦隊加速 CI 交付
Docker Blog · 2026-05-01
Docker 的 Coding Agent Sandboxes 團隊部署了一套由七種 AI 角色組成的自主工程師艦隊，在 CI/CD 管線中執行測試、分流、修復與文件等重複性工作。
Skill 系統與隔離機制
七個艦隊角色（/build-engineer、/project-manager、/product-owner、/cli-tester、/performance-tester、/upgrade-tester、/software-engineer）各由一份 SKILL.md 定義角色、職責與允許使用的工具，共 20 個 skills（7 個角色 + 13 個基礎能力）。Agent 運行在 Docker Sandbox（microVM 隔離），每個 sandbox 獲得獨立的檔案系統、Docker daemon 與私有網路，提供強隔離防止不受信任的 Agent 程式碼影響宿主系統。
Ralph-Loop 迭代引擎
程式碼生成採用「Worker + Reviewer」分離模式：Worker（Claude Opus）負責實作，Reviewer（Claude Opus，百萬 context）評估，最多 5 輪迭代直到 SHIP 或 REVISE。Agent 建立工作分支、迭代至測試通過後發 PR，人工審查後合併——Agent 不自動 merge。
實際效益
標記 agent-fix 的 issue 在約 1 小時內獲得第一個 PR 草稿；/cli-tester 在 macOS/Linux/Windows 三平台執行 52+ 個測試場景，覆蓋 624+ 種組合；/software-engineer 每週主動提出 3 個技術債 PR；/product-owner 每日自動從 commit log 生成可讀的發布說明並發至 Slack。
原始來源：Docker Blog