2026-08-28 — Kubernetes GPU 資源池化打造 AI 工廠,HCP Vault 稽核日誌接上 Microsoft Sentinel

打造 AI 工廠:用 Kubernetes 把 GPU 資源池化給多團隊共用

CNCF Blog · 2026-08-27

CNCF 於 2026 年 8 月 27 日發布文章,由 vCluster 平台顧問 Hrittik Roy 撰寫,描述所謂「AI 工廠」的架構模式:讓一個團隊做微調(fine-tuning)、另一個團隊跑推論服務、第三個團隊執行評估(evaluation),同時共用同一批昂貴的加速器硬體。文章指出真正的瓶頸是使用率而非模型服務本身——傳統 device plugin 模式常把整顆 GPU 綁死給只用到一成算力的 Pod,造成大量浪費。

排程與資源分配層

解法的核心是 Dynamic Resource Allocation(DRA),已在 Kubernetes 1.34 正式 GA,讓排程器把加速器當成具備屬性與拓撲資訊的「豐富裝置」來配對,而不只是單純計數。搭配 CNCF Incubating 專案 HAMi 強制執行跨廠牌加速器的每個 Pod 記憶體與算力上限,再加上 NVIDIA MIG 提供硬體層級隔離的多執行個體切分。KAI Scheduler 負責拓撲感知的放置決策,Volcano 處理 gang scheduling,Kueue 則管理排隊、准入與配額。

工作負載與租戶隔離

推論層由 vLLM 擔任引擎,KServe(同為 CNCF Incubating)包一層自動擴縮;分散式推論則交給 NVIDIA Dynamo 與 llm-d,Slinky 讓 SLURM 工作負載也能跑在 Kubernetes 上,KubeVirt 補上虛擬機需求。租戶隔離方面,vCluster 為每個租戶提供獨立虛擬控制平面,搭配 Pod Security 原則與 Cilium、Multus、SR-IOV 做網路層隔離,RDMA 則走 RoCEv2 或 InfiniBand。

上線生產環境的門檻

文章強調從展示走向正式生產,需要 NVIDIA AI Cluster Runtime 驗證設定,以及 Kubernetes 1.35+ 才會標準化的 AI Conformance 專案。規模擴大到數百個 GPU 節點、橫跨多個資料中心時,必須靠 GitOps(Flux/Argo CD)與宣告式租戶定義維持單一事實來源,而效能表現則高度依賴 NVLink/NVSwitch 網域、fabric 連接方式與 NUMA 局部性等硬體拓撲細節。

自助式供裝:透過 CRD、Terraform provider 或 GitOps,搭配 OIDC(如 Keycloak)做 RBAC
計量與計費:DCGM 統計 GPU 秒數,交由 OpenCost 依租戶分攤成本
可觀測性:Prometheus、OpenTelemetry 搭配 DCGM exporter 蒐集 GPU 遙測
安全與供應鏈:Kyverno/OPA 做政策管控,Falco 與 Trivy 分別負責執行期與供應鏈掃描

文章也點出一個關鍵抉擇:團隊可以直接採用廠商整合方案(如 NVIDIA 的 DSX OS),或是自行從上述 CNCF 生態系專案組裝出等效能力——兩條路線在維運複雜度與客製彈性之間各有取捨。

原始來源:Building an AI factory on Kubernetes

把 HCP Vault Dedicated 稽核日誌接進 Microsoft Sentinel 的完整管線

HashiCorp Blog · 2026-08-27

HashiCorp 於 2026 年 8 月 27 日發布由 Abhijeet Lokhande 撰寫的文章,說明如何把 HCP Vault Dedicated 的稽核日誌串進 Microsoft Sentinel——這是微軟建構在 Azure 上的雲原生 SIEM(安全資訊與事件管理)暨 SOAR 平台,整合 Microsoft 365、Defender XDR、Azure 與第三方資料來源進行威脅偵測與自動回應。由於 HCP Vault Dedicated 目前沒有原生的 Sentinel 連接器,文章提供的是一條自建的資料管線。

資料流架構

整條路徑是:HCP Vault Dedicated 的 generic HTTP sink → Azure Function App → Azure Monitor Logs Ingestion API → 由 Data Collection Endpoint(DCE)支撐的 Data Collection Rule(DCR) → 自訂 Log Analytics 資料表 HCPVaultAudit_CL → 選擇性接上 Sentinel。兩種接入端點擇一:預設是 Python、Consumption 方案的 Azure Function App,走 bearer token 驗證;若訂閱沒有 App Service worker 配額,則退而求其次用 Azure Logic Apps,改用簽名回呼網址,兩者都靠 Managed Identity 取得 DCR 的 Monitoring Metrics Publisher 角色。

部署與設定步驟

HashiCorp 提供了配套的 Terraform 專案來建立上述 Azure 資源:

git clone https://github.com/abhijeetvlokhande/hvd-sentinel-integration.git
./scripts/preflight.sh "<SUBSCRIPTION_ID>"
./scripts/configure-terraform.sh
terraform -chdir=terraform apply

接著在 HCP 主控台啟用 Generic HTTP Sink,把 URI 設成 Terraform 輸出的 hcp_sink_url,方法固定為 POST、格式為 JSON(非 NDJSON),並關閉 gzip 壓縮——這三項設定是本篇整合成功與否的關鍵細節。

驗證與規則

資料進到 Log Analytics 後,可用以下 KQL 確認事件已寫入:

HCPVaultAudit_CL
| where TimeGenerated > ago(24h)
| summarize Events = count() by path
| order by Events desc

文章附上的起手式 Sentinel 分析規則涵蓋身分驗證活動、機密列舉、敏感路徑存取與非上班時段行為四類偵測情境,且資料表結構支援日後從 rawData 欄位解析出更多欄位而不需異動 schema。此整合僅支援 Vault Dedicated 的 Essentials 與 Standard 兩個方案層級,Development 層級不在支援範圍內。

原始來源:Stream HCP Vault Dedicated audit logs to Microsoft Sentinel

End of article