安装后配置

流程

1. 编辑 Image Registry Operator config 对象，并将 networkAccess.type 设置为 Internal ：

   $ oc edit configs.imageregistry/cluster

   # ...
   spec:
     # ...
      storage:
         azure:
           # ...
           networkAccess:
             type: Internal
   # ...

2. 可选：输入以下命令确认 Operator 已完成置备。这可能需要几分钟时间。

   $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w

3. 可选：如果 registry 由路由公开，并且要将存储帐户配置为私有，则必须禁用重定向（如果集群外部拉取到集群），则必须禁用重定向才能继续工作。输入以下命令禁用 Image Operator 配置中的重定向：

   $ oc patch configs.imageregistry cluster --type=merge -p '{"spec":{"disableRedirect": true}}'

   注意

   启用重定向后，从集群外部拉取镜像将无法正常工作。

验证

1. 运行以下命令来获取 registry 服务名称：

   $ oc registry info --internal=true

   输出示例

   image-registry.openshift-image-registry.svc:5000

2. 运行以下命令来进入 debug 模式：

   $ oc debug node/<node_name>

3. 运行推荐的 chroot 命令。例如：

   $ chroot /host

4. 输入以下命令登录到容器 registry：

   $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

   输出示例

   Login Succeeded!

5. 输入以下命令验证您可以从 registry 中拉取镜像：

   $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools

   输出示例

   Trying to pull image-registry.openshift-image-registry.svc:5000/openshift/tools/openshift/tools...
   Getting image source signatures
   Copying blob 6b245f040973 done
   Copying config 22667f5368 done
   Writing manifest to image destination
   Storing signatures
   22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

流程

1. 编辑 Image Registry Operator config 对象并使用 VNet 和子网名称配置私有端点：

   $ oc edit configs.imageregistry/cluster

   # ...
   spec:
     # ...
      storage:
         azure:
           # ...
           networkAccess:
             type: Internal
             internal:
               subnetName: <subnet_name>
               vnetName: <vnet_name>
               networkResourceGroupName: <network_resource_group_name>
   # ...

2. 可选：输入以下命令确认 Operator 已完成置备。这可能需要几分钟时间。

   $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w

   注意

   启用重定向后，从集群外部拉取镜像将无法正常工作。

验证

1. 运行以下命令来获取 registry 服务名称：

   $ oc registry info --internal=true

   输出示例

   image-registry.openshift-image-registry.svc:5000

2. 运行以下命令来进入 debug 模式：

   $ oc debug node/<node_name>

3. 运行推荐的 chroot 命令。例如：

   $ chroot /host

4. 输入以下命令登录到容器 registry：

   $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

   输出示例

   Login Succeeded!

5. 输入以下命令验证您可以从 registry 中拉取镜像：

   $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools

   输出示例

   Trying to pull image-registry.openshift-image-registry.svc:5000/openshift/tools/openshift/tools...
   Getting image source signatures
   Copying blob 6b245f040973 done
   Copying config 22667f5368 done
   Writing manifest to image destination
   Storing signatures
   22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

验证

1. 运行以下命令来获取 registry 服务名称：

   $ oc registry info

   输出示例

   default-route-openshift-image-registry.<cluster_dns>

2. 输入以下命令登录到容器 registry：

   $ podman login --tls-verify=false -u unused -p $(oc whoami -t) default-route-openshift-image-registry.<cluster_dns>

   输出示例

   Login Succeeded!

3. 输入以下命令验证您可以从 registry 中拉取镜像：

   $ podman pull --tls-verify=false default-route-openshift-image-registry.<cluster_dns>
   /openshift/tools

   输出示例

   Trying to pull default-route-openshift-image-registry.<cluster_dns>/openshift/tools...
   Getting image source signatures
   Copying blob 6b245f040973 done
   Copying config 22667f5368 done
   Writing manifest to image destination
   Storing signatures
   22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9

流程

1. 配置 HAProxy Ingress Controller，以便您可以在端口 6443、22623、443 和 80 上从负载均衡器访问集群。根据您的需要，您可以在 HAProxy 配置中指定来自多个子网的单个子网或 IP 地址的 IP 地址。

   带有列出子网的 HAProxy 配置示例

   # ...
   listen my-cluster-api-6443
       bind 192.168.1.100:6443
       mode tcp
       balance roundrobin
     option httpchk
     http-check connect
     http-check send meth GET uri /readyz
     http-check expect status 200
       server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
       server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
       server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
   
   listen my-cluster-machine-config-api-22623
       bind 192.168.1.100:22623
       mode tcp
       balance roundrobin
     option httpchk
     http-check connect
     http-check send meth GET uri /healthz
     http-check expect status 200
       server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
       server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
       server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
   
   listen my-cluster-apps-443
       bind 192.168.1.100:443
       mode tcp
       balance roundrobin
     option httpchk
     http-check connect
     http-check send meth GET uri /healthz/ready
     http-check expect status 200
       server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
       server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
       server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
   
   listen my-cluster-apps-80
      bind 192.168.1.100:80
      mode tcp
      balance roundrobin
     option httpchk
     http-check connect
     http-check send meth GET uri /healthz/ready
     http-check expect status 200
       server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
       server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
       server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
   # ...

   带有多个列出子网的 HAProxy 配置示例

   # ...
   listen api-server-6443
       bind *:6443
       mode tcp
         server master-00 192.168.83.89:6443 check inter 1s
         server master-01 192.168.84.90:6443 check inter 1s
         server master-02 192.168.85.99:6443 check inter 1s
         server bootstrap 192.168.80.89:6443 check inter 1s
   
   listen machine-config-server-22623
       bind *:22623
       mode tcp
         server master-00 192.168.83.89:22623 check inter 1s
         server master-01 192.168.84.90:22623 check inter 1s
         server master-02 192.168.85.99:22623 check inter 1s
         server bootstrap 192.168.80.89:22623 check inter 1s
   
   listen ingress-router-80
       bind *:80
       mode tcp
       balance source
         server worker-00 192.168.83.100:80 check inter 1s
         server worker-01 192.168.83.101:80 check inter 1s
   
   listen ingress-router-443
       bind *:443
       mode tcp
       balance source
         server worker-00 192.168.83.100:443 check inter 1s
         server worker-01 192.168.83.101:443 check inter 1s
   
   listen ironic-api-6385
       bind *:6385
       mode tcp
       balance source
         server master-00 192.168.83.89:6385 check inter 1s
         server master-01 192.168.84.90:6385 check inter 1s
         server master-02 192.168.85.99:6385 check inter 1s
         server bootstrap 192.168.80.89:6385 check inter 1s
   
   listen inspector-api-5050
       bind *:5050
       mode tcp
       balance source
         server master-00 192.168.83.89:5050 check inter 1s
         server master-01 192.168.84.90:5050 check inter 1s
         server master-02 192.168.85.99:5050 check inter 1s
         server bootstrap 192.168.80.89:5050 check inter 1s
   # ...

2. 使用 curl CLI 命令验证用户管理的负载均衡器及其资源是否正常运行：

   1. 运行以下命令并查看响应，验证集群机器配置 API 是否可以被 Kubernetes API 服务器资源访问：

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure

      如果配置正确，您会收到 JSON 对象的响应：

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }

   2. 运行以下命令并观察输出，验证集群机器配置 API 是否可以被 Machine 配置服务器资源访问：

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure

      如果配置正确，命令的输出会显示以下响应：

      HTTP/1.1 200 OK
      Content-Length: 0

   3. 运行以下命令并观察输出，验证控制器是否可以被端口 80 上的 Ingress Controller 资源访问：

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

      如果配置正确，命令的输出会显示以下响应：

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache

   4. 运行以下命令并观察输出，验证控制器是否可以被端口 443 上的 Ingress Controller 资源访问：

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>

      如果配置正确，命令的输出会显示以下响应：

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

3. 配置集群的 DNS 记录，使其以用户管理的负载均衡器的前端 IP 地址为目标。您必须在负载均衡器上将记录更新为集群 API 和应用程序的 DNS 服务器。

   修改 DNS 记录示例

   <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
   A record pointing to Load Balancer Front End

   <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
   A record pointing to Load Balancer Front End

   重要

   DNS 传播可能需要一些时间才能获得每个 DNS 记录。在验证每个记录前，请确保每个 DNS 记录传播。

4. 要使 OpenShift Container Platform 集群使用用户管理的负载均衡器，您必须在集群的 install-config.yaml 文件中指定以下配置：

   # ...
   platform:
       loadBalancer:
         type: UserManaged 1
       apiVIPs:
       - <api_ip> 2
       ingressVIPs:
       - <ingress_ip> 3
   # ...

   1

   为 type 参数设置 UserManaged，为集群指定用户管理的负载均衡器。参数默认为 OpenShiftManagedDefault，它表示默认的内部负载均衡器。对于 openshift-kni-infra 命名空间中定义的服务，用户管理的负载均衡器可将 coredns 服务部署到集群中的 pod，但忽略 keepalived 和 haproxy 服务。

   2

   指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共 IP 地址，以便 Kubernetes API 可以与用户管理的负载均衡器通信。

   3

   指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共 IP 地址，以便用户管理的负载均衡器可以管理集群的入口流量。

验证

1. 使用 curl CLI 命令验证用户管理的负载均衡器和 DNS 记录配置是否正常工作：

   1. 运行以下命令并查看输出，验证您可以访问集群 API：

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

      如果配置正确，您会收到 JSON 对象的响应：

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }

   2. 运行以下命令并查看输出，验证您可以访问集群机器配置：

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure

      如果配置正确，命令的输出会显示以下响应：

      HTTP/1.1 200 OK
      Content-Length: 0

   3. 运行以下命令并查看输出，验证您可以在端口上访问每个集群应用程序：

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      如果配置正确，命令的输出会显示以下响应：

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

   4. 运行以下命令并查看输出，验证您可以在端口 443 上访问每个集群应用程序：

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      如果配置正确，命令的输出会显示以下响应：

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

