向集群添加 Operator - 管理员任务 | Operators | OpenShift Dedicated

关于使用 OperatorHub 安装 Operator
使用 Web 控制台从 OperatorHub 安装
使用 CLI 从 OperatorHub 安装
为多租户集群准备多个 Operator 实例
在自定义命名空间中安装全局 Operator
Operator 工作负载的 Pod 部署
控制 Operator 的安装位置

使用 Operator Lifecycle Manager (OLM)，具有 `dedicated-admin` 角色的管理员可以将基于 OLM 的 Operator 安装到 OpenShift Dedicated 集群。

有关 OLM 如何处理安装在同一命名空间中的 Operator 的更新，以及使用自定义全局 Operator 组安装 Operator 的替代方法的信息，请参见多租户和 Operator 共存。

关于使用 OperatorHub 安装 Operator

OperatorHub 是一个用于发现 Operator 的用户界面；它与 Operator Lifecycle Manager (OLM) 协同工作，后者在集群上安装和管理 Operator。

作为 `dedicated-admin`，您可以使用 OpenShift Dedicated Web 控制台或 CLI 从 OperatorHub 安装 Operator。将 Operator 订阅到一个或多个命名空间会使 Operator 可供集群中的开发人员使用。

在安装过程中，您必须确定 Operator 的以下初始设置

安装模式: 选择**集群上的所有命名空间（默认）**可在所有命名空间上安装 Operator，或者如果可用，则选择单个命名空间，只在选定的命名空间上安装 Operator。此示例选择**所有命名空间…**以使 Operator 可供所有用户和项目使用。
更新通道: 如果 Operator 可通过多个通道获得，您可以选择要订阅的通道。例如，要从**稳定**通道部署（如果可用），请从列表中选择它。
审批策略: 您可以选择自动或手动更新。

如果您为已安装的 Operator 选择自动更新，则当所选通道中提供该 Operator 的新版本时，Operator Lifecycle Manager (OLM) 会在没有人为干预的情况下自动升级正在运行的 Operator 实例。

如果您选择手动更新，则当提供 Operator 的较新版本时，OLM 会创建更新请求。然后，您必须作为 `dedicated-admin` 手动批准该更新请求，才能将 Operator 更新到新版本。

其他资源

了解 OperatorHub

使用 Web 控制台从 OperatorHub 安装

您可以使用 OpenShift Dedicated Web 控制台从 OperatorHub 安装和订阅 Operator。

前提条件

使用具有 `dedicated-admin` 角色的帐户访问 OpenShift Dedicated 集群。

步骤

在 Web 控制台中导航到**Operators → OperatorHub**页面。
滚动或在**按关键字筛选**框中键入关键字以查找所需的 Operator。例如，键入 `advanced` 以查找 Kubernetes 的高级集群管理 Operator。

您还可以按**基础设施功能**筛选选项。例如，如果您想查看在断开连接的环境（也称为受限网络环境）中工作的 Operator，请选择**断开连接**。
选择操作符以显示其他信息。

选择社区操作符会发出警告，提示 Red Hat 不认证社区操作符；您必须在继续之前确认此警告。
阅读有关操作符的信息，然后点击安装。

在安装操作符页面上，配置您的操作符安装。

如果您想安装特定版本的 Operator，请从列表中选择一个更新通道和版本。您可以浏览 Operator 在任何通道中的各个版本，查看该通道和版本的元数据，并选择要安装的确切版本。

版本选择默认为所选通道的最新版本。如果选择了通道的最新版本，则默认情况下启用自动审批策略。否则，如果未安装所选通道的最新版本，则需要手动审批。

使用手动审批安装操作符会导致命名空间中安装的所有操作符都使用手动审批策略，并且所有操作符都会一起更新。如果您想独立更新操作符，请将操作符安装到单独的命名空间中。

确认操作符的安装模式。
- 集群上的所有命名空间（默认）将操作符安装在默认的 `openshift-operators` 命名空间中，以监视并使其可用于集群中的所有命名空间。此选项并非始终可用。
- 集群上的特定命名空间允许您选择要在其中安装操作符的特定单个命名空间。操作符将仅监视并可用于此单个命名空间。
对于启用了令牌身份验证的云提供商上的集群
- 如果集群使用 AWS 安全令牌服务（Web 控制台中的STS 模式），请在角色 ARN 字段中输入您的服务帐户的 AWS IAM 角色的 Amazon 资源名称 (ARN)。要创建角色的 ARN，请按照准备 AWS 帐户中描述的过程进行操作。
- 如果集群使用 Microsoft Entra 工作负载 ID（Web 控制台中的工作负载身份/联合身份模式），请在相应的字段中添加客户端 ID、租户 ID 和订阅 ID。
- 如果集群使用 Google Cloud Platform 工作负载身份（Web 控制台中的GCP 工作负载身份/联合身份模式），请在相应的字段中添加项目编号、池 ID、提供商 ID 和服务帐户电子邮件。

