选择托管式容器运行时环境

Last reviewed 2024-08-30 UTC

本文档可帮助您评估应用要求，并根据技术和组织方面的考虑因素在 Cloud Run 和 Google Kubernetes Engine (GKE) Autopilot 之间进行选择。本文档适用于需要为工作负载选择 Google Cloud 目标容器运行时环境的云架构师。本教程假定您熟悉 Kubernetes 和 Google Cloud，并且对 Cloud Run、Cloud Run functions 或 AWS Lambda 等云无服务器运行时环境有一定的了解。

Google Cloud 提供了多种具有各种功能的运行时环境选项。下图显示了 Google Cloud 托管式服务的范围：

Google Cloud 服务，从管理程度最高到最低。

图中显示了以下内容：

  • 管理程度最高的运行时环境（本指南的重点）：

    这些选项由 Google 管理，用户无需管理底层计算基础设施。

  • 管理程度最低的运行时环境：

    • GKE Standard，针对企业工作负载进行了优化，可提供单集群可伸缩性（最多 15,000 个节点）。
    • Compute Engine，包括针对机器学习 (ML) 和高性能计算 (HPC) 工作负载的加速器优化 A3 系列虚拟机。

    这些选项需要一定程度的用户级基础设施管理，例如基于计算能力的虚拟机 (VM)。GKE Standard 中的虚拟机是 Kubernetes 集群节点。Compute Engine 中的虚拟机是核心平台服务，您可以进行自定义以满足自己的需求。

本指南可帮助您在管理程度最高的运行时环境（Cloud Run 和 GKE Autopilot）之间进行选择。如需更全面地了解 Google Cloud 运行时环境，请参阅 Google Cloud 应用托管选项指南。

环境概览

本部分简要介绍了 Cloud Run 和 GKE Autopilot 功能。Cloud Run 和 GKE Autopilot 都紧密集成在 Google Cloud 中，因此两者之间存在许多共同之处。这两个平台都支持多种负载均衡选项与 Google 高度可靠且可伸缩的负载均衡服务结合使用。当需要更精细的专用网络时，它们还支持 VPC 网络、Identity-Aware Proxy (IAP) 和 Google Cloud Armor。这两个平台都仅针对您实际用于应用的资源向您收取费用。

从软件交付的角度来看，作为容器运行时环境，Cloud Run 和 GKE Autopilot 由构成 Google Cloud 容器生态系统的服务提供支持。这些服务包括 Cloud Build、Artifact Registry、Binary Authorization 和 Cloud Deploy 提供的持续交付，帮助确保您的应用安全可靠地部署到生产环境中。这意味着，您和您的团队负责做出构建和部署决策。

由于两个平台之间的共同之处，建议您采用灵活的部署应用的方法来充分利用每个平台的优势，详情请参阅结合使用 GKE 和 Cloud Run指南。以下各部分介绍了 Cloud Run 和 Autopilot 的独特方面。

Cloud Run

Cloud Run 是一个无服务器托管式计算平台，可让您直接在 Google 可伸缩的基础设施之上运行应用。Cloud Run 为两种主要类型的应用提供自动化和扩缩功能：

  • Cloud Run 服务：适用于响应 Web 请求的代码。
  • Cloud Run 作业：适用于执行一个或多个后台任务，然后在工作完成时退出的代码。

借助这两种部署模型，Cloud Run 可以支持各种应用架构，同时实现最佳实践，让开发者专注于代码。

Cloud Run 还支持从以下来源部署应用代码：

  • 各个轻量级函数
  • 从源代码构建的完整应用
  • 容器化应用

Cloud Run 集成了构建和部署功能，该功能支持 FaaS 和从源代码构建的能力，以及预构建容器运行时功能。以这种方式使用 Cloud Run 时，构建和部署应用容器映像的步骤是完全自动执行的，并且不需要您进行自定义配置。

GKE Autopilot

GKE Autopilot 是 GKE 中默认和推荐的集群操作模式。借助 Autopilot，您可以在 Kubernetes 上运行应用，省去管理基础设施方面的开销。当您使用 Autopilot 时，Google 会管理集群配置的关键底层方面，包括节点预配和扩缩、默认安全状况以及其他预配置的设置。借助 Autopilot 管理节点资源，您只需为工作负载请求的资源付费。Autopilot 会持续监控和优化基础设施资源以确保其最适合，同时为您的工作负载提供SLA。

