第 5 章 故障排除

5.1. 安装故障排除

5.1.1. 确定安装问题在哪里发生

当对 OpenShift Container Platform 安装问题进行故障排除时,可以监控安装日志来确定在哪个阶段出现问题。然后,检索与该阶段相关的诊断数据。

OpenShift Container Platform 安装过程包括以下阶段:

  1. 创建 Ignition 配置文件。
  2. bootstrap 机器启动并开始托管 master 机器启动所需的远程资源。
  3. master 机器从 bootstrap 机器获取远程资源并完成启动。
  4. master 机器使用 bootstrap 机器来组成 etcd 集群。
  5. bootstrap 机器使用新的 etcd 集群启动临时 Kubernetes control plane。
  6. 临时 control plane 将生产环境的 control plane 调度到 master 机器。
  7. 临时 control plane 关机,并将控制权交给生产环境 control plane。
  8. bootstrap 机器将 OpenShift Container Platform 组件添加到生产环境 control plane。
  9. 安装程序关闭 bootstrap 机器。
  10. control plane 设置 worker 节点。
  11. control plane 以一组 Operator 的形式安装其他服务。
  12. 集群下载并配置日常运作所需的其余组件,包括在受支持的环境中创建 worker 机器。

5.1.2. 用户置备的基础架构安装注意事项

默认安装方法使用安装程序置备的基础架构。对于安装程序置备的基础架构的集群,OpenShift Container Platform 可以管理集群的所有方面,包括操作系统本身。若有可能,可以使用此功能来避免置备和维护集群基础架构。

您也可以在自己提供的基础架构上安装 OpenShift Container Platform 4.7。如果您使用这个安装方法,请完全遵循用户置备的基础架构安装文档中的内容。另外,在安装前请考虑以下事项:

  • 查看 Red Hat Enterprise Linux(RHEL)生态系统中的内容来决定您所使用的服务器硬件或虚拟环境可以获得的 Red Hat Enterprise Linux CoreOS(RHCOS)对其支持的级别。
  • 很多虚拟化和云环境需要在客户端操作系统中安装代理。确保将这些代理作为通过守护进程集部署的容器化工作负载安装。
  • 如果要启用动态存储、按需服务路由、节点主机名到 Kubernetes 主机名解析以及集群自动扩展等功能,请安装云供应商集成。

    注意

    不可能在混合有不同云供应商,或跨多个物理或虚拟平台的 OpenShift Container Platform 环境中启用云供应商集成。节点生命周期控制器不允许将来自现有供应商外部的节点添加到集群中,且无法指定多个云供应商集成。

  • 如果要使用机器集或自动扩展来自动置备 OpenShift Container Platform 集群节点,则需要针对于供应商的 Machine API 实现。
  • 检查您所选云供应商是否提供了将 Ignition 配置文件注入主机的方法作为其初始部署的一部分。如果不这样做,则需要使用 HTTP 服务器托管 Ignition 配置文件。解决 Ignition 配置文件问题的步骤会因部署了这两种方法的不同而有所不同。
  • 如果要利用可选的框架组件,如嵌入式容器 registry、ElasticSearch 或 Prometheus,则需要手动置备存储。除非明确进行了配置,用户置备的基础架构安装中不定义默认存储类。
  • 在高可用性 OpenShift Container Platform 环境中,需要一个负载均衡器来在所有 master 节点中分发 API 请求。您可以使用任何满足 OpenShift Container Platform DNS 路由和端口要求的基于 TCP 的负载平衡解决方案。

5.1.3. 在 OpenShift Container Platform 安装前检查负载均衡器配置

在开始 OpenShift Container Platform 安装前,请检查您的负载均衡器配置。

先决条件

  • 已根据选择配置了外部负载均衡器,准备 OpenShift Container Platform 安装。以下示例基于使用 HAProxy 为集群提供负载均衡服务的 Red Hat Enterprise Linux(RHEL)主机。
  • 为准备 OpenShift Container Platform 安装已配置了 DNS 准备。
  • 有到负载均衡器的 SSH 访问权限。

