OpenShift 文档正在迁移，很快将只能在 docs.redhat.com（所有 Red Hat 产品文档的所在地）访问。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

向集群添加 Operators

编辑

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

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

关于使用 OperatorHub 安装 Operator

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

作为 `dedicated-admin`，您可以使用 AWS 上的 Red Hat OpenShift 服务 Web 控制台或 CLI 从 OperatorHub 安装 Operator。将 Operator 订阅到一个或多个命名空间可使开发人员在您的集群上使用该 Operator。

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

安装模式

选择 **集群上的所有命名空间（默认）** 以将 Operator 安装到所有命名空间，或者选择单个命名空间（如果可用）仅将 Operator 安装到选定的命名空间。此示例选择 **所有命名空间…** 以使所有用户和项目都可以使用该 Operator。

更新渠道

如果 Operator 可通过多个渠道获得，您可以选择要订阅的渠道。例如，要从 **稳定** 渠道部署（如果可用），请从列表中选择它。

批准策略

您可以选择自动或手动更新。

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

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

其他资源
编辑

使用 Web 控制台从 OperatorHub 安装

您可以使用 AWS 上的 Red Hat OpenShift 服务 Web 控制台从 OperatorHub 安装和订阅 Operator。

先决条件

  • 使用具有 `dedicated-admin` 角色的帐户访问 AWS 上的 Red Hat OpenShift 服务集群。

步骤

  1. 在 Web 控制台中导航到 **Operators → OperatorHub** 页面。

  2. 滚动或在 **按关键字筛选** 框中键入关键字以查找所需的 Operator。例如，键入 `advanced` 以查找 Kubernetes 的高级集群管理 Operator。

    您还可以按 **基础架构功能** 筛选选项。例如，如果您想查看在断开连接的环境（也称为受限网络环境）中工作的 Operator，请选择 **断开连接**。

  3. 选择 Operator 以显示其他信息。

    选择社区 Operator 会发出警告，说明 Red Hat 不对社区 Operator 进行认证；您必须在继续之前确认该警告。

  4. 阅读有关 Operator 的信息，然后单击 **安装**。

  5. 在 **安装 Operator** 页面上，配置您的 Operator 安装

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

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

      使用 **手动** 批准安装 Operator 会导致在命名空间中安装的所有 Operator 都使用 **手动** 批准策略，并且所有 Operator 都会一起更新。如果要独立更新 Operator，请将 Operator 安装到单独的命名空间。

    2. 确认 Operator 的安装模式

      • 集群上的所有命名空间（默认） 将操作符安装在默认的 openshift-operators 命名空间中，以便监视并使其可用于集群中的所有命名空间。此选项并非始终可用。

      • 集群上的特定命名空间 允许您选择一个特定的单个命名空间来安装操作符。该操作符将仅监视并可用于此单个命名空间。

    3. 对于启用了令牌身份验证的云提供商上的集群

      • 如果集群使用 AWS 安全令牌服务（Web 控制台中的STS 模式），请在角色 ARN 字段中输入您的服务帐户的 AWS IAM 角色的 Amazon 资源名称 (ARN)。要创建角色的 ARN，请按照准备 AWS 帐户中描述的步骤操作。

      • 如果集群使用 Microsoft Entra 工作负载 ID（Web 控制台中的工作负载身份/联合身份模式），请在相应的字段中添加客户端 ID、租户 ID 和订阅 ID。

      • 如果集群使用 Google Cloud Platform 工作负载身份（Web 控制台中的GCP 工作负载身份/联合身份模式），请在相应的字段中添加项目编号、池 ID、提供商 ID 和服务帐户电子邮件。

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

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

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

  6. 单击安装以使操作符可用于此 Red Hat OpenShift Service on AWS 集群上选择的命名空间。

    1. 如果您选择了手动审批策略，则订阅的升级状态将保持为正在升级状态，直到您查看并批准安装计划。

      在安装计划页面上批准后，订阅升级状态将变为最新。

    2. 如果您选择了自动审批策略，则升级状态应在无需干预的情况下变为最新。

验证

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

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

    如果未成功

    • 检查工作负载→Pod页面上openshift-operators项目（或如果选择了特定命名空间…安装模式，则为其他相关命名空间）中报告问题的任何 Pod 的日志，以进行进一步的故障排除。

  • 安装操作符后，元数据将指示已安装的通道和版本。

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

使用 CLI 从 OperatorHub 安装

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

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

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

  • 使用具有 `dedicated-admin` 角色的帐户访问 AWS 上的 Red Hat OpenShift 服务集群。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 查看 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
