job的pod已经执行完成的情况下，为什么依然有实例在挂卷等事件，并且事件信息是失败的？-凯发k8国际娱乐官网入口

问题现象：

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），可能存在由于运行时间过短而误报卷挂载超时的情况，若这类短时运行任务属于正常退出，则该误报对业务没有影响可以忽略。