流程

1. 登录 OpenShift CLI (oc)。

2. 您可以运行以下命令来检查集群是否使用构架有效负载：

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

流程

1. 登录到您的 Azure 帐户：

   $ az login

2. 创建存储帐户并将 aarch64 虚拟硬盘 (VHD) 上传到您的存储帐户。OpenShift Container Platform 安装程序会创建一个资源组，但引导镜像也可以上传到名为资源组的自定义中：

   $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS 1

   1

   westus 对象是一个示例区域。

3. 使用您生成的存储帐户创建存储容器：

   $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}

4. 您必须使用 OpenShift Container Platform 安装程序 JSON 文件提取 URL 和 aarch64 VHD 名称：

   1. 运行以下命令，提取 URL 字段并将其设置为 RHCOS_VHD_ORIGIN_URL ：

      $ RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.aarch64."rhel-coreos-extensions"."azure-disk".url')

   2. 运行以下命令，提取 aarch64 VHD 名称并将其设置为 BLOB_NAME 作为文件名：

      $ BLOB_NAME=rhcos-$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.aarch64."rhel-coreos-extensions"."azure-disk".release')-azure.aarch64.vhd

5. 生成共享访问令牌 (SAS) 令牌。通过以下命令，使用此令牌将 RHCOS VHD 上传到存储容器：

   $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`

   $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`

6. 将 RHCOS VHD 复制到存储容器中：

   $ az storage blob copy start --account-name ${STORAGE_ACCOUNT_NAME} --sas-token "$sas" \
    --source-uri "${RHCOS_VHD_ORIGIN_URL}" \
    --destination-blob "${BLOB_NAME}" --destination-container ${CONTAINER_NAME}

   您可以使用以下命令检查复制过程的状态：

   $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy

   输出示例

   {
    "completionTime": null,
    "destinationSnapshot": null,
    "id": "1fd97630-03ca-489a-8c4e-cfe839c9627d",
    "incrementalCopy": null,
    "progress": "17179869696/17179869696",
    "source": "https://rhcos.blob.core.windows.net/imagebucket/rhcos-411.86.202207130959-0-azure.aarch64.vhd",
    "status": "success", 1
    "statusDescription": null
   }

   1

   如果 status 参数显示 success 对象，则复制过程已完成。

7. 使用以下命令创建镜像 gallery：

   $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}

   使用镜像 gallery 创建镜像定义。在以下示例中，rhcos-arm64 是镜像定义的名称。

   $ az sig image-definition create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --publisher RedHat --offer arm --sku arm64 --os-type linux --architecture Arm64 --hyper-v-generation V2

8. 要获取 VHD 的 URL，并将其设置为 RHCOS_VHD_URL 作为文件名称，请运行以下命令：

   $ RHCOS_VHD_URL=$(az storage blob url --account-name ${STORAGE_ACCOUNT_NAME} -c ${CONTAINER_NAME} -n "${BLOB_NAME}" -o tsv)

9. 使用 RHCOS_VHD_URL 文件、您的存储帐户、资源组和镜像 gallery 创建镜像版本。在以下示例中，1.0.0 是镜像版本。

   $ az sig image-version create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --gallery-image-version 1.0.0 --os-vhd-storage-account ${STORAGE_ACCOUNT_NAME} --os-vhd-uri ${RHCOS_VHD_URL}

10. 现在生成您的 arm64 引导镜像。您可以使用以下命令访问镜像的 ID：

    $ az sig image-version show -r $GALLERY_NAME -g $RESOURCE_GROUP -i rhcos-arm64 -e 1.0.0

    以下示例镜像 ID 在计算机器设置的 recourseID 参数中使用：

    resourceID 示例

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0

流程

1. 运行以下命令登录到您的 Azure 帐户：

   $ az login

2. 运行以下命令，创建一个存储帐户并将 x86_64 虚拟硬盘 (VHD) 上传到您的存储帐户。OpenShift Container Platform 安装程序会创建一个资源组。但是，引导镜像也可以上传到名为资源组的自定义中：

   $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS 1

   1

   westus 对象是一个示例区域。

3. 运行以下命令，使用您生成的存储帐户创建存储容器：

   $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}

4. 使用 OpenShift Container Platform 安装程序 JSON 文件提取 URL 和 x86_64 VHD 名称：

   1. 运行以下命令，提取 URL 字段并将其设置为 RHCOS_VHD_ORIGIN_URL ：

      $ RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.x86_64."rhel-coreos-extensions"."azure-disk".url')

   2. 运行以下命令，提取 x86_64 VHD 名称并将其设置为 BLOB_NAME 作为文件名：

      $ BLOB_NAME=rhcos-$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.x86_64."rhel-coreos-extensions"."azure-disk".release')-azure.x86_64.vhd

5. 生成共享访问令牌 (SAS) 令牌。运行以下命令，使用此令牌将 RHCOS VHD 上传到存储容器：

   $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`

   $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`

6. 运行以下命令，将 RHCOS VHD 复制到存储容器中：

   $ az storage blob copy start --account-name ${STORAGE_ACCOUNT_NAME} --sas-token "$sas" \
    --source-uri "${RHCOS_VHD_ORIGIN_URL}" \
    --destination-blob "${BLOB_NAME}" --destination-container ${CONTAINER_NAME}

   您可以运行以下命令来检查复制过程的状态：

   $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy

   输出示例

   {
    "completionTime": null,
    "destinationSnapshot": null,
    "id": "1fd97630-03ca-489a-8c4e-cfe839c9627d",
    "incrementalCopy": null,
    "progress": "17179869696/17179869696",
    "source": "https://rhcos.blob.core.windows.net/imagebucket/rhcos-411.86.202207130959-0-azure.aarch64.vhd",
    "status": "success", 1
    "statusDescription": null
   }

   1

   如果 status 参数显示 success 对象，则代表复制过程已完成。

7. 运行以下命令来创建镜像 gallery：

   $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}

8. 运行以下命令，使用镜像 gallery 创建镜像定义：

   $ az sig image-definition create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-x86_64 --publisher RedHat --offer x86_64 --sku x86_64 --os-type linux --architecture x64 --hyper-v-generation V2

   在本例中，rhcos-x86_64 是镜像定义的名称。

9. 要获取 VHD 的 URL，并将其设置为 RHCOS_VHD_URL 作为文件名称，请运行以下命令：

   $ RHCOS_VHD_URL=$(az storage blob url --account-name ${STORAGE_ACCOUNT_NAME} -c ${CONTAINER_NAME} -n "${BLOB_NAME}" -o tsv)

10. 运行以下命令，使用 RHCOS_VHD_URL 文件、存储帐户、资源组和镜像 gallery 创建镜像版本：

    $ az sig image-version create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --gallery-image-version 1.0.0 --os-vhd-storage-account ${STORAGE_ACCOUNT_NAME} --os-vhd-uri ${RHCOS_VHD_URL}

    在本例中，1.0.0 是镜像版本。

11. 可选：运行以下命令来访问生成的 x86_64 引导镜像的 ID：

    $ az sig image-version show -r $GALLERY_NAME -g $RESOURCE_GROUP -i rhcos-x86_64 -e 1.0.0

    以下示例镜像 ID 在计算机器设置的 recourseID 参数中使用：

    resourceID 示例

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-x86_64/versions/1.0.0

流程

1. 登录 OpenShift CLI (oc)。

2. 创建 YAML 文件，并添加配置来创建计算机器集来控制集群中的 64 位 ARM 或 64 位 x86 计算节点。

   Azure 64 位 ARM 或 64 位 x86 计算节点的 MachineSet 对象示例

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     labels:
       machine.openshift.io/cluster-api-cluster: <infrastructure_id>
       machine.openshift.io/cluster-api-machine-role: worker
       machine.openshift.io/cluster-api-machine-type: worker
     name: <infrastructure_id>-machine-set-0
     namespace: openshift-machine-api
   spec:
     replicas: 2
     selector:
       matchLabels:
         machine.openshift.io/cluster-api-cluster: <infrastructure_id>
         machine.openshift.io/cluster-api-machineset: <infrastructure_id>-machine-set-0
     template:
       metadata:
         labels:
           machine.openshift.io/cluster-api-cluster: <infrastructure_id>
           machine.openshift.io/cluster-api-machine-role: worker
           machine.openshift.io/cluster-api-machine-type: worker
           machine.openshift.io/cluster-api-machineset: <infrastructure_id>-machine-set-0
       spec:
         lifecycleHooks: {}
         metadata: {}
         providerSpec:
           value:
             acceleratedNetworking: true
             apiVersion: machine.openshift.io/v1beta1
             credentialsSecret:
               name: azure-cloud-credentials
               namespace: openshift-machine-api
             image:
               offer: ""
               publisher: ""
               resourceID: /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0 1
               sku: ""
               version: ""
             kind: AzureMachineProviderSpec
             location: <region>
             managedIdentity: <infrastructure_id>-identity
             networkResourceGroup: <infrastructure_id>-rg
             osDisk:
               diskSettings: {}
               diskSizeGB: 128
               managedDisk:
                 storageAccountType: Premium_LRS
               osType: Linux
             publicIP: false
             publicLoadBalancer: <infrastructure_id>
             resourceGroup: <infrastructure_id>-rg
             subnet: <infrastructure_id>-worker-subnet
             userDataSecret:
               name: worker-user-data
             vmSize: Standard_D4ps_v5 2
             vnet: <infrastructure_id>-vnet
             zone: "<zone>"

   1

   将 resourceID 参数设置为 arm64 或 amd64 引导镜像。

   2

   将 vmSize 参数设置为安装中使用的实例类型。一些实例类型是 Standard_D4ps_v5 或 D8ps。

