Kubernetes 中 Consul 服务 TTL 健康检查的替代方案答案

【问题标题】：An alternative to Consul service TTL health check in KubernetesKubernetes 中 Consul 服务 TTL 健康检查的替代方案
【发布时间】：2020-04-24 11:03:32
【问题描述】：

Consul 有一个 TTL 健康检查，它的状态应该通过 HTTP 接口定期更新。从 akka.net 微服务中，我们向已注册的 Consul 服务端点执行 GET 请求，以重置 TTL 计时器并在 Consul 服务仪表板中保持生命。

Kubernetes 有类似的东西吗？不是对pod_ip:port 执行请求的活跃度/就绪度探测，而是等待来自正在运行的应用程序的请求。例如，我们不仅要监控在某个端口上运行的 AKKA 应用程序，还要确保参与者系统中的每个参与者都是健康的。

谢谢！

【问题讨论】：

您可以创建一个脚本来从 pod 内部执行 HTTP GET 请求。你能提供一个完整的例子来说明这种交流吗？另外，Consul 是否在 kubernetes 集群中运行？请提供有关完整架构的更多信息，以便为您提供更好的答案。
嗨@willrof，我们正在迁移到码头工人并希望完全摆脱使用Consul。目前，我们有这样的逻辑，即从参与者向 Consul 服务发送 GET 请求。但我们希望配置 EKS 以在某些参与者停止更新其状态（由于某种原因卡住）时重新启动 pod，而无需重构应用程序代码（或最小化它）。

标签： kubernetes consul kubernetes-health-check

【解决方案1】：

Kubernetes 想要探测应用程序（使用活跃度和就绪度探测），而应用程序想要发送它的 TTL 心跳信号以向 Consul 代理等发出活跃度信号。

协调两种运行状况检查策略的一种方法是在应用程序的 pod 中运行一个特殊的 sidecar health check server。这样的 sidecar 服务器将位于应用程序和 kubelet 之间，并会处理应用程序的 TTL 心跳以更新其内部状态，并注意应用程序是否还活着。只要是这种情况，它就会向HTTP probes of Kubernetes 回复 200 OK。否则，它会向 Kubernetes 回复 200-300 范围之外的代码，以表明应用程序不健康。

Consul 代理本身可以作为这样的 sidecar 健康检查服务器的一部分。它的HTTP health check API 以 JSON 对象的形式返回应用程序的 TTL-liveness 状态。所需要做的就是将状态转换为适当的 HTTP 返回码。但是使用 Consul 代理是完全可选的：sidecar 当然可以自己处理 TTL 心跳。

【讨论】：

是的，这是个好主意，但我们想摆脱使用 Consul。