创建基础架构机器集 | 机器管理 | OpenShift Container Platform 4.17

OpenShift Container Platform 基础设施组件
为生产环境创建基础设施机器集
将机器集资源分配给基础设施节点
- 使用污点和容忍度绑定基础设施节点工作负载
将资源移动到基础设施机器集

只有在 Machine API 可运行的集群中才能使用高级机器管理和扩展功能。具有用户预配基础设施的集群需要额外的验证和配置才能使用 Machine API。

具有基础设施平台类型 `none` 的集群无法使用 Machine API。即使连接到集群的计算机器安装在支持此功能的平台上，此限制也适用。此参数安装后无法更改。

要查看集群的平台类型，请运行以下命令：

$ oc get infrastructure cluster -o jsonpath='{.status.platform}'

您可以使用基础设施机器集创建仅托管基础设施组件（例如默认路由器、集成容器镜像注册表以及集群指标和监控组件）的机器。这些基础设施机器不计入运行环境所需的订阅总数。

在生产部署中，建议您部署至少三个机器集来容纳基础设施组件。Red Hat OpenShift Service Mesh 部署 Elasticsearch，这需要在不同的节点上安装三个实例。为了实现高可用性，可以将这些节点中的每一个部署到不同的可用区。此配置需要三个不同的机器集，每个可用区一个。在没有多个可用区的全球 Azure 区域中，您可以使用可用性集来确保高可用性。

OpenShift Container Platform 基础设施组件

每个自管理的 Red Hat OpenShift 订阅都包含 OpenShift Container Platform 和其他与 OpenShift 相关的组件的权利。这些权利包含用于运行 OpenShift Container Platform 控制平面和基础设施工作负载，在调整大小期间无需考虑。

要符合基础设施节点的条件并使用包含的权利，只有支持集群的组件（而不是最终用户应用程序的一部分）才能在这些实例上运行。示例包括以下组件：

Kubernetes 和 OpenShift Container Platform 控制平面服务
默认路由器
集成容器镜像注册表
基于 HAProxy 的 Ingress 控制器
集群指标收集或监控服务，包括用于监控用户定义项目的组件
集群聚合日志
Red Hat Quay
Red Hat OpenShift 数据基金会
Red Hat Advanced Cluster Management for Kubernetes
Red Hat Advanced Cluster Security for Kubernetes
Red Hat OpenShift GitOps
Red Hat OpenShift Pipelines
Red Hat OpenShift Service Mesh

运行任何其他容器、Pod 或组件的任何节点都是您的订阅必须涵盖的工作节点。

有关基础设施节点以及哪些组件可以在基础设施节点上运行的信息，请参阅企业 Kubernetes 的 OpenShift 规模和订阅指南文档中的“Red Hat OpenShift 控制平面和基础设施节点”部分。

要创建基础设施节点，您可以使用机器集、标记节点或使用机器配置池。

为生产环境创建基础设施机器集

在生产部署中，建议您部署至少三个计算机器集来容纳基础设施组件。Red Hat OpenShift Service Mesh 部署 Elasticsearch，这需要在不同的节点上安装三个实例。为了实现高可用性，可以将这些节点分别部署到不同的可用区。这种配置需要三个不同的计算机器集，每个可用区一个。在没有多个可用区的全球 Azure 区域中，您可以使用可用性集来确保高可用性。

为不同的云创建基础设施机器集

使用适合您云的示例计算机器集。

AWS 上计算机器集自定义资源的示例 YAML

此示例 YAML 定义一个在us-east-1a Amazon Web Services (AWS) 本地区域中运行的计算机器集，并创建标记为node-role.kubernetes.io/infra: ""的节点。

在此示例中，<infrastructure_id>是基于您在配置集群时设置的集群 ID 的基础设施 ID 标签，<infra>是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
  name: <infrastructure_id>-infra-<zone> (2)
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: infra (3)
        machine.openshift.io/cluster-api-machine-type: infra
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone>
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          ami:
            id: ami-046fe691f52a953f9 (4)
          apiVersion: machine.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone> (6)
            region: <region> (7)
          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-node
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-lb
          subnet:
            filters:
              - name: tag:Name
                values:
                  - <infrastructure_id>-private-<zone> (8)
          tags:
            - name: kubernetes.io/cluster/<infrastructure_id>
              value: owned
            - name: <custom_tag_name> (5)
              value: <custom_tag_value>
          userDataSecret:
            name: worker-user-data
      taints: (9)
        - key: node-role.kubernetes.io/infra
          effect: NoSchedule

指定基于您在预配集群时设置的集群 ID 的基础设施 ID。如果您已安装 OpenShift CLI，则可以通过运行以下命令获取基础设施 ID：

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

2 指定基础设施 ID、infra 角色节点标签和区域。

3 指定infra角色节点标签。

为您的 AWS 区域中的 OpenShift Container Platform 节点指定有效的 Red Hat Enterprise Linux CoreOS (RHCOS) Amazon 机器镜像 (AMI)。如果您想使用 AWS Marketplace 镜像，则必须从AWS Marketplace完成 OpenShift Container Platform 订阅以获取您所在区域的 AMI ID。

$ oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}{"\n"}' \
    get machineset/<infrastructure_id>-<role>-<zone>

可选：为您的集群指定自定义标签数据。例如，您可以通过指定Email:[email protected]的name:value对来添加管理员联系电子邮件地址。

自定义标签也可以在install-config.yml文件中安装期间指定。如果install-config.yml文件和机器集包含具有相同name数据的标签，则机器集的标签值优先于install-config.yml文件中的标签值。

6 指定区域，例如us-east-1a。

7 指定区域，例如us-east-1。

8 指定基础设施 ID 和区域。

指定污点以防止在infra节点上调度用户工作负载。

在基础设施节点上添加NoSchedule污点后，在该节点上运行的现有 DNS Pod 将被标记为misscheduled。您必须删除或在misscheduled DNS Pod 上添加容忍度。

在 AWS 上运行的机器集支持非保证的Spot 实例。与 AWS 上的按需实例相比，使用 Spot 实例可以节省成本。通过向MachineSet YAML 文件添加spotMarketOptions来配置 Spot 实例。

Azure 上计算机器集自定义资源的示例 YAML

此示例 YAML 定义一个在区域中的1 Microsoft Azure 区域中运行的计算机器集，并创建标记为node-role.kubernetes.io/infra: ""的节点。

