16.6. 在 IBM Z 和 IBM LinuxONE 的 LPAR 上安装集群

流程

1. 设置静态 IP 地址。
2. 设置 HTTP 或 HTTPS 服务器，为集群节点提供 Ignition 文件。
3. 确保您的网络基础架构提供集群组件之间所需的网络连接。有关 要求的详情，请参阅用户置备的基础架构 的网络要求部分。

4. 将防火墙配置为启用 OpenShift Container Platform 集群组件进行通信所需的端口。如需有关所需端口的详细信息，请参阅用户置备的基础架构 部分的网络要求。

   重要

   默认情况下，OpenShift Container Platform 集群可以访问端口 1936，因为每个 control plane 节点都需要访问此端口。

   避免使用 Ingress 负载均衡器公开此端口，因为这样做可能会导致公开敏感信息，如统计信息和指标（与 Ingress Controller 相关的统计信息和指标）。

5. 为集群设置所需的 DNS 基础架构。

   1. 为 Kubernetes API、应用程序通配符、bootstrap 机器、control plane 机器和计算机器配置 DNS 名称解析。

   2. 为 Kubernetes API、bootstrap 机器、control plane 机器和计算机器配置反向 DNS 解析。

      如需有关 OpenShift Container Platform DNS 要求的更多信息，请参阅用户置备 DNS 要求部分。

6. 验证您的 DNS 配置。

   1. 从安装节点，针对 Kubernetes API 的记录名称、通配符路由和集群节点运行 DNS 查找。验证响应中的 IP 地址是否与正确的组件对应。

   2. 从安装节点，针对负载均衡器和集群节点的 IP 地址运行反向 DNS 查找。验证响应中的记录名称是否与正确的组件对应。

      有关详细的 DNS 验证步骤，请参阅用户置备的基础架构 验证 DNS 解析部分。

7. 置备所需的 API 和应用程序入口负载平衡基础架构。有关 要求的更多信息，请参阅用户置备的基础架构的负载平衡 要求部分。

流程

1. 从安装节点，针对 Kubernetes API 的记录名称、通配符路由和集群节点运行 DNS 查找。验证响应中包含的 IP 地址是否与正确的组件对应。

   1. 对 Kubernetes API 记录名称执行查询。检查结果是否指向 API 负载均衡器的 IP 地址：

      $ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain> 1

      1

      将 <nameserver_ip> 替换为 nameserver 的 IP 地址，<cluster_name> 替换为您的集群名称，<base_domain> 替换为您的基本域名。

      输出示例

      api.ocp4.example.com.		604800	IN	A	192.168.1.5

   2. 对 Kubernetes 内部 API 记录名称执行查询。检查结果是否指向 API 负载均衡器的 IP 地址：

      $ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>

      输出示例

      api-int.ocp4.example.com.		604800	IN	A	192.168.1.5

   3. 测试 *.apps.<cluster_name>.<base_domain> DNS 通配符查找示例。所有应用程序通配符查询都必须解析为应用程序入口负载均衡器的 IP 地址：

      $ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>

      输出示例

      random.apps.ocp4.example.com.		604800	IN	A	192.168.1.5

      注意

      在示例中，将相同的负载均衡器用于 Kubernetes API 和应用程序入口流量。在生产环境中，您可以单独部署 API 和应用程序入口负载均衡器，以便可以隔离扩展每个负载均衡器基础架构。

      您可以使用另一个通配符值替换 random。例如，您可以查询到 OpenShift Container Platform 控制台的路由：

      $ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>

      输出示例

      console-openshift-console.apps.ocp4.example.com. 604800 IN	A 192.168.1.5

   4. 针对 bootstrap DNS 记录名称运行查询。检查结果是否指向 bootstrap 节点的 IP 地址：

      $ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>

      输出示例

      bootstrap.ocp4.example.com.		604800	IN	A	192.168.1.96

   5. 使用此方法对 control plane 和计算节点的 DNS 记录名称执行查找。检查结果是否与每个节点的 IP 地址对应。

