设置基于应用的健康检查和自动修复

本文档介绍如何设置基于应用的健康检查，以自动修复托管式实例组 (MIG) 中的虚拟机。此外，还介绍如何执行以下操作：使用健康检查但不使用自动修复、移除健康检查、查看自动修复政策以及检查每个虚拟机的健康状况。

您可以配置基于应用的健康检查来验证虚拟机上的应用是否按预期响应。如果您配置的健康检查检测到虚拟机上的应用没有响应，则 MIG 会将虚拟机标记为健康状况不佳，并默认对其进行修复。根据基于应用的健康检查修复虚拟机的行为称为自动修复。

您还可以在 MIG 中关闭自动修复，以便使用健康检查而不触发针对健康状况不佳的虚拟机的修复。

如需详细了解 MIG 中的修复，请参阅关于修复虚拟机以实现高可用性。

准备工作

  • 如果您尚未设置身份验证，请进行设置。身份验证是通过其进行身份验证以访问 Google Cloud 服务和 API 的过程。如需从本地开发环境运行代码或示例，您可以通过选择以下选项之一向 Compute Engine 进行身份验证：

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. After installing the Google Cloud CLI, initialize it by running the following command: 

      gcloud init

      If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

    2. Set a default region and zone.

      3. Terraform

      如需在本地开发环境中使用本页面上的 Terraform 示例，请安装并初始化 gcloud CLI，然后使用您的用户凭证设置应用默认凭证。

      1. Install the Google Cloud CLI.

      2. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      3. To initialize the gcloud CLI, run the following command: 

        gcloud init

      4. If you're using a local shell, then create local authentication credentials for your user account: 

        gcloud auth application-default login

        You don't need to do this if you're using Cloud Shell.

        If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

        5. 如需了解详情，请参阅 Set up authentication for a local development environment。

      REST

      如需在本地开发环境中使用本页面上的 REST API 示例，请使用您提供给 gcloud CLI 的凭据。

        After installing the Google Cloud CLI, initialize it by running the following command: 

        gcloud init

        If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      如需了解详情，请参阅 Google Cloud 身份验证文档中的使用 REST 时进行身份验证。

价格

设置基于应用的健康检查后，每当虚拟机的健康状况发生变化时，Compute Engine 默认会在 Cloud Logging 中写入日志条目。 Cloud Logging 提供每月免费配额，之后会按数据量计费。为避免产生费用，您可以停用运行状况更改日志。

设置基于应用的健康检查和自动修复

如需在 MIG 中设置基于应用的健康检查和自动修复，必须执行以下操作：

  1. 创建健康检查（如果尚未创建）。
  2. 在 MIG 中配置自动修复政策以应用健康检查。

创建健康检查

您可以将单个健康检查应用于最多 50 个 MIG。 如果您拥有的实例组超过 50 个，请创建多个健康检查。

以下示例展示了如何为自动修复创建健康检查。您可以在 MIG 中为自动修复创建区域级或全球健康检查。在此示例中，您将创建全球健康检查，使其在端口 80 上查找 Web 服务器响应。如需使健康检查探测能够访问 Web 服务器，请配置防火墙规则。

