• 健康检查
    • 被动健康检查
    • 连接池交互
    • HTTP健康检查过滤器
    • 主动健康检查(快速失败)
    • 健康检查身份识别
  • 返回

    健康检查

    主动健康检查是以每个上游服务群集进行配置。如服务发现部分所述,主动健康检查与SDS服务发现配合使用。但是,即使使用其他服务发现方式,也有相应需要进行主动健康检查的情况。Envoy支持三种不同类型的健康检查以及相应设置(检查时间间隔,因故障标记主机不健康,成功之后标记主机健康等):

    • HTTP:HTTP健康检查期间,Envoy将向上游主机发送HTTP请求。如果主机健康,预计会有200返回码。如果上游主机想立即通知下游主机不再向其转发流量,则返回503返回码。

    • L3/L4:在L3/L4健康检查期间,Envoy会向上游主机发送一个可配置的报文。如果主机期望被认为是健康的,则在响应中回应相应的报文。Envoy也支持只连接L3/L4健康检查。

    • Redis:Envoy将发送一个Redis PING命令,并期待一个PONG响应。上游Redis服务器可以使用PONG以外的任何其他响应,来立即触发的健康检查失败。

    被动健康检查

    Envoy还支持通过检测异常值,来进行被动健康检查。

    连接池交互

    浏览此处获取更多信息。

    HTTP健康检查过滤器

    当部署Envoy网格并在集群之间进行主动健康检查时,会生成大量健康检查的流量。Envoy提供一个可配置HTTP健康检查过滤器,并安装在HTTP监听器中。这个过滤器有几种不同的操作模式:

    • 不通过:在此模式下,健康检查请求永远不会传递到本地服务。Envoy将根据服务器当前的耗尽状态,以200或503响应。

    • 通过:在这种模式下,Envoy会将每个健康检查请求传递给本地服务。预计该服务将返回200或503取决于其健康状况。

    • 通过缓存:在这种模式下,Envoy会将健康检查请求传递给本地服务,但是会将结果缓存一段时间。随后在缓存有效时间内,进行的健康检查都会从缓存获取结果。当缓存超时后,下一个健康检查请求将被传递给本地服务。在使用较大的Envoy网格时,这是推荐的操作模式。Envoy使用持久性连接进行健康检查,健康检查请求对Envoy本身的成本很低。因此,这种操作模式产生了每个上游主机的健康状态的最终一致的视图,而没有使大量的健康检查请求压倒本地服务。

    进一步阅读:

    • 健康检查过滤器配置
    • 健康检查失败管理端口(/healthcheck/fail)
    • 健康检查成功管理端口(/healthcheck/ok)

    主动健康检查(快速失败)

    当使用主动健康检查和被动健康检查(异常检测)时,通常使用较长的健康检查间隔来避免大量的主动健康检查流量。在这种情况下,在使用健康检查失败管理端口时,对能够快速排除上游主机,仍然很有用。为了支持这个,路由器过滤器将响应x-envoy-immediate-health-check-fail头。如果此报头由上游主机设置,则Envoy将立即将主机标记为主动健康检查失败。请注意,只有在主机集群中配置了主动健康检查,才会出现此情况。如果Envoy已通过健康检查失败管理端口标记为失败,则运行状况检查过滤器将自动设置此标头。

    健康检查身份识别

    只要验证上游主机对特定健康检查URL的响应,并不一定意味着上游主机是有效的。例如,在云自动扩展或容器环境中,使用最终一致的服务发现时,主机可能会消失,然后以相同的IP地址返回,但会以不同的主机类型返回。解决这个问题的一个办法是为每个服务类型设置不同的HTTP健康检查URL。这种方法的缺点是使得整体配置变得更加复杂,因为每个健康检查URL都是完全自定义的。

    Envoy的HTTP健康检查支持service_name选项。如果设置了此选项,运行健康检查程序会将x-envoy-upstream-healthchecked-cluster响应头域的值与service_name进行比较。如果值不匹配,健康检查不通过。上游运行状况检查过滤器会将x-envoy-upstream-healthchecked-cluster附加到响应头域。附加值由—service-cluster命令行选项确定。

    返回

    • 架构介绍
    • 简介
    • 首页目录