从旧版健康检查迁移到分组健康检查

自 2019 年 9 月 15 日起，如果您使用的是旧版健康检查，那么您的应用会继续运行并接收健康检查，但您无法部署该应用的新版本。

本页面介绍如何从旧版健康检查升级到分组健康检查。

验证您的健康检查类型

要验证您的应用使用的健康检查的类型，请运行以下命令：

gcloud app describe

如果您的应用使用的是分组健康检查，则相应说明应包括以下信息：

featureSettings:
    splitHealthChecks: true

在升级到分组健康检查之前，请考虑旧版健康检查与分组健康检查之间的以下几项重要差异：

默认情况下，针对分组健康检查的 HTTP 请求不转发。相比之下，旧版健康检查默认转发到应用中的 /_ah/health 路径。
如果应用健康状况良好并且已准备就绪，则转发的分组健康检查必须返回 200 OK。旧版健康检查将以下 HTTP 代码视为健康状况良好：200、301、302、303、307、401、402、403、404、405。

如果您未指定活跃性检查路径或就绪性检查路径，则默认情况下，分组健康检查只会确认虚拟机实例和 Docker 容器正在运行。只要这些条件成立，虚拟机就会继续接收流量并保持活跃状态，无论应用的内部状态如何。

相比之下，启用旧版健康检查后，如果应用的 /_ah/health 路径开始返回健康状况不佳的 HTTP 错误代码（例如 5XX），则旧版健康检查将失败，同时虚拟机将停止接收流量并重启。

如果您的应用依赖于默认的旧版健康检查行为，请相应地设置活跃性检查路径和就绪性检查路径。

您可以使用分组健康检查重写每个旧版健康检查选项，如下所示：

选项	在分组健康检查中保持相同的行为
`enable_health_check`	如果为 `True` 或未设置，请将 `liveness_check.path` 和 `readiness_check.path` 配置为在应用运行状况良好时返回 `200 OK` 的应用路径。
`check_interval_sec`	将 `liveness_check.check_interval_sec` 和 `readiness_check.check_interval_sec` 配置为相同的值。
`timeout_sec`	将 `liveness_check.timeout_sec` 和 `readiness_check.timeout_sec` 配置为相同的值。
`unhealthy_threshold`	将 `readiness_check.failure_threshold` 配置为相同的值。
`healthy_threshold`	将 `liveness_check.success_threshold` 和 `readiness_check.success_threshold` 配置为相同的值。
`restart_threshold`	将 `liveness_check.failure_threshold` 配置为相同的值。请注意，`check_interval_sec` 选项值与 `failure_threshold` 选项值的乘积表示使运行状况不良的虚拟机宕机所需的时间。

如需从旧版健康检查迁移到分组健康检查，同时避免出现数值较高的 5xx 状态代码，请完成以下步骤：

了解旧版健康检查和分组健康检查之间的重要差异。
为应用中的每个版本转换旧版健康检查选项。

或者，您可以自定义每个版本的 app.yaml 文件中的 liveness_check 或 readiness_check 部分。如需查看示例，请参阅活动性检查和就绪性检查。

运行以下命令：

gcloud app update --split-health-checks --project [YOUR_PROJECT_ID]