2. 从安装节点，针对负载均衡器和集群节点的 IP 地址运行反向 DNS 查找。验证响应中包含的记录名称是否与正确的组件对应。

   1. 对 API 负载均衡器的 IP 地址执行反向查找。检查响应是否包含 Kubernetes API 和 Kubernetes 内部 API 的记录名称：

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.5

      输出示例

      5.1.168.192.in-addr.arpa. 604800	IN	PTR	api-int.ocp4.example.com. 1
      5.1.168.192.in-addr.arpa. 604800	IN	PTR	api.ocp4.example.com. 2

      1

      为 Kubernetes 内部 API 提供记录名称。

      2

      为 Kubernetes API 提供记录名称。

      注意

      OpenShift Container Platform 应用程序通配符不需要 PTR 记录。针对应用程序入口负载均衡器的 IP 地址解析反向 DNS 解析不需要验证步骤。

   2. 对 bootstrap 节点的 IP 地址执行反向查找。检查结果是否指向 bootstrap 节点的 DNS 记录名称：

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.96

      输出示例

      96.1.168.192.in-addr.arpa. 604800	IN	PTR	bootstrap.ocp4.example.com.

   3. 使用此方法对 control plane 和计算节点的 IP 地址执行反向查找。检查结果是否与每个节点的 DNS 记录名称对应。

流程

1. 如果您在本地计算机上没有可用于在集群节点上进行身份验证的现有 SSH 密钥对，请创建一个。例如，在使用 Linux 操作系统的计算机上运行以下命令：

   $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1

   1

   指定新 SSH 密钥的路径和文件名，如 ~/.ssh/id_ed25519。如果您已有密钥对，请确保您的公钥位于 ~/.ssh 目录中。

   注意

   如果您计划在 x86_64、ppc64le 和 s390x 架构上安装使用 RHEL 加密库（这些加密库已提交给 NIST 用于 FIPS 140-2/140-3 验证）的 OpenShift Container Platform 集群，则不要创建使用 ed25519 算法的密钥。相反，创建一个使用 rsa 或 ecdsa 算法的密钥。

2. 查看公共 SSH 密钥：

   $ cat <path>/<file_name>.pub

   例如，运行以下命令来查看 ~/.ssh/id_ed25519.pub 公钥：

   $ cat ~/.ssh/id_ed25519.pub

3. 将 SSH 私钥身份添加到本地用户的 SSH 代理（如果尚未添加）。在集群节点上，或者要使用 ./openshift-install gather 命令，需要对该密钥进行 SSH 代理管理，才能在集群节点上进行免密码 SSH 身份验证。

   注意

   在某些发行版中，自动管理默认 SSH 私钥身份，如 ~/.ssh/id_rsa 和 ~/.ssh/id_dsa。

   1. 如果 ssh-agent 进程尚未为您的本地用户运行，请将其作为后台任务启动：

      $ eval "$(ssh-agent -s)"

      输出示例

      Agent pid 31874

      注意

      如果集群处于 FIPS 模式，则只使用 FIPS 兼容算法来生成 SSH 密钥。密钥必须是 RSA 或 ECDSA。

4. 将 SSH 私钥添加到 ssh-agent ：

   $ ssh-add <path>/<file_name> 1

   1

   指定 SSH 私钥的路径和文件名，如 ~/.ssh/id_ed25519.pub

   输出示例

   Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

流程

1. 访问 OpenShift Cluster Manager 站点的 Infrastructure Provider 页面。如果您有红帽帐户，请使用您的凭证登录。如果没有，请创建一个帐户。
2. 选择您的基础架构供应商。

