将容器迁移到 Google Cloud：迁移到多集群 GKE 环境

Last reviewed 2023-05-08 UTC

本文档可帮助您规划、设计和实现从一个 Google Kubernetes Engine (GKE) 环境到新的 GKE 环境的迁移。如果操作不当，那么将应用从一个环境迁移到另一个环境可能会遭遇挑战。因此，您需要谨慎规划和执行迁移。

本文档是关于迁移到 Google Cloud 的系列文章中的一篇。如需简要了解本系列，请参阅迁移到 Google Cloud：选择迁移路径。

本文档是一系列文章中的一篇，介绍了如何将容器迁移到 Google Cloud：

如果您计划从一个 GKE 环境迁移到另一个 GKE 环境，则本文档非常有用。如果您正在评估迁移的时机并希望了解潜在的情况，本文档也可以提供帮助。

从一个 GKE 环境迁移到另一个 GKE 环境的原因可能包括：

  • 启用仅可在创建集群时获得的 GKE 功能。GKE 一直在不断发展，不断推出新功能和安全修复。如需获得大多数新功能和修复，您可能需要通过自动升级或手动方式将 GKE 集群和节点池升级到较新的 GKE 版本。

    某些新的 GKE 功能无法在现有集群上启用，您需要创建新的 GKE 集群并启用这些新功能。例如，您只能在创建新集群时启用 GKE 中的 VPC 原生网络、Dataplane V2 或元数据隐藏。您无法在集群创建后更新现有集群的配置以启用这些功能。

  • 实现基础架构的自动化预配和配置流程。如果您手动预配和配置基础架构，则可以设计和实现预配和配置 GKE 集群的自动化流程，而不是依赖于手动和容易出错的方法。

在设计新环境的架构时，我们建议您考虑使用多集群 GKE 环境。通过在环境中预配和配置多个 GKE 集群，可以获得以下好处：

  • 降低在架构中引入单点故障的可能性。例如，如果某个集群发生服务中断，其他集群可以接管。
  • 受益于多集群环境提供的更大灵活性。例如，通过将更改应用于部分集群，您可以限制错误配置更改导致的问题的影响。然后，您可以先验证更改，然后再将其应用于其余集群。
  • 让工作负载跨集群通信。例如，部署在一个集群中的工作负载可以与部署在另一个集群中的工作负载通信。

本文档中的指南也适用于单集群 GKE 环境。迁移到单集群 GKE 环境后，与多集群环境相比，其环境管理较为简单。但是，单集群环境无法受益于多集群 GKE 环境提供的更高的灵活性、可靠性和弹性。

下图说明了迁移过程的路径。

迁移路径包含四个阶段。

上图所示的框架包含迁移到 Google Cloud：使用入门中定义的以下阶段：

  1. 评估和发现工作负载。
  2. 规划和构建基础。
  3. 部署工作负载。
  4. 优化您的环境。

您将在每个迁移步骤中按照上述阶段操作。本文档还依赖于将容器迁移到 Google Cloud：将 Kubernetes 迁移到 GKE中讨论的概念，相应位置会提供链接。

评估您的环境

在评估阶段，您需要收集有关来源环境和要迁移的工作负载的信息。此评估对于迁移以及合理调整迁移过程和目标环境所需的资源至关重要。在评估阶段，您将完成以下任务：

  1. 构建一个完整的应用清单。
  2. 根据应用的属性和依赖项对应用进行分类。
  3. 针对 Google Cloud 培训和指导您的团队。
  4. 针对 Google Cloud 构建实验和概念验证。
  5. 计算目标环境的总拥有成本 (TCO)。
  6. 选择您首先要迁移的工作负载。

以下部分依赖于《迁移到 Google Cloud：评估和发现工作负载》。 但提供了专门的信息供您评估要迁移到新 GKE 集群的工作负载。

在“将 Kubernetes 迁移到 GKE”中，评估环境介绍了如何评估 Kubernetes 集群和资源，例如 ServiceAccounts 和 PersistentVolume。此信息也适用于评估 GKE 环境。

