Operator Lifecycle Manager (OLM) 与 Helm

Question

Operator Lifecycle Manager (OLM) 与 Helm 的区别和优势是什么？

OLM - https://github.com/operator-framework/operator-lifecycle-manager

头盔 - https://helm.sh/

据我所知，Helm 是 Kubernetes 的通用包管理器，而 OLM 是特定于操作员的。但是，Helm 可以用来部署操作员。那么，对于操作员而言，OLM 与 Helm 有何不同/更好？

Answer 1

Helm提供了通过 Helm Charts 将应用程序安装到 Kubernetes 上的能力，Helm Charts 本身就是模板化 K8s 清单的集合。它通过渲染这些模板并将其提供给 K8s API 服务器来仅处理这些应用程序的基本生命周期（安装/删除/回滚/升级）。根据 Helm 的版本，存在与依赖项管理以及可以在哪些命名空间中创建哪些资源相关的限制。

正如前面的用户提到的， OLM（Operator Lifecycle Manager）是一个基于声明的系统，旨在支持 Operator 的安装，Operator 本身负责提供逻辑和指令来管理应用程序的生命周期（安装/创建/删除） /升级）。OLM 是一种管理这些 Operator 的生命周期和打包的固执己见的方法。还有一个 SDK 可以帮助用户从 Helm/Ansible/Go 创建 Operator，以适应该系统。它具有通过 K8s APIServer 相互通信的各种组件，大量利用 CRD 和自定义资源来实现这一切。

优点/差异：

两者都可用于安装/删除/回滚/升级 Operator，但 OLM 提供了一个模型，您可以通过该模型将应用程序部署（考虑 alpha 与稳定）的各种部署操作方法设计到不同的可订阅“通道”中。当您更新这些“渠道”中的方法时，订阅的人会自动获得根据这些方法升级/安装更新版本的能力。OLM 中的依赖关系也以不同的方式处理，您可以在不同的命名空间中按顺序安装一系列依赖的 Operator。Helm 在这方面受到更多限制。

最后，OLM 假设您的容器映像是可公开访问的，并且它们在清单中的使用内置于容器中（CatalogSource、Operators 等），而 Helm 图表更容易使用各种基于 Helm 的 CLI 命令（或第 3 方工具）进行修改来覆盖创建之前的模板值。