在此示例中，<infrastructure_id>是基于您在配置集群时设置的集群 ID 的基础设施 ID 标签，infra是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
    machine.openshift.io/cluster-api-machine-role: infra (2)
    machine.openshift.io/cluster-api-machine-type: infra
  name: <infrastructure_id>-infra-<region> (3)
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region>
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: infra
        machine.openshift.io/cluster-api-machine-type: infra
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region>
    spec:
      metadata:
        creationTimestamp: null
        labels:
          machine.openshift.io/cluster-api-machineset: <machineset_name>
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image: (4)
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/galleries/gallery_<infrastructure_id>/images/<infrastructure_id>-gen2/versions/latest (5)
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region> (6)
          managedIdentity: <infrastructure_id>-identity
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg
          sshPrivateKey: ""
          sshPublicKey: ""
          tags:
            - name: <custom_tag_name> (7)
              value: <custom_tag_value>
          subnet: <infrastructure_id>-<role>-subnet
          userDataSecret:
            name: worker-user-data
          vmSize: Standard_D4s_v3
          vnet: <infrastructure_id>-vnet
          zone: "1" (8)
      taints: (9)
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

指定基于您在预配集群时设置的集群 ID 的基础设施 ID。如果您已安装 OpenShift CLI，则可以通过运行以下命令获取基础设施 ID：

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

您可以通过运行以下命令获取子网：

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1

您可以通过运行以下命令获取虚拟网络：

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1

2 指定infra节点标签。

3 指定基础设施 ID、infra 节点标签和区域。

4 指定计算机器集的镜像详细信息。如果您想使用 Azure Marketplace 镜像，请参阅“选择 Azure Marketplace 镜像”。

5 指定与您的实例类型兼容的镜像。安装程序创建的 Hyper-V 第 2 代镜像具有-gen2后缀，而第 1 代镜像具有相同名称，但没有后缀。

6 指定放置机器的区域。

7 可选：在您的机器集中指定自定义标签。在<custom_tag_name>字段中提供标签名称，在<custom_tag_value>字段中提供相应的标签值。

8 指定在其中放置机器的区域内的区域。请确保您指定的区域支持该区域。

指定污点以防止在 infra 节点上调度用户工作负载。

在基础设施节点上添加NoSchedule污点后，在该节点上运行的现有 DNS Pod 将被标记为misscheduled。您必须删除或在misscheduled DNS Pod 上添加容忍度。

在 Azure 上运行的机器集支持非保证的Spot VM。与 Azure 上的标准 VM 相比，使用 Spot VM 可以节省成本。您可以通过向MachineSet YAML 文件添加spotVMOptions来配置 Spot VM。

其他资源

选择 Azure Marketplace 镜像

Azure Stack Hub 上计算机器集自定义资源的示例 YAML

此示例 YAML 定义一个在区域中的1 Microsoft Azure 区域中运行的计算机器集，并创建标记为node-role.kubernetes.io/infra: ""的节点。

在此示例中，<infrastructure_id>是基于您在配置集群时设置的集群 ID 的基础设施 ID 标签，<infra>是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
    machine.openshift.io/cluster-api-machine-role: <infra> (2)
    machine.openshift.io/cluster-api-machine-type: <infra> (2)
  name: <infrastructure_id>-infra-<region> (3)
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> (3)
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
        machine.openshift.io/cluster-api-machine-role: <infra> (2)
        machine.openshift.io/cluster-api-machine-type: <infra> (2)
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> (3)
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: "" (2)
      taints: (4)
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          availabilitySet: <availability_set> (6)
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/images/<infrastructure_id> (1)
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region> (5)
          managedIdentity: <infrastructure_id>-identity (1)
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg (1)
          sshPrivateKey: ""
          sshPublicKey: ""
          subnet: <infrastructure_id>-<role>-subnet  (1) (2)
          userDataSecret:
            name: worker-user-data (2)
          vmSize: Standard_DS4_v2
          vnet: <infrastructure_id>-vnet (1)
          zone: "1" (7)

指定基于您在预配集群时设置的集群 ID 的基础设施 ID。如果您已安装 OpenShift CLI，则可以通过运行以下命令获取基础设施 ID：

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

您可以通过运行以下命令获取子网：

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1

您可以通过运行以下命令获取虚拟网络：

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1

2 指定<infra>节点标签。

3 指定基础设施 ID、<infra>节点标签和区域。

指定污点以防止在 infra 节点上调度用户工作负载。

在基础设施节点上添加NoSchedule污点后，在该节点上运行的现有 DNS Pod 将被标记为misscheduled。您必须删除或在misscheduled DNS Pod 上添加容忍度。

5 指定放置机器的区域。

6 指定集群的可用性集。

7 指定在其中放置机器的区域内的区域。请确保您指定的区域支持该区域。

在 Azure Stack Hub 上运行的机器集不支持非保证的 Spot VM。

IBM Cloud 上计算机器集自定义资源的示例 YAML

此示例 YAML 定义一个在指定的 IBM Cloud® 区域中的区域中运行的计算机器集，并创建标记为node-role.kubernetes.io/infra: ""的节点。

在此示例中，<infrastructure_id>是基于您在配置集群时设置的集群 ID 的基础设施 ID 标签，<infra>是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
    machine.openshift.io/cluster-api-machine-role: <infra> (2)
    machine.openshift.io/cluster-api-machine-type: <infra> (2)
  name: <infrastructure_id>-<infra>-<region> (3)
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<region> (3)
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
        machine.openshift.io/cluster-api-machine-role: <infra> (2)
        machine.openshift.io/cluster-api-machine-type: <infra> (2)
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<region> (3)
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: ibmcloudproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: ibmcloud-credentials
          image: <infrastructure_id>-rhcos (4)
          kind: IBMCloudMachineProviderSpec
          primaryNetworkInterface:
              securityGroups:
              - <infrastructure_id>-sg-cluster-wide
              - <infrastructure_id>-sg-openshift-net
              subnet: <infrastructure_id>-subnet-compute-<zone> (5)
          profile: <instance_profile> (6)
          region: <region> (7)
          resourceGroup: <resource_group> (8)
          userDataSecret:
              name: <role>-user-data (2)
          vpc: <vpc_name> (9)
          zone: <zone> (10)
        taints: (11)
        - key: node-role.kubernetes.io/infra
          effect: NoSchedule

基于您在准备集群时设置的集群 ID 的基础架构 ID。如果您已安装 OpenShift CLI，则可以通过运行以下命令获取基础架构 ID。

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

2 <infra> 节点标签。

3 基础架构 ID、<infra> 节点标签和区域。

4 用于集群安装的自定义 Red Hat Enterprise Linux CoreOS (RHCOS) 镜像。

5 基础架构 ID 和您区域内的可用区，用于放置机器。请确保您的区域支持您指定的可用区。

6 指定 IBM Cloud® 实例配置文件。

7 指定放置机器的区域。