构建您的清单

要确定迁移范围，您必须了解您当前的 GKE 环境。首先，您需要收集有关集群的信息，然后需要关注这些集群中部署的工作负载以及工作负载的依赖项。在评估阶段结束时，您会有两份清单：一份用于集群，另一份用于这些集群中部署的工作负载。

在“将 Kubernetes 迁移到 GKE”中，构建您的清单介绍了如何构建 Kubernetes 集群和工作负载的清单。它也适用于构建 GKE 环境的清单。在继续本文档之前，请先按照该指导构建 Kubernetes 集群的清单。

按照“将 Kubernetes 迁移到 GKE”指南构建您的清单后，您可以优化清单。要完成 GKE 集群和节点池的清单，请考虑每个集群和节点池的 GKE 特定方面和功能，包括：

构建清单时，您可能会发现在迁移过程中需要停用一些 GKE 集群。某些 Google Cloud 资源在您删除创建它们的 GKE 集群后不会被删除。请确保您的迁移计划包括弃用这些资源。

如需了解其他可能特定于 GKE 的方面和功能，请参阅 GKE 文档。

完成评估

构建与 GKE 集群和工作负载相关的清单后，请完成将容器迁移到 Google Cloud：将 Kubernetes 迁移到 GKE 中评估阶段的其余活动。

规划和构建基础

在规划阶段，您将预配和配置支持您在 Google Cloud 上的工作负载的基础、云基础架构和服务。在规划阶段，您将完成以下任务：

  • 构建资源层次结构。
  • 配置身份和访问权限管理。
  • 设置结算功能。
  • 设置网络连接。
  • 强化安全性。
  • 设置监控和提醒。

设置网络连接时，请确保您的子网中有足够的 IP 地址可分配给节点、pod 和 Service。为集群设置网络时，请谨慎地规划 IP 地址分配，例如，您可以为 GKE 配置以非公开方式使用的公共 IP。为集群上的 pod 和 Service 分配次要 IP 地址范围后便无法更改。如果分配的 pod 或 Service 范围为 /22（1024 个地址）或更小，请特别小心。否则，随着集群规模扩大，pod 和 Service 的 IP 地址可能会耗尽。如需了解详情，请参阅 IP 地址范围规划。

我们建议为您为 GKE 环境创建的内部负载均衡器使用单独的共享子网。使用 type: LoadBalancer 的 Kubernetes 服务时，您可以指定负载均衡器子网。配置内部 HTTP(S) 内部负载均衡器时，必须配置代理专用子网。

要构建 GKE 环境的基础，请完成将容器迁移到 Google Cloud：将 Kubernetes 迁移到 GKE 中的规划和构建阶段的活动。

部署工作负载

在部署阶段，您将执行以下操作：

  1. 预配和配置目标环境。
  2. 将数据从来源环境迁移到目标环境。
  3. 在目标环境中部署您的工作负载。

本部分提供了将工作负载部署到 GKE 的专门信息。它基于将 Kubernetes 迁移到 GKE：部署工作负载中的信息。

评估您的运行时平台和环境

如需获得更灵活、更可靠且更易于维护的基础架构，我们建议您设计和实现多集群架构。在多集群架构中，您的环境中有多个生产 GKE 集群。例如，如果您在环境中预配多个 GKE 集群，则可以实现高级集群生命周期策略，例如滚动升级或蓝绿升级。如需详细了解多集群 GKE 架构设计及其优势，请参阅使用多集群 Ingress 执行多集群 GKE 升级。

跨多个集群运行环境时，还需要考虑其他挑战，例如：

  • 您需要为传入流量调整配置管理、服务发现和通信、应用发布和负载均衡。
  • 您可能需要在集群上运行额外的软件，以及额外的自动化和基础架构。

为应对这些挑战，您可能需要使用持续集成/持续部署 (CI/CD) 流水线按顺序更新集群配置，以最大限度地减少错误的影响。您可能还需要使用负载均衡器将流量从一个集群分发到其他集群。

