用于声明式管理 Helm 版本的工具
作者：Scott Rigby，Matt Farina
我们经常收到一些人的问题，他们想要工具或方法来管理在环境中的 Helm 版本。这篇文章提供了一些见解和方向来帮助人们开始。
为什么 Helm 没有工具做到这一点
你可能想知道，为什么 Helm 不提供开箱即用的工具来做这件事？
Helm 是一个软件包管理员。我们经常把它比作其他平台的包管理器，比如 apt、yum、zipper、homebrew 等等。所有这些项目，包括 Helm，都将它们的范围保持在包管理的领域内。
管理包的实例如何在环境中运行是一个单独的问题，人们对此有不同的想法。比如有的人用 Ansible，有的人用 Terraform，有的人两者都用，有的人用完全不同的东西。不同的工具甚至可以使用不同的方法（例如，有些是基于推的，有些是基于拉的）。_所有这些都能够与相同的包管理器一起工作_。
Helm 项目致力于提供一个包管理器，它可以很好地与各种其他工具一起工作，这些工具可以使用各种不同的方法来管理版本。
声明式和命令性
在 Kubernetes 领域中，我们讨论声明式管理。如果你不熟悉这个概念，这里有一个简单的解释。
使用声明式管理，你可以向系统声明你想要的最终状态。例如，你希望运行 X 个工作负载实例。然后，系统会努力实现这一点，并且通常会报告将声明的状态变为现实的进度。随着时间的推移，系统使声明的状态成为现实的方式可以改变，而不需要你声明的内容或进度的状态改变。
命令式管理必须一步一步地告诉系统该做什么。你告诉系统实现最终目标的每一步，而不是声明你想要什么。
Kubernetes 提供了一种对资源进行声明式和命令式管理的方法[1]。由于 Kubernetes 社区倾向于使用声明式管理（如果可能的话），这篇文章的剩余部分将集中在可以与 Helm 一起使用的声明式工具上。
工具
Kubernetes 生态系统已经产生了许多不同风格的项目来帮助你声明式地管理你的 Helm 版本。为了说明这些选项，我们将看看 CNCF 里的姐妹项目和一些其他的开源项目。你可以在CNCF Landscape[2]中找到更多的选择。
CNCF 项目
本节的范围仅限于已毕业和孵化[3]的 CNCF 项目。有超过 100 个 CNCF 项目，其中许多是沙箱项目[4]。你可以在成熟度等级解释[5]中了解更多关于项目类型之间的差异。以下项目值得一看：
- Flux Helm Controller[6]——Flux[7]是一个支持 GitOps 的项目集合。其中一个组件提供了一个 GitOps 方法来管理 Helm 版本。Flux 原生支持 Helm。
- Argo CD[8]——Argo[9]项目将自己定义为“为 Kubernetes 提供开源工具来运行工作流、管理集群和正确执行 GitOps。”Argo CD 侧重于声明性持续交付，并且支持 Helm charts。
其他项目
除了 CNCF 项目，还有许多项目可以帮助你管理你的 Helm 版本。以下集合是一个示例，并不详尽。
- Helmfile[10]——一个用于部署 Helm charts 的声明性规范。
- Captain[11]——一个 Helm 控制器。
- Terraform Helm provider[12]——使你能够通过 Terraform 管理 Helm charts。
- Orkestra[13]——基于列表中的其他工具，ork estra 为相关的 Helm 版本组及其 subcharts 添加了一个健壮的依赖关系图，以及一个反向 DAG，用于指定回滚的依赖关系要求。
- Fleet[14]——这是一个 GitOps 工具链，可以与 Kubernetes 清单、Helm charts 和 Kustomize 一起使用。
工具比较
到目前为止，我们所看到的工具之间存在一些差异。下表提供了对它们之间差异的一些见解。这不是详尽的，你应该评估你自己使用的任何工具。
保留 Helm 版本信息 | 支持 Helm hooks | OCI 支持 | 不需要 Helm 二进制 | |
|---|---|---|---|---|
Flux Helm controller | ✅ | ✅ | 🚫1 | ✅ |
Argo CD | 🚫 | ⚠️2 | ✅3 | 🚫 |
Helmfile | ✅ | ⚠️4 | ⚠️5 | 🚫6 |
Captain | ✅ | ✅ | ⚠️7 | ✅ |
Terraform Helm provider | ✅ | ⚠️8 | ✅ | ✅ |
Orkestra | ✅ | ✅ | 🚫9 | ✅ |
Fleet | ✅ | ✅ | 🚫10 | ✅ |
- 因为 Flux 充分利用了 Helm SDK，所以从 Helm v3.8.0 开始，Flux 现在可以添加 OCI 工件集成（Flux 团队成员帮助完成了将 OCI 支持从实验性的变成 Helm 中的完整功能）。RFC-0002[15]现在被标记为可实现的，这方面的工作正在进行中。你可以看这个 fluxcd/source-controller 问题#669[16]了解进度。
- 因为 Argo 不保留 Helm 版本信息，有将 Helm hooks 映射到 ArgoCD hooks 的尝试，但是，Argo hooks 少得多，并且有不可映射的概念，例如安装和升级之间没有区别。你可以通过专门为 ArgoCD 编写 charts 来解决这个问题，但是常用的社区 charts 中的 hooks 将不起作用。
- ArgoCD shells out 到 Helm CLI，生成模板。这使得 Argo 可以在 Helm CLI 的 OCI 功能完成之前打开它，原因与它除了模板化之外不能支持 Helm 功能一样。因此，OCI 不是 ArgoCD 源架构的一部分。
- Helmfile 有一个 hooks 的自定义概念，不一定映射到 Helm hooks。请参阅 readme hooks 部分[17]和这个问题[18]，了解相关说明和工作进展。
- Helmfile 有实验性的 OCI 支持，但没有向用户明确解释它在执行 Helm CLI 之前设置了 HELM_EXPERIMENTAL_OCI=1。参见#2112[19]和#2111[20]。
- Helmfile 参数化 Helm 二进制文件（默认：Helm）。
- Captain 依靠一个相关的项目alauda/oci-chartrepo[21]来混合使用 oci registry 作为 helm chart 仓库。
- Terraform Helm provider 在 Helm hooks 和等待配置方面有一些问题[22]。
- Orkestra 利用 Flux Helm 控制器来协调版本。参见上面关于 Flux Helm 控制器 OCI 状态的说明。一旦 Flux 发布了完整的实现，Orkestra 也将支持 OCI。
- Fleet 使用 Helm SDK。一旦它使用支持 OCI 注册中心的 Helm SDK 版本，Fleet 将继承这种支持。
注意，这个比较是从博文发表的时候开始的。项目会随着时间的推移而变化，功能集也会随着时间的推移而变化。在选择一个项目之前，你应该评估项目的当前状态。
总结
如果你想在 Helm 和 Kubernetes 配置中使用配置管理器，有很多选择。虽然 Helm 项目并不特别建议一个项目胜过另一个项目，但我们确实建议在适当的时候使用配置管理器。
参考资料
[1]
对资源进行声明式和命令式管理的方法: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/
[2]
CNCF Landscape: https://landscape.cncf.io/
[3]
毕业和孵化: https://www.cncf.io/projects/
[4]
沙箱项目: https://www.cncf.io/sandbox-projects/
[5]
成熟度等级解释: https://www.cncf.io/projects/#maturity-levels
[6]
Flux Helm Controller: https://fluxcd.io/docs/components/helm/
[7]
Flux: https://fluxcd.io/
[8]
Argo CD: https://github.com/argoproj/argo-cd
[9]
Argo: https://argoproj.github.io/
[10]
Helmfile: https://github.com/roboll/helmfile
[11]
Captain: https://github.com/alauda/captain
[12]
Terraform Helm provider: https://github.com/hashicorp/terraform-provider-helm
[13]
Orkestra: https://azure.github.io/orkestra/
[14]
Fleet: https://github.com/rancher/fleet
[15]
RFC-0002: https://github.com/fluxcd/flux2/tree/main/rfcs/0002-helm-oci
[16]
#669: https://github.com/fluxcd/source-controller/issues/669
[17]
hooks 部分: https://github.com/roboll/helmfile#hooks
[18]
这个问题: https://github.com/roboll/helmfile/issues/1291
[19]
#2112: https://github.com/roboll/helmfile/issues/2112
[20]
#2111: https://github.com/roboll/helmfile/issues/2111
[21]
alauda/oci-chartrepo: https://github.com/alauda/oci-chartrepo
[22]
问题: https://github.com/hashicorp/terraform-provider-helm/issues/683
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。