8 放置机器资源的资源组。这是安装时指定的现有资源组，或者是以基础架构 ID 为名的安装程序创建的资源组。

9 VPC 名称。

10 指定在其中放置机器的区域内的区域。请确保您指定的区域支持该区域。

阻止用户工作负载在基础设施节点上调度的污点。

在基础设施节点上添加NoSchedule污点后，在该节点上运行的现有 DNS Pod 将被标记为misscheduled。您必须删除或在misscheduled DNS Pod 上添加容忍度。

GCP 上计算机器集自定义资源的 YAML 示例

此 YAML 示例定义了一个在 Google Cloud Platform (GCP) 上运行的计算机器集，并创建带有 node-role.kubernetes.io/infra: "" 标签的节点，其中 infra 是要添加的节点标签。

使用 OpenShift CLI 获取的值

在以下示例中，您可以使用 OpenShift CLI 获取集群的一些值。

基础架构 ID

<infrastructure_id> 字符串是基于您在准备集群时设置的集群 ID 的基础架构 ID。如果您已安装 OpenShift CLI，则可以通过运行以下命令获取基础架构 ID。

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

镜像路径

<path_to_image> 字符串是用于创建磁盘的镜像的路径。如果您已安装 OpenShift CLI，则可以通过运行以下命令获取镜像路径。

$ oc -n openshift-machine-api \
  -o jsonpath='{.spec.template.spec.providerSpec.value.disks[0].image}{"\n"}' \
  get machineset/<infrastructure_id>-worker-a

GCP MachineSet 值示例

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
  name: <infrastructure_id>-w-a
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <infra> (2)
        machine.openshift.io/cluster-api-machine-type: <infra>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: gcpprovider.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <path_to_image> (3)
            labels: null
            sizeGb: 128
            type: pd-ssd
          gcpMetadata: (4)
          - key: <custom_metadata_key>
            value: <custom_metadata_value>
          kind: GCPMachineProviderSpec
          machineType: n1-standard-4
          metadata:
            creationTimestamp: null
          networkInterfaces:
          - network: <infrastructure_id>-network
            subnetwork: <infrastructure_id>-worker-subnet
          projectID: <project_name> (5)
          region: us-central1
          serviceAccounts: (6)
          - email: <infrastructure_id>-w@<project_name>.iam.gserviceaccount.com
            scopes:
            - https://www.googleapis.com/auth/cloud-platform
          tags:
            - <infrastructure_id>-worker
          userDataSecret:
            name: worker-user-data
          zone: us-central1-a
      taints: (7)
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

1 对于 <infrastructure_id>，请指定基于您在准备集群时设置的集群 ID 的基础架构 ID。

2 对于 <infra>，请指定 <infra> 节点标签。

指定当前计算机器集中使用的镜像的路径。

要使用 GCP Marketplace 镜像，请指定要使用的产品。

OpenShift Container Platform：https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-413-x86-64-202305021736
OpenShift Platform Plus：https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-413-x86-64-202305021736
OpenShift Kubernetes Engine：https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-413-x86-64-202305021736

4 可选：以 key:value 对的形式指定自定义元数据。有关用例，请参阅 GCP 关于设置自定义元数据的文档。

5 对于 <project_name>，请指定您用于集群的 GCP 项目的名称。

6 指定单个服务帐户。不支持多个服务帐户。

指定污点以防止在 infra 节点上调度用户工作负载。

在基础设施节点上添加NoSchedule污点后，在该节点上运行的现有 DNS Pod 将被标记为misscheduled。您必须删除或在misscheduled DNS Pod 上添加容忍度。

在 GCP 上运行的机器集支持非保证的抢占式虚拟机实例。与 GCP 上的普通实例相比，使用抢占式虚拟机实例可以节省成本。您可以配置抢占式虚拟机实例，方法是在 MachineSet YAML 文件中添加 preemptible。

Nutanix 上计算机器集自定义资源的 YAML 示例

此 YAML 示例定义了一个 Nutanix 计算机器集，该机器集创建带有 node-role.kubernetes.io/infra: "" 标签的节点。

在此示例中，<infrastructure_id>是基于您在配置集群时设置的集群 ID 的基础设施 ID 标签，<infra>是要添加的节点标签。

使用 OpenShift CLI 获取的值

在以下示例中，您可以使用 OpenShift CLI (oc) 获取集群的一些值。

基础架构 ID

<infrastructure_id> 字符串是基于您在准备集群时设置的集群 ID 的基础架构 ID。如果您已安装 OpenShift CLI，则可以通过运行以下命令获取基础架构 ID。

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
    machine.openshift.io/cluster-api-machine-role: <infra> (2)
    machine.openshift.io/cluster-api-machine-type: <infra>
  name: <infrastructure_id>-<infra>-<zone> (3)
  namespace: openshift-machine-api
  annotations: (4)
    machine.openshift.io/memoryMb: "16384"
    machine.openshift.io/vCPU: "4"
spec:
  replicas: 3
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <infra>
        machine.openshift.io/cluster-api-machine-type: <infra>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone>
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          bootType: "" (5)
          categories: (6)
          - key: <category_name>
            value: <category_value>
          cluster: (7)
            type: uuid
            uuid: <cluster_uuid>
          credentialsSecret:
            name: nutanix-credentials
          image:
            name: <infrastructure_id>-rhcos (8)
            type: name
          kind: NutanixMachineProviderConfig
          memorySize: 16Gi (9)
          project: (10)
            type: name
            name: <project_name>
          subnets:
          - type: uuid
            uuid: <subnet_uuid>
          systemDiskSize: 120Gi (11)
          userDataSecret:
            name: <user_data_secret> (12)
          vcpuSockets: 4 (13)
          vcpusPerSocket: 1 (14)
      taints: (15)
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

1 对于 <infrastructure_id>，请指定基于您在准备集群时设置的集群 ID 的基础架构 ID。

2 指定<infra>节点标签。

3 指定基础架构 ID、<infra> 节点标签和可用区。

4 集群自动缩放器的注释。

指定计算机器使用的启动类型。有关启动类型的更多信息，请参阅了解虚拟化环境中的 UEFI、安全启动和 TPM。有效值为 Legacy、SecureBoot 或 UEFI。默认为 Legacy。

在 OpenShift Container Platform 4.17 中，必须使用 Legacy 启动类型。

6 指定要应用于计算机器的一个或多个 Nutanix Prism 类别。此部分需要 key 和 value 参数，用于 Prism Central 中存在的类别键值对。有关类别的更多信息，请参阅类别管理。

7 指定 Nutanix Prism Element 集群配置。在此示例中，集群类型为 uuid，因此存在 uuid 部分。

8 指定要使用的镜像。使用集群中现有默认计算机器集中的镜像。