流程

  1. 检查 haproxy systemd 服务是否活跃:

    $ ssh <user_name>@<load_balancer> systemctl status haproxy
  2. 验证负载均衡器是否在监听所需端口。以下示例引用端口 80443644322623

    • 对于在 Red Hat Enterprise Linux(RHEL)6 上运行的 HAProxy 实例,请使用 netstat 命令验证端口状态:

      $ ssh <user_name>@<load_balancer> netstat -nltupe | grep -E ':80|:443|:6443|:22623'
    • 对于在 Red Hat Enterprise Linux(RHEL)7 或 8 上运行的 HAProxy 实例,请使用 ss 命令验证端口状态:

      $ ssh <user_name>@<load_balancer> ss -nltupe | grep -E ':80|:443|:6443|:22623'
      注意

      红帽建议在 Red Hat Enterprise Linux(RHEL)7 或更高版本中使用 ss 命令而不是 netstatSS 由 iproute 软件包提供。有关 ss 命令的详情请参考 Red Hat Enterprise Linux(RHEL)7 性能调节指南

  3. 检查通配符 DNS 记录是否被解析为负载均衡器:

    $ dig <wildcard_fqdn> @<dns_server>

5.1.4. 指定 OpenShift Container Platform 安装程序日志级别

默认情况下,OpenShift Container Platform 安装程序日志级别设置为 info。如果在诊断失败的 OpenShift Container Platform 安装时需要更详细的日志记录,您可以在重新开始安装时将 openshift-install 日志级别提高为 debug

先决条件

  • 有访问安装主机的访问权限。

流程

  • 在启动安装时将安装日志级别设置为 debug:

    $ ./openshift-install --dir=<installation_directory> wait-for bootstrap-complete --log-level=debug  1
    1
    可能的日志级别包括 infowarn 、errordebug

5.1.5. openshift-install 命令问题故障排除

如果您在运行 openshift-install 命令时遇到问题,请检查以下内容:

  • 安装过程在 Ignition 配置文件创建后 24 小时内启动。运行以下命令时创建 Ignition 文件:

    $ ./openshift-install create ignition-configs --dir=./install_dir
  • install-config.yaml 文件与安装程序位于同一个目录中。如果使用 ./openshift-install --dir 选项声明了其他不同的安装路径,请验证 install-config.yaml 文件是否存在于该目录中。

5.1.6. 监控安装进度

您可以在 OpenShift Container Platform 安装过程中监控高级别安装、bootstrap 和 control plane 日志。这提高了安装过程的可视性,并有助于识别安装失败的阶段。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您需要有到主机的 SSH 访问权限。
  • 您有 bootstrap 和 master 节点的完全限定域名。

    注意

    初始 kubeadmin 密码可在安装主机的 <install_directory>/auth/kubeadmin-password 中找到。

流程

  1. 在安装过程中监控安装日志:

    $ tail -f ~/<installation_directory>/.openshift_install.log
  2. 在 bootstrap 节点引导后,监控 bootkube.service journald 单元日志。这可让您了解第一个 control plane 的 bootstrap。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名:

    $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service
    注意

    bootstrap 节点上的 bootkube.service 日志会输出 etcd connection refused 错误,这表示 bootstrap 服务器无法在 master 节点上连接到 etcd。在各个 master 节点上启动 etcd 且节点已加入集群后,这个错误应该会停止。

  3. 引导后,监控 master 节点上的 kubelet.service journald 单元日志。这可让您了解 master 节点代理活动。

    1. 使用 oc 监控日志:

      $ oc adm node-logs --role=master -u kubelet
    2. 如果 API 无法正常工作,使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service
  4. 引导后,监控 master 节点上的 crio.service journald 单元日志。这可让您了解 master 节点 CRI-O 容器运行时的活动。

    1. 使用 oc 监控日志:

      $ oc adm node-logs --role=master -u crio
    2. 如果 API 无法正常工作,使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值:

      $ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service

5.1.7. 收集 bootstrap 节点诊断数据

当遇到与 bootstrap 相关的问题,可以从 bootstrap 节点收集 bootkube.service journald 单元日志和容器日志。

先决条件

  • 具有到 bootstrap 节点的 SSH 访问权限。
  • 具有 bootstrap 节点的完全限定域名。
  • 如果使用 HTTP 服务器托管 Ignition 配置文件,则必须具有 HTTP 服务器的完全限定域名和端口号。还必须有到 HTTP 主机的 SSH 访问权限。

