运行状况检查概览

Google Cloud 提供了运行状况检查机制,用于确定实例组和区域网络端点组 (NEG) 等后端是否正确响应流量。本文讨论特定于 Google Cloud 负载平衡器和 Traffic Director 的运行状况检查概念。

Google Cloud 提供了全球运行状况检查系统和地区运行状况检查系统,这些系统可以按指定的时间间隔(可配置)定期连接到后端。每次连接尝试称为一次“探测”,而且每个运行状况检查系统都称为“探测器”。Google Cloud 会记录每次探测是成功还是失败。

运行状况检查可与负载平衡器和 Traffic Director 协同工作。Google Cloud 会根据指定的连续成功或失败探测次数(可配置),评估负载平衡器或 Traffic Director 中每个后端的整体运行状况。在配置的次数内成功做出响应的后端会被视为运行状况良好,而未能在指定的次数内成功做出响应的后端则会被视为运行状况不佳

Google Cloud 会根据每个后端的整体运行状况来确定该后端是否有能力接收新的请求或连接。除了能够配置探测频率和运行状况阈值之外,您还可以配置成功探测标准。运行状况检查原理部分会对此进行详细介绍。

Google Cloud 会使用未在您的 Virtual Private Cloud 网络中定义的特殊路由来执行运行状况检查。如需了解完整信息,请参阅负载平衡器返回路径

运行状况检查类别、协议和端口

Google Cloud 按类别和协议组织运行状况检查。

这两种类别是运行状况检查和旧式运行状况检查。每种运行状况检查类别都支持一组不同的协议,并且都允许指定用于执行运行状况检查的端口。协议和端口决定了 Google Cloud 运行状况检查系统与您的后端的通信方式。例如,您可以创建一个在 TCP 端口 80 上使用 HTTP 协议的运行状况检查,或者创建一个在实例组配置所指定的端口上使用 TCP 协议的运行状况检查。

Traffic Director 和大多数 Google Cloud 负载平衡器都需要新的运行状况检查,但网络负载平衡需要使用 HTTP 协议的旧式运行状况检查。您可以在下一部分(选择运行状况检查)中找到有关选择类别、协议和端口的具体指导信息。

您无法将旧式运行状况检查转换为运行状况检查,也无法将运行状况检查转换为旧式运行状况检查。

选择运行状况检查

运行状况检查必须与 Traffic Director 或负载平衡器的类型及该产品使用的后端类型(实例组或区域 NEG)兼容。您在创建运行状况检查时必须指定的三个要素如下:

  • 类别:运行状况检查或旧式运行状况检查(必须与负载平衡器兼容)。
  • 协议:定义 Google Cloud 系统定期探测后端所使用的协议。
  • 端口指定:定义运行状况检查的协议使用的端口。

本部分最后的指南总结了对给定负载平衡器类型和后端类型有效的一组运行状况检查类别、协议和端口指定方式。

如需了解各种负载平衡器支持的运行状况检查类型,请参阅运行状况检查

类别和协议

负载平衡器的类型及其使用的后端类型决定了运行状况检查的类别。网络负载平衡需要使用 HTTP 协议的旧式运行状况检查,而其他所有负载平衡器类型则需要定期运行状况检查。

您必须从运行状况检查类别所支持的协议列表中选择协议。最好使用与负载平衡器相同的协议;不过,这种做法并非强制性要求,也并非总是可行。例如,网络负载平衡器需要旧式运行状况检查,并且要求旧式运行状况检查使用 HTTP 协议,尽管网络负载平衡通常支持 TCP 和 UDP。对于网络负载平衡器,您必须在虚拟机实例上运行 HTTP 服务器,以便虚拟机实例能够响应运行状况检查的探测请求。

下表列出了运行状况检查类别以及各类别支持的协议。

运行状况检查类别 支持的协议
运行状况检查 • gRPC
• HTTP
• HTTPS
• HTTP/2(带 TLS)
• SSL
• TCP
旧式运行状况检查 • HTTP
• HTTPS

旧式 HTTPS 运行状况检查不受网络负载平衡器支持,并且不能与其他大多数负载平衡器类型搭配使用。

类别和端口指定