9 指定集群的内存量（以 Gi 为单位）。

10 指定您用于集群的 Nutanix 项目。在此示例中，项目类型为 name，因此存在 name 部分。

11 指定系统磁盘的大小（以 Gi 为单位）。

12 指定用户数据 YAML 文件中位于 openshift-machine-api 命名空间中的密钥的名称。使用安装程序在默认计算机器集中填充的值。

13 指定 vCPU 套接字的数量。

14 指定每个套接字的 vCPU 数量。

指定污点以防止在 infra 节点上调度用户工作负载。

在基础设施节点上添加NoSchedule污点后，在该节点上运行的现有 DNS Pod 将被标记为misscheduled。您必须删除或在misscheduled DNS Pod 上添加容忍度。

RHOSP 上计算机器集自定义资源的 YAML 示例

此 YAML 示例定义了一个在 Red Hat OpenStack Platform (RHOSP) 上运行的计算机器集，并创建带有 node-role.kubernetes.io/infra: "" 标签的节点。

在此示例中，<infrastructure_id>是基于您在配置集群时设置的集群 ID 的基础设施 ID 标签，<infra>是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
    machine.openshift.io/cluster-api-machine-role: <infra> (2)
    machine.openshift.io/cluster-api-machine-type: <infra> (2)
  name: <infrastructure_id>-infra (3)
  namespace: openshift-machine-api
spec:
  replicas: <number_of_replicas>
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra (3)
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
        machine.openshift.io/cluster-api-machine-role: <infra> (2)
        machine.openshift.io/cluster-api-machine-type: <infra> (2)
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra (3)
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: ""
      taints: (4)
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1alpha1
          cloudName: openstack
          cloudsSecret:
            name: openstack-cloud-credentials
            namespace: openshift-machine-api
          flavor: <nova_flavor>
          image: <glance_image_name_or_location>
          serverGroupID: <optional_UUID_of_server_group> (5)
          kind: OpenstackProviderSpec
          networks: (6)
          - filter: {}
            subnets:
            - filter:
                name: <subnet_name>
                tags: openshiftClusterID=<infrastructure_id> (1)
          primarySubnet: <rhosp_subnet_UUID> (7)
          securityGroups:
          - filter: {}
            name: <infrastructure_id>-worker (1)
          serverMetadata:
            Name: <infrastructure_id>-worker (1)
            openshiftClusterID: <infrastructure_id> (1)
          tags:
          - openshiftClusterID=<infrastructure_id> (1)
          trunk: true
          userDataSecret:
            name: worker-user-data (2)
          availabilityZone: <optional_openstack_availability_zone>

指定基于您在预配集群时设置的集群 ID 的基础设施 ID。如果您已安装 OpenShift CLI，则可以通过运行以下命令获取基础设施 ID：

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

2 指定<infra>节点标签。

3 指定基础架构 ID 和 <infra> 节点标签。

指定污点以防止在 infra 节点上调度用户工作负载。

在基础设施节点上添加NoSchedule污点后，在该节点上运行的现有 DNS Pod 将被标记为misscheduled。您必须删除或在misscheduled DNS Pod 上添加容忍度。

5 要为 MachineSet 设置服务器组策略，请输入从创建服务器组返回的值。对于大多数部署，建议使用 anti-affinity 或 soft-anti-affinity 策略。

6 对于多网络部署是必需的。如果部署到多个网络，此列表必须包含用作 primarySubnet 值的网络。

7 指定您希望节点端点发布到的 RHOSP 子网。通常，这与 install-config.yaml 文件中 machinesSubnet 值使用的子网相同。

vSphere 上计算机器集自定义资源的 YAML 示例

此 YAML 示例定义了一个在 VMware vSphere 上运行的计算机器集，并创建带有 node-role.kubernetes.io/infra: "" 标签的节点。

在此示例中，<infrastructure_id>是基于您在配置集群时设置的集群 ID 的基础设施 ID 标签，<infra>是要添加的节点标签。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  creationTimestamp: null
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
  name: <infrastructure_id>-infra (2)
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra (2)
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
        machine.openshift.io/cluster-api-machine-role: <infra> (3)
        machine.openshift.io/cluster-api-machine-type: <infra> (3)
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra (2)
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: "" (3)
      taints: (4)
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: vsphereprovider.openshift.io/v1beta1
          credentialsSecret:
            name: vsphere-cloud-credentials
          diskGiB: 120
          kind: VSphereMachineProviderSpec
          memoryMiB: 8192
          metadata:
            creationTimestamp: null
          network:
            devices:
            - networkName: "<vm_network_name>" (5)
          numCPUs: 4
          numCoresPerSocket: 1
          snapshot: ""
          template: <vm_template_name> (6)
          userDataSecret:
            name: worker-user-data
          workspace:
            datacenter: <vcenter_data_center_name> (7)
            datastore: <vcenter_datastore_name> (8)
            folder: <vcenter_vm_folder_path> (9)
            resourcepool: <vsphere_resource_pool> (10)
            server: <vcenter_server_ip> (11)

指定基于集群配置时设置的集群 ID 的基础设施 ID。如果您已安装 OpenShift CLI（oc），则可以通过运行以下命令获取基础设施 ID

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

2 指定基础架构 ID 和 <infra> 节点标签。

3 指定<infra>节点标签。

指定污点以防止在 infra 节点上调度用户工作负载。

在基础设施节点上添加NoSchedule污点后，在该节点上运行的现有 DNS Pod 将被标记为misscheduled。您必须删除或在misscheduled DNS Pod 上添加容忍度。

5 指定要部署计算机器集的 vSphere 虚拟机网络。此虚拟机网络必须是集群中其他计算机器所在的网络。

6 指定要使用的 vSphere 虚拟机模板，例如 user-5ddjd-rhcos。

7 指定要部署计算机器集的 vCenter 数据中心。

8 指定要部署计算机器集的 vCenter 数据存储。

9 指定 vCenter 中 vSphere 虚拟机文件夹的路径，例如 /dc1/vm/user-inst-5ddjd。

10 指定虚拟机的 vSphere 资源池。

11 指定 vCenter 服务器 IP 或完全限定域名。

创建计算机器集

除了安装程序创建的计算机器集外，您还可以创建自己的计算机器集，以动态管理您选择的特定工作负载的机器计算资源。

先决条件

部署 OpenShift Container Platform 集群。
安装 OpenShift CLI（oc）。
以具有 cluster-admin 权限的用户身份登录 oc。

步骤

创建一个新的 YAML 文件，其中包含计算机器集自定义资源 (CR) 示例，并命名为 <file_name>.yaml。

确保您已设置 <clusterID> 和 <role> 参数值。

