Kubernetes 运营商生命周期经理（OLM）与掌舵人

运营商生命周期管理器（OLM）与HERM的区别和优势是什么

OLM-

掌舵人

---

据我所知，Helm是Kubernetes的通用软件包经理，其中as OLM是针对运营商的。但是，头盔可以用来部署操作员。那么，对于操作员来说，OLM与Helm有什么不同/更好的地方呢？

嗯，Helm无法自行部署。它只为头盔图表提供原语，您可以在相应地设置基础设施时安装这些原语。为了部署任何东西，您需要某种将所有部分放在一起的管道

---

OLM是一种声明性方法，用于解决某种发布管理问题，您可以在其中定义不同版本的“可部署”并对其进行升级。我还不了解如何将其用于定制服务。据我不久前所知，您只能使用一些预定义的应用程序。还请注意，OLM不会取代头盔。我假设OLM管理的任何“可部署”的东西也可以在一天结束时通过Helm安装。

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

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

好处/区别：

两者都可用于安装/删除/回滚/升级操作员，但OLM提供了一个模型，您可以通过该模型将应用程序部署（想想alpha vs stable）的各种部署操作方法精心设计到不同的可订阅“通道”中。当您在这些“通道”中更新这些方法时，订阅的方法将自动获得根据这些方法升级/安装新版本的能力。OLM中的依赖关系也是以不同的方式处理的，您可以在不同的名称空间中按顺序安装一系列依赖操作符。赫尔姆在这方面有点限制

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