搭配使用 GKE 和 Cloud Run

本指南适用于运行各种容器化工作负载并希望利用 Google Kubernetes Engine (GKE) 和 Cloud Run 的优势将应用部署到 Google Cloud Platform 的基础设施管理员和应用操作员。混合策略可让您优化费用、性能和管理开销。

您应熟悉以下内容：

为何搭配使用 GKE 和 Cloud Run？

GKE 和 Cloud Run 在运行容器化应用方面具有不同优势，可满足不同级别的工作负载复杂性。不过，您无需在这两个平台之间进行选择。您可以根据需要在两个平台之间迁移工作负载，从而同时利用 GKE 和 Cloud Run 的优势。

以下是使用两个运行时来部署工作负载的一些优势：

  • GKE 和 Cloud Run 提供相对较高水平的可移植性：

    • 这两个平台都使用标准容器映像作为部署工件。您可以在任一平台中为您的应用使用相同映像，而无需进行任何修改，从而实现 GKE 和 Cloud Run 之间工作负载的无缝迁移。您无需更新持续集成设置即可在 GKE 和 Cloud Run 之间迁移，只要容器映像存储在Artifact Registry 中。

    • GKE 和 Cloud Run 都使用声明式 API 模型。Cloud Run Admin API v1 的设计目标是与 Kubernetes API 兼容。这意味着您可以使用熟悉的 Kubernetes 概念（如 Deployment、Service 和 Pod 横向自动扩缩器）来管理 Cloud Run 服务。这种相似性可让您更轻松地在两个平台之间转换配置。

    • 资源以具有相同声明性和标准结构的 YAML 文件表示，因此可以在不同运行时之间轻松迁移。下面是一个示例，它比较了 Kubernetes 部署和 Cloud Run 服务的 YAML 文件。

  • GKE 和 Cloud Run 都与 Cloud Logging 和 Cloud Monitoring 无缝集成，并为您提供 Google Cloud 控制台的集中视图，以便您观察应用指标，无论其平台如何。您还可以在这两个平台上使用服务等级目标 (SLO) 监控，并在 Cloud Monitoring 信息中心上统一显示 SLO。

  • 您可以使用 Cloud Deploy 实现对 GKE 资源或 Cloud Run 服务的持续交付。或者，如果您愿意，可以使用并行部署将应用同时部署到 GKE 和 Cloud Run。

  • 您可以通过为 GKE 和 Cloud Run 上的服务使用外部和内部负载均衡器来辅助高级流量管理。这包括公开外部端点的功能，以便您可以在这两个平台上为同一应用部署和运行不同的网址。您还可以将流量拆分到 GKE 和 Cloud Run 中的同一服务，从而实现从一个平台无缝迁移到另一个平台。

  • Google Cloud 提供了安全工具，以改善使用这两种运行时时的安全状况。借助操作系统扫描功能，您可以在部署到任一平台之前扫描容器，了解是否存在漏洞。中央 Binary Authorization 政策可以强制执行与 GKE 和 Cloud Run 控制平面的集成，以根据您定义的政策允许或阻止映像部署。借助 VPC Service Controls，安全团队可以跨 GKE 和 Cloud Run 资源定义精细的边界控制措施。

比较 GKE 和 Cloud Run

为了充分利用 GKE 和 Cloud Run 的最佳功能，并了解何时在它们之间移动工作负载，请务必了解这两种服务之间的不同之处。

特征 GKE Cloud Run
部署和管理

管理 Kubernetes 集群，包括节点配置、网络、扩缩和升级。

Google Cloud 管理底层基础设施并提供简化集群操作的工具，但您仍需负责 Kubernetes 的核心方面。

直接在 Google Cloud 可伸缩的基础设施之上运行容器。

您只需提供源代码或容器映像，Cloud Run 可以为您构建容器。您无需创建集群，也不必预配和管理基础设施。
控制和灵活性

对 Kubernetes 集群的完全控制。

您可以创建节点配置、网络政策、安全设置和插件的高级自定义设置。

对底层基础设施的有限控制。

您可以配置环境变量、并发和网络连接等内容，但无法自定义底层基础设施或环境。简单易用、速度快的选择。
应用类型 支持无状态和有状态应用，非常适合具有特定资源需求的复杂应用。 最适合无状态、请求或事件驱动型服务、Web 服务和函数。
价格模式 无论操作模式（Standard 或 Autopilot）、集群大小或拓扑如何，都按集群以每小时付费。 按量付费，计费时间以 100 毫秒为增量向上取整。

使用场景

假设您是一家正在构建大型电子商务平台的零售公司的平台管理员。您要部署以下容器化工作负载：

  • 前端网站和移动应用：用于处理产品浏览、搜索和结账的无状态 Web 应用。

  • 商品目录管理系统：管理商品库存情况性和更新的有状态服务。

  • 商品推荐引擎：一种复杂的微服务，用于为每位用户生成个性化商品推荐。

  • 批处理作业：包括更新商品清单和分析用户行为等定期任务。

