处理 Cloud Run 容器关闭答案

【问题标题】：Handling a Cloud Run container shutdown处理 Cloud Run 容器关闭
【发布时间】：2020-04-16 20:22:13
【问题描述】：

在编写 Cloud Run 服务时，我们开发了一个容器来侦听 PORT 环境变量以处理传入的 HTTP 请求。容器的一个实例会启动并处理请求，然后在结束原始请求后会再存活一段时间，以防有进一步的请求到达。如果没有进一步的请求，GCP 关闭容器。正是在这个领域，我有一个问题。

容器内是否有钩子、信号或其他指示容器正在关闭？

在我的示例中，我的容器想要干净地结束。也许它想关闭连接或执行一些快速刷新缓存。

【问题讨论】：

我会尝试监听SIGTERM 信号，看看它是否会触发。这是标准 docker 容器关闭序列的一部分，我猜这里会发生类似的事情。
我在 Cloud Run 上找到了一个非常好的常见问题解答，其中有一个答案……请参阅……github.com/ahmetb/…
请记住，您仅在实例处理请求时才计费，而在这里，您希望在请求之外执行一些处理（不计费）。 您需要有一个强有力的用例来证明这一点！ 本着 Cloud Run 的精神，该服务是无状态的。我可以理解，必须关闭连接以防止任何守护程序连接到外部服务，但在 Cloud Run 容器合同中，刷新缓存不是有效用例。
@guillaumeblaquiere - 这是个好主意！谢谢你。这让我想到了推论……那就是“我们是否需要为在收到请求之前发生的处理/启动时间付费？”。我的猜测是肯定的，并开辟了一条全新的考虑途径（面向未来）。
@johnmich，如果您 ping Cloud Run，您可以防止冷启动（如果它是您服务的最新活动实例）。我在this article 中描述了这一点。但是触发关闭的实例将关闭。

标签： google-cloud-platform google-cloud-run

【解决方案1】：

已找到关于 Cloud Run 的精彩问答常见问题解答here。在该常见问题解答中，有一项内容如下：

Cloud Run 服务的终止信号是什么？

目前， Cloud Run 终止容器，同时使用 unix 信号缩放到零 9（SIGKILL）。 SIGKILL 不能被应用程序捕获（捕获）。因此，您的应用程序应该可以被突然终止。

一个相关且重要的条目还显示：

我的服务何时会缩小到零？

Cloud Run 不保证它将保留多长时间服务“热情”。这取决于容量和谷歌的等因素实现细节。

一些用户发现他们的服务可以保持一个小时或更长时间。

意见

我觉得有趣的是这个故事似乎是即时的SIGKILL。如果我们将 Docker 作为容器环境的基础，我们可以阅读有关 docker stop 的信息，这似乎是干净地停止容器的方法。在它自己的描述中它说：

容器内的主进程会收到SIGTERM，之后宽限期，SIGKILL。

这似乎表明对于正常 Docker 容器停止，运行容器的进程将收到一个信号。

【讨论】：

【解决方案2】：

SIGTERM（unix 信号 15）现在发送到 Cloud Run 服务，如果您在代码中处理信号，您有 10 秒的时间来处理关闭任何资源等。

见here。

容器实例可以随时关闭。当一个容器实例需要关闭，新的传入请求被路由到当前正在处理的其他实例和请求有时间去完成。然后容器实例接收到一个 SIGTERM 信号指示关闭前 10 秒的时间段的开始（带有 SIGKILL 信号）。在此期间，容器实例为分配 CPU 并计费。如果容器实例没有捕获 SIGTERM 信号，立即关闭。

（取自here的代码图片）

【讨论】：