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