当前位置:主页 > 查看内容

job的pod已经执行完成的情况下,为什么依然有实例在挂卷等事件,

发布时间:2021-09-25 00:00| 位朋友查看

简介:问题现象: job的pod已经执行完成的情况下,依然有实例在挂卷等事件,并且事件信息是失败的。 图1 问题截图 问题原因: 各种类型的POD(Deployment/StatefulSet/Job/CronJob)在Node上启动时: 由kubelet针对该POD创建podWorker(独立协程)负责检测POD与关……

问题现象:

job的pod已经执行完成的情况下,依然有实例在挂卷等事件,并且事件信息是失败的。

图1 问题截图

问题原因:

各种类型的POD(Deployment/StatefulSet/Job/CronJob)在Node上启动时:

  • 由kubelet针对该POD创建podWorker(独立协程)负责检测POD与关联volume的挂载情况:每隔0.3s检测当前POD所需挂载的volume都已经挂载成功,检测超时为2min3s;若检测周期中以及最终超时到达时POD关联volume都没有检测到挂载成功,则上报事件“Unable to mount volumes for pod …”。
  • 由kubelet中VolumeManager(独立协程)负责具体实施POD关联volume的挂载操作。

对于long running的POD(Deployment/StatefulSet),除了类似镜像拉取失败、存储挂载失败、容器网络分配失败、当前节点CPU/Mem不满足POD的实际使用要求等异常场景外,POD容器若最终都会启动成功时,上述podWorker在几次周期后都会判定挂载成功。

而对于短时运行的POD(Job/CronJob),由于容器中业务存在正常退出(如问题场景的GCS Demo job只执行一些echo和ls命令,总体耗时1s不到),就存在短时POD运行退出时若刚好在两次podwork检测volume挂载周期中,那么就会出现本问题单所述的误报,但是不影响业务使用,且实际的Job业务还是会运行超过上述时间的。

当前kubelet上述能力属于社区挂载框架既有能力。

解决方法:

针对短时运行的POD(Job/CronJob),可能存在由于运行时间过短而误报卷挂载超时的情况,若这类短时运行任务属于正常退出,则该误报对业务没有影响可以忽略。


本站部分内容转载于网络,版权归原作者所有,转载之目的在于传播更多优秀技术内容,如有侵权请联系QQ/微信:153890879删除,谢谢!
上一篇:私有网络 调整安全组优先级 - 操作指南 下一篇:没有了

推荐图文

  • 周排行
  • 月排行
  • 总排行

随机推荐