8.6. 故障排除

8.6.1. 安装程序工作流故障排除

在对安装环境进行故障排除之前,了解裸机上安装程序置备安装的整体流至关重要。下面的图表提供了故障排除流程,并按部就班地划分环境。

Flow-Diagram-1

install-config.yaml 文件出错或者无法访问 Red Hat Enterprise Linux CoreOS(RHCOS)镜像时,工作流 1(共 4 步) 的工作流演示了故障排除工作流。故障排除建议可在 故障排除 install-config.yaml 中找到。

Flow-Diagram-2

工作流 2(共 4 步) 描述了对 bootstrap 虚拟机问题 无法引导集群节点的 bootstrap 虚拟机 以及 检查日志 的故障排除工作流。当在没有 provisioning 网络的情况下安装 OpenShift Container Platform 集群时,这个工作流不适用。

Flow-Diagram-3

工作流 3(共 4 步)描述了 没有 PXE 引导的集群节点的故障排除工作流。如果使用 RedFish Virtual Media 进行安装,则每个节点必须满足安装程序部署该节点的最低固件要求。详情请查看 先决条件 部分中的使用拟介质安装对固件的要求

Flow-Diagram-4

工作流 4(共 4 步) 演示了 无法访问的 API 的故障验证的安装 的故障排除工作流。

8.6.2. install-config.yaml 故障排除

install-config.yaml 配置文件代表作为 OpenShift Container Platform 集群一部分的所有节点。该文件包含由 apiVersionbaseDomainimageContentSources 和虚拟 IP 地址组成的必要选项。如果在 OpenShift Container Platform 集群部署早期发生错误,则 install-config.yaml 配置文件中可能会出现错误。

流程

  1. 使用 YAML-tips 中的指南。
  2. 使用 syntax-check 来验证 YAML 语法是否正确。
  3. 验证 Red Hat Enterprise Linux CoreOS(RHCOS)QEMU 镜像是否已正确定义,并可以通过 install-config.yaml 提供的 URL 访问。例如:

    $ curl -s -o /dev/null -I -w "%{http_code}\n" http://webserver.example.com:8080/rhcos-44.81.202004250133-0-qemu.x86_64.qcow2.gz?sha256=7d884b46ee54fe87bbc3893bf2aa99af3b2d31f2e19ab5529c60636fbd0f1ce7

    如果输出为 200,则代表从存储 bootstrap 虚拟机镜像的 webserver 返回了有效的响应。

8.6.3. Bootstrap 虚拟机问题

OpenShift Container Platform 安装程序生成 bootstrap 节点虚拟机,该虚拟机处理置备 OpenShift Container Platform 集群节点。

流程

  1. 触发安装程序后大约 10 到 15 分钟,使用 virsh 命令检查 bootstrap 虚拟机是否正常运行:

    $ sudo virsh list
     Id    Name                           State
     --------------------------------------------
     12    openshift-xf6fq-bootstrap      running
    注意

    bootstrap 虚拟机的名称始终是集群名称再加上一组随机字符,并以"bootstrap"结尾。

    如果 bootstrap 虚拟机在 10 到 15 分钟后还没有运行,请检查其没有运行的原因。可能的问题包括:

  2. 确定在该系统中运行了 libvirtd:

    $ systemctl status libvirtd
    ● libvirtd.service - Virtualization daemon
       Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
       Active: active (running) since Tue 2020-03-03 21:21:07 UTC; 3 weeks 5 days ago
         Docs: man:libvirtd(8)
               https://libvirt.org
     Main PID: 9850 (libvirtd)
        Tasks: 20 (limit: 32768)
       Memory: 74.8M
       CGroup: /system.slice/libvirtd.service
               ├─ 9850 /usr/sbin/libvirtd

    如果 bootstrap 虚拟机可以正常工作,请登录它。

  3. 使用 virsh console 命令查找 bootstrap 虚拟机的 IP 地址:

    $ sudo virsh console example.com
    Connected to domain example.com
    Escape character is ^]
    Red Hat Enterprise Linux CoreOS 43.81.202001142154.0 (Ootpa) 4.3
    SSH host key: SHA256:BRWJktXZgQQRY5zjuAV0IKZ4WM7i4TiUyMVanqu9Pqg (ED25519)
    SSH host key: SHA256:7+iKGA7VtG5szmk2jB5gl/5EZ+SNcJ3a2g23o0lnIio (ECDSA)
    SSH host key: SHA256:DH5VWhvhvagOTaLsYiVNse9ca+ZSW/30OOMed8rIGOc (RSA)
    ens3:  fd35:919d:4042:2:c7ed:9a9f:a9ec:7
    ens4: 172.22.0.2 fe80::1d05:e52e:be5d:263f
    localhost login:
    重要

    当在没有 provisioning 网络的情况下部署 OpenShift Container Platform 集群时,您必须使用公共 IP 地址,而不是像 172.22.0.2 这样的私有 IP 地址。

  4. 获取 IP 地址后,使用 ssh 命令登录到 bootstrap 虚拟机:

    注意

    在上一步的控制台输出中,您可以使用 ens3 提供的 IPv6 IP 地址或 ens4 提供的 IPv4 IP。

    $ ssh core@172.22.0.2

