健康检查

可以在每个上游集群的基础上配置主动健康检查。如服务发现部分所述，主动健康检查和 EDS 服务发现类型是相辅相成的。但是，即使使用其他服务发现类型，也有一些场景需要主动健康检查。Envoy 支持三种不同类型的健康检查，以及各种设置（检查间隔、标记主机为不健康之前所需的失败次数、标记主机为健康之前所需的成功次数等）。

• HTTP: 在 HTTP 健康检查期间，Envoy 将向上游主机发送 HTTP 请求。默认情况下，如果主机健康，它会期望收到 200 响应。预期和可重试的响应代码是可配置的。如果上游主机想要立即通知下游主机不再将流量转发到它，它可以返回非预期或不可重试的状态代码（默认情况下为任何非 200 代码）。

• gRPC: 在 gRPC 健康检查期间，Envoy 将向上游主机发送 gRPC 请求。默认情况下，如果主机健康，它会期望收到 200 响应。gRPC 健康检查是此处可配置的。

• L3/L4: 在 L3/L4 健康检查期间，Envoy 将向上游主机发送可配置的字节缓冲区。如果主机被认为健康，它会期望在响应中回显字节缓冲区。Envoy 还支持仅连接 L3/L4 健康检查。

• Redis: Envoy 将发送 Redis PING 命令并期望收到 PONG 响应。上游 Redis 服务器可以响应任何非 PONG 内容，以导致立即的主动健康检查失败。可选地，Envoy 可以对用户指定的键执行 EXISTS 操作。如果键不存在，则视为通过健康检查。这允许用户通过将指定键设置为任何值并等待流量耗尽，来将 Redis 实例标记为维护状态。请参阅 redis_key。

• Thrift: Envoy 将发送 Thrift 请求并期望收到成功响应。上游主机也可以响应异常，以导致健康检查失败。请参阅 thrift。

健康检查在为集群指定的传输套接字上进行。这意味着，如果集群使用启用了 TLS 的传输套接字，则健康检查也将通过 TLS 进行。用于健康检查连接的 TLS 选项可以指定，这在相应的上游使用基于 ALPN 的FilterChainMatch（对健康检查和数据连接使用不同的协议）时非常有用。

每个集群成员健康检查配置

如果为上游集群配置了主动健康检查，则可以通过设置HealthCheckConfig（位于每个定义的LocalityLbEndpoints的LbEndpoint的Endpoint中）为每个注册的成员指定特定的附加配置。

设置健康检查配置以设置集群成员的替代健康检查地址和端口的示例如下：

load_assignment:
  endpoints:
  - lb_endpoints:
    - endpoint:
        health_check_config:
          port_value: 8080
          address:
            socket_address:
              address: 127.0.0.1
              port_value: 80
        address:
          socket_address:
            address: localhost
            port_value: 80

健康检查事件日志记录

Envoy 可以通过在HealthCheck 配置 event_log_path中指定日志文件路径，来选择性地生成每个健康检查器的弹出和添加事件的日志。该日志被构建为HealthCheckEvent 消息的 JSON 转储。

注意：HealthCheck 配置 event_log_path已弃用，取而代之的是HealthCheck event_logger 扩展。event_log_path用于文件接收器扩展的 JSON 转储。

创建了一个新的事件接收器扩展目录 envoy.health_check.event_sinks，并且可以在此处找到 API。

可以通过将always_log_health_check_failures 标志设置为 true，将 Envoy 配置为记录所有健康检查失败事件。

被动健康检查

Envoy 还通过异常检测支持被动健康检查。

连接池交互

有关更多信息，请参阅此处。

HTTP 健康检查过滤器

当 Envoy 网格部署了集群之间的主动健康检查时，会生成大量的健康检查流量。Envoy 包含一个 HTTP 健康检查过滤器，可以安装在配置的 HTTP 监听器中。该过滤器能够以几种不同的操作模式运行。

• 不通过: 在此模式下，健康检查请求永远不会传递给本地服务。Envoy 将根据服务器的当前排空状态返回 200 或 503。

• 不通过，根据上游集群健康状况计算: 在此模式下，健康检查过滤器将根据一个或多个上游集群中至少指定百分比的服务器是否可用（健康+降级），返回 200 或 503。（但是，如果 Envoy 服务器处于排空状态，它将返回 503，无论上游集群健康状况如何）。

• 通过: 在此模式下，Envoy 将将每个健康检查请求传递给本地服务。本地服务应根据其健康状态返回 200 或 503。

• 通过，并带有缓存: 在此模式下，Envoy 将将健康检查请求传递给本地服务，但随后将结果缓存一段时间。后续的健康检查请求将在达到缓存时间之前返回缓存的值。当达到缓存时间时，下一个健康检查请求将传递给本地服务。这是在操作大型网格时推荐的操作模式。Envoy 使用持久连接进行健康检查流量，并且健康检查请求对 Envoy 本身几乎没有成本。因此，这种操作模式在不使用大量的健康检查请求来压倒本地服务的情况下，可以获得最终一致的每个上游主机的健康状态视图。

进一步阅读

• 健康检查过滤器配置。

• /healthcheck/fail 管理端点。

• /healthcheck/ok 管理端点。

主动健康检查快速失败

当使用主动健康检查以及被动健康检查（异常检测）时，通常使用较长的健康检查间隔以避免大量的主动健康检查流量。在这种情况下，能够在使用 /healthcheck/fail 管理端点时快速清空上游主机仍然很有用。为了支持这一点，路由器过滤器 _以及_ HTTP 主动健康检查器将响应 x-envoy-immediate-health-check-fail 头部。如果此头部由上游主机设置，Envoy 将立即将主机标记为主动健康检查失败并 排除 在负载均衡之外。请注意，这仅在主机的集群已配置了主动健康检查 时 才会发生。 健康检查过滤器 将在 Envoy 通过 /healthcheck/fail 管理端点被标记为失败时自动设置此头部。

健康检查标识

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

Envoy HTTP 健康检查器支持 service_name_matcher 选项。如果设置了此选项，健康检查器还会将 x-envoy-upstream-healthchecked-cluster 响应头部的值与 service_name_matcher 进行比较。如果值不匹配，则健康检查不会通过。上游健康检查过滤器将 x-envoy-upstream-healthchecked-cluster 追加到响应头部。追加的值由 --service-cluster 命令行选项确定。

性能下降的健康状况

当使用 HTTP 健康检查器时，上游主机可以返回 x-envoy-degraded 以通知健康检查器主机性能下降。请参阅 此处 以了解这将如何影响负载均衡。