概述

Operator是OpenShift Container Platform（OCP）中最重要的组件之一。Operator是control plane上打包、部署和管理服务的首选方法。它们还可为用户运行的应用提供优势。

Operator集成了Kubernetes API和CLI工具（比如 kubectl 和 oc 命令）。它们提供方法来监控应用、执行健康检查、管理无线（over-the-air，OTA）更新，并确保应用保持在指定状态。

虽然遵循类似的Operator概念和目标，但OCP中的Operator取决于其用途，可被两个不同的系统管理：

• 集群Operator，由Cluster Version Operator（CVO）管理，被默认安装，用来执行集群功能。
• 可选的附加Operator，由Operator Lifecycle Manager（OLM）管理，供用户在其应用程序中运行。

通过Operator，可以创建应用来监控集群中运行的服务。Operator是专为应用而设计的。Operator实现并自动化了常见的“第1天操作”（比如安装和配置）以及“第2天操作”（如自动缩放和缩减并创建备份）。这些活动都处于一个在集群里运行的软件中。

了解Operator

什么是Operator

概念上，Operator把人工的操作知识编码为软件，这样更容易给消费者共享。

Operator是一组软件，用于降低运行其它软件的操作复杂性。它是软件厂商的工程团队的扩展，可以监控Kubernetes环境（比如OCP），并根据当前状态实时做出决策。Advanced Operator被设计为用来无缝地处理升级过程，自动对失败做出反应，而且不会采取“捷径”（比如为了节省时间而跳过软件备份过程）。

从技术上讲，Operator是一种打包、部署和管理Kubernetes应用的方法。

Kubernetes应用可在Kubernetes上部署，也可使用Kubernetes API和 kubectl / oc 工具来管理。要充分利用Kubernetes，需要一组结合的API来扩展，以便服务和管理Kubernetes上运行的应用。可把Operator看作管理Kubernetes中这类应用的运行时。

为何使用Operator

Operator提供一下功能：

• 安装和升级的可重复性。
• 对每个系统组件的持续健康检查。
• 无线（Over-the-air，OTA）更新OpenShift组件和ISV内容。
• 封装领域工程师的知识，并传播给所有用户，而非一两个。

为何在Kubernetes上部署？Kubernetes（扩展至OCP）包含构建复杂分布式系统所需的所有原语（primitive），包括secret处理、负载均衡、service发现、自动扩展。它们可跨on-premise和云提供商工作。

为何使用Kubernetes API和 kubectl 工具来管理应用？这些API功能丰富，针对所有平台均有客户端，并可插入到集群的访问控制/审计中。Operator使用Kubernetes扩展机制，定制资源定义（Custom Resource Definition，CRD），所以定制对象，比如 MongoDB ，其外观和行为就像内建的、原生的Kubernetes对象。

Operator与Service Broker比较？
服务代理（service broker）是实现应用的编程发现和部署的一步。但它并非一个长时间运行的进程，所以无法执行“第2天操作”，如升级、故障转移、扩展。它在安装时对可调性（tunable）提供定制化和参数化，而Operator则持续监控集群的当前状态。非集群的服务非常适合于service broker，不过也有适合它们的Operator。

Operator Framework

Operator Framework是基于上述客户体验提供的一套工具和能力。不仅仅是编写代码，测试、交付和更新Operator也同样重要。Operator Framework组件包含了解决这些问题的开源工具：

Operator SDK：Operator SDK辅助Operator作者基于其自身专长，来启动、构建、测试和打包其Operator，而无需了解Kubernetes API复杂性知识。

Operator Lifecycle Manager（OLM）：OLM控制Operator的安装、升级和基于角色的访问控制（role-based access control，RBAC）。它默认部署在OpenShift Container Platform 4.14中。

Operator Registry：Operator Registry存储Cluster Service Version（CSV）和Custom Resource Definition（CRD）以便在集群中创建，并存储有关包和频道的Operator元数据。它运行在Kubernetes或OpenShift集群中，向OLM提供这些Operator目录数据。

