Question

有没有一种方法可以配置活动探针以在Pod成功完成后停止运行？

我正在使用活动探针，以确保批处理作业（预计将在几分钟到几周内完成运行）能够响应并正常运行。但是，当Pod成功完成时，似乎在Pod停止为活动性探针提供服务（在这种情况下，触摸文件）与成功完成之后删除Pod之间存在延迟。在此延迟期间，活动性探针失败足够多次，以触发Kubernetes重新启动Pod。

除了增加活动度探针的故障阈值或周期，或减少Pod的终止宽限期外，对于这个问题，我还没有遇到任何可能的缓解措施，也没有可靠的解决方案。实际上，我在Kubernetes的文档中没有提到在批处理Job中使用活动探针的情况。

来自kubectl describe pod <pod>的事件日志如下。消息Liveness probe failed: OCI runtime exec failed: exec failed: cannot exec a container that has stopped: unknown令我特别感兴趣，并且使我认为活跃度探测在Pod完成期间失败的想法是什么。

Events:
  Type     Reason     Age                From              Message
  ----     ------     ----               ----              -------
  Warning  Unhealthy  55m                kubelet, pascal0  Liveness probe failed: OCI runtime exec failed: exec failed: cannot exec a container that has stopped: unknown
  Normal   Created    55m (x8 over 21h)  kubelet, pascal0  Created container
  Normal   Pulled     55m (x7 over 18h)  kubelet, pascal0  Container image "<image>" already present on machine
  Normal   Started    55m (x8 over 21h)  kubelet, pascal0  Started container

一些相关的Job配置值包括在下面。

backoffLimit: 10
restartPolicy: OnFailure
livenessProbe:
  exec:
    command:
      - test
      - $(stat -c %Y /tmp/healthy) -gt $(($(date +%s) - 10))
  initialDelaySeconds: 30
  periodSeconds: 60
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3

Answer 1

除了增加活动度探针的故障阈值或周期，或减少Pod的终止宽限期外，对于这个问题，我还没有遇到任何可能的缓解措施，也没有可靠的解决方案。

调整这些参数以满足您的需求没有错。 Default吊舱的正常终止时间为30秒，因此，如果您的容器需要更多时间终止，则应相应更改探测时间。或者我可能错过了要点，这可能会成为您的问题。

实际上，我在Kubernetes的文档中没有发现在批处理Job中使用活动探针的任何提及。

我也不是。显然，这不是一种很流行的方法，因此可能没有经过足够好的测试。

关于变通办法，我打算建议使用preStop hook，但是在阅读whole story之后，我发现了suggestion在问题{ {3}}：

我最终使用带时间戳文件的livenessProbe来从sidecar容器中了解容器的活泼性。希望这对您也有帮助

您还可以考虑配置srikumarb的活动度探针，例如检查正常运行时间（或与文件系统无关的任何时间）

或者，您可以尝试使用#55807作为探针文件的占位符。

批处理作业上的活动性探针在完成后重新启动Pod

1 个答案: