Docker 推出 SBX：用 microVM 把 AI Agent 關進沙盒，憑證留在主機外面
Docker Blog · 2026-07-01
背景
Docker 在部落格文章中指出，讓 AI agent 直接在開發者主機上執行指令是一種不對稱風險：agent 可能刪除重要檔案、外洩憑證、安裝惡意套件，或在無人監督下修改設定。文章作者 Karan Verma 主張，AI 產生的指令應該在「設計來安全容錯」的環境中執行，而不是預設取得主機的完整權限。這篇文章介紹 Docker 新推出的 sbx 工具，把這個原則落地成一個可獨立安裝、不需要完整 Docker Desktop 的沙盒執行環境。
核心改動
Docker Sandbox（SBX）的隔離基礎是 microVM 而非單純的容器層。原因是傳統容器與主機共用核心（kernel），一旦 AI agent 執行未知程式碼或存取外部套件庫，共用核心就成為攻擊面；microVM 則提供獨立的核心邊界。文章同時介紹了「代理管理憑證」（proxy-managed credentials）機制：真正的憑證留在主機端，沙盒內部只看得到 sentinel 佔位值，等到請求要送出沙盒邊界時，才由代理層把佔位值換成真實的認證標頭。這代表即使 agent 在沙盒內把憑證印出來或外洩，外部看到的也只是無效的佔位字串。
Docker 另外定義了 Sandbox Kits 這個封裝單位，把工具、依賴套件、環境變數、（代理管理的）憑證、網路規則、檔案與啟動指令，甚至 agent 的記憶檔（如 AGENTS.md、CLAUDE.md）打包成可重複使用的環境藍圖。Kits 分成兩種：Mixin Kits 用來為既有 agent 疊加額外能力，Agent Kits 則是從零定義一個完整的 agent 執行環境。實際使用方式如下：
sbx run claude --kit ./my-kit/影響範圍
這篇文章把 Docker 先前發表的〈Why MicroVMs? The Architecture Behind Docker Sandboxes〉架構文章，收斂成一套面向終端使用者的操作模型：microVM 提供隔離基礎，Sandbox Kits 讓這個基礎變得日常可用。隨著 agent 自主執行指令、串接外部服務的比例升高，把憑證與網路存取權從沙盒內部移除會是下一階段 agent 開發工具鏈的共同課題，而不只是 Docker 單一產品的差異化賣點。
kpt 重新出發：完整加入 CNCF Sandbox，主打「Configuration as Data」而非 IaC
CNCF Blog · 2026-07-02
背景
kpt 最早由 Google 在 GoogleContainerTools 底下開發，用來操作以 Kubernetes Resource Model（KRM） 表示的設定檔——也就是一批描述叢集資源期望狀態的宣告式 YAML 檔案。專案後來把主要程式碼與 KRM functions 目錄搬到獨立的 kptdev 組織下維護。CNCF 這篇由 Ericsson 的 Ciaran Johnston 撰寫的文章，是在 kpt 正式完整加入 CNCF Sandbox 之後的「重新介紹」，說明專案目前的定位與技術取向。
規格細節
kpt 的核心概念是 Configuration as Data：設定本身是純粹的結構化資料（KRM 套件），轉換設定的商業邏輯則獨立成 functions，兩者刻意分離。因為設定只是資料，不需要執行任何程式就能對它 diff、lint、審查。這與多數工具採用的「configuration as code」路線不同，也是 kpt 與 Kustomize 這類工具的分野——kpt 採用「in-place」更新模式，讓最終要套用的完整設定隨時可見、可審閱，而不是隱藏在範本邏輯背後。
工具鏈依照套件生命週期分成幾個環節：kpt CLI 負責用範本 bootstrap 新套件；pipelines 負責串接驗證器（validator）與轉換器（mutator），把通用範本自動特化成上百個站點各自需要的參數化套件；套件在部署前要經過審查與驗證流程；最後才由 kpt 把套件部署到實際環境，並持續監控其 reconciliation 狀態。整套工具是模組化設計，可以只取用其中一部分能力嵌入既有的 Kubernetes 工具鏈，不必整套換掉。
影響範圍
文章提到專案接下來的重點包含 v1 API 穩定化、文件重新整理，以及社群要求已久的密鑰（secrets）處理與多叢集支援。kpt 的每週例會固定在週三 CET 14:00 於 GitHub 進行，討論也同步在 kptdev/kpt issues 與 Kubernetes Slack 的 kpt 頻道上進行。對於已經在用 GitOps 或平台工程套件管理的團隊而言，kpt 重新定位為「可插入既有工具鏈的一部分」，而不是要取代整條 pipeline。
Kubernetes DRA 在 v1.35 GA：ResourceClaim、DeviceClass 如何取代 Device Plugin 的節點綁定限制
CNCF Blog · 2026-07-01
背景
在 Dynamic Resource Allocation（DRA）出現之前，Kubernetes 要分配 GPU 等特殊裝置得靠 Device Plugin API，缺點是排程器只知道裝置的數量，不知道裝置的具體型號與特性。這逼得使用者得把同型號裝置固定綁在同一個節點上，並且用複雜的 nodeSelector 或 Affinity 規則手動湊資源。CNCF Ambassador ChengHao Yang 在這篇文章中說明，DRA 已在 Kubernetes v1.35 正式 GA，文中示範環境使用 Kubernetes v1.35.3。
規格細節
DRA 引入四個新的 API 資源取代舊模型：
DeviceClass：定義一類裝置，例如一般 GPU、MIG 切分後的 GPU、或 VFIO 直通裝置ResourceSlice：由 DRA driver 在每個節點自動更新，記錄該 driver 在這個節點上管理的所有裝置ResourceClaim：使用者手動宣告要分配的裝置，狀態會經過pending到allocated,reservedResourceClaimTemplate：讓 Deployment 底下每個 Pod 都能各自產生專屬的裝置宣告
文章展示了兩個進階能力：一是用 CEL 表達式直接篩選裝置，例如指定 GPU 記憶體門檻；二是用 firstAvailable 策略設定裝置的排序偏好，讓排程器依序嘗試分配。文中也提到 GPU time slicing 可以透過設定檔啟用，讓多個工作負載共享同一張實體 GPU 的運算時間。
影響範圍
實測環境搭配 NVIDIA GPU Operator v26.3.1 與 NVIDIA DRA Driver GPU v25.12.0。文章特別指出，NVIDIA 已把 dra-driver-nvidia-gpu 移交進 Kubernetes SIGs 底下維護，官方文件也把它的標籤從 Beta 拿掉，代表這條技術路線與周邊生態系正逐漸走向穩定。對於跑 AI/ML 工作負載、需要精細管理 GPU 資源的叢集，DRA 提供的裝置選擇模型比 Device Plugin 時代更貼近實際硬體拓樸，不再需要用 workaround 去模擬裝置感知排程。