3. 运行以下命令来创建计算机器集：

   $ oc create -f <file_name> 1

   1

   将 <file_name> 替换为计算机器设置配置 YAML 文件的名称。例如： arm64-machine-set-0.yaml, 或 amd64-machine-set-0.yaml。

验证

1. 运行以下命令验证新机器是否正在运行：

   $ oc get machineset -n openshift-machine-api

   输出必须包含您创建的机器集。

   输出示例

   NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
   <infrastructure_id>-machine-set-0                   2        2      2          2  10m

2. 您可以运行以下命令来检查节点是否已就绪并可以调度：

   $ oc get nodes

流程

1. 登录 OpenShift CLI (oc)。

2. 您可以运行以下命令来检查集群是否使用构架有效负载：

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

流程

1. 登录 OpenShift CLI (oc)。

2. 创建 YAML 文件，并添加配置来创建计算机器集来控制集群中的 64 位 ARM 或 64 位 x86 计算节点。

   AWS 64 位 ARM 或 x86 计算节点的 MachineSet 对象示例

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     labels:
       machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
     name: <infrastructure_id>-aws-machine-set-0 2
     namespace: openshift-machine-api
   spec:
     replicas: 1
     selector:
       matchLabels:
         machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
         machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 4
     template:
       metadata:
         labels:
           machine.openshift.io/cluster-api-cluster: <infrastructure_id>
           machine.openshift.io/cluster-api-machine-role: <role> 5
           machine.openshift.io/cluster-api-machine-type: <role> 6
           machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 7
       spec:
         metadata:
           labels:
             node-role.kubernetes.io/<role>: ""
         providerSpec:
           value:
             ami:
               id: ami-02a574449d4f4d280 8
             apiVersion: awsproviderconfig.openshift.io/v1beta1
             blockDevices:
               - ebs:
                   iops: 0
                   volumeSize: 120
                   volumeType: gp2
             credentialsSecret:
               name: aws-cloud-credentials
             deviceIndex: 0
             iamInstanceProfile:
               id: <infrastructure_id>-worker-profile 9
             instanceType: m6g.xlarge 10
             kind: AWSMachineProviderConfig
             placement:
               availabilityZone: us-east-1a 11
               region: <region> 12
             securityGroups:
               - filters:
                   - name: tag:Name
                     values:
                       - <infrastructure_id>-node 13
             subnet:
               filters:
                 - name: tag:Name
                   values:
                     - <infrastructure_id>-subnet-private-<zone>
             tags:
               - name: kubernetes.io/cluster/<infrastructure_id> 14
                 value: owned
               - name: <custom_tag_name>
                 value: <custom_tag_value>
             userDataSecret:
               name: worker-user-data

   1 2 3 9 13 14

   指定基于置备集群时所设置的集群 ID 的基础架构 ID。如果已安装 OpenShift CLI（oc）软件包，您可以通过运行以下命令来获取基础架构 ID：

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

   4 7

   指定基础架构 ID、角色节点标签和区域。

   5 6

   指定要添加的角色节点标签。

   8

   为节点指定 AWS 区域的 Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI)。RHCOS AMI 必须与机器架构兼容。

   $ oc get configmap/coreos-bootimages \
   	  -n openshift-machine-config-operator \
   	  -o jsonpath='{.data.stream}' | jq \
   	  -r '.architectures.<arch>.images.aws.regions."<region>".image'

   10

   指定与所选 AMI 的 CPU 架构一致的机器类型。如需更多信息，请参阅"为 AWS 64 位 ARM 测试的实例类型"

   11

   指定区。例如，us-east-1a。确保您选择的区有带有所需架构的机器。

   12

   指定区域。例如，us-east-1。确保您选择的区有带有所需架构的机器。

3. 运行以下命令来创建计算机器集：

   $ oc create -f <file_name> 1

   1

   将 <file_name> 替换为计算机器设置配置 YAML 文件的名称。例如：aws-arm64-machine-set-0.yaml, 或 aws-amd64-machine-set-0.yaml。

验证

1. 运行以下命令，查看计算机器集列表：

   $ oc get machineset -n openshift-machine-api

   输出必须包含您创建的机器集。

   输出示例

   NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
   <infrastructure_id>-aws-machine-set-0                   2        2      2          2  10m

2. 您可以运行以下命令来检查节点是否已就绪并可以调度：

   $ oc get nodes

流程

1. 登录 OpenShift CLI (oc)。

2. 您可以运行以下命令来检查集群是否使用构架有效负载：

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

流程

1. 登录 OpenShift CLI (oc)。

2. 创建 YAML 文件，并添加配置来创建计算机器集来控制集群中的 64 位 ARM 或 64 位 x86 计算节点。

   GCP 64 位 ARM 或 64 位 x86 计算节点的 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: <role> 2
           machine.openshift.io/cluster-api-machine-type: <role>
           machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
       spec:
         metadata:
           labels:
             node-role.kubernetes.io/<role>: ""
         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 5
             metadata:
               creationTimestamp: null
             networkInterfaces:
             - network: <infrastructure_id>-network
               subnetwork: <infrastructure_id>-worker-subnet
             projectID: <project_name> 6
             region: us-central1 7
             serviceAccounts:
             - 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

   1

   指定基于置备集群时所设置的集群 ID 的基础架构 ID。您可以运行以下命令来获取基础架构 ID:

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

   2

   指定要添加的角色节点标签。

   3

   指定当前计算机器集中使用的镜像的路径。您需要到镜像的路径的项目和镜像名称。

   要访问项目和镜像名称，请运行以下命令：

   $ oc get configmap/coreos-bootimages \
     -n openshift-machine-config-operator \
     -o jsonpath='{.data.stream}' | jq \
     -r '.architectures.aarch64.images.gcp'

   输出示例

     "gcp": {
       "release": "415.92.202309142014-0",
       "project": "rhcos-cloud",
       "name": "rhcos-415-92-202309142014-0-gcp-aarch64"
     }

   使用输出中的 project 和 name 参数，在机器集中创建 image 字段的路径。镜像的路径应该采用以下格式：

   $ projects/<project>/global/images/<image_name>

   4

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

   5

   指定与所选操作系统镜像的 CPU 架构一致的机器类型。如需更多信息，请参阅"在 64 位 ARM 基础架构上为 GCP 测试的实例类型"。

   6

   指定用于集群的 GCP 项目的名称。

   7

   指定区域。例如，us-central1。确保您选择的区有带有所需架构的机器。

3. 运行以下命令来创建计算机器集：

   $ oc create -f <file_name> 1

   1

   将 <file_name> 替换为计算机器设置配置 YAML 文件的名称。例如：gcp-arm64-machine-set-0.yaml, 或 gcp-amd64-machine-set-0.yaml。

验证

1. 运行以下命令，查看计算机器集列表：

   $ oc get machineset -n openshift-machine-api

   输出必须包含您创建的机器集。

   输出示例

   NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
   <infrastructure_id>-gcp-machine-set-0                   2        2      2          2  10m

2. 您可以运行以下命令来检查节点是否已就绪并可以调度：

   $ oc get nodes

流程

1. 登录 OpenShift CLI (oc)。

2. 您可以运行以下命令来检查集群是否使用构架有效负载：

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

流程

1. 运行以下命令，从集群中删除 Ignition 配置文件：

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

2. 将您从集群导出的 worker.ign Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。

3. 您可以验证 ignition 文件是否在 URL 上可用。以下示例获取计算节点的 Ignition 配置文件：

   $ curl -k http://<HTTP_server>/worker.ign

4. 您可以运行以下命令来访问 ISO 镜像以引导新机器：

   RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.<architecture>.artifacts.metal.formats.iso.disk.location')

5. 使用 ISO 文件在更多计算机器上安装 RHCOS。在安装集群前，使用创建机器时使用的相同方法：

   • 将 ISO 镜像刻录到磁盘并直接启动。
   • 在 LOM 接口中使用 ISO 重定向。

6. 在不指定任何选项或中断实时引导序列的情况下引导 RHCOS ISO 镜像。等待安装程序在 RHCOS live 环境中引导进入 shell 提示符。

   注意

   您可以中断 RHCOS 安装引导过程来添加内核参数。但是，在这个 ISO 过程中，您应该使用以下步骤中所述的 coreos-installer 命令，而不是添加内核参数。

7. 运行 coreos-installer 命令并指定满足您的安装要求的选项。您至少必须指定指向节点类型的 Ignition 配置文件的 URL，以及您要安装到的设备：

   $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12

   1

   您必须使用 sudo 运行 coreos-installer 命令，因为 core 用户没有执行安装所需的 root 权限。

   2

   当 Ignition 配置文件通过 HTTP URL 获取时，需要 --ignition-hash 选项来验证集群节点上 Ignition 配置文件的真实性。<digest> 是上一步中获取的 Ignition 配置文件 SHA512 摘要。

   注意

   如果要通过使用 TLS 的 HTTPS 服务器提供 Ignition 配置文件，您可以在运行 coreos-installer 前将内部证书颁发机构(CA)添加到系统信任存储中。

   以下示例将引导节点安装初始化到 /dev/sda 设备。bootstrap 节点的 Ignition 配置文件从 IP 地址 192.168.1.2 的 HTTP Web 服务器获取：

   $ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b

