×

关于操作符组

OperatorGroup资源定义的操作符组为OLM安装的操作符提供了多租户配置。操作符组选择目标命名空间,以便在其成员操作符中生成所需的RBAC访问权限。

目标命名空间集由存储在集群服务版本(CSV)的olm.targetNamespaces注释中的逗号分隔字符串提供。此注释应用于成员操作符的CSV实例,并投影到它们的部署中。

操作符组成员资格

如果满足以下条件,则操作符被认为是操作符组的成员

  • 操作符的CSV存在于与操作符组相同的命名空间中。

  • 操作符的CSV中的安装模式支持操作符组目标的命名空间集。

CSV中的安装模式由InstallModeType字段和布尔值Supported字段组成。CSV的规范可以包含一组四种不同InstallModeTypes的安装模式。

表1. 安装模式和受支持的操作符组
InstallModeType 描述

OwnNamespace

操作符可以是选择其自身命名空间的操作符组的成员。

SingleNamespace

操作符可以是选择一个命名空间的操作符组的成员。

MultiNamespace

操作符可以是选择多个命名空间的操作符组的成员。

AllNamespaces

操作符可以是选择所有命名空间的操作符组的成员(目标命名空间集为空字符串"")。

如果CSV的规范省略了InstallModeType的条目,则除非现有条目隐式支持它,否则该类型被认为不受支持。

目标命名空间选择

您可以使用spec.targetNamespaces参数显式命名操作符组的目标命名空间。

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace
spec:
  targetNamespaces:
  - my-namespace

您也可以使用带有spec.selector参数的标签选择器来指定命名空间。

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace
spec:
  selector:
    cool.io/prod: "true"

不建议通过spec.targetNamespaces列出多个命名空间或通过spec.selector使用标签选择器,因为在未来的版本中,Operator组中对多个目标命名空间的支持可能会被移除。

如果同时定义了spec.targetNamespacesspec.selector,则会忽略spec.selector。或者,您可以同时省略spec.selectorspec.targetNamespaces来指定一个全局Operator组,它会选择所有命名空间。

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace

已解析的选择命名空间集显示在Opeator组的status.namespaces参数中。全局Operator组的status.namespace包含空字符串(""),这向使用者Operator发出信号,表明它应该监视所有命名空间。

Operator组CSV注释

Operator组的成员CSV具有以下注释:

注释 描述

olm.operatorGroup=<group_name>

包含Operator组的名称。

olm.operatorNamespace=<group_namespace>

包含Operator组的命名空间。

olm.targetNamespaces=<target_namespaces>

包含一个逗号分隔的字符串,列出Operator组的目标命名空间选择。

除了olm.targetNamespaces之外的所有注释都包含在复制的CSV中。在复制的CSV中省略olm.targetNamespaces注释可以防止租户之间目标命名空间的重复。

提供的API注释

组/版本/种类(GVK)是Kubernetes API的唯一标识符。有关Operator组提供的GVK的信息显示在olm.providedAPIs注释中。注释的值是一个由逗号分隔的<kind>.<version>.<group>组成的字符串。包含Operator组所有活动成员CSV提供的CRD和API服务的GVK。

查看以下具有单个活动成员CSV的OperatorGroup对象的示例,该CSV提供PackageManifest资源。

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  annotations:
    olm.providedAPIs: PackageManifest.v1alpha1.packages.apps.redhat.com
  name: olm-operators
  namespace: local
  ...
spec:
  selector: {}
  serviceAccount:
    metadata:
      creationTimestamp: null
  targetNamespaces:
  - local
status:
  lastUpdated: 2019-02-19T16:18:28Z
  namespaces:
  - local

基于角色的访问控制

创建Operator组时,会生成三个集群角色。每个角色都包含一个单一的聚合规则,该规则具有设置为匹配标签的集群角色选择器,如下所示:

集群角色 匹配的标签

olm.og.<operatorgroup_name>-admin-<hash_value>

olm.opgroup.permissions/aggregate-to-admin: <operatorgroup_name>

olm.og.<operatorgroup_name>-edit-<hash_value>

olm.opgroup.permissions/aggregate-to-edit: <operatorgroup_name>

olm.og.<operatorgroup_name>-view-<hash_value>

olm.opgroup.permissions/aggregate-to-view: <operatorgroup_name>

只要CSV使用AllNamespaces安装模式监视所有命名空间,并且没有因原因InterOperatorGroupOwnerConflict而处于失败状态,则当CSV成为Operator组的活动成员时,就会生成以下RBAC资源:

  • 来自CRD的每个API资源的集群角色

  • 来自API服务的每个API资源的集群角色

  • 其他角色和角色绑定

