第 7 章 在 IBM Z 和 LinuxONE 上安装

流程

1. 设置静态 IP 地址
2. 设置一个 FTP 服务器。
3. 提供所需的负载均衡器。
4. 配置机器的端口。
5. 配置 DNS。
6. 确保网络可以正常工作。

流程

1. 如果还没有为计算机上免密码身份验证而配置的 SSH 密钥，请创建一个。例如，在使用 Linux 操作系统的计算机上运行以下命令：

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

   1

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

   运行此命令会在指定的位置生成不需要密码的 SSH 密钥。

   注意

   如果您计划在 x86_64 架构中安装使用 FIPS 验证的/Modules in Process 加密库的 OpenShift Container Platform 集群，不要创建使用 ed25519 算法的密钥。反之，创建一个使用 rsa 或 ecdsa 算法的密钥。

2. 作为后台任务启动 ssh-agent 进程：

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

   输出示例

   Agent pid 31874

   注意

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

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

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

   输出示例

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

   1

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

流程

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. 创建用来存储您所需的安装资产的安装目录：

   $ 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. 编辑 install-config.yaml 文件并添加代理设置。例如：

   apiVersion: v1
   baseDomain: my.domain.com
   proxy:
     httpProxy: http://<username>:<pswd>@<ip>:<port> 1
     httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
     noProxy: example.com 3
   additionalTrustBundle: | 4
       -----BEGIN CERTIFICATE-----
       <MY_TRUSTED_CA_CERT>
       -----END CERTIFICATE-----
   ...

   1

   用于创建集群外 HTTP 连接的代理 URL。URL 必须是 http。

   2

   用于创建集群外 HTTPS 连接的代理 URL。

   3

   要排除在代理中的目标域名、IP 地址或其他网络 CIDR 的逗号分隔列表。在域前面加 . 来仅匹配子域。例如： .y.com 匹配 x.y.com，但不匹配 y.com。使用 * 绕过所有目的地的代理。

   4

   如果提供，安装程序会在 openshift-config 命名空间中生成名为 user-ca- bundle 的配置映射来保存额外的 CA 证书。如果您提供 additionalTrustBundle 和至少一个代理设置，则 Proxy 对象会被配置为引用 trustedCA 字段中的 user-ca-bundle 配置映射。然后，Cluster Network Operator 会创建一个 trusted-ca-bundle 配置映射，该配置映射将为 trustedCA 参数指定的内容与 RHCOS 信任捆绑包合并。additionalTrustBundle 字段是必需的，除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。

   注意

   安装程序不支持代理的 readinessEndpoints 字段。

2. 保存该文件，并在安装 OpenShift Container Platform 时引用。

流程

1. 切换到包含安装程序的目录，并为集群生成 Kubernetes 清单：

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

   1

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

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>，请指定相同的安装目录。

   该目录中将生成以下文件：

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

流程

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

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

   重要

   RHCOS 镜像可能不会随着 OpenShift Container Platform 的每一发行版本都有改变。您必须下载最高版本的镜像，其版本号应小于或等于您安装的 OpenShift Container Platform 版本。只使用以下流程中描述的适当内核、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. 创建参数文件。以下参数特定于特定虚拟机：

   • 对于 coreos.inst.install_dev=，请为 DASD 安装指定 dasda ，或者为 FCP 指定 sda 。请注意 FCP 需要 zfcp.allow_lun_scan=0。
   • 对于 rd.dasd=，请指定要安装 RHCOS 的 DASD。
   • rd.zfcp=<adapter>,<wwpn>,<lun> 指定要在其中安装 RHCOS 的 FCP 磁盘。

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

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

   • 所有其他参数都可以保留。

     bootstrap 机器的实例参数文件（bootstrap-0.parm）如下：

     rd.neednet=1 \
     console=ttysclp0 \
     coreos.inst.install_dev=dasda \
     coreos.live.rootfs_url=http://cl1.provide.example.com:8080/assets/rhcos-live-rootfs.s390x.img \
     coreos.inst.ignition_url=http://cl1.provide.example.com:8080/ignition/bootstrap.ign \
     ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \
     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

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

4. 将 initramfs 、内核、参数文件和 RHCOS 镜像传送到 z/VM 中，例如使用 FTP。有关如何使用 FTP 传输文件并从虚拟 reader 引导的详情，请参考 在 Z/VM 中安装。

5. 将文件 punch 到 z/VM 虚拟机的虚拟 reader，即成为 bootstrap 节点。

   请参阅 IBM 文档中的 PUNCH。

   提示

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

6. 在 bootstrap 机器中登录到 CMS。

7. 从 reader IPL bootstrap 机器：

   $ ipl c

   请参阅 IBM 文档中的 IPL。

8. 对集群中的其他机器重复此步骤。

流程

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.19.0 up
   INFO Waiting up to 30m0s for bootstrapping to complete...
   INFO It is now safe to remove the bootstrap resources

   Kubernetes API 服务器提示已在 control plane 机器上完成 bootstrap 时，命令运行成功。