GKE Autopilot 支持可能不适合 Cloud Run 的工作负载。例如，GKE Autopilot 通常支持长期运行的工作负载或有状态工作负载。

选择运行时环境

通常，如果工作负载的特性适合托管式平台，则 Cloud Run 的无服务器运行时环境将是理想之选。使用 Cloud Run 可以减少管理基础设施的工作量，减少自行管理的配置，从而降低运营开销。除非您明确希望或需要使用 Kubernetes，否则我们建议您先考虑将无服务器作为目标运行时环境。虽然 Kubernetes 提供了开放平台的强大抽象层，但使用它会增加复杂性。如果您不需要 Kubernetes，我们建议您考虑应用是否适合无服务器。如果一些标准使您的工作负载不太适合无服务器，我们建议您使用 Autopilot。

以下部分详细介绍了可帮助您解答这些问题的一些标准，尤其是工作负载是否适合无服务器这一问题。鉴于上文中介绍的 Autopilot 和 Cloud Run 之间的共同之处，如果没有任何技术或其他阻碍因素，则在这些平台之间进行迁移是一项简单的任务。如需详细了解迁移选项，请参阅从 Cloud Run 迁移到 GKE 以及从 Kubernetes 迁移到 Cloud Run。

为工作负载选择运行时环境时，您需要考虑技术和组织方面的因素。技术考虑因素是应用或 Google Cloud 运行时环境的特性。组织考虑因素是您的组织或团队的非技术特性，可能会影响您的决策。

技术考虑因素

以下是一些会影响您选择平台的技术考虑因素：

  • 控制和可配置性：对执行环境的控制粒度。
  • 网络流量管理和路由：通过网络进行交互的可控制性。
  • 横向和纵向可伸缩性：支持动态增长和缩减容量。
  • 支持有状态应用：用于存储持久性状态的功能。
  • CPU 架构：支持不同的 CPU 类型。
  • 加速器分流（GPU 和 TPU）：能够将计算分流到专用硬件。
  • 高内存、CPU 和其他资源容量：消耗的各种资源的级别。
  • 对 Kubernetes 的显式依赖关系：Kubernetes API 使用要求。
  • 适用于多租户的复杂 RBAC：支持共享池资源。
  • 容器任务超时时长上限：长期运行的应用或组件的执行时长。

以下部分详细介绍了这些技术考虑因素，以帮助您选择运行时环境。

控制和可配置性

与 Cloud Run 相比，GKE Autopilot 可对工作负载的执行环境进行更精细的控制。在 Pod 上下文中，Kubernetes 提供了许多可配置的基本组件，您可以对其进行调整以满足应用要求。配置选项包括特权级别、服务质量参数、容器生命周期事件的自定义处理程序，以及多个容器之间的进程命名空间共享。

Cloud Run 直接支持 Kubernetes Pod API Surface 的一部分，如 Cloud Run Service 对象的参考 YAML 和 Cloud Run Job 对象的参考 YAML 中所述。这些参考指南可帮助您根据应用要求评估这两个平台。

Cloud Run 执行环境的容器合同相对简单，适用于大多数服务工作负载。但是，合同指定了必须满足的一些要求。如果您的应用或其依赖项无法满足这些要求，或者您需要对执行环境进行更精细的控制，则 Autopilot 可能更适合。

如果您想减少在配置和管理方面花费的时间，不妨考虑选择 Cloud Run 作为运行时环境。与 Autopilot 相比，Cloud Run 的配置选项更少，因此可以帮助您最大限度地提高开发者的工作效率并降低运营开销。

网络流量管理和路由

Cloud Run 和 GKE Autopilot 均与 Google Cloud Load Balancing 集成。不过，GKE Autopilot 还提供了一组丰富且强大的基本组件，用于配置服务到服务通信的网络环境。配置选项包括使用命名空间和网络政策在网络层的精细权限和隔离、端口重新映射以及集群内的内置 DNS 服务发现。GKE Autopilot 还支持高度可配置且灵活的 Gateway API。此功能可以有效地控制流量路由到集群中服务的方式以及集群中服务间流量的路由方式。

由于 Autopilot 具有高度可配置性，因此如果您的多个服务具有高度网络相互依赖性，或者对于应用组件之间的流量路由方式有复杂的要求，则 Autopilot 可能是最佳选择。这种模式的一个示例是分布式应用，该应用被分解为许多具有复杂相互依赖模式的微服务。在这种情况下，AutoPilot 网络配置选项可帮助您管理和控制服务之间的交互。