表2. 为来自CRD的每个API资源生成的集群角色
集群角色 设置

<kind>.<group>-<version>-admin

<kind>的动词

  • *

聚合标签

  • rbac.authorization.k8s.io/aggregate-to-admin: true

  • olm.opgroup.permissions/aggregate-to-admin: <operatorgroup_name>

<kind>.<group>-<version>-edit

<kind>的动词

  • 创建

  • 更新

  • 修补

  • 删除

聚合标签

  • rbac.authorization.k8s.io/aggregate-to-edit: true

  • olm.opgroup.permissions/aggregate-to-edit: <operatorgroup_name>

<kind>.<group>-<version>-view

<kind>的动词

  • 获取

  • 列出

  • 观察

聚合标签

  • rbac.authorization.k8s.io/aggregate-to-view: true

  • olm.opgroup.permissions/aggregate-to-view: <operatorgroup_name>

<kind>.<group>-<version>-view-crdview

apiextensions.k8s.io customresourcedefinitions <crd-name>的动词

  • 获取

聚合标签

  • rbac.authorization.k8s.io/aggregate-to-view: true

  • olm.opgroup.permissions/aggregate-to-view: <operatorgroup_name>

表3. 为来自API服务的每个API资源生成的集群角色
集群角色 设置

<kind>.<group>-<version>-admin

<kind>的动词

  • *

聚合标签

  • rbac.authorization.k8s.io/aggregate-to-admin: true

  • olm.opgroup.permissions/aggregate-to-admin: <operatorgroup_name>

<kind>.<group>-<version>-edit

<kind>的动词

  • 创建

  • 更新

  • 修补

  • 删除

聚合标签

  • rbac.authorization.k8s.io/aggregate-to-edit: true

  • olm.opgroup.permissions/aggregate-to-edit: <operatorgroup_name>

<kind>.<group>-<version>-view

<kind>的动词

  • 获取

  • 列出

  • 观察

聚合标签

  • rbac.authorization.k8s.io/aggregate-to-view: true

  • olm.opgroup.permissions/aggregate-to-view: <operatorgroup_name>

其他角色和角色绑定
  • 如果CSV精确定义了一个包含*的目标命名空间,则会为CSV的permissions字段中定义的每个权限生成一个集群角色和相应的集群角色绑定。所有生成的资源都具有olm.owner: <csv_name>olm.owner.namespace: <csv_namespace>标签。

  • 如果CSV没有精确定义一个包含*的目标命名空间,则Operator命名空间中所有具有olm.owner: <csv_name>olm.owner.namespace: <csv_namespace>标签的角色和角色绑定都会被复制到目标命名空间。

复制的CSV

OLM在Operator组的每个目标命名空间中创建Operator组所有活动成员CSV的副本。复制的CSV的目的是告诉目标命名空间的用户已配置特定Operator来监视在那里创建的资源。

复制的CSV的状态原因是Copied,并且会更新以匹配其源CSV的状态。olm.targetNamespaces注释在复制的CSV在集群上创建之前会被去除。省略目标命名空间选择可以避免租户之间目标命名空间的重复。

当其源CSV不再存在或其源CSV所属的Operator组不再以复制的CSV的命名空间为目标时,复制的CSV将被删除。

默认情况下,disableCopiedCSVs字段被禁用。启用disableCopiedCSVs字段后,OLM会删除集群上现有的复制的CSV。禁用disableCopiedCSVs字段后,OLM会再次添加复制的CSV。

  • 禁用disableCopiedCSVs字段

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OLMConfig
    metadata:
      name: cluster
    spec:
      features:
        disableCopiedCSVs: false
    EOF
  • 启用disableCopiedCSVs字段

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OLMConfig
    metadata:
      name: cluster
    spec:
      features:
        disableCopiedCSVs: true
    EOF

静态Operator组

如果Operator组的spec.staticProvidedAPIs字段设置为true,则该Operator组为静态的。因此,OLM不会修改Operator组的olm.providedAPIs注释,这意味着它可以在预先设置。当用户想要使用Operator组来防止一组命名空间中的资源竞争,但没有提供这些资源的API的活动成员CSV时,这很有用。

以下是一个Operator组的示例,该组使用something.cool.io/cluster-monitoring: "true"注释保护所有命名空间中的Prometheus资源。

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-monitoring
  namespace: cluster-monitoring
  annotations:
    olm.providedAPIs: Alertmanager.v1.monitoring.coreos.com,Prometheus.v1.monitoring.coreos.com,PrometheusRule.v1.monitoring.coreos.com,ServiceMonitor.v1.monitoring.coreos.com
spec:
  staticProvidedAPIs: true
  selector:
    matchLabels:
      something.cool.io/cluster-monitoring: "true"

