2026-05-14 — Cloudflare Browser Run Containers、K8s v1.36 Gang Scheduling、PSI GA

Cloudflare Browser Run 遷移至獨立 Container 架構：並發量翻 4 倍，Quick Actions 延遲砍半

Cloudflare Blog · 2026-05-13

Cloudflare Browser Run（可程式控制的無頭瀏覽器服務）完成從共用 Browser Isolation 基礎設施到獨立 Cloudflare Containers 的遷移。新架構讓並發瀏覽器數從 30 提升到 120，每分鐘可啟動 60 個瀏覽器，Quick Actions 端點的 P50 回應時間下降超過 50%。

舊架構的問題

Browser Isolation（BISO）共用模型的長會話特性與 Browser Run 短促突發的使用模式相互干擾，導致擴容策略無法獨立最佳化。舊系統使用 Workers KV 追蹤 container 狀態，但 KV 的最終一致性延遲約 30 秒，造成同一個 container 被重複認領的競態條件。

新架構：Durable Object 池 + D1 + Queues

新設計以 Durable Object 承載每個 container 的狀態，並在各地區建立預熱的 DO-backed browser container pool，限制 DO 與 container 間的距離以降低延遲。Container 狀態遷移至 D1（SQLite 事務），以原子 SQL 交易防止競態：

UPDATE containers
SET status = 'picked'
WHERE sessionId IN (
    SELECT sessionId FROM candidate_pool
    ORDER BY RANDOM() LIMIT ?5
)
RETURNING data

Queues 批次寫入每 5 秒更新一次 container 狀態，批次設定 100 列 / 1 秒超時，P95 寫入延遲 0.1ms，每地點可支援 500,000 個 container（原上限 5,000）。

漸進式遷移策略

工程團隊在請求路徑插入一個 Worker，同時服務 BISO 與 Container 版瀏覽器，按 Quick Actions → 免費帳號 → 付費帳號 → 合約客戶的順序漸進切換。遷移期間也完成了對 WebGL 與 WebMCP（Model Context Protocol for Web）的支援，後者為 AI Agent 與瀏覽器的互動提供標準化介面。

Kubernetes v1.36 工作負載感知排程：Workload/PodGroup v1alpha2、Gang Scheduling、DRA 整合

Kubernetes Blog · 2026-05-13

Kubernetes v1.36 引入 scheduling.k8s.io/v1alpha2 API，將靜態模板（Workload）與執行時狀態（PodGroup）解耦，使 AI/ML 訓練任務、批次作業等需要協調排程的工作負載能以原子方式操作，解決逐 Pod 排程在大規模場景下的效率問題。

API 結構

Workload 物件充當靜態模板，定義 podGroupTemplates 及其排程策略；PodGroup 持有執行時狀態，透過 podGroupTemplateRef 引用模板。Pod 本身以新欄位 schedulingGroup.podGroupName 取代舊有的 workloadRef：

spec:
  schedulingGroup:
    podGroupName: training-job-workers-pg

Gang scheduling 在 PodGroup 的 schedulingPolicy.gang.minCount 指定最少同時可排程的 Pod 數，排程器以 PodGroup Scheduling Cycle 對整個 PodGroup 做原子決策，而非逐 Pod 評估。

DRA 整合與拓撲感知

Dynamic Resource Allocation（DRA）的 ResourceClaim 支援在 v1.36 與 PodGroup 整合，使 GPU、FPGA 等動態硬體資源的申請能與 Gang 排程協同作業。拓撲感知排程（Topology-Aware Scheduling）與工作負載感知搶佔（Workload-Aware Preemption）在本版本推出第一版，可在叢集拓撲層面分配 PodGroup，並以整個工作負載為單位進行搶佔決策，避免部分 Pod 被驅逐後 Gang 失去法定數量的問題。

Kubernetes v1.36：PSI 資源壓力指標畢業至 GA，提供搶先偵測飽和的高解析度訊號

Kubernetes Blog · 2026-05-12

Kubernetes v1.36 讓 Pressure Stall Information（PSI）指標功能門控 KubeletPSI 畢業至 GA（預設啟用）。PSI 源自 Linux 核心 2018 年引入的機制，透過 /proc/pressure/ 與 cgroup v2 壓力檔案，量測任務因等待 CPU、記憶體、I/O 而停頓的時間比例，在資源飽和演變為服務中斷之前提供預警。

指標結構

每種資源（CPU、Memory、I/O）各有 some（至少一個任務阻塞）與 full（所有任務阻塞）兩種維度，搭配 10s / 60s / 300s 移動平均及累計總量。Kubelet 在 /metrics/resource 端點以 Prometheus 格式暴露節點、Pod、Container 三個粒度的指標：

kubelet_psi_cpu_some_avg10{node="node-1"} 2.50
kubelet_psi_memory_full_avg60{node="node-1"} 0.08
kubelet_psi_io_full_avg300{node="node-1"} 1.20

啟用條件與效能影響

需要 Linux kernel 啟用 psi=1 及 cgroup v2。在 80+ Pod 密度的驗證測試中，kubelet CPU 開銷約 2.5%，核心層開銷 0.9%–3.1%，被評估為可接受的生產負擔。PSI GA 後可直接用於排程決策的輸入訊號、HPA/VPA 的觸發條件，以及容量規劃的長期趨勢追蹤。

End of article