配置健康检查

Google Distributed Cloud (GDC) air-gapped 提供的健康检查机制可确定后端实例是否能够正确响应流量。本文档介绍了如何为负载平衡器创建和使用健康检查。

除非另有说明，否则 Google Cloud 健康检查是通过根据健康检查资源中指定的参数连接到后端的专用软件任务实现的。每次连接尝试称为一次探测。 Google Cloud 会记录每次探测是成功还是失败。

每个后端的健康状况由连续成功或失败的探测次数（可配置）决定。也就是说，您可以配置将后端标记为健康状况良好所需的连续探测成功次数，以及将其标记为健康状况不佳所需的连续探测失败次数。

此健康状况决定了后端是否有资格接收新的请求或连接。健康检查器会识别出运行状况不佳的后端，此类后端不会通过负载均衡器接收流量。您可以定义成功探测的标准。如需了解详情，请参阅健康检查原理部分。

注意： 此处介绍的健康检查机制仅适用于虚拟机工作负载后端，不适用于 pod。您可以使用 Kubernetes 容器探测为 pod 配置 HTTP(S) 健康检查。

健康检查协议

健康检查支持以下协议：

• TCP
• HTTP
• HTTPS

选择健康检查

健康检查必须与负载均衡器的类型及后端类型兼容。选择健康检查时，请考虑以下因素：

• 协议：GDC 用于探测后端的协议。支持的协议包括 TCP、HTTP 和 HTTPS。TCP 协议适用于验证与后端连接的基本健康检查，而 HTTP 和 HTTPS 协议则为已运行 HTTP 或 HTTPS 工作负载的虚拟机提供更精细的健康检查机制。
• 端口指定：GDC 用于协议的端口，用于探测后端的健康状况。 您必须为健康检查指定端口。
• 类别：健康检查可以是全球级或可用区级。全球健康检查会覆盖 GDC 部署的所有可用区，而可用区级健康检查仅对应一个可用区。

健康检查原理

以下部分介绍了健康检查原理。

探测

设置健康检查时，您可以定义或接受默认设置，以控制每个探测器评估关联端点健康状况的频率。这些设置至关重要，因为负载均衡器会根据您配置的标准停止将请求路由到被视为不健康的后端。探测器将持续进行评估，并在后端再次被视为正常后恢复向其发送流量。

请务必注意，健康检查设置会统一应用于后端服务或目标池中的所有后端，而不能针对每个后端单独配置。

配置标志	说明	默认值
检查间隔 check-interval	从一次探测开始到同一探测器发出的下一次探测开始之间的时间（以秒为单位）。	5s（5 秒）
timeoutSec timeoutSec	在声明失败之前等待探测的时间（以秒为单位）。	5s（5 秒）
healthyThreshold healthyThreshold	要将端点视为运行状况良好必须成功的连续探测次数。	2
unhealthyThreshold unhealthyThreshold	要将端点视为运行状况不佳所必须失败的连续探测次数。	2

HTTP 和 HTTPS 健康检查的成功标准

对于 HTTP 和 HTTPS 健康检查，在健康检查超时之前，成功响应必须包含 HTTP 200 (OK) 状态代码。其他 HTTP 响应代码（包括重定向，例如 301、302）均被视为健康状况不佳。

除了要求 HTTP 200 (OK) 响应代码之外，您还可以：

• 配置每个健康检查探测器，使其向特定的请求路径（而不是默认请求路径 /）发送 HTTP 请求。
• 配置每个健康检查探测器，使其检查 HTTP 响应正文中是否存在预期的响应字符串。预期响应字符串必须仅包含可打印的单字节 ASCII 字符，并且这些字符位于 HTTP 响应正文的前 1,024 个字节内。

下表列出了适用于 HTTP 和 HTTPS 健康检查的 requestPath 和 response 字段的有效组合。

配置标志	探测器行为	成功标准
既未指定 RequestPath 也未指定 Response	探测器使用 / 作为请求路径。	仅限 HTTP 200 (OK) 响应代码。
同时指定了 RequestPath 和 Response	探测器使用配置的请求路径。	HTTP 200 (OK) 响应代码和 HTTP 响应正文的前 1,024 个 ASCII 字符范围内的字符必须与预期的响应字符串匹配。
仅指定了响应	探测器使用 / 作为请求路径。	HTTP 200 (OK) 响应代码和 HTTP 响应正文的前 1,024 个 ASCII 字符范围内的字符必须与预期的响应字符串匹配。
仅指定了 RequestPath	探测器使用配置的请求路径。	仅限 HTTP 200 (OK) 响应代码。

TCP 健康检查的成功标准

TCP 健康检查具有以下基本成功标准：

