Operator Lifecycle Manager (OLM) 与 Helm 的区别和优势是什么？
OLM - https://github.com/operator-framework/operator-lifecycle-manager
头盔 - https://helm.sh/
我知道 Helm 是 Kubernetes 的通用包管理器，而 OLM 是特定于操作员的。但是，Helm 可用于部署运营商。那么，对于运营商而言，OLM 与 Helm 有何不同/更好？
1422 次
2 回答
8
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 的 CLI 命令（或第 3 方工具）覆盖 Helm 图表更容易修改创建之前的模板值。
于 2020-05-12T16:22:22.997 回答
0
好吧，Helm 无法自行部署。它仅提供 Helm Charts 的原语，您可以在相应地设置基础设施时安装它们。为了部署任何东西，您需要某种将所有部分组合在一起的管道。
OLM 是一种解决某种发布管理的声明性方法，您可以在其中定义不同版本的“可部署”，然后对其进行升级。我尚未了解如何将其与自定义服务一起使用。据我前段时间挖掘，您只能使用一些预定义的应用程序。另请注意，OLM 不会取代 Helm。我假设任何“可部署”OLM 管理的东西也可以是在一天结束时通过 Helm 安装的东西。
于 2019-06-27T12:02:24.680 回答