OCP的operator——（2）OLM

了解Operator

Operator Lifecycle Manager（OLM）

OLM概念和资源

OLM是什么

Operator Lifecycle Manager（OLM）帮助用户安装、更新和管理Kubernetes原生应用（Operator）以及跨OCP集群运行的关联服务的生命周期。它是Operator Framework的一部分，是一个开源工具包，以高效、自动化、且可扩展的方式管理Operator。

OLM默认在OCP 4.14中运行，帮助集群管理员Operator进行安装、升级和授权。OCP web console提供了管理界面，供集群管理员安装Operator，以及为项目授权以便使用集群上可用的Operator目录。

开发人员通过自助服务体验，无需成为相关的专家也可provision和配置数据库实例、监控、大数据服务，因为Operator已将相关知识融入其中。

OLM资源

以下CRD由OLM定义和管理：

资源	短名称	描述
ClusterServiceVersion（CSV）	csv	应用元数据。例如：名称、版本、图标、所需资源。
CatalogSource	catsrc	定义应用的CSV、CRD和package存储库。
Subscription	sub	通过追踪package中的频道来保持CSV更新。
InstallPlan	ip	为自动安装或升级CSV而需创建的资源的计算列表。
OperatorGroup	og	将部署在同一namespace中的所有Operator配置为 OperatorGroup 对象，以便在一系列namespace或集群范围内监视其CR。
OperatorConditions	-	在OLM和它管理的Operator之间创建通信频道。Operator可以写入 Status.Conditions 数组，以向OLM通报复杂状态。

Cluster service version（CSV）

CSV代表OCP集群中运行的Operator的一个特定版本。它是一个由Operator元数据所创建的YAML manifest，辅助OLM在集群中运行Operator。

OLM需要Operator的元数据，以确保它可以在集群中安全运行，并在发布Operator的新版本时提供如何做升级的信息。这和传统操作系统的软件打包相似。可将OLM的打包步骤看作是制作 rpm 、 deb 或 apk bundle的阶段。

CSV中包含Operator容器image附带的元数据，用于在用户界面填充名称、版本、描述、label、存储库链接、logo等信息。

CSV也是运行Operator所需的技术信息源，例如其管理或依赖哪些CR、RBAC规则、集群需求、安装策略。这些信息告诉OLM如何创建所需的资源并将Operator作为deployment来建立。

Catalog source

Catalog source代表元数据存储，通常是引用容器registry中存储的 index image 。OLM查询catalog source来发现和安装Operator及其依赖项。OCP web console中的OperatorHub也会显示由catalog source provision的Operator。

注意：集群管理员可以使用web console中的Administration -> Cluster Settings -> Configuration -> OperatorHub页面查看集群中已启用的catalog source所提供的Operator的完整列表。

CatalogSource 对象的 spec 指明了如何构造pod，或者是如何与服务于Operator Registry gRPC API的服务进行通信。

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog # 1
  namespace: openshift-marketplace # 2
  annotations:
    olm.catalogImageTemplate: # 3
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
spec:
  displayName: Example Catalog # 4
  image: quay.io/example-org/example-catalog:v1 # 5
  priority: -400 # 6
  publisher: Example Org
  sourceType: grpc #7
  grpcPodConfig:
    securityContextConfig: <security_mode> # 8
    nodeSelector: # 9
      custom_label: <label>
    priorityClassName: system-cluster-critical # 10
    tolerations: # 11
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"
  updateStrategy:
    registryPoll: # 12
      interval: 30m0s
status:
  connectionState:
    address: example-catalog.openshift-marketplace.svc:50051
    lastConnect: 2021-08-26T18:14:31Z
    lastObservedState: READY # 13
  latestImageRegistryPoll: 2021-08-26T18:46:25Z # 14
  registryService: # 15
    createdAt: 2021-08-26T16:16:37Z
    port: 50051
    protocol: grpc
    serviceName: example-catalog
    serviceNamespace: openshift-marketplace