3. 进入到安装类型的页面，下载与您的主机操作系统和架构对应的安装程序，并将该文件放在您要存储安装配置文件的目录中。

   重要

   安装程序会在用来安装集群的计算机上创建几个文件。在完成集群安装后，您必须保留安装程序和安装程序所创建的文件。这两个文件都需要删除集群。

   重要

   删除安装程序创建的文件不会删除您的集群，即使集群在安装过程中失败也是如此。要删除集群，请为特定云供应商完成 OpenShift Container Platform 卸载流程。

4. 提取安装程序。例如，在使用 Linux 操作系统的计算机上运行以下命令：

   $ tar -xvf openshift-install-linux.tar.gz

5. 从 Red Hat OpenShift Cluster Manager 下载安装 pull secret。此 pull secret 允许您与所含授权机构提供的服务进行身份验证，这些服务包括为 OpenShift Container Platform 组件提供容器镜像的 Quay.io。

流程

1. 导航到红帽客户门户网站上的 OpenShift Container Platform 下载页面。
2. 从 产品变体 下拉列表中选择架构。
3. 从 版本 下拉列表中选择适当的版本。
4. 点 OpenShift v4.16 Linux Client 条目旁的 Download Now 来保存文件。

5. 解包存档：

   $ tar xvf <file>

6. 将 oc 二进制文件放到 PATH 中的目录中。

   要查看您的 PATH，请执行以下命令：

   $ echo $PATH

流程

1. 导航到红帽客户门户网站上的 OpenShift Container Platform 下载页面。
2. 从 版本 下拉列表中选择适当的版本。
3. 点 OpenShift v4.16 Windows Client 条目旁的 Download Now 来保存文件。
4. 使用 ZIP 程序解压存档。

5. 将 oc 二进制文件移到 PATH 中的目录中。

   要查看您的 PATH，请打开命令提示并执行以下命令：

   C:\> path

流程

1. 导航到红帽客户门户网站上的 OpenShift Container Platform 下载页面。
2. 从 版本 下拉列表中选择适当的版本。

3. 点 OpenShift v4.16 macOS Client 条目旁的 Download Now 来保存文件。

   注意

   对于 macOS arm64，请选择 OpenShift v4.16 macOS arm64 Client 条目。

4. 解包和解压存档。

5. 将 oc 二进制文件移到 PATH 的目录中。

   要查看您的 PATH，请打开终端并执行以下命令：

   $ echo $PATH

流程

1. 创建一个安装目录来存储所需的安装资产：

   $ mkdir <installation_directory>

   重要

   您必须创建一个目录。有些安装资产，如 bootstrap X.509 证书的过期间隔较短，因此不得重复使用安装目录。如果要重复使用另一个集群安装中的单个文件，您可以将它们复制到您的目录中。但是，安装资产的文件名可能会在发行版本间有所变化。从以前的 OpenShift Container Platform 版本中复制安装文件时请小心。

2. 自定义提供的 install-config.yaml 文件模板示例，并将其保存在 <installation_directory> 中。

   注意

   此配置文件必须命名为 install-config.yaml。

3. 备份 install-config.yaml 文件，以便您可以使用它安装多个集群。

   重要

   install-config.yaml 文件会在安装过程的下一步中使用。现在必须备份它。

流程

1. 进入包含 OpenShift Container Platform 安装程序的目录，并为集群生成 Kubernetes 清单：

   $ ./openshift-install create manifests --dir <installation_directory> 1

   1

   对于 <installation_directory>，请指定包含您创建的 install-config.yaml 文件的安装目录。

   警告

   如果您要安装一个三节点集群，请跳过以下步骤，以便可以调度 control plane 节点。

   重要

   当您将 control plane 节点从默认的不可调度配置为可以调度时，需要额外的订阅。这是因为 control plane 节点变为计算节点。

2. 检查 <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes 清单文件中的 mastersSchedulable 参数是否已设置为 false。此设置可防止在 control plane 机器上调度 pod：

   1. 打开 <installation_directory>/manifests/cluster-scheduler-02-config.yml 文件。
   2. 找到 mastersSchedulable 参数，并确保它被设置为 false。
   3. 保存并退出 文件。