可选：如果您不确定为特定字段设置哪个值，可以检查集群中现有的计算机器集。

要列出集群中的计算机器集，请运行以下命令

$ oc get machinesets -n openshift-machine-api

示例输出

NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

要查看特定计算机器集自定义资源 (CR) 的值，请运行以下命令

$ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

示例输出

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
  name: <infrastructure_id>-<role> (2)
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec: (3)
        ...

1 集群基础设施 ID。

默认节点标签。

对于具有用户配置的基础设施的集群，计算机器集只能创建 worker 和 infra 类型机器。

3 计算机器集 CR 的 <providerSpec> 部分中的值是特定于平台的。有关 CR 中 <providerSpec> 参数的更多信息，请参阅您的提供程序的示例计算机器集 CR 配置。

通过运行以下命令创建 MachineSet CR
```
$ oc create -f <file_name>.yaml
```

验证

通过运行以下命令查看计算机器集列表

$ oc get machineset -n openshift-machine-api

示例输出

NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

当新的计算机器集可用时，DESIRED 和 CURRENT 值匹配。如果计算机器集不可用，请等待几分钟，然后再次运行该命令。

创建基础设施节点

请参阅针对安装程序配置的基础设施环境或控制平面节点由机器 API 管理的任何集群的创建基础设施机器集。

集群的要求规定必须配置基础设施（也称为 infra 节点）。安装程序仅提供控制平面和工作节点的配置。工作节点可以通过标签指定为基础设施节点或应用程序（也称为 app）节点。

步骤

为要充当应用程序节点的工作节点添加标签

$ oc label node <node-name> node-role.kubernetes.io/app=""

为要充当基础设施节点的工作节点添加标签

$ oc label node <node-name> node-role.kubernetes.io/infra=""

检查适用的节点现在是否具有 infra 角色和 app 角色
```
$ oc get nodes
```

创建一个默认的集群范围节点选择器。默认节点选择器应用于在所有命名空间中创建的 Pod。这将与 Pod 上任何现有的节点选择器相交，这会进一步约束 Pod 的选择器。

如果默认节点选择器键与 Pod 标签的键冲突，则不会应用默认节点选择器。

但是，请勿设置可能导致 Pod 无法调度的默认节点选择器。例如，当 Pod 的标签设置为不同的节点角色（例如 node-role.kubernetes.io/master=""）时，将默认节点选择器设置为特定节点角色（例如 node-role.kubernetes.io/infra=""）可能会导致 Pod 无法调度。因此，在将默认节点选择器设置为特定节点角色时，请谨慎操作。

您可以选择使用项目节点选择器来避免集群范围节点选择器键冲突。

编辑 Scheduler 对象
```
$ oc edit scheduler cluster
```

添加具有适当节点选择器的 defaultNodeSelector 字段

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
spec:
  defaultNodeSelector: node-role.kubernetes.io/infra="" (1)
# ...

1	此示例节点选择器默认情况下在基础设施节点上部署 Pod。

保存文件以应用更改。

您现在可以将基础设施资源移动到新标记的 infra 节点。

其他资源

将资源移动到基础设施机器集

为基础设施机器创建机器配置池

如果您需要基础设施机器具有专用配置，则必须创建 infra 池。

如果自定义机器配置池引用相同的文件或单元，则会覆盖默认的工作程序池配置。

步骤

为要使用特定标签分配为 infra 节点的节点添加标签

$ oc label node <node_name> <label>

$ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=

创建一个机器配置池，其中包含工作程序角色和自定义角色作为机器配置选择器

$ cat infra.mcp.yaml

示例输出

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]} (1)
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/infra: "" (2)

1	添加工作程序角色和您的自定义角色。
2	将您添加到节点的标签添加为 `nodeSelector`。

自定义机器配置池继承自工作程序池的机器配置。自定义池使用针对工作程序池的目标任何机器配置，但还增加了部署仅针对自定义池的更改的能力。因为自定义池继承自工作程序池的资源，所以对工作程序池的任何更改也会影响自定义池。

拥有 YAML 文件后，您可以创建机器配置池
```
$ oc create -f infra.mcp.yaml
```

检查机器配置以确保基础设施配置已成功呈现

$ oc get machineconfig

示例输出

NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
00-master                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
99-master-ssh                                                                                          3.2.0             31d
99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
99-worker-ssh                                                                                          3.2.0             31d
rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             23m
rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d
rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d

您应该看到一个新的机器配置，前缀为 rendered-infra-*。

可选：要将更改部署到自定义池，请创建一个使用自定义池名称作为标签的机器配置，例如 infra。请注意，这不是必需的，仅出于教学目的而显示。通过这种方式，您可以应用仅特定于您的 infra 节点的任何自定义配置。

创建新的机器配置池后，MCO 会为此池生成一个新的渲染配置，并且该池的相关节点将重新启动以应用新配置。
1. 创建机器配置
  $ cat infra.mc.yaml
  示例输出
  apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 51-infra labels: machineconfiguration.openshift.io/role: infra (1) spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/infratest mode: 0644 contents: source: data:,infra
  1 将您添加到节点的标签添加为 nodeSelector。
2. 将机器配置应用于 infra 标记的节点
  $ oc create -f infra.mc.yaml

确认您的新机器配置池可用

$ oc get mcp

示例输出

NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-60e35c2e99f42d976e084fa94da4d0fc    True      False      False      1              1                   1                     0                      4m20s
master   rendered-master-9360fdb895d4c131c7c4bebbae099c90   True      False      False      3              3                   3                     0                      91m
worker   rendered-worker-60e35c2e99f42d976e084fa94da4d0fc   True      False      False      2              2                   2                     0                      91m

在此示例中，工作节点已更改为 infra 节点。

其他资源

有关在自定义池中分组 infra 机器的信息，请参阅使用机器配置池进行节点配置管理。

将机器集资源分配给基础设施节点

创建基础设施机器集后，worker 和 infra 角色将应用于新的 infra 节点。即使也应用了 worker 角色，应用了 infra 角色的节点也不会计入运行环境所需的订阅总数。

但是，如果 infra 节点被分配为工作节点，则用户工作负载可能会意外地分配给 infra 节点。为了避免这种情况，您可以对 infra 节点应用污点，并对要控制的 Pod 应用容忍度。

使用污点和容忍度绑定基础设施节点工作负载

如果您有一个已分配 infra 和 worker 角色的 infra 节点，则必须配置该节点，以使其不分配用户工作负载。

