有时候我要启动很多工作,每个工作都安装了一个pvc。由于我们的资源有限,某些吊舱无法在不到一分钟的时间内安装完毕。
无法为pod“ package-job-120348968617328640-5gv7s_vname(b059856a-ecfa-11ea-a226-fa163e205547)”安装卷:超时已到期,等待卷挂接或为pod“ vname” /“ package-job- 120348968617328640-5gv7s”。未安装的卷列表= [tmp]。未连接卷的列表= [log tmp]。
它肯定会继续重试。但是,它永远不会成功(事件年龄就像44s (x11 over 23m)
)。但是,如果我删除此广告连播,此作业将创建一个新的广告连播并完成。
那为什么会这样呢?容器是否应该自动重试安装而不需要手动干预? 如果无法避免,是否有变通办法,它将在Init Phase中自动删除超过2分钟的Pod?
实际上是我的云提供商在某些节点卡死(由网络问题引起)中提供的附加脚本。因此,如果其他人遇到这些问题,也许检查附有磁盘的存储插件是一个好主意。
答案 0 :(得分:2)
那为什么会这样呢?容器是否应该自动重试安装而不需要手动干预?如果无法避免,是否有变通办法,它将在Init Phase中自动删除超过2分钟的Pod?
可能有多种原因。如果您进行kubectl describe pod <podname>
,您在Pod上有任何活动吗?并且您是否重用了另一个Pod以前使用的PVC?
我猜您使用的是区域群集,该群集由多个数据中心(可用区)组成,并且您的PVC位于一个可用区中,但您的Pod已计划在另一个可用区中运行?在这种情况下,由于Pod位于另一个AZ中,因此Pod将永远无法挂载该卷。
答案 1 :(得分:0)
当同一卷连接到运行Pod的同一节点时,我遇到了同样的问题。
我ssh进入节点并重新启动var.DD_API_KEY
,然后它解决了该问题。