1. CatalogSource 对象的名称。此值也用作在请求的namespace中创建相关pod的名称的一部分。

2. 要创建目录的namespace。要使目录在所有namespace中都可用，需将此值设置为 openshift-marketplace 。默认Red Hat提供的catalog source也使用 openshift-marketplace namespace。否则，将值设置为特定namespace，以使得Operator仅在该namespace中可用。

3. 可选：为避免集群升级可能会使Operator安装处于不支持的状态或没有连续更新路径，可以启用自动更改Operator目录的index image版本作为集群升级的一部分。

   为index image名称设置 olm.catalogImageTemplate 注解，并使用一个或多个Kubernetes集群版本变量，正如为image tag构建模板时所示。该注解会在运行时覆盖 spec.image 字段。更多详细信息，请参阅“定制catalog source的image模板”。

4. 在web console和CLI中的显示名称。

5. 目录的索引image。在使用 olm.catalogImageTemplate 注解时，也可以省略，该注解会在运行时设置pull spec。

6. Catalog source的权重。OLM在依赖项解析过程中使用该权重来排优先级。高权重表示该目录优先于低权重目录。

7. 源类型包括：

   • 带有 image 引用的 grpc ：OLM pull该image并运行pod，为合规的API服务。
   • 带有 address 字段的 grpc ：OLM会尝试通过给定地址来联系gRPC API。在大多数情况下不应该使用这种类型。
   • configmap ：OLM解析configmap数据，并运行一个服务于gRPC API的pod。

8. 指定 legacy 或 restricted 值。如果没有设置该字段，则默认值为 legacy 。在将来的OCP发行版本中，计划的默认值为 restricted 。如果目录无法使用 restricted 权限运行，建议手动将此字段设置为 legacy 。

9. 可选：对于 grpc 类型的catalog source，请覆盖在 spec.image 的内容的pod的默认node选择器（如果定义了）。

10. 可选：对于 grpc 类型的catalog source，请覆盖在 spec.image 的内容的pod的默认优先级类名称（如果定义了）。Kubernetes默认提供了 system-cluster-critical 和 system-node-critical 优先级类。将字段设置为空（“”），可为pod分配默认优先级。可以手动定义其它优先级类。

11. 可选：对于 grpc 类型的catalog source，请覆盖 spec.image 的内容的pod的默认容限（tolerations）（如果定义了）。

12. 以指定的时间间隔自动检查新版本，以保持更新。

13. 目录连接的最后观察状态。例如：

    • READY ：成功建立连接。
    • CONNECTING ：正在尝试建立连接。
    • TRANSIENT_FAILURE ：尝试建立连接时发生了临时的问题，比如超时。该状态将会最终切回到 CONNECTING ，然后重试。

14. 存储目录image的容器registry最近一次的轮询时间，以确保image是最新的。

15. 目录的Operator Registry服务的状态信息。

在订阅中引用 CatalogSource 对象的 name ，会指示OLM到哪里搜索请求的Operator：

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace

定制catalog source的image模板

Operator与底层集群的兼容性可以通过catalog source以各种方式表示。其中一种用于Red Hat默认提供的catalog的方法，是识别“为特定平台发行版本（比如OCP 4.14）特别创建的索引image”的image tag。

在集群升级过程中，Red Hat默认提供的catalog source的索引image tag由Cluster Version Operator（CVO）自动更新，以便OLM pull目录的更新版本。例如，在从OCP 4.13 升级到 4.14 的过程中，redhat-operators 目录的 CatalogSource 对象中的 spec.image 字段，从：

registry.redhat.io/redhat/redhat-operator-index:v4.13

更新为：

registry.redhat.io/redhat/redhat-operator-index:v4.14

但是，CVO不会自动更新定制目录的image tag。为确保集群升级后，留给用户的Operator安装是兼容的、受支持的，还应保持更新定制目录，以引用更新的索引image。

从OCP 4.9开始，集群管理员可以在定制目录的 CatalogSource 对象中添加 olm.catalogImageTemplate 注解到包含模板的image引用。模板中支持使用以下Kubernetes版本变量：

