7.7.3. 收集应用程序诊断数据以调查应用程序失败

应用程序故障可在运行的应用程序 pod 中发生。在这些情况下,您可以使用以下策略检索诊断信息:

  • 检查与应用程序 pod 相关的事件。
  • 查看应用程序 pod 的日志,包括不是由 OpenShift Container Platform 日志框架收集的特定应用程序日志文件。
  • 以互动方式测试应用程序功能,并在应用程序容器中运行诊断工具。

先决条件

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

流程

  1. 列出与特定应用程序 pod 相关的事件。以下示例检索名为 my-app-1-akdlg 的应用程序 pod 的事件:

    $ oc describe pod/my-app-1-akdlg
  2. 检查应用程序 pod 的日志:

    $ oc logs -f pod/my-app-1-akdlg
  3. 在正在运行的应用程序 pod 中查询特定日志。发送到 stdout 的日志由 OpenShift Container Platform 日志记录框架收集,并包含在上一命令的输出中。以下查询只适用于没有发送到 stdout 的日志。

    1. 如果应用程序日志可以在 pod 内不需要 root 权限的情况下就可以进行访问,则按如下方式处理日志文件:

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log
    2. 如果需要 root 访问权限才能查看应用程序日志,您可以启动具有 root 权限的 debug 容器,然后从容器内查看日志文件。从项目的 DeploymentConfig 对象启动 debug 容器。pod 用户通常使用非 root 权限运行,但运行具有临时 root 特权的 pod 进行故障排除时在调查问题时很有用:

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log
      注意

      如果您运行不使用 -- <command>oc debug dc/<deployment_configuration> --as-root,则可以获得 debug pod 内带有 root 权限的一个互动式 shell 。

  4. 以互动方式测试应用程序功能,并在带有互动 shell 的应用程序容器中运行诊断工具。

    1. 在应用程序容器上启动一个交互式 shell:

      $ oc exec -it my-app-1-akdlg /bin/bash
    2. 在 shell 中以互动方式测试应用程序功能。例如,您可以运行容器的入口点命令并观察结果。然后,在更新源代码并通过 S2I 进程重建应用程序容器前,直接从命令行测试更改。
    3. 运行容器中的诊断二进制文件。

      注意

      运行一些诊断二进制文件需要 root 权限。在这些情况下,您可以通过运行 oc debug dc/<deployment_configuration> --as-root,根据有问题的 pod 的 DeploymentConfig 对象启动一个带有 root 访问权限的 debug pod。然后,您可以从 debug pod 中以 root 用户身份运行诊断二进制文件。

  5. 如果容器中没有诊断二进制文件,您可以使用 nsenter 在容器的命名空间中运行主机的诊断二进制文件。以下实例在一个容器的命名空间中运行 ip ad,使用主机的 ip 二进制代码。

    1. 在目标节点上进入一个 debug 会话。此步骤被实例化为一个名为 <node_name>-debug 的 debug pod:

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

      # chroot /host
      注意

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

    3. 确定目标容器 ID:

      # crictl ps
    4. 确定容器的进程 ID。在本例中,目标容器 ID 是7fe32346b120:

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'
    5. 在容器命名空间中运行 ip ad,使用主机的 ip 二进制代码。本例使用 31150 作为容器的进程 ID。nsenter 命令输入目标进程的命名空间并在命名空间中运行命令。因为本例中的目标进程是一个容器的进程 ID,所以 ip ad 命令在主机的容器命名空间中运行:

      # nsenter -n -t 31150 -- ip ad
      注意

      只有在使用特权容器(如 debug 节点)时,才能在容器的命名空间中运行主机的诊断二进制代码。