将容器迁移到 Google Cloud：从 OpenShift 迁移到 GKE Enterprise

本文档旨在帮助您规划、设计和实现从 OpenShift 到 GKE Enterprise 的迁移。如果操作不当，那么将工作负载从一个环境迁移到另一个环境可能会遭遇挑战，因此请谨慎规划和执行迁移。

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

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

如果您计划从在本地、私有托管环境或其他云服务商服务中运行的 OpenShift 迁移到 GKE Enterprise，本文档会非常有用。如果您正在评估迁移的时机并希望了解潜在的情况，本文档也可以提供帮助。目标环境可以是以下任意一种：

  • 完全在 Google Cloud 上的托管环境。
  • 混合环境，这种情况下，您将部分工作负载保留在本地或私有托管环境中，将其余工作负载迁移到 Google Cloud。

如需确定哪种环境符合您的需求，请先明确您的要求。例如，您可以通过迁移到公有云环境并将部分责任分包给 Google，专注于提高业务价值，而不是担心基础架构。您可以受益于弹性使用模式，从而优化支出和资源使用情况。如果您有任何要求，比如必须将某些工作负载保留在 Google Cloud 之外，则可能需要考虑使用混合环境，例如，如果您需要将部分工作负载保留在当前环境中，以符合数据位置政策和法规。或者，您可以实施改进并迁移迁移策略，即先原地对工作负载进行现代化改造，然后再迁移到 Google Cloud。

无论您的目标环境是哪种类型，此迁移的目标都是使用 GKE Enterprise 管理在该环境中运行的工作负载。通过采用 GKE Enterprise，您可以使用一系列服务，其中包括：

  • 多集群管理，可帮助您和您的组织从一个位置集中管理整个云端和本地环境中的集群、基础架构和工作负载。
  • Config Sync 和 Policy Controller，可在所有基础设施中创建通用配置和政策，并将其同时应用于本地和云端。
  • Anthos Service Mesh：可采用全托管式服务网格，从而简化运营服务、流量管理、遥测操作以及保护服务之间的通信。
  • Binary Authorization，可帮助确保您在环境中部署的容器受到信任。
  • Cloud Run for Anthos，可为 GKE Enterprise 环境中的无服务器工作负载提供支持。

我们建议您在迁移过程中尽早评估这些服务，还在进行迁移设计时就要进行评估。现在，您可以更轻松地采用这些服务，无需稍后修改您的流程和基础架构。您可以立即开始使用这些服务，也可以在准备好对工作负载进行现代化改造时使用。

在此迁移中，您将按照迁移到 Google Cloud：使用入门中定义的迁移框架进行操作。 该框架包含四个阶段：

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

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

迁移路径包含四个阶段。

本文档涉及将容器迁移到 Google Cloud：将 Kubernetes 迁移到 GKE中介绍的概念，因此会适时提供跳转到该文档的链接。

评估和发现工作负载

在评估阶段，您需要确定将工作负载从 OpenShift 迁移到 GKE Enterprise 的要求和依赖项：

  1. 构建流程和应用的完整清单。
  2. 根据流程和应用的属性和依赖项为其编制目录。
  3. 为您的团队开展 Google Cloud 培训和指导
  4. 在 Google Cloud 上构建实验和概念验证。
  5. 计算目标环境的总拥有成本 (TCO)。
  6. 选择您首先要迁移的工作负载。

以下部分依赖迁移到 Google Cloud：评估和发现工作负载，但提供了专门的信息供您用于评估要从 OpenShift 迁移到 GKE Enterprise 的工作负载。

构建您的清单

如需构建环境组件的清单，请考虑以下事项：

  • 服务交付和平台管理模式
  • OpenShift 项目
  • 构建和部署流程
  • 工作负载、要求和依赖项
  • OpenShift 集群配置

服务交付和平台管理模式

如需将工作负载从 OpenShift 迁移到 GKE Enterprise，请评估 OpenShift 环境的当前服务交付和平台管理模式。此模式可能反映了您当前的组织结构和需求。如果发现当前模式无法满足组织需求，您可以借助此次迁移改进此模式。

首先，您需要收集以下几个方面负责团队的信息：

  • 应用开发和部署，包括所有 OpenShift 用户，通常是开发或工作负载发布团队。
  • OpenShift 平台管理，包括创建 OpenShift 项目，向用户分配角色，配置安全上下文以及配置 CI/CD 流水线。
  • OpenShift 安装和集群管理，包括 OpenShift 安装、升级、集群扩缩和容量管理。
  • 基础架构管理。这些团队管理物理服务器、存储空间、网络、虚拟化平台和操作系统。

