舰队的工作原理

本页面详细介绍了队列如何帮助您管理多集群部署,包括一些关键的队列术语和概念。舰队是 Google Cloud 关于以逻辑方式整理集群和其他资源的概念,让您可以使用和管理多集群功能,并在您的所有系统中应用一致的政策。舰队构成企业多集群功能在 Google Cloud中的工作原理的关键部分。

本指南适用于要利用多个集群和相关基础架构的技术读者,包括系统架构师、平台运营商和服务操作员。无论组织是在Google Cloud中、跨多个云服务提供商还是在本地运行多个集群,上述概念都非常有用。

在阅读本页面内容之前,请确保您熟悉基本的 Kubernetes 概念(例如集群和命名空间);如果不熟悉,请参阅 Kubernetes 基础知识GKE 文档为 Cloud 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 对象(例如在不同集群中具有相同名称的命名空间)会被视为同一个对象。这种标准化做法有助于更轻松地管理舰队资源。如果您使用的是利用相同性的功能,则采用相同性可提供一些有关如何设置命名空间、服务和身份的可靠指导。但是,它也遵循大多数组织自身已在实施的内容。

不同类型的相同性具有不同的优势,如下表所示:

相同性属性 可帮助您执行以下操作
命名空间在多个集群中被视为相同。
  • 向各个集群的用户授予访问权限。
  • 汇总各个集群的指标和日志。
命名空间和服务名称的组合在多个集群中被视为相同。同一命名空间中同名的服务使用相同的标签选择器。
  • 使用 Cloud Service Mesh 在集群内和跨集群路由流量。
  • 使用 GKE 多集群 Service 在多个集群中自动创建服务。
  • 使用多集群 Ingress 和多集群 Gateway 定位多集群 Service。
命名空间和服务账号(身份)的组合在多个集群中被视为相同。
  • 为在集群上运行的一组工作负载编写一次 IAM 政策。
  • 针对在集群上运行的一组工作负载编写 Cloud Service Mesh 授权政策。
  • 使用 SPIFFE 证书向服务网格中的对等体进行身份验证,而无需区分集群中的工作负载。

这表明,不同的舰队功能依赖于不同类型的相同性。少数功能完全不使用相同性。如需了解详情,请参阅哪些功能使用相同性?,包括无需考虑舰队级相同性即可使用哪些功能,以及哪些功能可能需要更仔细的规划。

命名空间相同性

队列相同性的基本示例是命名空间相同性。许多舰队功能会将不同集群中同名的命名空间视为相同。考虑该属性的另一种方法是,命名空间在整个队列中以逻辑方式定义,即使命名空间的实例化仅存在于一组队列资源中也是这样。

请考虑以下 backend 命名空间示例。虽然命名空间仅在集群 A 和 B 中实例化,但它在集群 C 中已隐式预留(必要时,backend 命名空间中的服务也可以安排到集群 C 中)。这意味着命名空间是分配给整个队列,而不是按集群分配。因此,命名空间相同性要求命名空间所有权在整个队列中保持一致。

展示队列命名空间相同性的示意图
舰队中的命名空间相同性

服务相同性

Cloud Service Mesh 和多集群 Ingress 在命名空间中使用服务相同性的概念。与命名空间相同性类似,这意味着具有相同命名空间和服务名称的服务被视为同一服务。

对于 Cloud 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 一样。

展示访问队列外资源的身份相同性的示意图
访问队列外部资源的身份相同性

队列中的身份相同性

在队列中,身份相同性的用法与我们先前讨论的外部身份相同性的用法类似。就像授权队列服务访问一次外部服务一样,您也可以在内部为它们授权。

在以下示例中,我们使用 Cloud Service Mesh 创建多集群服务网格,其中 frontend 有权访问 backend。使用 Cloud Service Mesh 和舰队时,我们无需指定集群 B 和 C 中的 frontend 可以访问集群 A 和 B 中的 backend。相反,我们只需指定队列中的 frontend 可以访问队列中的 backend。此属性不仅可以简化授权操作,而且还可提高资源边界的灵活性;现在,可以轻松在集群之间移动工作负载,而不会影响工作负载的授权方式。如同工作负载身份相同性,对队列资源进行治理至关重要,这可确保服务之间通信的完整性。

展示队列中身份相同性的示意图
队列中的身份相同性

哪些功能使用相同性?