OperatorHub：OperatorHub是一个web console，集群管理员用它来发现并选择Operator来安装。它在OCP中被默认部署。

这些工具可组合使用，因此可自由选择有用的工具。

Operator成熟度模型

Operator封装的管理逻辑的复杂度可以变化。该逻辑通常也会高度依赖于Operator所代表的服务类型。

不过，对于大部分Operator可能包含的特定功能集，可以概括出Operator的封装操作的成熟度等级。就此而言，以下Operator成熟度模型针对Operator的通用的“第2天操作”，定义了五个成熟度阶段：

该模型还显示了如何最好地通过Operator SDK的Helm、Go和Ansible功能来开发这些功能。

Operator Framework 打包格式

本指南概述了OCP中OLM所支持的Operator打包格式。

Bundle格式

Operator的Bundle格式是Operator Framework引入的打包格式。为提高可伸缩性，并更好地支持上游用户托管自己的目录，bundle格式规格简化了Operator元数据的发布。

Operator bundle代表Operator的一个版本。磁盘上的bundle manifest是容器化的，并作为bundle image提供，该image是一个不可运行的容器image，其中存储了Kubernetes manifest和Operator元数据。然后，使用已有的容器工具（比如 podman 和 docker ）和容器registry（比如 Quay ）来管理bundle image的存储和发布。

Operator元数据可以包括：

• 标识Operator的信息，比如名称和版本。
• 驱动UI的额外信息，比如其图标和示例CR。
• 所需的和所提供的API。
• 相关image。

把manifest加载到Operator Registry数据库中时，会验证以下需求：

• 该bundle必须在注解中定义至少一个频道。
• 每个bundle都有一个CSV。
• 如果CSV拥有CRD，则该CRD必须存在于bundle中。

Manifest

Bundle manifest指的是一组Kubernetes manifest，用于定义Operator的部署和RBAC模型。

Bundle包括每个目录的CSV，一般还包含了CRD，这些CRD在 /manifest 目录中定义CSV所拥有的API。

etcd
├── manifests
│   ├── etcdcluster.crd.yaml
│   └── etcdoperator.clusterserviceversion.yaml
│   └── secret.yaml
│   └── configmap.yaml
└── metadata└── annotations.yaml└── dependencies.yaml

以下对象类型也可以包括在bundle的 /manifests 目录中：

• ClusterRole
• ClusterRoleBinding
• ConfigMap
• ConsoleCLIDownload
• ConsoleLink
• ConsoleQuickStart
• ConsoleYamlSample
• PodDisruptionBudget
• PriorityClass
• PrometheusRule
• Role
• RoleBinding
• Secret
• Service
• ServiceAccount
• ServiceMonitor
• VerticalPodAutoscaler

当bundle中包含这些可选对象时，OLM可以从bundle创建它们，并和CSV一起管理其生命周期：

• 删除CSV时，OLM会删除可选对象。
• 升级CSV时：
  • 如果可选对象的名称相同，OLM会更新它。
  • 如果可选对象的名称在版本之间发生变化，OLM会删除并重建它。

注解

Bundle还在其 /metadata 目录中包含 annotations.yaml 文件。该文件定义了更高级别的聚合数据，以帮助描述关于如何将bundle添加到bundle索引中的格式和包信息：

annotations:operators.operatorframework.io.bundle.mediatype.v1: "registry+v1"operators.operatorframework.io.bundle.manifests.v1: "manifests/"operators.operatorframework.io.bundle.metadata.v1: "metadata/"operators.operatorframework.io.bundle.package.v1: "test-operator"operators.operatorframework.io.bundle.channels.v1: "beta,stable"operators.operatorframework.io.bundle.channel.default.v1: "stable"

注意：如果出现不匹配的情况，则以 annotations.yaml 文件为准，因为依赖这些注解的集群Operator Registry只能访问此文件。

依赖

Operator的依赖项列在bundle的 metadata/ 目录中的 dependencies.yaml 文件中。此文件是可选的，目前仅用于指明Operator-version依赖项。

依赖项列表中的每一项包含一个 type 字段，用于指定依赖项的类型。支持以下Operator依赖项类型：

