用于 Spring Boot 服务的 k8s 探针，最佳实践

Question

我正在为提供 Spring Boot 服务的 kubernetes 部署配置启动/活跃/就绪探针。截至 Spring Boot 文档，最佳实践是使用相应的活性和就绪执行器端点，如下所述： https ://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-启动

你用什么来启动探针？您对 failureThreshold、延迟、周期和超时值有何建议？您在将 isito sidecar 部署到现有设置时遇到过问题吗？

Answer 1

启动探针是可选的。

\n

最初，Kubernetes 中有两种类型的探针：就绪性和活跃性。然而，人们遇到了容器启动缓慢的问题。当容器需要很长时间才能启动时，Kubernetes 在initialDelaySeconds 之后首次检查活性探针。如果检查失败，Kubernetes 会尝试 failureThreshold 次，时间间隔为 periodSeconds。如果活跃度探测仍然失败，Kubernetes 会认为容器不活跃并重新启动它。不幸的是，容器可能会再次失败，导致无限的重启循环。

\n

您可能希望增加 failureThreshold 和 periodSeconds 以避免无休止的重新启动，但在线程死锁的情况下，它可能会导致更长的检测和恢复时间。

\n

您可能希望延长initialDelaySeconds 的时间，以便为容器启动提供足够的时间。然而，确定适当的延迟可能具有挑战性，因为您的应用程序可以在各种硬件上运行。例如，在一个环境中将initialDelaySeconds 增加到60 秒以避免此问题可能会导致在将服务部署到仅需要20 秒启动的更高级硬件时不必要的缓慢启动。在这种场景下，Kubernetes 等待 60 秒进行第一次活性检查，导致 pod 空闲了 40 秒，但仍然需要 60 秒才能提供服务。

\n

为了解决这个问题，Kubernetes 在 1.16 中引入了启动探针，它会推迟所有其他探针，直到 pod 完成其启动过程。对于慢速启动的 Pod，启动探针可以以较高的故障阈值以较短的时间间隔进行轮询，直到满足要求为止，此时其他探针可以开始。

\n

如果容器\xe2\x80\x99s除API组件之外的其他组件需要很长时间才能准备就绪，则容器可以简单地在liveness探针中报告200，并且不需要startup探针。因为 API 组件很快就会准备就绪并报告 200，所以 Kubernetes 不会无休止地重启容器，它会耐心等待，直到所有就绪探针都表明容器全部为 \xe2\x80\x9cready\xe2\x80\x9d 后才采取Pod 的流量。

\n

启动探针的实现方式与活性探针相同。一旦启动探针确认容器已初始化，活性探针将立即报告容器处于活动状态，不给 Kubernetes 错误重启容器留下空间。

\n

关于initialDelaySeconds、periodSeconds、failureThreshold、timeout，确实是敏感度和误报之间的平衡。例如，如果您的故障阈值很高，并且准备就绪探测的 periodSeconds 很高，那么 k8s 无法及时检测到容器中的问题，并且您的 pod 会继续占用流量，因此许多请求将失败。如果您为就绪探测设置较低的 failureThreshold 和较低的 periodSeconds，则临时问题可能会使 Pod 脱离流量，这是误报。我更喜欢默认的 failureThreshold 为 3，periodSeconds 为 5，successThreshold 为 1 或 2。

\n

顺便说一句，不要使用 Spring Boot 的默认健康检查，您始终需要自定义它们。更多详情请参见：https://danielw.cn/health-check-probes-in-k8s

\n