对于更新审批，请选择自动或手动审批策略。

如果 Web 控制台显示集群使用 AWS STS、Microsoft Entra 工作负载 ID 或 GCP 工作负载身份，则必须将更新审批设置为手动。

不建议使用自动审批更新的订阅，因为在更新之前可能需要进行权限更改。使用手动审批更新的订阅可确保管理员有机会验证更高版本的权限，采取任何必要的步骤，然后进行更新。

单击安装，使操作符可用于此 OpenShift Dedicated 集群上的所选命名空间。
1. 如果您选择了手动审批策略，则订阅的升级状态将保持为正在升级，直到您查看并批准安装计划。
  
  在安装计划页面上批准后，订阅升级状态将变为最新。
2. 如果您选择了自动审批策略，则升级状态应在无需干预的情况下变为最新。

验证

订阅的升级状态为最新后，选择操作符→已安装的操作符以验证已安装操作符的集群服务版本 (CSV) 最终是否显示。相关命名空间中的状态最终应变为成功。

对于所有命名空间…安装模式，状态在 `openshift-operators` 命名空间中变为成功，但如果您在其他命名空间中检查，则状态为已复制。

如果未成功
- 检查工作负载→Pod 页面上 `openshift-operators` 项目（或如果选择了特定命名空间…安装模式，则为其他相关命名空间）中报告问题的任何 Pod 的日志，以进行进一步故障排除。
安装操作符后，元数据将指示安装了哪个通道和版本。

通道和版本下拉菜单仍可用于在此目录上下文中查看其他版本的元数据。

其他资源

手动批准挂起的操作符更新

使用 CLI 从 OperatorHub 安装

您可以使用 CLI 从 OperatorHub 安装操作符，而不是使用 OpenShift Dedicated Web 控制台。使用 `oc` 命令创建或更新 `Subscription` 对象。

对于 `SingleNamespace` 安装模式，您还必须确保在相关命名空间中存在相应的 Operator 组。由 `OperatorGroup` 对象定义的 Operator 组选择目标命名空间，在其中为与 Operator 组位于同一命名空间中的所有 Operator 生成所需的 RBAC 访问权限。

在大多数情况下，此过程的 Web 控制台方法更可取，因为它会在后台自动执行任务，例如在选择 `SingleNamespace` 模式时自动处理 `OperatorGroup` 和 `Subscription` 对象的创建。

前提条件

使用具有 `dedicated-admin` 角色的帐户访问 OpenShift Dedicated 集群。
您已安装 OpenShift CLI (`oc`)。

步骤

查看 OperatorHub 中集群可用的操作符列表。

$ oc get packagemanifests -n openshift-marketplace

示例输出

NAME                               CATALOG               AGE
3scale-operator                    Red Hat Operators     91m
advanced-cluster-management        Red Hat Operators     91m
amq7-cert-manager                  Red Hat Operators     91m
# ...
couchbase-enterprise-certified     Certified Operators   91m
crunchy-postgres-operator          Certified Operators   91m
mongodb-enterprise                 Certified Operators   91m
# ...
etcd                               Community Operators   91m
jaeger                             Community Operators   91m
kubefed                            Community Operators   91m
# ...

注意您所需操作符的目录。

检查您所需的操作符以验证其支持的安装模式和可用的通道。

$ oc describe packagemanifests <operator_name> -n openshift-marketplace

示例输出

# ...
Kind:         PackageManifest
# ...
      Install Modes: (1)
        Supported:  true
        Type:       OwnNamespace
        Supported:  true
        Type:       SingleNamespace
        Supported:  false
        Type:       MultiNamespace
        Supported:  true
        Type:       AllNamespaces
# ...
    Entries:
      Name:       example-operator.v3.7.11
      Version:    3.7.11
      Name:       example-operator.v3.7.10
      Version:    3.7.10
    Name:         stable-3.7 (2)
# ...
   Entries:
      Name:         example-operator.v3.8.5
      Version:      3.8.5
      Name:         example-operator.v3.8.4
      Version:      3.8.4
    Name:           stable-3.8 (2)
  Default Channel:  stable-3.8 (3)

