Google Cloud 为 Google Cloud 负载均衡器后端、Traffic Director 后端和代管实例组的基于应用的自动修复提供可配置的健康检查。本文档介绍了关键健康检查概念。
除非另有说明，否则 Google Cloud 健康检查是通过根据健康检查资源中指定的参数连接到后端的专用软件任务实现的。每次连接尝试称为一次“探测”。Google Cloud 会记录每次探测是成功还是失败。
系统会根据指定的连续成功或失败探测次数（可配置），评估每个后端的整体运行状况。在配置的次数内成功做出响应的后端会被视为运行状况良好，而未能在指定的次数内成功做出响应的后端则会被视为不健康。
每个后端的整体运行状况决定了其是否有资格接收新的请求或连接。您可以配置成功探测标准。健康检查原理部分会对此进行详细介绍。
由专用软件任务实现的健康检查使用未在 Virtual Private Cloud (VPC) 网络中定义的特殊路由。如需了解详情，请参阅负载均衡器返回路径。
健康检查类别、协议和端口
健康检查具有类别和协议。这两种类别是健康检查和旧版健康检查及其支持的协议，如下所示：
健康检查
旧式健康检查：
协议和端口决定了健康检查探测的完成方式。例如，健康检查可以在 TCP 端口 80 上使用 HTTP 协议，也可以在实例组中的命名端口上使用 TCP 协议。
您无法将旧式健康检查转换为健康检查，也无法将健康检查转换为旧式健康检查。
选择健康检查
健康检查必须与负载均衡器（或 Traffic Director）的类型及后端类型兼容。选择健康检查时要考虑的因素如下：
- 类别：健康检查或旧式健康检查。 只有基于目标池的外部直通式网络负载均衡器需要旧式健康检查。对于所有其他产品，您需要定期健康检查。
- 协议：Google Cloud 用于探测后端的协议。 使用健康检查（或旧式健康检查）时，最好使用协议与负载均衡器的后端服务或目标池使用的协议相匹配的检查。 不过，健康检查协议和负载均衡器协议并不一定要相同。
- 端口指定：Google Cloud 用于协议的端口。
您必须为健康检查指定端口。健康检查有两种端口指定方法（
--port和--use-serving-port）。对于旧式健康检查，只有一种方法 (--port)。
下一部分介绍了每种类型的负载均衡器和后端的有效健康检查选择。
负载均衡器指南
下表显示了每个负载均衡器和后端类型支持的类别、范围和端口指定。
| 负载均衡器 | 后端类型 | 健康检查类别和范围 | 端口指定 |
|---|---|---|---|
|
全球外部应用负载均衡器 传统应用负载均衡器 1 全球外部代理网络负载均衡器 传统代理网络负载均衡器 |
支持的 NEG | 健康检查（全球） |
|
| 实例组 | 健康检查（全球） |
|
|
| 区域级外部应用负载均衡器 | 支持的 NEG | 健康检查（区域） |
|
| 实例组 | 健康检查（区域） |
|
|
|
跨区域内部应用负载均衡器 跨区域内部代理网络负载均衡器 |
支持的 NEG | 健康检查（全球） |
|
| 实例组 | 健康检查（全球） |
|
|
|
区域级内部应用负载均衡器 区域级内部代理网络负载均衡器 区域级外部代理网络负载均衡器 |
支持的 NEG | 健康检查（区域） |
|
| 实例组 | 健康检查（区域） |
|
|
| 外部直通式网络负载均衡器 2 | 实例组 | 健康检查（区域） |
|
| 目标池中的 实例 |
旧式健康检查 （使用 HTTP 协议的全球健康检查） |
旧式健康检查仅支持端口号 (--port) 指定。 |
|
| 内部直通式网络负载均衡器 2 | 支持的 NEG | 健康检查（全球或区域） |
|
| 实例组 | 健康检查（全球或区域） |
|
| 负载均衡器模式 | 支持旧版健康检查 |
|---|---|
全球外部应用负载均衡器 传统应用负载均衡器 |
是，如果同时满足以下两个条件：
|
| 区域级外部应用负载均衡器 | 否 |
--use-serving-port 标志，因为与内部直通式网络负载均衡器和外部直通式网络负载均衡器一起使用的后端服务不会订阅任何已命名的端口。此外，内部直通式网络负载均衡器仅支持具有 GCE_VM_IP 端点并且缺少端口信息的可用区级 NEG。其他使用说明
对于内部直通式网络负载均衡器，您只能为后端服务的协议使用
TCP或UDP。如果您通过内部直通网络负载均衡器后的虚拟机提供 HTTP 流量，那么使用 HTTP 协议进行健康检查是一种有意义的做法。基于目标池的外部直通式网络负载均衡器必须使用旧版 HTTP 健康检查。 它不能使用旧式 HTTPS 健康检查或任何非旧式健康检查。如果您使用基于目标池的外部直通式网络负载均衡器对 TCP 流量进行负载均衡，则需要在负载均衡虚拟机上运行 HTTP 服务，以便这些虚拟机能够响应健康检查探测。
对于几乎所有其他负载均衡器类型，您必须使用常规的非旧式健康检查，其中协议与负载均衡器的后端服务协议相匹配。对于使用 gRPC 协议的后端服务，请仅使用 gRPC 或 TCP 健康检查。不要使用 HTTP(S) 或 HTTP/2 健康检查。
使用混合 NEG 后端的某些基于 Envoy 的负载均衡器不支持 gRPC 健康检查。如需了解详情，请参阅混合 NEG 概览。
使用 Traffic Director 进行健康检查
将健康检查与 Traffic Director 搭配使用时，请注意以下行为差异。
使用 Traffic Director，
INTERNET_FQDN_PORT和NON_GCP_PRIVATE_IP_PORT类型的网络端点的健康检查行为与其他类型的网络端点的健康检查行为不同。 Traffic Director 对 Envoy 代理进行编程，以执行互联网 NEG（INTERNET_FQDN_PORT端点）和混合 NEG（NON_GCP_PRIVATE_IP_PORT端点）的健康检查，而不是使用专用软件任务。Envoy 支持以下健康检查协议：
- HTTP
- HTTPS
- HTTP/2
- TCP
当 Traffic Director 与 Service Directory 集成，并且您将 Service Directory 服务绑定到 Traffic Director 后端服务时，您不能在后端服务上设置健康检查。
健康检查原理
以下部分介绍了健康检查原理。
探测
创建健康检查或创建旧式健康检查时，您可以指定以下标志或接受其默认值。您创建的每项健康检查或旧式健康检查由多重探测实现。这些标志控制每个探测对实例组中的实例或可用区 NEG 中的端点进行评估的频率。
您不能针对每个后端分别配置健康检查的设置。健康检查与整个后端服务关联。对于基于目标池的外部直通式网络负载均衡器，旧版 HTTP 健康检查与整个目标池关联。因此，探测参数对于给定后端服务或目标池所引用的全部后端来说都是相同的。
| 配置标志 | 用途 | 默认值 |
|---|---|---|
检查间隔时间check-interval |
检查间隔时间是指从一个探测器发出的一次探测开始到由同一探测器发出的下一次探测开始之间的时间量。该时间以秒为单位。 | 5s（5 秒） |
超时timeout |
超时表示 Google Cloud 等待探测响应的时间量。其值必须小于或等于检查间隔时间。该时间以秒为单位。 | 5s（5 秒） |
探测 IP 地址范围和防火墙规则
为了使健康检查正常运行，您必须创建入站 allow 防火墙规则，以便来自 Google Cloud 探测器的流量能够连接到您的后端。
下表显示了允许的来源 IP 地址范围：
| 产品 | 探测来源 IP 地址范围 | 防火墙规则示例 |
|---|---|---|
|
除外部直通式网络负载均衡器以外的其他所有产品的防火墙规则 | |
| 外部直通式网络负载均衡器 |
对于进入后端的 IPv4 流量：
对于进入后端的 IPv6 流量：
|
外部直通式网络负载均衡器的防火墙规则 |
| 内部直通式网络负载均衡器 |
对于进入后端的 IPv4 流量：
对于进入后端的 IPv6 流量：
|
内部直通式网络负载均衡器的防火墙规则 |
| 具有互联网 NEG 后端和混合 NEG 后端的 Traffic Director | 运行 Envoy 软件的虚拟机的 IP 地址 | 防火墙规则示例 |
1 对于混合 NEG，无需将 Google 的健康检查探测范围列入许可名单。但是，如果您在单个后端服务中结合使用混合和可用区级 NEG，则需要将可用区级 NEG 的 Google 健康检查探测范围列入许可名单。
2 对于区域级互联网 NEG，健康检查是可选的。来自使用区域级互联网 NEG 的负载均衡器的流量源自代理专用子网，然后（使用 Cloud NAT）经过 NAT 转换为手动或自动分配的 NAT IP 地址。此流量包括健康检查探测以及从负载均衡器发送到后端的用户请求。如需了解详情，请参阅区域级 NEG：使用 Cloud NAT 出站。
3 基于目标池的外部直通式网络负载均衡器仅支持 IPv4 流量，并且可能通过元数据服务器代理健康检查。在此示例中，健康检查数据包源与元数据服务器的 IP 地址匹配：169.254.169.254。您无需创建防火墙规则即可允许来自元数据服务器的流量。始终允许来自元数据服务器的数据包。
防火墙规则的重要性
Google Cloud 要求您创建必要的入站 allow 防火墙规则，以允许来自探测器的流量传输到您的后端。最佳做法是将这些规则限制为仅使用与健康检查所使用的协议和端口匹配的协议和端口。对于来源 IP 地址范围，请确保使用前面部分记录的探测 IP 地址范围。
如果您没有允许健康检查的入站 allow 防火墙规则，则隐式 deny 规则会阻止入站流量。如果探测器无法与您的后端进行通信，负载均衡器会认为您的后端运行状况不佳。
探测 IP 地址范围的安全注意事项
在规划健康检查和必要的防火墙规则时，请考虑以下信息：
探测 IP 地址范围属于 Google。Google Cloud 在您的 VPC 网络外部但在 Google 的生产网络中，使用特殊路由协调来自探测器的通信。
Google 使用探测 IP 地址范围向外部应用负载均衡器和外部代理网络负载均衡器发送健康检查探测。如果从互联网收到数据包，且数据包的来源 IP 地址是在探测 IP 地址范围内，则 Google 会丢弃数据包。这包括 Compute Engine 实例或 Google Kubernetes Engine (GKE) 节点的外部 IP 地址。
探测 IP 地址范围是 Google Cloud 探测器使用的可能 IP 地址的完整集合。如果使用
tcpdump或类似工具，您可能无法观察到来自所有探测 IP 地址范围内所有 IP 地址的流量。最佳做法是创建允许所有探测 IP 地址范围作为来源的入站防火墙规则。Google Cloud 可以自动实现新的探测器而不发送通知。
多重探测和频率
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) 状态代码。此外，您还可以执行以下操作：
您可以将 Google Cloud 探测器配置为向特定的请求路径发送 HTTP 请求。如果您未指定请求路径，则使用
/。如果您通过指定预期响应字符串来配置基于内容的健康检查，则 Google Cloud 必须在 HTTP 响应正文的前 1024 个字节内找到预期的字符串。
使用 HTTP、HTTPS 和 HTTP/2 协议的健康检查可以按以下组合方式使用请求路径和响应字符串标志。
| 配置标志 | 成功标准 |
|---|---|
请求路径request-path |
指定 Google Cloud 要向其发送健康检查探测请求的网址路径。 如果您省略了此标志，则 Google Cloud 会将探测请求发送到根路径 /。
|
响应response |
您可以选择使用响应标志来配置基于内容的健康检查。预期响应字符串必须小于或等于 1024 个 ASCII（单字节）字符。配置此标志后，Google Cloud 不但会收到 HTTP 200 (OK) 状态代码，还会在响应的前 1024 字节范围内找到该预期字符串。 |
SSL 和 TCP 成功标准
除非您指定预期响应字符串，否则在以下两个基本条件均为 True 时，使用 SSL 和 TCP 协议的健康检查探测会成功：
- 每个 Google Cloud 探测器都可以在配置的探测超时之前成功完成 SSL 或 TCP 握手。
- 对于 TCP 健康检查，TCP 会话会通过以下方式被正常终止：
- 后端；或
- Google Cloud 探测器在探测器的 TCP 会话仍处于已建立状态时发送的 TCP RST（重置）数据包
如果后端发送 TCP RST（重置）数据包以关闭 TCP 健康检查的 TCP 会话，则探测可能被视为不成功。当 Google Cloud 探测器已发起正常的 TCP 终止时，会发生这种情况。
如果您提供请求字符串和预期响应字符串，而且每个字符串的长度不应超过 1024 个 ASCII（单字节）字符，则可以创建基于内容的健康检查。如果您配置了预期响应字符串，那么只有在满足基本条件且返回的响应字符串与预期响应字符串完全匹配时，Google Cloud 才会认为探测成功。
使用 SSL 和 TCP 协议的健康检查可以按以下组合方式使用请求和响应标志。
| 配置标志 | 成功标准 |
|---|---|
请求和响应均不指定--request 和 --response 标志均不指定 |
如果满足基本条件，则 Google Cloud 会将探测视为成功。 |
同时指定了请求和响应--request 和 --response 标志均指定 |
Google Cloud 会发送您配置的请求字符串，并等待预期响应字符串。如果满足基本条件且返回的响应字符串与预期响应字符串完全匹配，则 Google Cloud 会将探测视为成功。 |
| 仅响应指定 仅 --response 标志指定 |
Google Cloud 会等待预期响应字符串，而且如果满足基本条件且返回的响应字符串与预期响应字符串完全匹配，Google Cloud 会将探测视为成功。 只有在后端会在 TCP 或 SSL 握手过程中自动发送响应字符串时，才能单独使用 --response。 |
| 仅请求指定 仅 --request 标志指定 |
Google Cloud 会发送您配置的请求字符串，并在满足基本条件时将探测视为成功。系统不会检查响应（如果有）。 |
gRPC 成功标准
如果您使用的是 gRPC 健康检查，请确保 gRPC 服务发送状态为 OK 且状态字段相应设置为 SERVING 或 NOT_SERVING 的 RPC 响应。
请注意以下几点：
- gRPC 健康检查仅可用于 gRPC 应用和 Traffic Director。
- gRPC 健康检查不支持 TLS。
详情请参阅以下内容：
旧式健康检查成功标准
如果旧式健康检查探测收到的响应是 HTTP 200 OK，则探测被视为成功。所有其他 HTTP 响应代码（包括重定向 301、302）均被视为运行状况不佳。
运行状况
Google Cloud 使用以下配置标志来确定实现流量负载均衡的每个后端的整体运行状况。
| 配置标志 | 用途 | 默认值 |
|---|---|---|
运行状况良好判断阈值healthy-threshold |
运行状况良好判断阈值指定了要将后端视为运行状况良好所需满足的连续成功探测次数。 | 2 个探测的阈值。 |
运行状况不佳判断阈值unhealthy-threshold |
运行状况不佳判断阈值指定了要将后端视为运行状况不佳所需满足的连续失败探测次数。 | 2 个探测的阈值。 |
达到此运行状况良好判断阈值后，Google Cloud 会将后端视为运行状况良好。运行状况良好的后端可以接收新的连接。
达到运行状况不佳判断阈值后，Google Cloud 会将后端视为运行状况不佳。运行状况不佳的后端不能接收新的连接；但是，现有连接不会立即终止。这些连接会一直保持打开状态，直到发生超时情况或流量被舍弃。
现有连接可能无法返回响应，具体取决于导致探测失败的原因。如果运行状况不佳的后端能够再次达到运行状况良好判断阈值，则该后端就会被视为运行状况良好。
当所有后端健康状况不佳时，具体行为会有所不同，具体取决于您使用的负载均衡器的类型：
| 负载均衡器 | 所有后端运行状况都不正常时的行为 |
|---|---|
| 传统应用负载均衡器 | 当所有后端健康状况不佳时，向客户端返回 HTTP“502”状态代码。 |
| 全局外部应用负载均衡器 区域外部应用负载均衡器 内部应用负载均衡器 |
当所有后端健康状况不佳时，向客户端返回 HTTP“503”状态代码。 |
| 代理网络负载均衡器 | 当所有后端运行状况不佳时终止客户端连接。 |
| 内部直通式网络负载均衡器和基于后端服务的外部直通网络负载均衡器 | 当所有后端都不健康并且未配置故障切换时，作为最后的补救措施，将流量分配到所有后端虚拟机。 如需详细了解此行为，请参阅内部直通式网络负载均衡器的流量分配和基于后端服务的外部直通式网络负载均衡器的流量分配。 |
| 基于目标池的外部直通式网络负载均衡器 | 当所有后端健康状况不佳时，作为最后的补救措施，将流量分配到所有后端虚拟机。 |
补充说明
以下部分包含有关在 Google Cloud 上使用健康检查的更多说明。
基于内容的健康检查
基于内容的健康检查就是其成功标准取决于对预期响应字符串的评估的健康检查。使用基于内容的健康检查来指示 Google Cloud 健康检查探测更全面地验证您的后端响应。
如需配置基于 HTTP、HTTPS 或 HTTP/2 内容的健康检查，请指定预期响应字符串以及选择性地定义请求路径。如需了解详情，请参阅 HTTP、HTTPS 和 HTTP/2 的成功标准。
如需配置基于 SSL 或 TCP 内容的健康检查，请指定预期响应字符串以及选择性地定义请求字符串。如需了解详情，请参阅 SSL 和 TCP 成功标准。
证书和健康检查
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。