横向和纵向可伸缩性

Cloud Run 和 GKE Autopilot 都支持对服务和作业进行手动和自动横向扩缩。横向扩缩可在需要时提供更高的处理能力，并在不需要时消除增加的处理能力。对于典型工作负载，Cloud Run 通常比 GKE Autopilot 更快地横向扩容，以响应每秒请求数量的激增。例如，视频演示“无服务器计算有哪些新变化？”展示了 Cloud Run 在约 10 秒内从 0 个实例扩容到 10,000 多个实例。为了加快 Kubernetes 上的横向扩缩速度（需要一些额外费用），Autopilot 让您可以预配额外的计算容量。

如果您的应用无法通过添加更多实例来扩缩以增加可用资源的级别，则 Autopilot 可能更适合您的应用。Autopilot 支持纵向扩缩，可动态调整可用的处理能力，而无需增加正在运行的应用实例的数量。

Cloud Run 可以在应用未使用时将其自动缩减至零个副本，这对于特别侧重于费用优化的某些应用场景非常有用。由于应用可缩减至零的特性，您可以执行多个优化步骤，以最大限度缩短请求到达时间与应用启动并运行且能够处理请求的时间。

支持有状态应用

Autopilot 提供全面的 Kubernetes 卷支持，由永久性磁盘提供支持，可让您运行各种有状态部署，包括自行管理的数据库。Cloud Run 和 GKE Autopilot 均可让您连接到其他服务，例如 Filestore 和 Cloud Storage 存储桶。它们还能够使用 Cloud Storage FUSE 将对象存储存储桶装载到文件系统。

Cloud Run 使用内存中文件系统，这可能不适合需要永久性本地文件系统的应用。此外，本地内存中文件系统会与应用的内存共享。因此，临时文件系统以及应用和容器的内存用量都会使内存限制耗尽。如果您使用具有大小限制的专用内存中卷，则可以避免此问题。

Cloud Run 服务或作业容器具有任务超时上限。在 Autopilot 集群的 pod 中运行的容器可以重新调度，但受限于使用 Pod 中断预算 (PDB) 配置的任何限制条件。不过，如果 Pod 免遭节点自动升级或纵向缩容事件导致的逐出，则最多可以运行 7 天。通常，Cloud Run 中的批量工作负载更有可能考虑任务超时。对于长期运行的工作负载以及无法在最长任务时长内完成的批量任务，Autopilot 可能是最佳选择。

CPU 架构

所有 Google Cloud 计算平台都支持 x86 CPU 架构。Cloud Run 不支持 Arm 架构处理器，但 Autopilot 支持由 Arm 架构提供支持的托管式节点。如果您的工作负载需要 Arm 架构，您需要使用 Autopilot。

加速器分流

Autopilot 支持使用 GPU 和使用 TPU，包括使用预留资源的能力。Cloud Run 支持使用 GPU，但存在一些限制。

高内存、CPU 和其他资源要求

相较于 GKE Autopilot 资源请求限制，单个 Cloud Run 服务或作业（单个实例）可以使用的 CPU 和内存资源数上限是受限制的。根据工作负载的特性，Cloud Run 可能还有其他限制来限制可用资源。例如，Cloud Run 可能会限制启动超时时间和出站连接数上限。使用 Autopilot 时，某些限制可能不适用，或者允许的值可能更高。

对 Kubernetes 的显式依赖关系

某些应用、库或框架可能对 Kubernetes 有显式依赖关系。Kubernetes 依赖关系可能是由以下某种原因引起的：

  1. 应用要求（例如，应用调用 Kubernetes API 或使用 Kubernetes 自定义资源）。
  2. 用于配置或部署应用的工具（例如 Helm）的要求。
  3. 第三方创建者或提供方的支持要求。

在这些场景中，Autopilot 是目标运行时环境，因为 Cloud Run 不支持 Kubernetes。

适用于多租户的复杂 RBAC

如果您的组织对多租户有特别复杂的组织结构或要求，请使用 Autopilot，以便利用 Kubernetes 基于角色的访问控制 (RBAC)。对于更简单的选项，您可以使用 Cloud Run 内置的安全和隔离功能。

组织考虑因素

以下是一些会影响您选择环境的组织考虑因素：

  • 广泛的技术策略：组织的技术方向。
  • 利用 Kubernetes 生态系统：有意利用 OSS 社区。
  • 现有的内部工具：已在使用特定工具。
  • 开发团队个人资料：开发者技能组合和经验。
  • 运营支持：运营团队的能力和重点。

