Kubernetes Openshift健康检查

对于Openshift运行状况检查（活动性和就绪性探测），活动性检查是否在容器准备就绪后运行。因此，准备就绪初始延迟是否应小于活跃度初始延迟

请告知

谢谢

---

B.

为准备就绪和活动性检查指定的延迟是从部署开始。活跃度检查延迟的开始并不取决于pod第一次准备就绪。一旦它们开始，它们都会在豆荚的生命中奔跑

您需要根据每个检查的角色以及如何实施检查来评估延迟的设置

就绪探测检查应用程序是否准备好为请求提供服务。它最初用于确定pod是否已正确启动并准备就绪，但随后也用于确定pod IP是否应在任何时间段内从端点集中移除，如果检查设置为再次通过，则可能会在稍后添加回pod IP，同时应用程序再次准备好处理请求

活动性探测器检查应用程序是否仍在工作。它用于检查在pod中运行的应用程序是否仍在运行，以及是否正常工作。如果探针持续出现故障，pod将关闭，并启动一个新的pod进行更换

因此，使活动性检查的延迟大于就绪性检查的延迟是非常合理的，特别是在初始启动阶段，活动性检查将失败。你不希望pod在启动时间很长的时候被杀死

您可能还需要查看周期和成功/失败阈值

---

总的来说，很难给出一个固定的规则，因为它取决于您的应用程序。

我想您的意思是活跃度检查要大于就绪度检查。谢谢，这样pod就能够在就绪度健康检查完成后为请求提供服务；即使活动性检查尚未完成。只有准备就绪检查用于确定pod是否已正确启动，以便它能够接收流量。也就是说，如果在这段时间内活性检查失败，豆荚仍然会被杀死。因此，为什么将活动性检查延迟到通常知道应用程序应该已经启动的时间之后，会更安全。