7.8. 对 Source-to-Image 进行故障排除
7.8.1. Source-to-Image 故障排除策略
Source-to-Image (S2I) 是一种用于构建可重复生成的 Docker 格式容器镜像的工具。它通过将应用程序源代码注入容器镜像,并汇编新镜像来生成可随时运行的镜像。新镜像融合了基础镜像(构建器)和构建的源。
要确定 S2I 进程中的故障发生位置,您可以观察与以下 S2I 阶段相关的 pod 状态:
- 在构建配置阶段,构建 pod 用于从基础镜像和应用程序源代码创建应用程序容器镜像。
- 在部署配置阶段,部署 pod 用于从构建配置阶段构建的应用程序容器镜像中部署应用程序 pod。部署 pod 还会部署其他资源,如服务和路由。部署配置在构建配置成功后开始。
-
在部署 pod 启动应用程序 pod 后,应用程序故障可能会在运行的应用程序 pod 中发生。例如,即使应用程序 pod 处于
Running
状态,应用程序的行为也可能不会如预期。在这种情况下,您可以访问正在运行的应用程序 pod,以调查 pod 中的应用程序故障。
当对 S2I 问题进行故障排除时,请按照这个策略操作:
- 监控构建、部署和应用程序 pod 状态
- 确定发生问题 S2I 进程阶段
- 查看与失败阶段对应的日志
7.8.2. 收集 Source-to-Image 诊断数据
S2I 工具按顺序运行构建 pod 和部署 pod。部署 pod 负责根据构建阶段创建的应用程序容器镜像部署应用程序 pod。观察构建、部署和应用程序 pod 状态,以确定 S2I 进程中的故障发生位置。然后,重点收集诊断数据。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - API 服务仍然可以正常工作。
-
已安装 OpenShift CLI(
oc
)。
流程
在整个 S2I 过程中监控 pod 状态,以确定在哪个阶段发生故障:
$ oc get pods -w 1
- 1
- 使用
-w
来监控 pod 是否有变化,直到您使用Ctrl+C
退出命令。
检查 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>
7.8.3. 收集应用程序诊断数据以调查应用程序失败
应用程序故障可在运行的应用程序 pod 中发生。在这些情况下,您可以使用以下策略检索诊断信息:
- 检查与应用程序 pod 相关的事件。
- 查看应用程序 pod 的日志,包括不是由 OpenShift Logging 框架收集的特定应用程序日志文件。
- 以互动方式测试应用程序功能,并在应用程序容器中运行诊断工具。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。
流程
列出与特定应用程序 pod 相关的事件。以下示例检索名为
my-app-1-akdlg
的应用程序 pod 的事件:$ oc describe pod/my-app-1-akdlg
检查应用程序 pod 的日志:
$ oc logs -f pod/my-app-1-akdlg
在正在运行的应用程序 pod 中查询特定日志。发送到 stdout 的日志由 OpenShift Logging 框架收集,并包含在上一命令的输出中。以下查询只适用于没有发送到 stdout 的日志。
如果应用程序日志可以在 pod 内不需要 root 权限的情况下就可以进行访问,则按如下方式处理日志文件:
$ oc exec my-app-1-akdlg -- cat /var/log/my-application.log
如果需要 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 。
以互动方式测试应用程序功能,并在带有互动 shell 的应用程序容器中运行诊断工具。
在应用程序容器上启动一个交互式 shell:
$ oc exec -it my-app-1-akdlg /bin/bash
- 在 shell 中以互动方式测试应用程序功能。例如,您可以运行容器的入口点命令并观察结果。然后,在更新源代码并通过 S2I 进程重建应用程序容器前,直接从命令行测试更改。
运行容器中的诊断二进制文件。
注意运行一些诊断二进制文件需要 root 权限。在这些情况下,您可以通过运行
oc debug dc/<deployment_configuration> --as-root
,根据有问题的 pod 的DeploymentConfig
对象启动一个带有 root 访问权限的 debug pod。然后,您可以从 debug pod 中以 root 用户身份运行诊断二进制文件。
如果容器中没有诊断二进制文件,您可以使用
nsenter
在容器的命名空间中运行主机的诊断二进制文件。以下实例在一个容器的命名空间中运行ip ad
,使用主机的ip
二进制代码。在目标节点上进入一个 debug 会话。此步骤被实例化为一个名为
<node_name>-debug
的 debug pod:$ oc debug node/my-cluster-node
将
/host
设为 debug shell 中的根目录。debug pod 在 pod 中的/host
中挂载主机的 root 文件系统。将根目录改为/host
,您可以运行主机可执行路径中包含的二进制文件:# chroot /host
注意运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.12 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作,
oc
操作将会受到影响。在这种情况下,可以使用ssh core@<node>.<cluster_name>.<base_domain>
来访问节点。确定目标容器 ID:
# crictl ps
确定容器的进程 ID。在本例中,目标容器 ID 是
7fe32346b120
:# crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'
在容器命名空间中运行
ip ad
,使用主机的ip
二进制代码。本例使用31150
作为容器的进程 ID。nsenter
命令输入目标进程的命名空间并在命名空间中运行命令。因为本例中的目标进程是一个容器的进程 ID,所以ip ad
命令在主机的容器命名空间中运行:# nsenter -n -t 31150 -- ip ad
注意只有在使用特权容器(如 debug 节点)时,才能在容器的命名空间中运行主机的诊断二进制代码。