OpenShift 文档正在迁移，很快将只能在 docs.redhat.com（所有 Red Hat 产品文档的所在地）访问。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

Source-to-Image 过程故障排除

Source-to-Image 故障排除策略

使用 Source-to-Image (S2I) 构建可重现的、Docker 格式的容器镜像。您可以通过将应用程序源代码注入容器镜像并组装新镜像来创建可立即运行的镜像。新镜像包含基础镜像（构建器）和构建的源代码。

要确定 S2I 流程中故障发生的位置，您可以观察与以下每个 S2I 阶段相关的 Pod 的状态

  1. **在构建配置阶段**，使用构建 Pod 从基础镜像和应用程序源代码创建应用程序容器镜像。

  2. **在部署配置阶段**，使用部署 Pod 从在构建配置阶段构建的应用程序容器镜像部署应用程序 Pod。部署 Pod 还部署其他资源，例如服务和路由。部署配置在构建配置成功后开始。

  3. **在部署 Pod 启动应用程序 Pod 之后**，应用程序故障可能发生在正在运行的应用程序 Pod 中。例如，即使应用程序 Pod 处于`Running`状态，应用程序也可能无法按预期运行。在这种情况下，您可以访问正在运行的应用程序 Pod 以调查 Pod 中的应用程序故障。

在排除 S2I 问题时，请遵循以下策略：

  1. 监控构建、部署和应用程序 Pod 状态

  2. 确定 S2I 流程中出现问题的阶段

  3. 查看与失败阶段对应的日志

收集 Source-to-Image 诊断数据

S2I 工具按顺序运行构建 Pod 和部署 Pod。部署 Pod 负责根据在构建阶段创建的应用程序容器镜像部署应用程序 Pod。监视构建、部署和应用程序 Pod 状态以确定 S2I 流程中故障发生的位置。然后，相应地关注诊断数据收集。

先决条件

  • 您已作为拥有cluster-admin角色的用户访问集群。

  • 您的API服务仍在运行。

  • 您已安装OpenShift CLI (oc)。

步骤

  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 dc/<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>

收集应用程序诊断数据以调查应用程序故障

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

  • 查看与应用程序Pod相关的事件。

  • 查看应用程序Pod的日志，包括OpenShift日志框架未收集的特定于应用程序的日志文件。

  • 交互式测试应用程序功能并在应用程序容器中运行诊断工具。

先决条件

  • 您已作为拥有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日志框架收集，并包含在上一个命令的输出中。以下查询仅适用于未发送到stdout的日志。

    1. 如果可以在没有root权限的情况下访问Pod中的应用程序日志，请按如下方式连接日志文件。

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

    2. 如果需要root访问权限才能查看应用程序日志，您可以启动具有root权限的调试容器，然后从容器内查看日志文件。从项目的DeploymentConfig对象启动调试容器。Pod用户通常以非root权限运行，但在问题调查期间，使用临时的root权限运行故障排除Pod可能很有用。

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

      如果您运行oc debug dc/<deployment_configuration> --as-root而不附加-- <command>，则可以访问调试Pod中具有root访问权限的交互式shell。

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

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

      $ oc exec -it my-app-1-akdlg /bin/bash

    2. 从shell内交互式测试应用程序功能。例如，您可以运行容器的入口点命令并观察结果。然后，直接从命令行测试更改，然后再更新源代码并通过S2I流程重新构建应用程序容器。

    3. 运行容器中可用的诊断二进制文件。

      运行某些诊断二进制文件需要root权限。在这些情况下，您可以基于有问题的Pod的DeploymentConfig对象，通过运行oc debug dc/<deployment_configuration> --as-root启动具有root访问权限的调试Pod。然后，您可以从调试Pod内以root身份运行诊断二进制文件。

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

    1. 进入目标节点上的调试会话。此步骤将实例化一个名为<node_name>-debug的调试Pod。

      $ oc debug node/my-cluster-node

    2. 将/host设置为调试shell中的根目录。调试Pod在Pod内的/host中挂载主机的根文件系统。通过将根目录更改为/host，您可以运行包含在主机可执行路径中的二进制文件。

      # chroot /host

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

    3. 确定目标容器ID。

      # crictl ps

    4. 确定容器的进程ID。在此示例中，目标容器ID为a7fe32346b120。

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

    5. 使用主机的ip二进制文件在容器的命名空间中运行ip ad。此示例使用31150作为容器的进程ID。nsenter命令进入目标进程的命名空间并在其命名空间中运行命令。因为此示例中的目标进程是容器的进程ID，所以ip ad命令是从主机在容器的命名空间中运行的。

      # nsenter -n -t 31150 -- ip ad

      只有当您使用特权容器（例如调试节点）时，才可以在容器的命名空间中运行主机的诊断二进制文件。

其他资源