OCP的operator——（1）概述

蓝黑2020

已于 2024-04-22 18:25:25 修改

阅读量996

点赞数 30

分类专栏： openshift 文章标签： ocp operator openshift

于 2024-02-14 08:25:51 首次发布

本文链接：https://blog.csdn.net/duke_ding2/article/details/136090321

版权

openshift 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

概述

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.package
    value:
      packageName: prometheus
      version: ">0.27.0"
  - type: olm.gvk
    value:
      group: etcd.database.coreos.com
      kind: EtcdCluster
      version: 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。