除了协议之外,您还必须为运行状况检查选择端口指定方式。非旧版运行状况检查提供了三种端口指定方法,而旧版运行状况检查仅提供了一种方法。对于每种负载平衡器类型,并非所有端口指定方法都适用。负载平衡器的类型及负载平衡器使用的后端类型决定了您可以使用的端口指定方法。

运行状况检查类别 端口指定方法及含义
运行状况检查 --port:指定 TCP 端口号
--use-serving-port
• 对于实例组,使用后端服务订阅的特定端口
• 对于区域 NEG,请使用在每个端点中定义的端口
旧式运行状况检查 --port:指定 TCP 端口号

负载平衡器指南

下表显示了每个 Google Cloud 负载平衡器和后端类型支持的类别、范围和端口指定。

负载平衡器 后端类型 运行状况检查类别和范围 端口指定
内部 TCP/UDP 负载平衡 1 实例组 运行状况检查(全球或地区)
  • 自定义端口号 (--port)
内部 HTTP(S) 负载平衡 区域 NEG 运行状况检查(区域)
  • 自定义端口号 (--port)
  • 端点的端口号 (--use-serving-port)
实例组 运行状况检查(区域)
  • 自定义端口号 (--port)
  • 后端服务的已命名端口 (--use-serving-port)
网络负载平衡 目标池中的
实例
使用 HTTP 协议的旧式运行状况检查(全球) 旧式运行状况检查仅支持端口号 (--port) 指定。
外部 HTTP(S) 负载平衡 2

TCP 代理负载平衡

SSL 代理负载平衡
区域 NEG 运行状况检查(全球)
  • 自定义端口号 (--port)
  • 端点的端口号 (--use-serving-port)
实例组 运行状况检查(全球)
  • 自定义端口号 (--port)
  • 后端服务的已命名端口 (--use-serving-port)

1 您不能使用 --use-serving-port 标志,因为内部后端服务不具有已命名的端口。
2 在以下情况下,您可以(但不建议)对与外部 HTTP(S) 负载平衡器关联的后端服务使用旧式运行状况检查:

  • 后端是实例组,而不是区域 NEG。
  • 后端虚拟机会传送使用 HTTP 或 HTTPS 协议的流量。

运行状况检查原理

以下部分介绍了运行状况检查原理。

探测

创建非旧式运行状况检查创建旧式运行状况检查时,您可以指定以下标志或接受其默认值。您创建的每项运行状况检查或旧式运行状况检查由多重探测实现。这些标志控制每个 Google Cloud 运行状况检查探测对实例组后端中的实例或区域 NEG 后端中的端点进行评估的频率。

您不能针对每个后端分别配置运行状况检查的设置。运行状况检查与整个后端服务关联,而旧式运行状况检查与整个目标池(用于网络负载平衡)或后端服务(用于某些外部 HTTP(S) 负载平衡配置)关联。因此,探测参数对于给定后端服务或目标池所引用的全部后端来说都是相同的。

配置标志 用途 默认值
检查间隔时间
check-interval
检查间隔时间是指从一个探测器发出的一次探测开始到由同一探测器发出的下一次探测开始之间的时间量。该时间以秒为单位。 如果省略,则 Google Cloud 将使用 5s(5 秒)。
超时
timeout
超时表示 Google Cloud 等待探测响应的时间量。其值必须小于或等于检查间隔时间。该时间以秒为单位。 如果省略,则 Google Cloud 将使用 5s(5 秒)。

探测 IP 地址范围和防火墙规则

为了使运行状况检查正常运行,您必须创建入站 allow 防火墙规则,以便来自 Google Cloud 探测器的流量能够连接到您的后端。

下表显示了允许的来源 IP 地址范围:

产品 探测来源 IP 地址范围 防火墙规则示例
内部 TCP/UDP 负载平衡
内部 HTTP(S) 负载平衡
外部 HTTP(S) 负载平衡
SSL 代理负载平衡
TCP 代理负载平衡
Traffic Director
35.191.0.0/16
130.211.0.0/22
除网络负载平衡器以外的其他所有产品的防火墙规则
网络负载平衡 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
网络负载平衡器的防火墙规则

防火墙规则的重要性

Google Cloud 要求您创建必要的入站 allow 防火墙规则,以允许来自探测器的流量传输到您的后端。最佳做法是将这些规则限制为仅使用与运行状况检查所使用的协议和端口匹配的协议和端口。对于来源 IP 地址范围,请确保使用前面部分记录的探测 IP 地址范围。