建议保留为基础设施节点创建的双标签infra,worker，并使用污点和容忍度来管理用户工作负载计划所在的节点。如果从节点中删除worker标签，则必须创建自定义池来管理它。如果没有自定义池，则 MCO 无法识别标签不是master或worker的节点。如果不存在选择自定义标签的自定义池，则保留worker标签允许节点由默认的工作节点机器配置池管理。infra标签向集群传达它不计入订阅总数的信息。

先决条件

在 OpenShift Container Platform 集群中配置其他MachineSet对象。

步骤

向基础设施节点添加污点以阻止在其上调度用户工作负载。

确定节点是否具有污点。

$ oc describe nodes <node_name>

示例输出

oc describe node ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
Name:               ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
Roles:              worker
 ...
Taints:             node-role.kubernetes.io/infra:NoSchedule
 ...

此示例显示该节点具有污点。您可以继续在下一步中向您的 Pod 添加容忍度。

如果您尚未配置污点来阻止在其上调度用户工作负载

$ oc adm taint nodes <node_name> <key>=<value>:<effect>

例如

$ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoSchedule

您可以选择应用以下 YAML 来添加污点：

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    ...
spec:
  taints:
    - key: node-role.kubernetes.io/infra
      effect: NoSchedule
      value: reserved
  ...

此示例在node1上放置一个污点，该污点具有键node-role.kubernetes.io/infra和污点效果NoSchedule。具有NoSchedule效果的节点仅调度容忍该污点的 Pod，但允许现有 Pod 保留在节点上调度。

如果使用调度程序，则违反节点污点的 Pod 可能会被从集群中驱逐。

除了上述具有 NoSchedule 效果的污点之外，还添加具有 NoExecute 效果的污点。

$ oc adm taint nodes <node_name> <key>=<value>:<effect>

例如

$ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoExecute

您可以选择应用以下 YAML 来添加污点：

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    ...
spec:
  taints:
    - key: node-role.kubernetes.io/infra
      effect: NoExecute
      value: reserved
  ...

此示例在node1上放置一个污点，该污点具有键node-role.kubernetes.io/infra和污点效果NoExecute。具有NoExecute效果的节点仅调度容忍该污点的 Pod。此效果将删除节点上任何没有匹配容忍度的现有 Pod。

为要在基础设施节点上调度的 Pod 配置添加容忍度，例如路由器、注册表和监控工作负载。将以下代码添加到Pod对象规范中：

tolerations:
  - effect: NoSchedule (1)
    key: node-role.kubernetes.io/infra (2)
    value: reserved (3)
  - effect: NoExecute (4)
    key: node-role.kubernetes.io/infra (5)
    operator: Exists (6)
    value: reserved (7)

1	指定您添加到节点的效果。
2	指定您添加到节点的键。
3	指定您添加到节点的键值对污点的值。
4	指定您添加到节点的效果。
5	指定您添加到节点的键。
6	指定`Exists`运算符以要求节点上存在具有键`node-role.kubernetes.io/infra`的污点。
7	指定您添加到节点的键值对污点的值。

此容忍度与oc adm taint命令创建的污点匹配。具有此容忍度的 Pod 可以调度到基础设施节点上。

将通过 OLM 安装的 Operator 的 Pod 移动到基础设施节点并非总是可行的。移动 Operator Pod 的能力取决于每个 Operator 的配置。

使用调度程序将 Pod 调度到基础设施节点。有关详细信息，请参阅关于*控制 Pod 部署到节点*的文档。

其他资源

有关将 Pod 调度到节点的一般信息，请参阅使用调度程序控制 Pod 部署。
有关将 Pod 调度到基础设施节点的说明，请参阅将资源移动到基础设施机器集。
有关污点不同效果的更多详细信息，请参阅了解污点和容忍度。

将资源移动到基础设施机器集

默认情况下，一些基础设施资源已部署在您的集群中。您可以通过添加基础设施节点选择器来将它们移动到您创建的基础设施机器集，如下所示：

spec:
  nodePlacement: (1)
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/infra: ""
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/infra
      value: reserved
    - effect: NoExecute
      key: node-role.kubernetes.io/infra
      value: reserved

1	向要移动的组件添加具有适当值的`nodeSelector`参数。您可以使用显示的格式使用`nodeSelector`，也可以使用`<key>: <value>`对，具体取决于为节点指定的值。如果您向基础设施节点添加了污点，请也添加匹配的容忍度。

将特定的节点选择器应用于所有基础设施组件会导致 OpenShift Container Platform 将这些工作负载调度到具有该标签的节点上。

移动路由器

您可以将路由器 Pod 部署到不同的计算机器集。默认情况下，Pod 部署到工作节点。

先决条件

在 OpenShift Container Platform 集群中配置其他计算机器集。

步骤

查看路由器 Operator 的IngressController自定义资源。

$ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

命令输出类似于以下文本：

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: 2019-04-18T12:35:39Z
  finalizers:
  - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
  generation: 1
  name: default
  namespace: openshift-ingress-operator
  resourceVersion: "11341"
  selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
  uid: 79509e05-61d6-11e9-bc55-02ce4781844a
spec: {}
status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2019-04-18T12:36:15Z
    status: "True"
    type: Available
  domain: apps.<cluster>.example.com
  endpointPublishingStrategy:
    type: LoadBalancerService
  selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default

编辑ingresscontroller资源并将nodeSelector更改为使用infra标签。

$ oc edit ingresscontroller default -n openshift-ingress-operator

  spec:
    nodePlacement:
      nodeSelector: (1)
        matchLabels:
          node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved

1	向要移动的组件添加具有适当值的`nodeSelector`参数。您可以使用显示的格式使用`nodeSelector`，也可以使用`<key>: <value>`对，具体取决于为节点指定的值。如果您向基础设施节点添加了污点，请也添加匹配的容忍度。

确认路由器 Pod 正在infra节点上运行。

查看路由器 Pod 列表并记下正在运行的 Pod 的节点名称。

$ oc get pod -n openshift-ingress -o wide

示例输出

NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

在此示例中，正在运行的 Pod 位于ip-10-0-217-226.ec2.internal节点上。

查看正在运行的 Pod 的节点状态。
```
$ oc get node <node_name> (1)
```
1 指定从 Pod 列表中获得的<node_name>。
示例输出
```
NAME                          STATUS  ROLES         AGE   VERSION
ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.30.3
```
因为角色列表包括infra，所以 Pod 正在正确的节点上运行。

移动默认注册表

您可以配置注册表 Operator 以将其 Pod 部署到不同的节点。

先决条件

在 OpenShift Container Platform 集群中配置其他计算机器集。

步骤

查看config/instance对象。

$ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

示例输出

