OTel 與 Service Mesh 指標整合：2026 實戰參考指南
CNCF Blog · 2026-06-29
CNCF 於 2026 年 6 月 29 日發布了一份以 K3s v1.34.6 與 Linkerd 2.19+ 為基礎的可觀測性參考架構，示範如何將 Service Mesh 的代理層指標透過 OpenTelemetry Collector 收集後，與應用層 OTel 語意合併輸出至 VictoriaMetrics 與 Grafana。實驗環境採用 OTel Demo（Astronomy Shop），搭配 OTel Collector Contrib 0.118.0，完整展現從 Linkerd proxy 埠口 4191 到監控後端的資料流。
Mesh 代理指標的來源與語意
Linkerd 的 sidecar proxy（linkerd-proxy）透過埠口 4191 暴露 Prometheus 格式的指標，其中最關鍵的是 response_total 與 response_latency_ms，分別記錄 HTTP 回應次數與延遲直方圖。這些指標天生攜帶 client_id（mTLS 識別身份）、direction（inbound/outbound）及 tls 等 Mesh 專屬標籤，是純 OTel instrumentation 難以取得的東西。TCP 層則有 tcp_open_connections、tcp_read_bytes_total、tcp_write_bytes_total 三個計數器，提供東西向流量的 L7 可視度。
原始 scrape 會帶出大量非必要指標。單一 30 個 Pod 的叢集在過濾後仍有約 9,280 條序列；若不過濾，cardinality 將急速膨脹。文章建議以 OTTL 表達式做精準篩選，只保留五個指標系列：
filter/mesh:
metrics:
metric:
- >-
not(name == "response_total"
or IsMatch(name, "response_latency_ms.*")
or name == "tcp_open_connections"
or name == "tcp_read_bytes_total"
or name == "tcp_write_bytes_total")這個過濾器將原本 163 個指標名稱縮減至 11 個，大幅降低後端儲存壓力。IsMatch 以正規表達式匹配直方圖 bucket、count、sum 三個衍生系列，確保直方圖完整性不受破壞。
Collector Pipeline 的分層設計
完整 Pipeline 分為接收、處理、輸出三階段。接收端使用 prometheus/mesh receiver 搭配 Kubernetes pod discovery，以 linkerd-proxy 為容器名稱條件，每 30 秒 scrape 一次埠口 4191。處理階段最關鍵的是 resource/mesh processor，它在所有序列上插入 layer=mesh 屬性，讓下游查詢可以直接以此標籤區分 Mesh 指標與應用層 OTel 指標。
完整的 processors 鏈如下：
filter/mesh：OTTL 過濾，保留五個核心指標系列resource/mesh：插入layer=mesh識別標籤k8sattributes：注入 pod、namespace、deployment、node 等 Kubernetes 後設資料resourcedetection：補充基礎設施層的資源資訊batch：批次輸出以提升吞吐
版本釘選是一個值得注意的操作細節：replacement: $1:4191 的 relabel 規則在部分舊版 Collector 中會被誤解析為環境變數展開，因此建議鎖定映像標籤至 0.118.0 或更新版本。OTel 提供應用層語意，Mesh 提供 mTLS 身份驗證與東西向 L7 可視度，兩層互補而非重複。
原始來源：CNCF Blog — OTel and Mesh-Derived Metrics: A 2026 Reference
etcd-operator 加入 Cozystack，全新 v1alpha2 API 重寫上線
CNCF Blog · 2026-06-29
etcd-operator 專案於 2026 年 6 月正式從 Ænix 移交至 Cozystack 社群，同時釋出以 Apache 2.0 授權從頭重寫的 v1alpha2 API，完全脫離原先基於 StatefulSet 的架構，改以 etcd 原生 Membership API 直接驅動叢集成員管理。此次移交源於 Ænix 早先嘗試捐贈 CNCF 的過程中，etcd 社群另行啟動了官方 operator，促使 Cozystack 走向獨立發展路線。
API Group 更名與架構轉型
API 群組從 etcd.aenix.io/v1alpha1 更名為 etcd-operator.cozystack.io/v1alpha2，同時引入兩個核心資源取代舊有的 StatefulSet 驅動模型。EtcdCluster 定義期望狀態（副本數、版本、儲存、TLS、認證），而 EtcdMember 則是 operator 為每個成員自動建立的資源，各自擁有獨立的 Pod 與 PVC。這種一對一對應設計讓 operator 可以直接呼叫 MemberAdd、MemberPromote、MemberRemove 等 etcd 原生操作，繞過 StatefulSet 的抽象層限制。
v1alpha2 同步引進多項 API 細節改進。原本自由格式的 spec.options 對映被結構化型別參數取代，涵蓋 quota-backend-bytes、自動壓縮設定及快照計數等欄位。備份資源 EtcdBackup 更名為 EtcdSnapshot，語意更精確；驗證邏輯也從 Webhook 全面移至 CRD 內建的 CEL 規則，消除對外部 Webhook 的依賴，降低多租戶環境下的操作複雜度。
進階功能：縮容至零與無中斷遷移
相較於官方 etcd operator，Cozystack 實作額外提供數項多租戶場景驅動的功能。縮容至零（zero replicas）可暫停整個叢集並保留所有成員身份資訊，恢復時不需重新初始化；記憶體後端儲存（tmpfs）則適合測試場景，避免不必要的磁碟 I/O。系統自動生成 PodDisruptionBudget 以防止 quorum 喪失，並支援 /scale 子資源，相容 kubectl 與 VerticalPodAutoscaler。
對於已存在的叢集，etcd-migrate 工具可在不搬移資料、不重啟 Pod、不影響 quorum 的前提下完成就地遷移。TLS 憑證管理透過 cert-manager 整合，客戶端與 peer 之間的連線各自獨立設定；S3 與 PVC 皆支援作為快照目標。kubectl-etcd 外掛進一步簡化日常運維任務，讓操作者無須直接操作 etcdctl 命令列。
原始來源：CNCF Blog — etcd-operator Joins Cozystack with a New v1alpha2 API
Spindle 推出 MicroVM 執行引擎，CI 工作流程獲得完整隔離環境
Tangled Blog · 2026-06-29
Tangled 平台的 CI/CD 工作流程引擎 Spindle 於近期發布了全新的 MicroVM 執行引擎，讓每個工作流程在獨立的輕量虛擬機器中執行，徹底取代原有的容器隔離模型。新引擎基於 QEMU，但刻意移除 BIOS、PCI 匯流排探測、模擬顯示卡等傳統元件，僅保留 virtio 裝置以實現快速開機與最小記憶體佔用。
Agent 通訊模型與映像類型
Spindle MicroVM 放棄 SSH 連線，改採以 vsock 為底層的 Agent 架構。客機端執行以 Rust 撰寫的 shuttle agent，開機後主動透過 vsock 回撥宿主機，接收工作流程步驟訊息並逐一執行。宿主機側的對應元件位於 spindle/engines/microvm/agent.go，兩端共同實作 agentproto 協定規範。這個設計讓任何符合協定的客製化 agent 都能接入，不受 SSH 金鑰管理與防火牆規則限制。
映像分為兩類。NixOS 映像允許直接在工作流程 YAML 中宣告完整的機器設定：
engine: microvm
image: nixos
dependencies:
- go
- github:nixos/nixpkgs#hello
services:
postgresql:
enable: true
ensureDatabases: ["spindle-workflow"]
ensureUsers:
- name: spindle-workflow
ensureDBOwnership: true
virtualisation:
docker: true非 NixOS 映像目前以 Alpine 為基底，不支援工作流程層級的 NixOS 設定，但若映像內已預裝 Nix，仍可存取 Spindle 的 Nix 快取。這種雙軌設計讓使用者在靈活性與映像精簡度之間自行取捨。
快取策略與網路隔離
Spindle 建置了雙代理 Nix 快取機制來壓縮重複建置成本。讀取代理同時向多個 substituter 與工作流程指定的快取並行查詢，上傳代理則在工作流程執行期間非同步將建置產物推送至 Spindle 快取，避免阻塞後續步驟。一旦依賴項目被快取，後續所有需要相同衍生物的工作流程皆可直接跳過重新建置。
網路隔離以命名空間堆疊實現：VM 在獨立的使用者、網路、掛載命名空間中執行，QEMU 本身也在此隔離命名空間內運行，完全無法直接存取宿主機網路。客機流量經過 guest → QEMU slirp → 命名空間的 slirp4netns 兩層轉發才抵達外部網路。DNS 解析由宿主機側透過 vsock 代理，並過濾私有與特殊用途位址，防止客機探測內部基礎設施。資源排程器採用保守式（work-conserving）演算法搭配老化與每用戶公平性機制，在 VM 開機前就完成 vCPU、記憶體、磁碟的分配，並可選擇以 cgroup 強制執行記憶體與 swap 上限，OOM kill 事件會以明確標記回報而非泛化的崩潰錯誤。