以下部分详细介绍了这些组织考虑因素，以帮助您选择环境。

广泛的技术策略

组织或团队可能已就优先使用某些技术而非其他技术的策略达成一致。例如，如果团队达成了尽可能在无服务器或 Kubernetes 上实现标准化的协议，该协议可能会影响甚至规定目标运行时环境。

如果给定工作负载不适合策略中指定的运行时环境，您可能需要决定以下一项或多项操作，但需要注意随附的事项：

  • 重新设计工作负载的架构。不过，如果工作负载不适合，这样做可能会导致性能、费用、安全性或其他特性并非最佳。
  • 将工作负载注册为战略发展方向的例外情况。不过，如果过度使用例外情况，可能会导致技术组合不一致。
  • 重新考虑策略。但是，这样做可能会导致政策开销，从而阻碍或阻止进度。

利用 Kubernetes 生态系统

作为前面所述的广泛技术策略的一部分，组织或团队可能会因生态系统显著且不断发展而决定选择 Kubernetes 作为其所选平台。此选项与选择 Kubernetes 不同，因为存在技术应用依赖关系，如上一部分对 Kubernetes 的显式依赖关系中所述。在考虑使用 Kubernetes 生态系统时，应重点考虑活跃的社区、丰富的第三方工具以及强大的标准和可移植性。利用 Kubernetes 生态系统可以加快开发速度并缩短上市期。

现有的内部工具

在某些情况下，在组织或团队中使用现有工具生态系统（针对任何环境）可能是有利的。例如，如果您使用的是 Kubernetes，则可以选择继续使用 ArgoCD 等部署工具、Gatekeeper 等政策工具以及 Helm 等软件包管理工具。现有工具可能包括已建立的组织合规性自动化规则，以及其他可能费用高昂或需要很长准备时间才能针对替代目标环境实现的功能。

开发团队个人资料

应用或工作负载团队可能之前有使用 Kubernetes 的经验，这有助于提高团队实现 Autopilot 的速度和能力。团队可能需要一些时间才能熟练掌握新的运行时环境。这可能会导致平台在提升技能期间可靠性降低，具体取决于运营模式。

对于不断壮大的团队，招聘能力可能会影响组织选择平台。在某些市场中，Kubernetes 技能可能稀缺，因此需要提高招聘费用。选择 Cloud Run 等环境有助于简化招聘流程，并让您能够在预算范围内更快地扩大团队规模。

运营支持

选择运行时环境时，请考虑 SRE、DevOps 和平台团队以及其他运营人员的经验和能力。从可靠性的角度来看，运营团队有效支持生产环境的能力至关重要。此外，运营团队还必须能够支持预生产环境，以确保开发者不会因停机、依赖手动流程或繁琐的部署机制而限制开发者速度。

如果您使用 Kubernetes，中央运营团队或平台工程团队可以处理 Autopilot Kubernetes 升级。虽然升级是自动进行的，但运营人员通常会密切监控升级，以确保最大程度减少对工作负载的中断。某些组织选择手动升级控制平面版本。GKE Enterprise 还提供简化跨多个集群管理应用的功能。

与 Autopilot 相比，Cloud Run 不需要持续的管理开销或控制平面升级。通过使用 Cloud Run，您可以简化运营流程。通过选择单个运行时环境，您可以进一步简化运营流程。如果您选择使用多个运行时环境，则需要确保团队有足够的能力、功能和兴趣来支持这些运行时环境。

选择

如需开始选择流程，请与各利益相关方进行沟通。对于每个应用，请组建一个工作组，其中包括开发者、运营人员、任何中央技术治理组的代表、内部应用用户和消费者、安全团队、云财务优化团队，以及组织中可能相关的其他角色或群组。您可以选择分发信息收集调查问卷来整理应用特性，并在会议之前分享结果。我们建议您选择一个仅包含必要利益相关方的小型工作组。每个工作会议可能不需要所有代表。

您还可以邀请其他团队或群组的代表加入，他们应具备在 Autopilot 和/或 Cloud Run 上构建和运行应用的经验。在对话过程中，请参考本文档中的技术和组织考虑因素，评估您的应用是否适合各个潜在平台。

我们建议您在几个月后安排一次核对，以便根据在新环境中部署应用的结果来确认或重新考虑此决定。

后续步骤

贡献者

作者：Henry Bell | 云解决方案架构师

其他贡献者：