如果您无法成功登录到 bootstrap 虚拟机,您可能会遇到以下情况之一:

  • 无法访问 172.22.0.0/24 网络。验证 provisioner 和 provisioning 网桥之间的网络连接。如果您使用 provisioning 网络,可能会出现此问题。
  • 您无法通过公共网络访问 bootstrap 虚拟机。当尝试通过 baremetal 网络进行 SSH 时,验证 provisioner 主机的连接,特别是 baremetal 网桥的连接。
  • 存在 Permission denied (publickey,password,keyboard-interactive) 问题。当尝试访问 bootstrap 虚拟机时,可能会出现 Permission denied 错误。验证试图登录到虚拟机的用户的 SSH 密钥是否在 install-config.yaml 文件中设置。

8.6.3.1. Bootstrap 虚拟机无法引导集群节点

在部署期间,bootstrap 虚拟机可能无法引导集群节点,这会阻止虚拟机使用 RHCOS 镜像置备节点。这可能是因为以下原因:

  • install-config.yaml 文件有问题。
  • 使用 baremetal 网络时出现带外网络访问的问题。

要验证这个问题,有三个与 ironic 相关的容器:

  • ironic-api
  • ironic-conductor
  • ironic-inspector

流程

  1. 登录到 bootstrap 虚拟机:

    $ ssh core@172.22.0.2
  2. 要检查容器日志,请执行以下操作:

    [core@localhost ~]$ sudo podman logs -f <container-name>

    <container-name> 替换为 ironic-apiironic-conductorironic-inspector 之一。如果您遇到 control plane 节点没有通过 PXE 引导的问题,请检查 ironic-conductor pod。ironic-conductor pod 包含了有关尝试引导集群节点的最详细信息,因为它尝试通过 IPMI 登录该节点。

潜在原因

集群节点在部署启动时可能处于 ON 状态。

解决方案

在通过 IPMI 开始安装前关闭 OpenShift Container Platform 集群节点:

$ ipmitool -I lanplus -U root -P <password> -H <out-of-band-ip> power off

8.6.3.2. 检查日志

在下载或访问 RHCOS 镜像时,首先请验证 install-config.yaml 配置文件中的 URL 是否正确。

内部 webserver 托管 RHCOS 镜像的示例

bootstrapOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-qemu.x86_64.qcow2.gz?sha256=9d999f55ff1d44f7ed7c106508e5deecd04dc3c06095d34d36bf1cd127837e0c
clusterOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-openstack.x86_64.qcow2.gz?sha256=a1bda656fa0892f7b936fdc6b6a6086bddaed5dafacedcd7a1e811abb78fe3b0

ipa-downloadercoreos-downloader 容器从 Webserver 或外部 quay.io registry 下载资源(由 install-config.yaml 配置文件中指定的为准)。验证以下两个容器是否正在运行,并根据需要检查其日志:

  • ipa-downloader
  • coreos-downloader