流程

  1. 如果可以访问 bootstrap 节点的控制台,请监控控制台,直到节点可以提供登录提示。
  2. 验证 Ignition 文件配置。

    • 如果您使用 HTTP 服务器托管 Ignition 配置文件。

      1. 验证 bootstrap 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名:

        $ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  1
        1
        -I 选项只返回标头。如果指定的 URL 中有 Ignition 文件,该命令会返回 200 OK 状态。如果没有,该命令会返回 404 file not found
      2. 要验证 bootstrap 节点是否收到 Ignition 文件,请查询服务主机上的 HTTP 服务器日志。例如,如果您使用 Apache web 服务器提供 Ignition 文件,请输入以下命令:

        $ grep -is 'bootstrap.ign' /var/log/httpd/access_log

        如果收到 bootstrap Ignition 文件,相关的 HTTP GET 日志消息将包含 200 OK 成功状态,这表示请求成功。

      3. 如果未收到 Ignition 文件,请检查 Ignition 文件是否存在,是否在服务主机上具有适当的文件和 Web 服务器权限。
    • 如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。

      1. 查看 bootstrap 节点的控制台,以确定机制是否正确注入 bootstrap 节点 Ignition 文件。
  3. 验证 bootstrap 节点分配的存储设备是否可用。
  4. 验证 bootstrap 节点是否已从 DHCP 服务器分配了一个 IP 地址。
  5. 从 bootstrap 节点收集 bootkube.service journald 单元日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名:

    $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service
    注意

    bootstrap 节点上的 bootkube.service 日志会输出 etcd connection refused 错误,这表示 bootstrap 服务器无法在 master 节点上连接到 etcd。在各个 master 节点上启动 etcd 且节点已加入集群后,这个错误应该会停止。

  6. 从 bootstrap 节点容器收集日志。

    1. 使用 bootstrap 节点上的 podman 来收集日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名:

      $ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'
  7. 如果 bootstrap 过程失败,请验证以下内容。

    • 您可从安装主机解析 api.<cluster_name>.<base_domain>
    • 负载均衡器代理端口 6443 连接到 bootstrap 和 master 节点。确保代理配置满足 OpenShift Container Platform 安装要求。

5.1.8. 解决 master 节点安装问题

如果您遇到 master 节点安装问题,请确定 master 节点、OpenShift Container Platform 软件定义的网络(SDN)和网络 Operator 的状态。收集 kubelet.servicecrio.service journald 单元日志和 master 节点容器日志,以检查 master 节点代理、CRI-O 容器运行时和 pod 的情况。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您需要有到主机的 SSH 访问权限。
  • 您有 bootstrap 和 master 节点的完全限定域名。
  • 如果使用 HTTP 服务器托管 Ignition 配置文件,则必须具有 HTTP 服务器的完全限定域名和端口号。还必须有到 HTTP 主机的 SSH 访问权限。

    注意

    初始 kubeadmin 密码可在安装主机的 <install_directory>/auth/kubeadmin-password 中找到。