# ...

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

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

    $ 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命令可能会返回来自意外目录的包

      • 在同一命名空间中安装了多个目录。

      • 这些目录包含相同操作符或名称相同的操作符。

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

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

    每个命名空间只能有一个操作符组。有关更多信息，请参阅“操作符组”。

    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字段使用相同的<namespace>值。

    2. 创建OperatorGroup对象

      $ oc apply -f operatorgroup.yaml

  4. 创建一个Subscription对象以将命名空间订阅到操作符。

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

      如果您想订阅操作符的特定版本，请将startingCSV字段设置为所需的版本，并将installPlanApproval字段设置为Manual，以防止操作符在目录中存在更高版本时自动升级。有关详细信息，请参阅以下“具有特定起始操作符版本的示例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 要订阅的操作符的名称。
      4 提供操作符的目录源的名称。
      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 的特定版本。

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

      1. 确保将Subscription 对象设置为手动更新批准

        带有手动更新批准的Subscription 对象示例 
        kind: Subscription
# ...
spec:
  installPlanApproval: Manual (1)
        1 不建议使用自动审批更新的订阅，因为在更新之前可能需要进行权限更改。使用手动审批更新的订阅可确保管理员有机会验证更高版本的权限，采取任何必要的步骤，然后进行更新。

      2. 在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

    3. 运行以下命令创建Subscription 对象

      $ oc apply -f subscription.yaml

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

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

验证

  1. 运行以下命令检查已安装 Operator 的Subscription 对象的状态

    $ oc describe subscription <subscription_name> -n <namespace>

  2. 如果您为SingleNamespace安装模式创建了 Operator 组，请运行以下命令检查OperatorGroup对象的状态

    $ oc describe operatorgroup <operatorgroup_name> -n <namespace>
其他资源
编辑

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

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

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

先决条件

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

  • 您想要安装的所有 Operator 实例在给定集群中必须具有相同的版本。

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

  1. 在安装 Operator 之前，为租户 Operator 创建一个与租户命名空间分开的命名空间。您可以通过创建项目来实现这一点。例如，如果租户的命名空间是team1，您可以创建一个team1-operator项目

    $ oc new-project team1-operator

  2. 为租户 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

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

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

先决条件

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

步骤

  1. 在安装 Operator 之前，为所需 Operator 的安装创建一个命名空间。您可以通过创建项目来实现这一点。此项目的命名空间将成为自定义全局命名空间

    $ oc new-project global-operators

  2. 创建一个自定义的全局 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 具有依赖项，则这些依赖项也会自动安装在自定义全局命名空间中。因此，依赖项 Operator 具有相同的更新策略和共享安装计划是有效的。
其他资源
编辑

Operator 工作负载的 Pod 部署

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

控制 Operator 和 Operand 工作负载的 Pod 部署具有以下前提条件

  1. 根据您的需求，确定要为 Pod 指定的目标节点或节点集。如果可用，请记下标识节点的现有标签，例如 node-role.kubernetes.io/app。否则，请使用计算机器集或直接编辑节点来添加标签，例如 myoperator。您将在后续步骤中将此标签用作项目上的节点选择器。

  2. 如果您想确保只有具有特定标签的 Pod 才能在节点上运行，同时将无关的工作负载引导到其他节点，请使用计算机器集或直接编辑节点来向节点添加污点。使用确保不匹配污点的新的 Pod 无法在节点上调度的效果。例如，myoperator:NoSchedule 污点确保不匹配污点的新的 Pod 不会调度到该节点，但允许节点上现有的 Pod 保持不变。

  3. 创建一个配置了默认节点选择器（如果您添加了污点，则还需要匹配的容忍度）的项目。

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

对于 Operator Pod

管理员可以在项目中创建 Subscription 对象，如下节所述。这样，Operator Pod 就会部署到指定的节点上。

对于 Operand Pod

使用已安装的 Operator，用户可以在项目中创建应用程序，这会将 Operator 拥有的自定义资源 (CR) 放置在项目中。这样，Operand Pod 就会部署到指定的节点上，除非 Operator 在其他命名空间中部署集群范围的对象或资源，在这种情况下，此自定义 Pod 部署将不适用。

其他资源
编辑

控制 Operator 的安装位置

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

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

  • 如果您希望一起工作的 Operator 调度到同一主机或位于同一机架上的主机上

  • 如果您希望 Operator 分散在整个基础架构中，以避免因网络或硬件问题导致的停机

您可以通过向 Operator 的 Subscription 对象添加节点亲和性、Pod 亲和性或 Pod 反亲和性约束来控制 Operator Pod 的安装位置。节点亲和性是一组规则，调度程序使用这些规则来确定 Pod 的部署位置。Pod 亲和性使您可以确保将相关的 Pod 调度到同一节点。Pod 反亲和性允许您防止 Pod 被调度到节点上。

以下示例展示了如何使用节点亲和性或 Pod 反亲和性将 Custom Metrics Autoscaler 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 的部署位置，请完成以下步骤

  1. 照常安装 Operator。

  2. 如果需要，请确保您的节点已标记，以便正确响应亲和性。

  3. 编辑 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>
其他资源