本文档介绍如何在多集群 Google Kubernetes Engine (GKE) 环境中设计、规划和实现升级。虽然本文档使用多集群 Ingress 进行升级，但概念可以应用于其他解决方案，例如手动配置外部负载均衡器。本文档提供了一个附带的教程，介绍了如何使用多集群 Ingress 来升级多集群 GKE 环境。本文档适用于负责维护 GKE 集群队列的 Google Cloud 管理员。
对多集群架构的需求
本部分介绍您可能需要使用多集群 Kubernetes 架构的各种原因。
Kubernetes 即基础架构
本文档将 Kubernetes 集群视为基础架构的组件。基础架构是一次性的。任何基础架构组件都不需要采取特殊处理，因为组件是出于某种目的提供的。Kubernetes 旨在为开发者和运维人员提供自动化和编排功能，从而向使用方提供基于容器的应用和服务。使用方可以是内部团队、其他服务或外部客户。
常见的多集群场景
除了 Kubernetes-as-infrastruction 参数外，还有许多其他原因需要使用多集群环境：
- 地理位置。多个服务必须位于多个地区。与从单个地区提供服务相比，将服务放在更靠近使用方所在的地区可缩短延迟时间，因而提供更好的使用体验。Kubernetes 集群在单个地区中运行。对于多地区部署，需要在多个地区提供多个 Kubernetes 集群。每个多云环境或混合云环境中也需要多个集群。Kubernetes 集群通常与有状态服务的数据源位于同一位置。某些应用可能必须与其后端（例如，关系型数据库管理系统 (RDBMS)）位于同一位置（地区和区域）。
- 租户和环境。Kubernetes 集群专为多租户设计。多个团队可以共享一个集群来处理其各自的服务。Kubernetes 提供了命名空间、基于角色的访问权限控制 (RBAC)、网络政策和身份验证等标准资源，用于在多租户环境中正确配置访问权限控制。在某些情况下，由于公司的政策、隐私权、安全性或行业规定，某些服务可能无法与其他服务共存。在这种情况下，多个集群需要将某些租户分隔到各自的集群中。环境（开发、预演和生产）通常也会作为单独的集群创建。不同环境中安装的应用的访问权限范围和类型差异很大，应作为单独的集群保留。
- 组合和功能。有时，系统会创建一个集群来执行特殊功能。例如，对于由 Spot 虚拟机组成的实例集群，机器学习工作流使用 Kubeflow 或数据分析作业，这些作业可能需要具有 GPU 或其他硬件要求的节点以便批量分析工作负载。这些硬件要求可能不适用于其他服务。这些工作流对业务的运营可能并不重要，并且可能需要临时集群（短期集群）。可观测性（日志记录、指标和跟踪记录）和 CI/CD 工具等共享服务更适用于其自有平台管理集群。对于非业务关键工作流，通常出现单独的功能专属集群。
- 弹性。通常使用多个集群来提高环境中的弹性。每个集群都有一个影响区域。在此上下文中，影响区域是指由于集群故障、配置有误或因计划内或计划外维护而导致集群离线而产生负面影响的服务数量。如果您有大量较小的集群，则您拥有大量较小的影响区域。如果某个服务存在于两个集群中，则这两个集群的负载相同。如果一个集群离线，则 50% 的流量会受到影响。如果同一服务由单个集群处理，则该集群上的任何事件都将导致该服务 100% 中断。因此，通常使用多个集群来实现灾难恢复。
本文档重点介绍多集群部署的弹性。
多集群和分布式服务
分布式服务是一种部署到多个 Kubernetes 集群的 Kubernetes 服务。分布式服务是无状态服务，在多个集群中以相同方式操作。这意味着分布式服务使用相同的 Kubernetes 服务名称，并且在多个集群内的同一命名空间中实现。Kubernetes 服务与运行它们的 Kubernetes 集群相关联。如果某个 Kubernetes 集群离线，则 Kubernetes 服务也会离线。分布式服务是从各个 Kubernetes 集群中提取出来的。如果一个或多个 Kubernetes 集群已关闭，则分布式服务可能处于在线状态并位于服务等级目标 (SLO) 中。
在下图中，frontend 是在服务名称和命名空间相同的多个集群上运行的分布式服务。
使用此架构，frontend 服务与单个集群无关联，在图中从概念上以涵盖 Kubernetes 集群基础架构层级的层级表示。如果运行 frontend 服务的任何个别集群关闭，frontend 仍会保持在线状态。在单个集群上运行了其他服务：accounts 服务和 ledger 服务。它们的正常运行时间和可用性取决于其所在的 Kubernetes 集群的正常运行时间。
多租户是进行多集群部署的一种原因。分布式服务会在多集群架构上创建弹性服务。无状态服务是多集群环境中的分布式服务的首要候选项。使用分布式服务时，需要满足以下要求和注意事项：
多集群网络。您可以使用多集群入站流量技术（如 多集群 Ingress）或者使用您自己的外部负载均衡器或代理解决方案，将发往分布式服务的流量发送到运行该服务的集群。无论您选择使用哪个选项，都必须控制在分布式服务的特定实例中路由流量的时间、位置和数量。下图显示了将流量发送到两个 GKE 集群中运行的分布式服务
frontend的负载均衡器。
可观测性。使用工具为分布式服务测量 SLO（通常是可用性和延迟时间）。此配置可让您全面了解每个服务在多个集群中的表现。虽然分布式服务在大多数可观测性解决方案中都不是明确定义的资源，但您可以收集和组合各个 Kubernetes 服务指标。解决方案（如 Cloud Monitoring）或开源工具（如 Grafana）提供了 Kubernetes 服务指标。Istio 和 Anthos Service Mesh 等服务网格解决方案也提供了服务指标，无需进行任何检测。
服务位置。Kubernetes 服务在单个 Kubernetes 集群中提供节点级容错能力。这意味着 Kubernetes 服务可以承受节点中断。在节点中断期间，Kubernetes 控制层面节点会自动将 Pod 重新调度到运行状况良好的节点。分布式服务提供集群级层的容错能力。这意味着分布式服务可以承受集群中断。在规划分布式服务的容量时，您必须考虑此服务位置。分布式服务不需要在每个集群上运行。分布式服务在哪些集群上运行取决于以下要求：
- 哪些位置或地区需要服务？
- 分布式服务需要的 SLO 是什么？
- 分布式服务需要哪种类型的故障容忍度（集群、区域或地区级）？例如，您是否要求在单个区域内有多个集群，或者一个地区或多个地区中的区域内有多个集群？
在最糟糕的情况下，分布式服务应承受哪种程度的中断？在集群层级提供了以下选项：
- N+1（其中 N 表示满足服务容量需求所需的集群数量）。分布式服务可以承受单个集群故障
- N+2。分布式服务 可以承受两个并发故障。例如，两个集群中同时发生 Kubernetes 服务的计划内和计划外中断。
发布和回滚。Kubernetes 服务等分布式服务允许逐步发布和回滚。与 Kubernetes 服务不同，分布式服务使集群可以作为额外的部署单元，以便逐步进行更改。发布和回滚还取决于服务要求。在某些情况下（例如修复了一个问题），您可能需要同时在所有集群上升级该服务。在其他情况下，您可能需要慢慢地发布（或错开）更改，一个更改一个集群。这种逐步发布行为通过逐步对服务进行更改，降低了分布式服务的风险。但是，此过程可能需要更长时间，具体取决于集群的数量。没有最好的升级策略。通常，使用多个发布和回滚策略取决于分布式服务要求。此处的要点是，分布式服务必须允许对环境逐步进行控制更改。
业务连续性和灾难恢复 (BCDR)。这些术语通常一起使用。业务连续性是指在发生重大（计划内或计划外）事件时关键服务的连续性，而灾难恢复则是指在发生此类事件后将业务运营恢复到正常状态所需执行的步骤。BCDR 有许多策略不在本文档的讨论范围内。BCDR 需要在系统和服务中实现一定级别的冗余。分布式服务的主要优点是它们在多个位置（集群、区域和地区）运行。
BCDR 策略通常依赖于之前讨论的发布和回滚策略。例如，如果以错开或受控的方式执行发布，则可以及早捕获错误或错误的配置推送，而不会影响大量用户。由于大规模的扩容并且快速变化（例如，在现代 CI/CD 实践中），通常并非所有用户都能使用同一版本的分布式服务。分布式系统和服务中的 BCDR 规划和策略不同于传统的单体式架构。在传统系统中，更改是全面进行的，对大量用户（甚至是每位用户）造成影响，因此必须创建冗余或备份系统，以防发布过程中出现不良影响。在分布式系统和服务中，几乎所有更改都是逐步进行的，以便仅影响少数用户。
集群生命周期管理。与受控发布和回滚一样，分布式服务允许进行受控集群生命周期管理。分布式服务提供集群级层的弹性，因此集群可以停止轮替以进行维护。集群生命周期管理是不适用于 Kubernetes 服务的分布式服务原则。
本文档的其余部分重点介绍分布式服务的集群生命周期方面。
GKE 集群生命周期管理
集群生命周期管理可以定义为维护运行状况良好的已更新 Kubernetes 集群所需的策略和规划，同时不违反服务 SLO。在设置适当的策略和规划后，集群生命周期管理应该具有规律性、可预期性以及平稳性。
本文档重点介绍 GKE 生命周期管理。但是，您可以将这些概念应用于 Kubernetes 的其他发行版。
GKE 版本控制和升级
在讨论集群生命周期管理的策略和规划之前，请务必了解促成集群升级的因素。
一个集群包含两个组件：控制层面节点和工作器节点。Kubernetes 集群升级要求所有节点都升级到同一版本。Kubernetes 遵循语义版本控制架构。Kubernetes 版本表示为 X.Y.Z:，其中 X 是主要版本，Y 是次要版本，Z 是补丁程序版本。次要版本大约每三个月（每季度）发布一次，Kubernetes 项目会维护最近三个次要版本的发布分支。这意味着存在九个月的 Kubernetes 次要版本不再进行维护，并且在升级到最新版本时可能需要更改 API。Kubernetes 升级必须有规律地进行规划。我们建议按计划在每个季度或每两个季度执行一次 GKE 升级。
GKE 集群支持通过任意受支持的次要版本运行 Kubernetes 版本。在任意给定时间，至少都有两个次要版本可用。
GKE 提供以下集群可用性类型：
- 单区域集群。一个控制层面节点和所有节点池都位于一个地区的一个区域。
- 多区域集群。一个控制层面节点位于一个区域，而节点池位于一个地区的多个区域。
- 地区级集群。一个地区的多个区域中的多个控制层面节点和节点池。
GKE 是一项代管式服务，为控制层面节点和工作器节点提供自动升级。
GKE 自动升级
GKE 自动升级是一种常见且常用的集群生命周期策略。GKE 自动升级提供了一种全代管式方式让您将 GKE 集群更新为受支持的版本。GKE 自动升级可单独升级控制层面节点和工作器节点：
主实例自动升级。默认情况下，GKE 控制平面节点会自动升级。单区域和多区域集群具有一个控制平面（控制平面节点）。在控制平面节点升级期间，工作负载会继续运行。但直到升级完成前，您都无法部署新的工作负载，也无法修改现有工作负载或对集群的配置进行其他更改。
地区级集群有多个控制层面副本，且一次只会升级一个副本。在升级过程中，集群保持高可用性，并且每个控制平面副本仅在升级时不可用。
工作器节点自动升级。一次只升级一个节点池。 在节点池中，节点升级的顺序不确定，且一次只能升级一个节点。一次可以更改已升级的节点数量，但此过程可能需要几个小时，具体取决于节点及其工作负载配置。
GKE 自动升级生命周期策略
我们建议您尽可能使用 GKE 自动升级。GKE 自动升级优先考虑控制便利性但是，GKE 自动升级能够通过很多方法来影响您的集群在特定参数中的升级时间和方式。您可以影响维护期和维护排除项。发布渠道会影响版本选择，而节点升级策略会影响节点升级的顺序和时间。尽管存在这些控制机制和地区级集群（具有多个 Kubernetes 控制层面），但 GKE 自动升级并不能保证服务的正常运行时间。如果您需要以下一项或多项功能，则可以选择不使用 GKE 自动升级功能：
- 控制 GKE 集群的确切版本。
- 控制升级 GKE 的确切时间。
- 控制 GKE 集群的升级策略（详见下一部分）。
GKE 多集群生命周期管理
本部分介绍各种 GKE 多集群生命周期管理策略以及如何进行规划。
规划和设计注意事项
在选择集群生命周期管理策略时需要考虑到 GKE 多集群架构。在讨论这些策略之前，必须先讨论可能会影响到集群生命周期管理策略或受到它的影响的一些设计决策。
集群类型
如果使用 GKE 自动升级作为集群生命周期管理策略，则集群类型可能很重要。例如，地区级集群具有多个控制层面节点，其中一次自动升级一个控制层面节点，而区域级集群具有一个控制层面节点。如果未使用 GKE 自动升级，并且将所有 Kubernetes 集群视为一次性基础架构，则在决定集群生命周期管理策略时，您选择的集群类型可能无关紧要。您可以将下一部分（GKE 多集群生命周期管理）中讨论的策略应用于任何类型的集群。
集群位置和占用空间
在决定集群位置和占用空间时，请考虑以下因素：
- 集群必须位于的区域和地区。
- 所需的集群数量和大小。
第一个因素通常容易满足，因为区域和地区取决于您的业务以及您为用户提供服务所在的地区。
处理集群的数量和大小通常可分为以下几类，每个类别都有其优点和缺点：
- 一小部分大型集群。您可以选择使用地区级集群提供的冗余和弹性，并在每个地区放置一个（或两个）大型地区级集群。此方法的好处在于可以降低管理多个集群的运营开销。其缺点在于，由于受影响的地区太多，因此可能会同时影响大量的服务。
- 大量小型集群。您可以创建大量小型集群以减少集群影响地区，因为您的服务会拆分到多个集群中。此方法也适用于短期临时集群（例如，运行批处理工作负载的集群）。此方法的缺点是运营开销更高，因为要升级更多集群。由于控制层面节点数量较多，因此也会产生额外费用。您可以使用自动化、可预测的计划和策略来降低费用和较高的运营开销，并在受影响的团队和服务之间谨慎协调。
本文并不推荐任何一种方法；您可以自己选择。在某些情况下，您可以为不同类别的服务选择两种设计模式。
以下策略适合任何一种设计选项。
容量规划
在规划容量时，请务必考虑选定的集群生命周期策略。容量规划必须考虑以下正常的服务负载和维护事件：
- 规划的事件，例如集群升级
- 集群中断等计划外事件，例如错误的配置推送和错误发布
在规划容量时，您必须考虑整体中断或局部中断。如果仅为计划中的维护事件进行设计，则所有分布式服务都必须有一个额外的集群，而不是一个必需的集群，这样，您就可以一次停止一个集群的轮替以进行升级，而无需将服务降级。此方法也称为 N+1 容量规划。如果要为计划内和计划外的维护事件进行设计，则所有分布式服务必须具有两个（或更多）额外的集群（而不是必需的集群组）用于提供预期容量，一个用于计划内事件，另一个用于在规划的维护期内发生的计划外事件。此方法也称为 N+2 容量规划。
在多集群架构中，通常会使用术语“排空”和“溢出”这两个术语。 这些术语是指在升级和维护事件期间从集群中移除（或排空）流量，并将流量重定向（或溢出）到其他集群的过程。此过程通过使用多集群 Ingress 或其他负载均衡方法等网络解决方案完成。谨慎使用排空和溢出是某些集群生命周期管理策略的核心。在进行容量规划时，您必须考虑排空和溢出。例如，当某集群被排空时，您需要考虑其他集群是否有足够的容量来处理溢出的其他流量。其他注意事项包括在相应区域或地区中有足够容量，或者需要将流量发送到其他地区（如果每个地区使用单地区级集群）。下图显示从一个集群移除流量（有时称为排空集群）并发送到另一个运行相同分布式服务的集群。
集群和分布式服务
基于服务的集群设计决定了集群架构（数量、大小和位置）由需要在集群上运行的服务决定。因此，集群的位置由分布式服务的位置决定。在决定分布式服务的位置时，请考虑以下事项：
- 位置要求。需要在哪些地区提供服务？
- 重要性。服务可用对企业有多重要？
- SLO。服务的服务级别目标（通常基于重要性）是什么？
- 弹性。服务的弹性如何？它是否需要承受集群、区域甚至地区故障？
在规划集群升级时，您必须考虑单个集群在排空时影响的服务数量，并且必须考虑将每项服务溢出到其他相应的集群。集群可以是单租户集群，也可以是多租户集群。单租户集群仅处理一个服务或由一组服务表示的产品。单租户集群不会与其他服务或产品共享集群。多租户集群可以运行许多通常被拆分成命名空间的服务和产品。
对团队的影响
集群事件不仅会影响服务，还会影响团队。例如，DevOps 团队可能需要在集群升级期间重定向或暂停其 CI/CD 流水线。同样，支持团队会收到计划内服务中断的提醒。必须执行自动化并准备好工具，以帮助减轻对多个团队的影响。当所有团队都收到通知时，集群或集群组升级应被视为具有规律性和平稳性
时间、安排和协调
Kubernetes 每季度发布一次新的次要版本，并维护最近的三个发行版。您必须仔细规划集群升级的时间和安排。执行这些升级时，服务所有者、服务运营商和平台管理员之间必须达成协议。在规划升级时，请考虑以下问题：
- 多久升级一次？每个季度升级一次还是按不同的时间表升级？
- 何时升级？是在每个季度开头业务放缓时升级还是行业因素导致业务暂停期间升级？
- 何时不应升级？您是否有明确的不升级时间计划，例如避免高峰时段事件，比如黑色星期五、网购星期一或大型会议会议以及其他行业特定活动期间。
请务必在与服务所有者以及运营和支持团队明确沟通后再制定策略。应该不会出现意外，每个人都应了解集群升级的时间和方式。这就需要与所涉及的所有团队进行清晰的协调。一个服务可以与多个团队进行交互。通常，这些团队可以分为以下类别：
- 服务开发者，负责创建业务逻辑并将其编入服务中。
- 负责安全可靠地运行服务的服务运营商。这些运营商可以由多个团队（例如政策或安全管理员、网络管理员和支持团队）组成。
在集群升级期间，每个人都必须进行交流，以便在这段时间内可以采取适当操作。其中一种方法是以计划升级中断突发事件的方式来升级集群。您需要有突发事件指挥官、聊天室和回顾（即使没有任何用户受到影响）。如需了解详情，请参阅突发事件响应。
GKE 集群生命周期策略
本部分介绍 GKE 多集群架构中常用的主要集群生命周期管理策略。需要注意的是，一种策略并非适用于所有情形，您可以为多种类别的服务和业务需要选择多个策略。
滚动升级
下图显示了滚动升级策略。
使用负载均衡器时，一个 GKE 集群中的所有流量都会被排空并进行升级。排空的流量负载会溢出到其他 GKE 集群。
滚动升级是本文档讨论的策略中最简单且最具成本效益的策略。从运行 old_ver（或当前生产）版本的 n 个集群开始。然后，一次排空 m 个集群，其中 m 小于 n。然后，您可以删除集群并使用新版本重新创建新集群，或升级已排空的集群。
是删除还是升级新集群取决于集群的大小，以及您是否认为集群是不可变的基础架构。不可变基础架构规定：您无需持续升级集群（随着时间的推移，可能会产生不想要的结果），而是创建新集群以避免任何意外的配置。
如果使用 GKE，则可以使用单个命令或 API 调用来创建 GKE 集群。新的集群策略要求您将整个集群配置（集群清单）存储在集群之外（通常存储在 Git 中）。然后，您可以在新集群上使用相同的配置模板。如果这是一个新集群，请确保您的 CI/CD 流水线指向正确的集群。正确配置集群后，您可以在监控服务的 SLO 时缓慢将流量推送回集群。
将对所有集群重复执行此过程。根据您的容量规划，您可以一次升级多个集群，而不违反服务 SLO。
如果您更重视简单易用和费用而非弹性，请使用滚动升级策略。在此策略中，您永远不会超出所有分布式服务所需的 GKE 容量。
下图比较了在多集群架构中升级 GKE 集群期间的时间轴和服务容量要求。
上图显示，在整个 GKE 升级过程中，用于支持服务的容量绝不会低于所需的容量。当待升级的 GKE 集群停止轮替时，其他集群将纵向扩容以支持负载。
蓝/绿升级
下图显示了蓝/绿升级策略。
在上图中，将添加运行新版本的新 GKE 集群。然后，负载均衡器用于将流量发送到新集群，同时缓慢排空其中一个旧集群，直到没有流量可发送到该集群。然后，您可以移除完全排空的旧集群。剩余集群可以按照相同的过程操作。
蓝/绿升级策略提供一些额外的弹性。此策略与滚动升级类似，但它更昂贵。唯一的区别在于，首先使用版本创建新的 m 集群，其中 m 小于或等于 n，而不是排空现有集群。将新集群添加到 CI/CD 流水线，然后在监控服务 SLO 时缓慢溢出流量。当新集群完全收到流量时，您可以使用旧版本排空和删除集群。
用于升级集群的蓝/绿策略类似于服务通常使用的蓝/绿色策略。一次创建多个新集群会增加整体费用，但有助于加快集群升级的速度。只有在使用了额外集群时才会增加升级费用。先创建新集群的优势在于发生故障时您可以回滚。您还可以在向新集群发送生产流量之前先测试该集群。由于这些集群与旧版本集群共存一段很短的时间，因此额外开销比较少。
如果您更重视简单易用和弹性而非费用，请使用蓝/绿升级策略。系统首先会添加额外的集群，并在升级期间超出 GKE 集群所要求的容量。
在上图中，首先添加新集群可暂时增加可用容量以超过所需容量，而集群组中的其他集群将被排空并从集群组中移除。但是，在移除其中一个旧的（已完全排空）集群后，容量会恢复到所需容量。突出显示此容量更改，因为使用此模型可能会增加费用，具体取决于集群组中的集群数量和大小。
Canary 集群升级
Canary 集群升级是本文档中讨论的最具弹性和最复杂的策略。此策略完全抽象化了服务生命周期管理中的集群生命周期管理，因此可针对您的服务提供最低风险和最高弹性。在上一个滚动和蓝/绿升级策略中，可在单个版本上维护整个 GKE 集群组。在此策略中，您可以维护运行不同版本的两个或三个 GKE 集群组。随着时间的推移，您会将服务从一个集群组迁移到另一个集群组，而不是升级集群。当最旧的 GKE 集群组被排空后（即所有服务均已迁移到下一个版本 GKE 集群组），您可以删除这些集群组。
此策略要求您至少维护两个 GKE 集群组，一个用于当前生产环境，另一个用于下一个生产候选版本。您还可以维护两个以上的 GKE 集群组。多一个集群组可增加灵活性，但费用和运营开销也会增加。这些额外的集群组与在不同的环境中（例如开发、预演和生产环境）中拥有集群不同。非生产环境非常适合测试使用非生产流量的 Kubernetes 功能和服务。
使用 Canary 集群升级的策略表明，您可以在生产环境中维护多个 GKE 集群组版本。这类似于服务经常使用的 Canary 发布策略。使用 Canary 服务部署时，服务所有者始终可以找到特定版本服务的问题。对于 Canary 集群，服务所有者还必须考虑其服务运行所在的 GKE 集群组版本。单个分布式服务版本可以在多个 GKE 集群组版本上运行。服务的迁移可能会逐步执行，因此您可以在将服务的所有流量都发送到新版本的集群之前，了解该服务对新集群组的影响。
下图显示了管理 GKE 集群的不同集群组可以从服务生命周期完全抽象化集群生命周期。
上图显示了分布式服务 frontend 缓慢地从一组 GKE 集群迁移到下一组运行新版本的集群，直到一段时间后较早的集群组完全被排空为止。排空集群组后，可以将其移除并创建新的集群组。所有服务都将迁移到下一个集群组，移除已被排空的旧集群组。
如果您重视弹性高于一切，请使用 Canary 集群升级策略。
选择升级策略
下图可帮助您根据服务和业务需求来确定哪种策略最适合您。
上图是一个决策树，可帮助您选择适合您的升级策略：
- 如果您不需要完全控制升级的确切版本和时间，则可以选择 GKE 中提供的自动升级功能。
- 如果优先考虑降低费用，则可以选择滚动升级策略。
- 如果您优先考虑在费用和弹性之间达到平衡，则可以选择蓝/绿策略。
- 如果您优先考虑弹性而不是费用，则可以选择 Canary 集群升级策略。
使用多集群 Ingress 进行 GKE 集群生命周期管理
几乎任何策略都取决于能否在升级过程中将流量排空和重新路由到其他集群。提供此多集群入站流量功能的解决方案是多集群 Ingress。多集群 Ingress 是一个适用于 GKE 集群且由 Google Cloud 托管的多集群入站流量控制器，它支持跨集群和地区部署共享的负载均衡资源。多集群 Ingress 是一个解决方案，可以将客户端流量发送到在多个地区的许多集群中运行的分布式服务。与 Ingress for GKE 一样，它使用 Cloud Load Balancing 将流量发送到后端服务。后端服务是分布式服务。后端服务将流量发送到多个后端，这些后端是在多个 GKE 集群上运行的 Kubernetes 服务。对于跨集群的服务到服务流量，您可以使用服务网格技术，例如跨分布式服务提供类似功能的 Anthos Service Mesh 或 Istio。
对于 GKE 多集群环境，您可以使用多集群 Ingress 处理以前讨论的集群生命周期管理策略中多个集群的流量。您可以按照通过多集群 Ingress 使用蓝绿策略进行 GKE 升级的教程操作。
后续步骤
- 详细了解多集群 Ingress。
- 了解如何跨集群部署多集群 Ingress。