控制台

  1. 为自动修复创建健康检查，这种检查比负载均衡健康检查更加保守。

    例如，创建一个查找端口 80 响应的健康检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在此示例中，如果健康检查成功返回一次，则会将虚拟机标记为“健康状况良好”。如果健康检查连续失败 3 次，则会将虚拟机标记为”健康状况不佳“。

    1. 在 Google Cloud 控制台中，前往创建健康检查页面。

      转到“创建健康检查”

    2. 为此健康检查指定名称，例如 example-check。

    3. 选择一个范围。您可以选择区域级或全球。对于此示例，选择全球。

    4. 对于协议，请确保选中 HTTP。

    5. 对于端口，请输入 80。

    6. 在健康状况判断标准部分中，提供以下值：

      1. 对于检查间隔，请输入 5。
      2. 对于超时，请输入 5。
      3. 设置状况良好判断阈值，指定健康状况不佳的虚拟机必须连续多少次返回成功的健康检查，才能被标记为健康状况良好。对于此示例，请输入 1。
      4. 设置状况不佳判断阈值，指定健康状况良好的虚拟机必须连续多少次返回不成功的健康检查，才能被标记为健康状况不佳。对于此示例，请输入 3。

    7. 点击创建以创建健康检查。

  2. 创建防火墙规则以允许健康检查探测连接到您的应用。

    健康检查探测请求来自 130.211.0.0/22 和 35.191.0.0/16 范围内的地址，因此请确保您的网络防火墙规则允许健康检查进行连接。在此示例中，MIG 使用的是 default 网络，并且其虚拟机监听的是端口 80。如果端口 80 尚未在默认网络中打开，请创建防火墙规则。

    1. 在 Google Cloud 控制台中，前往防火墙政策页面。

      转到“防火墙政策”

    2. 点击创建防火墙规则。

    3. 输入防火墙规则的名称。例如 allow-health-check。

    4. 对于网络，请选择 default 网络。

    5. 对于目标，请选择 All instances in the network。

    6. 对于来源过滤条件，请选择 IPv4 ranges。

    7. 对于来源 IPv4 范围，输入 130.211.0.0/22 和 35.191.0.0/16。

    8. 在协议和端口中，选择指定的协议和端口并执行以下操作：

      1. 选择 TCP。
      2. 在端口字段中，输入 80。

    9. 点击创建。

gcloud

  1. 为自动修复创建健康检查，这种检查比负载均衡健康检查更加保守。

    例如，创建一个查找端口 80 响应的健康检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在本示例中，如果虚拟机成功返回一次，则会被标记为“运行状况良好”。如果连续 3 次未能成功返回，则虚拟机会被标记为“运行状况不佳”。以下命令会创建一个全球健康检查。

    gcloud compute health-checks create http example-check --port 80 \
   --check-interval 30s \
   --healthy-threshold 1 \
   --timeout 10s \
   --unhealthy-threshold 3 \
   --global

  2. 创建防火墙规则以允许健康检查探测连接到您的应用。

    健康检查探测请求来自 130.211.0.0/22 和 35.191.0.0/16 范围内的地址，因此请确保您的防火墙规则允许健康检查进行连接。在此示例中，MIG 使用的是 default 网络，并且其虚拟机监听的是端口 80。如果端口 80 尚未在默认网络中打开，请创建防火墙规则。

    gcloud compute firewall-rules create allow-health-check \
    --allow tcp:80 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default

Terraform

  1. 使用 google_compute_http_health_check 资源创建健康检查。

    例如，创建一个查找端口 80 响应的健康检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在本示例中，如果虚拟机成功返回一次，则会被标记为“运行状况良好”。如果连续 3 次未能成功返回，则虚拟机会被标记为“运行状况不佳”。以下请求会创建一个全球健康检查。

    resource "google_compute_http_health_check" "default" {
  name                = "example-check"
  timeout_sec         = 10
  check_interval_sec  = 30
  healthy_threshold   = 1
  unhealthy_threshold = 3
  port                = 80
}

  2. 使用 google_compute_firewall 资源创建防火墙。

    健康检查探测请求来自 130.211.0.0/22 和 35.191.0.0/16 范围内的地址，因此请确保您的防火墙规则允许健康检查进行连接。在此示例中，MIG 使用的是 default 网络，并且其虚拟机监听的是端口 80。如果端口 80 尚未在默认网络中打开，请创建防火墙规则。

    resource "google_compute_firewall" "default" {
  name          = "allow-health-check"
  network       = "default"
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
  allow {
    protocol = "tcp"
    ports    = [80]
  }
}

如需了解如何应用或移除 Terraform 配置，请参阅基本 Terraform 命令。