流程

  1. 登录到 bootstrap 虚拟机:

    $ ssh core@172.22.0.2
  2. 检查 bootstrap 虚拟机中的 ipa-downloadercoreos-downloader 容器的状态:

    [core@localhost ~]$ sudo podman logs -f ipa-downloader
    [core@localhost ~]$ sudo podman logs -f coreos-downloader

    如果 bootstrap 虚拟机无法访问镜像的 URL,使用 curl 命令验证虚拟机能否访问镜像。

  3. 要检查 bootkube 日志以了解在部署阶段是否启动了所有容器,请执行以下操作:

    [core@localhost ~]$ journalctl -xe
    [core@localhost ~]$ journalctl -b -f -u bootkube.service
  4. 验证所有 pod 都在运行,包括 dnsmasqmariadbhttpdironic

    [core@localhost ~]$ sudo podman ps
  5. 如果 pod 存在问题,请检查相关的容器日志。要检查 ironic-api 的日志,请执行以下操作:

    [core@localhost ~]$ sudo podman logs <ironic-api>

8.6.4. 集群节点不能 PXE 引导

当 OpenShift Container Platform 集群节点无法 PXE 引导时,在不能 PXE 引导的集群节点上执行以下检查。如果没有 provisioning 网络,则在安装 OpenShift Container Platform 集群时不适用此步骤。

流程

  1. 检查到 provisioning 网络的网络连接。
  2. 确保 provisioning 网络的 NIC 上启用了 PXE,并且其他所有 NIC 都禁用了 PXE。
  3. 验证 install-config.yaml 配置文件是否有正确的硬件配置集,以及连接到 provisioning 网络的 NIC 的引导 MAC 地址。例如:

    control plane 节点设置

    bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC
    hardwareProfile: default          #control plane node settings

    Worker 节点设置

    bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC
    hardwareProfile: unknown          #worker node settings

8.6.5. API 无法访问

当集群正在运行且客户端无法访问 API 时,可能是因为域名解析的问题影响对 API 的访问。

流程

  1. 主机名解析: 检查集群节点带有完全限定域名,而不只是 localhost.localdomain。例如:

    $ hostname

    如果没有设定主机名,请设置正确的主机名。例如:

    $ hostnamectl set-hostname <hostname>
  2. 错误的名称解析: 使用 dignslookup 检查每个节点在 DNS 服务器中是否可以被正确解析。例如:

    $ dig api.<cluster-name>.example.com
    ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> api.<cluster-name>.example.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37551
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ; COOKIE: 866929d2f8e8563582af23f05ec44203d313e50948d43f60 (good)
    ;; QUESTION SECTION:
    ;api.<cluster-name>.example.com. IN A
    
    ;; ANSWER SECTION:
    api.<cluster-name>.example.com. 10800 IN	A 10.19.13.86
    
    ;; AUTHORITY SECTION:
    <cluster-name>.example.com. 10800 IN NS	<cluster-name>.example.com.
    
    ;; ADDITIONAL SECTION:
    <cluster-name>.example.com. 10800 IN A	10.19.14.247
    
    ;; Query time: 0 msec
    ;; SERVER: 10.19.14.247#53(10.19.14.247)
    ;; WHEN: Tue May 19 20:30:59 UTC 2020
    ;; MSG SIZE  rcvd: 140

    示例中的输出显示 api.<cluster-name>.example.com VIP 的适当 IP 地址为 10.19.13.86。这个 IP 地址应该位于 baremetal 网络中。

8.6.6. 清理以前的安装

如果上一个部署失败,在尝试再次部署 OpenShift Container Platform 前从失败的尝试中删除工件。

流程

  1. 在安装 OpenShift Container Platform 集群前关闭所有裸机节点:

    $ ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off
  2. 删除以前部署中保留的旧的 bootstrap 资源:

    for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'});
    do
      sudo virsh destroy $i;
      sudo virsh undefine $i;
      sudo virsh vol-delete $i --pool $i;
      sudo virsh vol-delete $i.ign --pool $i;
      sudo virsh pool-destroy $i;
      sudo virsh pool-undefine $i;
    done
  3. clusterconfigs 目录中删除以下内容以防止 Terraform 失败:

    $ rm -rf ~/clusterconfigs/auth ~/clusterconfigs/terraform* ~/clusterconfigs/tls ~/clusterconfigs/metadata.json

8.6.7. 创建 registry 的问题