手动管理基础架构容易出错，并且由于配置错误以及缺少有关基础架构当前状态的内部文档，您可能会遇到问题。为帮助降低这些问题带来的风险，我们建议您应用基础架构即代码模式。应用此模式时，您可以按处理工作负载源代码的方式处理基础架构预配。

多集群 GKE 环境有几个架构方案，本部分稍后会进行介绍。选择哪个方案取决于多个因素，没有一个方案天生优于其他方案。每种类型各有利弊。要选择架构类型，请执行以下操作：

  1. 建立一组标准来评估多集群 GKE 环境的架构类型。
  2. 根据评估标准评估每种环境。
  3. 选择最符合您需求的方案。

如需建立评估多集群 GKE 环境的架构类型的标准，请使用您完成的环境评估来确定所需的功能。按重要性对功能进行排序。例如，在评估工作负载和环境后，您可以考虑使用以下评估标准（按可能的重要性顺序列出）：

  1. Google 管理的解决方案。您希望使用 Google 管理还是自行管理的服务和产品？
  2. 与架构进行交互的界面。是否有您可以与之进行交互的机器可读界面？界面是否定义为开放标准？界面支持声明式指令还是命令式指令，还是同时支持两者？
  3. 在 GKE 环境外部公开服务。该架构是否允许您在工作负载部署到的 GKE 集群外部公开工作负载？
  4. 集群间通信。该架构是否支持集群之间的通信通道？您的工作负载是否支持分布式架构？此项标准对于支持具有分布式设计（例如 Jenkins）的工作负载非常重要。
  5. 流量管理。该架构是否支持高级流量管理功能，例如故障注入、流量转移、请求超时和重试、断路器以及流量镜像？这些功能是立即可用还是需要您自行实现？
  6. 预配和配置其他工具。您是否需要预配和配置其他硬件或软件组件？

Google Cloud 提供以下用于设计多集群 GKE 环境架构的方案。要为工作负载选择最佳方案，您首先需要根据之前建立的评估标准对工作负载进行评估。使用任意的有序等级，针对每项评估标准为每个设计方案分配得分。例如，您可以针对每项评估标准为每个环境分配一个得分，评分等级为 1 到 10。以下方案基于管理新的多集群 GKE 环境所需的工作量，按递增顺序显示。

  1. 多集群 Ingress 和多集群服务发现
  2. 多集群 Ingress 和 Anthos Service Mesh
  3. Traffic Director
  4. Kubernetes 和自行管理的 DNS 记录更新

以下部分详细介绍了这些方案，并提供评估每个方案的标准的列表。通过阅读产品文档，您可能可以根据某些标准分配得分。例如，通过阅读文档，您可以根据之前建立的一些评估标准来评估 Anthos Service Mesh。但是，如需根据其他标准分配得分，您可能需要设计和执行更深入的基准和模拟。例如，您可能需要对不同多集群 GKE 架构的性能进行基准化分析，以评估它们是否适合您的工作负载。

多集群 Ingress 和多集群服务发现

多集群 Ingress 是一项 Google 管理的服务，可让您公开工作负载，无论工作负载部署到哪个 GKE 集群。它还允许您跨 GKE 集群和区域配置共享负载均衡器。如需详细了解如何在多集群 GKE 环境中使用多集群 Ingress，请参阅使用多集群 Ingress 执行多集群 GKE 升级和通过 Istio 网格扩展功能为迁移提供支持。