REST

  1. 为自动修复创建健康检查，这种健康检查比负载均衡健康检查更加保守。

    例如，创建一个查找端口 80 响应的健康检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在本示例中，如果虚拟机成功返回一次，则会被标记为“运行状况良好”。如果连续 3 次未能成功返回，则虚拟机会被标记为“运行状况不佳”。以下请求会创建一个全球健康检查。

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks

{
 "name": "example-check",
 "type": "http",
 "port": 80,
 "checkIntervalSec": 30,
 "healthyThreshold": 1,
 "timeoutSec": 10,
 "unhealthyThreshold": 3
}

  2. 创建防火墙规则以允许健康检查探测连接到您的应用。

    健康检查探测请求来自 130.211.0.0/22 和 35.191.0.0/16 范围内的地址，因此请确保您的防火墙规则允许健康检查进行连接。在此示例中，MIG 使用的是 default 网络，并且其虚拟机监听的是端口 80。如果端口 80 尚未在默认网络中打开，请创建防火墙规则。

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "allow-health-check",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
 "sourceRanges": [
  "130.211.0.0/22",
  "35.191.0.0/16"
 ],
 "allowed": [
  {
   "ports": [
    "80"
   ],
   "IPProtocol": "tcp"
  }
 ]
}

    请将 PROJECT_ID 替换为您的项目 ID。

在 MIG 中配置自动修复政策

在 MIG 中，只能设置一项自动修复政策来应用健康检查。

在配置自动修复政策之前，如果您还没有健康检查，请创建一个。可以在 MIG 中将区域级或全球健康检查用于自动修复。区域级健康检查可减少跨区域依赖项并帮助实现数据驻留，而如果要对多个区域中的 MIG 使用相同的健康检查，则全球健康检查会很方便。

如果您希望在设置新的健康检查时防止错误触发自动修复，或者希望使用健康检查但不使用自动修复，请参阅配置不使用自动修复的健康检查。您还可以在 MIG 中配置健康检查后关闭自动修复。

如需配置自动修复政策，请选择以下选项之一：

控制台

  1. 在 Google Cloud 控制台中，前往实例群组页面。

    进入“实例组”

  2. 在列表的名称列下方，点击要在其中应用健康检查的 MIG 的名称。

  3. 点击修改以修改此 MIG。

  4. 在虚拟机实例生命周期部分的自动修复下，选择全球或区域性健康检查。

  5. 更改或保留初始延迟时间设置。

    初始延迟时间是新虚拟机初始化并运行其启动脚本所需的秒数。在虚拟机的初始延迟时间段内，MIG 会忽略失败的健康检查，因为虚拟机可能处于启动过程中。这可以防止 MIG 过早地重新创建虚拟机。如果健康检查在初始延迟期间收到健康状况良好响应，则表示启动过程已完成且虚拟机已准备就绪。初始延迟计时器从虚拟机的 currentAction 字段更改为 VERIFYING 时开始计时。初始延迟时间的值必须介于 0 到 3600 秒之间。在控制台中，默认值为 300 秒。

  6. 点击保存以应用所做的更改。

gcloud

如需在现有 MIG 中配置自动修复政策，请使用 update 命令。 例如，使用以下命令在现有的可用区级 MIG 中配置自动修复政策：

gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

如需在创建 MIG 时配置自动修复政策，请使用 create 命令。 例如，在创建可用区级 MIG 时，您可以使用以下命令配置自动修复政策：

gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

