×

OpenShift Dedicated 利用 Kubernetes 的 Pod 概念,Pod 是在一个主机上一起部署的一个或多个容器。Pod 是可以在 OpenShift Dedicated 上定义、部署和管理的最小计算单元。

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

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

了解 Pod 错误状态

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

下表列出了 Pod 错误状态及其说明。

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

ErrImagePull

通用的镜像检索错误。

ErrImagePullBackOff

镜像检索失败并已回退。

ErrInvalidImageName

指定的镜像名称无效。

ErrImageInspect

镜像检查未成功。

ErrImageNeverPull

PullPolicy 设置为 NeverPullImage,并且目标镜像不在主机本地存在。

ErrRegistryUnavailable

尝试从注册表检索镜像时,遇到 HTTP 错误。

ErrContainerNotFound

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

ErrRunInitContainer

容器初始化失败。

ErrRunContainer

Pod 的所有容器均未成功启动。

ErrKillContainer

Pod 的所有容器均未成功终止。

ErrCrashLoopBackOff

容器已终止。kubelet 将不会尝试重新启动它。

ErrVerifyNonRoot

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

ErrCreatePodSandbox

Pod 沙箱创建未成功。

ErrConfigPodSandbox

未获取 Pod 沙箱配置。

ErrKillPodSandbox

Pod 沙箱未成功停止。

ErrSetupNetwork

网络初始化失败。

ErrTeardownNetwork

网络终止失败。

查看 Pod 状态

您可以查询 Pod 状态和错误状态。您还可以查询 Pod 的关联部署配置并查看基本镜像可用性。

先决条件
  • 您作为具有 `dedicated-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. 当部署配置在退出时发生更改时,配置将自动重新部署。在部署过程中观察 Pod 状态,以确定问题是否已解决

    $ oc get pods -w
  7. 查看命名空间内的事件,以获取与 Pod 故障相关的诊断信息

    $ oc get events

检查 Pod 和容器日志

您可以检查 Pod 和容器日志中与显式 Pod 故障相关的警告和错误消息。根据策略和退出代码,Pod 和容器日志在 Pod 终止后仍然可用。

先决条件
  • 您作为具有 `dedicated-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>

访问正在运行的 Pod

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

先决条件
  • 您作为具有 `dedicated-admin` 角色的用户可以访问集群。

  • 您的 API 服务仍在运行。

  • 您已安装 OpenShift CLI(`oc`)。

步骤
  1. 切换到包含您要访问的 Pod 的项目。这是必要的,因为 `oc rsh` 命令不接受 `-n` 命名空间选项

    $ oc project <namespace>
  2. 启动到 Pod 的远程 shell

    $ oc rsh <pod_name>  (1)
    1 如果 Pod 包含多个容器,除非指定了 `-c `,否则 `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` 取消端口转发会话。

启动具有 root 访问权限的调试 Pod

您可以基于有问题的 Pod 的部署或部署配置启动具有 root 访问权限的调试 Pod。Pod 用户通常以非 root 权限运行,但在问题调查期间,使用临时 root 权限运行故障排除 Pod 可能很有用。

先决条件
  • 您作为具有 `dedicated-admin` 角色的用户可以访问集群。

  • 您的 API 服务仍在运行。

  • 您已安装 OpenShift CLI(`oc`)。

步骤
  1. 基于部署启动具有 root 访问权限的调试 Pod。

    1. 获取项目的部署名称

      $ oc get deployment -n <project_name>
    2. 基于部署启动具有 root 权限的调试 Pod

      $ oc debug deployment/my-deployment --as-root -n <project_name>
  2. 基于部署配置启动具有 root 访问权限的调试 Pod。

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

      $ oc get deploymentconfigs -n <project_name>
    2. 基于部署配置启动具有 root 权限的调试 Pod

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

您可以将 `-- ` 附加到前面的 `oc debug` 命令,以便在调试 Pod 中运行单个命令,而不是运行交互式 shell。

复制文件到 Pod 和容器以及从 Pod 和容器复制文件

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

先决条件
  • 您作为具有 `dedicated-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` 二进制文件可用。