设置运行状况检查和自动修复

代管实例组 (MIG) 通过主动保持虚拟机 (VM) 实例可用（即处于 RUNNING 状态）来维护应用的高可用性。如果代管实例停止运行，但状态更改不是由 MIG 发起的，MIG 会自动重新创建该实例。另一方面，如果 MIG 有意停止处于 RUNNING 状态的实例（例如，当自动扩缩器删除实例时），则 MIG 不会重新创建该实例。

不是由 MIG 发起的实例状态更改包括：

硬件故障。
终止抢占式实例。
在 Compute Engine API 或 gcloud 命令行工具中使用 instances.delete 方法（而非 instanceGroupManagers.deleteInstances 方法）删除 MIG 实例。
基础架构维护事件（当虚拟机实例未设置为实时迁移时）。

但是，依靠实例的状态来确定应用运行状况可能不够。例如，检查实例是否处于 RUNNING 状态并不会检测应用故障，例如冻结，过载或崩溃。

如需进一步提高应用的可用性以及验证应用是否能正常响应，可以为 MIG 配置自动修复政策。

自动修复政策依赖于基于应用的运行状况检查来验证应用是否按预期响应。与仅验证虚拟机是否处于 RUNNING 状态相比，检查应用是否响应可以获得更加精准的结果。

如果自动修复程序确定应用没有响应，则 MIG 会自动重新创建该虚拟机。对于抢占式虚拟机，该组会在必要的资源变得再次可用时重新创建虚拟机。

自动修复行为

自动修复功能使用用于创建虚拟机的原始实例模板（不一定是 MIG 中的当前实例模板）重新创建运行状况不佳的虚拟机。例如，如果虚拟机原先是使用 instance-template-a 创建的，然后您更新 MIG 以在 OPPORTUNISTIC 模式下使用 instance-template-b，则自动修复仍会使用 instance-template-a 重新创建该虚拟机。这是因为自动修复的重新创建操作不是用户启动的，所以 Compute Engine 不会假定虚拟机应该使用新模板。如果要应用新模板，请参阅更改 MIG 的实例模板。

在任何给定时间，并发自动修复的虚拟机数量都比 MIG 的规模小。这可确保即使出现以下情况，实例组仍可以持续运行一部分虚拟机：自动修复政策不适合工作负载，防火墙规则配置错误，或者某些网络连接或基础架构问题导致系统将运行状况良好的虚拟机错误地识别为运行状况不佳。但是，如果区域级 MIG 只有一个虚拟机，或者地区级 MIG 在每个区域只有一个虚拟机，则自动修复会在这些虚拟机运行状况不佳时重新创建它们。

自动修复不会在虚拟机的初始化期间重新创建虚拟机。如需了解详情，请参阅 autoHealingPolicies[].initialDelaySec 属性。此设置会延迟自动修复功能检查该虚拟机的时间，以避免在虚拟机启动过程中过早地重新创建虚拟机。初始延迟计时器从虚拟机的 currentAction 为 VERIFYING 时开始计时。

首次将运行状况检查附加到代管实例组时，可能需要 30 分钟才能开始进行监控。

自动修复和磁盘

在基于模板重新创建虚拟机时，自动修复程序会以不同方式处理不同类型的磁盘。在尝试重新创建虚拟机时，某些磁盘配置可能会导致自动修复程序失败。

磁盘类型	`autodelete`	在自动修复操作期间的行为
新的永久性磁盘	`true`	如实例模板中所指定的那样重新创建磁盘。重新创建磁盘及其虚拟机时，原来写入该磁盘的所有数据都将丢失。
新的永久性磁盘	`false`	在自动修复程序重新创建虚拟机时保留并重新连接磁盘。
现有的永久性磁盘	`true`	旧磁盘已删除。虚拟机重新创建失败，因为 Compute Engine 无法将已删除的磁盘重新挂接到虚拟机。
现有的永久性磁盘	`false`	如实例模板中所指定的那样重新附加旧磁盘。磁盘上的数据会保留。但是，对于现有的读写磁盘，MIG 最多只能有一个虚拟机，因为单个永久性磁盘无法以读写模式挂接到多个虚拟机。
新的本地 SSD	无	如实例模板中所指定的那样重新创建磁盘。在重新创建或删除虚拟机时，本地 SSD 上的数据将丢失。