服务交付和平台管理模式可以由以下团队组成：

  • 开发团队。此团队负责开发工作负载并将它们部署到 OpenShift 上。处理复杂的生产环境时，部署工作负载的团队可能与开发团队不同。 方便起见，在本文档中，我们将这个团队视为开发团队的成员。在自助环境中，开发团队还负责创建 OpenShift 项目。
  • 平台团队。此团队负责 OpenShift 平台管理，通常称为 OpenShift 集群管理员。该团队为不同的开发团队配置 OpenShift 项目模板，并在更多代管环境中创建 OpenShift 项目。该团队还分配角色和权限，配置安全上下文和基于角色的访问控制 (RBAC)，定义计算资源和对象的配额，以及定义构建和部署策略。他们有时被称为“DevOps 团队”或“中间件团队”（如果他们为开发者管理中间件和应用服务器配置的话）。平台团队和基础架构团队可能亦参与低级别的 OpenShift 集群管理活动，例如软件安装和升级、集群扩缩以及容量管理。
  • 基础架构团队。该团队负责管理支持 OpenShift 环境的底层基础架构。例如，他们负责服务器、存储空间、网络、虚拟化平台和基本操作系统。此团队有时称为“数据中心团队”或“运营团队”。如果 OpenShift 部署在公有云环境中，则此团队负责公有云服务商提供的基础架构即服务 (IaaS) 服务。

此外，请务必评估您是否针对不同的环境采用专用 OpenShift 集群。例如，您可能采用不同的环境进行开发、质保和生产，或者采用不同的环境来分隔不同的网络和安全区域，例如分隔内部区域和非军事区域。

OpenShift 项目

OpenShift 项目是一个 Kubernetes 命名空间，具有额外的注释，可让开发者独立于其他团队管理资源，从而以逻辑方式分隔资源。如需构建 OpenShift 项目的清单，请针对每个项目考虑以下方面：

  • 集群角色和本地角色。 OpenShift 支持 OpenShift 项目的本地角色或集群范围角色。您需要评估自己是否创建了集群和本地角色，用于在目标环境中设计有效的访问权限控制机制。
  • 集群角色和本地角色的角色绑定。 通过向用户和群组分配角色绑定，向他们授予对 OpenShift 项目执行操作的权限。角色可以处于集群级层或本地级层。通常而言，本地角色绑定会绑定到预定义的集群角色。 例如，默认的 OpenShift 项目管理员角色绑定可能会绑定到默认集群管理员角色。
  • 资源配额。为了限制总资源的消耗，OpenShift 可让您同时定义 OpenShift 项目级配额和多个 OpenShift 项目的配额。 您需要评估它们与 Kubernetes 资源配额的对应情况，并填充您在 OpenShift 环境中预配和配置的所有资源配额的列表。

评估环境介绍如何评估 Kubernetes 资源（例如 ServiceAccounts 和 PersistentVolume）。

构建和部署流程

收集服务交付和平台管理模式以及 OpenShift 项目的信息后，您可以评估如何构建工作负载并将其部署到您的环境中。

在现有 OpenShift 环境中，您可能针对所有工作负载具有相同的构建和部署流程，也有可能需要评估不同的流程。容器映像是容器化工作负载构建流程的工件。在 OpenShift 环境中，您可能会构建容器映像，存储它们并以不同方式部署它们：

构建每个容器映像后，您可以将其存储在稍后可以部署的 Container Registry 中。您的 Container Registry 可以托管在 OpenShift 上，也可以托管在 OpenShift 环境之外。 请进行此方面的评估，因为您可能需要在目标环境中使用类似的系统。

工作负载、要求和依赖项

每个 OpenShift 应用都包含以下组件：

根据应用的用途，您可以使用不同的对象来定义应用，而不是使用 Deployment 或 DeploymentConfig 对象：

  • 使用 Job 或Cron 作业定义批量应用。
  • 使用 StatefulSet 定义有状态应用。
  • 如果您有需要在每个节点上运行或与特定节点绑定的操作相关工作负载，则可以使用 DaemonSet 对它们进行定义。

下表列出了您为了将应用迁移到目标 GKE Enterprise 环境而从 OpenShift 资源收集的最重要的规范和参数。

