url - 健康检查是否应该调用其他应用健康检查

Question

我有两个我控制的 API A 和 B，并且都进行了就绪性和 liveness 健康检查。 A 依赖于 B。

A
/foo - This endpoint makes a call to /bar in B
/status/live
/status/ready

B
/bar
/status/live
/status/ready

由于依赖关系，A 的就绪健康检查是否应该调用 API B 的就绪健康检查？

Answer 1

如果服务 A 可以服务于业务请求，则它已准备就绪。因此，如果能够到达 B 是它需要做的一部分(看起来确实如此)，那么它应该检查 B。

让 A 检查 B 的一个好处是您可以 fail fast on a bad rolling upgrade .假设您的 A 配置错误，因此升级为 B 提供了错误的连接详细信息 - 可能 B 的服务名称作为环境变量注入(inject)，并且新版本有错字。如果您的 A 实例在启动时检查到 Bs，那么您可以更轻松地确保升级失败并且没有流量流向新配置错误的 Pod。有关更多信息，请参阅 https://medium.com/spire-labs/utilizing-kubernetes-liveness-and-readiness-probes-to-automatically-recover-from-failure-2fe0314f2b2e

A 检查 B 的事件端点或任何最小可用性端点而不是 B 的就绪端点通常就足够了。这是因为 Kubernetes 将是 checking B's readiness probe for you anyway因此，A 可以到达的任何 B 实例都将是一个就绪实例。如果 B 的 readiness endpoint performs more checks than the liveness one 调用 B 的事件端点而不是准备状态，则可能会有所不同。 .请记住，kubernetes 会定期调用这些探测器 - readiness as well as liveness - they both have a period .区别在于 Pod 是退出服务流量(如果准备失败)还是重新启动(如果事件失败)。你不想做end-to-end transaction checks ，您希望这些检查包含最少的逻辑并且不会消耗过多的负载。

如果 A 的 readiness 实现中的代码进行检查而不是在 k8s 级别(在 Pod 规范本身中)进行检查，则更可取。最好在 k8s 级别执行此操作，因为理想情况下您想知道在容器中运行的代码确实可以连接。

检查依赖服务的另一种方法可用is with a check in an initContainer .使用 initContainers 可以避免在启动期间看到多次重启(通过确保正确的顺序)，但是通过探针对依赖项进行检查可以更深入(如果在应用程序的代码中实现)并且探针将在启动后继续定期运行。因此，两者都使用可能是有利的。

小心检查其他服务是否准备就绪，因为它可能导致级联不可用。例如，如果一个后端短暂地出现故障并且前端正在对其进行探测，那么前端也将变得不可用，因此将无法显示良好的错误消息。您可能希望从简单的探测开始，然后小心地增加复杂性。