您希望添加什么内容？
我们希望添加可配置的超时，以允许挂起的pod转换为失败。
如果它可以基于容器事件或消息而不是捕获所有超时进行配置，那将是理想的。
可能的API如下所示：
- regexp: "Failed to pull image.*desc = failed to pull and unpack image" # Suggests genuine problem with image name, no point in waiting around too long.
gracePeriod: 90s
- regexp: "Failed to pull image.*code = Unknown desc = Error response from daemon" # Seen when image doesn't exist, no point in waiting around too long.
gracePeriod: 90s这可以允许某些事件/状态转换为失败。
为什么需要这样做？
在阿尔马达项目中，我们发现，对于批处理用户，控制Pod在标记为失败之前处于挂起状态的时间是非常有用的。这允许我们的调度程序从集群中删除Pod，并为调度新的Pod留出空间。这还允许用户收到无效Pod的通知，他们能够使用正确的配置重新提交他们的Pod。
我们已经讨论了这个想法与非目标的https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/3329-retriable-and-non-retriable-failures#non-goals和@alculquicondor要求我创建一个问题。
8条答案
按热度按时间pu3pd22g1#
@kannon92：此问题目前正在等待分类。
如果SIG或子项目确定这是一个相关问题，他们将通过应用
triage/accepted标签接受该问题，并提供进一步的指导。triage/accepted标签可以由组织成员通过在注解中写入/triage accepted来添加。here提供了使用PR评论与我进行交互的说明。如果您对我的行为有任何问题或建议，请向kubernetes/test-infra存储库提交问题。
v440hwme2#
/已签名节点
/wg批次
8ljdwjyq3#
/已签名应用程序
regex当然不是我们想要鼓励的API，因为消息可能会从一个版本到下一个版本发生变化。
如果说您希望针对这些特定的待定场景，这是否公平？
PodScheduled=false）您是否认为其他待定情景对目标有用？
API的附加要求是在何处定义超时。
b4wnujal4#
也许@smarterclayton已经考虑过这个问题了：）
2uluyalo5#
/已签名应用程序
regex当然不是我们想要鼓励的API，因为消息可能会从一个版本到下一个版本发生变化。
如果说您希望针对这些特定的待定场景，这是否公平？
PodScheduled=false）您是否认为其他待定情景对目标有用？
API的附加要求是在何处定义超时。
所以我四处打听了一下。我们发现其他有用的区域也在InvalidConfigMaps、InvalidSecrets、bad pvc中。你在KEP的NonGoals中涵盖了很多。我们还遇到了GPU插件无法初始化的问题。
ws51t4hk6#
我想我们可以在一个单独的PodCondition
FailedToStartup中涵盖其中的大部分。我们需要sig-node输入。我们可以尝试在kubecon或下一次sig-node会议上获得一些反馈。dfuffjeb7#
@alculquicondor你能解释一下为什么这不是Job Controller的责任吗？我想到的一件事是这是一个更大的问题，因为仅仅对于调度作业的用户来说。但是我不太明白sig-node和sig-apps的责任之间的区别？主要是因为kubelet负责确定Pod是否发生故障吗？
wfsdck308#
主要是因为Kubelet负责确定Pod是否出现故障吗？
是的，我知道
此外，作业失败策略基于Pod条件，您描述的所有方案都没有Pod条件。