引言
Helm 作為 Kubernetes 生態系中最重要的包管理工具，自 2015 年推出後持續推動雲原生應用的部署與管理。隨著 Kubernetes 生態系快速演進，Helm 3 在 2018 年發佈後逐漸暴露出與現代化需求的落差。為應對這些挑戰，Helm 4 的開發自 2022 年 KubeCon 鹽湖城會議啟動，並預計於 QCon Atlanta 發佈。本文將深入解析 Helm 4 的技術更新重點、核心特性與實踐方向。
主要內容
技術定義與基本概念
Helm 是 Kubernetes 的包管理工具，透過 Charts（圖表）封裝應用配置，簡化複雜的資源部署流程。Helm 4 繼承 Helm 3 的核心架構，並針對 Kubernetes 生態系的演進進行重大更新，包括 API 支援、CLI 設計、Charts 格式與安全性等領域。
重要特性與功能
1. 破壞性更新與版本策略
- API 支援淘汰：移除對 Kubernetes 1.15 及 OCI 資源庫 V1 的支援，強制升級至 V2。
- Charts v3 實驗性更新：與 Helm 4 同步開發，提供可插拔渲染引擎、CRD 管理改進、資源排序機制與狀態檢查升級。
- 版本兼容性：Helm 4 將保留 Charts v2 支援，但 v3 作為實驗性版本，需社區反饋後逐步穩定。
2. CLI 與日誌系統改進
- 結構化日誌：遷移至 slog 包，支援結構化日誌輸出與錯誤訊息解析，同時保留與 Kubernetes log API 的兼容性。
- 模組化命令：K3s 等工具內建 Helm 命令模組，提升 CLI 的靈活性與可擴展性。
3. Charts v3 核心改進
- 可插拔渲染引擎：支援替換現有渲染引擎（如 gopl），圖表內可嵌入自定義引擎，提升靈活性。
- CRD 管理優化：解決不同命名空間安裝衝突、版本回滾導致的依賴衝突問題，新增資源排序機制。
- 狀態檢查升級：整合 K status 工具，提供智能狀態追蹤與權重管理。
4. OCI 註冊表整合
- 標準化配置：借鑒容器鏡像管理經驗，使用
registries.com 標準化 OCI 資源庫配置，支援鏡像、代理與鏡像功能。
- 社區協作：與容器引擎社區合作，推動 OCI 索引標準化方案，解決現有 OCI 版本缺乏標準化索引機制的問題。
5. 安全性與加密庫更新
- 現代加密標準：汰換舊版 Go 加密庫，支援 EDDSA 等現代加密標準，並計畫移除不支援現代簽名標準的舊庫。
- 簽名功能強化：支援 cosign 與 sigstore 工具，取代傳統 PGP/GPG 簽名方式。
6. 插件系統強化
- 擴展性設計：提升插件功能，支援自訂過濾器（如 Go Template 模板過濾器）與 WebAssembly 支援，允許不同語言/架構執行插件。
- 未來方向：探索更靈活的插件架構，可能影響 Helm 5 版本的設計。
實際應用案例
- CRD 管理優化：在多命名空間部署應用時，Helm 4 的 CRD 管理改進可避免版本衝突，確保應用穩定性。
- OCI 註冊表整合：企業可透過標準化 OCI 資源庫配置，簡化 Helm 圖表與容器鏡像的協同管理。
- 安全性提升：透過現代加密標準與簽名工具，提升 Helm 圖表的存取控制與資料完整性。
優勢與挑戰
優勢：
- 提升 CLI 與 Charts 的靈活性與可擴展性。
- 強化安全性與加密標準，符合現代雲原生需求。
- 支援 OCI 註冊表整合，促進與容器生態系的協同。
挑戰：
- Charts v3 需社區持續反饋，可能影響 Helm 4 的穩定性。
- OCI 索引標準化需與社區協議，短期內難以完全解決。
- 破壞性更新可能導致 SDK 使用者需進行遷移與調整。
總結
Helm 4 透過重大更新，強化了 CLI 設計、Charts 格式、安全性與 OCI 整合，為 Kubernetes 生態系的現代化需求提供更強大的工具支持。開發者應關注 Charts v3 的實驗性功能與 OCI 標準化進展，並透過社群協作推動 Helm 4 的穩定與擴展。未來，Helm 4 的版本策略與社區參與將持續影響其在雲原生領域的應用深度與廣度。