K8S对Pod调度失败,Schdule控制器报错1 scheduling_queue.go:346] Unable to find backoff value for pod default/engine-video-process-worker-face-face-24902-t4-6b5bcf6d9c-swdwp in backoffQ
问题描述:
1、生产环境,基于K8s部署的应用,某个应用按要求需要运行9个副本,项目成功运行50余天后,应用的pod突然由9个变为6个,其他3个变为Pengding状态;
2、9个Pod需要消耗服务器的GPU资源,通过NodeSelector对pod和Node打选择标签,共3个GPU Node,正常工作时每个Node运行3个Pod,出现问题后每个Node只能运行两个Pod。
3、集群使用英伟达官方的GPU devcie-plug查看管理GPU资源,GPU devcie-plug以daemonset的方式运行在各个Node上。
排查过程:
1、使用"kubectl describe pod namespaces"查看pod描述。
发现调度失败的原因是:“0/9 nodes are available: 6 Insufficient nvidia.com/gpu, 6 node(s) didn't match node selector”,显然是GPU数量不足;
2、检查Pod的部署yaml文件,podyaml的nodeSelector“node-engine-stream=True”“node-gpu-t4=True”和node上的标签一致,标签选择器正常;
3、查看Node上GPU资源的使用情况,3个GPU节点的T4卡数量都是4个,但是已经使用用的GPU卡数分别是2、3、3个,且已使用的T4卡负载率都比较低,由此可见并不是Node GPU数量不足所致;
4、查看看schedule的日志,发现大量的日志“Unable to find backoff value for pod default/engine-video-process-worker-face-face-24902-t4-6b5bcf6d9c-swdwp in backoffQ”,说明Schdule调度异常;
5、逐个节点上重启静态Pod schdule、api-server、control-manager后,再次重启业务Pod,仍然只有6个处于pengding状态;
6、查看K8s Schdule源码,发现"Unable to find backoff value for pod default/engine-video-process-worker-face-face-24902-t4-6b5bcf6d9c-swdwp in backoffQ”并不是问题的根本原因。
结论:GPU Node的资源、标签选择器都是正常的,api-server、schdule、control-manager均工作正常,但是pod无法成功调度,可能是GPU 插件未能成功将Node的GPU资源反映到K8s中去。
解决办法:
重新启动nvidia-device-plugin pod,再重启业务Pod的deployemnt,问题解决。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型,支持深度思考和联网搜索!
· 使用C#创建一个MCP客户端
· 基于 Docker 搭建 FRP 内网穿透开源项目(很简单哒)
· ollama系列1:轻松3步本地部署deepseek,普通电脑可用
· 按钮权限的设计及实现