替换以下内容：

  • MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
  • SIZE：组中的虚拟机数量。
  • INSTANCE_TEMPLATE_URL：您要用于在 MIG 中创建虚拟机的实例模板的网址。网址可以包含实例模板的 ID 或名称。请指定以下某个值：
    • 对于区域级实例模板：projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • 对于全球实例模板：INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL：您要为自动修复设置的健康检查的部分网址。例如：
    • 区域级健康检查：projects/example-project/regions/us-central1/healthChecks/example-health-check
    • 全局健康检查：projects/example-project/global/healthChecks/example-health-check。
  • INITIAL_DELAY：新虚拟机初始化并运行其启动脚本所需的秒数。在虚拟机的初始延迟时间段内，MIG 会忽略失败的健康检查，因为虚拟机可能处于启动过程中。这可以防止 MIG 过早地重新创建虚拟机。如果健康检查在初始延迟期间收到健康状况良好响应，则表示启动过程已完成且虚拟机已准备就绪。初始延迟计时器从虚拟机的 currentAction 字段变为 VERIFYING 时开始计时。 初始延迟时间的值必须介于 0 到 3600 秒之间。默认值为 0。
  • ZONE：该 MIG 所在的可用区。对于区域级 MIG，请使用 --region 标志。

Terraform

如需在 MIG 中配置自动修复政策，请使用 auto_healing_policies 代码块。

以下示例在可用区级 MIG 中配置自动修复政策。如需详细了解示例中使用的资源，请参阅 google_compute_instance_group_manager。对于区域级 MIG，请使用 google_compute_region_instance_group_manager 资源。

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

如需了解如何应用或移除 Terraform 配置，请参阅基本 Terraform 命令。

REST

如需在现有 MIG 中配置自动修复政策，请使用 patch 方法，如下所示：

例如，进行以下调用，以在现有可用区级 MIG 中设置自动修复：

  PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
  {
    "autoHealingPolicies": [
      {
        "healthCheck": "HEALTH_CHECK_URL",
        "initialDelaySec": INITIAL_DELAY
      }
    ]
  }

如需在创建 MIG 时配置自动修复政策，请使用 insert 方法，如下所示：

例如，在创建可用区级 MIG 时，进行以下调用以配置自动修复政策：

  POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
  {
    "name": "MIG_NAME",
    "targetSize": SIZE,
    "instanceTemplate": "INSTANCE_TEMPLATE_URL",
    "autoHealingPolicies": [
      {
        "healthCheck": "HEALTH_CHECK_URL",
        "initialDelaySec": INITIAL_DELAY
      }
    ]
  }

替换以下内容：

  • PROJECT_ID：您的项目 ID。
  • MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
  • SIZE：组中的虚拟机数量。
  • INSTANCE_TEMPLATE_URL：您要用于在 MIG 中创建虚拟机的实例模板的网址。网址可以包含实例模板的 ID 或名称。请指定以下某个值：
    • 对于区域级实例模板：projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • 对于全球实例模板：INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL：您要为自动修复设置的健康检查的部分网址。例如：
    • 区域级健康检查：projects/example-project/regions/us-central1/healthChecks/example-health-check
    • 全局健康检查：projects/example-project/global/healthChecks/example-health-check。
  • INITIAL_DELAY：新虚拟机初始化并运行其启动脚本所需的秒数。在虚拟机的初始延迟时间段内，MIG 会忽略失败的健康检查，因为虚拟机可能处于启动过程中。这可以防止 MIG 过早地重新创建虚拟机。如果健康检查在初始延迟期间收到健康状况良好响应，则表示启动过程已完成且虚拟机已准备就绪。初始延迟计时器从虚拟机的 currentAction 字段变为 VERIFYING 时开始计时。 初始延迟时间的值必须介于 0 到 3600 秒之间。默认值为 0。
  • ZONE：该 MIG 所在的可用区。对于区域级 MIG，请在网址中使用 regions/REGION。

自动修复设置完成后，可能要等待 10 分钟才能开始监控实例组中的虚拟机。监控开始后，Compute Engine 会开始根据您的自动修复配置将虚拟机标记为健康状况良好（否则重新创建虚拟机）。例如，如果您配置的初始延迟时间为 5 分钟，健康检查间隔为 1 分钟，并且健康状况阈值为 1 次检查，时间安排会如下所述：

  • 自动修复开始监控实例组中的虚拟机之前 10 分钟的延迟时间
  • + 5 分钟（配置的初始延迟时间）
  • + 1 分钟的检查间隔 * 运行状况阈值（60 秒 * 1）
  • = 将该虚拟机标记为“健康状况良好”或重新创建虚拟机之前，要等待 16 分钟

