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

流程

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.17 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

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

      # systemctl is-active crio

   4. 输出更详细的 crio.service 状态概述：

      # systemctl status crio.service

流程

1. 收集 CRI-O journald 单元日志。以下示例从所有 control plane 节点（在集群中）收集日志：

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

流程

1. 在节点上使用 cordon。这是为了避免在节点处于 Ready 状态时调度任何工作负载。当您的 Status 部分中存在 SchedulingDisabled 时代表调度被禁用：

   $ oc adm cordon <node_name>

2. 以 cluster-admin 用户身份排空节点：

   $ oc adm drain <node_name> --ignore-daemonsets --delete-emptydir-data

   注意

   pod 或 pod 模板的 terminationGracePeriodSeconds 属性控制安全终止的时间。此属性的默认值为 30 秒，但可以根据需要针对每个应用程序进行自定义。如果设置的值大于 90 秒，则 pod 可能会标记为 SIGKILL，且无法成功终止。

3. 当节点返回时，通过 SSH 或控制台连接节点。然后连接到 root 用户：

   $ ssh core@node1.example.com
   $ sudo -i

4. 手动停止 kubelet：

   # systemctl stop kubelet

5. 停止容器和 pod：

   1. 使用以下命令停止 HostNetwork 中没有的 pod。必须首先删除它们，因为它们依赖于 HostNetwork 中的网络插件 pod。

      .. for pod in $(crictl pods -q); do if [[ "$(crictl inspectp $pod | jq -r .status.linux.namespaces.options.network)" != "NODE" ]]; then crictl rmp -f $pod; fi; done

   2. 停止所有其他 pod：

      # crictl rmp -fa

6. 手动停止 crio 服务：

   # systemctl stop crio

7. 运行这些命令后，您可以完全擦除临时存储：

   # crio wipe -f

8. 启动 crio 和 kubelet 服务：

   # systemctl start crio
   # systemctl start kubelet

9. 如果 crio 和 kubelet 服务启动，且节点处于 Ready 状态时，代表清理操作已正常工作：

   $ oc get nodes

   输出示例

   NAME				    STATUS	                ROLES    AGE    VERSION
   ci-ln-tkbxyft-f76d1-nvwhr-master-1  Ready, SchedulingDisabled   master	 133m   v1.30.3

10. 将节点标记为可以调度。当状态中不再有 SchedulingDisabled 时代表启用了调度：

    $ oc adm uncordon <node_name>

    输出示例

    NAME				     STATUS	      ROLES    AGE    VERSION
    ci-ln-tkbxyft-f76d1-nvwhr-master-1   Ready            master   133m   v1.30.3