虽然一般来讲，最佳做法是使用尽可能少的集群，但组织出于各种原因会选择部署多个集群来实现各种技术和业务目标。大多数组织至少将各种服务放在不同的集群中，将非生产服务与生产服务分开。在更复杂的场景中，组织可能会选择多个集群来跨层级、语言区域、团队或基础架构提供商分隔服务。
采用多个集群的主要原因分为三个要求类别：
- 隔离：分离服务的控制层面和控制层面，主要用于提高可靠性或满足安全需求
- 位置：将服务放置在特定位置，以便满足可用性、延迟时间和位置需求
- 扩缩：尤其是在 Kubernetes 集群的上下文中，扩缩服务超出单个集群所施加的实际限制
我们将在后面几个部分中更详细地介绍这些。
在许多情况下，组织需要同时平衡其中多项要求。在考虑您自己的组织时，请记住，我们的一般建议是使用尽可能少的集群。确定哪些多集群需求是贵组织的最高优先级，不能妥协，然后据此进行权衡，从而创建多集群架构。
如果您发现您的组织考虑“每个服务模型一个集群”或“每个团队一个集群”模式，则可能需要考虑所管理的管理负担。队列以及 Google Cloud 支持这些组件和功能旨在尽可能简化管理多个集群，但一些附加集群管理更加复杂。
隔离
在此上下文中，隔离是指控制层面和/或数据层面的分离，两者都可以通过运行多个集群来实现。但是，根据实施的不同，此隔离也可能扩展到数据层面隔离。考虑以下各项时，通常会出现隔离：
环境
很多时候，组织在不同的集群上运行开发、预演/测试和生产服务，并且通常在不同的网络和云项目中运行。这种分离用于避免生产服务意外中断，并防止在开发或测试期间对敏感数据的访问。工作负载分层
许多具有许多复杂应用的组织都选择通过这些服务来安排其服务，选择在不同的集群上分开运行关键的服务和不太关键的服务。在这样的环境中，这些更关键的服务及其集群在访问、安全性、升级、政策等方面得到了特殊考虑。下面的分层示例是将无状态服务与有状态服务放在不同的集群上，以此区分它们。减少因故障而造成的影响
当组织希望限制运营商错误、集群故障或相关基础架构故障时，他们可以将服务分散在多个集群上。升级
当组织担心潜在就地升级问题（即升级自动化故障、应用不稳定或回滚功能）时，他们可以选择将其服务副本部署到新集群中。以这种方式升级需要规划或自动化才能实现，从而确保在升级过程中处理流量管理和状态复制。安全/监管分离
组织可能会出于多种原因选择隔离服务，包括将需遵守监管规定的工作负载与不太敏感的工作负载分离，或在与第一方（可信）服务（集群）不同的基础架构上运行第三方（可信度较低）服务。租户分离
将租户分离到多个集群通常出于各种原因，包括安全隔离、性能隔离、费用核算、甚至所有权。
位置
延迟时间
某些服务必须在特定位置（或地理位置）上实际放置该工作负载，才能满足一些延迟时间要求。如果上游服务或最终用户对延迟时间比较敏感，则可能会有这种需求，但如果工作负载本身对下游服务延迟时间比较敏感，也很容易会有这种需求。可用性
在单个云提供商（或多个提供商）跨多个可用区运行同一服务可提高总体可用性。管辖区
数据驻留和其他管辖区处理要求可能要求将计算和数据存储在特定区域内，因此需要将基础架构部署到多个数据中心或云服务商。数据引力
庞大的数据主体（甚至是某些数据库实例）可能难以实现或无法实现，甚至不适合整合到单个云提供商或区域。根据处理和传送要求，可能需要将应用部署在其数据旁边。旧版基础架构/服务
正如数据难以移到云端一样，一些旧版基础架构也难以移动。虽然这些旧版服务不可移动，但通过部署其他集群以用于开发新服务，组织可以提高开发速度。开发者选择
组织通常将从能够在使用的云托管服务中提供开发者选择中受益。通常，选择将让团队可使用最能满足其需求的工具更快地移动，但代价是需要管理每个提供商分配的其他资源。本地/边缘计算需求
最后，由于组织希望在更多传统工作环境（例如仓库、工厂车间、零售店等）中采用应用现代化改造做法，因此这需要管理更多基础架构组件上的更多工作负载。
扩缩
由于 GKE 可以将集群扩缩到超过 5000 个节点，因此这些限制很少会成为运营多个集群的原因。在集群达到可伸缩性限制之前，组织通常会决定将服务分散在多个集群中。对于确实达到可伸缩性限制的集群，跨多个集群运行应用可以缓解一些挑战，但会增加管理多个集群的复杂性。