我正在尝试设置一个 readiness_check
对于我的应用程序。这是我的 app.yaml
的相关部分:
readiness_check:
path: '/readiness_check'
check_interval_sec: 30
timeout_sec: 4
failure_threshold: 10
success_threshold: 1
app_start_timeout_sec: 300
( Full config )
我正在开发的项目是一个在 Express 上运行的 Node.js 应用程序。这是我的处理方式
/readiness_check
端点:app
.get(['/readiness_check'], (req, res) => res.sendStatus(200))
无
readiness_check
配置,我的部署过程成功,我可以毫无问题地访问我的应用程序。但是,当我包含 readiness_check
时,该过程失败并出现以下错误:OperationError: Error Response: [4] Your deployment has failed to become healthy in the allotted time and therefore was rolled back. If you believe this was an error, try adjusting the 'app_start_timeout_sec' setting in the 'readiness_check' section.
我检查了日志,我可以看到
/readiness_check
返回 502
起初(当应用程序仍在启动时)然后开始返回 200
状态码。使用 curl
访问端点手动显示相同的结果。但仍然出于某种原因,GCP 认为我的部署并不健康。运行
gcloud app describe
确认我有 splitHealthChecks
功能启用。我走过troubleshooting sections in the documentation然后发现我没有
servicecontrol.googleapis.com
和 endpoints.googleapis.com
服务已启用,所以我启用了它们,但这也无济于事。我还在文档中看到了以下注释:
If you examine the nginx.health_check logs for your application, you might see health check polling happening more frequently than you have configured, due to the redundant health checkers that are also following your settings. These redundant health checkers are created automatically and you cannot configure them.
这可能是一个无关的问题,但我找不到
nginx.health_check
在我的应用程序日志中。我试图搜索“nginx”文本,但没有看到与健康检查相关的任何内容。虽然在寻找“readiness_check”,但它确实向我展示了我上面提到的响应。
最佳答案
可能有更多可能的方法来解决这个问题:
1) 您可以增加 resources
中的值您的 app.yaml
中的标题文件。您可以查看更多相关信息 here .
2) 您可以增加 app_start_timeout_sec
的值至 the maximum value ,即 1800。这样你就可以给你的应用更多的时间来变得健康。
3)尽管如此,运行 gcloud app describe
确认您已启用 splitHealthChecks 功能,您是否执行了从旧版本迁移健康检查的所有正确步骤?它是否适用于您应用程序的所有版本,甚至是旧版本?
您可以仔细检查转换健康检查所需采取的所有步骤 here .应用命令 gcloud app update --split-health-checks --project [YOUR_PROJECT_ID]
可能还不够。
编辑:
即使,理论上,如果您没有 split your traffic across different versions ,这应该不是问题(我想不出为什么会这样)。在关于迁移的文档中,在第 2 步中,它说:
Convert legacy health check options for each version in your application.
为此,您应该编写并更新
app.yaml
相应地针对每个版本,然后将服务部署为 assigned to a certain version ID .例如:gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote
4) 作为一种解决方法,您可以“伪造”
readiness_check
响应,在一定时间后给出 200 状态响应。您必须在 this section 中添加自定义处理程序.这样部署就不会超时,并且会继续在后台工作。但是,这会错过就绪检查的目的,因为您的实例可能会在尚未准备好时接收流量。如果您考虑到这一点,并且可以在您的应用程序中处理这个问题,那么这将是一个可以考虑的选项。最后,我假设您使用的是 App Engine Flex,至于标准版本,健康检查不可用并且会出现错误。您可以查看 this discussion here .
关于google-app-engine - 尽管 readiness_check 返回 200 状态响应,但 Google App Engine 应用程序部署失败,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59580867/