来源 OpenShift 资源清单 最重要的规范和参数
Deployment、DeploymentConfig、StatementSet、Job、Cron 作业 容器映像和代码库、容器端口、Pod 副本数、ConfigMap、Secret、PersistentVolumeClaim、资源请求和限制、更新策略、StatefulSet 服务名称、Cron 作业时间表
ImageStream 容器映像、映像拉取政策、容器映像存储库
水平 Pod 自动扩缩器 自动扩缩条件
Service 用于从集群内部连接到应用的主机名、IP 地址和公开服务的端口、为外部资源创建的端点
Route 用于从集群外部连接到应用的主机名和资源路径、路由规则、加密、证书链信息

评估环境介绍如何评估 Kubernetes 资源，例如以下资源：

OpenShift 4 引入了 Operator Framework。 如果您使用的是此 OpenShift 版本，则可能已使用安装的 Operator 部署了一些应用。 在这种情况下，您将获取已安装 Operator 的列表，并为每个 Operator 收集有关已部署 Operator 实例的信息。这些实例是 Operator 定义的自定义资源，用于部署之前列出的一些 Kubernetes 资源。

除了评估这些资源之外，您还需要评估以下内容：

  • 应用的网络连接要求。例如，您的 Service 或 Pod 是否需要公开给特定网络？它们是否需要访问特定的后端系统？
  • 需要在特定位置运行工作负载的限制条件比如，为了符合某些要求，例如与其他工作负载通信的延迟时间要求，与数据位置相关的政策要求，以及与用户之间的距离要求，是否有需要保留在本地的工作负载或数据集？

OpenShift 集群配置

接下来，您需要评估 OpenShift 集群。为了完成此任务，请收集以下信息：

  • OpenShift 版本。本文档中的 OpenShift 主要版本是 OpenShift 3 和 OpenShift 4。不同的 OpenShift 版本可能具有不同的功能。您可以评估自己正在运行的是哪个版本的 OpenShift，以便了解您是否使用的有任何 OpenShift 版本特有的特性。
  • 用于身份验证的身份提供商。身份验证方面，您可能使用的是内置 OAuth 服务器以及一个或多个身份提供商。
  • 安全上下文限制。评估您在集群中定义的 OpenShift 安全上下文限制，其配置以及将其分配给的用户、群组和服务账号。
  • 网络政策和隔离。评估网络政策，配置 Pod 网络隔离的方式以及您在集群中配置的 OpenShift SDN 模式。

  • 监控。评估当前的监控要求以及预配和配置当前监控系统的方法，以确定如何在目标环境中设计和实现监控解决方案。此评估可以帮助您确定是使用新的监控解决方案，还是可以继续使用现有解决方案。许多 OpenShift 版本都包含一个基于 Prometheus 的监控堆栈，用于监控系统组件，也可用于监控应用。设计目标解决方案时，请考虑以下事项：

    • 您目前在 OpenShift 环境中使用的监控解决方案，例如由 OpenShift 托管的 Prometheus、独立的 Prometheus - Grafana 堆栈、Zabbix、InfluxData 或者 Nagios。
    • 如何生成和收集指标，例如拉取或推送机制。
    • OpenShift 集群中部署的任何组件的依赖项。
    • 您的监控系统的位置，例如部署在云环境中还是本地。
    • 您当前为工作负载收集的指标。
    • 您在当前的监控系统中针对指标配置的任何提醒。

  • 日志记录。评估当前的日志记录要求以及预配和配置当前日志记录系统的方法，以确定如何在目标环境中设计和实现日志记录解决方案。此评估可以帮助您确定是使用新的日志记录解决方案，还是可以继续使用现有解决方案。许多 OpenShift 版本都附带基于 Elasticsearch、Fluentd 和 Kibana (EFK) 堆栈的日志记录解决方案，用于从系统组件收集日志。此解决方案还可用于应用日志记录。设计目标解决方案时，请考虑以下事项：

    • 您当前在 OpenShift 环境中使用的日志记录系统，例如 OpenShift 托管的 EFK 堆栈，独立的 EFK 堆栈还是 Splunk。
    • OpenShift 集群中部署的任何组件的依赖项。
    • 日志存储组件的架构和容量。
    • 您的日志记录系统的位置，例如部署在云环境中还是本地。
    • 日志保留政策和配置。

评估环境介绍如何评估以下内容：

  • 集群数量
  • 每个集群的节点数量和类型
  • 关于日志记录、监控和跟踪的其他注意事项
  • 自定义 Kubernetes 资源

完成评估

构建与 OpenShift 流程和工作负载相关的清单后，请完成迁移到 Google Cloud：评估和发现工作负载中所述评估阶段的其余活动。