配置健康检查但不使用自动修复

您可以在 MIG 中关闭自动修复，并使用已配置的健康检查来监控应用健康状况，或者您可以实现自己的修复逻辑。如果在 MIG 中关闭自动修复，不会影响健康检查的正常运行。健康检查会继续探测应用并提供虚拟机健康状况。不过，MIG 将不再修复不健康的虚拟机。

如需配置不包含自动修复的健康检查，请选择以下选项之一。

控制台

  1. 在 Google Cloud 控制台中，前往实例群组页面。

    进入“实例组”

  2. 在列表的名称列下方，点击要在其中应用健康检查的 MIG 的名称。

  3. 点击修改以修改此 MIG。

  4. 在虚拟机实例生命周期部分的自动修复下，选择全球或区域性健康检查。

  5. 更改或保留初始延迟时间设置。

    初始延迟时间是新虚拟机初始化并运行其启动脚本所需的秒数。在虚拟机的初始延迟时间段内，MIG 会忽略失败的健康检查，因为虚拟机可能处于启动过程中。这可以防止 MIG 过早地重新创建虚拟机。如果健康检查在初始延迟期间收到健康状况良好响应，则表示启动过程已完成且虚拟机已准备就绪。初始延迟计时器从虚拟机的 currentAction 字段更改为 VERIFYING 时开始计时。初始延迟时间的值必须介于 0 到 3600 秒之间。在控制台中，默认值为 300 秒。

  6. 在未能通过健康检查时下拉列表中，选择无操作。

  7. 点击保存以应用更改。

gcloud

如需配置不包含自动修复的健康检查，在指定健康检查配置时，您还必须将 --action-on-vm-failed-health-check 标志设置为 do-nothing，如下所示：

  • 在现有 MIG中，请使用 Beta 版 update 命令：

    例如，在现有的可用区级 MIG 中使用以下命令：

    gcloud beta compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

  • 创建 MIG 时，请使用 Beta 版 create 命令。

    例如，在创建可用区级 MIG 时，请使用以下命令：

    gcloud beta compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

替换以下内容：

  • MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
  • SIZE：组中的虚拟机数量。
  • INSTANCE_TEMPLATE_URL：您要用于在 MIG 中创建虚拟机的实例模板的网址。网址可以包含实例模板的 ID 或名称。请指定以下某个值：
    • 对于区域级实例模板：projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • 对于全球实例模板：INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL：您要为自动修复设置的健康检查的部分网址。例如：
    • 区域级健康检查：projects/example-project/regions/us-central1/healthChecks/example-health-check
    • 全局健康检查：projects/example-project/global/healthChecks/example-health-check。
  • INITIAL_DELAY：新虚拟机初始化并运行其启动脚本所需的秒数。在虚拟机的初始延迟时间段内，MIG 会忽略失败的健康检查，因为虚拟机可能处于启动过程中。这可以防止 MIG 过早地重新创建虚拟机。如果健康检查在初始延迟期间收到健康状况良好响应，则表示启动过程已完成且虚拟机已准备就绪。初始延迟计时器从虚拟机的 currentAction 字段变为 VERIFYING 时开始计时。 初始延迟时间的值必须介于 0 到 3600 秒之间。默认值为 0。
  • ZONE：该 MIG 所在的可用区。对于区域级 MIG，请使用 --region 标志。

REST

