5.3. CRI-O 容器运行时问题故障排除

5.3.1. 关于 CRI-O 容器运行时引擎

CRI-O 是 Kubernetes 的原生容器运行时实现,可与操作系统紧密集成来提供高效和优化的 Kubernetes 体验。CRI-O,提供用于运行、停止和重启容器的工具。

CRI-O 容器运行时引擎由在每个 OpenShift Container Platform 集群节点上使用 systemd 服务进行管理。当出现容器运行时问题时,验证每个节点上的 crio systemd 服务的状态。从清单容器运行时问题的节点收集 CRI-O journald 单元日志。

5.3.2. 验证 CRI-O 运行时引擎状态

您可以在每个集群节点上验证 CRI-O 容器运行时引擎状态。

先决条件

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

流程

  1. 通过在节点上查询 debug pod 中的 crio systemd 服务来查看 CRI-O 状态。

    1. 为节点启动 debug pod:

      $ oc debug node/my-node
    2. /host 设为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host,您可以运行主机可执行路径中包含的二进制文件:

      # chroot /host
      注意

      运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

    3. 检查 crio systemd 服务在该节点上是否活跃:

      # systemctl is-active crio
    4. 输出更详细的 kubelet.service 状态概述:

      # systemctl status crio

5.3.3. 收集 CRI-O journald 单元日志

如果遇到 CRI-O 问题,您可以从节点获取 CRI-O journald 单元日志。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI(oc)。
  • 您有 control plane 或 master 机器的完全限定域名。

流程

  1. 收集 CRI-O journald 单元日志。以下示例从集群中的所有 master 节点收集日志:

    $ oc adm node-logs --role=master -u crio
  2. 从特定节点收集 CRI-O journald 单元日志:

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

    $ ssh core@<node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.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> 来访问节点。