• kube_major_version
• kube_minor_version
• kube_patch_version

注意：必须指定Kubernetes集群版本，而不是OCP集群版本，因为后者目前不适用于模板。

如果已经创建并push了带有指定更新Kubernetes版本tag的索引image，设置此注解可使定制目录中的索引image版本在集群升级后自动更改。该注解值用于设置或更新 CatalogSource 对象的 spec.image 字段中的image引用。这有助于避免在集群升级后，Operator安装处于不受支持的状态，或没有连续更新路径。

注意：无论存储在哪个registry中，必须确保在集群升级时，有更新tag的索引image可被集群访问。

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog
  namespace: openshift-marketplace
  annotations:
    olm.catalogImageTemplate:
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}"
spec:
  displayName: Example Catalog
  image: quay.io/example-org/example-catalog:v1.27
  priority: -400
  publisher: Example Org

注意：如果设置了 spec.image 字段和 olm.catalogImageTemplate 注解，则 spec.image 字段会被注解中的解析值覆盖。如果注解没有解析为可用的pull spec，catalog source会回退到设置的 spec.image 值。

如果没有设置 spec.image 字段，且注解没有解析为可用的pull spec，OLM会停止catalog source的reconciliation，并将其设置为人类可读的错误情况。

对于使用Kubernetes 1.27的OCP 4.14集群，上例中的 olm.catalogImageTemplate 注解会解析为以下image引用：

quay.io/example-org/example-catalog:v1.27

对于未来的OCP版本，可以为定制目录创建更新的索引image，该image以更新的Kubernetes版本为目标，供以后的OCP版本使用。升级前设置了 olm.catalogImageTemplate 注解，则将集群升级到更新的OCP版本也会自动更新目录的索引image。

目录健康需求

集群上的Operator目录从安装解析来说是可交换的。 Subscription 对象可能会引用特定目录，但依赖项会根据集群中的所有目录来解决。

例如，如果Catalog A不健康，则引用Catalog A的订阅可能会解析Catalog B中的依赖项，这可能不是集群管理员所预期的，因为B通常比A的目录优先级更低。

因此，OLM要求所有具有给定全局namespace的目录（例如，默认的 openshift-marketplace namespace或定制全局namespace）都是健康的。当目录不健康时，其共享全局namespace中所有的Operator安装或更新操作都将失败，带着 SourcesUnhealthy 状况。如果允许这些操作处于不健康状态，OLM可能会做出在集群管理员期望之外的解析和安装决策。

作为集群管理员，如果观察到一个不健康目录，并希望将目录视为无效并恢复Operator安装，请参阅“删除定制目录”或“禁用缺省OperatorHub catalog source"部分，以了解有关删除不健康目录的信息。

Subscription

订阅由 Subscription 对象定义，代表安装Operator的意图。它是将Operator与catalog source相关联的CR。

订阅描述了要订阅Operator包的哪个频道，以及自动还是手动更新。如果设置为自动更新，订阅可确保OLM管理并升级Operator，以确保集群中始终运行最新版本。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace

该 Subscription 对象定义了Operator的名称和namespace，以及可以找到Operator数据的目录。频道（比如 alpha 、 beta 、 stable ）可帮助确定应从catalog source安装哪个Operator流。

订阅中的频道名称可能会因Operator而异，但在给定的Operator中，命名schema应遵守通用惯例。例如，频道名称可能会遵循Operator （ 1.2 、 1.3 ）或发行频率（ stable 、 fast ）提供的次发行版本更新流。

除了可从OCP web console轻松查看外，还可以通过检查相关订阅的状态来识别是否有新版本的Operator。 currentCSV 字段的值是OLM所知道的最新版本，而 installedCSV 是集群中的安装版本。

Install plan

安装计划（Install Plan， IP）由 InstallPlan 对象定义，描述了OLM为了安装或升级到Operator特定版本而创建的一组资源。该版本由CSV定义。