在创建断开连接的 registry 时,在尝试对 registry 进行镜像时,可能会遇到 "User Not Authorized" 错误。如果您没有在现有的 pull-secret.txt 文件中添加新身份验证,则可能会出现这个错误。

流程

  1. 检查以确保身份验证成功:

    $ /usr/local/bin/oc adm release mirror \
      -a pull-secret-update.json
      --from=$UPSTREAM_REPO \
      --to-release-image=$LOCAL_REG/$LOCAL_REPO:${VERSION} \
      --to=$LOCAL_REG/$LOCAL_REPO
    注意

    用于镜像安装镜像的变量输出示例:

    UPSTREAM_REPO=${RELEASE_IMAGE}
    LOCAL_REG=<registry_FQDN>:<registry_port>
    LOCAL_REPO='ocp4/openshift4'

    为 OpenShift 安装设置环境章节中的获取 OpenShift 安装程序步骤中,设置了 RELEASE_IMAGEVERSION 值。

  2. 镜像 registry 后,确认您可以在断开连接的环境中访问它:

    $ curl -k -u <user>:<password> https://registry.example.com:<registry-port>/v2/_catalog
    {"repositories":["<Repo-Name>"]}

8.6.8. 其它问题

8.6.8.1. 解决 runtime network not ready 错误

部署集群后您可能会收到以下错误:

`runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: Missing CNI default network`

Cluster Network Operator 负责部署网络组件以响应安装程序创建的特殊对象。它会在安装过程的早期阶段运行(在 Control Plane(master)节点启动后,bootstrap control plane 被停止前运行)。它可能会显示更细微的安装程序问题,比如启动 Control Plane(master)节点时延迟时间过长,或者 apiserver 通讯的问题。

流程

  1. 检查 openshift-network-operator 命名空间中的 pod:

    $ oc get all -n openshift-network-operator
    NAME                                    READY STATUS            RESTARTS   AGE
    pod/network-operator-69dfd7b577-bg89v   0/1   ContainerCreating 0          149m
  2. provisioner 节点上,确定存在网络配置:

    $ kubectl get network.config.openshift.io cluster -oyaml
    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      serviceNetwork:
      - 172.30.0.0/16
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      networkType: OpenShiftSDN

    如果不存在,代表安装程序没有创建它。要确定安装程序没有创建它的原因,请执行以下操作:

    $ openshift-install create manifests
  3. 检查 network-operator 是否正在运行:

    $ kubectl -n openshift-network-operator get pods
  4. 检索日志:

    $ kubectl -n openshift-network-operator logs -l "name=network-operator"

    在具有三个或更多 Control Plane(master)节点的高可用性集群上,Operator 将执行领导选举机制,所有其他 Operator 会休眠。如需了解更多详细信息,请参阅 故障排除

8.6.8.2. 集群节点没有通过 DHCP 获得正确的 IPv6 地址

如果集群节点没有通过 DHCP 获得正确的 IPv6 地址,请检查以下内容:

  1. 确定保留的 IPv6 地址不在 DHCP 范围之外。
  2. 在 DHCP 服务器的 IP 地址保留中,确保保留指定了正确的 DHCP 唯一识别符(DUID)。例如:

    # This is a dnsmasq dhcp reservation, 'id:00:03:00:01' is the client id and '18:db:f2:8c:d5:9f' is the MAC Address for the NIC
    id:00:03:00:01:18:db:f2:8c:d5:9f,openshift-master-1,[2620:52:0:1302::6]
  3. 确保路由声明(Route Announcement)正在正常工作。
  4. 确定 DHCP 服务器正在侦听提供 IP 地址范围所需的接口。

8.6.8.3. 集群节点没有通过 DHCP 获得正确的主机名

在 IPv6 部署过程中,集群节点必须通过 DHCP 获得其主机名。有时 NetworkManager 不会立即分配主机名。Control Plane(master)节点可能会报告错误,例如:

Failed Units: 2
  NetworkManager-wait-online.service
  nodeip-configuration.service

这个错误表示集群节点可能在没有从 DHCP 服务器收到主机名的情况下引导,这会导致 kubelet 使用 localhost.localdomain 主机名引导。要解决这个问题,强制节点更新主机名。