• 对于 TCP 健康检查，健康检查探测器必须在健康检查超时之前成功打开与后端的 TCP 连接。
• 对于 TCP 健康检查，必须通过以下任一方式关闭 TCP 连接：
  • 通过健康检查探测器发送 FIN 或 RST（重置）数据包。
  • 通过后端发送 FIN 数据包。
  • 如果后端发送 TCP RST 数据包，那么健康检查探测器已发送 FIN 数据包时，探测可能被视为不成功。

准备工作

如需配置健康检查探测，您必须具备以下条件：

• 拥有您要为其配置负载均衡器的项目。如需了解详情，请参阅创建项目。

• 必要的身份和访问权限角色：

  • 请让您的组织 IAM 管理员向您授予 Load Balancer Admin (load-balancer-admin) 角色。
  • 对于全球 ILB，请让您的组织 IAM 管理员向您授予 Global Load Balancer Admin (global-load-balancer-admin) 角色。如需了解详情，请参阅预定义角色说明。

注意： HealthCheck 对象仅对与虚拟机端点相关联的负载平衡器有效。

创建和管理健康检查

GDC 支持全局健康检查和可用区级健康检查。

HealthCheck API

您可以将 HealthCheck 对象配置为全局或地区级。全局 HealthCheck 对象用于全局负载均衡器配置，而区域 HealthCheck 对象用于区域负载均衡器配置。这两种类型的名称和规范相同。不过，它们使用不同的 apiVersion 值和 API 服务器：

• 可用区级 apiVersion：networking.gdc.goog
• 全局 apiVersion：networking.global.gdc.goog

您还可以使用 gdcloud CLI 来创建和管理健康检查。

创建全局 HealthCheck

以下示例展示了如何使用 API 创建健康检查：

  kubectl --kubeconfig GLOBAL_ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.global.gdc.goog/v1 
  kind: HealthCheck 
  metadata: 
    namespace: PROJECT 
    name: my-hc 
  spec: 
    httpHealthCheck: 
      port: PORT 
      host: HOST 
      requestPath: requestPath 
      response: responseT 
  EOF

创建可用区级 HealthCheck

以下示例展示了如何使用 API 创建健康检查：

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.gdc.goog/v1
  kind: HealthCheck
  metadata:
    namespace: PROJECT
    name: my-hc
  spec:
    httpHealthCheck:
      port: PORT
      host: HOST
      requestPath: requestPath 
      response: response 
  EOF 

如需将健康检查与负载均衡器相关联，请参阅以下内容：

• 配置内部负载平衡器
• 配置外部负载平衡器

配置验证

为确保配置正确，请验证 HealthCheck 对象的 Ready 条件。此条件表示存在任何配置错误。此外，请确认这些字段准确反映了所需的 HealthCheck 设置。

其他使用说明

以下部分包含有关在 Google Cloud上使用健康检查的更多说明。

证书和健康检查

对于要求后端使用证书的协议（例如 HTTPS），

• 证书可以自签名，也可以由任何证书授权机构 (CA) 签名。
• 已过期或未来的证书均可接受。

标头

为 HTTP 或 HTTPS 协议配置健康检查时，您可以使用 --host 标志指定 HTTP Host 标头。

请务必注意，负载均衡器仅会向客户端请求添加您配置的自定义请求标头，而不会向健康检查探测添加自定义请求标头。因此，如果后端需要将特定标头用于授权，而健康检查数据包中缺少该标头，则健康检查可能会失败。

示例健康检查

如果健康检查配置了以下参数：

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

健康检查将按以下方式运行：

• 每个健康检查探测器将：
  1. 每隔 30 秒启动从来源 IP 地址到后端实例的 HTTP 连接。
  2. 等待 HTTP 200 (OK) 状态代码返回（HTTP 和 HTTPS 协议的指定成功标准），最长等待 5 秒。
• 如果至少有一个健康检查探测系统满足下列条件，则后端会被视为健康状况不佳：
  1. 由于连接遭拒、连接超时或套接字超时，未收到两个连续探测的 HTTP 200 (OK) 响应。
  2. 收到两个不符合协议专用成功标准的连续响应。
• 如果至少一个健康检查探测系统收到两个符合协议专用成功标准的连续响应，则后端会被视为健康状况良好。

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

限制

1. GDC 健康检查仅适用于虚拟机端点。
2. 配置了健康检查的负载平衡器无法将 Pod 和虚拟机配置为混合后端。负载均衡器的端点必须仅包含 pod 或仅包含虚拟机。目前，负载均衡器的端点必须仅包含 pod 或仅包含虚拟机。
3. 目前尚不支持更改负载均衡器和关联的健康检查。