本页面详细介绍了队列如何帮助您管理多集群部署，包括一些关键的队列术语和概念。Environ 是 Google Cloud 的概念，用于以逻辑方式组织集群和其他资源，让您可以使用和管理多集群功能，并在您的所有系统中应用一致的政策。队列是企业多集群功能在 Google Cloud 中的工作原理的关键组成部分。
本指南适用于要利用多个集群和相关基础架构的技术读者，包括系统架构师、平台运营商和服务操作员。无论组织是在 Google Cloud 中、跨多个云提供商还是在本地运行多个集群，上述概念都非常有用。
您需要熟悉基本的 Kubernetes 概念（例如集群和命令空间）；如果没有，请参阅 Kubernetes 基础知识、GKE 文档和准备 Anthos Service Mesh 的应用。
如需详细了解 GKE Enterprise 平台以及使用舰队的组件，请参阅我们的 GKE Enterprise 技术概览和探索 GKE Enterprise 教程。但是，您无需熟悉 GKE Enterprise 即可学习本指南。
术语
以下是在讨论队列时会用到的一些重要术语。
队列感知资源
队列感知资源是 Google Cloud 项目资源，可以进行逻辑分组并作为队列管理。目前只有 Kubernetes 集群可以是队列成员。
队列宿主项目
与其他许多 Google Cloud 资源一样，队列的实现植根于 Google Cloud 项目，我们称之为队列宿主项目。给定的 Google Cloud 项目只能关联单个舰队（或没有舰队）。此限制可强化使用 Google Cloud 项目在未受治理或未一起使用的资源之间实现更强的隔离。
分组基础架构
队列的首要重要概念是分组的概念，即选择哪些相关队列感知资源应成为队列的一部分。如需决定如何对内容进行分组，您需要回答以下问题：
- 资源之间是否相关？
- 具有大量跨服务通信的资源受益于最多一起管理队列。
- 同一部署环境中的资源（例如生产环境）应队列一起管理。
- 谁管理资源？
- 统一（或至少相互信任）对资源的控制至关重要，这可确保队列的完整性。
为了说明这一点，假设有一个组织具备多条业务线 (LOB)。在这种情况下，服务很少跨 LOB 边界进行通信，处于不同 LOB 的服务以不同方式进行管理（例如，各个 LOB 的升级周期不同），这些服务的每个 LOB 甚至拥有一组不同的管理员。在这种情况下，或许较佳的做法是为每个 LOB 设置队列。此外，每个 LOB 也可能采用多个队列将其生产服务和非生产服务分开。
以下各部分将介绍其他队列概念时，您可能会发现在考虑特定组织需求时创建多个队列的其他原因。
相同性
队列概念的一个重要概念是相同性概念。这意味着，某些 Kubernetes 对象（例如不同集群中同名的命名空间）将被视为同一对象。这种标准化做法使得管理队列资源更具可控性。它提供了有关如何设置命名空间、服务和身份的可靠指导。但是，它也遵循大多数组织自身也在实施的内容。
命名空间相同性
队列相同性的基本示例是命名空间相同性。许多组件会将不同集群中同名的命名空间视为同一命名空间。考虑该属性的另一种方法是，命名空间在整个队列中以逻辑方式定义，即使命名空间的实例化仅存在于一组队列资源中也是这样。
请考虑以下 backend 命名空间示例。虽然命名空间仅在集群 A 和 B 中实例化，但它在集群 C 中已隐式预留（必要时，backend 命名空间中的服务也可以安排到集群 C 中）。这意味着命名空间是分配给整个队列，而不是按集群分配。因此，命名空间相同性要求命名空间所有权在整个队列中保持一致。
服务相同性
Anthos Service Mesh 和多集群 Ingress 在命名空间中使用服务相同性的概念。与命名空间相同性类似，这意味着具有相同命名空间和服务名称的服务被视为同一服务。
对于 Anthos Service Mesh，服务端点可以在整个网格中进行合并。使用多集群 Ingress，MultiClusterService (MCS) 资源能够使端点更明确地合并；但我们建议对命名采用类似的做法。因此，请务必确保同一命名空间中名称完全相同的服务实际上是相同的服务。
在以下示例中，互联网流量在集群 B 和 C 的 frontend 命名空间内的同名服务中实现了负载均衡。同样，使用队列中的服务网格属性，frontend 命名空间中的服务可以访问集群 A 和 C 中的 auth 命名空间中同名的服务。
访问外部资源时的身份相同性
队列中的服务在出站时可以利用通用身份访问 Google Cloud 服务、对象存储等外部资源。此通用身份可让队列内的服务访问一次外部资源（而不是逐个访问集群）。
为了进一步说明这一点，请参考以下示例。集群 A、B 和 C 在其队列中注册了通用身份。当 backend 命名空间中的服务访问 Google Cloud 资源时，其身份将被映射到名为 back 的通用 Google Cloud 服务账号。Google Cloud 服务账号 back 可以在任意数量的代管式服务（从 Cloud Storage 到 Cloud SQL）上获得授权。当在 backend 命名空间中添加新的队列资源（例如集群）时，它们会自动继承工作负载身份相同性属性。
因为身份相同，队列中的所有资源都很重要且受到良好管理。回顾之前的例子，如果集群 C 归一个单独的不受信任的团队所有，则他们还可以创建 backend 命名空间并访问代管式服务，就像集群 A 或集群 B 中的 backend 一样。
队列中的身份相同性
在队列中，身份相同性的用法与我们先前讨论的外部身份相同性的用法类似。就像授权队列服务访问一次外部服务一样，您也可以在内部为它们授权。
在以下示例中，我们使用 Anthos Service Mesh 创建多集群服务网格，其中 frontend 有权访问 backend。使用 Anthos Service Mesh 和队列时，我们无需指定集群 B 和 C 中的 frontend 可以访问集群 A 和集群 B 中的 backend。相反，我们只需指定队列中的 frontend 可以访问队列中的 backend。此属性不仅可以简化授权操作，而且还可提高资源边界的灵活性；现在，可以轻松在集群之间移动工作负载，而不会影响工作负载的授权方式。如同工作负载身份相同性，对队列资源进行治理至关重要，这可确保服务之间通信的完整性。
排他性
队列感知资源在任何给定时间都只能属于单个队列，这一限制由 Google Cloud 工具和组件强制执行。此限制可确保只有一个可靠来源用于治理集群。此限制没有排他性，即使是使用最简单的组件也很复杂，需要您的组织解释并配置来自多个队列的多个组件的交互方式。
高信任度
服务相同性、工作负载身份相同性、网格身份相同性均是以队列成员之间的高信任度原则为基础构建的。这种信任机制能够将这些资源的管理级别提升至队列，而不是逐一管理每个资源（即逐一管理 Kubernetes 资源的每个集群），最终使集群边界变得不太重要。
在另一个队列中，集群提供防止受到半径影响、保护（控制层面和底层基础架构）、嘈杂邻域等的保护。但是，它们对于政策和治理并没有很强的边界，因为任何一个队列中的管理员成员可能会影响队列其他成员的服务的运作方式。
因此，我们建议队列将管理员不信任的集群放入各自的队列中，以便将其隔离。然后，您可以根据需要在单个队列边界上向各项服务授权。
团队范围
团队范围是一种进一步将舰队细分为集群组的机制，可让您定义分配给特定应用团队的舰队感知资源。根据您的使用场景，单个舰队成员集群可以不与任何团队关联、与一个团队关联或与多个团队关联，从而允许多个团队共享集群。您还可以使用团队范围在整个舰队中按照发布顺序升级集群，但需要每个集群仅与一个团队关联。
团队范围可以关联明确指定的舰队命名空间，命名空间在范围内被视为相同。与舰队提供的默认命名空间相同性相比，这可让您更精细地控制命名空间。
支持舰队的组件
以下 GKE Enterprise 和 GKE 组件都会使用队列概念（例如命名空间和身份相同性），以提供简化的方式来使用集群和服务。如需了解将队列与每个组件搭配使用时的任何当前要求或限制，请参阅组件要求。
工作负载身份池
一组队列提供一个通用工作负载身份池，可用于在服务网格内以及向外部服务统一进行身份验证和授权工作负载。Anthos Service Mesh
Anthos Service Mesh 是一套工具，可帮助您在 Google Cloud、本地环境和其他受支持的环境上监控和管理可靠的服务网格。您可以跨同一队列中的集群形成服务网格。Config Sync
Config Sync 使您可以利用命名空间、标签和注释等核心 Kubernetes 概念来部署和监控存储在中央可靠来源（例如 Git 代码库）中的系统的声明式配置软件包。借助 Config Sync，配置会在舰队中定义，但在每个本地成员资源中应用和强制执行。Policy Controller
Policy Controller 使您可以为 Kubernetes 集群应用和强制执行声明式政策。这些政策充当安全措施，有助于实现集群和舰队的最佳实践、安全性和合规性管理。多集群 Ingress
多集群 Ingress 使用队列定义可以实现流量负载均衡的一组集群和服务端点，从而实现低延迟的高可用性服务。Knative serving
Knative serving 是一个由 Google 托管、受支持的 Knative 开发者平台，消除了底层基础设施的复杂性，因而可在队列中的所有集群中轻松构建、部署和管理应用和服务。