从旧版运行状况检查迁移到分组运行状况检查

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

本页面介绍如何从旧版运行状况检查升级到分组运行状况检查

验证您的运行状况检查类型

要验证您的应用使用的运行状况检查的类型,请运行以下命令:

gcloud app describe

如果您的应用使用的是分组运行状况检查,则相应说明应包括以下信息:

featureSettings:
    splitHealthChecks: true

了解主要区别

在升级到分组运行状况检查之前,请考虑旧版运行状况检查与分组运行状况检查之间的以下几项重要区别:

  • 默认情况下,针对分组运行状况检查的 HTTP 请求不会转发。相比之下,旧版运行状况检查默认转发到应用中的 /_ah/health 路径。

  • 如果应用运行状况良好并且准备就绪,则转发的分组运行状况检查必须返回 200 OK 旧版运行状况检查将以下 HTTP 代码视为运行状况良好:200301302303307401402403404405

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

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

如果您的应用依赖于默认的旧版运行状况检查行为,请相应地设置活跃性检查路径就绪性检查路径

转换旧版运行状况检查选项

您可以使用分组运行状况检查重写每个旧版运行状况检查选项,如下所示:

选项 在分组运行状况检查中保持相同的行为
enable_health_check 如果该选项设置为 True 或未进行设置,请将 liveness_check.pathreadiness_check.path 配置为在应用运行状况良好时返回 200 OK 的应用路径。
check_interval_sec liveness_check.check_interval_secreadiness_check.check_interval_sec 配置为相同的值。
timeout_sec liveness_check.timeout_secreadiness_check.timeout_sec 配置为相同的值。
unhealthy_threshold readiness_check.failure_threshold 配置为相同的值。
healthy_threshold liveness_check.success_thresholdreadiness_check.success_threshold 配置为相同的值。
restart_threshold liveness_check.failure_threshold 配置为相同的值。请注意,check_interval_sec 选项乘以 failure_threshold 选项所得的值就是运行状况不佳的虚拟机关停所需的时间。

启用分组运行状况检查

要从旧版运行状况检查迁移到分组运行状况检查,并避免出现更高的 5xx 状态代码,请完成以下步骤:

  1. 了解旧版运行状况检查和分组运行状况检查之间的重要区别

  2. 对应用中的每个版本转换旧版运行状况检查选项

    或者,您可以在 liveness_check 文件中针对每个版本自定义 readiness_checkapp.yaml 部分。如需查看示例,请参阅活跃性检查就绪性检查

  3. 运行以下命令:

    gcloud app update --split-health-checks --project [YOUR_PROJECT_ID]
  4. 如果您对旧版运行状况检查使用了自定义设置,则必须从 app.yaml 文件中移除 health_check 部分。

  5. 部署一个新的应用主版本,以开始使用活动性和就绪性运行状况检查。