为什么 Cloud Run 让 18 个（成本非常高）容器一直闲置？

Question

我有一个云运行服务。它的设置是为了处理零星的科学数据处理任务。

它有min_instances=1，max_instances=40. 它会在没有任何活性物质的情况下静置，然后每周几次爆发至 5-10 个活性容器。

这是第二代运行时。

我们在GCP上的账单逐渐增加，我们并没有考虑太多（因为使用量增加了）；但最近我们做了很多工作来简化服务和降低成本，但这些工作都没有达到预期的成本降低效果。深入研究成本 SKU 单位（用户体验噩梦，GCP 确实需要更好的细分能力），我发现成本的绝大部分来自 Cloud Run 中的空闲 CPU 和空闲 RAM。

梳理我们拥有的 10 多个 Cloud Run 服务，其中两个表现出非常奇怪的行为：空闲实例数量非常高。在下面的例子中，我们有 18 台机器持续运行。这些机器也不便宜！

关于 Cloud Run 自动扩展的文档非常清楚：“为了最大限度地减少冷启动的影响，Cloud Run 可能会让某些实例空闲最多 15 分钟。” 但这些容器是永久打开的。

怎么max_instances=1可能有18个空闲实例一直在运行呢？

Answer 1

事后分析后回答我自己的问题。

每次我们合并到 GitHub 上的 main 时，CI/CD 系统都会自动发布服务的新版本。然后 100% 的流量被定向到新版本。

Cloud Run 上的每个修订版都标有该版本的代码版本（例如v0-1-2version 0.1.2）。看起来很明智，因为它允许我们直接回滚到给定版本。

自从我们实施 CI 系统以来，我们已经发布了 18 个版本。事实证明，如果您标记某个修订版，即使没有流量流向该修订版，Cloud Run 也会保持该修订版处于活动状态，并尊重其min_instances参数。

revision_url这是为了允许流量通过从标签派生的路由到特定版本，而不管流量路由设置如何。

但是，这阻止我们关闭服务修订。只有两种方法可以关闭旧版本，这样您的成本就不会随着时间的推移而呈指数增长：

• 删除它的标签（我觉得这很疯狂，因为标签是你知道哪个版本是哪个版本的方式）

• 复制旧版本的设置，将它们复制到新版本，覆盖min_instances为 0，发布新版本，将旧标签应用到新版本（完全不诚实，因为它根本不是相同的版本）。

• 永远不要设置min_instances参数

如果 GCP 的任何人读到这篇文章，那么向某些东西添加标签不应该成为它是否保持活动的谓词。我们可以更改以激活/停用服务修订版的标志active将非常有益。