1	指示支持哪些安装模式。
2	示例通道名称。
3	如果未指定通道，则默认选择的通道。

您可以通过运行以下命令以 YAML 格式打印操作符的版本和通道信息：

$ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml

如果在命名空间中安装了多个目录，请运行以下命令以查找来自特定目录的操作符的可用版本和通道：

$ oc get packagemanifest \
   --selector=catalog=<catalogsource_name> \
   --field-selector metadata.name=<operator_name> \
   -n <catalog_namespace> -o yaml

如果您未指定操作符的目录，如果满足以下条件，则运行 `oc get packagemanifest` 和 `oc describe packagemanifest` 命令可能会返回来自意外目录的包：

在同一命名空间中安装了多个目录。
这些目录包含相同的操作符或名称相同的操作符。

如果您打算安装的操作符支持 `AllNamespaces` 安装模式，并且您选择使用此模式，请跳过此步骤，因为 `openshift-operators` 命名空间默认情况下已安装相应的 Operator 组，名为 `global-operators`。

如果您打算安装的操作符支持 `SingleNamespace` 安装模式，并且您选择使用此模式，则必须确保在相关命名空间中存在相应的 Operator 组。如果不存在，您可以按照以下步骤创建：

每个命名空间只能有一个 Operator 组。有关更多信息，请参阅“Operator 组”。
1. 为 `SingleNamespace` 安装模式创建一个 `OperatorGroup` 对象 YAML 文件，例如 `operatorgroup.yaml`。
  `SingleNamespace` 安装模式的示例 `OperatorGroup` 对象：
  apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: <operatorgroup_name> namespace: <namespace> (1) spec: targetNamespaces: - <namespace> (1)
  1 对于 `SingleNamespace` 安装模式，请对 `metadata.namespace` 和 `spec.targetNamespaces` 字段使用相同的 `` 值。
2. 创建 `OperatorGroup` 对象。
  $ oc apply -f operatorgroup.yaml

创建 `Subscription` 对象以将命名空间订阅到操作符。

为 `Subscription` 对象创建一个 YAML 文件，例如 `subscription.yaml`。

如果您想订阅特定版本的 Operator，请将startingCSV字段设置为所需版本，并将installPlanApproval字段设置为Manual，以防止 Operator 在目录中存在更高版本时自动升级。详情请参阅以下“具有特定起始 Operator 版本的示例Subscription对象”。

示例Subscription对象

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: <subscription_name>
  namespace: <namespace_per_install_mode> (1)
spec:
  channel: <channel_name> (2)
  name: <operator_name> (3)
  source: <catalog_name> (4)
  sourceNamespace: <catalog_source_namespace> (5)
  config:
    env: (6)
    - name: ARGS
      value: "-v=10"
    envFrom: (7)
    - secretRef:
        name: license-secret
    volumes: (8)
    - name: <volume_name>
      configMap:
        name: <configmap_name>
    volumeMounts: (9)
    - mountPath: <directory_name>
      name: <volume_name>
    tolerations: (10)
    - operator: "Exists"
    resources: (11)
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    nodeSelector: (12)
      foo: bar

1	对于默认的`AllNamespaces`安装模式用法，请指定`openshift-operators`命名空间。或者，如果您已创建自定义全局命名空间，也可以指定它。对于`SingleNamespace`安装模式用法，请指定相关的单个命名空间。
2	要订阅的通道名称。
3	要订阅的 Operator 名称。
4	提供 Operator 的目录源名称。
5	目录源的命名空间。对于默认的 OperatorHub 目录源，请使用`openshift-marketplace`。
6	`env`参数定义了 OLM 创建的 pod 中所有容器中必须存在的一组环境变量。
7	`envFrom`参数定义了一组用于填充容器中环境变量的来源。
8	`volumes`参数定义了 OLM 创建的 pod 上必须存在的一组卷。
9	`volumeMounts`参数定义了 OLM 创建的 pod 中所有容器中必须存在的一组卷挂载。如果`volumeMount`引用了不存在的`volume`，则 OLM 将无法部署 Operator。
10	`tolerations`参数定义了 OLM 创建的 pod 的容忍列表。
11	`resources`参数定义了 OLM 创建的 pod 中所有容器的资源限制。
12	`nodeSelector`参数为 OLM 创建的 pod 定义了`NodeSelector`。