3. 要创建 Ignition 配置文件，请从包含安装程序的目录运行以下命令：

   $ ./openshift-install create ignition-configs --dir <installation_directory> 1

   1

   对于 <installation_directory>，请指定相同的安装目录。

   为安装目录中的 bootstrap、control plane 和计算节点创建 Ignition 配置文件。kubeadmin-password 和 kubeconfig 文件在 ./<installation_directory>/auth 目录中创建：

   .
   ├── auth
   │   ├── kubeadmin-password
   │   └── kubeconfig
   ├── bootstrap.ign
   ├── master.ign
   ├── metadata.json
   └── worker.ign

流程

1. 为 control plane 和计算节点创建 Butane 配置文件。

   以下 control plane 节点的 Butane 配置示例为磁盘加密创建一个名为 master-storage.bu 的文件：

   variant: openshift
   version: 4.16.0
   metadata:
     name: master-storage
     labels:
       machineconfiguration.openshift.io/role: master
   storage:
     luks:
       - clevis:
           tang:
             - thumbprint: QcPr_NHFJammnRCA3fFMVdNBwjs
               url: http://clevis.example.com:7500
           options: 1
              - --cipher
              - aes-cbc-essiv:sha256
         device: /dev/disk/by-partlabel/root 2
         label: luks-root
         name: root
         wipe_volume: true
     filesystems:
       - device: /dev/mapper/root
         format: xfs
         label: root
         wipe_filesystem: true
   openshift:
     fips: true 3

   1

   只有在启用了 FIPS 模式时才需要 cipher 选项。如果禁用了 FIPS，则省略该条目。

   2

   对于在 DASD 类型磁盘中安装，使用 device: /dev/disk/by-label/root 替换。

   3

   是否启用或禁用 FIPS 模式。默认情况下不启用 FIPS 模式。如果启用了 FIPS 模式，运行 OpenShift Container Platform 的 Red Hat Enterprise Linux CoreOS(RHCOS)机器会绕过默认的 Kubernetes 加密套件，并使用由 RHCOS 提供的加密模块。

2. 运行以下命令，创建自定义 initramfs 文件来引导机器：

   $ coreos-installer pxe customize \
       /root/rhcos-bootfiles/rhcos-<release>-live-initramfs.s390x.img \
       --dest-device /dev/disk/by-id/scsi-<serial_number> --dest-karg-append \
       ip=<ip_address>::<gateway_ip>:<subnet_mask>::<network_device>:none \
       --dest-karg-append nameserver=<nameserver_ip> \
       --dest-karg-append rd.neednet=1 -o \
       /root/rhcos-bootfiles/<node_name>-initramfs.s390x.img

   注意

   首次引导前，您必须为集群中的每个节点自定义 initramfs，并添加 PXE 内核参数。

3. 创建包含 ignition.platform.id=metal 和 ignition.firstboot 的参数文件。

   control plane 机器的内核参数文件示例

   cio_ignore=all,!condev rd.neednet=1 \
   console=ttysclp0 \
   coreos.inst.install_dev=/dev/<block_device> \1
   ignition.firstboot ignition.platform.id=metal \
   coreos.inst.ignition_url=http://<http_server>/master.ign \2
   coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \3
   ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
   rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 \
   rd.zfcp=0.0.5677,0x600606680g7f0056,0x034F000000000000 \4
   zfcp.allow_lun_scan=0

   1

   指定块设备类型。对于在 DASD 类型磁盘中安装，请指定 /dev/dasda。对于在 FCP 类型磁盘中安装，请指定 /dev/sda。

   2

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

   3

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

   4

   对于在 DASD 类型磁盘中安装，使用 rd.dasd=0.0.xxxx 替换来指定 DASD 设备。

   注意

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

流程

