Kubernetes v1.37:動態資源配置的擴充資源支援與裝置汙點機制雙雙轉為正式版
Kubernetes Blog · 2026-09-03
Kubernetes 專案在 v1.37 版本部落格文章中,一次公布了 Dynamic Resource Allocation(DRA) 子系統的四項更動。其中兩項功能從 Beta 升級為 GA,一項升級為 Beta,另一項屬性定義則直接以穩定狀態上線。這代表 DRA 自早期版本引入以來,正逐步從實驗性 API 走向可在生產環境依賴的能力。
背景:DRA 想解決什麼問題
在 DRA 出現以前,叢集分配 GPU 之類的特殊硬體只能靠 device plugin,以整數數量描述容量,無法依屬性篩選裝置,也無法讓多個容器共享同一個裝置。DRA 改用 resource.k8s.io API 群組下的 DeviceClass、ResourceClaim 與 ResourceSlice 三種物件,讓工作負載用 CEL 運算式描述所需裝置屬性,而非單純填寫數量。裝置擁有者用 ResourceSlice 回報硬體清單,管理員以 DeviceClass 分類,工作負載再以 ResourceClaim 提出請求,目前仍不支援搶占。
核心改動:兩項 GA、一項 Beta
KEP-5004(DRA Extended Resource) 是最重要的變動,經 v1.34 Alpha、v1.36 Beta 後於 v1.37 GA。它讓既有 extended resource(如 example.com/gpu)工作負載不改 YAML 就能改吃 DRA 裝置,做法是在 DeviceClass 新增 extendedResourceName 欄位映射:
apiVersion: resource.k8s.io/v1beta1
kind: DeviceClass
metadata:
name: gpu.example.com
spec:
selectors:
- cel:
expression: device.driver == 'gpu.example.com'
extendedResourceName: example.com/gpu排程器會在 PreFilter 階段偵測這類請求,自動建立一個對應的 ResourceClaim,配置結果則寫回 Pod 的 status.extendedResourceClaimStatus 供 kubelet 用 CDI 注入裝置。同一個節點不能同時用 device plugin 與 DRA 廣播同一種資源,且單一 extended resource 名稱只能對應一個 DeviceClass。另一項功能 KEP-5055(DRA Device Taints and Tolerations) 同樣走完 v1.33 Alpha、v1.36 Beta 到 v1.37 GA 的流程,由 DRADeviceTaints 與 DRADeviceTaintRules 兩個獨立 feature gate 控制。它讓 DRA 驅動程式或叢集管理員能對裝置打上 NoSchedule 或 NoExecute 汙點,效果與節點汙點相同,差別在於只影響實際使用該裝置 ResourceClaim 的 Pod,而非整個節點。
被標記 NoExecute 汙點且無對應 toleration 的 Pod,會由新增的裝置汙點驅逐控制器處理:kubelet 停止容器、標記 Pod 完成,ResourceClaim 控制器再將它從 reservedFor 移除並釋放配額。叢集管理員可以直接建立 DeviceTaintRule 物件,依驅動程式、裝置池或裝置名稱篩選要下線維護的硬體,不必動到驅動程式設定。KEP-4817 把 ResourceClaim.status.devices 升級為 Beta,新增網路裝置的介面名稱、MAC 與 IP 位址回報;Issue 6072 則把 resource.kubernetes.io/numaNode 屬性名稱標準化為穩定狀態,不同廠商驅動程式從此可用同一鍵值描述裝置所在 NUMA node。
| 功能 | KEP / Issue | v1.37 階段 | 版本演進 |
|---|---|---|---|
| DRA Extended Resource | KEP-5004 | GA | v1.34 Alpha → v1.36 Beta → v1.37 GA |
| Device Taints and Tolerations | KEP-5055 | GA | v1.33 Alpha → v1.36 Beta → v1.37 GA |
| ResourceClaim 裝置狀態(網路介面) | KEP-4817 | Beta | v1.37 進入 Beta |
| NUMA node 標準屬性 | Issue 6072 | Stable | v1.37 直接以穩定狀態發布 |
影響範圍
對叢集管理員而言,最直接的效果是可以在不驚動應用團隊的前提下,把 GPU 排程邏輯搬到 DRA,同一叢集裡 device plugin 與 DRA 驅動也能在不同節點並存。裝置汙點機制讓維護排除單一故障硬體變得跟排除節點一樣容易,不必整批驅逐節點上所有 Pod。網路裝置狀態回報和 NUMA 屬性標準化,則對自建可觀測性或拓樸感知排程的團隊有意義,不必再讀取各驅動私有的屬性名稱。
Docker 以 microVM 沙箱回應 AI Coding Agent 的「YOLO 模式」風險
Docker Blog · 2026-09-03
Docker 官方部落格在 2026 年 9 月 3 日發文,指出愈來愈多開發者在使用 Claude Code、Cursor、Codex CLI 等 AI coding agent 時,選擇關閉逐步核准的權限提示,讓 agent 自主讀寫檔案、執行 shell 指令與呼叫工具,業界俗稱這種用法為「YOLO 模式」。文章作者為 Docker 的 Eric Jia 與 Srini Sekaran,主張問題不在於要不要用 YOLO 模式,而在於用它的環境夠不夠隔離。
原本的問題:每家 agent 都有自己的免確認開關
目前主流 coding agent 幾乎都內建了跳過權限確認的旗標,只是名稱各不相同。這些開關拿掉的是人類在每個動作執行前的最後一道審核關卡,agent 因此能連續完成一長串操作而不被打斷。
- Claude Code:
--dangerously-skip-permissions - Cursor:設定內的 Auto-run 開關
- Codex CLI:
--full-auto或--dangerously-bypass-approvals-and-sandbox - Gemini CLI:
--yolo旗標,或執行期間按Ctrl+Y切換 - GitHub Copilot CLI:
--allow-all(別名即為--yolo)
在沒有額外隔離的主機上直接使用這些旗標,風險是具體且會實際發生的。文章列出的情境包括誤下 rm -rf 刪錯目錄、agent 讀到 .env 或 .ssh 之類的憑證檔、網頁或程式碼註解裡藏的提示注入(prompt injection)攻擊,以及修改範圍溢出到不相關專案。由於 agent 通常帶著使用者本人的網路權限,一旦被注入惡意指令,也可能被用來存取內部服務或把資料外傳。
採用的方法:把 agent 關進 microVM,而非裸機執行
Docker 的對策是 Docker Sandboxes,把 agent 的執行環境從主機搬進獨立的 microVM。與共用核心的容器不同,microVM 提供的是硬體層級的隔離邊界,沙箱裡只掛載專案工作目錄,主機檔案系統、真實憑證與網路存取範圍都不會暴露進去。agent 若要跑自己的容器,也可以在沙箱內部起 Docker,不會影響到宿主環境;沙箱本身是拋棄式的,出狀況就直接銷毀重開一個乾淨環境。三大平台都有對應安裝方式:
# macOS
brew trust docker/tap && brew install docker/tap/sbx
# Windows
winget install Docker.sbx
# Linux (Ubuntu)
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx安裝完成後不需要額外啟動 Docker Desktop,目前已支援 Claude Code、Copilot CLI、Codex、OpenCode、Kiro、Gemini CLI 等多款 agent。對於需要在團隊層級統一規範的組織,Docker 另外提供 AI Governance,讓管理者一次定義網路存取、檔案系統與 MCP 工具的使用規則,再自動套用到每台開發機上,而不必仰賴每位工程師自行記得要加哪個沙箱旗標。
實際效果
把 YOLO 模式和沙箱隔離綁在一起後,前面列出的風險場景大多被侷限在沙箱邊界之內:rm -rf 頂多清空拋棄式環境,憑證與提示注入的攻擊面也因為隔離而縮小。Docker 在文章中把這個組合定位成讓開發者「保留 YOLO 模式的速度,同時把出錯代價降到可回收」的作法,而不是勸退開發者停用免確認模式。文章沒有提供具體的事故數字或採用率數據,論述仍停留在架構建議層級。
原始來源:YOLO Mode: Agent Autonomy Without the Guardrails、Docker Sandboxes
在零停機前提下,用 ExternalName 服務把關鍵服務搬出 Kubernetes default 命名空間
CNCF Blog · 2026-09-03
CNCF Blog 在 2026 年 9 月 3 日刊出會員投稿文章,作者 George Sims(Downtherabbithole.dev)描述自己如何把一個放在 default 命名空間裡多年的驗證服務 auth-svc,遷移到專屬的 authentication 命名空間。整個遷移過程沒有造成任何停機,而這個服務負責整個地區叢集的登入驗證,一旦中斷就等於全區使用者無法登入。
原本的問題:改名字容易,協調所有呼叫端很難
auth-svc 長年待在 default 命名空間,單純遷移命名空間在技術上不困難,真正的困難在於有兩條存取路徑要同時維持不中斷:叢集內部靠 DNS 的服務發現,以及對外的 ingress 路由。更棘手的是有數十個分屬不同團隊、不同發版節奏的服務,程式碼裡硬編了舊的 DNS 名稱 auth-svc.default.svc.cluster.local,逐一協調所有團隊同時改名幾乎不可行。
環境本身也有結構性限制:既有的部署流程一次只能對單一命名空間佈署,沒有跨命名空間搬遷的既定做法。叢集的 OPA 政策更明文禁止在不同命名空間之間出現相同的 ingress 規則,這代表沒辦法簡單地在新命名空間複製一份 ingress 就了事,必須先取得暫時的政策例外。
採用的方法:用 ExternalName 服務做 DNS 轉發代理
解法的核心是 Kubernetes 的 ExternalName 服務類型。這種 Service 純粹運作在 DNS 層,回傳一筆指向目標網域的 CNAME 記錄,不經過 kube-proxy,也無法做 port 重新映射。做法是先把真正的服務部署到新的 authentication 命名空間,再於原本的 default 命名空間留一個 ExternalName 服務當跳板,讓舊呼叫端完全不必修改程式碼:
apiVersion: v1
kind: Service
metadata:
name: auth-svc
namespace: default
spec:
type: ExternalName
externalName: auth-svc.authentication.svc.cluster.local所有仍呼叫 auth-svc.default.svc.cluster.local 的服務,會被這筆 CNAME 悄悄導向新命名空間裡真正的服務,呼叫端完全無感。對外流量的部分,則是先幫新命名空間申請一個暫時的 policy 例外,允許新舊兩份 ingress 規則短暫並存,驗證新路徑沒問題後,再把舊 ingress 移除:
apiVersion: v1
kind: Namespace
metadata:
name: authentication
annotations:
policy.example.com/allow-duplicate-ingress: "true"整個遷移按照以下順序推進:
- 在
authentication命名空間部署真正的auth-svc服務 - 在
default命名空間建立ExternalName代理服務,轉發舊呼叫端流量 - 透過監控指標驗證代理是否正常運作
- 把舊 Pod 縮編到 0 個副本,而非直接刪除,保留隨時回滾的能力
- 先在 dev、staging 環境驗證數週,才在正式環境執行 cutover
實際效果
由於轉發發生在 DNS 層,依賴舊網址的數十個服務完全不需要改一行程式碼或重新部署,遷移過程對它們透明。把舊 Pod 縮到零副本而非刪除,也讓整個切換動作在觀察期內隨時可以一鍵回滾,大幅降低了「改了發現不對又要搶救」的風險。作者將 ExternalName 代理與縮容保留這兩個技巧,定位成往後任何把服務搬出 default 命名空間時都可以重複套用的做法,而不是這次遷移的一次性權宜之計。
原始來源:Migrating a critical Kubernetes deployment from the default namespace without any downtime、Kubernetes ExternalName Service docs