apiVersion: imageregistry.operator.openshift.io/v1
kind: Config
metadata:
  creationTimestamp: 2019-02-05T13:52:05Z
  finalizers:
  - imageregistry.operator.openshift.io/finalizer
  generation: 1
  name: cluster
  resourceVersion: "56174"
  selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
  uid: 36fd3724-294d-11e9-a524-12ffeee2931b
spec:
  httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
  logging: 2
  managementState: Managed
  proxy: {}
  replicas: 1
  requests:
    read: {}
    write: {}
  storage:
    s3:
      bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
      region: us-east-1
status:
...

编辑config/instance对象。

$ oc edit configs.imageregistry.operator.openshift.io/cluster

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          namespaces:
          - openshift-image-registry
          topologyKey: kubernetes.io/hostname
        weight: 100
  logLevel: Normal
  managementState: Managed
  nodeSelector: (1)
    node-role.kubernetes.io/infra: ""
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
    value: reserved
  - effect: NoExecute
    key: node-role.kubernetes.io/infra
    value: reserved

1	向要移动的组件添加具有适当值的`nodeSelector`参数。您可以使用显示的格式使用`nodeSelector`，也可以使用`<key>: <value>`对，具体取决于为节点指定的值。如果您向基础设施节点添加了污点，请也添加匹配的容忍度。

验证注册表 Pod 是否已移动到基础设施节点。
1. 运行以下命令以确定注册表 Pod 所在的节点：
  $ oc get pods -o wide -n openshift-image-registry
2. 确认节点具有您指定的标签。
  $ oc describe node <node_name>
  查看命令输出并确认node-role.kubernetes.io/infra位于LABELS列表中。

移动监控解决方案

监控堆栈包括多个组件，包括 Prometheus、Thanos Querier 和 Alertmanager。集群监控 Operator 管理此堆栈。要将监控堆栈重新部署到基础设施节点，您可以创建和应用自定义 ConfigMap。

步骤

编辑cluster-monitoring-config ConfigMap 并将nodeSelector更改为使用infra标签。

$ oc edit configmap cluster-monitoring-config -n openshift-monitoring

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |+
    alertmanagerMain:
      nodeSelector: (1)
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    prometheusK8s:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    prometheusOperator:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    metricsServer:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    kubeStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    telemeterClient:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    openshiftStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    thanosQuerier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    monitoringPlugin:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute

1	向要移动的组件添加具有适当值的`nodeSelector`参数。您可以使用显示的格式使用`nodeSelector`，也可以使用`<key>: <value>`对，具体取决于为节点指定的值。如果您向基础设施节点添加了污点，请也添加匹配的容忍度。

观察监控 Pod 移动到新机器。

$ watch 'oc get pod -n openshift-monitoring -o wide'

如果某个组件尚未移动到infra节点，请删除具有此组件的 Pod。
```
$ oc delete pod -n openshift-monitoring <pod>
```
来自已删除 Pod 的组件将在infra节点上重新创建。

移动垂直 Pod 自动缩放器 Operator 组件

垂直 Pod 自动缩放器 Operator (VPA) 包括三个组件：推荐器、更新器和准入控制器。Operator 和每个组件在控制平面节点上的 VPA 命名空间中都有自己的 Pod。您可以通过向 VPA 订阅和VerticalPodAutoscalerController CR 添加节点选择器来将 VPA Operator 和组件 Pod 移动到基础设施节点。

以下示例显示将 VPA Pod 默认部署到控制平面节点。

示例输出

NAME                                                READY   STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z   1/1     Running   0          7m59s   10.128.2.24   c416-tfsbj-master-1   <none>           <none>
vpa-admission-plugin-default-6cb78d6f8b-rpcrj       1/1     Running   0          5m37s   10.129.2.22   c416-tfsbj-master-1   <none>           <none>
vpa-recommender-default-66846bd94c-dsmpp            1/1     Running   0          5m37s   10.129.2.20   c416-tfsbj-master-0   <none>           <none>
vpa-updater-default-db8b58df-2nkvf                  1/1     Running   0          5m37s   10.129.2.21   c416-tfsbj-master-1   <none>           <none>

步骤

通过向 VPA Operator 的Subscription 自定义资源 (CR) 添加节点选择器来移动 VPA Operator Pod。

编辑 CR。

$ oc edit Subscription vertical-pod-autoscaler -n openshift-vertical-pod-autoscaler

添加节点选择器以匹配基础设施节点上的节点角色标签。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  labels:
    operators.coreos.com/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler: ""
  name: vertical-pod-autoscaler
# ...
spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: "" (1)

1	指定基础设施节点的节点角色。

如果基础设施节点使用了污点 (taint)，则需要向Subscription CR 添加容忍 (toleration)。

例如

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  labels:
    operators.coreos.com/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler: ""
  name: vertical-pod-autoscaler
# ...
spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations: (1)
    - key: "node-role.kubernetes.io/infra"
      operator: "Exists"
      effect: "NoSchedule"

1	指定基础设施节点污点的容忍。

通过向VerticalPodAutoscaler 自定义资源 (CR) 添加节点选择器来移动每个 VPA 组件。

编辑 CR。

$ oc edit VerticalPodAutoscalerController default -n openshift-vertical-pod-autoscaler

添加节点选择器以匹配基础设施节点上的节点角色标签。

apiVersion: autoscaling.openshift.io/v1
kind: VerticalPodAutoscalerController
metadata:
 name: default
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
  deploymentOverrides:
    admission:
      container:
        resources: {}
      nodeSelector:
        node-role.kubernetes.io/infra: "" (1)
    recommender:
      container:
        resources: {}
      nodeSelector:
        node-role.kubernetes.io/infra: "" (2)
    updater:
      container:
        resources: {}
      nodeSelector:
        node-role.kubernetes.io/infra: "" (3)

1	可选：指定 VPA 准入 Pod 的节点角色。
2	可选：指定 VPA 推荐器 Pod 的节点角色。
3	可选：指定 VPA 更新器 Pod 的节点角色。

如果目标节点使用了污点，则需要向VerticalPodAutoscalerController CR 添加容忍。

例如

apiVersion: autoscaling.openshift.io/v1
kind: VerticalPodAutoscalerController
metadata:
 name: default
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
  deploymentOverrides:
    admission:
      container:
        resources: {}
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations: (1)
      - key: "my-example-node-taint-key"
        operator: "Exists"
        effect: "NoSchedule"
    recommender:
      container:
        resources: {}
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations: (2)
      - key: "my-example-node-taint-key"
        operator: "Exists"
        effect: "NoSchedule"
    updater:
      container:
        resources: {}
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations: (3)
      - key: "my-example-node-taint-key"
        operator: "Exists"
        effect: "NoSchedule"