流程

  1. 检索 主机名:

    [core@master-X ~]$ hostname

    如果主机名是 localhost,请执行以下步骤。

    注意

    其中 X 是 control plane 节点(也称为 master 节点)号。

  2. 强制集群节点续订 DHCP 租期:

    [core@master-X ~]$ sudo nmcli con up "<bare-metal-nic>"

    <bare-metal-nic> 替换为与 baremetal 网络对应的有线连接。

  3. 再次检查 主机名:

    [core@master-X ~]$ hostname
  4. 如果主机名仍然是 localhost.localdomain,重启 NetworkManager:

    [core@master-X ~]$ sudo systemctl restart NetworkManager
  5. 如果主机名仍然是 localhost.localdomain,请等待几分钟并再次检查。如果主机名还是 localhost.localdomain,重复前面的步骤。
  6. 重启 nodeip-configuration 服务:

    [core@master-X ~]$ sudo systemctl restart nodeip-configuration.service

    此服务将使用正确的主机名引用来重新配置 kubelet 服务。

  7. 因为 kubelet 在上一步中有所改变,所以重新加载单元文件定义:

    [core@master-X ~]$ sudo systemctl daemon-reload
  8. 重启 kubelet 服务:

    [core@master-X ~]$ sudo systemctl restart kubelet.service
  9. 确保 kubelet 使用正确的主机名引导:

    [core@master-X ~]$ sudo journalctl -fu kubelet.service

如果集群节点在启动并运行集群后没有通过 DHCP 获得正确的主机名(例如在重启过程中),集群将会有一个待处理的 csr不要批准 csr,否则可能会出现其他问题。

处理 csr

  1. 在集群上获取 CSR:

    $ oc get csr
  2. 验证待处理的 csr 是否包含 Subject Name: localhost.localdomain:

    $ oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -text
  3. 删除包含 Subject Name: localhost.localdomain 的任何 csr:

    $ oc delete csr <wrong_csr>

8.6.8.4. 路由无法访问端点