如果您没有入站 allow 防火墙规则(这些规则允许您的运行状况检查使用的协议、端口和来源 IP 地址范围),则隐式 deny 入站防火墙规则会阻止来自所有来源的入站流量。如果探测器无法与您的后端取得联系,则 Google Cloud 负载平衡器会将您的所有后端归类为“运行状况不佳”。所有后端运行状况不佳时的行为取决于负载平衡器的类型:

  • 当所有后端运行状况不佳时,外部 HTTP(S) 负载平衡器会向客户端返回 HTTP 502 响应。

  • 当所有后端运行状况不佳时,内部 HTTP(S) 负载平衡器会向客户端返回 HTTP 503 响应。

  • 当所有后端运行状况不佳时,SSL 代理负载平衡器和 TCP 代理负载平衡器会出现超时。

  • 作为最后的补救手段,网络负载平衡器会在所有后端虚拟机都运行状况不佳时尝试将流量分配到所有虚拟机

  • 作为最后的补救手段,未配置故障转移的内部 TCP/UDP 负载平衡器会在所有后端虚拟机都运行状况不佳时将流量分配到所有虚拟机。启用故障转移后,您可以停用此行为

探测 IP 地址范围的安全注意事项

在规划运行状况检查和必要的防火墙规则时,请考虑以下信息:

  • 探测 IP 地址范围属于 Google。Google Cloud 在您的 VPC 网络外部但在 Google 的生产网络中,使用特殊路由协调来自探测器的通信。

  • Google 使用探测 IP 地址范围专门执行运行状况检查探测,以及专门从 Google Front End (GFE) 发送外部 HTTP(S) 负载平衡器、SSL 代理负载平衡器和 TCP 代理负载平衡器的流量。如果从互联网(包括 Compute Engine 实例或 Google Kubernetes Engine (GKE) 节点的外部 IP 地址)收到数据包,且数据包的来源 IP 地址是在探测 IP 地址范围内),则 Google 会丢弃数据包。

  • 探测 IP 地址范围是 Google Cloud 探测器使用的可能 IP 地址的完整集合。如果使用 tcpdump 或类似工具,您可能无法观察到来自所有探测 IP 地址范围中所有 IP 地址的流量。最佳做法是,将所有探测 IP 地址范围用作来源,为所选负载平衡器创建入站 allow 防火墙规则,因为 Google Cloud 可以自动实现新的探测器而不发送通知。

多重探测和频率

Google Cloud 从多个称为探测器的冗余系统发送运行状况检查探测。探测器使用特定的来源 IP 地址范围。Google Cloud 并不仅依赖于一个探测器来实现运行状况检查,也就是说,多个探测器会同时评估实例组后端中的实例或者区域 NEG 后端中的端点。如果某个探测器发生故障,则 Google Cloud 会继续跟踪后端运行状况。

您为运行状况检查配置的时间间隔和超时设置会应用于每个探测器。对于给定的后端,软件访问日志和 tcpdump 中显示的探测频率会比您配置的设置值更高。

这是预期行为,您无法配置 Google Cloud 用于运行状况检查的探测器数量。不过,您可以通过考虑以下几个因素来估算同时执行多重探测所带来的影响。

  • 如需估算每个后端服务的探测频率,请考虑以下事项:

    • 每个后端服务的基本频率。每项运行状况检查都有一个关联的检查频率,此频率与配置的检查时间间隔成反比:

      1(检查间隔时间)

      将运行状况检查与后端服务相关联时,您需要为该后端服务中的后端确立用于每个探测器的基本频率。

    • 探测比例系数。将后端服务的基本频率乘以 Google Cloud 使用的并发探测器数量。此数值可能不同,但通常介于 5 到 10 之间。

  • 内部 TCP/UDP 负载平衡器的多个转发规则。如果您配置了多个指向同一地区级内部后端服务的内部转发规则(每个规则具有不同的 IP 地址),则 Google Cloud 会使用多个探测器来检查各个 IP 地址。在这种情况下,请将每项后端服务的探测频率乘以配置的转发规则数。

  • 网络负载平衡器的多个转发规则。如果您配置了多个指向同一目标池的转发规则,则 Google Cloud 会使用多个探测器来检查各个 IP 地址。目标池中每个实例看到的探测频率乘以配置的转发规则数。

  • 外部 HTTP(S) 负载平衡器的多个目标代理。如果您配置了多个目标代理以将流量定向到外部 HTTP(S) 负载平衡的同一网址映射,则 Google Cloud 会使用多个探测器来检查与每个目标代理关联的 IP 地址。在这种情况下,请将每项后端服务的探测频率乘以配置的目标代理数。

  • SSL 代理负载平衡器和 TCP 代理负载平衡器的多个目标代理。如果您配置了多个目标代理以将流量定向到 SSL 代理负载平衡或 TCP 代理负载平衡的同一后端服务,则 Google Cloud 会使用多个探测器来检查与每个目标代理关联的 IP 地址。在这种情况下,请将每项后端服务的探测频率乘以配置的目标代理数。

  • 对各个后端服务进行求和。如果某个后端(例如实例组)供多个后端服务使用,那么后端实例的探测频率就是各后端服务的运行状况检查频率之和。

    使用区域 NEG 后端时,确切的运行状况检查探测次数会更难以确定。例如,同一个端点可以位于多个区域 NEG 中,这些区域 NEG 不一定具有相同的端点集,而且不同的端点可以指向同一个后端。