自动修复程序不会重新挂接实例模板中未指定的磁盘，例如在创建虚拟机后手动挂接到该虚拟机的磁盘。

如需保留写入磁盘的重要数据，请采取一些预防措施，例如：

拍摄常规永久性磁盘快照。
将数据导出到其他来源，例如 Cloud Storage。
配置有状态永久性磁盘。

如果您的虚拟机具有要保留的重要设置，Google 还建议您在实例模板中使用自定义映像。自定义映像包含您需要的任何自定义设置。在实例模板中指定自定义映像时，MIG 会使用包含所需自定义设置的自定义映像重新创建虚拟机。

设置运行状况检查和自动修复政策

您最多可以为每个 MIG 设置一项自动修复政策。

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

运行状况检查设置示例

以下示例演示了如何对 MIG 使用运行状况检查。在此示例中，您将创建运行状况检查，使其在端口 80 上查找 Web 服务器响应。如需使运行状况检查探测能够访问每个 Web 服务器，请配置防火墙规则。最后，通过设置 MIG 的自动修复政策，将运行状况检查应用于该实例组。

执行此任务所需的权限

您必须拥有以下权限才能执行此任务：

针对项目的 compute.healthChecks.create 权限（如果创建新的运行状况检查）。
针对要使用的运行状况检查的 compute.healthChecks.use 权限。
针对项目的 compute.firewalls.create 权限（如果创建新的防火墙）。
针对网络的 compute.networks.updatePolicy 权限（如果创建新的防火墙）。
针对 MIG 的 compute.instanceGroupManagers.update 权限。

这些权限是以下预配置角色中的可用权限。

compute.networkAdmin（用于创建运行状况检查）。
compute.securityAdmin（用于配置防火墙规则以允许运行状况检查进行连接）。
compute.instanceAdmin.v1（用于在 MIG 中创建和更新自动修复政策）。

控制台

为自动修复创建运行状况检查，这种检查比负载平衡运行状况检查更加保守。

例如，创建一个查找端口 80 响应的运行状况检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在本示例中，如果虚拟机成功返回一次，则会被标记为“运行状况良好”。如果连续 3 次未能成功返回，则会被标记为“运行状况不佳”。
1. 在 Google Cloud Console 中，转到创建运行状况检查页面。
  转到“创建运行状况检查”页面
2. 为此运行状况检查指定名称，例如 example-check。
3. 对于协议，请确保选中 HTTP。
4. 对于端口，请输入 80。
5. 对于检查间隔，请输入 5。
6. 对于超时，请输入 5。
7. 设置状况良好判断阈值，指定运行状况不佳的虚拟机必须连续多少次返回成功的运行状况检查，才能被标记为运行状况良好。对于此示例，请输入 1。
8. 设置状况不佳判断阈值，指定运行状况良好的虚拟机必须连续多少次返回不成功的运行状况检查，才能被标记为运行状况不佳。对于此示例，请输入 3。
9. 点击创建以创建运行状况检查。
创建防火墙规则以允许运行状况检查探测连接到您的应用。

注意：如果运行状况检查探测被防火墙规则阻止，则会因无法连接到应用而将您的虚拟机标记为 UNHEALTHY。在这种情况下，运行状况可能良好的虚拟机也会被自动重新创建。

运行状况检查探测请求来自 130.211.0.0/22 和 35.191.0.0/16 范围内的地址，因此请确保您的网络防火墙规则允许运行状况检查进行连接。在本示例中，我们的 MIG 使用的是 default 网络，并且其虚拟机侦听的是端口 80。如果端口 80 尚未在默认网络中打开，请创建防火墙规则。
1. 在 Google Cloud Console 中，转到创建防火墙规则页面。
  转到“创建防火墙规则”页面