8. 在机器的控制台上监控 RHCOS 安装的进度。

   重要

   在开始安装 OpenShift Container Platform 之前，确保每个节点中安装成功。观察安装过程可以帮助确定可能会出现 RHCOS 安装问题的原因。

9. 继续为集群创建更多计算机器。

流程

1. 确认 RHCOS 镜像的 PXE 或 iPXE 安装正确。

   • 对于 PXE：

     DEFAULT pxeboot
     TIMEOUT 20
     PROMPT 0
     LABEL pxeboot
         KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
         APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2

     1

     指定上传到 HTTP 服务器的 live kernel 文件位置。

     2

     指定上传到 HTTP 服务器的 RHCOS 文件的位置。initrd 参数值是 live initramfs 文件的位置，coreos.inst.ignition_url 参数值是 worker Ignition 配置文件的位置，coreos.live.rootfs_url 参数值是 live rootfs 文件的位置。coreos.inst.ignition_url 和 coreos.live.rootfs_url 参数仅支持 HTTP 和 HTTPS。

     注意

     此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台，请在 APPEND 行中添加一个或多个 console= 参数。例如，添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台，并将图形控制台设置为二级控制台。如需更多信息，请参阅 如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台？

   • 对于 iPXE (x86_64 + aarch64)：

     kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
     initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3
     boot

     1

     指定上传到 HTTP 服务器的 RHCOS 文件的位置。kernel 参数值是 kernel 文件的位置，在 UEFI 系统中引导时需要 initrd=main 参数，coreos.live.rootfs_url 参数值是 rootfs 文件的位置，coreos.inst.ignition_url 参数值则是 worker Ignition 配置文件的位置。

     2

     如果您使用多个 NIC，请在 ip 选项中指定一个接口。例如，要在名为 eno1 的 NIC 上使用 DHCP，请设置 ip=eno1:dhcp。

     3

     指定上传到 HTTP 服务器的 initramfs 文件的位置。

     注意

     此配置不会在使用图形控制台配置不同的控制台的机器上启用串行控制台访问，请在 kernel 行中添加一个或多个 console= 参数。例如，添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台，并将图形控制台设置为二级控制台。如需更多信息，请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台？ 和"启用 PXE 和 ISO 安装的串行控制台"部分。

     注意

     要在 aarch64 架构中网络引导 CoreOS 内核，您需要使用启用了 IMAGE_GZIP 选项的 iPXE 构建版本。请参阅 iPXE 中的IMAGE_GZIP 选项。

   • 对于 aarch64 中的 PXE（使用 UEFI 和 GRUB 作为第二阶段）：

     menuentry 'Install CoreOS' {
         linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
         initrd rhcos-<version>-live-initramfs.<architecture>.img 3
     }

     1

     指定上传到 HTTP/TFTP 服务器的 RHCOS 文件的位置。kernel 参数值是 TFTP 服务器中的 kernel 文件的位置。coreos.live.rootfs_url 参数值是 rootfs 文件的位置，coreos.inst.ignition_url 参数值则是 HTTP 服务器上的 worker Ignition 配置文件的位置。

     2

     如果您使用多个 NIC，请在 ip 选项中指定一个接口。例如，要在名为 eno1 的 NIC 上使用 DHCP，请设置 ip=eno1:dhcp。

     3

     指定上传到 TFTP 服务器的 initramfs 文件的位置。

2. 使用 PXE 或 iPXE 基础架构为集群创建所需的计算机器。

流程

1. 确认集群可以识别这些机器：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.29.4
   master-1  Ready     master  63m  v1.29.4
   master-2  Ready     master  64m  v1.29.4

   输出中列出了您创建的所有机器。

   注意

   在有些 CSR 被批准前，前面的输出可能不包括计算节点（也称为 worker 节点）。

2. 检查待处理的 CSR，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   在本例中，两台机器加入集群。您可能会在列表中看到更多已批准的 CSR。

3. 如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：

   注意

   由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后，Kubelet 为服务证书创建一个二级 CSR，这需要手动批准。然后，如果 Kubelet 请求具有相同参数的新证书，则后续提供证书续订请求由 machine-approver 自动批准。

   注意

   对于在未启用机器 API 的平台上运行的集群，如裸机和其他用户置备的基础架构，您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     注意

     在有些 CSR 被批准前，一些 Operator 可能无法使用。

4. 现在，您的客户端请求已被批准，您必须查看添加到集群中的每台机器的服务器请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 如果剩余的 CSR 没有被批准，且处于 Pending 状态，请批准集群机器的 CSR：

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. 批准所有客户端和服务器 CSR 后，机器将 处于 Ready 状态。运行以下命令验证：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.29.4
   master-1  Ready     master  73m  v1.29.4
   master-2  Ready     master  74m  v1.29.4
   worker-0  Ready     worker  11m  v1.29.4
   worker-1  Ready     worker  11m  v1.29.4

   注意

   批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态。

流程

1. 登录 OpenShift CLI (oc)。

2. 您可以运行以下命令来检查集群是否使用构架有效负载：

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

流程

1. 禁用 UDP 聚合。

   目前，IBM Z® 不支持 UDP 聚合，且不会在带有 x86_64 control plane 和其他 s390x 计算机器的多架构计算机器上自动取消激活 UDP 聚合。为确保正确在集群中添加额外的计算节点，您必须手动禁用 UDP 聚合。

   1. 使用以下内容创建 YAML 文件 udp-aggregation-config.yaml ：

      apiVersion: v1
      kind: ConfigMap
      data:
        disable-udp-aggregation: "true"
      metadata:
        name: udp-aggregation-config
        namespace: openshift-network-operator

   2. 运行以下命令来创建 ConfigMap 资源：

      $ oc create -f udp-aggregation-config.yaml

2. 运行以下命令，从集群中删除 Ignition 配置文件：

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

3. 将您从集群导出的 worker.ign Ignition 配置文件上传到 HTTP 服务器。注意此文件的 URL。

4. 您可以验证 Ignition 文件是否在 URL 上可用。以下示例获取计算节点的 Ignition 配置文件：

   $ curl -k http://<http_server>/worker.ign

5. 运行以下命令下载 RHEL live kernel、initramfs 和 rootfs 文件：

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')

6. 将下载的 RHEL live kernel、initramfs 和 rootfs 文件移到可从您要添加的 z/VM 客户机访问的 HTTP 或 HTTPS 服务器中。

7. 为 z/VM 客户机创建一个参数文件。以下参数特定于虚拟机：

   • 可选： 要指定一个静态 IP 地址，请添加带有以下条目的 ip= 参数，每个条目用冒号隔开：

     1. 计算机的 IP 地址。
     2. 个空字符串。
     3. 网关
     4. 子网掩码.
     5. hostname.domainname 格式的机器主机和域名。省略这个值可让 RHCOS 决定。
     6. 网络接口名称。省略这个值可让 RHCOS 决定。
     7. 值 none。
   • 对于 coreos.inst.ignition_url=，请指定 worker.ign 文件的 URL。仅支持 HTTP 和 HTTPS 协议。
   • 对于 coreos.live.rootfs_url=，请为您引导的 kernel 和 initramfs 指定匹配的 rootfs 构件。仅支持 HTTP 和 HTTPS 协议。

   • 对于在 DASD 类型磁盘中安装，请完成以下任务：

     1. 对于 coreos.inst.install_dev=，请指定 /dev/dasda。
     2. Userd .dasd= 指定安装 RHCOS 的 DASD。

     3. 如果需要，您可以对参数进行进一步的调整。

        以下是一个示例参数文件 additional-worker-dasd.parm ：

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/dasda \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        rd.dasd=0.0.3490 \
        zfcp.allow_lun_scan=0

        将参数文件中的所有选项写为一行，并确保您没有换行字符。

   • 对于在 FCP 类型磁盘中安装，请完成以下任务：

     1. User d.zfcp=<adapter>,<wwpn>,<lun> 以指定要安装 RHCOS 的 FCP 磁盘。对于多路径，为每个额外路径重复此步骤。

        注意

        当使用多个路径安装时，您必须在安装后直接启用多路径，而不是在以后启用多路径，因为这可能导致问题。

     2. 将安装设备设置为：coreos.inst.install_dev=/dev/sda。

        注意

        如果使用 NPIV 配置额外的 LUN，FCP 需要 zfcp.allow_lun_scan=0。如果必须启用 zfcp.allow_lun_scan=1，因为您使用 CSI 驱动程序，则必须配置 NPIV，以便每个节点无法访问另一个节点的引导分区。

     3. 如果需要，您可以对参数进行进一步的调整。

        重要

        需要额外的安装后步骤才能完全启用多路径。如需更多信息，请参阅 安装后机器配置任务 中的"使用 RHCOS 上内核参数启用多路径"。

        以下是使用多路径的 worker 节点的 additional-worker-fcp.parm 示例参数文件：

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/sda \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000

        将参数文件中的所有选项写为一行，并确保您没有换行字符。

8. 使用 FTP 将 initramfs、kernel、参数文件和 RHCOS 镜像传送到 z/VM 中。有关如何使用 FTP 传输文件并从虚拟读取器引导的详情，请参阅 在 Z/VM 中安装。

9. 将文件 punch 到 z/VM 虚拟机的虚拟读取器。

   请参阅 IBM® 文档中的 PUNCH。

   提示

   您可以使用 CP PUNCH 命令，或者，如果使用 Linux，则使用 vmur 命令在两个 z/VM 虚拟机之间传输文件。

10. 在 bootstrap 机器上登录到 CMS。

