我正在尝试通过 CI/CD 作业将新修订版部署到 Cloud Run,并立即开始为新修订版提供 100% 的流量。
此服务不是面向客户的,我们不需要金丝雀部署或流量拆分。
目前该图像是在 gitlab ci 管道中构建并发布的 gcr。下一步是gcloud run deploy命令。该命令工作正常,我得到了一个新的修订版。然而,0% 的流量被提供给这个版本,我一生都无法弄清楚如何以编程方式管理它。
gcloud run deploy --help我能找到的唯一相关信息来自常见问题解答:
但是,Cloud Run(当前)仅支持从您的服务的最后一个健康版本提供流量。因此,它目前不支持基于修订的流量拆分和金丝雀部署。
但它似乎已经过时了,因为我目前可以通过 UI 手动在修订之间拆分流量。任何澄清将不胜感激。谢谢!
(您链接的 FAQ 存储库已过时,因为我坚持认为我会更新它,感谢您的提醒。)
Cloud Run 现在提供流量拆分。简而言之,它是如何工作的:
gcloud run deploy将使新修订版 100%gcloud run deploy将使新修订为 0%。为防止新修订获得流量,您可以明确使用--no-traffic.
如果您想以编程方式拆分流量,我建议您这样做:
在新部署之前将最新版本(假设它稳定/良好)提升到 100%:
gcloud run services update-traffic --to-revisions=LATEST=100 [...]
Run Code Online (Sandbox Code Playgroud)
(但是,如果您的最新版本不好,并且您不愿意向其发送 100% 流量,那么您实际上需要找到版本名称并使用它来代替LATEST)
部署新版本:
gcloud run deploy [...] --no-traffic
Run Code Online (Sandbox Code Playgroud)发送少量流量到新版本:
gcloud run services update-traffic --to-revisions=LATEST=5 [...]
Run Code Online (Sandbox Code Playgroud)
运行此程序时,新修订版将获得 5% 和其余的,而先前修订版将获得 95%。
对上述方法的警告:(@Steren 在下面的评论中提到了这一点。)如果您可能在很近的时间发生多个部署(想象两个
git pushes 触发部署),则 LATEST 可能会无意中指向错误的修订版。斯特伦的建议是:相反,使用
gcloud run deploy [...] --revision-suffix=1234 --no-traffic然后gcloud run services update-traffic --to-revisions service-1234=10。
您还可以为修订提供友好名称(“标签”),但目前无法在它们之间拆分流量。( #ahmetb-todo) 使用该功能,您将能够部署修订版并为其命名"candidate",然后在拆分流量时引用它,而不是使用复杂的自动生成的修订版名称。
或者,您可以通过使用gcloud run services replace命令部署 YAML 清单来管理修订之间的流量。这涉及了解 Knative API 的工作原理。以下是一些可能相关的文档:
| 归档时间: |
|
| 查看次数: |
768 次 |
| 最近记录: |