Kubernetes readinessProbe:健康检查会永远运行吗？

Question

我对HTTP readinessProbe有一些疑问：

1. 假设探针多次失败(failureThreshold)，并且一个pod标记为“未准备好”。如果k8s开始正确地响应，它会永远尝试readinessProbe并最终标记为准备好吗？或者一个被标记为还没有准备好的豆荚永远留在那里，而不需要重新尝试？
2. 如果还没有准备好的吊舱永远留在那里，K8s部署会尝试启动新的吊舱吗？不然我就没那么多豆荚了？
3. 如果一个吊舱通过了readinessProbe，k8s会继续检查它是否已经准备好，并最终(如果它开始失败)将它标记为将来没有准备好吗？这有可能吗？或者一个一旦被标记为准备好的豆荚就永远准备好了？

Answer 1

是的，集装箱永远留在那里。把准备好的探测器想象成一个破碎机，如果应用程序被淹没了，它就会切断吊舱的流量，直到它准备好再次获得流量。

2-不，就其本身而言，准备状态探测器只会阻止/启动通往货舱的交通。要向kubernetes发出信号，即需要重新启动吊舱，请使用活性探针。

3-是的，如答案1所示，准备状态探测器是一种让库伯奈特知道吊舱可以处理交通或需要休息的方法。

探测:启动探测-等待应用程序启动

用例:在开始服务流量之前需要一段时间的应用程序，例如，在开始时构建资产、预获取资产、构建缓存等等。

活性探针-检查应用程序是否健康

用例:检查应用程序是否正在运行，应用程序是否由于异常而退出，需要重新启动，或者应用程序是否正在运行，但无法处理请求

就绪探测-检查应用程序是否能够处理流量

用例:可以任意停止接收流量的应用程序，例如维护模式、数据密集型应用程序，这些应用程序的性能会下降，需要一种方法

你应该始终使用活跃和准备好的探针，当你的应用程序比平时花费更多的时间启动时，使用启动探针。

示例：

• 带有postgres数据库的python应用程序：
• 活性探测:获取/health状态200
• 准备状态探测:获取/health状态200，超时1s

/health端点使用简单的查询(从用户限制1选择id、电子邮件)查询数据库，并返回一个json。

如果吊舱失去了与数据库的连接，活性探测将失败，吊舱将被重新启动。如果数据库被请求淹没，查询将花费超过1s，探测将标记吊舱未准备就绪，防止附加请求到达数据库，并阻止其从不堪重负向崩溃发展。一旦数据库能够赶上并在不到1s内开始返回查询，就绪探测将再次将吊舱标记为健康，kubernetes将恢复对吊舱的服务请求。