问题描述
万一Pod在我的集群中发生故障，大约需要15秒或更长时间才能通过就绪探测逻辑确定故障，由于呼叫失败，该故障未被接受（因为未识别kubernetes Pod故障，因此它将发送流量）到失败的Pod /我的意思是失败的Pod仍在cluster-P服务端点中。
请在此提出建议，如何立即使准备就绪探针失败或在发生失败的情况下如何立即删除端点，而又不将秒数减少到5秒以下。
以下是我的配置：
initialDelaySeconds:90s
periodSeconds:5s
timeoutSeconds:2s
successthreshold:<default>
failureThreshold:<default>
预先感谢。
解决方法
您可以做的是probe's configuration进行调整以满足您的要求：
探针具有许多字段，您可以使用它们来更精确地 控制活动和准备检查的行为：
initialDelaySeconds：启动容器后，启动活动性或就绪性探测之前的秒数。默认为 0秒。最小值为0。
periodSeconds：执行探测的频率（以秒为单位）。默认为10秒。最小值为1。
timeoutSeconds：探测超时的秒数。默认为1秒。最小值为1。
successThreshold：探测失败的最小连续成功次数。默认为1。必须为1。 为了活泼。最小值为1。
failureThreshold：当探测失败时，Kubernetes将在尝试放弃之前尝试使用failureThreshold时间。在生气的情况下放弃 探针表示重新启动容器。如果准备就绪，请 窗格将标记为“未就绪”。默认值为3。最小值为1。
您尚未指定failureThreshold，因此它默认为3。当前使用的值大约需要15-20秒才能将Pod视为失败并重新启动。
如果您为periodSeconds，timeoutSeconds，successThreshold和failureThreshold设置了最小值，则可以期望进行更频繁的检查和更快的吊舱重新娱乐。