Google Cloud 为 Google Cloud 负载均衡器后端、Cloud Service Mesh 后端、 和托管式实例组的基于应用的自动修复提供可配置的健康检查。本文档介绍了关键健康检查概念。
除非另有说明，否则 Google Cloud 健康检查是通过根据健康检查资源中指定的参数连接到后端的专用软件任务实现的。每次连接尝试称为一次“探测”。 Google Cloud 会记录每次探测是成功还是失败。
系统会根据指定的连续成功或失败探测次数（可配置），评估每个后端的整体健康状况。在配置的次数内成功做出响应的后端会被视为运行状况良好，而未能在指定的次数内成功做出响应的后端则会被视为不健康。
每个后端的整体运行状况决定了其是否有资格接收新的请求或连接。您可以配置成功探测标准。健康检查原理部分会对此进行详细介绍。
由专用软件任务实现的健康检查使用未在 Virtual Private Cloud (VPC) 网络中定义的特殊路由。如需了解详情，请参阅健康检查的路径。
健康检查类别、协议和端口
健康检查具有类别和协议。这两种类别是健康检查和旧版健康检查及其支持的协议，如下所示：
健康检查
- 区域（gRPC、TCP、SSL、HTTP、HTTPS 或 HTTP/2）
- 区域级 gRPC（使用 TLS）（预览版）
- 全球（gRPC、TCP、SSL、HTTP、HTTPS 或 HTTP/2）
- 全球 gRPC（使用 TLS）（预览版）
旧式健康检查：
协议和端口决定了健康检查探测的完成方式。例如，健康检查可以在 TCP 端口 80 上使用 HTTP 协议，也可以在实例组中的命名端口上使用 TCP 协议。
您无法将旧式健康检查转换为健康检查，也无法将健康检查转换为旧式健康检查。
选择健康检查
健康检查必须与负载均衡器 （或 Cloud Service Mesh） 的类型及后端类型兼容。选择健康检查时要考虑的因素如下：
- 类别：健康检查或旧式健康检查。 只有基于目标池的外部直通式网络负载均衡器需要旧式健康检查。对于所有其他产品，您需要定期健康检查。
- 协议： Google Cloud 用于探测后端的协议。使用健康检查（或旧式健康检查）时，最好使用协议与负载均衡器的后端服务或目标池使用的协议相匹配的检查。 不过，健康检查协议和负载均衡器协议并不一定要相同。
- 端口指定： Google Cloud 用于协议的端口。
您必须为健康检查指定端口。健康检查有两种端口指定方法（
--port和--use-serving-port）。对于旧式健康检查，只有一种方法 (--port)。如需详细了解每个负载均衡器的健康检查端口要求，请参阅端口指定标志。
下一部分介绍了每种类型的负载均衡器和后端的有效健康检查选择。
负载均衡器指南
下表显示了每种负载均衡器类型支持的健康检查类别和范围。
| 负载均衡器 | 健康检查类别和范围 |
|---|---|
|
全球外部应用负载均衡器 传统应用负载均衡器 * 全球外部代理网络负载均衡器 传统代理网络负载均衡器 跨区域内部应用负载均衡器 跨区域内部代理网络负载均衡器 |
健康检查（全球） |
|
区域级外部应用负载均衡器 区域级内部应用负载均衡器 区域级内部代理网络负载均衡器 区域级外部代理网络负载均衡器 |
健康检查（区域） |
| 外部直通式网络负载均衡器 | 基于后端服务的负载均衡器：健康检查（区域） 基于目标池的负载均衡器：旧式健康检查 |
| 内部直通式网络负载均衡器 | 健康检查（全球或区域） |
| 负载均衡器模式 | 支持旧版健康检查 |
|---|---|
全球外部应用负载均衡器 传统应用负载均衡器 |
是，如果同时满足以下两个条件：
|
| 区域级外部应用负载均衡器 | 否 |
其他使用说明
对于虚拟机实例组后端，健康检查仅针对已启动的虚拟机实例执行。已停止的虚拟机实例不会收到健康检查数据包。
对于内部直通式网络负载均衡器，您只能为后端服务的协议使用
TCP或UDP。如果您通过内部直通网络负载均衡器后的虚拟机提供 HTTP 流量，那么使用 HTTP 协议进行健康检查是一种有意义的做法。基于目标池的外部直通式网络负载均衡器必须使用旧版 HTTP 健康检查。 它不能使用旧式 HTTPS 健康检查或任何非旧式健康检查。如果您使用基于目标池的外部直通式网络负载均衡器对 TCP 流量进行负载均衡，则需要在负载均衡虚拟机上运行 HTTP 服务，以便这些虚拟机能够响应健康检查探测。
对于几乎所有其他负载均衡器类型，您必须使用常规的非旧式健康检查，其中协议与负载均衡器的后端服务协议相匹配。对于使用 gRPC 协议的后端服务，请仅使用 gRPC 或 TCP 健康检查。不要使用 HTTP(S) 或 HTTP/2 健康检查。
使用混合 NEG 后端的某些基于 Envoy 的负载均衡器不支持 gRPC 健康检查。如需了解详情，请参阅混合 NEG 概览。
使用 Cloud Service Mesh 进行健康检查
将健康检查与 Cloud Service Mesh 搭配使用时，请注意以下行为差异。
使用 Cloud Service Mesh，
INTERNET_FQDN_PORT和NON_GCP_PRIVATE_IP_PORT类型的网络端点的健康检查行为与其他类型的网络端点的健康检查行为不同。Cloud Service Mesh 对 Envoy 代理进行编程，以执行互联网 NEG（INTERNET_FQDN_PORT端点）和混合 NEG（NON_GCP_PRIVATE_IP_PORT端点）的健康检查，而不是使用专用软件任务。Envoy 支持以下健康检查协议：
- HTTP
- HTTPS
- HTTP/2
- TCP
当 Cloud Service Mesh 与 Service Directory 集成，并且您将 Service Directory 服务绑定到 Cloud Service Mesh 后端服务时，您不能在后端服务上设置健康检查。
健康检查原理
以下部分介绍了健康检查原理。
探测
创建健康检查或创建旧式健康检查时，您可以指定以下标志或接受其默认值。您创建的每项健康检查或旧式健康检查由多重探测实现。这些标志控制每个探测对实例组中的实例或可用区 NEG 中的端点进行评估的频率。
您不能针对每个后端分别配置健康检查的设置。健康检查与整个后端服务关联。对于基于目标池的外部直通式网络负载均衡器，旧版 HTTP 健康检查与整个目标池关联。因此，探测参数对于给定后端服务或目标池所引用的全部后端来说都是相同的。
| 配置标志 | 用途 | 默认值 |
|---|---|---|
检查间隔时间check-interval |
检查间隔时间是指从一个探测器发出的一次探测开始到由同一探测器发出的下一次探测开始之间的时间量。该时间以秒为单位。 | 5s（5 秒） |
超时timeout |
超时是指 Google Cloud 等待探测响应的时长。其值必须小于或等于检查间隔时间。该时间以秒为单位。 | 5s（5 秒） |
探测 IP 地址范围和防火墙规则
为了使健康检查正常运行，您必须创建入站 allow 防火墙规则，以便来自 Google Cloud 探测器的流量能够连接到您的后端。如需查看相关说明，请参阅创建必需的防火墙规则。
下表显示了每个负载均衡器允许的来源 IP 范围：
| 产品 | 健康检查探测来源 IP 范围 |
|---|---|
|
对于进入后端的 IPv6 流量：
|
对于进入后端的 IPv6 流量：
|
|
|
|
| 外部直通式网络负载均衡器3 |
对于进入后端的 IPv4 流量：
对于进入后端的 IPv6 流量：
|
| 内部直通式网络负载均衡器 |
对于进入后端的 IPv4 流量：
对于进入后端的 IPv6 流量：
|
| 具有互联网 NEG 后端和混合 NEG 后端的 Cloud Service Mesh | 运行 Envoy 软件的虚拟机的 IP 地址 如需查看示例配置，请参阅 Cloud Service Mesh 文档 |
1 混合 NEG 不需要允许来自 Google 健康检查探测范围的流量。但是，如果您在单个后端服务中结合使用混合和可用区级 NEG，则需要允许来自可用区级 NEG 的 Google 健康检查探测范围的流量。
2 对于区域级互联网 NEG，健康检查是可选的。来自使用区域级互联网 NEG 的负载均衡器的流量源自代理专用子网，然后（使用 Cloud NAT）经过 NAT 转换为手动或自动分配的 NAT IP 地址。此流量包括健康检查探测以及从负载均衡器发送到后端的用户请求。如需了解详情，请参阅区域级 NEG：使用 Cloud NAT 网关。
3 基于目标池的外部直通式网络负载均衡器仅支持 IPv4 流量，并且可能通过元数据服务器代理健康检查。在此示例中，健康检查数据包源与元数据服务器的 IP 地址匹配：169.254.169.254。您无需创建防火墙规则即可允许来自元数据服务器的流量。始终允许来自元数据服务器的数据包。
探测 IP 地址范围的安全注意事项
在规划健康检查和必要的防火墙规则时，请考虑以下信息：
探测 IP 范围属于 Google。 Google Cloud 使用不在您的 VPC 网络内但在 Google 的生产网络内的特殊路由，在健康检查探测器和后端虚拟机之间进行通信。
探测 IP 范围仅在 Google 的生产网络内用于健康检查和负载均衡。 Google Cloud 和 Google 的生产网络通过强制执行以下操作来防止探测 IP 范围被用于任何其他用途：
如果来自互联网的数据包伪造了探测 IP 地址范围内的来源 IP 地址，Google 边缘路由器会丢弃这些数据包。
您不能将探测 IP 范围用于 VPC 网络中的子网。如需了解详情，请参阅禁止的 IPv4 子网范围和 IPv6 规范。
防火墙规则的重要性
Google Cloud 要求您创建必要的入站 allow 防火墙规则，以允许来自探测器的流量传输到您的后端：
探测 IP 范围是Google Cloud 探测器使用的可能 IP 地址的完整集合。如果使用
tcpdump或类似工具，您可能无法观察到来自所有探测 IP 地址范围内所有 IP 地址的流量。最佳做法是，创建允许所有探测 IP 范围作为来源的入站防火墙规则。 Google Cloud 可以自动实现新的探测器，但不发送通知。最佳实践是将这些规则限制为仅使用与健康检查所使用的协议和端口匹配的协议和端口。
如果您没有允许健康检查的入站 allow 防火墙规则，则隐式 deny 入站规则会阻止入站流量。如果探测器无法与您的后端进行通信，负载均衡器会认为您的后端运行状况不佳。
多重探测和频率
Google Cloud 从多个称为探测器的冗余系统发送健康检查探测。探测器使用特定的来源 IP 范围。Google Cloud 并不仅仅依赖于一个探测器来实现健康检查，也就是说，多个探测器会同时评估实例组后端中的实例或者可用区 NEG 后端中的端点。如果某个探测器发生故障，则Google Cloud 会继续跟踪后端健康状况。
您为健康检查配置的时间间隔和超时设置会应用于每个探测器。对于给定的后端，软件访问日志和 tcpdump 中显示的探测频率会比您配置的设置值更高。
这是正常现象，您无法配置 Google Cloud 用于健康检查的探测器数量。不过，您可以通过考虑以下几个因素来估算同时执行多重探测所带来的影响。
如需估算每个后端服务的探测频率，请考虑以下事项：
每个后端服务的基本频率。每项健康检查都有一个关联的检查频率，此频率与配置的检查时间间隔成反比：
1⁄（检查间隔时间）
将健康检查与后端服务相关联时，您需要为该后端服务中的后端确立用于每个探测器的基本频率。
探测比例系数。后端服务的基本频率乘以 Google Cloud 使用的并发探测器数量。此数值可能不同，但通常介于 5 到 10 之间。
内部直通式网络负载均衡器的多个转发规则。如果您配置了多个指向同一区域级内部后端服务的内部转发规则（每个规则具有不同的 IP 地址），则Google Cloud 会使用多个探测器来检查各个 IP 地址。在这种情况下，请将每项后端服务的探测频率乘以配置的转发规则数。
外部直通式网络负载均衡器的多个转发规则。如果您配置了多个指向同一后端服务或目标池的转发规则，则 Google Cloud 会使用多个探测器来检查每一个 IP 地址。在这种情况下，请将每个后端虚拟机的探测频率乘以配置的转发规则数。
外部应用负载均衡器的多个目标代理。如果您有多个目标代理将流量定向到同一网址映射，则 Google Cloud 会使用多个探测器来检查与每个目标代理关联的 IP 地址。在这种情况下，请将每项后端服务的探测频率乘以配置的目标代理数。
外部代理网络负载均衡器和区域级内部代理网络负载均衡器的多个目标代理。如果您配置了多个目标代理以将流量定向到同一后端服务，则Google Cloud 会使用多个探测器来检查与每个目标代理关联的 IP 地址。在这种情况下，请将每项后端服务的探测频率乘以配置的目标代理数。
对各个后端服务进行求和。如果某个后端供多个后端服务使用，那么后端实例的探测频率就是各后端服务的健康检查频率之和。
使用可用区 NEG 后端时，确切的健康检查探测次数会更难以确定。例如，同一端点可以位于多个可用区 NEG 中；这些可用区 NEG 不一定具有相同的端点集，而且不同的端点可以指向同一个后端。
探测数据包的目标
下表显示了接收健康检查探针发送的数据包的网络接口和目标 IP 地址，具体视负载均衡器的类型而定。
对于外部直通式网络负载均衡器和内部直通网络负载均衡器，应用必须绑定到负载均衡器的 IP 地址（或任何 IP 地址 0.0.0.0）。
| 负载均衡器 | 目标网络接口 | 目标 IP 地址 |
|---|---|---|
|
|
|
|
|
|
| 外部直通式网络负载均衡器 | 主要网络接口 (nic0) |
外部转发规则的 IP 地址。 如果多个转发规则指向同一个后端服务（对于基于目标池的外部直通式网络负载均衡器，则指向同一个目标池）， Google Cloud 会向每个转发规则的 IP 地址发送探测。 这会导致探测数量增加。 |
| 内部直通式网络负载均衡器 | 对于实例组后端和具有 GCE_VM_IP 端点的可用区级 NEG 后端，使用的网络接口都取决于后端服务的配置方式。如需了解详情，请参阅后端服务和网络接口。 |
内部转发规则的 IP 地址。 如果多个转发规则指向同一个后端服务，则 Google Cloud会向每个转发规则的 IP 地址发送探测。这会导致探测数量增加。 |
HTTP、HTTPS、HTTP/2 成功标准
HTTP、HTTPS 和 HTTP/2 健康检查始终要求在健康检查超时之前收到 HTTP 200 (OK) 响应代码。所有其他 HTTP 响应代码（包括重定向响应代码，如 301 和 302）均被视为健康状况不佳。
除了要求 HTTP 200 (OK) 响应代码之外，您还可以：
配置每个健康检查探测器，使其向特定的请求路径（而不是默认请求路径
/）发送 HTTP 请求。配置每个健康检查探测器，使其检查 HTTP 响应正文中是否存在预期的响应字符串。预期响应字符串必须仅包含可打印的单字节 ASCII 字符，并且这些字符位于 HTTP 响应正文的前 1,024 个字节内。
下表列出了适用于 HTTP、HTTPS 和 HTTP/2 健康检查的请求路径和响应标志的有效组合。
| 配置标志 | 探测器行为 | 成功标准 |
|---|---|---|
既未指定 --request-path 也未指定 --response
|
探测器使用 / 作为请求路径。 |
仅限 HTTP 200 (OK) 响应代码。 |
同时指定了 --request-path 和 --response
|
探测器使用配置的请求路径。 | HTTP 200 (OK) 响应代码和 HTTP 响应正文的前 1,024 个 ASCII 字符范围内的字符必须与预期的响应字符串匹配。 |
仅指定 --response
|
探测器使用 / 作为请求路径。 |
HTTP 200 (OK) 响应代码和 HTTP 响应正文的前 1,024 个 ASCII 字符范围内的字符必须与预期的响应字符串匹配。 |
仅指定 --request-path
|
探测器使用配置的请求路径。 | 仅限 HTTP 200 (OK) 响应代码。 |
SSL 和 TCP 成功标准
TCP 和 SSL 健康检查具有以下基本成功标准：
对于 TCP 健康检查，健康检查探测器必须在健康检查超时之前成功打开与后端的 TCP 连接。
对于 SSL 健康检查，健康检查探测器必须在健康检查超时之前成功打开与后端的 TCP 连接，并完成 TLS/SSL 握手。
对于 TCP 健康检查，必须通过以下任一方式关闭 TCP 连接：
- 通过健康检查探测器发送 FIN 或 RST（重置）数据包，或者
- 通过后端发送 FIN 数据包。如果后端发送 TCP RST 数据包，那么健康检查探测器已发送 FIN 数据包时，探测可能被视为不成功。
下表列出了适用于 TCP 和 SSL 健康检查的请求标志和响应标志的有效组合。请求标志和响应标志都必须仅包含可打印的单字节 ASCII 字符，每个字符串的长度不得超过 1,024 个字符。
| 配置标志 | 探测器行为 | 成功标准 |
|---|---|---|
既未指定 --request 也未指定 --response
|
探测器不发送任何请求字符串。 | 仅限基本成功标准。 |
同时指定了 --request 和 --response
|
探测器发送已配置的请求字符串。 | 基本成功标准并且探测器收到的响应字符串必须与预期响应字符串完全匹配。 |
仅指定 --response
|
探测器不发送任何请求字符串。 | 基本成功标准并且探测器收到的响应字符串必须与预期响应字符串完全匹配。 |
仅指定 --request
|
探测器发送已配置的请求字符串。 | 仅基本成功标准（不检查任何响应字符串）。 |
gRPC 成功标准
gRPC 健康检查仅与 gRPC 应用、 Google Cloud 负载均衡器和 Cloud Service Mesh 搭配使用。 Google Cloud 支持两种类型的 gRPC 健康检查：
GRPC_WITH_TLS（预览版）健康检查用于对启用了 TLS 的 gRPC 后端进行健康检查。它们支持未经身份验证的 TLS 加密，这意味着健康检查不会验证服务器的身份。GRPC健康检查用于对不安全的 gRPC 后端进行健康检查。它们不支持身份验证和加密，因此无法用于启用了 TLS 的 gRPC 后端。
如果您使用的是 gRPC 健康检查（无论是否启用 TLS），请确保 gRPC 服务发送状态为 OK 且状态字段相应设置为 SERVING 或 NOT_SERVING 的 RPC 响应。
详情请参阅以下内容：
旧式健康检查成功标准
如果旧式健康检查探测收到的响应是 HTTP 200 OK，则探测被视为成功。所有其他 HTTP 响应代码（包括重定向 301、302）均被视为运行状况不佳。
运行状况
Google Cloud 使用以下配置标志来确定实现流量负载均衡的每个后端的整体健康状况。
| 配置标志 | 用途 | 默认值 |
|---|---|---|
运行状况良好判断阈值healthy-threshold |
运行状况良好判断阈值指定了要将之前运行状况不佳的后端视为运行状况良好所需满足的连续成功探测次数。 | 2 个探测的阈值。 |
运行状况不佳判断阈值unhealthy-threshold |
运行状况不佳判断阈值指定了要将之前运行状况不佳的后端视为运行状况不佳所需满足的连续失败探测次数。 | 2 个探测的阈值。 |
达到此健康状况良好判断阈值后，Google Cloud 会将后端视为健康状况良好。健康状况良好的后端可以接收新的连接。
达到健康状况不佳判断阈值后，Google Cloud 会将后端视为健康状况不佳。健康状况不佳的后端不能接收新的连接；但是，现有连接不会立即终止。这些连接会一直保持打开状态，直到发生超时情况或流量被舍弃。
现有连接可能无法返回响应，具体取决于导致探测失败的原因。如果运行状况不佳的后端能够再次达到运行状况良好判断阈值，则该后端就会被视为运行状况良好。
当所有后端健康状况不佳时，具体行为会有所不同，具体取决于您使用的负载均衡器的类型：
| 负载均衡器 | 所有后端运行状况都不正常时的行为 |
|---|---|
| 传统应用负载均衡器 | 当所有后端健康状况不佳时，向客户端返回 HTTP“502”状态代码。 |
|
全球外部应用负载均衡器 跨区域内部应用负载均衡器 区域级外部应用负载均衡器 区域级内部应用负载均衡器 |
当所有后端健康状况不佳时，向客户端返回 HTTP“503”状态代码。 |
| 代理网络负载均衡器 | 当所有后端健康状况都不佳时，终结新的客户端 TCP 连接。 |
| 内部直通式网络负载均衡器 基于后端服务的外部直通式网络负载均衡器 |
根据故障切换配置、后端权重和后端健康状况分配新连接。有关详情，请参阅： |
| 基于目标池的外部直通式网络负载均衡器 | 当所有后端健康状况不佳时，作为最后的补救措施，将流量分配到所有后端虚拟机。 |
补充说明
以下部分包含有关在 Google Cloud上使用健康检查的更多说明。
证书和健康检查
Google Cloud 健康检查探测器不会执行证书验证，即使是协议（SSL、HTTPS 和 HTTP/2）要求您的后端使用证书也一样，例如：
- 您可以使用自签名证书或由任何证书授权机构 (CA) 签名的证书。
- 已过期或尚未生效的证书均可接受。
CN或subjectAlternativeName特性都不需要与Host标头或 DNS PTR 记录匹配。
标头
使用任何协议的健康检查（但不是旧式健康检查）可让您使用 --proxy-header 标志来设置代理标头。
旧式健康检查以及使用 HTTP、HTTPS 或 HTTP/2 协议的健康检查可让您使用 --host 标志来指定 HTTP Host 标头。
如果您使用的是任何自定义请求标头，请注意，负载均衡器仅会向客户端请求添加这些标头，而不会向健康检查探测添加这些标头。如果后端需要将特定标头用于授权，而健康检查数据包中缺少该标头，则健康检查可能会失败。
示例健康检查
假设您使用以下设置设定了健康检查：
- 间隔时间：30 秒
- 超时：5 秒
- 协议：HTTP
- 运行状况不佳判断阈值：2（默认值）
- 运行状况良好判断阈值：2（默认值）
使用这些设置时，健康检查的行为如下：
- 多个冗余系统会同时使用健康检查参数进行配置。时间间隔和超时设置会应用到每个系统。如需了解详情，请参阅多重探测和频率。
每个健康检查探测器都会执行以下操作：
至少有一个健康检查探测系统满足下列条件时，后端就会被视为健康状况不佳：
- 未收到两个连续探测的
HTTP 200 (OK)响应代码。例如，连接可能被拒绝，或者连接或套接字可能超时。 - 收到两个不符合协议专用成功标准的连续响应。
- 未收到两个连续探测的
如果至少一个健康检查探测系统收到两个符合协议专用成功标准的连续响应，则后端会被视为运行状况良好。
在此示例中，每个探测器每隔 30 秒启动一次连接。两次探测器连接尝试间隔 30 秒，无论超时时长如何（也就是无论连接是否超时）。换句话说，超时时间必须始终小于或等于间隔时间，而且超时时间不会增加该间隔时间。
在本示例中，每个探测器的时间（以秒为单位）如下所示：
- t=0：启动探测 A。
- t=5：停止探测 A。
- t=30：启动探测 B。
- t=35：停止探测 B。
- t=60：启动探测 C。
- t=65：停止探测 C。