要安装Operator，集群管理员或被授予Operator安装许可的用户，必须首先创建一个 Subscription 对象。订阅代表了从catalog source订阅Operator可用版本流的意图。然后，订阅会创建一个 InstallPlan 对象来方便Operator的资源安装。

然后，根据以下批准策略之一来批准安装计划：

• 如果订阅的 spec.installPlanApproval 字段被设置为 Automatic ，则会自动批准安装计划。
• 如果订阅的 spec.installPlanApproval 字段被设置为 Manual ，则安装计划必须由集群管理员或具有适合权限的用户手工批准。

批准安装计划后，OLM会创建指定的资源，并在订阅指定的namespace中安装Operator。

apiVersion: operators.coreos.com/v1alpha1
kind: InstallPlan
metadata:
  name: install-abcde
  namespace: operators
spec:
  approval: Automatic
  approved: true
  clusterServiceVersionNames:
    - my-operator.v1.0.1
  generation: 1
status:
  ...
  catalogSources: []
  conditions:
    - lastTransitionTime: '2021-01-01T20:17:27Z'
      lastUpdateTime: '2021-01-01T20:17:27Z'
      status: 'True'
      type: Installed
  phase: Complete
  plan:
    - resolving: my-operator.v1.0.1
      resource:
        group: operators.coreos.com
        kind: ClusterServiceVersion
        manifest: >-
        ...
        name: my-operator.v1.0.1
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1alpha1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: apiextensions.k8s.io
        kind: CustomResourceDefinition
        manifest: >-
        ...
        name: webservers.web.servers.org
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1beta1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: ''
        kind: ServiceAccount
        manifest: >-
        ...
        name: my-operator
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: Role
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: RoleBinding
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
      ...

Operator group

Operator组由 OperatorGroup 资源定义，为OLM安装的Operator提供multitenant配置。Operator组选择目标namespace，在其中为其成员Operator生成所需的RBAC访问权限。

这一组目标namespace通过存储在CSV的 olm.targetNamespaces 注解中的一个以逗号分隔的字符串来提供。该注解应用于成员Operator的CSV实例，并映射到其deployment中。

Operator condition

作为管理Operator生命周期的角色的一部分，OLM从定义Operator的Kubernetes资源状态来推断Operator状态。虽然此方法在一定程度上保证Operator处于给定状态，但在有些情况下，Operator可能需要和OLM沟通信息，而这些信息是无法推断的。这些信息可以被OLM使用来更好地管理Operator的生命周期。

OLM提供了一个名为 OperatorCondition 的CRD，它允许Operator向OLM沟通状况。当 OperatorCondition 资源的 Spec.Conditions 数组存在时，有一组受支持的状况，它们会影响OLM管理 Operator。

注意：默认情况下， OperatorCondition 对象中没有 Spec.Conditions 数组，直到由用户添加或使用定制Operator逻辑添加。

OLM架构

组件职责

OLM由两个Operator组成：OLM Operator和Catalog Operator。

每个Operator均负责管理CRD，而CRD是OLM框架的基础。

由OLM 和Catalog Operator管理的CRD：

资源	短名称	所有者	描述
ClusterServiceVersion （CSV）	csv	OLM	应用元数据：名称、版本、图标、所需资源、安装等。
InstallPlan	ip	Catalog	为自动安装或升级CSV而需创建的资源计算列表。
CatalogSource	catsrc	Catalog	定义应用的CSV、CRD、package存储库。
Subscription	sub	Catalog	用于通过追踪包中的频道来保持CSV更新。
OperatorGroup	og	OLM	将部署在同一namespace中的所有Operator配置为 OperatorGroup 对象，以便在一系列namespace或集群范围内监视其CR。

每个Operator还负责创建以下资源。

由OLM和Catalog Operator创建的资源：

资源	所有者
Deployments	OLM
ServiceAccounts	OLM
(Cluster)Roles	OLM
(Cluster)RoleBindings	OLM
CustomResourceDefinitions (CRDs)	Catalog
ClusterServiceVersions (CSVs)	Catalog