如需配置不包含自动修复的健康检查，在指定健康检查配置时，您还必须将 onFailedHealthCheck 字段设置为 DO_NOTHING，如下所示：

  • 在现有 MIG 中，使用 Beta 版 patch 方法，如下所示：

    例如，在现有可用区级 MIG 中进行以下调用：

    PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
{
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

  • 创建 MIG 时，请使用 Beta 版 insert 方法，如下所示：

    例如，在创建可用区级 MIG 时，进行以下调用：

    POST https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL",
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

替换以下内容：

  • PROJECT_ID：您的项目 ID。
  • MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
  • SIZE：组中的虚拟机数量。
  • INSTANCE_TEMPLATE_URL：您要用于在 MIG 中创建虚拟机的实例模板的网址。网址可以包含实例模板的 ID 或名称。请指定以下某个值：
    • 对于区域级实例模板：projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • 对于全球实例模板：INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL：您要为自动修复设置的健康检查的部分网址。例如：
    • 区域级健康检查：projects/example-project/regions/us-central1/healthChecks/example-health-check
    • 全局健康检查：projects/example-project/global/healthChecks/example-health-check。
  • INITIAL_DELAY：新虚拟机初始化并运行其启动脚本所需的秒数。在虚拟机的初始延迟时间段内，MIG 会忽略失败的健康检查，因为虚拟机可能处于启动过程中。这可以防止 MIG 过早地重新创建虚拟机。如果健康检查在初始延迟期间收到健康状况良好响应，则表示启动过程已完成且虚拟机已准备就绪。初始延迟计时器从虚拟机的 currentAction 字段变为 VERIFYING 时开始计时。 初始延迟时间的值必须介于 0 到 3600 秒之间。默认值为 0。
  • ZONE：该 MIG 所在的可用区。对于区域级 MIG，请在网址中使用 regions/REGION。

配置健康检查后，您可以监控虚拟机健康状况，以确认健康检查是否按预期工作。如果您希望 MIG 修复健康状况不佳的虚拟机，可以启用自动修复功能。

移除健康检查

您可以移除在自动修复政策中配置的健康检查，如下所示：

控制台

  1. 在 Google Cloud 控制台中，前往实例群组页面。

    进入“实例组”

    1. 点击要从中移除健康检查的 MIG 的名称。
    2. 点击修改以修改此 MIG。
    3. 在虚拟机实例生命周期部分的自动修复下，选择不检查健康状况。
    4. 点击保存以应用更改。

gcloud

如需移除自动修复政策中的健康检查配置，请在 update 命令中使用 --clear-autohealing 标志，如下所示：

gcloud compute instance-groups managed update MIG_NAME \
    --clear-autohealing

将 MIG_NAME 替换为 MIG 的名称。

REST

如需移除自动修复政策中的健康检查配置，请将自动修复政策设置为空值。

例如，如需移除可用区级 MIG 中的健康检查，请发出以下请求：

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
    {}
  ]
}

替换以下内容：

  • PROJECT_ID：您的项目 ID。
  • MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
  • ZONE：该 MIG 所在的可用区。对于区域级 MIG，请使用 regions/REGION。

查看 MIG 中的自动修复政策

您可以按如下方式查看 MIG 的自动修复政策：

控制台

  1. 在 Google Cloud 控制台中，前往实例群组页面。

    进入“实例组”

  2. 点击要查看其自动修复政策的 MIG 的名称。

  3. 点击详细信息标签页。

  4. 在虚拟机实例生命周期部分中，自动修复字段显示自动修复政策以及在健康政策中配置的初始延迟时间。

gcloud

如需查看 MIG 中的自动修复政策，请使用以下命令：

gcloud compute instance-groups managed describe MIG_NAME \
    --format="(autoHealingPolicies)"

将 MIG_NAME 替换为 MIG 的名称。

以下是输出示例： 

autoHealingPolicies:
  healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check
  initialDelaySec: 300

REST

如需查看 MIG 中的自动修复政策，请使用 REST 方法，如下所示：

例如，发出以下请求以查看可用区级 MIG 中的自动修复政策：

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

在响应正文中，检查 autoHealingPolicies[] 对象。

以下是示例响应：

