运营商生命周期管理器（OLM）与Helm

Question

Opera 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本身是模板化K8清单的集合。它通过呈现这些模板并将它们提供给K8s API服务器，从而仅处理这些应用程序的基本生命周期（安装/删除/回滚/升级）。基于Helm的版本，存在与依赖项管理相关的限制，并且可以在哪个名称空间中创建哪些资源。

如先前的用户所述，

OLM （运营商生命周期管理器）是一个基于声明的系统，旨在支持运营商的安装，该运营商本身负责提供逻辑和说明来管理运营商。应用程序的生命周期（安装/创建/删除/升级）。 OLM是一种管理这些操作员的生命周期和打包的自觉方法。还有一个SDK，可帮助用户从Helm / Ansible / Go创建操作员以适合该系统。它具有各种组件，这些组件通过K8s APIServer相互通信，充分利用CRD和自定义资源来实现这一切。

优点/区别：

两者都可用于安装/删除/回滚/升级操作员，但是OLM提供了一个模型，通过该模型，您可以将应用程序部署的各种部署操作方法（认为alpha与稳定）设计到不同的可订阅“通道”中。在这些“渠道”中更新这些方法时，已订阅的那些方法将自动具有根据这些方法升级/安装较新版本的能力。 OLM中的依赖项也以不同的方式处理，您可以按顺序在各种名称空间中安装一系列依赖的运算符。头盔在这方面受到更多限制。

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

Answer 2

嗯，Helm无法部署自己。它仅提供Helm Charts的原语，您可以在相应设置基础结构时安装原语。为了部署任何东西，您需要某种将所有部分组合在一起的管道。

OLM是一种声明式方法，用于解决某种发布管理，其中您定义了“ deployables”的不同版本，然后对其进行升级。我尚未了解如何将其与定制服务一起使用。据我前一段时间的研究，您只能使用一些预定义的应用程序。另请注意，OML不会替代Helm。我假设OML管理的是“可部署的”，也可以是一天结束时通过Helm安装的东西。