配置健康检查

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

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

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

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

健康检查协议

健康检查支持以下协议：

• TCP
• HTTP
• HTTPS

选择健康检查

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

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

健康检查原理

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

探测

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

请务必注意，健康检查设置统一适用于后端服务或目标池中的所有后端，并且无法针对每个后端分别进行配置。

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

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

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

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

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

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) 角色。如需了解详情，请参阅预定义角色说明。

创建和管理健康检查

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

HealthCheck API

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

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

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

创建全球级 HealthCheck

以下示例展示了如何使用 API 创建 HealthCheck：

  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 创建 HealthCheck：

  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. 负载均衡器及其关联的健康检查的可变性尚不受支持。