2. 对于名称，请为防火墙规则输入一个名称，例如 allow-health-check。
3. 对于网络，请选择 default 网络。
4. 对于来源过滤条件，请选择 IP ranges。
5. 对于来源 IP 地址范围，请输入 130.211.0.0/22 和 35.191.0.0/16。
6. 在协议和端口中，选择指定的协议和端口并输入 tcp:80。
7. 点击创建。
为地区级或区域级 MIG 组配置自动修复政策以应用运行状况检查。
1. 在 Google Cloud Console 中，转到实例组页面。
  转到“实例组”页面
2. 在列表的名称列下方，点击要应用运行状况检查的 MIG 的名称。
3. 点击修改组以修改此 MIG。
4. 在自动修复下方，选择您之前创建的运行状况检查。
5. 更改或保留初始延迟时间设置。此设置会延迟自动修复功能的初始检查，以避免在虚拟机启动过程中过早地重新创建虚拟机。初始延迟计时器从虚拟机的 currentAction 为 VERIFYING 时开始计时。
6. 点击保存以应用更改。

gcloud

如需使用本指南中的命令行示例，请安装 gcloud 命令行工具，或使用 Cloud Shell。

为自动修复创建运行状况检查，这种检查比负载平衡运行状况检查更加保守。

例如，创建一个查找端口 80 响应的运行状况检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在本示例中，如果虚拟机成功返回一次，则会被标记为“运行状况良好”。如果连续 3 次未能成功返回，则会被标记为“运行状况不佳”。
```
gcloud compute health-checks create http example-check --port 80 \
       --check-interval 30s \
       --healthy-threshold 1 \
       --timeout 10s \
       --unhealthy-threshold 3
```
注意：请使用支持 HTTP、HTTPS、TCP 和 SSL (TLS) 协议的新版运行状况检查。旧版 Compute Engine HTTP/HTTPS 运行状况检查继续有效。
创建防火墙规则以允许运行状况检查探测连接到您的应用。

运行状况检查探测请求来自 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
```
为地区级或区域级 MIG 组配置自动修复政策以应用运行状况检查。

使用 update 命令将运行状况检查应用于 MIG。

initial-delay 设置会延迟自动修复功能的初始检查，以避免在虚拟机启动过程中过早地重新创建虚拟机。初始延迟计时器从虚拟机的 currentAction 为 VERIFYING 时开始计时。

例如：
```
gcloud compute instance-groups managed update my-mig \
        --health-check example-check \
        --initial-delay 300 \
        --zone us-east1-b
```
注意：set-autohealing 命令已弃用，最终将被移除。请改用 update 命令。

API

如需使用本指南中的 API 示例，请设置 API 访问权限。

为自动修复创建运行状况检查，这种运行状况检查比负载平衡运行状况检查更加保守。

例如，创建一个查找端口 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
}
```
注意：请使用支持 HTTP、HTTPS、TCP 和 SSL (TLS) 协议的新版运行状况检查。旧版 Compute Engine HTTP/HTTPS 运行状况检查继续有效。
创建防火墙规则以允许运行状况检查探测连接到您的应用。

