准备工作

在使用可观察性服务对集群进行调试之前，请确保满足以下要求。

• 您的集群已连接到一个 IBM Cloud Monitoring 实例。 要连接您的集群，请参阅《 为 Red Hat OpenShift on IBM Cloud 启用指标 》。
• 您的集群已连接到一个 IBM Cloud Logs 实例。 要连接您的集群，请参阅“启用日志记录”。
• 您对账户中的 IBM Cloud Monitoring 和 IBM Cloud Logs 服务实例至少拥有 “查看者”级别的访问权限。

使用以下命令检查工作节点资源使用情况：IBM Cloud Monitoring

当工作节点进入 Critical 或 NotReady 状态时，CPU或内存占用率过高通常是导致该状态的常见原因。 使用 IBM Cloud Monitoring 的预构建仪表板，快速识别资源压力。

1. 打开您所在集群的 IBM Cloud Monitoring 仪表盘。

   1. 在 IBM Cloud 控制台中，导航至您的集群资源页面，然后点击相应的集群。
   2. 在 “集成”下，找到 “监控” 选项，然后点击 “启动”。 IBM Cloud Monitoring 用户界面将在新窗口中打开。

2. 导航至 Kubernetes > “节点”预构建仪表板，以查看各节点的 CPU 和内存使用情况。

   • 查找满足以下条件之一的节点：CPU % 或 内存 % 超过 80%。 达到或超过此阈值的节点存在过载风险，并可能开始无法调度新的 Pod。
   • 查找那些在过去一小时或一天内，CPU 或内存使用率突然飙升或持续处于较高水平的节点。 这可以帮助您判断该问题是暂时的还是持续存在的。

3. 要查看特定节点，请在仪表盘中单击该节点的名称，将所有图表筛选为仅显示该节点的数据。 请检查以下指标：

   • CPU 使用率（% ）——若该数值持续高于 90%，则表明 CPU 已达到饱和状态。
   • 内存使用率（% ）——该值若长期高于85%，将增加发生内存不足（OOM）事件的风险。
   • 网络数据入/出字节数 ——流量出现意外激增可能表明工作负载失控或遭遇网络攻击。

4. 要查看哪个Pod在节点上消耗的资源最多，请转到 Kubernetes > “Pods” 仪表板，并按受影响的节点进行筛选。 请记录那些 CPU 或内存使用率持续偏高的 Pod 的名称，因为这些很可能是导致工作节点不稳定的原因。

使用以下命令检查 pod 状态和重启次数：IBM Cloud Monitoring

频繁发生崩溃循环或重启的 Pod，通常是应用程序层级问题的迹象，例如因内存不足（OOM）导致的进程终止，或是就绪探针配置错误。 使用 IBM Cloud Monitoring 来识别这些 Pod，而无需反复运行 oc get pods 。

1. 在 IBM Cloud Monitoring 用户界面中，导航至 Kubernetes >“预构建 Pod”仪表板。

2. 查看 “容器重启”面板。 查找过去15分钟内重启次数大于零的Pod，或者在较长一段时间内重启次数急剧增加的Pod。

   • 重启计数器如果不断递增，则表明系统陷入了死循环。 请记下该 Pod 的名称和命名空间，以便在后续的日志排查步骤中使用。
   • 如果重启计数为零，但状态显示为 “待处理”或“未知”，则表明存在调度或节点连接问题，而非应用程序故障。

3. 若要为未来的 Pod 重启事件设置告警，请在 IBM Cloud Monitoring 用户界面中点击 “告警”图标，并针对 kubernetes.pod.restart.count 指标创建一个指标告警。 将阈值设置为：当任何 Pod 在五分钟内重启次数超过两次时触发。 这可以在死循环造成干扰之前提供早期预警。 有关配置警报的更多信息，请参阅 《设置 IBM Cloud® Monitoring 警报》

使用以下命令查看容器日志：IBM Cloud Logs

当 Pod 重启或节点出现问题时，查看容器日志对于查明根本原因至关重要。IBM Cloud Logs 会保留历史日志数据，而这些数据在容器重启后无法通过 oc logs 获取。