许多舰队功能完全不依赖于相同性,您可以无需考虑是否要在舰队中采用任何形式的相同性,即可启用和使用这些功能。其他功能(包括 Config Sync 和 Policy Controller)可以使用相同性,例如,如果您想在多个舰队成员集群中选择一个命名空间,以便从单一可靠来源进行配置,但并非所有应用场景都需要使用相同性。最后,多集群 Ingress 和舰队级工作负载身份联合等功能始终在集群之间采用某种形式的相同性,并且可能需要根据您的需求和现有工作负载谨慎采用。

某些舰队功能(例如舰队工作负载身份联合)要求整个舰队都可以采用这些功能所使用的相同性。您可以使用团队管理等其他功能,逐步在命名空间或团队范围级别选择使用相同性。

下表展示了哪些功能需要使用本部分中所述的一个或多个相同性概念。

功能 支持逐步采用相同性 取决于命名空间相同性 取决于服务相同性 取决于身份相同性
舰队 不适用
Binary Authorization 不适用
节点间透明加密 不适用
基于完全限定域名的网络政策 不适用
Connect 网关 不适用
Config Sync 不适用
Policy Controller 不适用
GKE Security Posture 不适用
Advanced Vulnerability Insights 不适用
合规状况 不适用
发布序列 不适用
团队管理
多集群 Ingress
多集群 Service
舰队工作负载身份联合
Cloud Service Mesh

排他性

舰队感知资源在任何给定时间都只能属于单个舰队,这一限制由 Google Cloud 工具和组件强制执行。此限制可确保只有一个可靠来源用于治理集群。此限制没有排他性,即使是使用最简单的组件也很复杂,需要您的组织解释并配置来自多个队列的多个组件的交互方式。

高信任度

服务相同性、工作负载身份相同性、网格身份相同性均是以队列成员之间的高信任度原则为基础构建的。这种信任机制能够将这些资源的管理级别提升至队列,而不是逐一管理每个资源(即逐一管理 Kubernetes 资源的每个集群),最终使集群边界变得不太重要。

在另一个队列中,集群提供防止受到半径影响、保护(控制层面和底层基础架构)、嘈杂邻域等的保护。但是,它们对于政策和治理并没有很强的边界,因为任何一个队列中的管理员成员可能会影响队列其他成员的服务的运作方式。

因此,我们建议队列将管理员不信任的集群放入各自的队列中,以便将其隔离。然后,您可以根据需要在单个队列边界上向各项服务授权。

团队范围

团队范围是一种进一步将舰队细分为集群组的机制,可让您定义分配给特定应用团队的舰队感知资源。根据您的使用场景,单个舰队成员集群可以不与任何团队关联、与一个团队关联或与多个团队关联,从而允许多个团队共享集群。您还可以使用团队范围在整个舰队中按照发布顺序升级集群,但需要每个集群仅与一个团队关联。

团队范围可以关联明确指定的舰队命名空间,命名空间在范围内被视为相同。与舰队提供的默认命名空间相同性相比,这可让您更精细地控制命名空间。

支持舰队的组件

以下 GKE Enterprise 和 GKE 组件都会使用队列概念(例如命名空间和身份相同性),以提供简化的方式来使用集群和服务。如需了解将队列与每个组件搭配使用时的任何当前要求或限制,请参阅组件要求

  • 工作负载身份池
    一组队列提供一个通用工作负载身份池,可用于在服务网格内以及向外部服务统一进行身份验证和授权工作负载。

  • Cloud Service Mesh
    Cloud Service Mesh 是一套工具,可帮助您在 Google Cloud、本地和其他受支持的环境中监控和管理可靠的服务网格。您可以跨同一队列中的集群形成服务网格。

  • Config Sync
    Config Sync 使您可以利用命名空间、标签和注释等核心 Kubernetes 概念来部署和监控存储在中央可靠来源(例如 Git 代码库)中的系统的声明式配置软件包。借助 Config Sync,配置会在舰队中定义,但在每个本地成员资源中应用和强制执行。

  • Policy Controller
    Policy Controller 使您可以为 Kubernetes 集群应用和强制执行声明式政策。这些政策充当安全措施,有助于实现集群和舰队的最佳实践、安全性和合规性管理。

  • 多集群 Ingress
    多集群 Ingress 使用队列定义可以实现流量负载均衡的一组集群和服务端点,从而实现低延迟的高可用性服务。

后续步骤

  • 如需详细了解何时使用多个集群来满足您的技术和业务需求,请参阅多集群用例
  • 准备考虑将这些概念应用到您自己的系统吗?请参阅规划舰队资源