这些工作负载同时代表无状态服务和有状态服务，因此您决定利用 GKE 和 Cloud Run 来获得最佳性能。以下是为工作负载实现混合方法的一种方法。

  1. 阅读 Cloud Run 工作负载适用性条件后，您决定将 Cloud Run 用于网站和移动应用，以及批处理作业。在 Cloud Run 上部署这些服务具有以下优势：

    • 在流量高峰和大型批量作业时自动扩缩，无需人工干预。

    • 采用按用量计费模式，经济高效。只有在用户浏览或结账时以及在批量作业执行期间使用资源时，您才需要付费。

    • 部署速度更快，更新即时可用，从而改善用户体验。

    • 轻松与其他 Google Cloud 服务集成。例如，对于事件驱动型处理，您可以使用 Cloud Functions 在 Cloud Run 上启动批处理作业，并实现无缝工作流。

  2. 产品目录管理系统是一项有状态服务，需要精细的控制和潜在的自定义存储解决方案。您决定使用 GKE 进行部署，因为它提供永久性存储，并且允许您挂接卷以实现商品数据的持久性和可靠性。

  3. 商品推荐引擎是一种复杂的微服务，可受益于 GKE。借助 GKE，您可以管理复杂的依赖项，并精细控制资源分配和扩缩。

GKE 最适合复杂的微服务架构、有状态应用、需要自定义基础设施或网络配置的工作负载，以及必须对 Kubernetes 进行深度控制的场景。Cloud Run 最适合事件驱动型应用。它非常适合无状态 Web 服务、API、批量作业以及受益于按用量计费的其他工作负载。

上面的示例演示了结合使用 GKE 和 Cloud Run 如何为您的电子商务平台提供强大且灵活的解决方案。您将同时获享这两个平台的优势：无状态工作负载的无服务器效率，以及对复杂微服务和有状态组件的 Kubernetes 控制。

注意事项

GKE 和 Cloud Run 互为补充，可满足复杂应用环境中的不同需求。

在采用混合方法部署工作负载时，存在以下注意事项：

  • 在 Cloud Run 上运行无状态微服务，以获得经济高效性和可伸缩性。

  • 在 GKE 上部署需要深度自定义的复杂有状态应用。

  • 如果您使用 Google Cloud 上的专用网络，通过 Cloud Run 服务访问 GKE 集群中的资源，则可以使用直接 VPC 出站流量向 Virtual Private Cloud (VPC) 网络发送请求。如需访问 GKE 集群的 Service，Cloud Run 服务必须连接到集群的 VPC 网络，并且 GKE Service 必须使用内部直通式网络负载均衡器。

  • 如需在 Cloud Run 和 GKE 之间迁移流量，您可以在全球外部应用负载均衡器后面公开外部端点。在两个运行时中的服务前面实现此负载均衡器后，您将能够在 Cloud Run 和 GKE 上部署同一应用，从而逐步将流量从一个平台转移到另一个平台。

  • 如需在专用 IP 地址后面公开 Virtual Private Cloud 中的 Cloud Run 服务，请使用内部负载均衡器。

请注意，如果您的工作负载已在 Cloud Run 上，则可以随时根据需要迁移到 GKE。

何时不应搭配使用 GKE 和 Cloud Run

虽然 GKE 和 Cloud Run 为许多容器化工作负载提供了极具吸引力的方法，但在某些情况下，将它们搭配使用可能不太合适。以下是不太建议您采用混合方法的一些示例：

  • 紧密耦合的微服务：如果您的微服务相互之间高度依赖，并且需要频繁进行延迟时间短的通信，那么跨不同平台管理它们可能会增加复杂性。平台之间频繁的网络调用可能会增加开销和潜在瓶颈，从而影响性能。

  • 具有自定义依赖项的旧版应用：如果您的应用依赖于 Cloud Run 不支持的特定库、框架或配置，则将其用于应用的某些部分可能需要大幅重构或解决方法。这可能会抵消无服务器优势，并导致专属于平台的维护开销。

  • 对可预测工作负载的预算限制：如果您的工作负载具有一致的资源要求并且预算有限，则 GKE 的按节点付费模式可能比 Cloud Run 的按用量计费更经济实惠。如果您有可预测的工作负载，可能无法充分利用 Cloud Run 的自动扩缩优势，这使得 GKE 的固定费用更具吸引力。

最佳方法最终取决于您的特定需求和优先事项。 在决定混合 GKE 和 Cloud Run 架构之前，请仔细评估应用的要求、资源限制和团队专业知识。

后续步骤