规划和构建基础

在规划和构建阶段，您需要预配和配置支持您的工作负载的基础架构和服务：

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

本部分提供的信息专用于在 GKE Enterprise 上构建基础，这些信息基于迁移到 Google Cloud：构建您的基础中所述内容。

在 Google Cloud 中构建基础之前，请阅读 GKE Enterprise 技术概览，了解 GKE Enterprise 的工作原理以及您可能需要哪些 GKE Enterprise 组件。根据您在评估阶段中收集的工作负载和数据局部性要求，您可以按如下所示部署工作负载 GKE On VMware、Google Cloud 上的 GKE 集群或 GKE on AWS。您的集群可能分布在不同的环境中。如需详细了解如何为 Google Cloud 上的 GKE 构建基础，请参阅规划和构建基础。

如需为 GKE On VMware 构建基础，请了解其核心概念，然后在安装 GKE On VMware 时考虑以下事项：

如需为 GKE on AWS 构建基础，请了解其核心概念，例如 GKE on AWS 架构和 GKE on AWS 存储空间。安装 GKE on AWS 时，请考虑以下事项：

部署您的工作负载

在部署阶段，您将工作负载部署到 GKE Enterprise 上：

  1. 预配和配置您的运行时平台和环境。
  2. 将数据从旧环境迁移到新环境。
  3. 部署工作负载。

以下部分提供的信息专用于将工作负载部署到 GKE Enterprise 上，这些信息基于迁移到 Google Cloud：传输大型数据集、迁移到 Google Cloud：部署工作负载以及迁移到 Google Cloud：从手动部署迁移到自动化容器化部署中所述内容。

预配和配置您的运行时平台和环境

在部署任何工作负载之前，请先预配和配置必要的 GKE Enterprise 集群。

您可以预配 Google Cloud 上的 GKE 集群，也可以预配 GKE On VMware 集群，还可以预配 GKE on AWS 集群。举例来说，如果您具有必须在本地部署的工作负载，则可以预配一个或多个 GKE On VMware 集群。如果您的工作负载没有任何位置要求，您可以预配 Google Cloud 上的 GKE 集群。在以上两种情况下，您都可以使用 GKE Enterprise 管理和监控集群。如有任何多云要求，则您可以预配 GKE on AWS 集群以及其他 GKE Enterprise 集群。

首先，您定义所需的 GKE Enterprise 集群数量和类型。这些方面的要求主要取决于您在评估阶段收集的信息，例如您要实现的服务模式以及您希望如何隔离不同的环境。如果目前多个开发团队共享 OpenShift 集群，则您必须在 GKE Enterprise 上实现多租户模式：

  • 使用不同的 Kubernetes 命名空间。平台团队为每个 OpenShift 项目创建一个 Kubernetes 命名空间，并实现集群多租户模式。 此模式与您在 OpenShift 环境中可能采用的模式非常相似，因此需要的 GKE Enterprise 集群数量可能与 OpenShift 集群数量类似。如果需要，您仍然可以为不同的环境创建专用集群。
  • 使用不同的 GKE Enterprise 集群。基础架构团队为每个开发团队提供一个 GKE Enterprise 集群，这些集群全部由平台团队进行管理。此模式需要的 GKE Enterprise 集群数量可能多于 OpenShift 集群数量，因为它为您的开发提供更大的灵活性和隔离。
  • 使用不同的 Google Cloud 项目。基础架构团队为每个开发团队创建一个 Google Cloud 项目，并在该 Google Cloud 项目中预配 GKE Enterprise 集群。然后由平台团队管理这些集群。此模型需要的 Open Enterprise 集群数量可能多于 OpenShift 集群数量，因为它为您的开发团队提供最大的灵活性和隔离。

确定所需的集群数量以及在哪些环境中预配这些集群后，请定义集群大小、配置和节点类型。然后，根据您在评估阶段收集的工作负载要求，预配集群和节点池。举例来说，您的工作负载可能需要某些性能和可伸缩性保证以及其他一些要求，例如需要 GPU 和 TPU。

如需详细了解如何预配和配置集群，请参阅以下内容：

创建集群后，在部署工作负载之前，请配置以下组件，以满足您在 OpenShift 项目和集群评估阶段收集的要求：

使用 Config Sync，您可以在符合 Git 标准的通用代码库中集中定义以下资源的配置，并将该配置同时应用于本地和云端的所有集群：

