k6 2.0 正式發布：MCP 整合、新斷言 API 與 OpenTelemetry 原生輸出
Grafana Blog · 2026-05-12
Grafana Labs 於 5 月 12 日發布 k6 2.0，這是該負載測試工具自開源以來的首個主版本升級。此次更新的核心是讓 k6 能夠嵌入 AI 編碼助理的工作流程，同時在瀏覽器測試、擴充架構與可觀測性輸出三個方向都有明確改動。官方明確表示既有腳本、checks、thresholds、scenarios 與 CI/CD 工作流程均維持向下相容。
背景
k6 原本定位為指令碼驅動的 HTTP 負載測試工具，腳本以 JavaScript 編寫，搭配 checks 與 thresholds 描述通過條件。版本 2.0 並未打破既有腳本相容性——此次升級的出發點是回應 AI 輔助開發工具（Claude Code、Cursor 等）的普及，以及使用者對瀏覽器測試和分散式測試的需求增長。擴充套件生態系的管理也需要一個更有結構的機制，促成了 xk6 工具鏈的全面升級。
核心改動
k6 x 命名空間新增四個子指令，讓 k6 可作為 MCP 伺服器暴露給 AI agent：
k6 x agent：在 Claude Code、Cursor 等工具中啟動 agentic 測試工作流程k6 x mcp：以 Model Context Protocol server 形式運作，提供工具與資源供 AI agent 呼叫k6 x docs：從命令列直接查詢 k6 文件與 API 參考k6 x explore：瀏覽 k6 擴充套件登錄庫
斷言 API 引入 expect()，分為兩種模式：非重試斷言（non-retrying）用於立即求值靜態數值，自動重試斷言則持續等待條件成立或逾時，專為瀏覽器測試中的非同步 UI 狀態設計。以下為啟動 MCP server 的指令範例：
k6 x mcp
# 在 Claude Code / Cursor 的 MCP 設定中指向此 server
# 即可讓 AI agent 直接生成、驗證、執行 k6 腳本瀏覽器模組擴大了對 Playwright API 的相容範圍，讓既有 Playwright 測試腳本可直接移植為 k6 負載情境。擴充架構方面，xk6 工具箱新增鷹架生成、靜態分析與測試能力，社群擴充可透過 k6 x 子指令命名空間新增自訂指令。官方同時整合了一份統一的擴充套件目錄，涵蓋 k6/x/faker、k6/x/mqtt、k6/x/sql、k6/x/dns 等常用協定。
影響範圍
可觀測性輸出新增 JSON 摘要格式與 OpenTelemetry 原生輸出支援，方便與既有監控管線整合而無需外掛適配器。分散式測試方面，k6 Operator 1.0 進入穩定版，可在 Kubernetes 上協調多節點壓測任務。
由於腳本相容性維持不變，現有 CI/CD 流水線升級後無需修改測試腳本；主要需要調整的是擴充套件開發者，需遷移至新的 xk6 工具鏈。採用 Playwright 的團隊可評估將部分功能測試直接重用為負載測試基礎，而 MCP server 模式則為 AI 驅動的測試腳本生成提供了直接入口。
pyinfra：用純 Python 取代 YAML Playbook 的無代理基礎設施自動化
pyinfra.com · v3（持續維護）
pyinfra 是一套以 Python 撰寫部署邏輯、透過 SSH 執行的無代理自動化工具，官方測試數據顯示比 Ansible 快約六倍。目標主機只需要一個 shell 與 SSH 連線，不需安裝 daemon、不存放狀態檔、也沒有控制平面。v3 要求 Python 3.10 以上，採 MIT 授權，可透過 uv tool install pyinfra 安裝。
原本的問題
Ansible 以 YAML playbook 為核心，條件邏輯與迴圈語法往往夾雜在 Jinja2 模板與 when: 條件中，可讀性隨規模遞減。YAML 本身不是程式語言，缺乏型別系統與模組化抽象，使得複雜的部署流程難以單元測試與維護。Chef 與 Puppet 雖使用真正的程式語言，但需在目標機器上預先安裝代理程式，增加了 bootstrap 成本與攻擊面。pyinfra 的出發點是：部署邏輯本質上是程式碼，應直接用程式語言表達，而非包裝在 DSL 或 YAML 語法糖裡。
採用的方法
pyinfra 的部署腳本就是普通的 Python 檔案，直接呼叫內建操作模組：
from pyinfra.operations import apt, files, systemd
apt.packages(
name="Install nginx",
packages=["nginx"],
update=True,
)
files.template(
name="Upload nginx config",
src="templates/nginx.conf.j2",
dest="/etc/nginx/nginx.conf",
)
systemd.service(
name="Enable and start nginx",
service="nginx",
enabled=True,
running=True,
)所有操作預設具備冪等性——重複執行只會在狀態不符預期時才實際變更，其餘跳過。乾跑模式（--dry）可在正式執行前預覽所有變更。並行執行以 gevent 實作，單次執行可同時處理數千台主機，輸出即時串流至終端。
Inventory 以 Python 資料結構定義，群組、主機變數、條件邏輯均可使用原生 Python 表達，無需學習特定 DSL 語法。自訂操作只需數行 Python，也不需撰寫 Ansible module 的樣板程式碼。pyinfra 可作為函式庫在既有 Python 程式中呼叫，也可與 pytest 結合進行部署邏輯的單元測試。
實際效果
專案目前由超過 180 位貢獻者維護，採用方包括 SAP、EPAM Systems、Lawrence Livermore 國家實驗室等。相較於 Ansible，pyinfra 在並行執行與 SSH 連線管理上的效率優勢使其在需要同時管理大量主機的場景中具備明確優勢。
對於已有 Python 技術棧的團隊，無需引入額外語言或工具生態，學習成本集中在操作模組 API 的熟悉度上。遷移路徑方面，pyinfra 可以逐步引入：現有的 Ansible 任務可先並行運行，待驗證行為一致後再全面切換，整個過程不需要停機窗口或批次遷移。
原始來源：pyinfra.com
Kubernetes SIG Storage 2026 聚焦：Volume Group Snapshot 正式穩定，物件儲存與 AI 工作負載支援持續推進
Kubernetes Blog · 2026-06-15
Kubernetes 官方部落格於 6 月 15 日發布 SIG Storage Spotlight 2026，回顧儲存特別興趣小組過去一年的工作進展。Volume Group Snapshots 在此周期正式升至穩定版（GA），允許同時為多個 volume 建立崩潰一致的群組快照；同時有兩項功能仍在 beta 階段推進：Changed Block Tracking 與 Container Object Storage Interface。
背景
SIG Storage 負責定義 Kubernetes 與底層儲存系統之間的標準介面，使儲存廠商得以自行開發驅動程式，而無需修改 Kubernetes 核心程式碼。核心基礎元件包括 PersistentVolumes（PV）、PersistentVolumeClaims（PVC）與 StorageClasses。Container Storage Interface（CSI）框架是 SIG Storage 推動的主要架構演進，將原本的 in-tree 儲存外掛遷移至 out-of-tree 的獨立驅動模型。目前 SIG 同時維護多個 CSI sidecar：csi-provisioner、csi-attacher、csi-resizer、csi-snapshotter。
核心改動
Volume Group Snapshots 正式進入穩定版，允許同時為一個應用所使用的多個 volume 建立崩潰一致（crash-consistent）的群組快照。這對有狀態應用（如資料庫）的備份場景尤為關鍵，確保跨 volume 的資料快照點相同，避免因快照時間差造成的資料不一致。
Changed Block Tracking（CBT）仍處於 beta，目標是支援增量備份：CBT 僅追蹤自上次快照後發生變更的資料區塊，可顯著降低大型 volume 的備份傳輸量與時間。Container Object Storage Interface（COSI）則將 SIG Storage 的管轄範圍從區塊與檔案儲存延伸至物件儲存，為 Kubernetes workload 提供標準化的 S3 相容物件存取介面，無需在 pod spec 中硬編碼供應商特定端點。
在資料保護方向，SIG Storage 與 SIG Apps 共同贊助的 Data Protection Working Group 持續填補 Kubernetes 原生資料保護機制的空缺。工作重心集中在備份生命週期管理與跨叢集復原流程的標準化，目標是讓備份與還原操作能夠透過 Kubernetes API 描述，而非依賴各 CSI driver 的私有實作。
影響範圍
AI 工作負載對儲存的需求模式與傳統 web 服務不同——訓練任務需要高吞吐量的大規模資料集讀取，推論服務則對延遲敏感。SIG Storage 將 AI 工作負載支援列為 2026 年的重點方向，具體包括評估高效能儲存介面與 GPU 節點的 locality-aware volume 排程。
對於維運團隊，Volume Group Snapshots 升至 GA 意味著可在正式環境中可靠使用群組快照功能，無需顧慮 API 變動風險。CSI sidecar 的持續維護確保現有儲存驅動與新版 Kubernetes 的相容性，升級 Kubernetes 版本時應確認對應的 CSI sidecar 版本相容矩陣。SIG 目前由 Xing Yang（VMware by Broadcom）與 Saad Ali（Google）擔任共同 chair，Michelle Au（Google）與 Jan Šafránek（Red Hat）擔任 tech lead。