Docker VMM 公開測試版：從第三方 Hypervisor 轉為自研虛擬化層
Docker Blog · 2026-08-12
Docker 於 2026 年 8 月 12 日發布 Docker VMM 公開測試版，這是 Docker Desktop 用於 macOS 與 Windows 的虛擬化層第一次由 Docker 自行從頭打造。此前 Docker Desktop 在 macOS 上依賴第三方虛擬機監視器 libkrun（4.35–4.85 版），而從 Docker Desktop v4.86 起，Docker VMM 改用官方自行開發、專為容器工作負載最佳化的 hypervisor。Windows 端則是 Docker 首次自行維護的 VMM，過去仰賴 Hyper-V 搭配第三方整合層。
核心改動
Docker VMM 定位為「容器最佳化 hypervisor」，同一套虛擬化引擎同時支撐 Docker VMM 與 Docker Sandboxes，讓 Docker 能對引擎堆疊的每一層做調校，而不受制於外部 VMM 的更新節奏。官方列出的效能改善集中在啟動速度、檔案 I/O 與記憶體管理三個面向：容器首次啟動、專案切換、重啟復原都變快；容器與主機間的檔案共享延遲降低，直接影響 edit-compile-test 迴圈；閒置容器記憶體會歸還主機，Docker Desktop 不再長期占用未使用的 RAM。
- Windows 端提供 Hyper-V 完整 VM 隔離，效能對齊 WSL2
- macOS（Apple Silicon）與 Windows 需要
Docker Desktop v4.86以上 - Linux 支援延後至 GA 階段才提供
影響範圍
啟用方式因平台而異：macOS 若已使用 Docker VMM 升級到 4.86 會自動套用，否則需到 Settings → General → Virtual Machine Manager 手動切換並重啟；Windows 則在同一路徑下直接切換，不需要 waitlist 或 feature flag。官方文件同時列出幾項已知限制，包括 Docker Linux VM 建議至少配置 4 GB RAM、bind mount 的自動共享尚未支援需手動設定、macOS 上不支援 Rosetta 使 amd64 模擬效能不佳，以及 MongoDB、Cassandra 等資料庫在 virtiofs 上可能出現相容性問題。測試期預計持續到 2026 年秋季，GA 目標訂在 10 月底，屆時將成為 Docker Desktop 新安裝的預設選項。
用 Kyverno 與 VictoriaMetrics 打造可觀測的 Policy as Code
CNCF Blog · 2026-08-12
CNCF 於 2026 年 8 月 12 日刊出由 VictoriaMetrics 與 Kyverno 社群共同撰寫的文章，說明如何把 Kubernetes 的 Policy as Code 從單純的准入攔截，轉成可持續觀測的治理機制。作者是 VictoriaMetrics 開發者關係負責人 Diana Todea 與 Kyverno 社群的 Cortney Nickerson。核心主張是政策不該是黑箱：叢集管理者不只要知道規則被擋下了，還要能看到政策執行的趨勢與分布。
規格細節
文章以 Kyverno 這套 CNCF Graduated 專案示範，其政策以 YAML 加 CEL（Common Expression Language）撰寫，涵蓋五種生命週期動作：
- Validate — 資源進入叢集前檢查是否符合設定規範
- Mutate — 自動補上缺漏的 metadata
- Generate — 依觸發條件產生附屬資源
- Image Validate — 限制容器映像只能來自可信 registry
- Delete — 阻擋特定資源被刪除
安裝與資料串接的示範相當直接，觀測性的關鍵在於把准入事件轉成 PromQL 可查詢的時間序列指標，例如 kyverno_admission_requests_total，再交由 VictoriaMetrics 儲存、Grafana 呈現核准率與資源分布。
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno -n kyverno --create-namespace影響範圍
這套組合的價值在於讓平台團隊在治理規模擴大時，不必犧牲對政策效果的可見度或開發者的部署速度。VictoriaMetrics 的角色是承載高基數（high-cardinality）指標且記憶體開銷低，適合長期保留 Kyverno 產生的大量准入事件序列。文章附上的示範 repository 提供完整的 Helm 安裝與 Grafana dashboard 設定，可直接套用在既有叢集上驗證。
Docker 支援 ModelPack：讓 AI 模型用 OCI 制式打包與流通
CNCF Blog · 2026-08-12
CNCF 於 2026 年 8 月 12 日刊出 Red Hat 工程師 Andrew Block 撰寫的文章，介紹 Docker 如何支援 ModelPack 這個以 OCI 標準打包 AI/ML 模型的開放規格。ModelPack 的目標是統一模型的封裝方式，讓模型能像容器映像一樣跨工具、跨 registry 流通。它與現有的 Docker Model 格式並存，而非取代，兩者都建立在 OCI artifact 之上，只是使用的 media type 不同。
規格細節
ModelPack 的 image manifest 遵循 application/vnd.oci.image.manifest.v1+json，並以 artifactType 欄位標記為 application/vnd.cncf.model.manifest.v1+json，與 Docker 原生 Model 格式（application/vnd.docker.ai.model.config.v0.1+json）在 config descriptor 上明確區隔。manifest 底下的 layers 依內容分成五類，各自支援 .raw、.tar、.tar+gzip、.tar+zstd 四種壓縮方式：
| Layer 類別 | 內容 |
|---|---|
| Weights | 模型權重本體 |
| Weight Config | tokenizer.json、config.json 等 |
| Documentation | License、README 等文件 |
| Code | 推論或前處理程式碼 |
| Datasets | 訓練或評測資料集 |
規格文件建議權重檔案盡量不壓縮以省去解壓成本，檔案排序需固定為字典序，且 metadata 不應取用磁碟上的浮動值，以確保打包結果可重現。目前所有 media type 都是 v1，屬第一版規格。
影響範圍
Docker CLI 已加入對應指令，可直接把既有模型輸出成 ModelPack 格式的 OCI artifact：
docker model package --format=cncf因為 ModelPack 與 Docker Model 格式都只是不同 media type 的 OCI artifact，Docker Hub、Quay、Harbor 等既有 registry 不需要額外改動即可儲存與分發，等於讓模型打包這件事延續了容器生態既有的基礎設施，而不用重建一套新的分發管道。
原始來源：CNCF Blog、ModelPack 規格文件