支持控制台（Console）开发人员开始试用联系人

7.7. 检查 pod 问题

OpenShift Container Platform 利用 Kubernetes 的 pod 概念，它是共同部署在同一主机上的一个或多个容器。pod 是可在 OpenShift Container Platform 4.15 上定义、部署和管理的最小计算单元。

在定义了 pod 后，它将分配到节点上运行，直到容器退出，或直到它被删除为止。根据策略和退出代码，Pod 可在退出或保留后删除，以便访问其日志。

首先要检查 pod 出现问题时 pod 的状态。如果发生 pod 故障，请观察 pod 的错误状态以识别特定镜像、容器或 pod 网络问题。根据错误状态集中诊断数据收集。查看 pod 事件消息以及 pod 和容器日志信息。通过访问命令行中运行的 pod，或根据 Pod 的部署配置启动具有 root 访问权限的调试 pod 来动态诊断问题。

7.7.1. 了解 pod 错误状态

pod 失败返回显式错误状态，可在 oc get pods 输出的 status 字段中观察到。Pod 错误状态会涵盖镜像、容器和容器网络相关的故障。

下表提供了 pod 错误状态及其描述列表。

表 7.3. Pod 错误状态
Pod 错误状态描述

ErrImagePull

通用镜像检索错误。

ErrImagePullBackOff

镜像检索失败。

ErrInvalidImageName

指定镜像名称无效。

ErrImageInspect

镜像检查没有成功。

ErrImageNeverPull

PullPolicy 设置为 NeverPullImage，目标镜像没有本地存在。

ErrRegistryUnavailable

当尝试从 registry 检索镜像时，会出现 HTTP 错误。

ErrContainerNotFound

指定容器在声明的 pod 中不存在或未由 kubelet 管理。

ErrRunInitContainer

容器初始化失败。

ErrRunContainer

pod 的容器都没有成功启动。

ErrKillContainer

没有 pod 的容器被成功终止。

ErrCrashLoopBackOff

容器已终止。kubelet 将不会试图重启它。

ErrVerifyNonRoot

容器或镜像尝试使用 root 权限运行。

ErrCreatePodSandbox

Pod 沙盒创建没有成功。

ErrConfigPodSandbox

Pod 沙盒配置没有获得。

ErrKillPodSandbox

pod 沙箱没有成功停止。

ErrSetupNetwork

网络初始化失败。

ErrTeardownNetwork

网络终止失败。

7.7.2. 检查 pod 状态

您可以查询 pod 状态和错误状态。您还可以查询 pod 的相关部署配置，并查看基础镜像的可用性。

先决条件

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

流程

  1. 切换到项目： 

    $ oc project <project_name>

  2. 列出在命名空间中运行的 pod，以及 pod 状态、错误状态、重启和年龄： 

    $ oc get pods

  3. 确定命名空间是否由部署配置管理： 

    $ oc status

    如果命名空间由部署配置管理，输出包括部署配置名称和基础镜像引用。

  4. 检查以上命令输出中引用的基础镜像： 

    $ skopeo inspect docker://<image_reference>

  5. 如果基础镜像引用不正确，请更新部署配置中的引用： 

    $ oc edit deployment/my-deployment

  6. 当部署配置退出时，配置将自动重新部署。在部署过程中的 Watch pod 的状态，以确定这个问题是否已解决： 

    $ oc get pods -w

  7. 检查命名空间中的事件，以了解与 pod 失败相关的诊断信息： 

    $ oc get events

7.7.3. 检查 pod 和容器日志

您可以检查 pod 和容器日志，以查看与显式 pod 失败相关的警告和错误消息。根据策略和退出代码，pod 和容器日志在 pod 终止后仍然可用。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI（oc）。

流程

  1. 查询特定 pod 的日志： 

    $ oc logs <pod_name>

  2. 查询 pod 中特定容器的日志： 

    $ oc logs <pod_name> -c <container_name>

    由前面的 oc logs 命令所获得的日志由发送到 pod 或容器中的 stdout 的信息组成。

  3. 检查 pod 中的 /var/log/ 中包含的日志。

    1. 列出 pod 中 /var/log 中所含的日志文件和子目录： 

      $ oc exec <pod_name>  -- ls -alh /var/log

      输出示例

      total 124K