具有特定起始 Operator 版本的示例Subscription对象

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-operator
spec:
  channel: stable-3.7
  installPlanApproval: Manual (1)
  name: example-operator
  source: custom-operators
  sourceNamespace: openshift-marketplace
  startingCSV: example-operator.v3.7.10 (2)

1	如果您的指定版本在目录中被更高版本取代，请将审批策略设置为`Manual`。此计划可防止自动升级到更高版本，并在起始 CSV 完成安装之前需要手动批准。
2	设置特定版本的 Operator CSV。

对于启用了令牌身份验证的云提供商集群（例如 Amazon Web Services (AWS) 安全令牌服务 (STS)、Microsoft Entra 工作负载 ID 或 Google Cloud Platform 工作负载身份），请按照以下步骤配置您的Subscription对象

确保Subscription对象设置为手动更新审批

具有手动更新审批的示例Subscription对象

kind: Subscription
# ...
spec:
  installPlanApproval: Manual (1)

1	不建议使用自动审批更新的订阅，因为在更新之前可能需要进行权限更改。使用手动审批更新的订阅可确保管理员有机会验证更高版本的权限，采取任何必要的步骤，然后进行更新。

在Subscription对象的config部分中包含相关的特定于云提供商的字段
- 如果集群处于 AWS STS 模式，请包含以下字段
  
  包含 AWS STS 变量的示例Subscription对象
  
  kind: Subscription # ... spec: config: env: - name: ROLEARN value: "<role_arn>" (1)
  
  1 包含角色 ARN 详情。
- 如果集群处于工作负载 ID 模式，请包含以下字段
  
  包含工作负载 ID 变量的示例Subscription对象
  
  kind: Subscription # ... spec: config: env: - name: CLIENTID value: "<client_id>" (1) - name: TENANTID value: "<tenant_id>" (2) - name: SUBSCRIPTIONID value: "<subscription_id>" (3)
  
  1 包含客户端 ID。
  
  2 包含租户 ID。
  
  3 包含订阅 ID。
- 如果集群处于 GCP 工作负载身份模式，请包含以下字段
  
  包含 GCP 工作负载身份变量的示例Subscription对象
  
  kind: Subscription # ... spec: config: env: - name: AUDIENCE value: "<audience_url>" (1) - name: SERVICE_ACCOUNT_EMAIL value: "<service_account_email>" (2)
  
  其中
  
  <audience>
  
  由管理员在 GCP 中创建时设置 GCP 工作负载身份，AUDIENCE值必须是以下格式的预格式化 URL
  
  //iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
  
  <service_account_email>
  
  SERVICE_ACCOUNT_EMAIL值是在 Operator 操作期间模拟的 GCP 服务帐户电子邮件，例如
  
  <service_account_name>@<project_id>.iam.gserviceaccount.com

通过运行以下命令创建Subscription对象
```
$ oc apply -f subscription.yaml
```

如果您将installPlanApproval字段设置为Manual，请手动批准挂起的安装计划以完成 Operator 安装。有关更多信息，请参阅“手动批准挂起的 Operator 更新”。

此时，OLM 现在已知晓所选 Operator。目标命名空间中应该会出现 Operator 的集群服务版本 (CSV)，并且 Operator 提供的 API 应该可以创建。

验证

通过运行以下命令检查已安装 Operator 的Subscription对象的状态
```
$ oc describe subscription <subscription_name> -n <namespace>
```
如果您为SingleNamespace安装模式创建了 Operator 组，请通过运行以下命令检查OperatorGroup对象的状态
```
$ oc describe operatorgroup <operatorgroup_name> -n <namespace>
```

其他资源

为多租户集群中 Operator 的多个实例做准备

作为具有dedicated-admin角色的管理员，您可以添加 Operator 的多个实例以在多租户集群中使用。这是使用标准**所有命名空间**安装模式（这可能被认为违反了最小权限原则）或**多命名空间**模式（未被广泛采用）的替代方案。有关更多信息，请参阅“多租户集群中的 Operator”。

在以下过程中，租户是指共享已部署工作负载的一组访问权限和特权的用户或用户组。租户 Operator 是仅供该租户使用的 Operator 实例。

前提条件

您可以作为具有dedicated-admin角色的用户访问集群。
您要安装的所有 Operator 实例在给定集群中必须是同一版本。

有关此信息和其他限制的更多信息，请参阅“多租户集群中的 Operator”。

步骤

