apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: my-group
namespace: my-namespace
spec:
targetNamespaces:
- my-namespace
由OperatorGroup
资源定义的操作符组为OLM安装的操作符提供了多租户配置。操作符组选择目标命名空间,以便在其成员操作符中生成所需的RBAC访问权限。
目标命名空间集由存储在集群服务版本(CSV)的olm.targetNamespaces
注释中的逗号分隔字符串提供。此注释应用于成员操作符的CSV实例,并投影到它们的部署中。
如果满足以下条件,则操作符被认为是操作符组的成员
操作符的CSV存在于与操作符组相同的命名空间中。
操作符的CSV中的安装模式支持操作符组目标的命名空间集。
CSV中的安装模式由InstallModeType
字段和布尔值Supported
字段组成。CSV的规范可以包含一组四种不同InstallModeTypes
的安装模式。
InstallModeType | 描述 |
---|---|
|
操作符可以是选择其自身命名空间的操作符组的成员。 |
|
操作符可以是选择一个命名空间的操作符组的成员。 |
|
操作符可以是选择多个命名空间的操作符组的成员。 |
|
操作符可以是选择所有命名空间的操作符组的成员(目标命名空间集为空字符串 |
如果CSV的规范省略了 |
您可以使用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
,则会忽略spec.selector
。或者,您可以同时省略spec.selector
和spec.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组的名称。 |
|
包含Operator组的命名空间。 |
|
包含一个逗号分隔的字符串,列出Operator组的目标命名空间选择。 |
除了 |
组/版本/种类(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组时,会生成三个集群角色。每个角色都包含一个单一的聚合规则,该规则具有设置为匹配标签的集群角色选择器,如下所示:
集群角色 | 匹配的标签 |
---|---|
|
|
|
|
|
|
只要CSV使用AllNamespaces
安装模式监视所有命名空间,并且没有因原因InterOperatorGroupOwnerConflict
而处于失败状态,则当CSV成为Operator组的活动成员时,就会生成以下RBAC资源:
来自CRD的每个API资源的集群角色
来自API服务的每个API资源的集群角色
其他角色和角色绑定
集群角色 | 设置 |
---|---|
|
对
聚合标签
|
|
对
聚合标签
|
|
对
聚合标签
|
|
对
聚合标签
|
集群角色 | 设置 |
---|---|
|
对
聚合标签
|
|
对
聚合标签
|
|
对
聚合标签
|
如果CSV精确定义了一个包含*
的目标命名空间,则会为CSV的permissions
字段中定义的每个权限生成一个集群角色和相应的集群角色绑定。所有生成的资源都具有olm.owner: <csv_name>
和olm.owner.namespace: <csv_namespace>
标签。
如果CSV没有精确定义一个包含*
的目标命名空间,则Operator命名空间中所有具有olm.owner: <csv_name>
和olm.owner.namespace: <csv_namespace>
标签的角色和角色绑定都会被复制到目标命名空间。
OLM在Operator组的每个目标命名空间中创建Operator组所有活动成员CSV的副本。复制的CSV的目的是告诉目标命名空间的用户已配置特定Operator来监视在那里创建的资源。
复制的CSV的状态原因是Copied
,并且会更新以匹配其源CSV的状态。olm.targetNamespaces
注释在复制的CSV在集群上创建之前会被去除。省略目标命名空间选择可以避免租户之间目标命名空间的重复。
当其源CSV不再存在或其源CSV所属的Operator组不再以复制的CSV的命名空间为目标时,复制的CSV将被删除。
默认情况下,
|
如果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组的目标命名空间集的交集不是空集,并且由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 文件而得到解决。
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 组。当尝试在命名空间中生成集群服务版本 (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 的安装模式被修改为支持目标命名空间选择后,将转换为挂起状态。