扫码关注微信公众号: 3分钟云计算

Operator生命周期管理（OLM）

该项目是由Red Hat 开发的旨在更加轻松地管理Kubernetes Operator。项目全程为Operator Lifecycle Manager，简称为OLM. 它已经作为技术预览版本在OpenShift 3.11中发布。有兴趣的小伙伴可以去红帽官网查看使用介绍。本文将会阐述它的上游版本的基本介绍，后续会贴出架构实现分析。

官网介绍：https://docs.openshift.com/container-platform/3.11/install_config/installing-operator-framework.html

Operator Lifecycle Manager

该项目是Operator Framework 下的一个组件，一个开源工具包，旨在以有效的，自动化的和可扩展的方式来管理Kubernetes的一种叫做 Operator 的原生应用。了解更多：https://coreos.com/blog/introducing-operator-framework

OLM 扩展了Kubernetes，提供了一种陈述式的方式来安装，管理和升级Operator，以及它在集群中所依赖的资源。

它还对其管理的组件强制执行一些约束，以确保良好的用户体验。

该项目使用户能够执行以下操作：

  • 将应用程序定义为封装了需求和元数据的一个Kubernetes资源

  • 使用依赖项解析方式自动地安装应用程序，或者使用kubectl/oc(OpenShift Client)手动安装应用程序

  • 使用不同的批准策略自动升级应用程序

该项目不会：

  • 替换 Helm

  • 将Kubernetes转变成一种PaaS

安装

请参考Installation guide，将OLM安装在Kubernetes 或者OpenShift 集群中。

一个关于OLM是如何适用于Operator Framework的完整的端到端的示例，请参考Operator Framework Getting Started Guide.

Kubernetes原生应用

Operator 是一种特定于应用程序的控制器。它扩展了Kubernetes API模拟用户的行为方式来创建，配置，管理和操作复杂应用程序的实例。

OLM要求应用程序由Operator管理，但这并不意味着每个应用程序都必须从头开始编写。根据所需的控制级别，您可以:

一旦你为OLM打包了一个应用程序，你可以通过写一个 ClusterServiceVersion 文件用OLM来部署它。

ClusterServiceVersion 可以被收集到CatalogSource，它通过`InstallPlan`解析依赖实现安装的自动化，并且通过`Subscription`保持使用最新版本。

阅读有关 architecture 和 philosophy的内容，了解有关OLM使用的组件的更多信息。

核心概念

用户自定义资源

OLM 通过要求Operator的接口使用Kubernetes API标准化了与Operator的交互。

因为我们希望用户定义其应用程序的接口，所以当前OLM使用CRD来定义Kubernetes API交互。示例：EtcdCluster CRD, EtcdBackup CRD

描述符

OLM在kubernetes API响应中引入了spec和status字段的“描述符”的概念。描述符旨在表示字段的各种属性，以便对其内容做出决定。例如，这可以驱动将两个操作员连接在一起（例如，将连接字符串从mysql实例连接到使用的应用程序），并用于在UI中驱动丰富的交互。

请参阅带有描述符的ClusterServiceVersion示例：https://github.com/operator-framework/operator-lifecycle-manager/blob/master/deploy/chart/catalog_resources/rh-operators/etcdoperator.v0.9.2.clusterserviceversion.yaml

依赖性解析

为了最大限度地减少在kubernetes上运行应用程序所需的工作量，OLM处理运行在OLM上的应用程序的依赖项的发现和解析。

这是通过在应用程序中定义额外的元数据实现的。每一个Operator必须定义：

  • 它负责管理的CRD。例如，Etcd Operator管理EtcdCluster资源

  • 它依赖的CRD。例如，Vault Operator依赖于EtcdCluster，因为Vault 由Etcd支持。

通过查找可以实现基本的依赖解析，同样地，对于每一个所依赖的CRD，它所对应的Operator来安装和管理它。用户与目录交互的方式可以进一步限制依赖性解析。

粒度

依赖性解析是通过CRD的（组，版本，种类）驱动的。这意味着给定CRD（特定组，版本，种类）不会发生更新，除非它们完全向后兼容。

无法表达对特定版本的Operator（例如，etcd-operator v0.9.0）或应用程序实例（例如etcd v3.2.1）的依赖性。这鼓励应用程序的开发者依赖于其接口而不是其实现。

发现，目录与自动升级

OLM具有目录的概念，目录是应用程序定义和CRD的存储库。

目录包含一组包，它将“通道”映射到特定的应用程序定义。通道允许包作者为不同的用户编写不同的升级路径（例如alpha与stable）。

示例：etcd package

用户可以订阅频道，当一个新的版本发布时，可以自动更新其Operator。

以下是一个订阅示例：

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: etcd
  namespace: local 
spec:
  channel: alpha
  name: etcd
  source: rh-operators

当在目录中一个新版本的etcd Operator可用时，它将会使etcd `ClusterServiceVersion` 更新到最新。

用户界面

使用OpenShift管理控制台（与上游Kubernetes兼容）与OLM管理的资源进行可视化交互。创建订阅，批准安装计划，识别Operator管理的资源等。

确保kubectl或者oc指向一个集群并运行：

$ ./scripts/run_console_local.sh

然后访问`http://localhost:9000`以查看控制台。

上一页Operator-SDK简介下一页Operators 介绍

最后更新于