OLM Operator

集群中存在CSV中指定的所需资源后，OLM Operator将负责部署由CSV资源定义的应用。

OLM Operator不关注所需资源的创建。可选择使用CLI或者使用Catalog Operator来手工创建这些资源。关注点的分离可以使得用户可以逐渐增加他们为其应用选择的OLM框架量。

OLM Operator使用以下工作流：

1. 观察namespace中的CSV，并检查是否满足需求。
2. 如果满足需求，运行CSV的安装策略。

注意：CSV必须是Operator组里的活跃成员，才可运行该安装策略。

Catalog Operator

Catalog Operator负责解析和安装CSV以及它们指定的所需资源。另外还负责监视频道中的catalog source中是否有软件包更新，并将其升级（如果有需要可选择自动）至最新的可用版本。

要追踪频道中的软件包，可以创建一个 Subscription 对象来配置所需的软件包、频道和 CatalogSource 对象，以便pull更新。在找到更新后，便会代表用户将一个适当的 InstallPlan 对象写入namespace。

Catalog Operator使用以下工作流：

1. 连接到集群中的每个catalog source。
2. 监视用户创建的未解析的install plan，如果找到了：
   1. 查找与请求名称相匹配的CSV，并将此CSV添加为已解析的资源。
   2. 对于每个受管的或所需的CRD，将其添加为已解析的资源。
   3. 对于每个所需的CRD，找到管理它的CSV。
3. 监视已解析的install plan，并为其创建所有已发现的资源（如果用户批准或自动批准）。
4. 监视catalog source和subscription，并基于它们创建install plan。

Catalog Registry

Catalog Registry存储CSV和CRD以便在集群中创建，并存储有关软件包和频道的元数据。

package manifest 是Catalog Registry中的一个条目，用于将软件包标识与CSV集相关联。在软件包中，频道指向某个CSV。因为CSV显式引用了所替换的CSV，软件包manifest向Catalog Operator提供了将CSV更新至频道中的最新版本所需的所有信息，逐步安装和替换每个中间版本。

OLM工作流

OLM中的Operator安装和升级工作流

在OLM生态系统中，以下资源用于解析Operator的安装和升级：

• ClusterServiceVersion (CSV)
• CatalogSource
• Subscription

CSV中定义的Operator元数据，可保存在一个被称为catalog source的集合中。Catalog source使用Operator Registry API，OLM又使用catalog source来查询可用的Operator，以及已安装Operator的更新。

Catalog source概览：

在catalog source里，Operator被整合为更新软件包和更新流，被称为频道，这应是OCP或其它持续发行周期的软件（比如Web浏览器）的熟悉的更新模式。

Catalog source里的包和频道：

用户在subscription的某个catalog source中指定某个软件包和频道，比如 etcd 包及其 alpha 频道。如果订阅了命名空间中尚未安装的软件包，则会安装该软件包的最新Operator。

注意：OLM有意避免了版本比较，因此从给定catalog -> channel -> package路径提供的“latest”或“newest”Operator并不一定是最高的版本号。更应将其视为频道的head引用，类似Git存储库。

每个CSV均有一个 replaces 参数，指明所替换的是哪个Operator。这样便构建了一个OLM可以查询的CSV图，且频道之间可共享更新。可将频道视为更新图的入口点。

可用频道更新的OLM图：

软件包的频道示例：

packageName: example
channels:
- name: alpha
  currentCSV: example.v0.1.2
- name: beta
  currentCSV: example.v0.1.3
defaultChannel: alpha

为了让OLM成功查询更新、给定一个catalog source、软件包、频道、CSV，目录必须能够明确无误地返回一个CSV，替换输入的CSV。

升级路径示例

略。

跳过升级

略。

替换多个Operator

略。

Z-stream支持

略。

OLM依赖项解析

略。

Operator组

略。

Multitenancy和Operator共置（colocation）

略。

Operator状况

略。

OLM指标

略。

OLM中的webhook管理

略。

参考

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