1. 在您的置备机器上登录到 Linux。

2. 从 RHCOS 镜像镜像获取 Red Hat Enterprise Linux CoreOS(RHCOS)内核、initramfs 和 rootfs 文件。

   重要

   RHCOS 镜像可能不会随着 OpenShift Container Platform 的每个发行版本而改变。您必须下载最高版本的镜像，其版本号应小于或等于您安装的 OpenShift Container Platform 版本。仅使用以下步骤中描述的适当 kernel、initramfs 和 rootfs 工件。

   文件名包含 OpenShift Container Platform 版本号。它们类似以下示例：

   • kernel: rhcos-<version>-live-kernel-<architecture>
   • initramfs: rhcos-<version>-live-initramfs.<architecture>.img

   • rootfs: rhcos-<version>-live-rootfs.<architecture>.img

     注意

     FCP 和 DASD 的 rootfs 镜像相同。

3. 创建参数文件。以下参数特定于特定虚拟机：

   • 对于 ip=，请指定以下七项：

     1. 计算机的 IP 地址。
     2. 个空字符串。
     3. 网关
     4. 子网掩码.
     5. hostname.domainname 格式的机器主机和域名。省略这个值可让 RHCOS 决定。
     6. 网络接口名称。省略这个值可让 RHCOS 决定。
     7. 如果使用静态 IP 地址，请指定 none。
   • 对于 coreos.inst.ignition_url=，请为机器角色指定 Ignition 文件。使用 bootstrap.ign、master.ign 或 worker.ign。仅支持 HTTP 和 HTTPS 协议。
   • 对于 coreos.live.rootfs_url=，请为您引导的内核和 initramfs 指定匹配的 rootfs 构件。仅支持 HTTP 和 HTTPS 协议。
   • 可选： 要启用安全引导，请添加 coreos.inst.secure_ipl

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

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

     3. 所有其他参数保持不变。

        bootstrap 机器的参数文件示例：bootstrap-0.parm ：

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/<block_device> \1
        coreos.inst.ignition_url=http://<http_server>/bootstrap.ign \2
        coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \3
        coreos.inst.secure_ipl \4
        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

        1

        指定块设备类型。对于在 DASD 类型磁盘中安装，请指定 /dev/dasda。对于在 FCP 类型磁盘中安装，请指定 /dev/sda。

        2

        指定 Ignition 配置文件的位置。使用 bootstrap.ign、master.ign 或 worker.ign。仅支持 HTTP 和 HTTPS 协议。

        3

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

        4

        可选： 要启用安全引导，请添加 coreos.inst.secure_ipl。

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

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

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

        注意

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

     2. 将安装设备设置为：coreos.inst.install_dev=/dev/disk/by-id/scsi-<serial_number>。

        注意

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

     3. 所有其他参数保持不变。

        重要

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

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

        cio_ignore=all,!condev rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/disk/by-id/scsi-<serial_number> \
        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 \
        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 \
        zfcp.allow_lun_scan=0

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

4. 将 initramfs、内核、参数文件和 RHCOS 镜像传送到 LPAR，例如使用 FTP。有关如何使用 FTP 和引导传输文件的详情，请参考 在 IBM Z® 上引导安装，以便在 LPAR 中安装 RHEL。
5. 引导机器
6. 对集群中的其他机器重复此步骤。

流程

1. 监控 bootstrap 过程：

   $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 1
       --log-level=info 2

   1

   对于 <installation_directory>，请指定安装文件保存到的目录的路径。

   2

   要查看不同的安装详情，请指定 warn、debug 或 error，而不是 info。

   输出示例

   INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
   INFO API v1.29.4 up
   INFO Waiting up to 30m0s for bootstrapping to complete...
   INFO It is now safe to remove the bootstrap resources

   当 Kubernetes API 服务器提示已在 control plane 机器上引导它时，该命令会成功。