1. 打开 IBM Cloud Logs 仪表板。

   1. 在 IBM Cloud 控制台中，导航至您的集群资源页面，然后点击相应的集群。
   2. 在 “集成”下，找到 “日志记录”选项，然后点击 “启动”。 IBM Cloud Logs 的用户界面将在新窗口中打开。

2. 将时间范围设置为涵盖问题发生的时间段。 如果该问题仍在持续，请将时间范围设置为过去一小时。 如果您正在调查过去发生的事件，请设置具体的开始和结束时间以缩小搜索范围。

3. 搜索受影响的 Pod 或命名空间。 使用界面顶部的查询栏来筛选日志。 例如，要显示 default 命名空间中所有Pod的日志，请输入以下查询：

   kubernetes.namespace_name:"default"
   

   若要按名称将结果范围缩小到特定的 Pod，请使用：

   kubernetes.pod_name:"MY_POD_NAME"
   

4. 检查日志条目中是否存在错误级别的记录。 请检查以下任何一种表明常见故障模式的迹象：

   • OOMKilled 或 out of memory — 容器超过了内存限制，被内核终止。
   • CrashLoopBackOff — 容器正在反复重启，这通常是由于启动时应用程序出现错误所致。
   • failed to pull image 或 ImagePullBackOff — 该节点无法从注册表中拉取容器镜像。
   • Connection refused 或 context deadline exceeded ——应用程序无法连接到依赖的服务或 Kubernetes API服务器。

5. 如果您发现与 OOM 相关的日志条目，请记录时间戳，并查看同一时间段内的 IBM Cloud Monitoring Kubernetes > Pods 仪表盘中同一时间段内的数据，以确认该 Pod 在重启前不久的内存使用量已达到上限。

使用以下方式查看 Kubernetes 上的活动：IBM Cloud Logs

Kubernetes 这些事件记录了集群中的重要活动，例如 Pod 调度失败、节点状态以及卷挂载错误。IBM Cloud Logs 会自动采集这些事件，并允许您按历史时间进行搜索和筛选——这与 oc get events 不同，后者仅显示当前会话中的近期事件。

1. 在 IBM Cloud Logs 用户界面中，使用以下查询显示整个集群中所有 Kubernetes 警告事件：

   kubernetes.event.type:"Warning"
   

2. 若要将事件过滤到特定的工作节点，请在查询中添加该节点的名称。 请将 NODE_NAME 替换为受影响节点的名称：

   kubernetes.event.type:"Warning" AND kubernetes.event.involvedObject.name:"NODE_NAME"
   

3. 查看事件日志条目中的 “原因”字段。 以下原因对于排查工作节点和工作负载问题最为相关：

NodeNotReady

该节点报告了 NotReady 状态。 该事件通常发生在工作节点进入 Critical 状态之前或与其同时发生。

OOMKilling

由于内存耗尽，内核终止了该节点上的一个进程。

FailedScheduling

调度器无法将该 Pod 部署到任何可用节点上。 “消息”字段通常会说明原因，例如 CPU 不足、内存不足或节点选择器不匹配。

BackOff

一个容器陷入了死循环。 每当 kubelet 在重启容器之前进行回退时，都会触发该事件。

FailedMount 或 FailedAttachVolume

无法将一个持久卷挂载或附加到 Pod 上，这导致该 Pod 无法启动。

1. 对于任何看似相关的事件，请记录其 involvedObject.name 和 involvedObject.namespace 的值，并利用这些值与前几节中收集的日志和指标数据进行关联分析。

后续步骤

• 如果您发现某个工作节点面临资源压力，请考虑 重新加载或替换该工作节点，或者调整该节点上运行的 Pod 的资源请求和限制。
• 如果 pod 因 OOM 终止而陷入崩溃循环，请提高受影响容器的内存限制，或将内存密集型工作负载迁移到具有更大节点的工作者池中。
• 如果日志显示镜像拉取失败，请检查 镜像拉取密钥，并确认工作节点能否访问容器注册表。
• 对于无法通过此处收集的信息解决的问题，请参阅《 为支持工单收集数据 》，以获取提交支持工单所需的信息。

相关链接

• 监控集群健康状况
• 入门指南 IBM Cloud Monitoring
• 入门指南 IBM Cloud Logs
• 排查处于 Critical 或 NotReady 状态的 worker 节点故障
• 设置 IBM Cloud® Monitoring 提醒