11. 运行以下命令，从 reader IPL bootstrap 机器：

    $ ipl c

    请参阅 IBM® 文档中的 IPL。

流程

1. 确认集群可以识别这些机器：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.29.4
   master-1  Ready     master  63m  v1.29.4
   master-2  Ready     master  64m  v1.29.4

   输出中列出了您创建的所有机器。

   注意

   在有些 CSR 被批准前，前面的输出可能不包括计算节点（也称为 worker 节点）。

2. 检查待处理的 CSR，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   在本例中，两台机器加入集群。您可能会在列表中看到更多已批准的 CSR。

3. 如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：

   注意

   由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后，Kubelet 为服务证书创建一个二级 CSR，这需要手动批准。然后，如果 Kubelet 请求具有相同参数的新证书，则后续提供证书续订请求由 machine-approver 自动批准。

   注意

   对于在未启用机器 API 的平台上运行的集群，如裸机和其他用户置备的基础架构，您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     注意

     在有些 CSR 被批准前，一些 Operator 可能无法使用。

4. 现在，您的客户端请求已被批准，您必须查看添加到集群中的每台机器的服务器请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 如果剩余的 CSR 没有被批准，且处于 Pending 状态，请批准集群机器的 CSR：

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. 批准所有客户端和服务器 CSR 后，机器将 处于 Ready 状态。运行以下命令验证：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.29.4
   master-1  Ready     master  73m  v1.29.4
   master-2  Ready     master  74m  v1.29.4
   worker-0  Ready     worker  11m  v1.29.4
   worker-1  Ready     worker  11m  v1.29.4

   注意

   批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态。

流程

1. 登录 OpenShift CLI (oc)。

2. 您可以运行以下命令来检查集群是否使用构架有效负载：

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

流程

1. 禁用 UDP 聚合。

   目前，IBM Z® 不支持 UDP 聚合，且不会在带有 x86_64 control plane 和其他 s390x 计算机器的多架构计算机器上自动取消激活 UDP 聚合。为确保正确在集群中添加额外的计算节点，您必须手动禁用 UDP 聚合。

   1. 使用以下内容创建 YAML 文件 udp-aggregation-config.yaml ：

      apiVersion: v1
      kind: ConfigMap
      data:
        disable-udp-aggregation: "true"
      metadata:
        name: udp-aggregation-config
        namespace: openshift-network-operator

   2. 运行以下命令来创建 ConfigMap 资源：

      $ oc create -f udp-aggregation-config.yaml

2. 运行以下命令，从集群中删除 Ignition 配置文件：

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

3. 将您从集群导出的 worker.ign Ignition 配置文件上传到 HTTP 服务器。注意此文件的 URL。

4. 您可以验证 Ignition 文件是否在 URL 上可用。以下示例获取计算节点的 Ignition 配置文件：

   $ curl -k http://<http_server>/worker.ign

5. 运行以下命令下载 RHEL live kernel、initramfs 和 rootfs 文件：

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')

6. 将下载的 RHEL live kernel、initramfs 和 rootfs 文件移到可从您要添加的 z/VM 客户机访问的 HTTP 或 HTTPS 服务器中。

7. 为 z/VM 客户机创建一个参数文件。以下参数特定于虚拟机：

   • 可选： 要指定一个静态 IP 地址，请添加带有以下条目的 ip= 参数，每个条目用冒号隔开：

     1. 计算机的 IP 地址。
     2. 个空字符串。
     3. 网关
     4. 子网掩码.
     5. hostname.domainname 格式的机器主机和域名。省略这个值可让 RHCOS 决定。
     6. 网络接口名称。省略这个值可让 RHCOS 决定。
     7. 值 none。
   • 对于 coreos.inst.ignition_url=，请指定 worker.ign 文件的 URL。仅支持 HTTP 和 HTTPS 协议。
   • 对于 coreos.live.rootfs_url=，请为您引导的 kernel 和 initramfs 指定匹配的 rootfs 构件。仅支持 HTTP 和 HTTPS 协议。

   • 对于在 DASD 类型磁盘中安装，请完成以下任务：

     1. 对于 coreos.inst.install_dev=，请指定 /dev/dasda。
     2. Userd .dasd= 指定安装 RHCOS 的 DASD。

     3. 如果需要，您可以对参数进行进一步的调整。

        以下是一个示例参数文件 additional-worker-dasd.parm ：

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/dasda \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        rd.dasd=0.0.3490 \
        zfcp.allow_lun_scan=0

        将参数文件中的所有选项写为一行，并确保您没有换行字符。

   • 对于在 FCP 类型磁盘中安装，请完成以下任务：

     1. User d.zfcp=<adapter>,<wwpn>,<lun> 以指定要安装 RHCOS 的 FCP 磁盘。对于多路径，为每个额外路径重复此步骤。

        注意

        当使用多个路径安装时，您必须在安装后直接启用多路径，而不是在以后启用多路径，因为这可能导致问题。

     2. 将安装设备设置为：coreos.inst.install_dev=/dev/sda。

        注意

        如果使用 NPIV 配置额外的 LUN，FCP 需要 zfcp.allow_lun_scan=0。如果必须启用 zfcp.allow_lun_scan=1，因为您使用 CSI 驱动程序，则必须配置 NPIV，以便每个节点无法访问另一个节点的引导分区。

     3. 如果需要，您可以对参数进行进一步的调整。

        重要

        需要额外的安装后步骤才能完全启用多路径。如需更多信息，请参阅 安装后机器配置任务 中的"使用 RHCOS 上内核参数启用多路径"。

        以下是使用多路径的 worker 节点的 additional-worker-fcp.parm 示例参数文件：

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/sda \
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
        coreos.inst.ignition_url=http://<http_server>/worker.ign \
        ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000

        将参数文件中的所有选项写为一行，并确保您没有换行字符。

8. 使用 FTP 将 initramfs、kernel、参数文件和 RHCOS 镜像传送到 z/VM 中。有关如何使用 FTP 传输文件并从虚拟读取器引导的详情，请参阅 在 Z/VM 中安装。

9. 将文件 punch 到 z/VM 虚拟机的虚拟读取器。

   请参阅 IBM® 文档中的 PUNCH。

   提示

   您可以使用 CP PUNCH 命令，或者，如果使用 Linux，则使用 vmur 命令在两个 z/VM 虚拟机之间传输文件。

10. 在 bootstrap 机器上登录到 CMS。

11. 运行以下命令，从 reader IPL bootstrap 机器：

    $ ipl c

    请参阅 IBM® 文档中的 IPL。

流程

1. 确认集群可以识别这些机器：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.29.4
   master-1  Ready     master  63m  v1.29.4
   master-2  Ready     master  64m  v1.29.4

   输出中列出了您创建的所有机器。

   注意

   在有些 CSR 被批准前，前面的输出可能不包括计算节点（也称为 worker 节点）。

2. 检查待处理的 CSR，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   在本例中，两台机器加入集群。您可能会在列表中看到更多已批准的 CSR。

3. 如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：

   注意

   由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后，Kubelet 为服务证书创建一个二级 CSR，这需要手动批准。然后，如果 Kubelet 请求具有相同参数的新证书，则后续提供证书续订请求由 machine-approver 自动批准。

   注意

   对于在未启用机器 API 的平台上运行的集群，如裸机和其他用户置备的基础架构，您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     注意

     在有些 CSR 被批准前，一些 Operator 可能无法使用。

4. 现在，您的客户端请求已被批准，您必须查看添加到集群中的每台机器的服务器请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 如果剩余的 CSR 没有被批准，且处于 Pending 状态，请批准集群机器的 CSR：

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. 批准所有客户端和服务器 CSR 后，机器将 处于 Ready 状态。运行以下命令验证：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.29.4
   master-1  Ready     master  73m  v1.29.4
   master-2  Ready     master  74m  v1.29.4
   worker-0  Ready     worker  11m  v1.29.4
   worker-1  Ready     worker  11m  v1.29.4

   注意

   批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态。

流程

1. 登录 OpenShift CLI (oc)。

2. 您可以运行以下命令来检查集群是否使用构架有效负载：

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

流程

1. 禁用 UDP 聚合。

   目前，IBM Z® 不支持 UDP 聚合，且不会在带有 x86_64 control plane 和其他 s390x 计算机器的多架构计算机器上自动取消激活 UDP 聚合。为确保正确在集群中添加额外的计算节点，您必须手动禁用 UDP 聚合。

   1. 使用以下内容创建 YAML 文件 udp-aggregation-config.yaml ：

      apiVersion: v1
      kind: ConfigMap
      data:
        disable-udp-aggregation: "true"
      metadata:
        name: udp-aggregation-config
        namespace: openshift-network-operator

   2. 运行以下命令来创建 ConfigMap 资源：

      $ oc create -f udp-aggregation-config.yaml

2. 运行以下命令，从集群中删除 Ignition 配置文件：

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

3. 将您从集群导出的 worker.ign Ignition 配置文件上传到 HTTP 服务器。注意此文件的 URL。

4. 您可以验证 Ignition 文件是否在 URL 上可用。以下示例获取计算节点的 Ignition 配置文件：

   $ curl -k http://<HTTP_server>/worker.ign

5. 运行以下命令下载 RHEL live kernel、initramfs 和 rootfs 文件：

    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')

6. 在启动 virt-install 前，将下载的 RHEL live kernel、initramfs 和 rootfs 文件移到 HTTP 或 HTTPS 服务器中。

