使用 Kubernetes API 调试工作程序节点
如果您有权访问集群,那么可以在 Node
资源上使用 Kubernetes API 来调试工作程序节点。
开始之前,请确保您在集群的所有名称空间中都具有 Manager 服务访问角色,该角色对应于 cluster-admin
RBAC 角色。
-
列出集群中的工作程序节点,并记下不在
Ready
STATUS 中的工作程序节点的 NAME。 请注意,NAME 是工作程序节点的专用 IP 地址。kubectl get nodes
-
描述每个工作程序节点,并查看输出中的
Conditions
部分。Type
: 可能影响工作程序节点的条件类型,例如内存或磁盘压力。LastTransitionTime
: 最近一次更新状态的时间。 使用此时间来确定工作程序节点问题的开始时间,这可帮助您进一步对问题进行故障诊断。
kubectl describe node <name>
-
检查工作节点的使用情况
- 在先前命令的
Allocated resources
输出中,查看使用工作程序节点的 CPU 和内存资源的工作负载。 您可能会注意到某些 pod 未设置资源限制,并且耗用的资源超出预期。 如果是这样,请调整 pod 的资源使用情况。 - 查看集群中各个工作程序节点的 CPU 和内存使用率百分比。 如果使用率始终超过 80%,请向集群添加更多工作程序节点以支持工作负载。
- 在先前命令的
-
检查集群中安装的定制许可控制器。 许可控制器通常会阻止必需的 pod 运行,这可能会使工作程序节点进入临界状态。 如果您有定制许可控制器,请尝试使用
kubectl delete
将其移除。 然后,检查工作程序节点问题是否已解决。kubectl get mutatingwebhookconfigurations --all-namespaces
kubectl get validatingwebhookconfigurations --all-namespaces
-
如果配置了 日志转发,请从以下路径查看与节点相关的日志。
/var/log/containerd.log /var/log/kube-proxy.log /var/log/kubelet.log /var/log/syslog
-
检查工作负载部署是否不会导致工作程序节点问题。
- 使用问题污染工作程序节点。
kubectl taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
- 请确保已删除任何定制许可控制器,如步骤 5 中所述。
- 重新启动工作程序节点。
- 经典:重新加载工作节点
ibmcloud ks worker reload -c <cluster_name_or_ID> --worker <worker_ID>
- VPC:更换工作节点。
ibmcloud ks worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
- 经典:重新加载工作节点
- 等待工作程序节点完成重新启动。 如果工作程序节点进入正常状态,那么问题可能是由工作负载引起的。
- 将一个工作负载一次调度到工作程序节点上,以查看导致该问题的工作负载。 要调度工作负载,请添加以下容错。
tolerations: - effect: NoExecute key: ibm-cloud-debug-isolate-customer-workload operator: Exists
- 确定导致问题的工作负载后,继续 调试应用程序部署。
- 使用问题污染工作程序节点。