{
  ...
  "autoHealingPolicies": [
    {
      "healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
      "initialDelaySec": 300
    }
  ],
  ...
}

替换以下内容：

  • PROJECT_ID：您的项目 ID。
  • MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
  • ZONE：该 MIG 所在的可用区。对于区域级 MIG，请使用 regions/REGION。

检查状态

在 MIG 中设置基于应用的健康检查后，您可以通过以下方式验证虚拟机正在运行并且其应用正常响应：

检查虚拟机的健康状况是否良好

如果您在 MIG 中配置了基于应用的健康检查，则可以检查每个代管式实例的健康状况。

检查代管实例的运行状况，以便执行以下操作：

  • 识别未自动修复的健康状况不佳的虚拟机。即使虚拟机在以下情况下被诊断为运行状况不佳，也可能无法立即修复：
    • 虚拟机仍在启动，并且其初始延迟时间尚未过去。
    • 正在修复很大一部分健康状况不佳的实例。MIG 延迟进一步自动修复，以确保实例组持续运行一部分实例。
  • 检测健康检查配置错误。例如，如果实例报告的健康状况为 TIMEOUT，则您可以检测配置错误的防火墙规则或无效的应用健康检查端点。
  • 通过衡量虚拟机转换为 RUNNING 状态的时间点与虚拟机转换为 HEALTHY 运行状况的时间点之间的时长，确定要配置的初始延迟时间值。如需衡量此时间差，您可以轮询 list-instances 方法，也可以观察 instances.insert 操作与收到的第一个运行状况良好信号之间的时间。

使用控制台、gcloud 命令行工具或 REST 查看健康状况。

控制台

  1. 在 Google Cloud 控制台中，前往实例群组页面。

    转到“实例组”。

  2. 在列表的名称列下方，点击要检查的 MIG 的名称。随即打开的页面中会显示实例组属性以及其中所含的虚拟机列表。

  3. 如果虚拟机健康状况不佳，您可以在健康检查状态列中查看其健康状况。

gcloud

使用 list-instances 子命令。

gcloud compute instance-groups managed list-instances MIG_NAME
    --zone ZONE

该命令会产生类似于以下内容的输出。HEALTH_STATE 字段显示每个虚拟机的运行状况。

NAME: igm-with-hc-fvz6
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

NAME: igm-with-hc-gtz3
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

替换以下内容：

  • MIG_NAME：MIG 的名称。
  • ZONE：该 MIG 所在的可用区。对于区域级 MIG，请使用 --region REGION。

REST

对于地区级 MIG，请构建一个向 listManagedInstances 方法发出的 POST 请求：

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/MIG_NAME/listManagedInstances

对于区域级 MIG，请使用区域级 MIG listManagedInstances 方法：

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/MIG_NAME/listManagedInstances

请求会返回类似于如下所示的响应，其中包括每个代管实例的 instanceHealth 字段。

{
  "managedInstances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/sproject-id/zones/zone/instances/igm-with-hc-fvz6",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6159431761228150698",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-fvz6"
    },
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/igm-with-hc-gtz3",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6622324799312181783",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-gtz3"
    }
  ]
}

运行状况

以下虚拟机运行状况可用：

  • HEALTHY：虚拟机可访问，可以建立与应用健康检查端点的连接，响应符合健康检查定义的要求。
  • DRAINING：虚拟机正在排空。与虚拟机的现有连接有时间完成，但新连接遭到拒绝。
  • UNHEALTHY：虚拟机可访问，但不符合健康检查定义的要求。
  • TIMEOUT：虚拟机无法访问，无法建立与应用健康检查端点的连接，或者虚拟机上的服务器未在指定超时时间内响应。例如，这可能是由配置错误的防火墙规则或虚拟机上的过载服务器应用造成的。
  • UNKNOWN：健康检查系统不知道虚拟机，或者其健康状况目前未知。有可能需要 10 分钟，才会开始监控 MIG 中的新虚拟机。