多集群服务发现是 GKE 的 Kubernetes 原生跨集群服务发现和连接机制。多集群服务发现基于 Kubernetes Service 资源构建，可帮助应用跨集群边界相互发现和连接。如需根据您之前建立的标准评估多集群 Ingress 和多集群服务发现，请使用以下列表（按照相对重要性编号）：

  1. Google 管理的解决方案。多集群服务发现是 GKE 的全代管式功能。它配置资源（Cloud DNS 区域和记录、防火墙规则和 Traffic Director），使您无需管理资源。
  2. 与架构进行交互的界面。使用名为 ServiceExport 的声明式 Kubernetes 资源将 Service 导出到其他集群。
  3. 在 GKE 环境外部公开服务。使用多集群 Ingress 和多集群服务发现时，无论您的工作负载部署在何处，您都可以在 GKE 集群外部公开工作负载。
  4. 集群间通信。您可以通过声明 ServiceExport 对象将现有 Service 导出到其他 GKE 集群。同一队列中的 GKE 集群会自动导入您使用 ServiceExport 对象导出的 Service。多集群服务发现会为每个导出的 Service 设置虚拟 IP 地址。多集群服务发现使用 Kubernetes DNS 惯例的简单变体自动配置 Traffic Director 资源、Cloud DNS 和防火墙规则，以发现和连接 Service。例如，要访问 my-svc Service，您可以使用 my-svc.my-ns.svc.clusterset.local 名称。
  5. 流量管理。多集群服务发现配置了简单的第 3/4 层连接，并依赖 DNS 进行服务发现。它不提供任何流量管理功能。
  6. 预配和配置其他工具。您可以通过启用 Google API 来设置多集群服务发现。无需安装任何其他工具。如需了解详情，请参阅将容器迁移到 Google Cloud：迁移到使用多集群服务发现和多集群 Ingress 的多集群 GKE 环境

多集群 Ingress 和 Anthos Service Mesh

服务网格是一种架构模式，可帮助分布式应用解决网络难题。这些难题包括服务发现、负载均衡、容错、流量控制、可观测性、身份验证、授权和传输加密。典型的服务网格实现由数据平面和控制平面组成。数据平面负责直接处理流量并将其转发到目标工作负载（通常使用边车代理）。控制平面是指配置数据平面的组件。

在基础架构中实现服务网格模式时，您可以选择以下两种 Google Cloud 产品之一：Anthos Service Mesh 和 Traffic Director。这两种产品都提供了一个控制平面，用于跨多个 GKE 集群配置应用层 (L7) 网络。Anthos Service Mesh 基于 Istio，提供声明式开源 API。Traffic Director 基于 Google 负载均衡功能和开源技术的结合，提供命令式 Google API。

Anthos Service Mesh 是 Google 管理的一套工具，可让您连接、管理、保护和监控工作负载（无论它们部署到哪个 GKE 集群），而无需修改您的应用代码。如需详细了解如何使用 Anthos Service Mesh 设置跨多个 GKE 集群的网格，请参阅将 GKE 集群添加到 Anthos Service Mesh。如需根据您之前建立的标准评估多集群 Ingress 和 Anthos Service Mesh，请使用以下列表（按照相对重要性编号）：

  1. Google 管理的解决方案。多集群 Ingress 和 Anthos Service Mesh 都是全代管式产品。您无需预配这些产品，因为 Google 会为您管理这些产品。
  2. 与架构进行交互的界面。Anthos Service Mesh 以 Istio 为核心。Anthos Service Mesh API 支持基于 Kubernetes 资源模型的声明式配置。
  3. 在 GKE 环境外部公开服务。利用多集群 Ingress 和 Anthos Service Mesh 入站流量网关，您可以在 GKE 集群外部公开工作负载。
  4. 集群间通信。无论 pod 在哪个集群运行，Anthos Service Mesh 会直接在 pod 之间设置安全通信通道。此设置使您无需花费额外的精力来预配和配置这些通信通道。Anthos Service Mesh 使用舰队和服务相同性概念将 GKE 服务发现扩展到多个集群。因此，您无需修改工作负载即可发现在网格的其他集群上运行的工作负载。
  5. 流量管理。Anthos Service Mesh 提供了高级流量管理功能，可用于控制保护传入流量以及将其路由到工作负载的方式。例如，Anthos Service Mesh 支持所有 Istio 流量管理功能，例如：故障注入、请求超时和重试、断路器、流量镜像和流量转移。您还可以使用这些流量管理功能来简化迁移到新 GKE 环境的过程。例如，您可以逐渐将流量从旧环境转移到新环境。
  6. 预配和配置其他工具。如需使用多集群 Ingress，您需要满足多集群服务发现前提条件，但不需要在 GKE 集群中安装其他工具。如需使用 Anthos Service Mesh，您需要在集群中安装 Anthos Service Mesh。