1	指定准入控制器 Pod 对基础设施节点污点的容忍。
2	指定推荐器 Pod 对基础设施节点污点的容忍。
3	指定更新器 Pod 对基础设施节点污点的容忍。

验证

您可以使用以下命令验证 Pod 是否已移动

$ oc get pods -n openshift-vertical-pod-autoscaler -o wide

Pod 将不再部署到控制平面节点。

示例输出

NAME                                                READY   STATUS    RESTARTS   AGE     IP            NODE                              NOMINATED NODE   READINESS GATES
vertical-pod-autoscaler-operator-6c75fcc9cd-5pb6z   1/1     Running   0          7m59s   10.128.2.24   c416-tfsbj-infra-eastus3-2bndt   <none>           <none>
vpa-admission-plugin-default-6cb78d6f8b-rpcrj       1/1     Running   0          5m37s   10.129.2.22   c416-tfsbj-infra-eastus1-lrgj8   <none>           <none>
vpa-recommender-default-66846bd94c-dsmpp            1/1     Running   0          5m37s   10.129.2.20   c416-tfsbj-infra-eastus1-lrgj8   <none>           <none>
vpa-updater-default-db8b58df-2nkvf                  1/1     Running   0          5m37s   10.129.2.21   c416-tfsbj-infra-eastus1-lrgj8   <none>           <none>

移动集群资源覆盖操作符 Pod

默认情况下，集群资源覆盖操作符安装过程会在clusterresourceoverride-operator命名空间中的节点上创建一个操作符 Pod 和两个集群资源覆盖 Pod。您可以根据需要将这些 Pod 移动到其他节点，例如基础设施节点。

以下示例显示集群资源覆盖 Pod 部署到控制平面节点，而集群资源覆盖操作符 Pod 部署到工作节点。

集群资源覆盖 Pod 示例

NAME                                                READY   STATUS    RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
clusterresourceoverride-786b8c898c-9wrdq            1/1     Running   0          23s   10.128.2.32   ip-10-0-14-183.us-west-2.compute.internal   <none>           <none>
clusterresourceoverride-786b8c898c-vn2lf            1/1     Running   0          26s   10.130.2.10   ip-10-0-20-140.us-west-2.compute.internal   <none>           <none>
clusterresourceoverride-operator-6b8b8b656b-lvr62   1/1     Running   0          56m   10.131.0.33   ip-10-0-2-39.us-west-2.compute.internal     <none>           <none>

节点列表示例

NAME                                        STATUS   ROLES                  AGE   VERSION
ip-10-0-14-183.us-west-2.compute.internal   Ready    control-plane,master   65m   v1.30.4
ip-10-0-2-39.us-west-2.compute.internal     Ready    worker                 58m   v1.30.4
ip-10-0-20-140.us-west-2.compute.internal   Ready    control-plane,master   65m   v1.30.4
ip-10-0-23-244.us-west-2.compute.internal   Ready    infra                  55m   v1.30.4
ip-10-0-77-153.us-west-2.compute.internal   Ready    control-plane,master   65m   v1.30.4
ip-10-0-99-108.us-west-2.compute.internal   Ready    worker                 24m   v1.30.4
ip-10-0-24-233.us-west-2.compute.internal   Ready    infra                  55m   v1.30.4
ip-10-0-88-109.us-west-2.compute.internal   Ready    worker                 24m   v1.30.4
ip-10-0-67-453.us-west-2.compute.internal   Ready    infra                  55m   v1.30.4

步骤

通过向集群资源覆盖操作符的Subscription 自定义资源 (CR) 添加节点选择器来移动集群资源覆盖操作符 Pod。

编辑 CR。

$ oc edit -n clusterresourceoverride-operator subscriptions.operators.coreos.com clusterresourceoverride

添加节点选择器以匹配您想要安装集群资源覆盖操作符 Pod 的节点上的节点角色标签。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: clusterresourceoverride
  namespace: clusterresourceoverride-operator
# ...
spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: "" (1)
# ...

1	指定您想要部署集群资源覆盖操作符 Pod 的节点的角色。

如果基础设施节点使用了污点 (taint)，则需要向Subscription CR 添加容忍 (toleration)。

例如

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: clusterresourceoverride
  namespace: clusterresourceoverride-operator
# ...
spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations: (1)
    - key: "node-role.kubernetes.io/infra"
      operator: "Exists"
      effect: "NoSchedule"

1	指定基础设施节点污点的容忍。

通过向ClusterResourceOverride 自定义资源 (CR) 添加节点选择器来移动集群资源覆盖 Pod。

编辑 CR。

$ oc edit ClusterResourceOverride cluster -n clusterresourceoverride-operator

添加节点选择器以匹配基础设施节点上的节点角色标签。

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
  name: cluster
  resourceVersion: "37952"
spec:
  podResourceOverride:
    spec:
      cpuRequestToLimitPercent: 25
      limitCPUToMemoryPercent: 200
      memoryRequestToLimitPercent: 50
  deploymentOverrides:
    replicas: 1 (1)
    nodeSelector:
      node-role.kubernetes.io/infra: "" (2)
# ...

1	可选：指定要部署的集群资源覆盖 Pod 的数量。默认值为`2`。每个节点只允许一个 Pod。
2	可选：指定您想要部署集群资源覆盖 Pod 的节点的角色。

如果基础设施节点使用了污点，则需要向ClusterResourceOverride CR 添加容忍。

例如

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
  name: cluster
# ...
spec:
  podResourceOverride:
    spec:
      memoryRequestToLimitPercent: 50
      cpuRequestToLimitPercent: 25
      limitCPUToMemoryPercent: 200
  deploymentOverrides:
    replicas: 3
    nodeSelector:
      node-role.kubernetes.io/worker: ""
    tolerations: (1)
    - key: "key"
      operator: "Equal"
      value: "value"
      effect: "NoSchedule"

1	指定基础设施节点污点的容忍。

验证

您可以使用以下命令验证 Pod 是否已移动

$ oc get pods -n clusterresourceoverride-operator -o wide

集群资源覆盖 Pod 现在已部署到基础设施节点。

示例输出

NAME                                                READY   STATUS    RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
clusterresourceoverride-786b8c898c-9wrdq            1/1     Running   0          23s   10.127.2.25   ip-10-0-23-244.us-west-2.compute.internal   <none>           <none>
clusterresourceoverride-786b8c898c-vn2lf            1/1     Running   0          26s   10.128.0.80   ip-10-0-24-233.us-west-2.compute.internal   <none>           <none>
clusterresourceoverride-operator-6b8b8b656b-lvr62   1/1     Running   0          56m   10.129.0.71   ip-10-0-67-453.us-west-2.compute.internal   <none>           <none>

其他资源

将监控组件移动到不同的节点