如需安装 Config Sync，请参阅安装 Config Sync。如需安装 Policy Controller，请参阅安装 Policy Controller。

从旧环境中迁移数据

现在，您可以将数据从来源环境迁移到目标环境。

如果您的 OpenShift 有状态应用在 Kubernetes 永久性卷上托管数据，则可以使用不同的策略将数据迁移到目标环境。 选择哪种策略合适取决于各种因素，例如您的来源和目标后端存储提供商以及部署位置：

  • 依赖于存储提供商的卷克隆、导出和导入功能。如果您正在本地环境中使用 VMware vSphere 卷，并且要迁移到 GKE On VMware，请克隆 PersistentVolume 底层 VMDK 虚拟磁盘，并将其装载为目标环境中的卷。如果要迁移到 GKE，请将虚拟磁盘作为 Compute Engine Persistent Disk 导入，然后将其用作永久性卷。
  • 使用操作系统工具或数据库工具备份来源环境中的数据。将数据托管在可从这两种环境访问的临时位置，然后在目标环境中恢复数据。
  • 使用远程复制工具（例如 rsync）将数据从来源环境复制到目标环境。
  • 使用独立于存储的备份解决方案，例如带有 restic 集成的 Velero。

如需了解详情，请参阅迁移到 Google Cloud：传输大型数据集。

如需详细了解如何迁移数据以及在 GKE 中管理存储的策略，请参阅将数据从旧环境迁移到新环境以及关于存储配置的 GKE 文档。

借助 GKE On VMware，您可以选择与外部存储系统集成的不同方案，例如通过 VMware vSphere 存储、Kubernetes 树内卷插件和容器存储接口 (CSI) 驱动程序。选择哪种方案取决于您需要集成的外部存储系统、支持的访问模式以及是否需要动态卷预配。

GKE on AWS 会自动部署适用于 Amazon Elastic Block Store (EBS) 的 CSI 驱动程序、通过 EBS 卷支持 PersistentVolumeClaim 的默认 StorageClass和适用于其他 EBS 卷类型的 StorageClass。您还可以安装其他 CSI 驱动程序和自定义 StorageClass。 如果您想要在 GKE on AWS 中导入 EBS 卷，则可以通过它创建 PersistentVolume。

部署工作负载

预配 GKE Enterprise 集群并迁移数据后，您现在可以构建和部署工作负载了。您可以选择不同的方案，从手动部署到完全自动化方案均可。

如果您需要使用 Operator 来部署在您的 OpenShift 环境中使用此部署方法的工作负载，则需要在部署工作负载之前安装该 Operator。您可以通过以下来源验证所需 Operator 的可用性：

手动部署

如果要在 OpenShift 环境中手动部署工作负载，您可以根据新的 GKE Enterprise 环境调整此手动部署流程。例如，您可以将在工作负载、要求和依赖项中评估的 OpenShift 资源清单手动转换为相应的 GKE Enterprise 资源清单。

下表是本文档工作负载、要求和依赖项部分中表格的扩展，添加了您可以在其中使用它们的目标 GKE Enterprise 资源的相关信息。

来源 OpenShift 资源清单 最重要的规范和参数 目标 GKE Enterprise 资源清单
Deployment、DeploymentConfig、StatementSet、Job、Cron 作业 容器映像和存储库、容器端口、Pod 副本数、ConfigMap、Secret、PersistentVolumeClaim、资源请求和限制、更新策略、StatefulSet 服务名称、Cron 作业时间表 Deployment、StatefulSet、Job、Cron 作业
ImageStream 容器映像、映像拉取政策、容器映像存储库 Deployment
Pod 横向自动扩缩器 自动扩缩条件 Pod 横向自动扩缩器
Service 用于从集群内部连接到应用的主机名、IP 地址和公开服务的端口、为外部资源创建的端点 Service
Route 用于从集群外部连接到应用的主机名和资源路径、路由规则 Ingress

设计和实现自动部署流程

如需自动构建和部署工作负载，请设计和实现构建和部署流程，或调整现有流程以支持新环境。如果您需要在混合环境中部署工作负载，则部署流程必须同时支持 GKE on Google Cloud 和 GKE On VMware。

如需实现构建和部署流程，您可以使用 Cloud Build。 如果要自动执行构建和部署流程，您可以配置构建触发器或 GitHub 应用触发器，或者通过 Google Cloud 控制台设置自动部署。如果您使用任何政策控制器限制条件，则可以对照 Cloud Build 作业中的政策检查 Kubernetes 和 GKE Enterprise 描述符，以便向开发者提供反馈。

