IBM Cloud Docs
调试工作程序节点

调试工作程序节点

虚拟私有云 经典基础架构

复查可用于调试工作程序节点并查找故障根本原因的选项。

检查工作程序节点通知和维护更新

检查 IBM Cloud 运行状况和状态仪表板，以获取可能与工作程序节点相关的任何通知或维护更新。 这些通知或更新可能有助于确定工作程序节点故障的原因。

  1. 经典集群 检查运行状况仪表板 以获取可能影响帐户中经典工作程序节点的任何 IBM Cloud 紧急维护通知。 根据维护通知的性质，您可能需要重新引导或重新装入工作程序节点。
  2. 检查 IBM Cloud 状态仪表板 以了解可能影响工作程序节点或集群的任何已知问题。 如果以下任何组件显示错误状态，那么该组件可能是工作程序节点中断的原因。
    • 对于所有集群，请检查 Kubernetes Service 和 Container Registry 组件。
    • 对于 Red Hat OpenShift 群集，请检查 Red Hat OpenShift on IBM Cloud 组件。
    • 对于 VPC 集群，请检查 Virtual Private Cloud，Virtual Private Endpoint 和 Virtual Server for VPC 组件。
    • 对于经典集群，请检查 经典基础架构供应 和 Virtual Servers 组件。

解决工作程序节点问题的快速步骤

如果工作程序节点未按预期运行，那么可以遵循以下步骤来更新集群和命令行工具或运行诊断测试。 如果问题仍然存在，请参阅 调试工作程序节点 以获取其他步骤。

  1. 将集群和工作程序节点更新到最新版本。
  2. 更新命令行工具。
  3. 在诊断和调试工具附加组件中运行测试。

调试工作程序节点

步骤 1: 获取工作程序节点状态

如果集群处于 Critical、Delete failed 或 Warning 状态，或者长时间卡在 Pending 状态，请复查工作程序节点的状态。

ibmcloud oc worker ls --cluster <cluster_name_or_id>

步骤 2: 查看工作程序节点状态

复查 CLI 输出中每个工作程序节点的 State 和 Status 字段。

有关更多信息，请参阅 工作程序节点状态。

第 3 步：获取每个工作节点的详细信息

获取工人节点的详细信息。 如果详细信息包含错误消息，请查看工作程序节点的常见错误消息列表以了解如何解决问题。

ibmcloud oc worker get --cluster <cluster_name_or_id> --worker <worker_node_id>

步骤 4: 查看工作程序节点的基础结构提供程序

查看基础结构环境以查找可能导致工作程序节点问题的其他原因。

  1. 请与网络团队一起检查，以确保最近的维护 (例如，防火墙或子网更新) 不会影响工作程序节点连接。
  2. 请查看 IBM Cloud for Red Hat OpenShift on IBM Cloud 和底层基础结构提供程序 (例如 Virtual Servers for classic，VPC 相关组件或 Satellite)。
  3. 如果您有权访问底层基础结构 (例如经典 Virtual Servers)，请查看工作程序节点的相应机器的详细信息。

第 5 步：收集工作节点的日志和其他详细信息

运行 must-gather 命令

oc adm must-gather CLI 命令收集群集信息，用于调试问题。 该工具必须收集资源定义、服务日志等。 请注意，审计日志不作为默认信息集的一部分收集，以减小文件的大小。

运行 oc adm must-gather 时，会在群集上的一个新项目中创建一个名称随机的新 pod。 数据在该 pod 上收集，并保存在一个以 must-gather.local 开头的新目录中。

查看以下命令示例。

oc adm must-gather

示例命令，要收集与一个或多个特定特征相关的数据，请使用 --image 参数和特定图像。

oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

收集审计日志的示例命令。

oc adm must-gather -- /usr/bin/gather_audit_logs

在特定命名空间中运行 must-gather 的示例命令。

oc adm must-gather --run-namespace <namespace> \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

从给定时间段内收集日志的示例命令。

oc adm must-gather --since=24h

oc adm must-gather --since-time=$(date -d '-24 hours' +%Y-%m-%dT%T.%9N%:z )

收集网络日志的示例命令。

oc adm must-gather -- gather_network_logs

如需更多示例和参数，请运行以下命令

oc adm must-gather -h

从必须收集目录创建压缩文件的示例命令。

tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/

将压缩文件附在您的支持案例中。

收集 SOS 报告

sosreport 是一款从 (RHEL) 和 (RHCOS) 系统中收集配置详情、系统信息和诊断数据的工具。Red Hat Enterprise Linux Red Hat Enterprise Linux CoreOS 它提供了一种收集与节点有关的诊断信息的标准化方法，可将这些信息提供给支持人员进行问题诊断。

在某些支持交互中，支持人员可能会要求您为特定 OpenShift Container Platform 节点收集 sosreport 存档。 例如，可能需要查看 oc adm must-gather 输出中未包含的系统日志或其他特定节点数据。

为 OpenShift Container Platform 集群节点生成 sosreport 的推荐方法是通过调试 pod。

访问 Red Hat OpenShift 集群。

  1. 列出工作节点

    oc get nodes

  2. 在目标节点上启动调试会话。

    oc debug node/node_name

    要在受 NoExecute 影响的目标节点上进入调试会话，可在临时命名空间中添加容忍度，并在临时命名空间中启动调试 pod。

    oc new-project temp oc patch namespace temp --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'

    oc debug node/my-cluster-node

  3. 将 /host 设置为调试 shell 的根目录。 调试 pod 会将主机的根文件系统挂载到 pod 中的 /host。 将根目录更改为 /host，就可以运行主机可执行路径中包含的二进制文件。

    chroot /host

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

  4. 启动工具箱容器，其中包括运行 sosreport 所需的二进制文件和插件。

    toolbox

    如果现有的工具箱 pod 已在运行，则工具箱命令会输出 'toolbox-' already exists. Trying to start…. 删除正在运行的工具箱容器（ podman rm toolbox- ），并启动一个新的工具箱容器。

  5. 运行 sos report 命令并按照提示收集故障排除数据。

    sos report -k crio.all=on -k crio.logs=on -k podman.all=on -k podman.logs=on

    在报告中包含节点的 OVN- Kubernetes 网络配置信息的示例命令。

    sos report --all-logs

    sosreport 输出提供存档的位置和校验和。 以下示例输出引用了支持案例 ID 01234567。 文件路径位于 chroot 环境之外，因为工具箱容器会将主机根目录挂载到 /host。

    Your sosreport has been generated and saved in:
/host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
The checksum is: 382ffc167510fd71b4f12a4f40b97a4e

  6. 将 sosreport 输出到文件。

    调试容器会将主机根目录挂载到 /host。 在指定连接的目标文件时，引用调试容器根目录的绝对路径，包括 /host。

    oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz

    OpenShift Container Platform 运行 (RHCOS) 的集群节点是不可变的，需要操作员来应用集群变更。Red Hat Enterprise Linux CoreOS 不建议使用 scp 从群集节点传输 sosreport 存档。 但是，如果 OpenShift Container Platform API 不可用，或者 kubelet 无法在目标节点上正常运行，oc 操作可能会受到影响。 在这种情况下，可以通过运行 scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path> 从节点复制 sosreport 存档。

  7. 将文件上传到您的支持案例。