流程

  1. 如果可以访问 master 节点的控制台,请监控控制台,直到节点可以提供登录提示。在安装过程中,Ignition 日志消息输出到控制台。
  2. 验证 Ignition 文件配置。

    • 如果您使用 HTTP 服务器托管 Ignition 配置文件。

      1. 验证 master 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名:

        $ curl -I http://<http_server_fqdn>:<port>/master.ign  1
        1
        -I 选项只返回标头。如果指定的 URL 中有 Ignition 文件,该命令会返回 200 OK 状态。如果没有,该命令会返回 404 file not found
      2. 要验证 master 节点是否收到 Ignition 文件,请查询服务主机上的 HTTP 服务器日志。例如,如果您使用 Apache web 服务器提供 Ignition 文件:

        $ grep -is 'master.ign' /var/log/httpd/access_log

        如果收到 master Ignition 文件,相关的 HTTP GET 日志消息将包含 200 OK 成功状态,表示请求成功。

      3. 如果未收到 Ignition 文件,请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。
    • 如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。

      1. 查看 master 节点的控制台,以确定机制是否正确注入 master 节点 Ignition 文件。
  3. 检查 master 节点分配的存储设备是否可用。
  4. 验证是否已从 DHCP 服务器为 master 节点分配了一个 IP 地址。
  5. 确定 master 节点状态。

    1. 查询 master 节点状态:

      $ oc get nodes
    2. 如果一个 master 节点没有处于 Ready 状态,检索节点的描述信息:

      $ oc describe node <master_node>
      注意

      如果某个安装问题导致 OpenShift Container Platform API 无法运行,或者 kubelet 还没有在每个节点上运行,则无法运行 oc 命令:

  6. 确定 OpenShift Container Platform SDN 状态。

    1. openshift-sdn 命名空间内查看 sdn-controllersdnovs 守护进程集的状态:

      $ oc get daemonsets -n openshift-sdn
    2. 如果这些资源列为 Not found,查看 openshift-sdn 命名空间中的 pod:

      $ oc get pods -n openshift-sdn
    3. 检查 openshift-sdn 命名空间中与失败的 OpenShift Container Platform SDN pod 相关的日志:

      $ oc logs <sdn_pod> -n openshift-sdn
  7. 确定集群网络配置状态。

    1. 查看集群的网络配置是否存在:

      $ oc get network.config.openshift.io cluster -o yaml
    2. 如果安装程序无法创建网络配置,请再次生成 Kubernetes 清单并查看消息输出:

      $ ./openshift-install create manifests
    3. 查看 openshift-network-operator 命名空间中的 pod 状态,以确定 Cluster Network Operator(CNO)是否在运行:

      $ oc get pods -n openshift-network-operator
    4. openshift-network-operator 命名空间中收集网络 Operator pod 日志:

      $ oc logs pod/<network_operator_pod_name> -n openshift-network-operator
  8. 引导后,监控 master 节点上的 kubelet.service journald 单元日志。这可让您了解 master 节点代理活动。

    1. 使用 oc 检索日志:

      $ oc adm node-logs --role=master -u kubelet
    2. 如果 API 无法正常工作,使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service
      注意

      运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

  9. 引导后,在 master 节点上获取 crio.service journald 单元日志。这可让您了解 master 节点 CRI-O 容器运行时的活动。

    1. 使用 oc 检索日志:

      $ oc adm node-logs --role=master -u crio
    2. 如果 API 无法正常工作,使用 SSH 来查看日志:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service
  10. 从 master 节点上的 /var/log/ 下的特定子目录收集日志。

    1. 获取 /var/log/ 子目录中所含的日志列表。以下示例列出所有 master 节点上的 /var/log/openshift-apiserver/ 中的文件:

      $ oc adm node-logs --role=master --path=openshift-apiserver
    2. 检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 master 节点的 /var/log/openshift-apiserver/audit.log 内容:

      $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log
    3. 如果 API 无法正常工作,请使用 SSH 来查看每个节点上的日志。以下示例是 /var/log/openshift-apiserver/audit.log 的尾部的内容:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log
  11. 使用 SSH 查看 master 节点容器日志。

    1. 列出容器:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps -a
    2. 使用 crictl 检索容器日志:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
  12. 如果您遇到 master 节点配置问题,检查 MCO、MCO 端点和 DNS 记录是否正常运行。Machine Config Operator(MCO)在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。

    1. 测试 MCO 端点是否可用。将 <cluster_name> 替换为适当的值:

      $ curl https://api-int.<cluster_name>:22623/config/master
    2. 如果端点不响应,请验证负载均衡器配置。确保端点配置为在端口 22623 上运行。
    3. 验证 MCO 端点的 DNS 记录是否已配置并解析到负载均衡器。

      1. 对定义的 MCO 端点名称运行 DNS 查找:

        $ dig api-int.<cluster_name> @<dns_server>
      2. 在负载均衡器上对分配的 MCO IP 地址进行逆向查询:

        $ dig -x <load_balancer_mco_ip_address> @<dns_server>
    4. 验证 MCO 是否直接从 bootstrap 节点运行。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名:

      $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master
    5. 系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息:

      $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking
    6. 检查证书的有效性:

      $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

5.1.9. 解决 etcd 安装问题

如果在安装过程中遇到 etcd 问题,您可以检查 etcd pod 状态并收集 etcd pod 日志。您还可以验证 etcd DNS 记录并检查 master 节点上的 DNS 可用性。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您需要有到主机的 SSH 访问权限。
  • 具有 master 节点的完全限定域名。