在安装过程中,可能会遇到虚拟路由器冗余协议(VRRP)冲突。如果以前使用一个特定集群名称部署的集群中的个 OpenShift Container Platform 节点仍在运行,且这个节点不是使用相同集群名称部署的当前 OpenShift Container Platform 集群的一部分,则可能会出现冲突。例如,一个集群使用集群名称 openshift 部署,它部署了三个 Control Plane(master)节点和三个 worker 节点。之后,一个单独的安装会使用相同的集群名称 openshift,但这个重新部署只安装了三个 control plane(master)节点,以前部署的三个 worker 节点处于 ON 状态。这可能导致 Virtual Router Identifier(VRID)冲突和 VRRP 冲突。

  1. 获取路由:

    $ oc get route oauth-openshift
  2. 检查服务端点:

    $ oc get svc oauth-openshift
    NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    oauth-openshift   ClusterIP   172.30.19.162   <none>        443/TCP   59m
  3. 尝试从 Control Plane(master)节点访问该服务:

    [core@master0 ~]$ curl -k https://172.30.19.162
    {
      "kind": "Status",
      "apiVersion": "v1",
      "metadata": {
      },
      "status": "Failure",
      "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
      "reason": "Forbidden",
      "details": {
      },
      "code": 403
  4. 找到 provisioner 节点的 authentication-operator 错误:

    $ oc logs deployment/authentication-operator -n openshift-authentication-operator
    Event(v1.ObjectReference{Kind:"Deployment", Namespace:"openshift-authentication-operator", Name:"authentication-operator", UID:"225c5bd5-b368-439b-9155-5fd3c0459d98", APIVersion:"apps/v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'OperatorStatusChanged' Status for clusteroperator/authentication changed: Degraded message changed from "IngressStateEndpointsDegraded: All 2 endpoints for oauth-server are reporting"

解决方案

  1. 确保每个部署的集群名称都是唯一的,确保没有冲突。
  2. 关闭所有不是使用相同集群名称的集群部署的一部分的节点。否则,OpenShift Container Platform 集群的身份验证 pod 可能无法成功启动。

8.6.8.5. 在 Firstboot 过程中 Ignition 失败

在 Firstboot 过程中,Ignition 配置可能会失败。

流程

  1. 连接到 Ignition 配置失败的节点:

    Failed Units: 1
      machine-config-daemon-firstboot.service
  2. 重启 machine-config-daemon-firstboot 服务:

    [core@worker-X ~]$ sudo systemctl restart machine-config-daemon-firstboot.service

8.6.8.6. NTP 没有同步

OpenShift Container Platform 集群的部署需要集群节点间的 NTP 时钟已同步。如果没有同步时钟,当时间差大于 2 秒时,部署可能会因为时钟偏移而失败。

流程

  1. 检查集群节点的 AGE 的不同。例如:

    $ oc get nodes
    NAME                         STATUS   ROLES    AGE   VERSION
    master-0.cloud.example.com   Ready    master   145m   v1.16.2
    master-1.cloud.example.com   Ready    master   135m   v1.16.2
    master-2.cloud.example.com   Ready    master   145m   v1.16.2
    worker-2.cloud.example.com   Ready    worker   100m   v1.16.2
  2. 检查因为时钟偏移导致的时间延迟。例如:

    $ oc get bmh -n openshift-machine-api
    master-1   error registering master-1  ipmi://<out-of-band-ip>
    $ sudo timedatectl
                   Local time: Tue 2020-03-10 18:20:02 UTC
               Universal time: Tue 2020-03-10 18:20:02 UTC
                     RTC time: Tue 2020-03-10 18:36:53
                    Time zone: UTC (UTC, +0000)
    System clock synchronized: no
                  NTP service: active
              RTC in local TZ: no

处理现有集群中的时钟偏移

  1. 创建一个 Butane 配置文件,其中包含要传送到节点的 chrony.conf 文件的内容。在以下示例中,创建 99-master-chrony.bu,将该文件添加到 control plane 节点。您可以修改 worker 节点的文件,或为 worker 角色重复此步骤。

    注意

    有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    variant: openshift
    version: 4.8.0
    metadata:
      name: 99-master-chrony
      labels:
        machineconfiguration.openshift.io/role: master
    storage:
      files:
      - path: /etc/chrony.conf
        mode: 0644
        overwrite: true
        contents:
          inline: |
            server <NTP-server> iburst 1
            stratumweight 0
            driftfile /var/lib/chrony/drift
            rtcsync
            makestep 10 3
            bindcmdaddress 127.0.0.1
            bindcmdaddress ::1
            keyfile /etc/chrony.keys
            commandkey 1
            generatecommandkey
            noclientlog
            logchange 0.5
            logdir /var/log/chrony
    1
    <NTP-server> 替换为 NTP 服务器的 IP 地址。
  2. 使用 Butane 生成 MachineConfig 对象文件 99-master-chrony.yaml,包含要发送到节点的配置:

    $ butane 99-master-chrony.bu -o 99-master-chrony.yaml
  3. 应用 MachineConfig 对象文件:

    $ oc apply -f 99-master-chrony.yaml
  4. 确定 System clock synchronized 的值为 yes

    $ sudo timedatectl
                   Local time: Tue 2020-03-10 19:10:02 UTC
               Universal time: Tue 2020-03-10 19:10:02 UTC
                     RTC time: Tue 2020-03-10 19:36:53
                    Time zone: UTC (UTC, +0000)
    System clock synchronized: yes
                  NTP service: active
              RTC in local TZ: no

    要在部署前设置时钟同步,请生成清单文件并将该文件添加到 openshift 目录中。例如:

    $ cp chrony-masters.yaml ~/clusterconfigs/openshift/99_masters-chrony-configuration.yaml

    然后继续创建集群。

8.6.9. 检查安装

安装后,请确保安装程序成功部署节点和 Pod。

流程

  1. 当正确安装 OpenShift Container Platform 集群节点时,在 STATUS 栏中会显示 Ready

    $ oc get nodes
    NAME                   STATUS   ROLES           AGE  VERSION
    master-0.example.com   Ready    master,worker   4h   v1.16.2
    master-1.example.com   Ready    master,worker   4h   v1.16.2
    master-2.example.com   Ready    master,worker   4h   v1.16.2
  2. 确认安装程序已成功部署所有 Pod。以下命令的输出中会排除仍在运行或已完成的 pod。

    $ oc get pods --all-namespaces | grep -iv running | grep -iv complete