2. 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.19.0
   master-1  Ready     master  63m  v1.19.0
   master-2  Ready     master  64m  v1.19.0

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

   注意

   在一些 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、oc rsh 和 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.20.0
   master-1  Ready     master  73m  v1.20.0
   master-2  Ready     master  74m  v1.20.0
   worker-0  Ready     worker  11m  v1.20.0
   worker-1  Ready     worker  11m  v1.20.0

   注意

   批准服务器 CSR 后可能需要几分钟时间让机器转换为 Ready 状态。

流程

1. 观察集群组件上线：

   $ watch -n5 oc get clusteroperators

   输出示例

   NAME                                       VERSION AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.6.0   True        False         False      3h56m
   cloud-credential                           4.6.0   True        False         False      29h
   cluster-autoscaler                         4.6.0   True        False         False      29h
   config-operator                            4.6.0   True        False         False      6h39m
   console                                    4.6.0   True        False         False      3h59m
   csi-snapshot-controller                    4.6.0   True        False         False      4h12m
   dns                                        4.6.0   True        False         False      4h15m
   etcd                                       4.6.0   True        False         False      29h
   image-registry                             4.6.0   True        False         False      3h59m
   ingress                                    4.6.0   True        False         False      4h30m
   insights                                   4.6.0   True        False         False      29h
   kube-apiserver                             4.6.0   True        False         False      29h
   kube-controller-manager                    4.6.0   True        False         False      29h
   kube-scheduler                             4.6.0   True        False         False      29h
   kube-storage-version-migrator              4.6.0   True        False         False      4h2m
   machine-api                                4.6.0   True        False         False      29h
   machine-approver                           4.6.0   True        False         False      6h34m
   machine-config                             4.6.0   True        False         False      3h56m
   marketplace                                4.6.0   True        False         False      4h2m
   monitoring                                 4.6.0   True        False         False      6h31m
   network                                    4.6.0   True        False         False      29h
   node-tuning                                4.6.0   True        False         False      4h30m
   openshift-apiserver                        4.6.0   True        False         False      3h56m
   openshift-controller-manager               4.6.0   True        False         False      4h36m
   openshift-samples                          4.6.0   True        False         False      4h30m
   operator-lifecycle-manager                 4.6.0   True        False         False      29h
   operator-lifecycle-manager-catalog         4.6.0   True        False         False      29h
   operator-lifecycle-manager-packageserver   4.6.0   True        False         False      3h59m
   service-ca                                 4.6.0   True        False         False      29h
   storage                                    4.6.0   True        False         False      4h30m

2. 配置不可用的 Operator。

流程

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

   $ watch -n5 oc get clusteroperators

   输出示例

   NAME                                       VERSION AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication                             4.6.0   True        False         False      3h56m
   cloud-credential                           4.6.0   True        False         False      29h
   cluster-autoscaler                         4.6.0   True        False         False      29h
   config-operator                            4.6.0   True        False         False      6h39m
   console                                    4.6.0   True        False         False      3h59m
   csi-snapshot-controller                    4.6.0   True        False         False      4h12m
   dns                                        4.6.0   True        False         False      4h15m
   etcd                                       4.6.0   True        False         False      29h
   image-registry                             4.6.0   True        False         False      3h59m
   ingress                                    4.6.0   True        False         False      4h30m
   insights                                   4.6.0   True        False         False      29h
   kube-apiserver                             4.6.0   True        False         False      29h
   kube-controller-manager                    4.6.0   True        False         False      29h
   kube-scheduler                             4.6.0   True        False         False      29h
   kube-storage-version-migrator              4.6.0   True        False         False      4h2m
   machine-api                                4.6.0   True        False         False      29h
   machine-approver                           4.6.0   True        False         False      6h34m
   machine-config                             4.6.0   True        False         False      3h56m
   marketplace                                4.6.0   True        False         False      4h2m
   monitoring                                 4.6.0   True        False         False      6h31m
   network                                    4.6.0   True        False         False      29h
   node-tuning                                4.6.0   True        False         False      4h30m
   openshift-apiserver                        4.6.0   True        False         False      3h56m
   openshift-controller-manager               4.6.0   True        False         False      4h36m
   openshift-samples                          4.6.0   True        False         False      4h30m
   operator-lifecycle-manager                 4.6.0   True        False         False      29h
   operator-lifecycle-manager-catalog         4.6.0   True        False         False      29h
   operator-lifecycle-manager-packageserver   4.6.0   True        False         False      3h59m
   service-ca                                 4.6.0   True        False         False      29h
   storage                                    4.6.0   True        False         False      4h30m

   或者，通过以下命令，如果所有集群都可用您会接到通知。它还检索并显示凭证：

   $ ./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 证书中恢复的文档。
   • 建议您在生成 12 小时后使用 Ignition 配置文件，因为集群安装后 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 服务器可以与集群机器通信。

流程

1. 登录到集群：

   $ oc login

2. 在您要收集硬件信息的节点中，启动一个调试容器：

   $ oc debug node/<nodename>

3. 进入 /host 文件系统并启动 toolbox:

   $ chroot /host
   $ toolbox

4. 收集 dbginfo 数据：

   $ dbginfo.sh

5. 然后可以使用 scp来获取数据。