Kubernetes Security Profiles Operator 正式發布 v1.0.0，八項 CRD API 全面升級穩定
CNCF Blog · 2026-06-26
背景
Security Profiles Operator（SPO）是 Kubernetes SIG 維護的叢集附加元件，讓管理員以宣告式 Custom Resource 的方式管理 Linux 核心安全機制——seccomp、SELinux 與 AppArmor——而無需手動維護各節點上的 profile 檔案。歷經六年開發，v1.0.0 於 2026 年 6 月正式發布，是該專案首個穩定版本，作者為 Red Hat 的 Sascha Grunert。
在此之前，SPO 的所有 CRD API 均處於 v1alpha1、v1alpha2 或 v1beta1 狀態，其中 SeccompProfile 在 v1beta1 已穩定運行超過四年。API 不穩定性是阻礙大規模生產採用的最主要障礙之一，此次畢業解決了長期懸而未決的問題。
核心改動
v1.0.0 將全部八個 CRD API 升至 v1，並加入轉換 webhook 提供零停機遷移路徑——舊版 API 請求會透明地轉換為 v1 格式儲存，現有資源無需同步刪除重建。API 結構本身也進行了多項修正：
- 無號整數改為有號整數，符合 Kubernetes API 慣例
- enum 值統一採用 PascalCase（
logs→Logs、RUNNING→Running） - 布林欄位改為指標類型，支援三態語意（true / false / unset）
- SPOD spec 欄位重組為子結構，
SecurityProfileNodeStatus欄位移至 Spec/Status 分區 AppArmorProfile新增至 ProfileBinding 的可接受 kinds- 所有欄位補全
+optional或+required標記與驗證 marker
規格細節
v1.0.0 發布前，SPO 接受了第三方安全稽核，審計結果為零個嚴重漏洞。稽核確認寫入主機的檔案路徑來自物件 metadata 而非使用者可控的 spec 欄位，CLI 指令以引數陣列形式組建，無 shell 注入攻擊面，且預設 RBAC 不向非管理員使用者授予多餘權限。
根據稽核發現，v1.0.0 新增了下列防護措施：
- 新增
enableRawSelinuxProfiles欄位至 SPOD 設定，允許叢集管理員完全關閉原始 SELinux CIL policy 支援 - ValidatingAdmissionWebhook 在協調前拒絕無效的原始 policy，取代原先讓錯誤在 reconciliation 階段才浮現的行為
- AppArmor 模板參數透過嚴格正則表達式進行輸入驗證，防範 ReDoS 攻擊
- 原始 policy 大小上限設定為 500 KB，eBPF 錄製器加入路徑長度與檔案數量上限以防止 OOM
此版本同步推出 spoc CLI 工具，提供 amd64、arm64 及 ppc64le 架構的二進位檔。對應的 Kubernetes Enhancement Proposal 為 KEP-6061，預期部分功能將進入 Kubernetes 上游。
影響範圍
從 v1beta1 升級的使用者需參考官方遷移指南（doc/migration-guide-v1.md），其中涵蓋欄位重組與類型變更的對應說明。轉換 webhook 可自動處理 API 版本差異，但管理員仍需確認叢集中的自動化工具與 CI/CD pipeline 已更新至使用 v1 API。新安裝者可直接透過 OperatorHub 取得 v1.0.0。
原始來源：CNCF Blog — Security Profiles Operator v1、GitHub Releases
Jaeger v2.18.0 整合 ClickHouse 後端：一千萬筆 span 壓縮率達 8.6 倍
CNCF Blog · 2026-06-23
原本的問題
Jaeger 是 CNCF 旗下的分散式追蹤平台，長期以 Elasticsearch、Cassandra 等通用資料庫作為後端儲存。這些行導向（row-oriented）資料庫對追蹤資料中高度重複的欄位（服務名稱、操作名稱、狀態碼）壓縮效益有限，且執行服務效能監控（SPM）聚合查詢時吞吐量不足。
Jaeger v2.18.0 在 Meta 工程師 Mahad Zaryab 主導下，新增 ClickHouse 作為實驗性後端。ClickHouse 的列導向（columnar）儲存引擎天然適合重複性高的追蹤資料，並可直接在 span 資料上執行 SPM 聚合，毋需額外部署指標管線。
採用的方法
設計決策記錄於 ADR-008（docs/adr/008-clickhouse-storage-schema.md）。方案以單一 spans 表為唯一寫入目標，衍生表全部由 materialized view 自動維護，包含 services、operations、trace_id_timestamps、attribute_metadata 與 dependencies 五張派生表。
主索引鍵排序順序選擇 (service_name, name, toDateTime(start_time))，以搜尋查詢為優先——Jaeger 最主要的互動是「依服務與操作名稱搜尋 span」，此設計讓搜尋成為直接主鍵查詢。代價是依 trace ID 取回完整 trace 的速度略慢，改以 Bloom filter 索引跳過不相關 granule 補償。資料表按 toDate(start_time) 進行每日分區，支援時間範圍查詢的 partition pruning。
屬性（attributes）採用 Nested 欄位按類型分欄儲存，取代 Map 類型或平行陣列：
bool_attributes Nested(key String, value Bool)int_attributes Nested(key String, value Int64)double_attributes Nested(key String, value Float64)str_attributes Nested(key String, value String)complex_attributes Nested(key String, value String)（用於 Bytes、Slice、Map）
Nested 欄位在壓縮率與過濾效能上均優於 Map 類型，且型別語意更清晰。另有 attribute_metadata 表記錄每個 (attribute_key, type, level) 三元組，讓 UI 搜尋查詢能快速解析屬性類型而不需全表掃描。
實際效果
在一千萬筆 span 的基準測試中，spans 表資料量從 6 GiB 壓縮至約 722 MiB，壓縮率達 8.6 倍。索引配置如下：
| 欄位 | 索引類型 | 用途 |
|---|---|---|
trace_id | bloom_filter（granularity 1） | 高基數 trace ID 針查 |
duration | minmax（granularity 1） | 持續時間範圍過濾 |
查詢延遲方面，trace 取回約 100 ms，多數搜尋查詢低於 50 ms，複雜過濾查詢約 140 ms；寫入吞吐量可達每秒 50,000+ 筆 span。快速啟動方式：
docker compose -f docker-compose/clickhouse/docker-compose.yml up -d
go run ./cmd/jaeger \
--config cmd/jaeger/config-clickhouse.yaml \
--feature-gates=storage.clickhouse目前 ClickHouse 後端標記為實驗性（experimental），需明確啟用 feature gate，支援 ClickHouse 25.x，schema 在未來版本仍可能出現 breaking change。