Operator组交集

如果两个Operator组的目标命名空间集的交集不是空集,并且由olm.providedAPIs注释定义的提供的API集的交集不是空集,则称这两个Operator组具有相交的提供的API

一个潜在的问题是,具有相交提供的API的Operator组可能会争夺交集命名空间集中的相同资源。

检查交集规则时,Operator组命名空间始终包含在其选择的目标命名空间中。

交集规则

每次活动成员CSV同步时,OLM都会查询集群以获取CSV的Operator组与所有其他Operator组之间相交提供的API集。然后,OLM检查该集合是否为空集。

  • 如果为true并且CSV提供的API是Operator组的子集

    • 继续转换。

  • 如果为true并且CSV提供的API不是Operator组的子集

    • 如果Operator组是静态的

      • 清理属于CSV的所有部署。

      • 将CSV转换为失败状态,状态原因是CannotModifyStaticOperatorGroupProvidedAPIs

    • 如果Operator组不是静态的

      • 用自身和CSV提供的API的并集替换Operator组的olm.providedAPIs注释。

  • 如果为false并且CSV提供的API不是Operator组的子集

    • 清理属于CSV的所有部署。

    • 将CSV转换为失败状态,状态原因是InterOperatorGroupOwnerConflict

  • 如果为false并且CSV提供的API是Operator组的子集

    • 如果Operator组是静态的

      • 清理属于CSV的所有部署。

      • 将CSV转换为失败状态,状态原因是CannotModifyStaticOperatorGroupProvidedAPIs

    • 如果Operator组不是静态的

      • 用自身和CSV提供的API的差集替换Operator组的olm.providedAPIs注释。

由Operator组导致的失败状态是非终端状态。

每次Operator组同步时都会执行以下操作:

  • 提供的 API 集是从集群中计算得出的,这些 API 来自活动成员 CSV 文件。请注意,复制的 CSV 文件将被忽略。

  • 集群集将与olm.providedAPIs进行比较,如果olm.providedAPIs包含任何额外的 API,则这些 API 将被修剪。

  • 所有在所有命名空间中提供相同 API 的 CSV 文件都将重新排队。这将通知在相交组中发生冲突的 CSV 文件,它们的冲突可能已通过调整大小或删除冲突的 CSV 文件而得到解决。

多租户 Operator 管理的限制

OpenShift Dedicated 对在同一集群上同时安装不同版本的 Operator 提供有限的支持。Operator Lifecycle Manager (OLM) 在不同的命名空间中多次安装 Operator。一个限制是 Operator 的 API 版本必须相同。

由于 Operator 使用 Kubernetes 中的全局资源——自定义资源定义 (CRD) 对象,因此它们是控制平面扩展。不同主版本的 Operator 通常具有不兼容的 CRD。这使得它们无法在集群的不同命名空间中同时安装。

所有租户或命名空间共享集群的同一控制平面。因此,多租户集群中的租户也共享全局 CRD,这限制了在同一集群上并行使用同一 Operator 的不同实例的场景。

支持的场景包括:

  • 不同版本的 Operator,它们提供完全相同的 CRD 定义(对于版本化的 CRD,则是完全相同的版本集)。

  • 不同版本的 Operator,它们不提供 CRD,而是其 CRD 在 OperatorHub 上的单独包中可用。

所有其他场景都不受支持,因为如果同一集群上有多个来自不同 Operator 版本的竞争或重叠的 CRD 需要协调,则无法保证集群数据的完整性。

Operator 组故障排除

成员资格

  • 安装计划的命名空间必须仅包含一个 Operator 组。当尝试在命名空间中生成集群服务版本 (CSV) 时,安装计划会在以下场景中认为 Operator 组无效:

    • 安装计划的命名空间中不存在 Operator 组。

    • 安装计划的命名空间中存在多个 Operator 组。

    • 在 Operator 组中指定了不正确或不存在的服务帐户名称。

    如果安装计划遇到无效的 Operator 组,则不会生成 CSV,并且InstallPlan资源将继续安装并显示相关消息。例如,如果同一命名空间中存在多个 Operator 组,则会提供以下消息:

    attenuated service account query failed - more than one operator group(s) are managing this namespace count=2

    其中count=指定命名空间中 Operator 组的数量。

  • 如果 CSV 的安装模式不支持其命名空间中 Operator 组的目标命名空间选择,则 CSV 将转换为失败状态,原因是UnsupportedOperatorGroup。由于此原因而处于失败状态的 CSV 在 Operator 组的目标命名空间选择更改为受支持的配置或 CSV 的安装模式被修改为支持目标命名空间选择后,将转换为挂起状态。