流程

  1. 检查 etcd pod 的状态。

    1. 查看 openshift-etcd 命名空间中的 pod 状态:

      $ oc get pods -n openshift-etcd
    2. 查看 openshift-etcd-operator 命名空间中的 pod 状态:

      $ oc get pods -n openshift-etcd-operator
  2. 如果以上命令中列出的任何 pod 没有显示 RunningCompleted 状态,请为 pod 收集诊断信息。

    1. 检查 pod 的事件:

      $ oc describe pod/<pod_name> -n <namespace>
    2. 检查 pod 的日志:

      $ oc logs pod/<pod_name> -n <namespace>
    3. 如果 pod 有多个容器,以上命令会创建一个错误并在错误消息中提供容器名称。检查每个容器的日志:

      $ oc logs pod/<pod_name> -c <container_name> -n <namespace>
  3. 如果 API 无法正常工作,请使用 SSH 来查看每个 master 节点上的 etcd pod 和容器日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值。

    1. 列出每个 master 节点上的 etcd pod:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods --name=etcd-
    2. 对于没有显示 Ready 状态的 pod,详细检查 pod 状态。将 <pod_id> 替换为上一命令输出中列出的 pod ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <pod_id>
    3. 列出与 pod 相关的容器:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps | grep '<pod_id>'
    4. 对于没有显示 Ready 状态的容器,请详细检查容器状态。将 <container_id> 替换为上一命令输出中列出的容器 ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
    5. 检查任何未显示 Ready 状态的容器的日志。将 <container_id> 替换为上一命令输出中列出的容器 ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
      注意

      运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

  4. 验证 master 节点的主和从属 DNS 服务器的连接。

5.1.10. 检查 master 节点 kubelet 和 API 服务器的问题

要在安装过程中调查 master 节点 kubelet 和 API 服务器问题,请检查 DNS、DHCP 和负载均衡器是否正常工作。另外,请确认证书没有过期。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您需要有到主机的 SSH 访问权限。
  • 具有 master 节点的完全限定域名。

流程

  1. 验证 API 服务器的 DNS 记录是否将 master 节点上的 kubelet 定向到 https://api-int.<cluster_name>.<base_domain>:6443。确保记录引用负载均衡器。
  2. 确保负载均衡器的端口 6443 定义引用每个 master 节点。
  3. 检查 DHCP 是否提供了唯一的 master 节点主机名。
  4. 检查每个 master 节点上的 kubelet.service journald 单元日志。

    1. 使用 oc 检索日志:

      $ oc adm node-logs --role=master -u kubelet
    2. 如果 API 无法正常工作,使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service
      注意

      运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

  5. 检查 master 节点 kubelet 日志中的证书过期信息。

    1. 使用 oc 检索日志:

      $ oc adm node-logs --role=master -u kubelet | grep -is 'x509: certificate has expired'
    2. 如果 API 无法正常工作,使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service  | grep -is 'x509: certificate has expired'

5.1.11. 调查 worker 节点安装问题

如果遇到 worker 节点安装问题,可以查看 worker 节点的状态。收集 kubelet.servicecrio.service journald 单元日志和 worker 节点容器日志,以检查 worker 节点代理、CRI-O 容器运行时和 pod 的情况。另外,还可以检查 Ignition 文件和 Machine API Operator 是否正常工作。如果 worker 节点安装后配置失败,检查 Machine Config Operator(MCO)和 DNS 是否正常工作。您还可以验证 bootstrap、master 和 worker 节点之间的系统时钟是否同步,并验证证书。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您需要有到主机的 SSH 访问权限。
  • 您有 bootstrap 和 worker 节点的完全限定域名。
  • 如果使用 HTTP 服务器托管 Ignition 配置文件,则必须具有 HTTP 服务器的完全限定域名和端口号。还必须有到 HTTP 主机的 SSH 访问权限。

    注意

    初始 kubeadmin 密码可在安装主机的 <install_directory>/auth/kubeadmin-password 中找到。