• olm.package
• olm.gvk
• olm.constraint

下面的例子中，为Prometheus Operator和etcd CRD指定依赖项：

dependencies:- type: olm.packagevalue:packageName: prometheusversion: ">0.27.0"- type: olm.gvkvalue:group: etcd.database.coreos.comkind: EtcdClusterversion: v1beta2

关于opm CLI

opm CLI工具由Operator Framework提供，用于Operator bundle格式。可以通过此工具从与软件存储库类似的Operator bundle列表中创建和维护Operator目录。其结果是一个容器image，它可以存储在容器registry中，然后安装到集群中。

目录包含一个指向Operator manifest内容的指针数据库，可通过在运行容器image时提供的已包含API来查询。在OCP中，OLM可以引用由CatalogSource对象定义的目录源中的image，它会定期轮询image，以对集群上安装的Operator进行频繁更新。

基于文件的目录

略。

RukPak

略。

Operator Framework常用术语表

常见Operator Framework术语

Bundle

在bundle format中，bundle是Operator CSV、manifest和元数据的集合。它们一起构成了可在集群中安装的Operator的唯一版本。

Bundle image

在 bundle format中， bundle image是一个从Operator manifest构建的容器image，其中包含一个bundle。Bundle image由Open Container Initiative（OCI）spec容器registry存储和发布，如 Quay.io 或者DockerHub。

Catalog source

Catalog source代表OLM可查询的元数据存储，以发现和安装Operator及其依赖项。

Channel

频道为Operator定义更新流，用于为订阅者滚动更新（roll out update）。频道头指向该频道的最新版本。例如， stable 频道中会包含Operator的所有稳定版本，按照从旧到新的顺序排列。

Operator可以有几个频道，若订阅与特定频道绑定，则只会在该频道中查找更新。

Channel head

频道头是指特定频道中最新已知的更新。

Cluster service version（CSV）

Cluster service version（CSV）是一个从Operator元数据创建的YAML manifest，可辅助OLM在集群中运行Operator。它是Operator容器image附带的元数据，用于在用户界面填充logo、描述和版本等信息。

CSV也是运行Operator所需的技术信息源，比如其所需的RBAC规则，及其管理或依赖的CR。

Dependency

Operator可能会依赖于集群中另一个Operator的存在。例如，Vault Operator依赖于etcd Operator的数据持久化层。

OLM通过确保在安装过程中，Operator和CRD的所有指定版本都已安装，来解决依赖关系。通过在目录中查找并安装那些“满足所需的CRD API，且与软件包或bundle不相关”的Operator，来解决该依赖关系。

Index image

在bundle格式中，index image是指数据库（数据库快照）image，其中包含关于 Operator bundle（包括所有版本的CSV和CRD）的信息。此索引可以托管集群中Operator的历史记录，并可使用 opm CLI 工具添加或删除Operator来加以维护。

Install plan

安装计划（install plan）是一个资源计算列表，为自动安装或升级CSV而创建。

Multitenancy

OCP中的tenant是指一个用户或一组用户，为一组部署的工作负载（通常由namespace或project表示）共享通用的访问和权限。可以使用租户在不同的组或团队之间提供一定级别的隔离。

当集群由多个用户或组共享时，它被视为多租户（multitenant）集群。

Operator group

Operator group将部署在同一namespace中的所有Operator配置为 OperatorGroup 对象，以便在一系列namspace或集群范围内监视其CR。

Package

在bundle format中，package是一个目录，其中包含每个版本的Operator的发布历史记录。CSV manifest中描述了Operator的发布版本和CRD。

Registry

Registry是一个存储Operator的bundle image的数据库，每个image都包含所有频道的所有最新和历史版本。

Subscription

Subscription通过追踪package中的频道来保持CSV更新。

Update graph

更新图表把CSV的版本关联到一起，与其它打包软件的更新图表类似。可以顺序安装Operator，也可以跳过某些版本。在添加新版本时，更新图表只会在头上增长。

参考

• https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14/html-single/operators/index