Kubernetes v1.36 Alpha：伺服器端分片 List/Watch 以 FNV-1a 雜湊減少控制器記憶體壓力
Kubernetes Blog · 2026-05-06
Kubernetes v1.36 在 Alpha 階段引入 Server-Side Sharded List and Watch，允許 controller 在 ListOptions 中指定 shardSelector，讓 API server 在回傳 List 結果與 Watch 事件流之前即進行過濾，而非讓每個 controller 副本接收完整事件流後自行篩選。功能由 ShardedListAndWatch feature gate 控制。
原本的問題
在擁有數萬節點、數十萬 Pod 的大型叢集中，監控高基數資源（如 Pod）的 controller 面臨擴展瓶頸：每個 controller 副本都接收完整的事件流，在水平擴展時每個副本的記憶體和 CPU 消耗不會隨分片數下降。傳統的客戶端分片（client-side sharding）僅是每個副本在收到事件後自行丟棄不屬於自己的部分，網路頻寬和 API server 的序列化負擔並未減少。
規格細節
分片以確定性 64 位元 FNV-1a 雜湊為基礎，雜湊目標欄位目前支援：
object.metadata.uidobject.metadata.namespace
Controller 以 shardRange(field, start, end) 函式指定要接收的雜湊範圍，start 和 end 為 16 進制的 64 位整數。API server 只回傳雜湊值落在 [start, end) 區間的物件。
shardSelector := "shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"
factory := informers.NewSharedInformerFactoryWithOptions(client, resyncPeriod,
informers.WithTweakListOptions(func(opts *metav1.ListOptions) {
opts.ShardSelector = shardSelector
}),
)回應的 metadata.shardInfo.selector 欄位讓客戶端確認 API server 確實支援並套用了分片過濾，防止靜默退化（silent downgrade）。
影響範圍
此特性處於 Alpha，預設關閉，需在 API server 啟用 ShardedListAndWatch feature gate。當前最適用場景是大型叢集中監控 Pod 等高基數資源的 controller（如排程器輔助、資源配額控制器），水平擴展後每個副本的記憶體消耗可線性下降。目前分片欄位限於 uid 和 namespace，未來版本可能擴展至自訂標籤。
原始來源：Kubernetes Blog
AI Agent 沙箱方案比較：容器、microVM、Docker Sandbox 的隔離與效能取捨
Docker Blog · 2026-05-07
Docker Captain Siri Varma Vegiraju 發表技術比較，系統梳理在 AI Agent 場景下幾種主流沙箱方案的安全邊界、效能特性與操作複雜度，重點比較標準容器（OCI/Docker）、microVM（Firecracker、gVisor）、以及 Docker Sandbox 的設計取捨。背景是：超過四分之一的生產程式碼已由 AI 生成，使用 Agent 的工程師合併 PR 的數量多出 60%，「讓 Agent 跑任意程式碼」的需求已從研究環境進入生產。
各方案比較
| 方案 | 隔離邊界 | 啟動延遲 | 適用場景 |
|---|---|---|---|
| 標準 Docker 容器 | namespaces + cgroups（共享核心） | 毫秒級 | 可信任程式碼，效能優先 |
| gVisor（runsc） | 使用者空間核心攔截系統呼叫 | 數百毫秒 | 中等信任，系統呼叫過濾 |
| Firecracker microVM | 獨立核心 + KVM 硬體虛擬化 | 125ms | 不可信任程式碼，強隔離 |
| Docker Sandbox | Firecracker + OCI + Snapshotter | ~125ms | AI Agent，標準 Docker API |
Docker Sandbox 的設計
Docker Sandbox 以 Firecracker 為底層虛擬化引擎，外部仍暴露標準 Docker API，讓現有的 Docker Compose 定義可直接用於沙箱環境。關鍵改進是 snapshotter 設計：利用共享映像層加速容器啟動，避免每個 Agent 執行都從零載入完整映像。沙箱完全隔離：每個 Agent 實例擁有獨立虛擬機核心，無法透過核心漏洞逃脫影響宿主或其他 Agent。
影響範圍
AI Agent 在「YOLO 模式」（允許自主執行任意命令）下的安全需求本質上與傳統 CI/CD 沙箱相似，但組合了更高頻率（Agent 可能每分鐘執行數十次）與更不可預測的程式碼（LLM 生成的 shell 命令）。microVM 方案的 125ms 啟動延遲在 Agent 工作流中通常可接受，但在互動性要求高的場景（如 REPL 式迭代）可能成為瓶頸；此時 gVisor 的毫秒級啟動是可考慮的折衷。
原始來源：Docker Blog