Kubernetes探测器的实现策略

Question

我正在努力为Kubernetes的产品探测定义一个合理的实现策略。深入研究现有的指导方针，包括官方文档和实地报告，我无法在生态系统中找到一种具有共识的共同方法；这很可能是预料之中的。

下面是我计划实现的探测定义规则：

就绪探测：为处理传入网络流量的服务启用它。

问:在任何其他用例中，我都应该考虑服务的准备状态探测吗？

活性探针：这对我来说是最难的了。作为一个规则，我想到的是:默认情况下不要定义它，只对检测到死锁的场景中的服务手动启用它，直到修复这些bug为止。我不认为这是一种健康的方法，只是假设一个服务会死锁，并让活动探测来处理它。第一个原因是很难从探测中识别服务死锁，第二个原因是它会导致错误无法解决。

问:还有其他的用例，我应该考虑使用活性探针吗？

启动探测：只有在该服务上启用活性探测时才启用它。

问:如果没有定义活性探针，定义启动探针有什么好处吗？

Answer 1

问题:如果没有定义活性探针，那么定义启动探针有什么好处吗？

我看不出定义没有活性的公正启动探针有什么好处。启动探针是用来保护启动缓慢的吊舱的。

问题:我应该考虑活性探针的其他用例吗？

如果服务依赖于DB或任何其他服务，并且在后端服务代码中，则有一个函数或端点来检查是否可以将其用作活性探测。您是对的，在这种情况下，留下错误的地址。

保持活性探针的卖点是，如果它失败了，它将自动重新启动容器POD，而就绪探测只是将状态从0/1更改为处理流量。

如果您不指定活动探测，它只会根据PID来决定容器状态。

如果您使用的是bash/sh，那么您可能不希望PID 1跟踪，而是希望在该活性探测中跟踪子进程PID 2。