7. 使用 RHEL kernel、initramfs 和 Ignition 文件创建新的 KVM 客户机节点；新磁盘镜像，并调整了 parm 行参数。

   $ virt-install \
      --connect qemu:///system \
      --name <vm_name> \
      --autostart \
      --os-variant rhel9.4 \ 1
      --cpu host \
      --vcpus <vcpus> \
      --memory <memory_mb> \
      --disk <vm_name>.qcow2,size=<image_size> \
      --network network=<virt_network_parm> \
      --location <media_location>,kernel=<rhcos_kernel>,initrd=<rhcos_initrd> \ 2
      --extra-args "rd.neednet=1" \
      --extra-args "coreos.inst.install_dev=/dev/vda" \
      --extra-args "coreos.inst.ignition_url=http://<http_server>/worker.ign " \ 3
      --extra-args "coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img" \ 4
      --extra-args "ip=<ip>::<gateway>:<netmask>:<hostname>::none" \ 5
      --extra-args "nameserver=<dns>" \
      --extra-args "console=ttysclp0" \
      --noautoconsole \
      --wait

   1

   对于 os-variant，为 RHCOS 计算机器指定 RHEL 版本。rhel9.4 是推荐的版本。要查询支持的操作系统的 RHEL 版本，请运行以下命令：

   $ osinfo-query os -f short-id

   注意

   os-variant 是区分大小写的。

   2

   对于 --location，指定 kernel/initrd 在 HTTP 或 HTTPS 服务器上的位置。

   3

   指定 worker.ign 配置文件的位置。仅支持 HTTP 和 HTTPS 协议。

   4

   指定您要引导的 kernel 和 initramfs 的 rootfs 工件位置。仅支持 HTTP 和 HTTPS 协议

   5

   可选： 对于 hostname，指定客户端机器的完全限定主机名。

   注意

   如果您使用 HAProxy 作为负载均衡器，在 /etc/haproxy/haproxy.cfg 配置文件中为 ingress-router-443 和 ingress-router-80 更新 HAProxy 规则。

8. 继续为集群创建更多计算机器。

流程

1. 确认集群可以识别这些机器：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.29.4
   master-1  Ready     master  63m  v1.29.4
   master-2  Ready     master  64m  v1.29.4

   输出中列出了您创建的所有机器。

   注意

   在有些 CSR 被批准前，前面的输出可能不包括计算节点（也称为 worker 节点）。

2. 检查待处理的 CSR，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   在本例中，两台机器加入集群。您可能会在列表中看到更多已批准的 CSR。

3. 如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：

   注意

   由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后，Kubelet 为服务证书创建一个二级 CSR，这需要手动批准。然后，如果 Kubelet 请求具有相同参数的新证书，则后续提供证书续订请求由 machine-approver 自动批准。

   注意

   对于在未启用机器 API 的平台上运行的集群，如裸机和其他用户置备的基础架构，您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     注意

     在有些 CSR 被批准前，一些 Operator 可能无法使用。

4. 现在，您的客户端请求已被批准，您必须查看添加到集群中的每台机器的服务器请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 如果剩余的 CSR 没有被批准，且处于 Pending 状态，请批准集群机器的 CSR：

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. 批准所有客户端和服务器 CSR 后，机器将 处于 Ready 状态。运行以下命令验证：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.29.4
   master-1  Ready     master  73m  v1.29.4
   master-2  Ready     master  74m  v1.29.4
   worker-0  Ready     worker  11m  v1.29.4
   worker-1  Ready     worker  11m  v1.29.4

   注意

   批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态。

流程

1. 登录 OpenShift CLI (oc)。

2. 您可以运行以下命令来检查集群是否使用构架有效负载：

   $ oc adm release info -o jsonpath="{ .metadata.metadata}"

流程

1. 运行以下命令，从集群中删除 Ignition 配置文件：

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

2. 将您从集群导出的 worker.ign Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。

3. 您可以验证 ignition 文件是否在 URL 上可用。以下示例获取计算节点的 Ignition 配置文件：

   $ curl -k http://<HTTP_server>/worker.ign

4. 您可以运行以下命令来访问 ISO 镜像以引导新机器：

   RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.<architecture>.artifacts.metal.formats.iso.disk.location')

5. 使用 ISO 文件在更多计算机器上安装 RHCOS。在安装集群前，使用创建机器时使用的相同方法：

   • 将 ISO 镜像刻录到磁盘并直接启动。
   • 在 LOM 接口中使用 ISO 重定向。

6. 在不指定任何选项或中断实时引导序列的情况下引导 RHCOS ISO 镜像。等待安装程序在 RHCOS live 环境中引导进入 shell 提示符。

   注意

   您可以中断 RHCOS 安装引导过程来添加内核参数。但是，在这个 ISO 过程中，您应该使用以下步骤中所述的 coreos-installer 命令，而不是添加内核参数。

7. 运行 coreos-installer 命令并指定满足您的安装要求的选项。您至少必须指定指向节点类型的 Ignition 配置文件的 URL，以及您要安装到的设备：

   $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12

   1

   您必须使用 sudo 运行 coreos-installer 命令，因为 core 用户没有执行安装所需的 root 权限。

   2

   当 Ignition 配置文件通过 HTTP URL 获取时，需要 --ignition-hash 选项来验证集群节点上 Ignition 配置文件的真实性。<digest> 是上一步中获取的 Ignition 配置文件 SHA512 摘要。

   注意

   如果要通过使用 TLS 的 HTTPS 服务器提供 Ignition 配置文件，您可以在运行 coreos-installer 前将内部证书颁发机构(CA)添加到系统信任存储中。

   以下示例将引导节点安装初始化到 /dev/sda 设备。bootstrap 节点的 Ignition 配置文件从 IP 地址 192.168.1.2 的 HTTP Web 服务器获取：

   $ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b

8. 在机器的控制台上监控 RHCOS 安装的进度。

   重要

   在开始安装 OpenShift Container Platform 之前，确保每个节点中安装成功。观察安装过程可以帮助确定可能会出现 RHCOS 安装问题的原因。

9. 继续为集群创建更多计算机器。

流程

1. 确认 RHCOS 镜像的 PXE 或 iPXE 安装正确。

   • 对于 PXE：

     DEFAULT pxeboot
     TIMEOUT 20
     PROMPT 0
     LABEL pxeboot
         KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
         APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2

     1

     指定上传到 HTTP 服务器的 live kernel 文件位置。

     2

     指定上传到 HTTP 服务器的 RHCOS 文件的位置。initrd 参数值是 live initramfs 文件的位置，coreos.inst.ignition_url 参数值是 worker Ignition 配置文件的位置，coreos.live.rootfs_url 参数值是 live rootfs 文件的位置。coreos.inst.ignition_url 和 coreos.live.rootfs_url 参数仅支持 HTTP 和 HTTPS。

     注意

     此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台，请在 APPEND 行中添加一个或多个 console= 参数。例如，添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台，并将图形控制台设置为二级控制台。如需更多信息，请参阅 如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台？

   • 对于 iPXE (x86_64 + ppc64le)：

     kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
     initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3
     boot

     1

     指定上传到 HTTP 服务器的 RHCOS 文件的位置。kernel 参数值是 kernel 文件的位置，在 UEFI 系统中引导时需要 initrd=main 参数，coreos.live.rootfs_url 参数值是 rootfs 文件的位置，coreos.inst.ignition_url 参数值则是 worker Ignition 配置文件的位置。

     2

     如果您使用多个 NIC，请在 ip 选项中指定一个接口。例如，要在名为 eno1 的 NIC 上使用 DHCP，请设置 ip=eno1:dhcp。

     3

     指定上传到 HTTP 服务器的 initramfs 文件的位置。

     注意

     此配置不会在使用图形控制台配置不同的控制台的机器上启用串行控制台访问，请在 kernel 行中添加一个或多个 console= 参数。例如，添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台，并将图形控制台设置为二级控制台。如需更多信息，请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台？ 和"启用 PXE 和 ISO 安装的串行控制台"部分。

     注意

     要在 ppc64le 架构中网络引导 CoreOS kernel，您需要使用启用了 IMAGE_GZIP 选项的 iPXE 构建版本。请参阅 iPXE 中的IMAGE_GZIP 选项。

   • 对于 ppc64le 上的 PXE （使用 UEFI 和 GRUB 作为第二阶段）：

     menuentry 'Install CoreOS' {
         linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
         initrd rhcos-<version>-live-initramfs.<architecture>.img 3
     }

     1

     指定上传到 HTTP/TFTP 服务器的 RHCOS 文件的位置。kernel 参数值是 TFTP 服务器中的 kernel 文件的位置。coreos.live.rootfs_url 参数值是 rootfs 文件的位置，coreos.inst.ignition_url 参数值则是 HTTP 服务器上的 worker Ignition 配置文件的位置。

     2

     如果您使用多个 NIC，请在 ip 选项中指定一个接口。例如，要在名为 eno1 的 NIC 上使用 DHCP，请设置 ip=eno1:dhcp。

     3

     指定上传到 TFTP 服务器的 initramfs 文件的位置。

2. 使用 PXE 或 iPXE 基础架构为集群创建所需的计算机器。

流程

1. 确认集群可以识别这些机器：

   $ oc get nodes

   输出示例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.29.4
   master-1  Ready     master  63m  v1.29.4
   master-2  Ready     master  64m  v1.29.4

   输出中列出了您创建的所有机器。

   注意

   在有些 CSR 被批准前，前面的输出可能不包括计算节点（也称为 worker 节点）。

2. 检查待处理的 CSR，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   在本例中，两台机器加入集群。您可能会在列表中看到更多已批准的 CSR。

3. 如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：

   注意

   由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准客户端 CSR 后，Kubelet 为服务证书创建一个二级 CSR，这需要手动批准。然后，如果 Kubelet 请求具有相同参数的新证书，则后续提供证书续订请求由 machine-approver 自动批准。

   注意

   对于在未启用机器 API 的平台上运行的集群，如裸机和其他用户置备的基础架构，您必须实施一种方法来自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     注意

     在有些 CSR 被批准前，一些 Operator 可能无法使用。

