为工作器池配置容器健康检查

您可以为新的和现有的 Cloud Run 工作器池配置 HTTP、TCP 和 gRPC 启动探测以及 HTTP 和 gRPC 活跃性探测。具体配置会因探测类型而异。

使用场景

您可以配置两种类型的健康检查探测：

• 活跃性探测确定是否重启容器。

  • 在这种情况下，重启容器可以在出现 bug 时提高工作器池的可用性。
  • 重要提示：活跃性探测旨在重启无法以任何其他方式恢复的单个实例。它们主要应该用于不可恢复的实例故障，例如，捕获工作器池正在运行但无进展的死锁。您可以使用自定义组织政策，要求每个容器都进行活跃性探测。

• 启动探测用于确定容器是否已启动。

  • 配置启动探测时，系统将停用活跃性检查，直到启动探测确定容器已启动，以防止干扰工作器池启动。
  • 如果您对慢启动容器使用活跃检查，则启动探测特别有用，因为它可以防止在容器启动和运行之前过早关停。

请注意，当工作器池遇到重复的启动或活跃性探测失败时，Cloud Run 会限制实例重启，以防止不受控制的崩溃循环。

CPU 分配

• 当探测运行时，系统始终会分配 CPU。
• 所有探测都按 CPU 和内存用量计费。

探测要求和行为

配置探测

任何配置更改都会导致新修订版本的创建。后续修订版本也将自动采用此配置设置，除非您进行了明确更新。

您可以使用 Cloud Run REST API 配置 HTTP、TCP 和 gRPC 探测：

创建 HTTP 健康检查端点

如果您为 Cloud Run 工作器池配置了 HTTP 启动探测或活跃性探测，则需要在工作器池代码中添加端点以响应探测。端点可以指定为任何所需的名称（例如 /startup 或 /ready），但名称必须与您在探测配置中为 path 指定的值相匹配。例如，如果您为 HTTP 启动探测指定了 /ready，请在探测配置中指定 path，如下所示：

startupProbe:
  httpGet:
    path: /ready

HTTP 健康检查端点可从外部访问，并且遵循与在外部公开的任何其他 HTTP 端点相同的原则。