在安装 Operator 之前，请为租户 Operator 创建一个与租户命名空间分开的命名空间。您可以通过创建项目来执行此操作。例如，如果租户的命名空间是team1，您可以创建一个team1-operator项目
```
$ oc new-project team1-operator
```
为租户 Operator 创建一个 Operator 组，该组的范围限定为租户的命名空间，并且spec.targetNamespaces列表中只有一个命名空间条目
1. 定义OperatorGroup资源并保存 YAML 文件，例如team1-operatorgroup.yaml
  apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: team1-operatorgroup namespace: team1-operator spec: targetNamespaces: - team1 (1)
  1 仅在spec.targetNamespaces列表中定义租户的命名空间。
2. 通过运行以下命令创建 Operator 组
  $ oc create -f team1-operatorgroup.yaml

后续步骤

在租户 Operator 命名空间中安装 Operator。此任务更易于使用 Web 控制台中的 OperatorHub 而不是 CLI 来执行；有关详细过程，请参阅使用 Web 控制台从 OperatorHub 安装。

完成 Operator 安装后，Operator 将驻留在租户 Operator 命名空间中并监视租户命名空间，但租户无法查看或使用 Operator 的 pod 或其服务帐户。

其他资源

多租户集群中的操作符

在自定义命名空间中安装全局 Operator

使用 OpenShift Dedicated Web 控制台安装 Operators 时，默认行为会将支持**所有命名空间**安装模式的 Operators 安装到默认的全局命名空间 `openshift-operators` 中。这可能会导致所有 Operators 在该命名空间中共享安装计划和更新策略相关的问题。有关这些限制的更多详细信息，请参见“多租户和 Operator 同址部署”。

作为具有 `dedicated-admin` 角色的管理员，您可以通过手动创建自定义全局命名空间并使用该命名空间安装您个人或范围内的 Operators 集及其依赖项来绕过此默认行为。

前提条件

您可以作为具有dedicated-admin角色的用户访问集群。

步骤

在安装 Operator 之前，请为所需 Operator 的安装创建一个命名空间。您可以通过创建一个项目来实现。该项目的命名空间将成为自定义全局命名空间。
```
$ oc new-project global-operators
```
创建一个自定义的全局 Operator 组，这是一个监视所有命名空间的 Operator 组。
1. 定义一个 `OperatorGroup` 资源并保存 YAML 文件，例如 `global-operatorgroup.yaml`。省略 `spec.selector` 和 `spec.targetNamespaces` 字段以使其成为全局 Operator 组，从而选择所有命名空间。
  apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: global-operatorgroup namespace: global-operators
  已创建的全局 Operator 组的 `status.namespaces` 包含空字符串 ("")，这向使用 Operator 发出信号，指示它应该监视所有命名空间。
2. 通过运行以下命令创建 Operator 组
  $ oc create -f global-operatorgroup.yaml

后续步骤

在您的自定义全局命名空间中安装所需的 Operator。由于 Web 控制台在使用自定义全局命名空间安装 Operator 时不会填充**已安装命名空间**菜单，因此此任务只能使用 OpenShift CLI (oc) 执行。有关详细步骤，请参见使用 CLI 从 OperatorHub 安装。

启动 Operator 安装时，如果 Operator 具有依赖项，则这些依赖项也会自动安装在自定义全局命名空间中。因此，依赖项 Operators 具有相同的更新策略和共享安装计划是有效的。

其他资源

多租户和操作符同址部署

Operator 工作负载的 Pod 部署位置

默认情况下，Operator Lifecycle Manager (OLM) 在安装 Operator 或部署 Operand 工作负载时，会在任意工作节点上放置 Pod。作为管理员，您可以使用项目结合节点选择器、污点和容差来控制 Operators 和 Operands 到特定节点的部署位置。

控制 Operator 和 Operand 工作负载的 Pod 部署位置具有以下先决条件：

根据您的要求确定一个或一组要为 Pod 指定的目标节点。如果可用，请记下标识节点或节点的现有标签，例如 `node-role.kubernetes.io/app`。否则，请使用计算机器集或直接编辑节点来添加标签，例如 `myoperator`。您将在后面的步骤中将此标签用作项目的节点选择器。
如果您想确保只有具有特定标签的 Pod 才能在节点上运行，同时将无关的工作负载引导到其他节点，请使用计算机器集或直接编辑节点来向节点添加污点。使用确保不匹配污点的新的 Pod 无法在节点上调度的效果。例如，`myoperator:NoSchedule` 污点确保不匹配污点的新的 Pod 不会调度到该节点，但允许节点上现有的 Pod 保持不变。
创建一个配置了默认节点选择器（如果添加了污点，则配置了匹配的容差）的项目。