Traffic Director

Traffic Director 是应用网络的代管式控制平面。它允许您预配和配置丰富的服务网格拓扑，以及高级流量管理和可观测性功能。如需详细了解 Traffic Director，请参阅 Traffic Director 概览和 Traffic Director 功能。如需预配和配置跨多个 GKE 集群的服务网格，您可以使用多集群或多环境 Traffic Director 配置。如需根据您之前建立的标准评估 Traffic Director，请使用以下列表（按相对重要性编号）：

  1. Google 管理的解决方案。Traffic Director 是全代管式产品。您无需配置此类产品，因为 Google 会为您管理这些产品。
  2. 与架构进行交互的界面。您可以使用 Google Cloud 控制台、Google Cloud CLI、Traffic Director API 或 Terraform 等工具配置 Traffic Director。Traffic Director 支持命令式配置模型，它基于开源产品和技术构建，例如 xDS 和 gRPC。
  3. 在 GKE 环境外部公开服务。Traffic Director 会预配和配置负载均衡器以处理来自服务网络外部的流量。
  4. 集群间通信。Traffic Director 控制平面提供 API，可让您将端点（例如多个集群上的 GKE pod）分组为服务后端。然后，这些后端可以从网格中的其他客户端路由。Traffic Director 未直接与 GKE 服务发现集成，但您可以选择使用开源控制器（如 gke-autoneg-controller）来自动完成集成。您还可以选择使用多集群服务发现将 GKE 服务发现扩展到多个集群。
  5. 流量管理。Traffic Director 提供高级流量管理功能，可用于简化迁移到新 GKE 环境的过程以及增强架构的可靠性。如需了解如何配置精确的流量路由、基于权重的流量拆分、流量镜像和精确调整的负载均衡等功能，请参阅配置高级流量管理。
  6. 预配和配置其他工具。Traffic Director 不在您的 GKE 集群中运行。如需了解如何预配和配置 Traffic Director，请参阅设置 Traffic Director 前的准备工作。如需配置 Traffic Director 需要的边车 pod 以在服务网络中包含您的工作负载，请参阅在 GKE pod 上部署具有 Envoy 的 Traffic Director。

Kubernetes 和自行管理的 DNS 记录更新

如果您不想在集群上安装其他软件，并且不需要服务网格提供的功能，则可以选择 Kubernetes 和自行管理的 DNS 记录更新方案。

虽然您可以使用此方案配置集群间发现和连接，但我们建议您选择本文档中介绍的其他方案。运行自行管理的解决方案所需的工作量远大于您可以从中获得的好处。另外，请考虑以下重要限制：

当您在 GKE 集群中创建 type: LoadBalancer 的 Service 或 Ingress 对象时，GKE 会自动创建网络负载均衡器和 HTTP(S) 负载均衡器，以使用负载均衡器 IP 地址公开该 Service。您可以使用负载均衡器的 IP 地址与 Service 进行通信。但是，我们建议您将这些 IP 地址映射到使用 Cloud DNS 的 DNS 记录或您可以使用 DNS 查询的 Service Directory 端点以避免依赖于 IP 地址，并配置客户端以使用这些 DNS 记录。您可以部署 Service 的多个实例，并将生成的所有负载均衡器 IP 地址映射到相关的 DNS 记录或 Service Directory 端点。

如需弃用 Service 的某个实例，请先从相关 DNS 记录或 Service Directory 端点移除相关的负载均衡器 IP 地址。然后，确保客户端的 DNS 缓存已更新，然后再弃用 Service。

您可以将工作负载配置为能够跨不同的 GKE 集群相互通信。为此，请先使用内部 TCP/UDP 负载均衡器或内部 HTTP(S) 负载均衡器在集群外部公开您的服务。然后，将负载均衡器的 IP 地址映射到 DNS 记录或 Service Directory 端点。最后，创建 type: ExternalName 的服务，使其指向每个集群中的这些 DNS 记录或 Service Directory 端点。