2. bootstrap 过程完成后，从负载均衡器中删除 bootstrap 机器。

   重要

   此时您必须从负载均衡器中删除 bootstrap 机器。您还可以删除或重新格式化 bootstrap 机器本身。

流程

1. 导出 kubeadmin 凭证：

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   对于 <installation_directory>，请指定安装文件保存到的目录的路径。

2. 验证您可以使用导出的配置成功运行 oc 命令：

   $ oc whoami

   输出示例

   system:admin

流程

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-mddf5   20m   system:node:master-01.example.com   Approved,Issued
   csr-z5rln   16m   system:node:worker-21.example.com   Approved,Issued

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. 观察集群组件上线：

   $ watch -n5 oc get clusteroperators

   输出示例

   NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.16.0    True        False         False      19m
   baremetal                                  4.16.0    True        False         False      37m
   cloud-credential                           4.16.0    True        False         False      40m
   cluster-autoscaler                         4.16.0    True        False         False      37m
   config-operator                            4.16.0    True        False         False      38m
   console                                    4.16.0    True        False         False      26m
   csi-snapshot-controller                    4.16.0    True        False         False      37m
   dns                                        4.16.0    True        False         False      37m
   etcd                                       4.16.0    True        False         False      36m
   image-registry                             4.16.0    True        False         False      31m
   ingress                                    4.16.0    True        False         False      30m
   insights                                   4.16.0    True        False         False      31m
   kube-apiserver                             4.16.0    True        False         False      26m
   kube-controller-manager                    4.16.0    True        False         False      36m
   kube-scheduler                             4.16.0    True        False         False      36m
   kube-storage-version-migrator              4.16.0    True        False         False      37m
   machine-api                                4.16.0    True        False         False      29m
   machine-approver                           4.16.0    True        False         False      37m
   machine-config                             4.16.0    True        False         False      36m
   marketplace                                4.16.0    True        False         False      37m
   monitoring                                 4.16.0    True        False         False      29m
   network                                    4.16.0    True        False         False      38m
   node-tuning                                4.16.0    True        False         False      37m
   openshift-apiserver                        4.16.0    True        False         False      32m
   openshift-controller-manager               4.16.0    True        False         False      30m
   openshift-samples                          4.16.0    True        False         False      32m
   operator-lifecycle-manager                 4.16.0    True        False         False      37m
   operator-lifecycle-manager-catalog         4.16.0    True        False         False      37m
   operator-lifecycle-manager-packageserver   4.16.0    True        False         False      32m
   service-ca                                 4.16.0    True        False         False      38m
   storage                                    4.16.0    True        False         False      37m

2. 配置不可用的 Operator。

流程