流程

  1. 如果可以访问 worker 节点的控制台,请监控控制台,直到节点可以提供登录提示。在安装过程中,Ignition 日志消息输出到控制台。
  2. 验证 Ignition 文件配置。

    • 如果您使用 HTTP 服务器托管 Ignition 配置文件。

      1. 验证 worker 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名:

        $ curl -I http://<http_server_fqdn>:<port>/worker.ign  1
        1
        -I 选项只返回标头。如果指定的 URL 中有 Ignition 文件,该命令会返回 200 OK 状态。如果没有,该命令会返回 404 file not found
      2. 要验证 worker 节点是否收到 Ignition 文件,请查询 HTTP 主机上的 HTTP 服务器日志。例如,如果您使用 Apache web 服务器提供 Ignition 文件:

        $ grep -is 'worker.ign' /var/log/httpd/access_log

        如果收到 worker Ignition 文件,相关的 HTTP GET 日志消息将包含 200 OK 成功状态,表示请求成功。

      3. 如果未收到 Ignition 文件,请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。
    • 如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。

      1. 查看 worker 节点的控制台,以确定机制是否正确注入 worker 节点 Ignition 文件。
  3. 检查 worker 节点分配的存储设备是否可用。
  4. 验证 worker 节点是否已从 DHCP 服务器分配了一个 IP 地址。
  5. 确定 worker 节点状态。

    1. 查询节点状态:

      $ oc get nodes
    2. 获取没有显示 Ready 状态的 worker 节点的详细节点描述:

      $ oc describe node <worker_node>
      注意

      如果某个安装问题导致 OpenShift Container Platform API 无法运行,或者 kubelet 还没有在每个节点上运行,则无法运行 oc 命令。

  6. 与 master 节点不同, worker 节点使用 Machine API Operator 进行部署和扩展。检查 Machine API Operator 的状态。

    1. 查看 Machine API Operator pod 状态:

      $ oc get pods -n openshift-machine-api
    2. 如果 Machine API Operator pod 没有处于 Ready 状态,请详细列出 pod 的事件:

      $ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api
    3. 检查 machine-api-operator 容器日志。容器在 machine-api-operator pod 中运行:

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator
    4. 同时检查 kube-rbac-proxy 容器日志。容器也会在 machine-api-operator pod 中运行:

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy
  7. 引导后,监控 worker 节点上的 kubelet.service journald 单元日志。这可让您了解 worker 节点代理活动。

    1. 使用 oc 检索日志:

      $ oc adm node-logs --role=worker -u kubelet
    2. 如果 API 无法正常工作,使用 SSH 来查看日志。将 <worker-node>.<cluster_name>.<base_domain> 替换为适当的值:

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service
      注意

      运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

  8. 引导后,在 worker 节点上获取 crio.service journald 单元日志。这可让您了解 worker 节点 CRI-O 容器运行时的活动。

    1. 使用 oc 检索日志:

      $ oc adm node-logs --role=worker -u crio
    2. 如果 API 无法正常工作,使用 SSH 来查看日志:

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service
  9. 从 worker 节点上的 /var/log/ 下的特定子目录收集日志。

    1. 获取 /var/log/ 子目录中所含的日志列表。以下示例列出所有 worker 节点上 /var/log/sssd/ 中的文件:

      $ oc adm node-logs --role=worker --path=sssd
    2. 检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 worker 节点的 /var/log/sssd/audit.log 内容:

      $ oc adm node-logs --role=worker --path=sssd/sssd.log
    3. 如果 API 无法正常工作,请使用 SSH 来查看每个节点上的日志。以下示例显示 /var/log/sssd/sssd.log 的尾部信息:

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log
  10. 使用 SSH 查看 worker 节点容器日志。

    1. 列出容器:

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl ps -a
    2. 使用 crictl 检索容器日志:

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
  11. 如果您遇到 worker 节点配置问题,检查 MCO、MCO 端点和 DNS 记录是否正常运行。Machine Config Operator(MCO)在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。

    1. 测试 MCO 端点是否可用。将 <cluster_name> 替换为适当的值:

      $ curl https://api-int.<cluster_name>:22623/config/worker
    2. 如果端点不响应,请验证负载均衡器配置。确保端点配置为在端口 22623 上运行。
    3. 验证 MCO 端点的 DNS 记录是否已配置并解析到负载均衡器。

      1. 对定义的 MCO 端点名称运行 DNS 查找:

        $ dig api-int.<cluster_name> @<dns_server>
      2. 在负载均衡器上对分配的 MCO IP 地址进行逆向查询:

        $ dig -x <load_balancer_mco_ip_address> @<dns_server>
    4. 验证 MCO 是否直接从 bootstrap 节点运行。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名:

      $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker
    5. 系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息:

      $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking
    6. 检查证书的有效性:

      $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

5.1.12. 安装后查询 Operator 状态

