kubernetes - 运算符(operator)生命周期管理器 (OLM) 与 Helm

Question

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

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

掌 Helm - https://helm.sh/

我知道 Helm 是 Kubernetes 的通用包管理器，而 OLM 是特定于运算符(operator)的。但是，Helm 可用于部署运算符(operator)。那么，对于运营商来说，OLM 与 Helm 有何不同/更好？

Answer 1

Helm 提供了通过 Helm Charts 将应用程序安装到 Kubernetes 的能力，Helm Charts 本身是模板化的 K8s list 的集合。它通过渲染这些模板并将它们提供给 K8s API 服务器来处理这些应用程序的基本生命周期(安装/删除/回滚/升级)。基于 Helm 的版本，在依赖管理以及可以在哪些命名空间中创建哪些资源方面存在限制。
OLM (Operator Lifecycle Manager)，正如前面用户提到的，是一个基于声明的系统，旨在支持 Operator 的安装，Operator 本身负责提供逻辑和指令来管理应用程序的生命周期(安装/创建/删除/升级)。 OLM 是管理这些 Operator 的生命周期和打包的一种固执的方法。还有一个 SDK 可以帮助用户从 Helm/Ansible/Go 创建 Operators 以适应这个系统。它具有通过 K8s APIServer 相互通信的各种组件，大量利用 CRD 和自定义资源来实现这一切。
优点/差异:
两者都可用于安装/删除/回滚/升级 Operator，但 OLM 提供了一个模型，您可以通过该模型将应用程序部署(考虑 alpha 与稳定)的各种部署操作方法制作到不同的可订阅“ channel ”中。当您在这些“ channel ”中更新这些方法时，订阅者将自动获得根据这些方法升级/安装更新版本的能力。 OLM 中的依赖项也以不同的方式处理，您可以在各种命名空间中按顺序安装一系列依赖项。 Helm 在这方面受到更多限制。
最后，OLM 假设您的容器镜像是可公开访问的，并且它们在 list 中的使用内置于容器(CatalogSource、Operators 等)中，而 Helm 图表更容易使用各种基于 Helm 的 CLI 命令(或第三方工具)进行修改以覆盖创建前的模板值。