drwxr-xr-x. 1 root root   33 Aug 11 11:23 .
drwxr-xr-x. 1 root root   28 Sep  6  2022 ..
-rw-rw----. 1 root utmp    0 Jul 10 10:31 btmp
-rw-r--r--. 1 root root  33K Jul 17 10:07 dnf.librepo.log
-rw-r--r--. 1 root root  69K Jul 17 10:07 dnf.log
-rw-r--r--. 1 root root 8.8K Jul 17 10:07 dnf.rpm.log
-rw-r--r--. 1 root root  480 Jul 17 10:07 hawkey.log
-rw-rw-r--. 1 root utmp    0 Jul 10 10:31 lastlog
drwx------. 2 root root   23 Aug 11 11:14 openshift-apiserver
drwx------. 2 root root    6 Jul 10 10:31 private
drwxr-xr-x. 1 root root   22 Mar  9 08:05 rhsm
-rw-rw-r--. 1 root utmp    0 Jul 10 10:31 wtmp

    2. 查询 pod 中 /var/log 中所含的特定日志文件： 

      $ oc exec <pod_name> cat /var/log/<path_to_log>

      输出示例

      2023-07-10T10:29:38+0000 INFO --- logging initialized ---
2023-07-10T10:29:38+0000 DDEBUG timer: config: 13 ms
2023-07-10T10:29:38+0000 DEBUG Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, uploadprofile
2023-07-10T10:29:38+0000 INFO Updating Subscription Management repositories.
2023-07-10T10:29:38+0000 INFO Unable to read consumer identity
2023-07-10T10:29:38+0000 INFO Subscription Manager is operating in container mode.
2023-07-10T10:29:38+0000 INFO

    3. 列出特定容器内 /var/log 中含有的日志文件和子目录： 

      $ oc exec <pod_name> -c <container_name> ls /var/log

    4. 查询特定容器中的 /var/log 中所含的特定日志文件： 

      $ oc exec <pod_name> -c <container_name> cat /var/log/<path_to_log>

7.7.4. 访问运行的 pod

您可以通过在 pod 中打开 shell，或通过端口转发获取网络访问，来动态查看正在运行的 pod。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI（oc）。

流程

  1. 切换到包含您要访问的 pod 的项目。这是必要的，因为 oc rsh 命令不支持使用 -n 选项指定命名空间： 

    $ oc project <namespace>

  2. 启动到 pod 的远程 shell: 

    $ oc rsh <pod_name>  1
    1
    如果 pod 有多个容器，除非使用 -c <container_name> 指定了一个容器，否则 oc rsh 会默认使用第一个容器。

  3. 启动至 pod 中的特定容器中的一个远程 shell ： 

    $ oc rsh -c <container_name> pod/<pod_name>

  4. 创建一个端口转发会话到 pod 上的端口： 

    $ oc port-forward <pod_name> <host_port>:<pod_port>  1
    1
    输入 Ctrl+C 来取消端口转发会话。

7.7.5. 启动具有 root 访问权限的 debug pod

您可以基于一个有问题的 pod 部署或部署配置，启动具有根访问权限的 debug pod。pod 用户通常使用非 root 权限运行，但运行具有临时 root 特权的 pod 进行故障排除时在调查问题时很有用：

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI（oc）。

流程

  1. 根据一个部署启动具有 root 访问权限的 debug pod。

    1. 获取项目部署名称： 

      $ oc get deployment -n <project_name>

    2. 根据部署启动带有 root 权限的 debug pod: 

      $ oc debug deployment/my-deployment --as-root -n <project_name>

  2. 根据部署配置启动具有 root 访问权限的 debug pod。

    1. 获取项目的部署配置名称： 

      $ oc get deploymentconfigs -n <project_name>

    2. 根据部署配置，使用 root 权限启动 debug pod: 

      $ oc debug deploymentconfig/my-deployment-configuration --as-root -n <project_name>
注意

您可以将 -- <command> 附加到前面的 oc debug 命令中，以便在 debug pod 中运行单个命令，而不是运行交互式 shell。

7.7.6. 将文件复制到 pod 和容器，或从 pod 和容器中复制

您可以将文件复制到 pod 或从 pod 复制，以测试配置更改或收集诊断信息。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • API 服务仍然可以正常工作。
  • 已安装 OpenShift CLI（oc）。

流程

  1. 将文件复制到 pod: 

    $ oc cp <local_path> <pod_name>:/<path> -c <container_name>  1
    1
    如果没有指定 -c 选项，则会选择 pod 中的第一个容器。

  2. 从 pod 复制文件： 

    $ oc cp <pod_name>:/<path>  -c <container_name> <local_path>  1
    1
    如果没有指定 -c 选项，则会选择 pod 中的第一个容器。
    注意

    要使 oc cp 正常工作，容器内必须有 tar。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.