探测数据包的目标

下表显示了接收运行状况检查探针发送的数据包的网络接口和目标 IP 地址,具体视负载平衡器的类型而定。

对于网络负载平衡器和内部 TCP/UDP 负载平衡器,应用必须绑定到负载平衡器的 IP 地址(或任何 IP 地址 0.0.0.0)。

负载平衡器 目标网络接口 目标 IP 地址
内部 TCP/UDP 负载平衡 位于针对内部后端服务指定的网络中的实例的网络接口。如果未指定,则使用主要网络接口 (nic0)。

如需了解详情,请参阅后端服务和网络接口
内部转发规则的 IP 地址。

如果多个转发规则指向同一个后端服务,则 Google Cloud 会将探测发送到每个转发规则的 IP 地址。这会导致探测数量增加。
网络负载平衡 主要网络接口 (nic0) 外部转发规则的 IP 地址。

如果多个转发规则指向同一个目标池,则 Google Cloud 会将探测发送到每个转发规则的 IP 地址。这会导致探测数量增加。
外部 HTTP(S) 负载平衡

内部 HTTP(S) 负载平衡

SSL 代理负载平衡

TCP 代理负载平衡

主要网络接口 (nic0)
  • 对于实例组后端,则为与每个实例的主要网络接口 (nic0) 关联的主要内部 IP 地址。
  • 对于区域 NEG 后端,则为端点的 IP 地址,该地址是主要内部 IP 地址或者别名 IP 地址范围(属于对端点进行托管的实例上的主要网络接口 nic0)。

HTTP、HTTPS、HTTP/2 成功标准

如果运行状况检查使用 HTTP、HTTPS 或 HTTP/2 协议,则每个探测都要求在探测超时之前传送 HTTP 200 (OK) 响应代码。此外,您还可以执行以下操作:

  • 您可以将 Google Cloud 探测器配置为向特定的请求路径发送 HTTP 请求。如果您未指定请求路径,则使用 /

  • 如果您通过指定预期响应字符串来配置基于内容的运行状况检查,则 Google Cloud 必须在 HTTP 响应的前 1024 个字节内找到预期的字符串。

  • 如果您配置预期响应字符串,则每个 Google Cloud 运行状况检查探测必须在来自后端的实际响应的前 1024 个字节内找到预期响应字符串。

使用 HTTP、HTTPS 和 HTTP/2 协议的运行状况检查可以按以下组合方式使用请求路径和响应字符串标志。

配置标志 成功标准
请求路径
request-path
指定 Google Cloud 要向其发送运行状况检查探测请求的网址路径。
如果您省略了此标志,则 Google Cloud 会将探测请求发送到根路径 /request-path 选项不支持查询参数。
响应
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 且状态字段相应设置为 SERVINGNOT_SERVING 的 RPC 响应。如需了解详情,请参阅 gRPC 运行状况检查文档

运行状况

Google Cloud 使用以下配置标志来确定实现流量负载平衡的每个后端的整体运行状况。

