Nelm 与 Helm 4 的比较：现有差异与未来规划

helm 4 最近正式发布，借此契机，flant 团队将其与在 werf 中孵化并逐步独立的替代方案 nelm 进行了深度对比。本文详细梳理了 helm 4 与 nelm 各自引入的关键新特性，系统剖析二者在核心能力上的差异，并同步公布了 nelm 的中长期演进路线图。

Helm 4 为云原生生态带来了多项实质性升级。其中最显著的用户体验改进是全面采用 Kubernetes 原生的 Server-Side Apply（SSA）机制，取代沿用多年的 3-Way Merge 策略，从根本上缓解了因合并逻辑导致的资源配置错误；同时集成 kstatus 实现更精准的资源状态观测。其余更新则侧重于技术债清理与架构轻量化。

尽管 SSA 的落地已属重大突破，但社区对 Helm 4 的期待远不止于此。呼声最高的两大需求是：提供 Go 模板之外的模板语言选项，以及增强对自定义资源定义（CRD）全生命周期管理的支持。

Helm 的版本迭代节奏在本次发布前明显提速，但由于其在生产环境中的广泛部署及严苛的向后兼容性承诺，涉及底层架构的重大调整仍可能延至后续主版本。

Nelm 与 Helm 4 的核心差异

Nelm 并非 Helm 的简单复刻，而是面向现代交付场景设计的下一代 Helm 兼容部署引擎——它在保持对 Helm Chart 格式与 Release 行为完全兼容的前提下，聚焦于快速引入前沿功能。

Nelm 起源于 werf 项目内部，最初为满足用户对更精细、更可控部署能力的诉求而开发，后演变为可独立运行的通用工具（无需依赖 werf 运行时）。其底层复用了 Helm 的部分基础模块，但对部署引擎、资源编排、状态跟踪等关键组件进行了彻底重构。

以下是 Nelm 相较 Helm 4 的六大差异化能力：

1. CRD 部署支持

Helm 官方推荐将 CRD 放置在 crds/ 目录下，但该目录内容仅在首次 helm install 时生效，后续 upgrade 操作完全忽略，无法实现 CRD 版本更新。

部分用户转而将 CRD 放入 templates/ 目录作为普通资源渲染，但这会破坏声明式部署语义，难以保障 CRD 必须早于依赖它的资源创建；且大型 CRD 文件易超出 Secret 存储限制。

更有开源 Chart 采用子 Chart 方式单独管理 CRD，进一步增加维护复杂度。

Nelm 则原生支持 crds/ 目录的全周期管理：CRD 不仅会在首次安装时部署，还会在每次 upgrade 或 rollback 时自动比对、更新并应用变更，真正实现 CRD 的声明式演进。

2. 可编程的资源部署顺序

Helm 主要依赖 hooks 实现有限的顺序控制，适用于 rollout 前后执行简单 Job 场景。

但当 Job 依赖 Deployment 就绪、或需在发布流程中途触发特定操作时，Helm 缺乏标准化机制。

Nelm 在每次发布前动态构建“操作图”（Operation Graph），显式建模资源间的依赖关系。通过 werf.io/deploy-dependency 注释，可精确指定某资源必须等待另一资源处于指定状态（如 state=ready,kind=StatefulSet,name=postgres）后才启动部署。

示例：

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）、external-dependency.werf.io/resource（用于声明对 Helm 外部资源如 Operator 创建的 Secret 的依赖）等高级注释。当然，Helm 原生的 hook 机制也完全兼容。

3. 细粒度资源生命周期控制

Helm 仅通过 helm.sh/resource-policy: keep 和 helm.sh/hook-delete-policy 提供基础级资源保留策略，面对“发布中途部署不可变 Job”、“部署后自动清理临时资源”或“跨多次发布共享同一资源”等复杂场景，表达力严重不足。

Nelm 引入三类全新生命周期注释：

Otter.ai

一个自动的会议记录和笔记工具，会议内容生成和实时转录

141

查看详情

1. werf.io/delete-policy：扩展删除时机策略，支持 before-creation（重建前删除）、before-creation-if-immutable（遇不可变字段冲突时重建）、succeeded（发布成功后删除）、failed（发布失败后删除），覆盖 hooks 与普通资源；
2. werf.io/ownership：赋予普通资源类似 hook 的所有权语义，防止因 Chart 移除或 Release 删除而导致资源被意外清理；
3. werf.io/deploy-on：精准控制资源仅在 install/upgrade/rollback/uninstall 等特定阶段渲染，行为类似 hook 但不改变资源本质。

