7.8. 对 Source-to-Image 进行故障排除

1. 在构建配置阶段，构建 pod 用于从基础镜像和应用程序源代码创建应用程序容器镜像。
2. 在部署配置阶段，部署 pod 用于从构建配置阶段构建的应用程序容器镜像中部署应用程序 pod。部署 pod 还会部署其他资源，如服务和路由。部署配置在构建配置成功后开始。
3. 在部署 pod 启动应用程序 pod 后，应用程序故障可能会在运行的应用程序 pod 中发生。例如，即使应用程序 pod 处于 Running 状态，应用程序的行为也可能不会如预期。在这种情况下，您可以访问正在运行的应用程序 pod，以调查 pod 中的应用程序故障。

1. 监控构建、部署和应用程序 pod 状态
2. 确定发生问题 S2I 进程阶段
3. 查看与失败阶段对应的日志

流程

1. 在整个 S2I 过程中监控 pod 状态，以确定在哪个阶段发生故障：

   $ oc get pods -w  1

   1

   使用 -w 来监控 pod 是否有变化，直到您使用 Ctrl+C 退出命令。

2. 检查 pod 失败的日志以找出错误。

   • 如果构建 pod 失败，请检查构建 pod 的日志：

     $ oc logs -f pod/<application_name>-<build_number>-build

     注意

     另外，您可以使用 oc logs -f bc/<application_name> 来查看构建配置的日志。构建配置的日志包括来自构建 pod 的日志。

   • 如果部署 pod 失败，请查看部署 pod 的日志：

     $ oc logs -f pod/<application_name>-<build_number>-deploy

     注意

     另外，您可以使用 oc logs -f bc/<application_name> 来查看部署配置的日志。此操作会从部署 pod 输出日志，直到部署 pod 成功完成为止。如果在部署 pod 完成后运行，命令会输出来自应用程序 pod 的日志。部署 pod 完成后，仍可通过运行 oc logs -f pod/<application_name>-<build_number>-deploy 来访问其日志。

   • 如果应用程序 pod 失败，或者应用程序没有如预期在正在运行的应用程序 pod 中发生，请查看应用程序 pod 的日志：

     $ oc logs -f pod/<application_name>-<build_number>-<random_string>

流程

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 Logging 框架收集，并包含在上一命令的输出中。以下查询只适用于没有发送到 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.9 集群节点不可变，它依赖于 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 节点）时，才能在容器的命名空间中运行主机的诊断二进制代码。