4.7. 在 LPAR 中的 IBM Z 和 IBM LinuxONE 上使用多架构计算机器创建集群

流程

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 ：

        rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/dasda \
        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.dasd=0.0.3490

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

   • 对于在 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 示例参数文件：

        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 状态。