配置标志 用途 默认值
运行状况良好判断阈值
healthy-threshold
运行状况良好判断阈值指定了要将后端视为运行状况良好所需满足的连续成功探测次数。 如果您省略了此标志,则 Google Cloud 会将 2 个探测用作阈值。
运行状况不佳判断阈值
unhealthy-threshold
运行状况不佳判断阈值指定了要将后端视为运行状况不佳所需满足的连续失败探测次数。 如果您省略了此标志,则 Google Cloud 会将 2 个探测用作阈值。

达到此运行状况良好判断阈值后,Google Cloud 会将后端视为运行状况良好。运行状况良好的后端可以接收新的连接。

达到运行状况不佳判断阈值后,Google Cloud 会将后端视为运行状况不佳。运行状况不佳的后端不能接收新的连接;但是,现有连接不会立即终止。这些连接会一直保持打开状态,直到发生超时情况或流量被舍弃。具体行为因您使用的负载平衡器类型而异。

现有连接可能无法返回响应,具体取决于导致探测失败的原因。如果运行状况不佳的后端能够再次达到运行状况良好判断阈值,则该后端就会被视为运行状况良好。

补充说明

基于内容的运行状况检查

基于内容的运行状况检查就是其成功标准取决于对预期响应字符串的评估的运行状况检查。使用基于内容的运行状况检查来指示 Google Cloud 运行状况检查探测更全面地验证您的后端响应。

  • 如需配置基于 HTTP、HTTPS 或 HTTP/2 内容的运行状况检查,请指定预期响应字符串以及选择性地定义请求路径。如需了解详情,请参阅 HTTP、HTTPS 和 HTTP/2 的成功标准

  • 如需配置基于 SSL 或 TCP 内容的运行状况检查,请指定预期响应字符串以及选择性地定义请求字符串。如需了解详情,请参阅 SSL 和 TCP 成功标准

证书和运行状况检查

Google Cloud 运行状况检查探测器不会执行证书验证,即使是要求您的后端使用证书的协议(SSL、HTTPS 和 HTTP/2),例如:

  • 您可以使用自签名证书或由任何证书授权机构 (CA) 签名的证书。
  • 已过期或尚未生效的证书均可接受。
  • CNsubjectAlternativeName 特性都不需要与 Host 标头或 DNS PTR 记录匹配。

标头

使用任何协议的运行状况检查(但不是旧式运行状况检查)可让您使用 --proxy-header 标志来设置代理标头。

旧式运行状况检查以及使用 HTTP、HTTPS 或 HTTP/2 协议的运行状况检查可让您使用 --host 标志来指定 HTTP Host 标头。

示例运行状况检查

假设您使用以下设置设定了运行状况检查:

  • 间隔时间:30 秒
  • 超时:5 秒
  • 协议:HTTP
  • 运行状况不佳判断阈值:2(默认值)
  • 运行状况良好判断阈值:2(默认值)

使用这些设置时,运行状况检查的行为如下:

  1. 多个冗余系统会同时使用运行状况检查参数进行配置。时间间隔和超时设置会应用到每个系统。如需了解详情,请参阅多重探测和频率
  2. 每个运行状况检查探测器都会执行以下操作:

    1. 每隔 30 秒启动从其中一个来源 IP 地址到后端实例的 HTTP 连接。
    2. 等待收到 HTTP 200 (OK) 响应代码(HTTP、HTTPS 和 HTTP/2 协议的成功标准),最长等待 5 秒。
  3. 至少有一个运行状况检查探测系统满足下列条件时,后端就会被视为运行状况不佳:

    1. 未收到两个连续探测的 HTTP 200 (OK) 响应代码。例如,连接可能被拒绝,或者连接或套接字可能超时。
    2. 收到两个不符合协议专用成功标准的连续响应。
  4. 如果至少一个运行状况检查探测系统收到两个符合协议专用成功标准的连续响应,则后端会被视为运行状况良好。

在此示例中,每个探测器每隔 30 秒启动一次连接。两次探测器连接尝试间隔 30 秒,无论超时时长如何(也就是无论连接是否超时)。换句话说,超时时间必须始终小于或等于间隔时间,而且超时时间不会增加该间隔时间。

在本示例中,每个探测器的时间(以秒为单位)如下所示:

  1. t=0:启动探测 A。
  2. t=5:停止探测 A。
  3. t=30:启动探测 B。
  4. t=35:停止探测 B。
  5. t=60:启动探测 C。
  6. t=65:停止探测 C。

后续步骤