您可以在安装结束时检查 Operator 状态。检索不可用的 Operator 的诊断数据。检查所有列为 Pending 或具有错误状态的 Operator pod 的日志。验证有问题的 pod 所使用的基础镜像。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 检查安装结束时,是否所有集群 Operator 都可用。

    $ oc get clusteroperators
  2. 验证所有所需的证书签名请求(CSR)是否已批准。有些节点可能无法变为 Ready 状态,且有些集群 Operator 可能无法使用(如果待处理的 CSR)。

    1. 检查 CSR 的状态,并确保添加到集群中的每台机器都有 PendingApproved 状态的客户端和服务器请求:

      $ oc get csr

      输出示例

      NAME        AGE     REQUESTOR                                                                   CONDITION
      csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
      csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
      csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
      csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
      ...

      1
      客户端请求 CSR。
      2
      服务器请求 CSR。

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

    2. 如果 CSR 没有获得批准,请在所添加机器的所有待处理 CSR 都处于 Pending 状态后,为您的集群机器批准这些 CSR:

      注意

      由于 CSR 会自动轮转,因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准,证书将会轮转,每个节点将会存在多个证书。您必须批准所有这些证书。批准初始 CSR 后,集群的 kube-controller-manager 会自动批准后续的节点客户端 CSR。

      注意

      对于在未启用机器 API 的平台中运行的集群,如裸机和其他用户置备的基础架构,必须采用一种方法自动批准 kubelet 提供证书请求(CSR)。如果没有批准请求,则 oc execoc rshoc logs 命令将无法成功,因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。这个方法必须监视新的 CSR,确认 CSR 由 system:nodesystem: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 oc adm certificate approve
  3. 查看 Operator 事件:

    $ oc describe clusteroperator <operator_name>
  4. 查看 Operator 命名空间中的 Operator pod 状态:

    $ oc get pods -n <operator_namespace>
  5. 获取没有处于 Running 状态的 pod 的详细描述:

    $ oc describe pod/<operator_pod_name> -n <operator_namespace>
  6. 检查 pod 日志:

    $ oc logs pod/<operator_pod_name> -n <operator_namespace>
  7. 遇到与 pod 基础镜像相关的问题时,请查看基础镜像状态。

    1. 获取有问题的 pod 使用的基础镜像的详情:

      $ oc get pod -o "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}" <operator_pod_name> -n <operator_namespace>
    2. 列出基础镜像发行信息:

      $ oc adm release info <image_path>:<tag> --commits

5.1.13. 从失败安装中收集日志

如果为安装程序提供了 SSH 密钥,则可以收集与失败安装相关的数据。

注意

用于收集失败安装日志的命令与从正在运行的集群收集日志时所用的命令不同。如果需要从正在运行的集群收集日志,请使用 oc adm must-gather 命令。

先决条件

  • OpenShift Container Platform 安装在 bootstrap 过程完成前失败。bootstrap 节点正在运行,并可通过 SSH 访问。
  • ssh-agent 进程在您的计算机上处于活跃状态,并且为 ssh-agent 进程和安装程序提供了相同的 SSH 密钥。
  • 如果尝试在您置备的基础架构中安装集群,则一定需要有 control plane 或 master 节点的完全限定域名。

流程

  1. 生成从 bootstrap 和 control plane 机器获取安装日志的命令:

    • 如果您使用安装程序置备的基础架构,请切换到包含安装程序的目录,并运行以下命令:

      $ ./openshift-install gather bootstrap --dir=<installation_directory> 1
      1
      installation_directory 是您在运行 ./openshift-install create cluster 时指定的目录。这个目录包括了安装程序所创建的 OpenShift Container Platform 定义文件。

      对于安装程序置备的基础架构,安装程序会保存有关集群的信息,因此您不用指定主机名或 IP 地址。

    • 如果您使用您置备的基础架构,切换到包含安装程序的目录,并运行以下命令:

      $ ./openshift-install gather bootstrap --dir=<installation_directory> \ 1
          --bootstrap <bootstrap_address> \ 2
          --master <master_1_address> \ 3
          --master <master_2_address> \ 4
          --master <master_3_address>" 5
      1
      对于 installation_directory,请指定在运行 ./openshift-install create cluster 时指定的同一目录。这个目录包括了安装程序所创建的 OpenShift Container Platform 定义文件。
      2
      <bootstrap_address> 是集群 bootstrap 机器的完全限定域名或 IP 地址。
      3 4 5
      <master_address> 是集群中 control plane 或 master 机器的完全限定域名或 IP 地址。
      注意

      默认集群包含三个 control plane 机器。如所示,列出所有 control plane 机器,无论集群使用了多少个。

    输出示例

    INFO Pulling debug logs from the bootstrap machine
    INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

    如果需要创建关安装失败的红帽支持问题单,请在问题单中附上压缩日志。

5.1.14. 其他资源

  • 如需了解更多与 OpenShift Container Platform 安装类型和流程相关的详细信息,请参阅安装过程。