2026-05-07 — K8s v1.36 宣告式驗證 GA、Docker Model Runner、Deptool

Kubernetes v1.36 Declarative Validation 進入 GA：18,000 行手寫驗證程式碼的終結

Kubernetes Blog · 2026-05-05

Kubernetes v1.36 將 Declarative Validation 提升至 GA（General Availability），正式以 +k8s: 標記標籤（marker tags）取代 Kubernetes 原生類型中約 18,000 行的手寫驗證程式碼。此功能透過 validation-gen 程式碼生成器，從 types.go 中的型別定義直接生成驗證函式，同時啟用 API linting 與自動化的 ratcheting 語意。

背景

Kubernetes 歷年來的 API 驗證以命令式 Go 程式碼實作，散落在 pkg/apis/*/validation/ 目錄下。這些程式碼難以被工具和 API 使用者程式化發現，驗證邏輯在不同資源間不一致，且維護負擔沉重——每份 PR 都需要逐行審查以確保正確性。更根本的問題是，驗證規則無法透過 OpenAPI schema 公開，導致客戶端工具無法在送出請求前進行本地驗證。

核心改動

+k8s: 標記的常用選項包括：

+k8s:optional / +k8s:required：欄位存在性約束
+k8s:minimum=0 / +k8s:maximum=100：數值範圍
+k8s:maxLength=16：字串長度限制
+k8s:listType=map / +k8s:listMapKey=type：集合語意
+k8s:immutable：不可變欄位
+k8s:update=[NoSet, NoModify, NoClear]：更新語意

type ReplicationControllerSpec struct {
    // +k8s:optional
    // +k8s:minimum=0
    Replicas *int32 `json:"replicas,omitempty"`
}

Ambient Ratcheting 是此版本的關鍵特性：更新物件時，框架自動比對新舊物件狀態，若欄位值語意不變，則略過新驗證規則。這讓 API 維護者可以在不引發回歸的情況下收緊或放寬驗證，而不需要等待客戶端遷移完成。

影響範圍

kube-api-linter 現在可以靜態分析 API 型別，在 PR 提交時即偵測違反約定的設計，減少 SIG API Machinery 審查者的手動負擔。驗證規則透過 OpenAPI 發布後，Kubebuilder 等生態工具可直接整合，讓 CRD 作者也受益於一致的驗證框架。DeclarativeValidation feature gate 在 v1.36 標記為 stable，可在生產叢集中使用。

原始來源：Kubernetes Blog — Kubernetes v1.36: Declarative Validation Graduates to GA

Docker Model Runner 本地影像生成：DDUF 格式、OpenAI 相容 API 與 Open WebUI 整合

Docker Blog · 2026-05-05

Docker 發布教程，介紹如何以 Docker Model Runner（DMR）結合 Open WebUI 在本地生成影像，整個管線完全私有，不需要雲端服務。DMR 以 OpenAI 相容 API（含 POST /v1/images/generations）作為推理前端，以 DDUF（Diffusers Unified Format） 作為模型封裝格式。

規格細節

DDUF 是單一檔案格式，將 Stable Diffusion 等擴散模型的所有組件打包：

Text encoder
VAE（Variational Autoencoder）
UNet/DiT（去噪網路）
Scheduler 配置

模型以 OCI artifact 形式發布至 Docker Hub，可直接用 docker model pull stable-diffusion 拉取。

API 呼叫格式完全相容 OpenAI，支援 negative_prompt、num_inference_steps（1–50）、guidance_scale（1–20）、seed 等擴散模型特有參數：

curl -X POST http://localhost:12434/engines/diffusers/v1/images/generations \
  -H "Content-Type: application/json" \
  -d '{"model":"stable-diffusion","prompt":"A cat",
       "size":"512x512","num_inference_steps":30}'

核心改動

DMR 採用代理架構：

控制平面（port 12434）：管理模型下載、生命週期、推理後端
Open WebUI（port 3000）透過 http://model-runner.docker.internal 路由至 DMR

首次請求時，DMR 解包 DDUF、透過 HuggingFace Diffusers 的 DiffusionPipeline 初始化、啟動 FastAPI 伺服器並將模型保留在記憶體中。自包含的 Python 環境安裝在 ~/.docker/model-runner/diffusers/，不與系統 Python 衝突。

影響範圍

GPU 支援涵蓋 NVIDIA CUDA、Apple Silicon MPS，以及 CPU fallback。OpenAI 相容介面意味著原本指向 OpenAI 影像生成 API 的程式碼只需修改 base URL 即可切換至本地端。對於需要資料隱私的組織（醫療影像、法律文件插圖）或在受限網路環境下開發的場景，此架構提供了無需修改應用邏輯的本地替換路徑。

原始來源：Docker Blog — Generate Images Locally with Docker Model Runner and Open WebUI

Deptool：靜態二進位 + 樂觀鎖實現次秒級宣告式部署

ruuda.nl · 2026-05-07

軟體工程師 Ruud van Asseldonk 發布 Deptool，一個針對個人基礎設施設計的輕量部署工具。它以 Git 儲存庫為配置真相來源，以約 1.6 MB 靜態二進位作為遠端代理，透過 SSH 傳輸並以樂觀鎖（optimistic concurrency）協調多主機的同步部署，目標是「次秒級部署」和完全可預測的執行行為。

原本的問題

作者的目標平台是最小化 Linux 發行版（Flatcar），沒有預裝套件管理器或直譯器。Ansible 的每次連接需要傳送數 MB 的 Python 模組，且命令式執行流程難以預測。Deptool 的設計約束是：只依賴目標主機上的 uname、mkdir、dd、chmod、sha256sum 等標準工具即可完成初始安裝。

採用的方法

部署工作流程為：

配置預先渲染為靜態檔案，以兩層結構（主機 → 應用程式）存放在 Git 中
deptool deploy 計算 cluster diff，本地生成計畫（offline，毫秒級）
使用者確認後，工具對所有受影響主機取得分散式鎖，確保計畫有效性
以 commit hash 版本化目錄（/var/lib/deptool/<hash>/）實體化檔案，current symlink 切換至新版本
重啟 systemd unit；若啟動失敗，毫秒級自動回滾至前一版本

與 Ansible 的根本差異在於：Deptool 傳送的是已生成的靜態配置，而非命令序列，因此沒有 SSH shell 逃脫問題，也沒有遠端環境差異造成的不確定性。

影響範圍

Deptool 明確定位為單一操作者的個人基礎設施工具，不適合高競爭的多操作者場景（樂觀鎖在此情境下效率低）。對 Flatcar 或類似最小化 Linux 發行版的用戶而言，它填補了現有主流工具（Ansible、NixOS、Terraform）在輕量、確定性部署場景下的空白。

原始來源：ruuda.nl — Building the deployment tool I wish I had

End of article

Kubernetes v1.36 Declarative Validation 進入 GA：18,000 行手寫驗證程式碼的終結

背景

核心改動

影響範圍

Docker Model Runner 本地影像生成：DDUF 格式、OpenAI 相容 API 與 Open WebUI 整合

規格細節

核心改動

影響範圍

Deptool：靜態二進位 + 樂觀鎖實現次秒級宣告式部署

原本的問題

採用的方法

影響範圍

More on this topic