1. 使用以下命令确认所有集群组件都在线：

   $ watch -n5 oc get clusteroperators

   输出示例

   NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.16.0    True        False         False      19m
   baremetal                                  4.16.0    True        False         False      37m
   cloud-credential                           4.16.0    True        False         False      40m
   cluster-autoscaler                         4.16.0    True        False         False      37m
   config-operator                            4.16.0    True        False         False      38m
   console                                    4.16.0    True        False         False      26m
   csi-snapshot-controller                    4.16.0    True        False         False      37m
   dns                                        4.16.0    True        False         False      37m
   etcd                                       4.16.0    True        False         False      36m
   image-registry                             4.16.0    True        False         False      31m
   ingress                                    4.16.0    True        False         False      30m
   insights                                   4.16.0    True        False         False      31m
   kube-apiserver                             4.16.0    True        False         False      26m
   kube-controller-manager                    4.16.0    True        False         False      36m
   kube-scheduler                             4.16.0    True        False         False      36m
   kube-storage-version-migrator              4.16.0    True        False         False      37m
   machine-api                                4.16.0    True        False         False      29m
   machine-approver                           4.16.0    True        False         False      37m
   machine-config                             4.16.0    True        False         False      36m
   marketplace                                4.16.0    True        False         False      37m
   monitoring                                 4.16.0    True        False         False      29m
   network                                    4.16.0    True        False         False      38m
   node-tuning                                4.16.0    True        False         False      37m
   openshift-apiserver                        4.16.0    True        False         False      32m
   openshift-controller-manager               4.16.0    True        False         False      30m
   openshift-samples                          4.16.0    True        False         False      32m
   operator-lifecycle-manager                 4.16.0    True        False         False      37m
   operator-lifecycle-manager-catalog         4.16.0    True        False         False      37m
   operator-lifecycle-manager-packageserver   4.16.0    True        False         False      32m
   service-ca                                 4.16.0    True        False         False      38m
   storage                                    4.16.0    True        False         False      37m

   另外，当所有集群都可用时，以下命令会通知您。它还检索并显示凭证：

   $ ./openshift-install --dir <installation_directory> wait-for install-complete 1

   1

   对于 <installation_directory>，请指定安装文件保存到的目录的路径。

   输出示例

   INFO Waiting up to 30m0s for the cluster to initialize...

   Cluster Version Operator 完成从 Kubernetes API 服务器部署 OpenShift Container Platform 集群时，该命令会成功。

   重要
   • 安装程序生成的 Ignition 配置文件包含 24 小时后过期的证书，然后在该时进行续订。如果在更新证书前关闭集群，且集群在 24 小时后重启，集群会自动恢复过期的证书。一个例外是，您必须手动批准待处理的 node-bootstrapper 证书签名请求(CSR)来恢复 kubelet 证书。如需更多信息，请参阅从过期的 control plane 证书 中恢复的文档。
   • 建议您在 Ignition 配置文件生成后的 12 小时内使用它们，因为 24 小时的证书会在集群安装后的 16 小时到 22 小时间进行轮转。通过在 12 小时内使用 Ignition 配置文件，您可以避免在安装过程中因为执行了证书更新而导致安装失败的问题。

2. 确认 Kubernetes API 服务器正在与 pod 通信。

   1. 要查看所有 pod 的列表，请使用以下命令：

      $ oc get pods --all-namespaces

      输出示例

      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
      openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
      openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
      openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
      openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
      openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
      ...

   2. 使用以下命令，查看上一命令的输出中所列 pod 的日志：

      $ oc logs <pod_name> -n <namespace> 1

      1

      指定 pod 名称和命名空间，如上一命令的输出中所示。

      如果 pod 日志显示，Kubernetes API 服务器可以与集群机器通信。

3. 对于使用光纤通道协议(FCP)的安装，还需要额外的步骤才能启用多路径。不要在安装过程中启用多路径。

   如需更多信息，请参阅 安装后机器配置任务 文档中的"使用 RHCOS 上使用内核参数启用多路径"。

1. 运行以下命令来调试节点：

   $ oc debug node/<node_name>
   chroot /host

2. 运行以下命令确认启用了安全引导：

   $ cat /sys/firmware/ipl/secure

   输出示例

   1 1

   1

   如果启用了安全引导，则值为 1，如果未启用安全引导，则值为 0。

3. 运行以下命令列出 re-IPL 配置：

   # lsreipl

   FCP 磁盘的输出示例

   Re-IPL type: fcp
   WWPN: 0x500507630400d1e3
   LUN: 0x4001400e00000000
   Device: 0.0.810e
   bootprog: 0
   br_lba: 0
   Loadparm: ""
   Bootparms: ""
   clear: 0

   DASD 磁盘输出示例

   for DASD output:
   Re-IPL type: ccw
   Device: 0.0.525d
   Loadparm: ""
   clear: 0

4. 运行以下命令来关闭节点：

   sudo shutdown -h

5. 从 LPAR 从硬件管理控制台 (HMC) 启动引导。请参阅 IBM 文档中的 从 LPAR 启动安全引导。
6. 当节点恢复时，再次检查安全引导状态。