时间戳

首页 > 解决方案 > 如何以编程方式更新谷歌云运行上的流量切换？

google-cloud-run - 如何以编程方式更新谷歌云运行上的流量切换？

问题描述

我正在尝试通过 CI/CD 作业将新修订版部署到 Cloud Run，并立即开始为新修订版提供 100% 的流量。

该服务不是面向客户的，我们不需要金丝雀部署或流量拆分。

目前该图像是在 gitlab ci 管道中构建的并已发布 gcr。下一步是gcloud run deploy命令。该命令运行良好，我得到了一个新版本。然而，0% 的流量被提供给这个版本，我一辈子都无法弄清楚如何以编程方式管理它。

我能从常见问题解答中找到的唯一相关信息是：

但是，Cloud Run（当​​前）仅支持从您的服务的最后一个健康版本中提供流量。因此，它目前不支持基于修订的流量拆分和金丝雀部署。

但它似乎已经过时了，因为我目前可以通过 UI 手动拆分修订之间的流量。任何澄清将不胜感激。谢谢！

标签： google-cloud-run

解决方案

（您链接的常见问题解答回购已过时，因为我坚持我会更新它，感谢您的提醒。）

Cloud Run 现在提供流量拆分。简而言之，它的工作原理如下：

  • 如果没有适当的流量拆分（最新=100%），gcloud run deploy将使新修订版 100%
  • 如果存在拆分，gcloud run deploy将使新修订版为 0%。

为防止新修订获得流量，您可以显式使用--no-traffic.

如果您想以编程方式拆分流量，我建议您这样做：

  1. 在新部署之前将最新版本（鉴于它稳定/良好）提升到 100%：

    gcloud run services update-traffic --to-revisions=LATEST=100 [...]

    （但是，如果您的最新修订版不好，并且您不愿意为其发送 100% 流量，那么您实际上需要找到修订版名称并使用它来代替LATEST）

  2. 部署新修订：

    gcloud run deploy [...] --no-traffic

  3. 向新版本发送少量流量：

    gcloud run services  update-traffic --to-revisions=LATEST=5 [...]

    当你运行它时，新版本将获得 5%，其余的将获得，之前的版本将获得 95%。

对上述方法的警告：（@Steren 在下面的评论中提到了这一点。）如果您可能在近距离发生多个部署（想象两个git pushes 触发部署），则 LATEST 可能会无意中指向错误的修订。Steren 的建议是：

相反，使用gcloud run deploy [...] --revision-suffix=1234 --no-trafficand then gcloud run services update-traffic --to-revisions service-1234=10。

您还可以为修订提供友好的名称（“标签”），但是目前无法在它们之间拆分流量。( #ahmetb-todo) 使用该功能，您将能够部署修订并为其命名"candidate"，然后在拆分流量时引用它，而不是复杂的自动生成的修订名称。

或者，您可以通过使用gcloud run services replace命令部署 YAML 清单来管理修订之间的流量。这涉及了解 Knative API 的工作原理。以下是一些可能相关的文档：

推荐阅读