Helm 4 已於最近發佈，為此，Flant 團隊將其與 werf 中開發的替代方案 Nelm 進行了比較。並介紹了 Nelm 與 Helm 4 兩個項目的新功能，詳細説明它們的差異，以及規劃了 Nelm 的未來路線。
Helm 4 給雲原生社區帶來了一系列新功能。最重要的用户層面變化是採用了 Kubernetes 的 Server-Side Apply (SSA)，取代了之前的 3-Way Merge，解決了資源更新錯誤的問題；並引入了基於 kstatus 的資源監控。其他新功能主要致力於減少技術負債。
雖然 SSA 的實現值得單獨發佈，但社區對 Helm 4 的期望更高。最受歡迎的需求包括 Go 模板的替代方案和更好地處理自定義資源定義（CRD）的部署。
Helm 的開發節奏在新版本發佈前加快，但鑑於 Helm 在業界的廣泛使用及嚴格的向後兼容要求，重大架構變更可能會推遲到下一次大版本。
Nelm 與 Helm 4 的區別
Nelm 是 Helm 4 的現代替代品，專注於引入新功能，同時保持對 Helm chart 和發佈的向後兼容。
Nelm 在 werf 內部創建，源於用户對更強大部署能力的需求。後來獨立成項目，可單獨使用（無需 werf）來部署 Helm chart 到 Kubernetes。內部採用了 Helm 代碼庫的一部分，但對部署引擎等複雜部分進行了重寫。
Nelm 早已支持 Server-Side Apply，並且不斷增加用户功能。例如，最近引入了基於 werf.io/delete-policy、werf.io/ownership 和 werf.io/deploy-on 註釋的資源生命週期管理。下面列出 Nelm 與 Helm 4 的主要差異。
1. CRD 部署
Helm 建議將 CRD 放在 chart 的 crds 目錄，但該目錄內資源只在首次安裝時部署，無法更新，且 helm upgrade 會忽略它。
有些用户將 CRD 放在 templates 目錄以當作普通資源部署，但這樣難以維護部署順序，且 CRD 文件大，可能超出 Secret 大小限制。
有些開源 chart 甚至單獨用子 chart 來部署 CRD。
Nelm 只需將 CRD 放入 crds 目錄，Nelm 提供完整的部署機制，CRD 會在每次升級時更新和部署。
2. 部署順序定義
Helm 通常用 hooks 定義部署順序，適合簡單的 Job 在 rollout 前後運行。
但如果 Job 依賴 Deployment，或需要在發佈中途運行，Helm 沒有標準解決方案。
Nelm 在每次發佈前構建操作圖，定義資源的部署順序。並提供 werf.io/deploy-dependency 註釋，設置操作間的依賴關係，確定順序。
示例：
kind: Deployment
metadata:
name: backend
annotations:
werf.io/deploy-dependency-db: state=ready,kind=StatefulSet,name=postgres
表示 backend Deployment 只有在 postgres StatefulSet 創建且就緒後才創建或更新。
該註釋適用於普通資源和 hooks。未來計劃支持對整個 chart 的依賴。
Nelm 還支持 werf.io/weight 註釋，類似於 helm.sh/hook-weight，適用於 hooks 和普通資源。
此外，還有 external-dependency.werf.io/resource 註釋，用於指定 Helm 發佈外的資源依賴，比如 operator 創建的 Secret。
當然，Helm 原生的 hooks 和權重也支持。
3. 資源生命週期
Helm 通過 helm.sh/resource-policy: keep 防止資源刪除，helm.sh/hook-delete-policy 控制 hook 刪除時機。
但如果需要在發佈中間部署不可變 Job，或部署後清理資源，或跨多個發佈管理同一資源，Helm 很難滿足。
Nelm 新增了一套資源生命週期管理註釋：
-
werf.io/delete-policy：類似 helm.sh/hook-delete-policy，支持發佈前重建（before-creation）、遇不可變字段錯誤時重建（before-creation-if-immutable）、發佈成功後刪除（succeeded）、發佈失敗後刪除（failed）。適用於 hooks 和普通資源。
-
werf.io/ownership：讓普通資源具備類似 hooks 的行為，防止應用或校驗發佈註釋，防止資源被刪除（如果從 chart 移除或發佈被刪除）。
-
werf.io/deploy-on：控制資源只在安裝、升級、回滾或卸載時渲染，類似 Helm hooks，但不將資源變成 hook。
這些註釋能模擬 Helm hook 的行為，無需正式聲明 hook。
例如，以下 hook：
metadata:
annotations:
helm.sh/hook: pre-install
helm.sh/hook-delete-policy: before-hook-creation
相當於下面非 hook 資源：
metadata:
annotations:
werf.io/deploy-on: install
werf.io/delete-policy: before-creation
werf.io/ownership: anyone
建議 Nelm 用户儘量避免使用 Helm hooks，這樣簡化 chart、增強資源靈活性、加快發佈速度。但如果要兼容原生 Helm，使用 hooks 仍可接受。
4. 高級資源跟蹤
Helm 3 支持簡單的資源就緒等待。Helm 4 用 kstatus 改進了準確度，但無根本改變。
Nelm 具有自己的高級資源跟蹤系統，相比 Helm 4：
- 檢測資源就緒更準確
- 不僅跟蹤就緒，還能判斷資源是否存在，檢測探針失敗等錯誤
- 支持熱門自定義資源的就緒規則
- 對其他自定義資源用啓發式方法判斷就緒，誤判少
- 部署時在終端實時顯示狀態、錯誤、日誌和事件
無需配置即可使用，支持通過命令行和註釋調優或關閉。
5. 加密 values.yaml 及其他文件
Helm 本身不支持 chart 內的加密文件，這由 helm-secrets 插件提供。
Nelm 原生支持加密 values 文件和 chart secrets 目錄內的任意文件。操作更簡單。
創建密鑰和加密文件示例：
NELM_SECRET_KEY=$(nelm chart secret key create)
nelm chart secret values-file edit secret-values.yaml
然後像普通值一樣使用：
# templates/secret.yaml
kind: Secret
stringData:
mySecret: {{ .Values.mySecretValue }}
nelm release install -n foo -r bar
6. 發佈計劃
Nelm 內置類似 helm diff 的功能。nelm release plan install 命令精確顯示下一次發佈將對集羣資源做的變更。不同於 helm diff，Nelm 計劃基於 Server-Side Apply 更新的資源操作計劃，而非 3-Way Merge。
未來將支持用單命令創建保存計劃（--save-plan），再用另一命令執行（--use-plan），確保操作完全可控。Helm 和 helm diff 目前無法實現此功能。
Nelm 缺少的功能
- 不支持 Helm 3 CLI 插件。它們依賴 Helm CLI 命令結構、選項和日誌渲染，兼容性差。我們計劃在 Nelm 內置實現最受歡迎的插件功能，如 helm diff 和 helm secrets。
- 不支持 post-renderers。計劃推出 Go 模板替代方案，並內置資源 patch 功能，無需外部插件。詳見 issues [#54](javascript:;) 和 [#115](javascript:;)。
- 目前無法與 Argo CD 和 Flux 結合，後續通過 Nelm operator 實現，相關 CR 會通過 Argo CD、Flux 或其它 GitOps 工具部署。
- Helmfile 和 Helmwave 不兼容 Nelm，計劃實現 Nelmfile，方便 CLI 原生支持。Helmwave 項目考慮切換到 Nelm。
Helm 4.0 發佈後 Nelm 的未來
Nelm 是 werf 的部署引擎，werf 已被 20,000+ 項目使用。Nelm 還在積極集成到 Deckhouse Kubernetes Platform 等產品中，發展前景穩固。
Helm 4.0 並未帶來實質變化。憑藉早期對新功能的聚焦，Nelm 功能領先且持續進步。過去一年穩定了 Nelm v1，重構了代碼庫，增加了諸多功能。未來將有兩名全職開發加入，社區活躍度也在提升。
未來規劃
未來半年計劃發佈 Nelm v2，遷移到 Helm 4 代碼庫，發佈 Nelm operator 以支持 Argo CD 和 Flux。明年計劃推出 Go 模板替代方案（現提議用 TypeScript 實現）、chart patch 和直接從 Git 下載 chart。
項目團隊表示，會繼續積極開發 Nelm，就像過去九年支持 werf 一樣。