如果您需要在本地运行构建作业或存储源代码，则可以使用 GitLab。 GitLab 提供源代码库、协作平台、CI/CD 功能以及容器映像注册表。您可以直接通过 Cloud Marketplace 在 GKE Enterprise 集群上部署 GitLab，也可以使用其他可用的安装选项。

如果您目前使用其中一项 OpenShift 设施构建或自动部署工作负载，则可以根据当前流程采用以下策略之一：

  • Jenkins 流水线。如果您使用 Jenkins 流水线自动执行构建和部署流程，则可以将流水线迁移到 Cloud Build，使用现有的 Jenkins 环境或在 Google Cloud 中部署 Jenkins。
  • 从 Dockerfile 进行的构建和部署以及所需的工件。 您可以通过 Dockerfile 或构建配置文件使用 Cloud Build 构建容器映像。 如果要在本地集群上执行构建，则可以使用 GitLab。
  • 源代码转映像构建。在 Cloud Build 中，您必须执行一个初步步骤，以构建生成的容器映像所需的工件。如果您的源代码转映像作业构建 Python 应用并生成容器映像，则您需要配置自定义构建步骤来构建 Python 应用，然后再构建容器映像。 此方法还要求您提供 Dockerfile；如果您不想提供 Dockerfile，则可以使用 Google Cloud 的 Buildpack 或 Jib 构建 Java 应用。
  • 自定义构建。您可以像现在一样在 OpenShift 中创建自定义 Cloud Build 构建器。如果您的自定义构建器未使用任何 OpenShift 特有特性，您可能能够像在 Cloud Build 中一样使用它们。

无论选择哪种方法构建容器映像，您都需要将其存储在容器映像存储库中。您有以下几种选择：

无论您选择如何存储容器映像，都需要为集群预配和配置凭据以访问容器映像存储库。

如果您需要向用户或第三方服务发送有关构建状态和容器映像的通知，则可以使用 Cloud Functions 响应 Cloud Build 和 Container Registry 生成的事件。

OpenShift 与 GKE Enterprise 功能对应情况汇总表

下表总结了 GKE Enterprise 功能与您在 OpenShift 上所用功能的对应情况。

OpenShift GKE Enterprise
OpenShift 项目
  • 由 Config Sync 集中管理的 Kubernetes 命名空间
  • 由 Config Sync 集中管理的 Kubernetes RBAC 授权
  • 由 Config Sync 集中管理的 Kubernetes 资源配额
OpenShift SDN 和网络隔离
  • 由 Config Sync 集中管理的 Calico 网络安全政策
OpenShift 安全上下文限制
  • Policy Controller 限制条件
OpenShift 流水线
  • Cloud Build
  • 使用 Google Cloud Jenkins 插件的 Jenkins 集成
  • GitLab
OpenShift 源代码转映像
  • Cloud Native Buildpacks
  • Jib
身份集成
  • Cloud Identity
  • Google Cloud Directory Sync
  • GKE on VMware OIDC 集成

优化您的环境

优化是迁移的最后一个阶段。在此阶段，您将使环境比以前更高效，同时，您将对可重复的循环执行多次迭代，直到您的环境满足优化要求。这种可重复的循环步骤如下：

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

以下部分依赖于《迁移到 Google Cloud：优化您的环境》。

评估您的当前环境、团队和优化循环

虽然首次评估侧重于从您的环境到 GKE Enterprise 的迁移，但这里的评估则是针对优化阶段的。

确定优化要求

关于 GKE on Google Cloud 优化要求，请查看在优化环境中制定的优化要求。

查看针对 GKE Enterprise 环境的以下优化要求：

完成优化

填充优化要求列表后，请完成迁移到 Google Cloud：优化您的环境中所述优化阶段的其余活动。

寻求帮助

Google Cloud 提供了各种选项和资源，方便您获取必要的帮助和支持，以充分利用 Google Cloud 服务：

  • 自助资源。如果您不需要专属支持，则可以按照自己的进度使用各种选项。
  • 技术合作伙伴。 Google Cloud 已与多家公司达成合作，便于您使用 Google Cloud 产品和服务。
  • Google Cloud 专业服务。我们的专业服务可以帮助您充分利用在 Google Cloud 中的投资。

Google Cloud Migration Center 提供了更多资源来帮助您将工作负载迁移到 Google Cloud。

如需详细了解这些资源，请参阅迁移到 Google Cloud：使用入门中的“寻求帮助”部分。

后续步骤