werf.io/deploy-on：控制资本只在安装、进级、回滚或卸载时衬着，类似 Helm hooks，但不将资本变成 hook。
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 会忽视它。
Nelm 还支撑 werf.io/weight 注释，类似于 helm.sh/hook-weight，实用于 hooks 和通俗资本。
有些开源 chart 甚至零丁用子 chart 来安排 CRD。
Nelm 只需将 CRD 放入 crds 目次，Nelm 供给完全的安排机制，CRD 会在每次进级时更新和安排。
2. 安排次序定义
Helm 平日用 hooks 定义安排次序，合适简单的 Job 在 rollout 前后运行。
但假如 Job 依附 Deployment，或须要在宣布半途运行，Helm 没有标准解决筹划。
示例：
kind: Deploymentmetadata: name: backend annotations: werf.io/deploy-dependency-db: state=ready,kind=StatefulSet,name=postgres表示 backend Deployment 只有在 postgres StatefulSet 创建且就绪后才创建或更新。
该注释实用于通俗资本和 hooks。将来筹划支撑对全部 chart 的依附。
此外，还有 external-dependency.werf.io/resource 注释，用于指定 Helm 宣布外的资本依附，比如 operator 创建的 Secret。
当然，Helm 原生的 hooks 和权重也支撑。
有些用户将 CRD 放在 templates 目次以算作通俗资本安排，但如许难以保护安排次序，且 CRD 文件大年夜，可能超出 Secret 大年夜小限制。
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 移除或宣布被删除）。
-
Helm 3 支撑简单的资本就绪等待。Helm 4 用 kstatus 改进了精确度，但无根本改变。
这些注释能模仿 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 仍可接收。
Nelm 在每次宣布前构建操作图，定义资本的安排次序。并供给 werf.io/deploy-dependency 注释，设置操作间的依附关系，肯定次序。
4. 高等资本跟踪
无需设备即可应用，支撑经由过程敕令行和注释调优或封闭。
5. 加密 values.yaml 及其他文件
Nelm 具有本身的高等资本跟踪体系，比拟 Helm 4：
- 检测资本就绪更精确
- 不仅跟踪就绪，还能断定资本是否存在，检测探针掉败等缺点
- 支撑热点自定义资本的就绪规矩
- 对其他自定义资本用启发式办法断定就绪，误判少
- 安排时在终端及时显示状况、缺点、日记和事宜
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.yamlkind: SecretstringData: mySecret: {{ .Values.mySecretValue }}nelm release install -n foo -r bar6. 宣布筹划
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]([removed];) 和 [#115]([removed];)。
- 今朝无法与 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 一样。
发表评论 取消回复