这些注释可组合使用，完整模拟 Helm hook 行为，却无需额外声明 hook 类型。

例如，以下 Helm hook：

metadata:
  annotations:
    helm.sh/hook: pre-install
    helm.sh/hook-delete-policy: before-hook-creation

等价于 Nelm 中的普通资源：

metadata:
  annotations:
    werf.io/deploy-on: install
    werf.io/delete-policy: before-creation
    werf.io/ownership: anyone

强烈建议 Nelm 用户优先采用注释方式替代传统 hook，以提升 Chart 可读性、资源调度灵活性及整体发布效率。若需与原生 Helm 兼容，hook 仍可继续使用。

4. 智能化资源状态跟踪

Helm 3 提供基础就绪等待，Helm 4 借助 kstatus 提升了判断精度，但仍未突破“是否 ready”的二元边界。

Nelm 构建了自主的高级资源跟踪系统，在以下维度显著超越 Helm 4：

• 就绪判定更鲁棒，支持多条件复合校验；
• 不仅识别“就绪”，还能感知“是否存在”、“探针持续失败”、“终态不收敛”等异常；
• 内置主流 CRD（如 Argo Rollouts、Knative Serving）的就绪规则；
• 对未知 CRD 启用启发式就绪推断，误判率大幅降低；
• 发布过程中实时输出终端状态流、错误堆栈、关联日志及事件详情。

开箱即用，亦可通过命令行参数或资源注释进行细粒度调优或禁用。

5. 原生 Chart 加密支持

Helm 本身不内置加密能力，需依赖 helm-secrets 等第三方插件。

Nelm 原生集成加密模块，支持对 values.yaml 及 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 内置 nelm release plan install 命令，可生成下一次发布的精确变更预览——不同于 helm diff 基于 3-Way Merge 的推测，Nelm 计划直接基于 SSA 的真实 apply 操作序列生成，零偏差。

后续将支持 --save-plan 保存计划快照，再通过 --use-plan 精确回放，确保发布过程完全可预测、可审计、可重现。该能力目前 Helm 生态尚无对应方案。

Nelm 当前暂未支持的功能

• Helm 3 CLI 插件兼容性：因插件深度耦合 Helm CLI 结构与日志格式，Nelm 暂不兼容。团队正规划在 Nelm 中原生实现高频插件功能（如 helm diff、helm secrets）。
• Post-renderers：暂不支持外部渲染器。计划内建 TypeScript 模板引擎及资源 Patch 功能，消除对外部工具链依赖（详见 issues #54 和 #115）。
• GitOps 工具集成：当前无法直接对接 Argo CD 或 Flux。将通过 Nelm Operator 提供原生 CRD 支持，使 GitOps 工具可通过标准方式部署和管理 Nelm Release。
• Helmfile / Helmwave 兼容性：现有工具链不兼容 Nelm。团队将推出 Nelmfile 标准格式，并评估 Helmwave 迁移至 Nelm 的可行性。

Helm 4 发布后 Nelm 的战略定位

作为 werf 的核心部署引擎，Nelm 已服务于超 20,000 个生产项目。其稳定性与扩展性获得广泛验证，Deckhouse Kubernetes Platform 等主流发行版也正加速集成。

Helm 4 的发布并未动摇 Nelm 的领先优势。得益于更敏捷的架构决策与功能聚焦，Nelm 在 SSA、CRD 管理、依赖调度、生命周期控制等关键领域已实现功能代差。过去一年，Nelm v1 完成稳定化，代码库完成现代化重构，并持续交付高价值特性。接下来，将新增两名全职工程师投入开发，社区贡献亦稳步增长。

未来半年重点规划

• 发布 Nelm v2：完成向 Helm 4 代码基线的迁移，夯实长期演进基础；
• 推出 Nelm Operator：提供 Argo CD、Flux 等 GitOps 工具的无缝接入能力；
• 启动 TypeScript 模板引擎研发（替代 Go 模板），同步设计 chart patch 机制与原生 Git Chart 拉取支持。

项目团队承诺：将持续高强度投入 Nelm 开发，延续过去九年深耕 werf 的工程信念与社区承诺。

源码地址：点击下载

以上就是Nelm 与 Helm 4 的比较：现有差异与未来规划的详细内容，更多请关注php中文网其它相关文章！