Google Cloud 提供了用于从 Amazon Elastic Kubernetes Service (Amazon EKS) 迁移到 Google Kubernetes Engine (GKE) 的工具、产品、指导和专业服务。本文档可帮助您设计、实施和验证从 Amazon EKS 迁移到 GKE 的计划。如果您要评估迁移的机会并希望了解迁移的可能情况，本文档也提供了指导。除了在 Amazon Elastic Compute Cloud (Amazon EC2) 上运行之外，Amazon EKS 还有一些其他部署选项，例如 AWS 输出上的 Amazon EKS 和任何位置的 Amazon EKS。本文档重点介绍 Amazon EKS on EC2。
本文档是关于从 AWS 迁移到 Google Cloud 的系列文章中的一篇，该系列文章包括以下文档：
- 开始
- 从 Amazon EC2 迁移到 Compute Engine
- 从 Amazon S3 迁移到 Cloud Storage
- 从 Amazon EKS 迁移到 Google Kubernetes Engine（本文档）
- 从 Amazon RDS 和 Amazon Aurora for MySQL 迁移到 Cloud SQL for MySQL
- 从 Amazon RDS 和 Amazon Aurora for PostgreSQL 迁移到 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL
- 从 Amazon RDS for SQL Server 迁移到 Cloud SQL for SQL Server
- 从 AWS Lambda 迁移到 Cloud Run
GKE 是一项由 Google 管理的 Kubernetes 服务，可用来使用 Google 的基础架构大规模部署和操作容器化应用，并提供有助于管理 Kubernetes 环境的功能，例如：
- 两个版本：GKE Standard 和 GKE Enterprise。借助 GKE Standard，您可以使用标准层级的核心功能。借助 GKE Enterprise，您可以使用 GKE 的所有功能。如需了解详情，请参阅 GKE 版本。
- 两种运维模式：：标准模式和 Autopilot 模式。使用标准模式时，您可以管理 GKE 集群中每个节点的底层基础架构和配置。使用 Autopilot 模式时，GKE 管理底层基础架构，例如节点配置、自动扩缩、自动升级、基准安全和网络配置。如需详细了解 GKE 运维模式，请参阅选择 GKE 运维模式。
- 在多个可用区中使用 Autopilot 模式时，Pod 的行业特有的服务等级协议。
- 通过节点自动预配功能自动创建和删除节点池。
- 由 Google 管理的多集群网络，可帮助您为工作负载设计和实现高可用性分布式架构。
如需详细了解 GKE，请参阅 GKE 概览。
如需迁移到 Google Cloud，建议您遵循迁移到 Google Cloud：使用入门中所述的迁移框架。
下图说明了迁移过程的路径。
您可能需要通过一系列迭代从来源环境迁移到 Google Cloud，例如，您可能会先迁移一部分工作负载，然后再迁移其他工作负载。对于每个单独的迁移迭代，您都需要遵循一般迁移框架的各个阶段：
- 评估和发现工作负载和数据。
- 在 Google Cloud 上规划和构建基础。
- 将工作负载和数据迁移到 Google Cloud。
- 优化您的 Google Cloud 环境。
如需详细了解此框架的各个阶段，请参阅迁移到 Google Cloud：使用入门。
如需设计有效的迁移计划，建议您验证计划的每个步骤，并确保您具有回滚策略。为了帮助验证您的迁移计划，请参阅迁移到 Google Cloud：验证迁移计划的最佳做法。
评估来源环境
在评估阶段，您需要确定从来源环境迁移到 Google Cloud 的要求和依赖项。
评估阶段对于成功迁移而言至关重要。您需要深入了解需要迁移的工作负载，它们的要求和依赖项以及您当前的环境。您需要清楚自己的起点，这样才能成功地计划和执行 Google Cloud 迁移。
评估阶段包括以下任务：
- 构建一个完整的工作负载清单。
- 根据工作负载的属性和依赖项对工作负载进行分类。
- 为您的团队开展 Google Cloud 培训和指导
- 在 Google Cloud 上构建实验和概念验证。
- 计算目标环境的总拥有成本 (TCO)。
- 为工作负载选择迁移策略。
- 选择迁移工具。
- 定义迁移计划和时间表。
- 验证迁移计划。
如需详细了解评估阶段和这些任务，请参阅迁移到 Google Cloud：评估和发现工作负载。以下部分基于该文档中的信息。
构建您的清单
为了确定迁移范围，请创建两份清单：
- 集群的清单。
- 在这些集群中部署的工作负载清单。
构建这些清单后，您可以：
- 评估来源环境的部署和运营流程。
- 评估支持服务和外部依赖项。
构建集群清单
如需构建集群的清单，请针对每个集群考虑以下方面：
- 节点的数量和类型。如果您知道当前环境有多少个节点以及每个节点的特性，则可以在迁移到 GKE 时确定集群的大小。运行新环境中的节点的硬件架构或代次可能与您在现有环境中使用的硬件架构或代次不同。每个架构和代次的性能各不相同，因此新环境所需要的节点数量可能与您的现有环境不同。请评估您在节点中使用的任何类型的硬件，例如高性能存储设备、GPU 和 TPU。 评估您要在节点上使用的操作系统映像。
- 内部或外部集群。请评估每个集群会公开给环境内部或外部的哪些操作者。为了支持您的用例，此评估包括集群中运行的工作负载以及与集群进行交互的接口。
- 多租户。如果您正在现有环境中管理多租户集群，请评估其在新的 Google Cloud 环境中能否正常运行。现在是评估如何改进多租户集群的好时机，因为多租户策略会影响您在 Google Cloud 上构建基础的方式。
- Kubernetes 版本。请收集有关集群的 Kubernetes 版本的信息，以评估这些版本与 GKE 中提供的版本是否不匹配。如果您运行的是旧版或最近发布的 Kubernetes 版本，则您使用的可能是 GKE 不提供的功能。这些功能可能已被弃用，或者 GKE 尚不提供包含这些功能的 Kubernetes 版本。
- Kubernetes 升级周期。如需维持可靠的环境，请了解如何处理 Kubernetes 升级以及升级周期与 GKE 升级的关系。
- 节点池。如果您正在使用任何形式的节点分组，则可能需要考虑这些分组如何映射到 GKE 中的节点池概念，因为您的分组条件可能不适合 GKE。
- 节点初始化。请评估每个节点的初始化方式，然后将其标记为可用于运行工作负载，以便您将这些初始化过程迁移到 GKE。
- 网络配置。评估集群的网络配置、其 IP 地址分配、如何配置其网络插件、如何配置其 DNS 服务器和 DNS 服务提供商（如果为这些集群配置了任何形式的 NAT 或 SNAT）以及它们是否为多集群环境的一部分。
- 合规性：评估集群需要满足的任何合规性和监管要求，以及是否满足这些要求。
- 配额和限制。评估如何为集群配置配额和限制。例如，每个节点可以运行多少个 Pod？一个集群可以有多少个节点？
- 标签和标记。评估您应用于集群、节点池和节点的任何元数据及其使用方式。例如，您可能会生成具有基于标签的详细费用归属的报告。
您在清单中评估的以下内容侧重于基础架构和 Kubernetes 集群的安全性：
- Namespace。如果您在集群中使用 Kubernetes 命名空间来逻辑分隔资源，请评估每个命名空间中有哪些资源，并了解创建这种分隔的原因。例如，您可能会将 Namespace 用作多租户策略的一部分。您可能会在为 Kubernetes 系统组件预留的 Namespace 中部署工作负载，并且在 GKE 中可能不会实施相同的控制措施。
- 基于角色的访问控制 (RBAC)。如果您在集群中使用 RBAC 授权，请列出您在集群中配置的所有 ClusterRole 和 ClusterRoleBinding 的说明。
- 网络政策。 请列出您在集群中配置的所有网络政策，并了解网络政策在 GKE 中的工作原理。
- Pod 安全上下文。请捕获有关您在集群中配置的 Pod 安全上下文的信息，并了解它们在 GKE 中的工作原理。
- 服务账号。如果集群中有任何进程正在与 Kubernetes API 服务器交互，请捕获有关它们正在使用的服务账号的信息。
构建 Kubernetes 集群的清单时，您可能会发现在迁移过程中需要停用一些集群。请确保您的迁移计划包括弃用这些资源。
构建 Kubernetes 工作负载清单
完成 Kubernetes 集群清单并评估环境的安全性后，请构建这些集群中部署的工作负载清单。评估工作负载时，请收集有关以下方面的信息：
- Pod 和控制器。如需确定新环境中的集群大小，请评估您已部署的每个工作负载的实例数量，以及您是否使用了资源配额和计算资源消耗限制。 收集有关在每个集群的控制层面节点上运行的工作负载以及每个工作负载使用的控制器的信息。例如，您正在使用多少个 Deployment？您正在使用多少个 DaemonSet？
- 作业和 Cron 作业。您的集群和工作负载可能需要在初始化或操作过程中运行作业或 Cron 作业。评估您已部署的作业和 Cron 作业实例的数量，以及每个实例的责任和完成标准。
- Kubernetes 自动扩缩器。如需在新环境中迁移自动扩缩政策，请了解 Pod 横向自动扩缩器和 Pod 纵向自动扩缩器在 GKE 上的工作原理。
- 无状态和有状态工作负载。无状态工作负载不会将数据或状态存储在集群或永久性存储空间中。有状态应用会保存数据供以后使用。对于每个工作负载，请评估哪些组件是无状态组件以及哪些组件是有状态组件，因为迁移有状态工作负载通常比迁移无状态工作负载更困难。
- Kubernetes 特性。从集群清单中，您可以了解每个集群运行的 Kubernetes 版本。请查看每个 Kubernetes 版本的版本说明，了解它包含哪些特性以及弃用了哪些特性。然后，请根据您需要的 Kubernetes 特性评估您的工作负载。此任务的目的是了解您使用的是已弃用的特性还是尚未在 GKE 中提供的特性。如果您发现任何不可用的特性，请停止使用已弃用的特性，并在 GKE 提供新特性时采用这些新特性。
- 存储。对于有状态工作负载，请评估它们是否使用 PersistenceVolumeClaim。请列出任何存储要求（例如大小和访问模式），以及这些 PersistenceVolumeClaim 映射到 PersistenceVolume 的方式。为了考虑未来增长，请评估是否需要扩展任何 PersistenceVolumeClaim。
- 配置和密文注入。为了避免每次更改环境配置时重新构建可部署的制品，请使用 ConfigMap 和 Secret 将配置和密文注入 Pod。对于每个工作负载，请评估该工作负载正在使用哪些 ConfigMap 和 Secret，以及如何填充这些对象。
- 依赖项。您的工作负载可能无法独立运行。它们可能具有依赖项，这些依赖项位于集群内部或者来自外部系统。对于每个工作负载，请捕获依赖项以及您的工作负载能否容忍依赖项不可用的情况。例如，常见的依赖项包括分布式文件系统、数据库、Secret 分发平台、身份和访问权限管理系统、服务发现机制以及任何其他外部系统。
- Kubernetes Service。如需将工作负载公开给内部和外部客户端，请使用 Service。对于每个 Service，您需要知道其类型。对于外部公开的服务，请评估该服务与基础架构的其余部分进行交互的方式。例如，您的基础架构如何支持 LoadBalancer 服务、网关对象和 Ingress 对象？您在集群中部署了哪些 Ingress 控制器？
- 服务网格。如果您正在环境中使用服务网格，请评估其配置方式。您还需要知道它涵盖多少个集群、哪些服务是该网格的一部分，以及如何修改该网格的拓扑。
- 污点和容忍以及亲和性和反亲和性。对于每个 Pod 和节点，请评估您是否配置了任何节点污点、Pod 容忍度或亲和性，以自定义 Kubernetes 集群中的 Pod 调度。您还可以通过这些属性发现可能的非同构节点或 Pod 配置，在这种情况下，可能意味着您需要特别留意并谨慎处理对 Pod 和/或节点的评估。例如，如果您将一组特定的 Pod 配置为仅在 Kubernetes 集群中的部分节点上调度，则可能意味着这些 Pod 需要使用仅在相应节点上可用的专用资源。
- 身份验证：评估工作负载如何针对集群中的资源和外部资源进行身份验证。
评估支持服务和外部依赖性
评估集群及其工作负载后，请评估基础架构中的其他支持服务和方面，例如：
- StorageClass 和 PersistentVolume。通过列出用于动态预配的 StorageClass 和静态预配的 PersistentVolume，评估您的基础架构如何支持 PersistentVolumeClaim。对于每个 PersistentVolume，请考虑以下方面：容量、卷模式、访问模式、类、回收政策、装载选项和节点亲和性。
- VolumeSnapshot 和 VolumeSnapshotContent。 对于每个 PersistentVolume，请评估您是否配置了任何 VolumeSnapshot，以及是否需要迁移任何现有 VolumeSnapshotContent。
- 容器存储接口 (CSI) 驱动程序。 如果部署在集群中，请评估这些驱动程序是否与 GKE 兼容，以及您是否需要调整卷的配置以适合与 GKE 兼容的 CSI 驱动程序。
- 数据存储。如果您依赖外部系统来预配 PersistentVolume，请为 GKE 环境中的工作负载提供一种使用这些系统的方法。数据存放区域会影响有状态工作负载的性能，因为外部系统和 GKE 环境之间的延迟时间与它们之间的距离成比例。对于每个外部数据存储系统，请考虑其类型（例如块卷、文件存储或对象存储），以及它需要满足的任何性能和可用性要求。
- 自定义资源和 Kubernetes 插件。收集有关可能已在集群中部署的任何自定义 Kubernetes 资源和任何 Kubernetes 插件的信息，因为这些资源可能无法在 GKE 中运行，或者您可能需要修改这些资源。例如，如果自定义资源与外部系统交互，您可以评估该资源是否适用于您的 Google Cloud 环境。
- 备份。评估来源环境中的集群配置和有状态工作负载数据的备份方式。
评估您的部署和运营流程
请务必清楚了解部署和运营流程的工作原理。这些流程是准备和维护生产环境以及在其中运行的工作负载的实践的基本组成部分。
部署和运营流程可能会构建工作负载正常运行所需的工件。因此，您应该收集有关每种工件类型的信息。例如，工件可以是操作系统软件包、应用部署包、操作系统映像、容器映像或其他类型。
除了工件类型之外，请考虑如何完成以下任务：
- 开发工作负载。评估开发团队为构建工作负载而制定的流程。例如，您的开发团队如何设计、编写和测试工作负载？
- 生成您在来源环境中部署的工件。为了在来源环境中部署工作负载，您可能会生成可部署的工件（例如容器映像或操作系统映像），或者您可能会通过安装和配置软件来自定义现有工件（例如第三方操作系统映像）。收集有关如何生成这些工件的信息有助于确保生成的工件适合在 Google Cloud 中部署。
存储工件。如果您生成存储在来源环境的 Artifact Registry 中的工件，则需要在 Google Cloud 环境中提供这些工件。为此，您可以使用以下策略：
- 在环境之间建立通信通道：使来源环境中的工件可从目标 Google Cloud 环境进行访问。
- 重构工件构建流程：完成来源环境的小幅度重构，以便在来源环境和目标环境中存储工件。此方法通过在目标 Google Cloud 环境中实现工件构建流程之前先构建工件制品库等基础架构来支持迁移。您可以直接实现此方法，也可以在上述先建立通信通道方法的基础上进行构建。
通过在来源环境和目标环境中均提供工件，您可以专注于迁移，而无需在迁移过程中在目标 Google Cloud 环境中实现工件构建流程。
扫描代码并签名。在工件构建流程中，您可能会使用代码扫描来帮助防范常见漏洞和意外的网络泄露，并使用代码签名来帮助确保只有受信任的代码在您的环境中运行。
在来源环境中部署工件。生成可部署的工件后，您可能会将其部署到来源环境中。建议您评估每个部署流程。评估有助于确保您的部署流程与 Google Cloud 兼容。它还有助于您了解最终重构流程所需的工作量。例如，如果部署流程仅适用于来源环境，则可能需要重构它们，从而以您的 Google Cloud 环境为目标。
注入运行时配置。您可能会注入特定集群、运行时环境或工作负载部署的运行时配置。该配置可能会初始化环境变量和其他配置值，例如 Secret、凭据和密钥。为帮助确保运行时配置注入过程在 Google Cloud 上正常运行，建议您评估如何配置在来源环境中运行的工作负载。
日志记录、监控和剖析。评估您实施来监控来源环境的健康、相关指标以及您如何使用这些流程提供的数据的日志记录、监控和剖析流程。
Authentication。评估您如何向来源环境进行身份验证。
预配和配置您的资源。为了准备来源环境，您可能设计并实现了预配和配置资源的流程。例如，您可能会使用 Terraform 以及配置管理工具在来源环境中预配和配置资源。
用于构建来源环境清单的工具
如需构建 Amazon EKS 集群的清单，我们建议您使用 Migration Center，这是 Google Cloud 的统一平台，可帮助您加快从当前环境到 Google Cloud 的端到端云之旅速度。 借助 Migration Center，您可以从 Amazon EKS 和其他 AWS 资源导入数据。然后，Migration Center 会推荐您可以迁移到的相关 Google Cloud 服务。
优化 Amazon EKS 集群和工作负载的清单
Migration Center 提供的数据可能无法完全捕获您感兴趣的维度。在这种情况下，您可以将该数据与您创建的基于 AWS API、AWS 开发者工具和 AWS 命令行界面的其他数据收集机制的结果集成。
除了从 Migration Center 获取的数据之外，还请考虑您要迁移的每个 Amazon EKS 集群的以下数据点：
- 考虑每个 Amazon EKS 集群特定于 Amazon EKS 的方面和功能，包括：
- 专用集群
- 集群端点访问权限控制
- Secret 加密
- 托管节点组和自行管理的节点
- Amazon EKS 资源上的标记
- EKS 中的 Amazon 自定义 AMI
- 使用 Amazon EKS Fargate
- 使用 Amazon EKS 管理的 Prometheus
- OpenID Connect 身份验证配置
- 评估您如何对 Amazon EKS 集群进行身份验证，以及如何为 Amazon EKS 配置 AWS Identity and Access Management (IAM)。
- 评估 Amazon EKS 集群的网络配置。
规划和构建基础
在规划和构建阶段，您需要预配和配置基础架构以执行以下操作：
- 在 Google Cloud 环境中支持您的工作负载。
- 连接来源环境和 Google Cloud 环境以完成迁移。
规划和构建阶段由以下任务组成：
- 构建资源层次结构。
- 配置 Google Cloud 的 Identity and Access Management (IAM)。
- 设置结算功能。
- 设置网络连接。
- 强化安全性。
- 设置日志记录、监控和提醒。
如需详细了解这些任务，请参阅迁移到 Google Cloud：规划和构建基础。
以下部分整合了“迁移到 Google Cloud：规划和构建基础”中的注意事项。
规划多租户
如需设计高效的资源层次结构，请考虑您的业务和组织结构如何映射到 Google Cloud。例如，如果您需要 GKE 上的多租户环境，可以在以下选项中进行选择：
- 为每个租户创建一个 Google Cloud 项目。
- 在不同租户之间共享一个项目，并预配多个 GKE 集群。
- 使用 Kubernetes 命名空间。
您的选择取决于您的隔离、复杂性和可扩缩性需求。例如，如果每个租户都有一个项目，则租户会彼此隔离，但由于项目数量较多，因此资源层次结构会变得更加复杂，难以管理。不过，虽然管理 Kubernetes Namespace 比复杂资源层次结构相对容易，但此方式并不能保证相同的隔离度。例如，控制平面可能会在租户之间共享。 如需了解详情，请参阅集群多租户。
配置身份和访问权限管理
GKE 支持使用 RBAC 来管理对 Google Cloud 项目及其集群中的资源的访问权限的多个选项。如需了解详情，请参阅访问权限控制。
配置 GKE 网络
网络配置是您的环境的基本方面。在预配和配置任何集群之前，建议您评估 GKE 网络模型、GKE 网络的最佳做法以及如何迁移到 GKE 时规划 IP 地址。
设置监控和提醒
清楚了解基础架构和工作负载的情况是寻找改进领域的关键。GKE 与 Google Cloud Observability 深度集成，因此您可以获取有关 GKE 集群以及这些集群中的工作负载的日日志记录、监控和剖析信息。
迁移数据并部署工作负载
在部署阶段，您将执行以下操作：
- 预配和配置 GKE 环境。
- 配置 GKE 集群。
- 重构工作负载。
- 重构部署和操作流程。
- 将数据从来源环境迁移到 Google Cloud。
- 在 GKE 环境中部署工作负载。
- 验证您的工作负载和 GKE 环境。
- 公开在 GKE 上运行的工作负载。
- 将流量从来源环境转移到 GKE 环境。
- 停用来源环境。
预配和配置您的 Google Cloud 环境
在将任何工作负载迁移到新的 Google Cloud 环境之前，请先预配 GKE 集群。
GKE 支持在现有集群上启用某些功能，但有些功能只能在创建集群时启用。为了帮助您避免中断并简化迁移，我们建议您在创建集群时启用所需的集群功能。否则，您可能需要销毁再重新创建集群，以防创建集群后无法启用所需的集群功能。
在评估阶段后，您现在已经知道如何在新的 Google Cloud 环境中预配 GKE 集群以满足您的需求。如需预配集群，请考虑以下事项：
- 集群数量、每个集群的节点数量、集群类型、每个集群和每个节点的配置，以及每个集群的可伸缩性方案。
- 每个集群的操作模式。GKE 提供了两种集群操作模式：GKE Autopilot 和 GKE Standard。
- 专用集群的数量。
- 选择 VPC 原生网络还是基于路由器的网络。
- GKE 集群中所需的 Kubernetes 版本和发布渠道。
- 用于对 GKE 集群中的节点进行逻辑分组的节点池，以及是否需要使用节点自动预配功能来自动创建节点池。
- 您可以从现有环境迁移到 GKE 环境的初始化过程以及您可以实现的新过程。例如，您可以通过为集群中的每个节点或节点池实施一个或多个最终具有特权的初始化过程来自动引导 GKE 节点。
- 每个集群的可伸缩性方案。
- 您需要的其他 GKE 功能，例如 Cloud Service Mesh 和 GKE 插件（例如 Backup for GKE）。
如需详细了解如何预配 GKE 集群，请参阅：
车队管理
预配 GKE 集群时，您可能会发现需要大量集群来支持环境的所有用例。例如，您可能需要将生产环境与非生产环境分开，或者跨团队或地理位置分隔服务。如需了解详情，请参阅多集群用例。
随着集群数量的增加，GKE 环境的运营可能会变得更加困难，因为管理大量集群会带来显著的可伸缩性和运营挑战。GKE 提供的工具和功能可帮助您管理舰队（即 Kubernetes 集群的逻辑分组）。如需了解详情，请参阅舰队管理。
多集群网络
为了帮助您提高 GKE 环境的可靠性，以及在多个 GKE 集群之间分配工作负载，您可以使用：
- 多集群服务发现（一种跨集群服务发现和调用机制）。服务可以跨 GKE 集群发现和访问。如需了解详情，请参阅多集群服务发现。
- 多集群网关（一种跨集群入站流量负载均衡机制）。如需了解详情，请参阅部署多集群网关。
- 托管式 Cloud Service Mesh 上的多集群网格。如需了解详情，请参阅设置多集群网格。
如需详细了解如何从单集群 GKE 环境迁移到多集群 GKE 环境，请参阅迁移到多集群网络。
配置 GKE 集群
在预配 GKE 集群之后，但在部署任何工作负载或迁移数据之前，请为每个 GKE 集群配置命名空间、RBAC、网络政策、服务账号以及其他 Kubernetes 和 GKE 对象。
如需在 GKE 集群中配置 Kubernetes 和 GKE 对象，我们建议您执行以下操作：
- 确保您拥有访问来源环境和 GKE 环境中的集群所需的凭据和权限。
- 评估来源环境中的 Kubernetes 集群内的对象是否与 GKE 兼容，以及支持这些对象的实现与来源环境和 GKE 的区别。
- 重构任何不兼容的对象使其与 GKE 兼容，或者弃用这些对象。
- 在 GKE 集群中创建这些对象。
- 在 GKE 集群中配置所需的任何其他对象。
Config Sync
为了帮助您采用 GitOps 最佳做法以在 GKE 扩缩时管理 GKE 集群的配置，建议您使用 Config Sync（一项用于从可靠来源部署配置的 GitOps 服务）。例如，您可以将 GKE 集群的配置存储在 Git 代码库中，并使用 Config Sync 应用该配置。
如需了解详情，请参阅 Config Sync 架构。
Policy Controller
Policy Controller 可帮助您应用和强制执行可编程政策，以帮助确保 GKE 集群和工作负载以安全且合规的方式运行。随着 GKE 环境的扩缩，您可以使用 Policy Controller 自动将政策、政策包和限制条件应用于所有 GKE 集群。例如，您可以限制从中提取容器映像的代码库，或者可以要求每个命名空间至少具有一个标签，以帮助您确保准确的资源消耗跟踪。
如需了解详情，请参阅政策控制器。
重构工作负载
设计容器化工作负载的最佳做法是避免依赖容器编排平台。由于工作负载的要求和设计，这在实践中并不总是可行的。例如，您的工作负载可能依赖于仅在来源环境中提供的特定于环境的功能，例如插件、扩展程序和集成。
虽然您可能能够将大多数工作负载按原样迁移到 GKE，但您可能需要花费额外的精力来重构依赖于特定于环境的功能的工作负载，才能最大限度地减少这些依赖项，最终切换到 GKE 上提供的替代方案。
如需在将工作负载迁移到 GKE 之前重构工作负载，请执行以下操作：
- 查看特定于来源环境的功能，例如插件、扩展程序和集成。
- 采用合适的替代 GKE 解决方案。
- 重构工作负载。
查看特定于来源环境的功能
如果您使用的是特定于来源环境的功能，并且您的工作负载依赖于这些功能，则需要执行以下操作：
- 找到合适的替代 GKE 解决方案。
- 重构工作负载，以便使用替代 GKE 解决方案。
在此次审核过程中，我们建议您执行以下操作：
- 考虑是否可以弃用上述任何特定于来源环境的功能。
- 评估特定于来源环境的功能对迁移成功的重要性。
采用合适的替代 GKE 解决方案
在查看特定于来源环境的功能并将其映射到合适的 GKE 替代解决方案后，就可以在 GKE 环境中采用这些解决方案了。为了降低迁移的复杂性，建议您执行以下操作：
- 避免为要弃用的特定于来源环境的功能采用替代 GKE 解决方案。
- 专注于为最关键的来源环境功能采用替代 GKE 解决方案，并为其余功能规划专用的迁移项目。
重构工作负载
虽然大多数工作负载可能可以如在 GKE 中那样运行，但您可能需要重构其中一些工作负载，尤其是当它们依赖于您采用了替代 GKE 解决方案的特定于来源环境的功能时。
此重构可能涉及：
- Kubernetes 对象描述符，例如以 YAML 格式表示的 Deployment 和 Service。
- 容器映像描述符，例如 Dockerfile 和 Containerfile。
- 工作负载源代码。
为了简化重构工作，建议您专注于应用使工作负载适合 GKE 所需的最少更改以及重大问题修复。您可以在将来的项目中规划其他改进和更改。
重构部署和操作流程
重构工作负载后，您可以重构部署和运营流程以执行以下操作：
- 在 Google Cloud 环境中预配和配置资源，而不是在来源环境中预配资源。
- 构建和配置工作负载并在 Google Cloud 中部署它们，而不是在来源环境中部署。
您在此过程早期的评估阶段收集了有关这些流程的信息。
您需要为这些流程考虑的重构类型取决于您如何设计和实现它们。重构还取决于您希望每个流程的最终状态是什么。例如，应该考虑以下事项：
- 您可能已经在来源环境中实现了这些流程，并打算在 Google Cloud 中设计和实现类似流程。例如，您可以重构这些流程，以使用 Cloud Build、Cloud Deploy 和 Infrastructure Manager。
- 您可能已在来源环境之外的其他第三方环境中实现这些流程。在这种情况下，您需要重构这些流程，以将您的 Google Cloud 环境作为目标，而不是将来源环境作为目标。
- 之前方法的组合。
重构部署和运营流程可能很复杂，并且可能需要花费大量精力。如果您尝试将这些任务作为工作负载迁移的一部分执行，则工作负载迁移可能会变得更加复杂，并可能使您面临风险。评估部署和操作流程后，您可能了解了其设计和复杂性。如果您估计重构部署和操作流程需要大量工作，建议您考虑将重构这些流程作为单独的专用项目的一部分。
如需详细了解如何在 Google Cloud 上设计和实现部署流程，请参阅：
本文档重点介绍用于生成要部署的工件并将其部署在目标运行时环境中的部署流程。重构策略在很大程度上取决于这些流程的复杂性。以下列表概述了一种可能的通用重构策略：
- 在 Google Cloud 上预配工件仓库。例如，您可以使用 Artifact Registry 存储工件和构建依赖项。
- 重构构建流程，以便在来源环境和 Artifact Registry 中存储工件。
- 重构部署流程，以便在目标 Google Cloud 环境中部署工作负载。例如，您可以先使用存储在 Artifact Registry 中的工件，在 Google Cloud 中部署一小部分工作负载。然后，您可以逐步增加在 Google Cloud 中部署的工作负载数量，直到要迁移的所有工作负载都在 Google Cloud 上运行。
- 重构 build 流程，以仅将工件存储在 Artifact Registry 中。
- 如有必要，请将要部署的较低版本的工件从来源环境中的代码库迁移到 Artifact Registry。例如，您可以将容器映像复制到 Artifact Registry。
- 当您不再需要来源环境中的代码库时，请将其停用。
为方便在迁移过程中因意外问题而最终回滚，您可以在迁移到 Google Cloud 的过程中将容器映像存储在 Google Cloud 中的当前工件仓库中。最后，在停用来源环境的过程中，您可以重构容器映像构建流程，以仅将工件存储在 Google Cloud 中。
虽然这对于成功迁移可能并不重要，但您可能需要将较低版本的工件从来源环境迁移到 Google Cloud 上的工件仓库。例如，为了支持将工作负载回滚到任意时间点，您可能需要将工件的早期版本迁移到 Artifact Registry。如需了解详情，请参阅从第三方注册表迁移映像。
如果您使用 Artifact Registry 存储工件，我们建议您配置控制功能来帮助保护工件仓库，例如访问权限控制、数据渗漏防范、漏洞扫描和 Binary Authorization。如需了解详情，请参阅控制访问权限和保护工件。
迁移数据
GKE 支持多种数据存储服务，例如块存储、原始块存储、文件存储和对象存储。如需了解详情，请参阅 GKE 集群存储概览。
如需将数据迁移到 GKE 环境，请执行以下操作：
- 预配和配置所有必要的存储基础架构。
- 在 GKE 集群中配置 StorageClass 预配程序。并非所有 StorageClass 预配工具都与所有环境兼容。在部署 StorageClass 预配工具之前，我们建议您评估其与 GKE 及其依赖项的兼容性。
- 配置 StorageClass。
- 配置 PersistentVolume 和 PersistentVolumeClaim 以存储要迁移的数据。
- 将数据从来源环境迁移到这些 PersistentVolume。此数据迁移的具体细节取决于源环境的特性。
如需将数据从来源环境迁移到 Google Cloud 环境，我们建议您按照迁移到 Google Cloud：转移大型数据集中的指导设计数据迁移方案。
将数据从 EKS 迁移到 GKE
AWS 为 Amazon EKS 提供了多种数据存储选项。本文档重点介绍以下数据迁移场景：
- 将数据从 Amazon EBS 卷迁移到 GKE
PersistentVolume资源。 - 将数据从 Amazon EBS 卷复制到 Amazon S3 或 Cloud Storage，然后将数据迁移到 GKE
PersistentVolume资源。
将数据从 Amazon EBS 卷迁移到 GKE PersistentVolume
您可以使用以下任一方法将数据从 Amazon EBS 卷迁移到 GKE PersistentVolume 资源：
- 直接将数据从 Amazon EBS 卷复制到 Compute Engine 永久性磁盘：
- 预配 Amazon EC2 实例，并附加包含要迁移的数据的 Amazon EBS 卷。
- 为 Compute Engine 实例预配具有足够容量的空永久性磁盘来存储要迁移的数据。
- 运行数据同步工具（例如 rsync），将数据从 Amazon EBS 卷复制到 Compute Engine 永久性磁盘。
- 从 Compute Engine 实例中分离永久性磁盘。
- 停用 Compute Engine 实例。
- 将永久性磁盘配置为 GKE
PersistentVolume资源。
- 将 Amazon EC2 实例和 Amazon EBS 卷迁移到 Compute Engine：
- 预配 Amazon EC2 实例，并附加包含要迁移的数据的 Amazon EBS 卷。
- 使用 Migrate for Virtual Machines 将 Amazon EC2 实例和 Amazon EBS 卷迁移到 Compute Engine。
- 从 Compute Engine 实例中分离永久性磁盘。
- 停用 Compute Engine 实例。
- 将永久性磁盘配置为 GKE
PersistentVolume资源。
如需详细了解如何将 Amazon EC2 实例迁移到 Compute Engine，请参阅从 AWS 迁移到 Google Cloud：从 Amazon EC2 迁移到 Compute Engine。
如需详细了解如何将 Compute Engine 永久性磁盘用作 GKE PersistentVolume 资源，请参阅将已有的永久性磁盘用作 PersistentVolume。
将数据从 Amazon EBS 卷复制到临时介质，然后迁移到 GKE PersistentVolume
除了从 Amazon EBS 卷直接迁移到 GKE PersistentVolume 资源之外，您还可以使用临时介质（例如对象存储）：
- 将数据从 Amazon EBS 卷上传到临时介质，例如 Amazon S3 存储桶或 Cloud Storage 存储桶。
- 将数据从临时介质下载到您的 GKE
PersistentVolume资源。
在某些情况下，使用多个介质可以根据您的网络和安全配置简化数据转移。例如，您可以先将数据上传到 S3 存储桶，然后将其从 S3 存储桶复制到 Cloud Storage 存储桶，最后将数据下载到永久性卷。无论您选择哪种方法，为了确保在注意重要事项的同时顺利完成转换，我们都建议您查看从 AWS 迁移到 Google Cloud：从 Amazon S3 迁移到 Cloud Storage。
选择迁移方式
最合适您的迁移选项取决于您的特定需求和要求，例如以下注意事项：
- 您需要迁移的数据量。
- 如果您要迁移的数据量较小（例如几个数据文件），不妨考虑使用 rsync 等工具将数据直接复制到 Compute Engine 永久性磁盘。此选项相对较快，但可能不适合迁移大量数据。
- 如果您要迁移大量数据，请考虑使用 Migrate to Virtual Machines 将数据迁移到 Compute Engine。此选项比直接复制数据复杂，但它更可靠且更具可伸缩性。
- 您需要迁移的数据类型。
- 源环境与目标环境之间的网络连接。
- 如果您无法在 AWS EC2 和 Compute Engine 实例之间建立直接网络连接，则建议您考虑使用 Amazon S3 或 Cloud Storage 在将数据迁移到 Compute Engine 时临时存储数据。此选项的费用可能较低，因为您无需同时保持 EC2 和 Compute Engine 实例运行。
- 迁移时间轴。
- 如果您的网络带宽有限或数据量较大，并且您的时间轴不严格，则还可以考虑使用 Transfer Appliance 将数据从 AWS 迁移到 Google Cloud。
无论您选择哪个选项，都请务必先测试迁移，然后再使其生效。测试可帮助您找出任何潜在问题，并确保迁移成功。
部署工作负载
部署流程准备就绪后，您可以将工作负载部署到 GKE。如需了解详情，请参阅部署工作负载概览。
如需准备要为 GKE 部署的工作负载，建议您分析 Kubernetes 描述符，因为 GKE 自动为您预配的一些 Google Cloud 资源可使用 Kubernetes 标签和注解进行配置，而不必手动预配这些资源。例如，您可以通过向 LoadBalancer Service 添加注解来预配一个内部负载均衡器（而不是外部负载均衡器）。
验证工作负载
在 GKE 环境中部署工作负载后，但在向用户公开这些工作负载之前，我们建议您执行全面的验证和测试。此测试可帮助您验证工作负载是否按预期运行。例如，您可以：
- 执行集成测试、负载测试、合规性测试、可靠性测试以及其他验证过程，以帮助您确保工作负载在其预期的参数范围内根据其规范运行。
- 在 Google Cloud Observability 中检查日志、指标和错误报告，以找出任何潜在问题并发现趋势，从而在问题发生之前预测问题。
如需详细了解工作负载验证，请参阅测试可靠性。
公开您的工作负载
完成在 GKE 环境中运行的工作负载的验证测试后，请公开工作负载以使其可供访问。
如需公开在 GKE 环境中运行的工作负载，您可以使用 Kubernetes Service 和服务网格。
如需详细了解如何公开在 GKE 中运行的工作负载，请参阅：
将迁移转移到 Google Cloud 环境
验证工作负载是否在 GKE 环境中运行后，并将其公开给客户端后，您可以将流量从来源环境迁移到 GKE 环境。为了帮助您避免大规模迁移和所有相关风险，我们建议您逐步将流量从来源环境迁移到 GKE。
根据您设计 GKE 环境的方式，您可以通过多种方式来实现负载均衡机制，以逐步将流量从来源环境迁移到目标环境。例如，您可以实现 DNS 解析政策，以根据某个政策解析 DNS 记录，从而将一定比例的请求发送到属于您的 GKE 环境的 IP 地址。或者，您可以使用虚拟 IP 地址和网络负载均衡器来实现负载均衡机制。
开始逐步将流量迁移到 GKE 环境后，我们建议您监控工作负载在负载增加时的行为。
最后，执行割接，即在将所有流量从来源环境迁移到 GKE 环境时发生。
如需详细了解负载均衡，请参阅前端负载均衡。
停用来源环境
GKE 环境中的工作负载正确响应请求后，您需要停用来源环境。
在开始停用来源环境中的资源之前，我们建议您执行以下操作：
- 备份所有数据，以帮助您恢复来源环境中的资源。
- 在停用环境之前，请通知您的用户。
如需停用来源环境，请执行以下操作：
- 停用在来源环境中的集群内运行的工作负载。
- 删除来源环境中的集群。
- 删除与这些集群关联的资源，例如安全组、负载均衡器和虚拟网络。
为避免遗留孤立资源，您停用来源环境中的资源的顺序很重要。例如，某些提供商要求您先停用创建负载均衡器的 Kubernetes Service，然后才能停用包含这些负载均衡器的虚拟网络。
优化您的 Google Cloud 环境
优化是迁移的最后一个阶段。在此阶段中，您将对优化任务进行迭代，直到目标环境满足您的优化要求。每个迭代的步骤如下：
- 评估您的当前环境、团队和优化循环。
- 确定优化要求和目标。
- 优化您的环境和团队。
- 调整优化循环。
重复执行这个任务序列，直到达到您的优化目标。
如需详细了解如何优化 Google Cloud 环境，请参阅迁移到 Google Cloud：优化您的环境和 Google Cloud 架构框架：性能优化。
以下部分整合了“迁移到 Google Cloud：优化您的环境”中的注意事项。
确定优化要求
优化要求可帮助您缩小当前优化迭代的范围。如需详细了解优化要求和目标，请参阅确定优化要求和目标。
如需确定针对 GKE 环境的优化要求，请先考虑以下几个方面：
- 安全、隐私和合规性：帮助您增强 GKE 环境的安全状况。
- 可靠性：帮助您提高 GKE 环境的可用性、可扩缩性和弹性。
- 费用优化：帮助您优化 GKE 环境的资源消耗和产生的支出。
- 运营效率：帮助您高效地维护和运营 GKE 环境。
- 性能优化：帮助您优化在 GKE 环境中部署的工作负载的性能。
安全性、隐私权和合规性
- 监控 GKE 集群的安全状况。您可以使用安全状况信息中心获取切实可行的建议，以帮助您改善 GKE 环境的安全状况。
- 强化您的 GKE 环境安全。了解 GKE 安全模型以及如何强化 GKE 集群的安全性。
- 保护您的软件供应链。对于安全关键型工作负载，Google Cloud 提供了一组模块化产品，可在整个软件生命周期中实现软件供应链安全最佳实践。
可靠性
- 提高集群的可靠性。为了帮助您设计一个可以更好地应对不太可能发生的可用区级服务中断的 GKE，请优先使用区域级集群，而不是可用区级集群或多个可用区级集群。
- 工作负载备份和恢复。使用 Backup for GKE 配置工作负载备份和恢复工作流。
费用优化
如需详细了解如何优化 GKE 环境的费用，请参阅：
运营效率
为了帮助避免会影响生产环境的问题，建议您：
- 将 GKE 集群设计为可换用。通过将集群视为可换用，并自动执行其预配和配置，您可以简化和泛化运维流程来对其进行维护，同时可简化未来的迁移和 GKE 集群升级。例如，如果您需要将可换用的 GKE 集群升级到新的 GKE 版本，则可以自动预配和配置升级后的新集群，并在新集群中自动部署工作负载，然后停用已过时的旧 GKE 集群。
- 监控所需的指标。确保正确收集有关工作负载和集群的所有相关指标。此外，请验证使用这些指标作为输入的所有相关提醒是否都已到位且正常运行。
如需详细了解如何在 GKE 环境中配置监控、日志记录和性能剖析，请参阅：
性能优化
- 设置集群自动扩缩和节点自动预配功能。使用集群自动扩缩和节点自动预配功能，根据需求自动调整 GKE 集群的大小。
- 自动扩缩工作负载。GKE 支持多种扩缩机制，例如：
- 根据指标自动扩缩工作负载。
- 通过配置 Pod 横向自动扩缩，通过更改 Kubernetes 工作负载的 Pod 数量来自动扩缩工作负载。
- 通过配置 Pod 纵向自动扩缩来调整资源请求和限制，以自动扩缩工作负载。
如需了解详情，请参阅 GKE 可扩缩性简介。
后续步骤
- 了解其他 AWS 到 Google Cloud 的迁移过程。
- 了解如何将 AWS 和 Azure 服务与 Google Cloud 进行比较。
- 了解何时寻求迁移帮助。
- 如需查看更多参考架构、图表和最佳实践，请浏览 Cloud 架构中心。
贡献者
作者：
- Marco Ferrari | 云解决方案架构师
- Xiang Shen | 解决方案架构师