（可选）您可以使用一个额外的 Ingress 控制器与多个工作负载共享单个负载均衡器和 Cloud DNS 记录或 Service Directory 端点。例如，如果您在集群中预配一个 Ingress 控制器，则可以将其配置为将传入 GKE 为该 Ingress 控制器创建的负载均衡器的请求重定向到多个 Service。使用额外的 Ingress 控制器可以减少您需要管理的 DNS 记录或 Service Directory 端点的数量。

如需根据您之前建立的标准评估 Kubernetes 和自行管理的 DNS 记录更新，请使用以下列表（按照相对重要性编号）：

  1. Google 管理的解决方案。您自行管理属于此解决方案的 Kubernetes 对象。Cloud DNS、Service Directory 和 Load Balancing 是 Google 管理的服务。
  2. 与架构进行交互的界面。GKE 以 Kubernetes 为核心，同时支持命令式和声明式配置模型。
  3. 在 GKE 环境外部公开服务。您可以使用 DNS 记录、Service Directory Endpoints 和负载均衡器将服务公开给 GKE 集群外部的客户端。
  4. 集群间通信。借助 type: ExternalName 的 Service，您可以定义指向另一个 GKE 集群中部署的服务的端点。此配置可让服务相互通信，就像它们部署在同一个集群中一样。
  5. 流量管理。除了 Kubernetes 和 GKE 已提供的功能之外，此解决方案不提供其他流量管理功能。例如，此方案不支持在不同集群之间分配流量。
  6. 预配和配置其他工具。此方案不需要在 GKE 集群中预配和配置其他软件。您可以选择安装 Ingress 控制器。

选择架构

为每个方案的每项标准分配值后，您需要计算每个方案的总得分。要计算每个方案的总得分，请根据标准加总该方案的所有评分。例如，如果一个环境在一项标准上得分为 10，在另一项标准上得分为 6，则该方案的总得分为 16。

您还可以向每项标准的得分分配不同的权重，从而体现每项标准对于评估的重要性。例如，如果在您的评估中，Google 管理的解决方案比支持分布式工作负载架构更重要，您可以定义系数来反映这一点：Google 管理的解决方案的系数为 1.0，分布式工作负载架构的系数为 0.7。然后，您使用这些乘数来计算一个选项的总得分。

计算您评估的每个环境的总得分后，您可以根据其总得分按降序排列环境。然后，选择得分最高的选项作为您选择的环境。

您可以通过多种方式表示这些数据，例如，您可以使用适合表示多变量数据的图表（例如雷达图表）直观呈现结果。

将数据从旧环境迁移到新环境

如需了解如何将数据从旧环境迁移到新环境，请参阅“将 Kubernetes 迁移到 GKE”中的将数据从旧环境迁移到新环境。

部署工作负载

如需了解如何将数据从旧环境迁移到新环境，请参阅部署工作负载。

本文档中的所有架构方案都可以让您将工作负载从现有的 GKE 环境迁移到新的多集群环境，没有任何停机时间或切换窗口。要在不停机的情况下迁移工作负载，请执行以下操作：

  1. 在新的多集群 GKE 环境中暂时集成现有的旧 GKE 集群。
  2. 在新的多集群环境中部署您的工作负载的实例。
  3. 逐渐从现有环境迁移流量，以便逐步将工作负载迁移到新的 GKE 集群，然后弃用旧的 GKE 集群。

完成部署

预配和配置运行时平台和环境后，请完成“将 Kubernetes 迁移到 GKE”的部署工作负载中所述的活动。

优化您的环境

优化是迁移的最后一个阶段。在此阶段，您将使环境比以前更高效。要优化环境，请完成以下可重复循环的多次迭代，直到环境满足您的优化要求：

  1. 评估您的当前环境、团队和优化循环。
  2. 确定优化要求和目标。
  3. 优化您的环境和团队。
  4. 调整优化循环。

如需执行 GKE 环境的优化，请参阅“将 Kubernetes 迁移到 GKE”中的优化您的环境。

后续步骤