4. 现在，您的客户端请求已被批准，您必须查看添加到集群中的每台机器的服务器请求：

   $ oc get csr

   输出示例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 如果剩余的 CSR 没有被批准，且处于 Pending 状态，请批准集群机器的 CSR：

   • 要单独批准，请对每个有效的 CSR 运行以下命令：

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> 是当前 CSR 列表中 CSR 的名称。

   • 要批准所有待处理的 CSR，请运行以下命令：

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. 批准所有客户端和服务器 CSR 后，机器将 处于 Ready 状态。运行以下命令验证：

   $ oc get nodes -o wide

   输出示例

   NAME               STATUS   ROLES                  AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                                                       KERNEL-VERSION                  CONTAINER-RUNTIME
   worker-0-ppc64le   Ready    worker                 42d   v1.29.5   192.168.200.21   <none>        Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.ppc64le   cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
   worker-1-ppc64le   Ready    worker                 42d   v1.29.5   192.168.200.20   <none>        Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.ppc64le   cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
   master-0-x86       Ready    control-plane,master   75d   v1.29.5   10.248.0.38      10.248.0.38   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
   master-1-x86       Ready    control-plane,master   75d   v1.29.5   10.248.0.39      10.248.0.39   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
   master-2-x86       Ready    control-plane,master   75d   v1.29.5   10.248.0.40      10.248.0.40   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
   worker-0-x86       Ready    worker                 75d   v1.29.5   10.248.0.43      10.248.0.43   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
   worker-1-x86       Ready    worker                 75d   v1.29.5   10.248.0.44      10.248.0.44   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9

   注意

   批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态。

流程

1. 标记您要运行 64k 页大小内核的节点：

   $ oc label node <node_name> <label>

   示例命令

   $ oc label node worker-arm64-01 node-role.kubernetes.io/worker-64k-pages=

2. 创建包含使用 ARM64 架构和 worker-64k-pages 角色的 worker 角色的机器配置池：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: worker-64k-pages
   spec:
     machineConfigSelector:
       matchExpressions:
         - key: machineconfiguration.openshift.io/role
           operator: In
           values:
           - worker
           - worker-64k-pages
     nodeSelector:
       matchLabels:
         node-role.kubernetes.io/worker-64k-pages: ""
         kubernetes.io/arch: arm64

3. 在计算节点上创建机器配置，以使用 64k-pages 参数启用 64k-pages。

   $ oc create -f <filename>.yaml

   MachineConfig 示例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: "worker-64k-pages" 1
     name: 99-worker-64kpages
   spec:
     kernelType: 64k-pages 2

   1

   在自定义机器配置池中指定 machineconfiguration.openshift.io/role 标签的值。MachineConfig 示例使用 worker-64k-pages 标签在 worker-64k-pages 池中启用 64k 页面。

   2

   指定所需的内核类型。有效值为 64k-pages 和 default

   注意

   64k-pages 类型仅支持基于 64 位 ARM 架构。realtime 类型仅支持基于 64 位 x86 架构。

流程

1. 运行以下命令，创建一个名为 openshift-multiarch-tuning-operator 的新项目：

   $ oc create ns openshift-multiarch-tuning-operator

2. 创建一个 OperatorGroup 对象：

   1. 使用用于创建 OperatorGroup 对象的配置创建 YAML 文件。

      创建 OperatorGroup 对象的 YAML 配置示例：

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: openshift-multiarch-tuning-operator
        namespace: openshift-multiarch-tuning-operator
      spec: {}

   2. 运行以下命令来创建 OperatorGroup 对象：

      $ oc create -f <file_name> 1

      1

      将 <file_name> 替换为包含 OperatorGroup 对象配置的 YAML 文件的名称。

3. 创建 Subscription 对象：

   1. 使用用于创建 Subscription 对象的配置创建 YAML 文件。

      创建 Subscription 对象的 YAML 配置示例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-multiarch-tuning-operator
        namespace: openshift-multiarch-tuning-operator
      spec:
        channel: stable
        name: multiarch-tuning-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        installPlanApproval: Automatic
        startingCSV: multiarch-tuning-operator.v1.0.0

   2. 运行以下命令来创建 Subscription 对象：

      $ oc create -f <file_name> 1

      1

      将 <file_name> 替换为包含 Subscription 对象配置的 YAML 文件的名称。

验证

1. 要验证是否安装了 Multiarch Tuning Operator，请运行以下命令：

   $ oc get csv -n openshift-multiarch-tuning-operator

   输出示例

   NAME                               DISPLAY                     VERSION   REPLACES                              PHASE
   multiarch-tuning-operator.v1.0.0   Multiarch Tuning Operator   1.0.0     multiarch-tuning-operator.v0.9.0      Succeeded

   如果 Operator 处于 Succeeded 阶段，则安装可以成功。

2. 可选：要验证是否创建了 OperatorGroup 对象，请运行以下命令：

   $ oc get operatorgroup -n openshift-multiarch-tuning-operator

   输出示例

   NAME                                        AGE
   openshift-multiarch-tuning-operator-q8zbb   133m

3. 可选：要验证是否已创建 Subscription 对象，请运行以下命令：

   $ oc get subscription -n openshift-multiarch-tuning-operator

   输出示例

   NAME                        PACKAGE                     SOURCE                  CHANNEL
   multiarch-tuning-operator   multiarch-tuning-operator   redhat-operators        stable

流程

1. 登陆到 OpenShift Container Platform Web 控制台。
2. 进入到 Operators → OperatorHub。
3. 在搜索字段中输入 Multiarch Tuning Operator。
4. 点 Multiarch Tuning Operator。
5. 从 Version 列表中选择 Multiarch Tuning Operator 版本。
6. 点 Install

7. 在 Operator 安装页面中设置以下选项 ：

   1. 将 Update Channel 设置为 stable。
   2. 将 Installation Mode 设置为 All namespaces on the cluster。

   3. 将 Installed Namespace 设置为 Operator recommended Namespace 或 Select a Namespace。

      推荐的 Operator 命名空间是 openshift-multiarch-tuning-operator。如果 openshift-multiarch-tuning-operator 命名空间不存在，它会在 Operator 安装过程中创建。

      如果选择 Select a namespace，则必须从 Select Project 列表中选择 Operator 的命名空间。

   4. 将 Update approval 设置为 Automatic 或 Manual。

      如果选择 Automatic 更新，Operator Lifecycle Manager (OLM) 将自动更新 Multiarch Tuning Operator 的运行实例，而无需任何干预。

      如果选择 手动 更新，OLM 会创建一个更新请求。作为集群管理员，您必须手动批准更新请求，才能将 Multiarch Tuning Operator 更新至更新的版本。

8. 可选：选择 Enable Operator recommended cluster monitoring on this Namespace 复选框。
9. 点 Install。

验证

1. 导航到 Operators → Installed Operators。
2. 验证 Multiarch Tuning Operator 是否已列出，Status 字段在 openshift-multiarch-tuning-operator 命名空间中为 Succeeded。

流程

1. 登录 OpenShift CLI (oc)。

2. 运行以下命令来删除 ClusterPodPlacementConfig 对象：

   $ oc delete clusterpodplacementconfig cluster

流程

1. 登陆到 OpenShift Container Platform Web 控制台。
2. 导航到 Operators → Installed Operators。
3. 在 Installed Operators 页面中，点 Multiarch Tuning Operator。
4. 点 Cluster Pod Placement Config 选项卡。
5. 从选项菜单中选择 Delete ClusterPodPlacementConfig。
6. 点击 Delete。

流程

1. 运行以下命令，获取 Multiarch Tuning Operator 的 Subscription 对象名称：

   $ oc get subscription.operators.coreos.com -n <namespace> 1

   1

   将 <namespace> 替换为您要卸载 Multiarch Tuning Operator 的命名空间的名称。

   输出示例

   NAME                                  PACKAGE                     SOURCE             CHANNEL
   openshift-multiarch-tuning-operator   multiarch-tuning-operator   redhat-operators   stable

2. 运行以下命令，获取 Multiarch Tuning Operator 的 currentCSV 值：

   $ oc get subscription.operators.coreos.com <subscription_name> -n <namespace> -o yaml | grep currentCSV 1

   1

   将 <subscription_name> 替换为 Subscription 对象名称。例如：openshift-multiarch-tuning-operator。将 <namespace> 替换为您要卸载 Multiarch Tuning Operator 的命名空间的名称。

   输出示例

   currentCSV: multiarch-tuning-operator.v1.0.0

3. 运行以下命令来删除 Subscription 对象：

   $ oc delete subscription.operators.coreos.com <subscription_name> -n <namespace> 1

   1

   将 <subscription_name> 替换为 Subscription 对象名称。将 <namespace> 替换为您要卸载 Multiarch Tuning Operator 的命名空间的名称。

   输出示例

   subscription.operators.coreos.com "openshift-multiarch-tuning-operator" deleted

4. 运行以下命令，使用 currentCSV 值删除目标命名空间中 Multiarch Tuning Operator 的 CSV：

   $ oc delete clusterserviceversion <currentCSV_value> -n <namespace> 1

   1

   将 <currentCSV> 替换为 Multiarch Tuning Operator 的 currentCSV 值。例如：multiarch-tuning-operator.v1.0.0。将 <namespace> 替换为您要卸载 Multiarch Tuning Operator 的命名空间的名称。

   输出示例

   clusterserviceversion.operators.coreos.com "multiarch-tuning-operator.v1.0.0" deleted