新虚拟机将返回 UNHEALTHY 状态，直到其经过健康检查系统的验证。

是否修复某个虚拟机取决于其运行状况：

  • 如果虚拟机的健康状况为 UNHEALTHY 或 TIMEOUT，并且其初始化期限已过，则自动修复服务会立即尝试对虚拟机进行修复。
  • 如果虚拟机的健康状况为 UNKNOWN，则 MIG 不会立即修复它。这是为了防止对健康检查信号暂时不可用的虚拟机进行不必要的修复。

如果出现以下情况，自动修复尝试可能会延迟：

  • 连续多次修复后，虚拟机的运行状况仍然不佳。
  • 实例组中存在很大一部分运行状况不佳的虚拟机。

我们希望了解您有关虚拟机运行状况值的使用场景、挑战或反馈。您可以通过 mig-discuss@google.com 向我们的团队提供您的反馈。

检查当前对虚拟机执行的操作

如果 MIG 正在创建虚拟机实例，MIG 会将该实例的只读 currentAction 字段设置为 CREATING。如果实例组附加了自动修复政策，虚拟机创建完成并运行后，MIG 会将实例的当前操作设置为 VERIFYING，并且健康检查程序将开始探测该虚拟机的应用。如果应用在其启动过程中通过了此初始健康检查，则虚拟机将通过验证，MIG 会将虚拟机的 currentAction 字段更改为 NONE。

如需检查当前对虚拟机执行的操作，请参阅查看当前对虚拟机执行的操作。

检查 MIG 是否处于稳定状态

在组级别，Compute Engine 会填充一个名为 status 的只读字段，该字段包含 isStable 标志。

如果组中的所有虚拟机正在运行且运行状况良好（即每个托管式实例的 currentAction 字段都设置为 NONE），则 MIG 将将 status.isStable 字段设置为 true。请注意，MIG 的稳定性取决于自动修复政策之外的实例组配置；举例来说，如果您的实例组采用自动扩缩机制，并且正在缩容或扩容，那么由于自动扩缩器操作的关系，MIG 会将 status.isStable 字段设置为 false。

如需检查 MIG 的 status.isStable 字段的值，请参阅检查 MIG 是否处于稳定状态。

查看历史自动修复操作

您可以使用 gcloud CLI 或 REST 查看过去的自动修复事件。

gcloud

将 gcloud compute operations list 命令和过滤条件搭配使用可以仅查看项目中自动修复的相应修复事件。

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

如需详细了解特定修复操作，请使用 describe 命令。例如：

gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b

REST

对于区域级 MIG，请向 regionOperations 资源提交 GET 请求并添加一个过滤条件，以将输出列表范围限定为 compute.instances.repair.* 事件。

GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

对于可用区级 MIG，请使用 zoneOperations 资源。

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

如需详细了解特定修复操作，请针对该特定操作提交 GET 请求。例如：

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

良好的自动修复健康检查需要具备哪些特点

自动修复健康检查应该比较保守，以免在不必要时删除并重新创建实例。如果为自动修复功能设置的健康检查过于严格，则自动修复程序可能会将繁忙的实例误认为故障实例，并且不必要地重启它们，从而降低可用性。

  • unhealthy-threshold。此值应大于 1。最好将此值设置为 3 或更大。这样可以防止在发生网络数据包丢失等罕见故障时误判。
  • healthy-threshold。对于大多数应用来说，将此值设置为 2 就足够了。
  • timeout。请将此时间值设置为一个较大的值（预期响应时间的五倍或更长时间）。这样可以防止在出现意外延迟（例如实例繁忙或网络拥堵造成的延迟）时误判。
  • check-interval。此值应介于 1 秒到超时的两倍之间（不要太长，也不要太短）。如果设置的时间太长，就不能及时发现故障实例。如果设置的时间太短，实例和网络可能会因健康检查每秒发送大量探测而变得非常繁忙。

后续步骤