MinIO 專案 2026 年 2 月終止維護，Docker 以 Extended Lifecycle Support 延長 5 年安全修補
Docker Blog · 2026-08-24
原本的問題
開源物件儲存系統 MinIO 已於 2026 年 2 月 13 日被上游封存（archived），此後不再釋出新版本、修補或安全更新。這套系統過去在 Docker Hub 上累積超過 10 億次 pull，代表大量正式環境目前仍在執行一套已停止維護的映像檔。Docker 在部落格中指出，專案一旦進入 EOL，環境會立刻暴露在此後才被揭露的新 CVE 之下，而遷移期限也從「排進 roadmap」變成「被稽核行事曆追著跑」。
企業面對這種情境通常只有兩個選項：倉促遷移可能在還沒驗證妥當前就把正式環境的相依版本換掉，風險不小；申請稽核例外則只是把問題往後延，例外清單只會隨季度增加。兩者都不是長期解法。
採用的方法
Docker 針對這類情境推出 Extended Lifecycle Support（ELS），是 Docker Hardened Images（DHI）之上的付費附加方案，可將安全支援延長至上游 EOL 之後最長 5 年。技術上，ELS 對嚴重（critical）與高風險（high）等級的 CVE 提供 14 天修補 SLA，涵蓋完整的 Go 相依套件圖，包含 transitive dependencies，而不只是最上層的套件本身。
採用方式很直接：團隊只需把 Dockerfile 中的 FROM 行改指向 ELS 標籤的映像檔，映像檔仍出現在標準 DHI catalog 中，不需要更換 registry 或既有工作流程。每個 ELS 映像檔都是從原始碼重新建置並簽署，並附上 SBOM（軟體物料清單）、VEX（弱點可利用性交換）聲明，以及在映像檔生命週期內持續維持的 SLSA Build Level 3 來源證明，讓稽核時可以直接拿出完整證據鏈。
| 項目 | 內容 |
|---|---|
| MinIO 上游 EOL 日期 | 2026-02-13 |
| Critical / High CVE 修補 SLA | 14 天 |
| 最長延伸支援期 | 上游 EOL 後 5 年 |
| 目前已涵蓋的 EOL 映像 | MinIO、Nginx、Node、Python |
目前 DHI catalog 除了新加入的 MinIO，也已涵蓋 Nginx、Node、Python 等常見會遇到 EOL 的映像；找不到現成版本的話，也可以另外向 Docker 提出客製建置需求。
實際效果
ELS 把「趕著遷移」與「申請稽核例外」兩個選項，換成第三條路：在既有版本上持續拿到安全修補，同時把遷移排進正常的 roadmap 節奏，不必被單一 CVE 或稽核截止日綁架。Docker 在文中引用 Black Duck 2026 年報告指出，商業程式碼庫中有 93% 含有兩年以上未見開發活動的元件，顯示 MinIO 只是這類「靜默 EOL」風險裡最新、也最引人注目的一例。
原始來源：Docker Blog
Atlassian 揭露大規模自動化根因分析架構：用訊號、時間、拓樸三維關聯取代人工比對
CNCF Blog · 2026-08-24
原本的問題
Atlassian 團隊在 CNCF 部落格發表文章，說明其內部用於事故處理的自動化根因分析（RCA）系統。在由數百個微服務互相串接的環境中，一次事故往往同時觸發 metrics、logs、traces 三種訊號的大量告警，值班工程師得手動在多個儀表板之間切換比對，才能拼湊出真正的故障源頭。
作者群把這個現象總結成一句話：「人類不該是關聯引擎（Humans shouldn't be correlation engines）」，點出問題核心不在於告警不夠多，而是缺乏系統性的方式把分散的告警串成一條因果鏈。
採用的方法
Atlassian 把 RCA 重新定義為跨三個維度的關聯問題：訊號類型（metrics/logs/traces）、時間（同時發生的異常較可能相關）、拓樸（故障沿著服務依賴邊傳播）。整條流程共分五步，先用 OpenTelemetry 產生的服務依賴圖做拓樸範圍收斂以縮小分析範圍，再針對每種訊號分別偵測異常：metrics 用 median absolute deviation（MAD）與百分位帶偵測 RED（rate/error/duration）訊號，traces 分析結構性異常與延遲違規，logs 則用 embedding 分群找出新型錯誤模式。
每個偵測器輸出統一格式的事件，例如：
{
"timestamp": "2025-07-24T15:24:00Z",
"service": "payment-service",
"signal_type": "metric",
"severity_score": 0.85,
"details": { ... }
}接著系統以可設定的時間窗（約 ±5 分鐘）做時間關聯評分，再用廣度優先搜尋（BFS）沿服務依賴圖做圖形化影響分析，判斷因果方向與故障傳播鏈。最後把時間分數與路徑分數加權合併成總分 S_overall = w1 × S_temporal + w2 × S_path，產出附帶信心分數與白話敘述的候選根因排序列表。文中特別強調「工程師不會只憑一個信心分數就採取行動」，因此每個假設都必須附上可追溯的因果敘事，而不只是一個數字。
實際效果
系統另外用序列指紋（sequence fingerprinting）對重複出現的故障模式去重，透過對有序的服務故障序列計算指紋，避免同一種根因在不同事故中被反覆當成新問題重新分析。系統也保留一個回饋迴路，記錄工程師對每次根因假設的驗證結果，用來調整各訊號與各維度的權重，使排序隨時間變得更準確。
文章沒有揭露具體的準確率、事故量或修復時間改善數字，重點放在「拓樸收斂 → 逐訊號異常偵測 → 時間關聯 → 圖形化影響分析 → 假設產生」這套方法論本身，以及 OpenTelemetry 提供的標準化 trace 如何讓服務依賴圖「白白拿到」，不需要另外建置一套拓樸資料來源。
原始來源：CNCF Blog
Kern：1.52 MB 免常駐服務的容器與虛擬資源執行環境，OCI 容器冷啟動壓到 3.5 毫秒
GitHub (getkern/kern) · 2026-08-25
原本的問題
在 Hacker News 登上首頁的 Kern 是一套鎖定「執行不受信任或 AI 產生程式碼」場景的容器與沙箱執行環境。作者指出，主流方案要嘛像 Docker、Podman 需要常駐 daemon 與可觀的閒置記憶體（Docker 閒置時佔用約 154–160 MB），要嘛像 gVisor、Firecracker 這類方案為了隔離強度犧牲冷啟動速度。
對於「每次呼叫都要開一個全新沙箱」的 AI agent 執行程式碼場景，這兩種取捨都不划算：daemon 常駐吃資源，啟動又不夠快，兩頭都討不到好處。
採用的方法
Kern 用 Rust 寫成單一 1.52 MB 靜態執行檔，只依賴 libc，不需要 daemon、socket 或背景程序，閒置時記憶體佔用為零。它預設一律 rootless（非特權使用者），透過 user／PID／mount／network／UTS／IPC namespace 隔離，執行前丟棄 16 個危險 Linux capabilities，並內建 seccomp allowlist 擋下 35 個逃逸相關 syscalls，被擋下時回傳 ENOSYS。
資源限制交給 cgroup v2，可用 --require-limits 強制要求；--security-profile untrusted 則一次套用針對惡意程式碼的完整強化設定。常用指令包括：
kern box dev --image alpine -it -- sh
kern run --memory 256M --cpus 0.5 -- ./cmd
kern compose stack.toml up
kern doctor資源設定可寫在 ~/.config/kern/kern.toml 中重複使用，涵蓋 vcpu（CPU 與記憶體配額）、vdisk（容量上限的暫存空間）、vgpio（裝置節點層級的曝露）三類 profile，可同時套用在沙箱與一般 host 行程上。上層另提供 kern-sandbox Python／Node SDK，預設每次呼叫都在全新沙箱中執行，逾時、OOM、被擋下的 syscall 會以資料形式回傳而非丟例外；還有 kern-mcp MCP server，讓 Claude Desktop、Cursor 等 MCP client 可直接呼叫 run_code、write_file 等工具在隔離沙箱中執行程式碼。
實際效果
專案自行公佈的效能對照如下：
| 執行環境 | 冷啟動（bare） | 200 個並行沙箱 | 需要 daemon | 預設 rootless |
|---|---|---|---|---|
| Kern | ~2.3 ms | ~0.11 s | 否 | 是 |
| bubblewrap | ~2.3 ms | ~0.16 s | 否 | 是 |
| runc | ~18.6 ms | ~0.35 s | 是 | 否 |
| Podman | ~293 ms | ~44.8 s | 否 | 否 |
| Docker | ~297 ms | ~16.2 s | 是 | 否 |
完整 OCI 容器（含 image pull）啟動約需 3.5 毫秒。目前版本為首次公開釋出的 v0.7.0，採 Apache-2.0 授權，測試涵蓋 840 項 Rust 測試、78 項 Python、61 項 Node，並已在 Linux、WSL2、Raspberry Pi、Jetson 與 Arduino UNO Q 上驗證可執行。
專案也坦言非特權 user namespace 隔離仍可能受核心層級的權限升級漏洞影響，不宣稱等同硬體層級的隔離；完整威脅模型與邊界記錄在 SECURITY.md 與 OPEN_ITEMS.md 中。release tag 皆經 GPG 簽署，但一般 commit 未簽署，安裝時建議透過 SHA256 校驗release binary 或以 cargo install 從原始碼建置。