运行状况检查探测请求来自 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"
  }
 ]
}
```
为地区级或区域级 MIG 组配置自动修复政策以应用运行状况检查。

自动修复政策是 instanceGroupManager 资源或 regionInstanceGroupManager 资源的一部分。

您可以使用 insert 或 patch 方法设置自动修复政策。

警告：instanceGroupManagers.setAutohealingPolicies 和 regionInstanceGroupManager.setAutohealingPolicies 方法不属于正式版 API，将会被弃用。请改用 insert 和 patch 方法。
以下示例使用 instanceGroupManagers.patch 方法设置自动修复政策。
```
PATCH https://compute.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
{
  "autoHealingPolicies": [
    {
      "healthCheck": "global/healthChecks/example-check",
      "initialDelaySec": 300
    }
  ],
}
```
initialDelaySec 设置会延迟自动修复功能的初始检查，以避免在虚拟机启动过程中过早地重新创建虚拟机。初始延迟计时器从虚拟机的 currentAction 为 VERIFYING 时开始计时。

如需关闭基于应用的自动修复，请将自动修复政策设置为空值，即 autoHealingPolicies[]。设置为 autoHealingPolicies[] 以后，MIG 仅重新创建未处于 RUNNING 状态的虚拟机。

您可以通过读取 instanceGroupManagers.autoHealingPolicies 字段来获取 MIG 的自动修复政策。您可以使用以下某个方法获取 MIG 资源：
- instanceGroupManagers.get 返回指定的地区代管实例组资源。
- instanceGroupManagers.list 返回指定项目和地区中的所有区域级 MIG。
- regionInstanceGroupManagers.get 返回指定的地区级 MIG 资源。
- regionInstanceGroupManagers.list 返回指定项目和地区中的所有地区级 MIG。

实例组创建或运行状况检查配置更新完成后，最多可能要等候 30 分钟，自动修复才会开始监控实例组中的实例。监控开始后，Compute Engine 会开始根据您的自动修复配置将实例标记为运行状况良好（或重新创建实例）。例如，如果您配置的初始延迟时间为 5 分钟，运行状况检查间隔为 1 分钟，并且运行状况阈值为 1 次检查，时间安排会如下所述：

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

检查状态

通过检查每个虚拟机的当前运行状况、检查对每个虚拟机的当前操作或检查实例组的状态，您可以验证虚拟机是否已创建以及其应用是否正在响应。

检查虚拟机的运行状况是否良好

如果您为 MIG 配置了自动修复，则可以检查每个代管实例的运行状况。

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

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

使用控制台、gcloud 命令行工具或 API 查看运行状况。

执行此任务所需的权限

您必须拥有以下权限才能执行此任务：

针对 MIG 的 compute.instanceGroupManagers.get 权限

控制台

在 Google Cloud Console 中，转到实例组页面。
转到“实例组”页面。
在列表的名称列下方，点击要检查的 MIG 的名称。随即打开的页面中会显示实例组属性以及其中所含的虚拟机列表。
如果虚拟机运行状况不佳，您可以在运行状况检查状态列中查看其运行状况。

gcloud

使用 list-instances 子命令。

gcloud compute instance-groups managed list-instances instance-group
NAME              ZONE                  STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE                            VERSION_NAME  LAST_ERROR
igm-with-hc-fvz6  europe-west1          RUNNING  HEALTHY       NONE    my-template
igm-with-hc-gtz3  europe-west1          RUNNING  HEALTHY       NONE    my-template

HEALTH_STATE 列显示每个虚拟机的运行状况。

API

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

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

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

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

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

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

运行状况

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

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

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

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

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

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

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

我们希望了解您有关虚拟机运行状况值的使用场景、挑战或反馈。请发送至 mig-discuss@google.com，与我们的团队分享您的反馈。

查看当前对虚拟机的操作

在创建虚拟机的过程中，该实例的 currentAction 为 CREATING。如果实例组附加了自动修复政策，虚拟机一旦创建完成并运行，该实例的 currentAction 将变为 VERIFYING，并且运行状况检查程序将开始探测该虚拟机的应用。如果应用在其启动过程中通过了此初始运行状况检查，则该虚拟机将通过验证且其 currentAction 将变为 NONE。

您可以使用 gcloud 命令行工具或 Compute Engine API 查看代管实例组中每个实例正在执行的 currentAction 以及 status。

执行此任务所需的权限

您必须拥有以下权限才能执行此任务：

对群组的 compute.instanceGroupManagers.get 权限
对群组的 compute.instanceGroupManagers.list 权限

gcloud

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

该命令会返回 MIG 中的实例列表及其状态和当前操作。例如：

NAME               ZONE           STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f                          CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING                DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING                 NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING                 NONE      my-old-template

该 HEALTH_STATE 列显示为空，除非您设置运行状况检查。

API

对区域或可用区 MIG 资源调用 listManagedInstances 方法。例如：

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

调用会返回 MIG 的实例列表，其中包含每个实例的 instanceStatus 和 currentAction。

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  }
 ]
}

如需查看有效 instanceStatus 字段值的列表，请参阅检查实例的状态。

如果实例正在进行某种更改，则其 currentAction 字段会填充以下操作之一，以帮助您跟踪更改进度。否则，currentAction 字段为 NONE。

可能的 currentAction 值如下：

ABANDONING：正在将该实例从 MIG 中移除。
CREATING：正在创建实例。
CREATING_WITHOUT_RETRIES：正在创建该实例，且不会重试；如果第一次尝试并未创建该实例，则 MIG 将不会再次尝试替换该实例。
DELETING：正在删除实例。
RECREATING：该实例正在被替换。
REFRESHING：该实例正从其当前目标池中移除，并正在被读取到当前目标池列表中（此列表与现有目标池可能相同，也可能不同）。
RESTARTING：正在使用 stop 和 start 方法重启该实例。
VERIFYING：该实例已创建并且正在接受验证。
NONE：当前并未对该实例执行任何操作。

验证 MIG 是否处于稳定状态

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

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

通过检查实例组的 status.isStable 字段的值来验证代管实例组中的所有实例是否正在运行且状况良好。

gcloud

使用 describe 命令：

gcloud compute instance-groups managed describe instance-group-name \
    [--zone zone | --region region]

gcloud 工具会返回 MIG 的详细信息，包括其 status.isStable 字段。

如需暂停脚本直至 MIG 稳定，请将 wait-until 命令与 --stable 标志结合使用。例如：

gcloud compute instance-groups managed wait-until instance-group-name \
    --stable \
    [--zone zone | --region region]
Waiting for group to become stable, current operations: deleting: 4
Waiting for group to become stable, current operations: deleting: 4
...
Group is stable

该命令会在 MIG 的 status.isStable 设置为 true 后返回。

API

对于地区级 MIG，请向 instanceGroupManagers.get 方法发出 GET 请求：

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name/get

对于地区代管实例组，请将 zones/zone 替换为 regions/region：

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/get

Compute Engine API 会返回有关 MIG 的详细信息，其中包括其 status.isStable 字段。

status.isStable 设置为 false 表示更改已生效、待处理或者 MIG 本身正被修改。

status.isStable 设置为 true 时，则表示以下含义：

MIG 中的任何实例都未在进行任何类型的更改，并且所有实例的 currentAction 均为 NONE。
MIG 中的实例没有任何待处理的更改。
MIG 本身未在修改。

请注意，MIG 的稳定性取决于许多因素，因为 MIG 能够以多种方式修改。例如：

发出发布新实例模板的请求。
发出创建、删除、调整或更新 MIG 中实例的请求。
通过自动扩缩器请求调整 MIG 的大小。
通过自动修复程序资源替换 MIG 中一个或多个运行状况不佳的实例。
重新分配区域 MIG 中的部分实例。

完成所有操作后，该 MIG 的 status.isStable 会立即重新设置为 true。

查看历史自动修复操作

您可以使用 gcloud 工具或 API 查看过去的自动修复事件。

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

API

对于地区级 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，请使用 zoneOoperations 资源。

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 秒到超时的两倍之间（不要太长，也不要太短）。如果设置的时间太长，就不能及时发现故障实例。如果设置的时间太短，实例和网络可能会因运行状况检查每秒发送大量探测而变得非常繁忙。

后续步骤

试用对高可用性应用使用自动修复功能教程。
详细了解实例组。
为 MIG 启用自动扩缩功能。
为 MIG 启用负载平衡功能。