此时，您可以使用创建的项目在以下情况下将 Pod 引导到指定的节点：

对于 Operator Pod：: 管理员可以按照下一节中的说明在项目中创建 `Subscription` 对象。因此，Operator Pod 将部署到指定的节点。
对于 Operand Pod：: 使用已安装的 Operator，用户可以在项目中创建应用程序，这会将 Operator 拥有的自定义资源 (CR) 置于项目中。因此，Operand Pod 将部署到指定的节点，除非 Operator 在其他命名空间中部署集群范围的对象或资源，在这种情况下，此自定义 Pod 部署位置不适用。

其他资源

创建项目范围的节点选择器

控制 Operator 的安装位置

默认情况下，安装 Operator 时，OpenShift Dedicated 会将 Operator Pod 随机安装到您的一个工作节点上。但是，在某些情况下，您可能希望将该 Pod 调度到特定节点或一组节点上。

以下示例描述了您可能希望将 Operator Pod 调度到特定节点或一组节点的情况：

如果您希望一起工作的 Operators 调度到同一主机或位于同一机架上的主机上。
如果您希望 Operators 分散在整个基础架构中，以避免因网络或硬件问题导致停机。

您可以通过向 Operator 的 `Subscription` 对象添加节点亲和性、Pod 亲和性或 Pod 反亲和性约束来控制 Operator Pod 的安装位置。节点亲和性是由调度程序用于确定可以在何处放置 Pod 的一组规则。Pod 亲和性使您可以确保相关的 Pod 调度到同一节点。Pod 反亲和性允许您阻止 Pod 调度到节点上。

以下示例演示如何使用节点亲和性或 Pod 反亲和性将自定义指标自动缩放 Operator 的实例安装到集群中的特定节点。

将 Operator Pod 部署到特定节点的节点亲和性示例：

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: (1)
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-163-94.us-west-2.compute.internal
#...

1	需要将 Operator 的 Pod 调度到名为 `ip-10-0-163-94.us-west-2.compute.internal` 的节点上的节点亲和性。

将 Operator Pod 部署到具有特定平台的节点的节点亲和性示例：

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: (1)
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/arch
              operator: In
              values:
              - arm64
            - key: kubernetes.io/os
              operator: In
              values:
              - linux
#...

1	需要将 Operator 的 Pod 调度到具有 `kubernetes.io/arch=arm64` 和 `kubernetes.io/os=linux` 标签的节点上的节点亲和性。

将 Operator Pod 部署到一个或多个特定节点的 Pod 亲和性示例：

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAffinity: (1)
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - test
          topologyKey: kubernetes.io/hostname
#...

1	将 Operator 的 Pod 部署到具有 `app=test` 标签的 Pod 所在节点上的 Pod 亲和性。

阻止 Operator Pod 部署到一个或多个特定节点的 Pod 反亲和性示例：

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAntiAffinity: (1)
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: cpu
              operator: In
              values:
              - high
          topologyKey: kubernetes.io/hostname
#...

1	阻止 Operator 的 Pod 调度到具有 `cpu=high` 标签的 Pod 所在节点上的 Pod 反亲和性。

步骤

要控制 Operator Pod 的部署位置，请完成以下步骤：

照常安装 Operator。
如果需要，请确保您的节点已标记，以便正确响应亲和性。

编辑 Operator `Subscription` 对象以添加亲和性。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity: (1)
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-185-229.ec2.internal
#...

1	添加 `nodeAffinity`、`podAffinity` 或 `podAntiAffinity`。有关创建亲和性的信息，请参见后面的附加资源部分。

验证

要确保 Pod 部署到特定节点，请运行以下命令：

$ oc get pods -o wide

示例输出

NAME                                                  READY   STATUS    RESTARTS   AGE   IP            NODE                           NOMINATED NODE   READINESS GATES
custom-metrics-autoscaler-operator-5dcc45d656-bhshg   1/1     Running   0          50s   10.131.0.20   ip-10-0-185-229.ec2.internal   <none>           <none>

其他资源

1	包含客户端 ID。
2	包含租户 ID。
3	包含订阅 ID。

向集群添加 Operators

关于使用 OperatorHub 安装 Operator

使用 Web 控制台从 OperatorHub 安装

使用 CLI 从 OperatorHub 安装

为多租户集群中 Operator 的多个实例做准备

在自定义命名空间中安装全局 Operator

Operator 工作负载的 Pod 部署位置

控制 Operator 的安装位置