流程

1. 登陆到 OpenShift Container Platform Web 控制台。
2. 进入到 Operators → OperatorHub。
3. 在搜索字段中输入 Multiarch Tuning Operator。
4. 点 Multiarch Tuning Operator。
5. 点 Details 标签页。
6. 在 Actions 菜单中，选择 Uninstall Operator。
7. 出现提示时，点 Uninstall。

验证

1. 导航到 Operators → Installed Operators。
2. 在 Installed Operators 页面中，验证 Multiarch Tuning Operator 没有被列出。

流程

1. 运行以下命令，查看集群中的计算机器：

   $ oc get machinesets.machine.openshift.io -n openshift-machine-api

   计算机器集以 <clusterid>-worker-<aws-region-az> 的形式列出。

2. 运行以下命令，查看集群中的计算机器：

   $ oc get machines.machine.openshift.io -n openshift-machine-api

3. 运行以下命令，在要删除的计算机器上设置注解：

   $ oc annotate machines.machine.openshift.io/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"

4. 运行以下命令来扩展计算机器集：

   $ oc scale --replicas=2 machinesets.machine.openshift.io <machineset> -n openshift-machine-api

   或者：

   $ oc edit machinesets.machine.openshift.io <machineset> -n openshift-machine-api

   提示

   您还可以应用以下 YAML 来扩展计算机器集：

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     name: <machineset>
     namespace: openshift-machine-api
   spec:
     replicas: 2

   您可以扩展或缩减计算机器。需要过几分钟以后新机器才可用。

   重要

   默认情况下，机器控制器会尝试排空在机器上运行的节点，直到成功为止。在某些情况下，如错误配置了 pod 中断预算，排空操作可能无法成功。如果排空操作失败，机器控制器无法继续删除机器。

   您可以通过在特定机器上注解 machine.openshift.io/exclude-node-draining 来跳过排空节点。

1. 编辑调度程序 Operator CR 以添加默认的集群范围节点选择器：

   $ oc edit scheduler cluster

   使用节点选择器的调度程序 Operator CR 示例

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     name: cluster
   ...
   spec:
     defaultNodeSelector: type=user-node,region=east 1
     mastersSchedulable: false

   1

   使用适当的 <key>:<value> 对添加节点选择器。

   完成此更改后，请等待重新部署 openshift-kube-apiserver 项目中的 pod。这可能需要几分钟。只有重新部署 pod 后，默认的集群范围节点选择器才会生效。

2. 使用计算机器集或直接编辑节点，为节点添加标签：

   • 在创建节点时，使用计算机器集向由计算机器设置管理的节点添加标签：

     1. 运行以下命令，将标签添加到 MachineSet 对象中：

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api 1

        1

        为每个标识添加 <key>/<value> 对。

        例如：

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

        提示

        您还可以应用以下 YAML 来向计算机器集中添加标签：

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"

     2. 使用 oc edit 命令验证标签是否已添加到 MachineSet 对象中：

        例如：

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        MachineSet 对象示例

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
          ...
        spec:
          ...
          template:
            metadata:
          ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node
          ...

     3. 通过缩减至 0 并扩展节点来重新部署与该计算机器集关联的节点：

        例如：

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

     4. 当节点就绪并可用时，使用 oc get 命令验证该标签是否已添加到节点：

        $ oc get nodes -l <key>=<value>

        例如：

        $ oc get nodes -l type=user-node

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.29.4

   • 直接向节点添加标签：

     1. 为节点编辑 Node 对象：

        $ oc label nodes <name> <key>=<value>

        例如，若要为以下节点添加标签：

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east

        提示

        您还可以应用以下 YAML 来向节点添加标签：

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            type: "user-node"
            region: "east"

     2. 使用 oc get 命令验证标签是否已添加到节点：

        $ oc get nodes -l <key>=<value>,<key>=<value>

        例如：

        $ oc get nodes -l type=user-node,region=east

        输出示例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.29.4

1. 中 worke worker 延迟配置集：

   1. 编辑 node.config 对象：

      $ oc edit nodes.config/cluster

   2. 添加 spec.workerLatencyProfile: MediumUpdateAverageReaction ：

      node.config 对象示例

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: MediumUpdateAverageReaction 1
      
      # ...

      1

      指定中 worker 延迟策略。

      随着更改被应用，每个 worker 节点上的调度都会被禁用。

2. 可选：改为低 worker 延迟配置集：

   1. 编辑 node.config 对象：

      $ oc edit nodes.config/cluster

   2. 将 spec.workerLatencyProfile 值更改为 LowUpdateSlowReaction ：

      node.config 对象示例

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: LowUpdateSlowReaction 1
      
      # ...

      1

      指定使用低 worker 延迟策略。

流程

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

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

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

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

      $ 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

   2. 要查看特定计算机器集自定义资源 (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。

      2

      默认节点标签。

      注意

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

      3

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

3. 运行以下命令来创建 MachineSet CR：

   $ oc create -f <file_name>.yaml

流程

1. 向您要充当应用程序节点的 worker 节点添加标签：

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

2. 向您要充当基础架构节点的 worker 节点添加标签：

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

3. 检查相关节点现在是否具有 infra 角色或 app 角色：

   $ oc get nodes

4. 创建默认的集群范围节点选择器。默认节点选择器应用到在所有命名空间中创建的 pod。这会创建一个与 pod 上任何现有节点选择器交集的交集，这会额外限制 pod 的选择器。

   重要

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

   但是，不要设置可能会导致 pod 变得不可调度的默认节点选择器。例如，当 pod 的标签被设置为不同的节点角色（如 node-role.kubernetes.io/infra=""）时，将默认节点选择器设置为特定的节点角色（如 node-role.kubernetes.io/master=""）可能会导致 pod 无法调度。因此，将默认节点选择器设置为特定节点角色时要小心。

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

   1. 编辑 Scheduler 对象：

      $ oc edit scheduler cluster

   2. 使用适当的节点选择器添加 defaultNodeSelector 字段：

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

      1

      这个示例节点选择器默认在基础架构节点上部署 pod。

   3. 保存文件以使改变生效。

流程

1. 向您要分配为带有特定标签的 infra 节点的节点添加标签：

   $ oc label node <node_name> <label>

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

2. 创建包含 worker 角色和自定义角色作为机器配置选择器的机器配置池：

   $ 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

   添加 worker 角色和自定义角色。

   2

   将您添加的标签作为 nodeSelector 添加到节点。

   注意

   自定义机器配置池从 worker 池中继承机器配置。自定义池使用任何针对 worker 池的机器配置，但增加了部署仅针对自定义池的更改的功能。由于自定义池从 worker 池中继承资源，对 worker 池的任何更改也会影响自定义池。

3. 具有 YAML 文件后，您可以创建机器配置池：

   $ oc create -f infra.mcp.yaml

4. 检查机器配置，以确保基础架构配置成功：

   $ 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-* 前缀。

5. 可选：要部署对自定义池的更改，请创建一个机器配置，该配置使用自定义池名称作为标签，如本例中的 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-labeled 节点：

      $ oc create -f infra.mc.yaml

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

   $ 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

   在本例中，worker 节点被改为一个 infra 节点。

流程

1. 向 infra 节点添加污点以防止在其上调度用户工作负载：

   1. 确定节点是否具有污点：

      $ 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 添加容限。

   2. 如果您还没有配置污点以防止在其上调度用户工作负载：

      $ 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 effect 的节点仅调度容许该污点的 pod，但允许现有 pod 继续调度到该节点上。

      注意

      如果使用 descheduler，则违反了节点污点的 pod 可能会从集群驱除。

   3. 添加带有 NoExecute Effect 的污点，以及上述带有 NoSchedule Effect 的污点：

      $ 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。

2. 为要在 infra 节点上调度的 pod 配置添加容限，如路由器、registry 和监控工作负载。在 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 Operator，以要求节点上存在一个带有键为 node-role.kubernetes.io/infra 的污点。

   7

   指定添加到节点的键值对污点的值。

   此容忍度与 oc adm taint 命令创建的污点匹配。具有此容忍度的 pod 可以调度到 infra 节点上。

   注意

   并不总是能够将通过 OLM 安装的 Operator 的 Pod 移到 infra 节点。移动 Operator Pod 的能力取决于每个 Operator 的配置。

3. 使用调度程序将 pod 调度到 infra 节点。详情请参阅控制节点上的 pod 放置的文档。

流程

1. 查看路由器 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

2. 编辑 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> 对。如果您在 infrasructure 节点中添加了污点，还要添加匹配的容限。

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

   1. 查看路由器 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 节点上。

   2. 查看正在运行的 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.29.4

      由于角色列表包含 infra，因此 Pod 在正确的节点上运行。

流程

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

2. 编辑 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> 对。如果您在 infrasructure 节点中添加了污点，还要添加匹配的容限。

3. 验证 registry pod 已移至基础架构节点。

   1. 运行以下命令，以识别 registry pod 所在的节点：

      $ oc get pods -o wide -n openshift-image-registry

   2. 确认节点具有您指定的标签：

      $ oc describe node <node_name>

      查看命令输出，并确认 node-role.kubernetes.io/infra 列在 LABELS 列表中。

流程

1. 编辑 cluster-monitoring-config 配置映射，并更改 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> 对。如果您在 infrasructure 节点中添加了污点，还要添加匹配的容限。

2. 观察监控 pod 移至新机器：

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

3. 如果组件没有移到 infra 节点，请删除带有这个组件的 pod:

   $ oc delete pod -n openshift-monitoring <pod>

   已删除 pod 的组件在 infra 节点上重新创建。