与 GKE 中的普通服务相比,运行 Cloud Run 的价值主张是啥?

Posted

技术标签:

【中文标题】与 GKE 中的普通服务相比,运行 Cloud Run 的价值主张是啥?【英文标题】:What's the value proposition of running Cloud Run versus a normal service in GKE?与 GKE 中的普通服务相比,运行 Cloud Run 的价值主张是什么? 【发布时间】:2019-09-11 04:57:58 【问题描述】:

如果我使用 Cloud Run 而不是在 GKE 中部署普通服务/容器,有什么好处吗?

【问题讨论】:

【参考方案1】:

我会尝试添加我的观点。

此答案不涵盖在 Google Cloud Run Kubernetes 中运行的容器。原因是我们希望为遗留 php 网站提供几乎零成本的解决方案。 Cloud Run 非常适合,我们在移植代码和学习 Cloud Run 方面都很轻松。

我们需要对遗留的 PHP 网站做点什么。该网站在 Windows Server 2012、IIS 和 PHP 7.0x 上运行。每月费用超过 100.00 美元 - 主要用于云中 VM 的 Windows 许可费用。访问该网站的次数不多,但出于各种业务原因需要该网站。

星期四(2019 年 4 月 18 日)决定我们需要学习 Google Cloud Run,因此我们决定将此站点移植到一个容器中,并尝试在 Google Cloud 中运行该容器。没有什么比真实世界的例子更能了解细节了。

周五,我们将 PHP 代码移植到 Apache。非常简单的过程。我们不担心 SSL,因为我们打算使用 Cloud Run SSL。

周六我们开始学习 Cloud Run。不到一个小时,我们就运行了 Hello World PHP 示例。 Link.

在两个小时内,我们就在 Cloud Run 中运行了容器化网站。同样,非常简单。

然后我们学习了如何使用我们的 DNS 服务器配置 Cloud Run SSL。

最终结果:

    在 Cloud Run 中运行的 PHP 网站成本几乎为零。 大约需要 1.5 天的时间来移植旧代码并学习 Cloud Run。 每月节省约 100.00 美元(无 Windows IIS 服务器)。 从现在开始,我们不必担心此站点的 SSL 证书。

对于静态的小型网站,Cloud Run 是一款杀手级产品。即使您不了解 Google Cloud,学习曲线也非常小。您只需为容器构建和部署配置 gcloud。这意味着开发人员无需掌握 GCP。

【讨论】:

感谢您的回答!如果您只是运行它并让 Google 处理您的集群,我非常同意您的看法,它将如何改变游戏规则。仅消除复杂性的数量就改变了游戏规则。我认为这就是无服务器的价值,谷歌只是用这个产品(预烘焙的运行时)消除了无服务器的灵活性障碍。虽然它仍处于测试阶段,但它有很多希望。我感兴趣的是,如果您已经拥有 GKE 集群,并且您可以正常部署容器。如果您将部署更改为 Cloud Run 服务,您将获得什么优势。 Cloud Run 和 Cloud Run Kubernetes 是一样的。除了 Cloud Run Kubernetes 有一些限制(目前) - 支持 VPC、Cloud SQL 等。对于 Cloud Run Kubernetes,您使用与 Cloud Run 相同的命令进行部署。这对于不了解 Kubernetes 的开发人员来说意义重大。【参考方案2】:

与在 GKE 中以本机方式运行服务相比,使用 Cloud Run 公开服务有许多不同之处。其中最主要的是 Cloud Run 提供了更多的无服务器基础架构。基本上你声明你想公开一个服务,然后让 GCP 做剩下的事情。将此与创建 Kubernetes 集群然后在 pod 中定义服务进行对比。使用手动创建的 GKE 集群,节点和环境始终处于开启状态,这意味着无论利用率如何,您都需要为它们付费。使用 Cloud Run,您的服务仅可用,您只需为实际消费付费。如果您的服务未被调用,您的成本为零。另一个优点是您不必预测您的使用需求并分配足够的节点。自动为您进行扩展。

另请参阅 Google Next 19 的这些演示文稿:

Migrating from a Monolith to Microservices (Cloud Next '19) What's New in Serverless Compute? (Cloud Next '19) Run Containers on GCP's Serverless Infrastructure (Cloud Next '19) Run Cloud Functions Everywhere (Cloud Next '19) Container Once, Serverless Anywhere (Cloud Next '19)

【讨论】:

虽然您的回答对 Cloud Run vs Cloud Run on GKE 是正确的,但我的问题是 Cloud Run on GKE 与正常运行部署之间有什么区别。 你好@chriz ...我想我没有遵循“正常”运行 REST 服务器应用程序的意思?您能否详细说明正常运行的含义?我以为这意味着构建一个容器,该容器会在 TCP 端口上主动侦听传入的 REST 请求,并在它们到达时为其提供服务,并以通常部署 pod 的方式将该容器部署在 POD 中。 就是这样,如果在 Cloud Run 中进行部署与在普通 pod 中没有部署相比有什么优势。 Cloud Run 基本上是另一种部署方式。 想象一下,如果给我一个服务 REST 请求的容器,该容器由一个单独的开发团队构建。我想将该容器作为黑匣子运行,而不用担心里面有什么。我现在的目标是运行这个容器。您认为我可以使用“普通”Kubernetes 运行它或者我可以使用 Cloud Run 运行它是 100% 正确的。但是请注意一些有趣的事情......使用 Cloud Run 运行它的复杂性接近于零。 是的,但我特别想问的是 Cloud Run 的第 2 种风格,即 Cloud Run for GKE,将我的容器作为普通 pod 运行与在 GKE 上作为 Cloud Run 运行有什么优势? Kubernetes 中还有一个带有 vanilla 部署的 Horizo​​ntal Pod Autoscaler,类似于 Cloud Run 的扩展方式?

以上是关于与 GKE 中的普通服务相比,运行 Cloud Run 的价值主张是啥?的主要内容,如果未能解决你的问题,请参考以下文章

使用私有 IP 从不同 VPC 网络中的 GKE 集群连接到 Cloud SQL

为公共 GKE 集群设置 Cloud NAT

Google Cloud 线上课堂 | Kubernetes 网络演进,GKE Gateway API 打开新篇章

Google Cloud 线上课堂 | Kubernetes 网络演进,GKE Gateway API 打开新篇章

GKE 自动部署具有不同映像的多个部署/服务

如何在 GKE 上提供对 Kubeflow 的访问权限?