使用 Kubernetes API 调试工作程序节点

如果您有权访问集群，那么可以在 Node 资源上使用 Kubernetes API 来调试工作程序节点。

在开始之前，请确保您在所有命名空间中都拥有 Manager 服务访问角色或群集的管理员平台角色（对应于 cluster-admin RBAC 角色）。

1. 访问 Red Hat OpenShift 集群。

2. 列出集群中的工作程序节点，并记下不在 Ready STATUS 中的工作程序节点的 NAME。 请注意，NAME 是工作程序节点的专用 IP 地址。

   oc get nodes
   

3. 描述每个工作程序节点，并查看输出中的 Conditions 部分。

   • Type: 可能影响工作程序节点的条件类型，例如内存或磁盘压力。
   • LastTransitionTime: 最近一次更新状态的时间。 使用此时间来确定工作程序节点问题的开始时间，这可帮助您进一步对问题进行故障诊断。

   oc describe node <name>
   

4. 检查工作节点的使用情况

   1. 在先前命令的 Allocated resources 输出中，查看使用工作程序节点的 CPU 和内存资源的工作负载。 您可能会注意到某些 pod 未设置资源限制，并且耗用的资源超出预期。 如果是这样，请调整 pod 的资源使用情况。
   2. 查看集群中各个工作程序节点的 CPU 和内存使用率百分比。 如果使用率始终超过 80%，请向集群添加更多工作程序节点以支持工作负载。

5. 检查集群中安装的定制许可控制器。 许可控制器通常会阻止必需的 pod 运行，这可能会使工作程序节点进入临界状态。 如果您有定制许可控制器，请尝试使用 oc delete 将其移除。 然后，检查工作程序节点问题是否已解决。

   kubectl get mutatingwebhookconfigurations --all-namespaces
   

   kubectl get validatingwebhookconfigurations --all-namespaces
   

6. 如果配置了 日志转发，请从以下路径查看与节点相关的日志。

   /var/log/kubelet.log
   /var/log/syslog
   /var/log/messages
   

7. 检查工作负载部署是否不会导致工作程序节点问题。

   1. 使用问题污染工作程序节点。

      oc taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
      

   2. 请确保已删除任何定制许可控制器，如步骤 5 中所述。
   3. 重新启动工作程序节点。
      • 经典：重新加载工作节点

        ibmcloud oc worker reload -c <cluster_name_or_ID> --worker <worker_ID>
        

      • VPC：更换工作节点。

        ibmcloud oc worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
        

   4. 等待工作程序节点完成重新启动。 如果工作程序节点进入正常状态，那么问题可能是由工作负载引起的。
   5. 将一个工作负载一次调度到工作程序节点上，以查看导致该问题的工作负载。 要调度工作负载，请添加以下容错。

      tolerations:
      - effect: NoExecute
        key: ibm-cloud-debug-isolate-customer-workload
        operator: Exists
      

   6. 确定导致问题的工作负载后，继续 调试应用程序部署。