规划最佳做法

本主题根据已通过 Migrate to Containers 执行的实际应用迁移，提供了有关将应用迁移到 Google Kubernetes Engine (GKE) 或 GKE Enterprise 的建议。

迁移中心资产识别客户端 CLI 或 mcdc CLI 是一种工具，用于确定虚拟机工作负载是否适合迁移到容器。

建议对某些类型的 Linux 和 Windows 工作负载（详述如下）使用 Migrate to Containers。

比较契合

Linux

适合使用 Migrate to Containers 进行迁移的 Linux 应用包括以下应用架构：

  • Web/应用服务器
  • 业务逻辑中间件（例如 Tomcat）
  • 多虚拟机/多层级堆栈（例如 LAMP）
  • 中小型数据库（例如 MySQL 和 PostgreSQL）

此外，最适合使用 Migrate to Containers 进行迁移的应用还具有以下运行特征：

  • 低工作周期和突发性工作负载
  • 开发、测试和训练实验室环境
  • 时刻连通的低负载服务

通常，大多数 Linux 工作负载都与迁移服务兼容，但明确列在不适合的工作负载下方的工作负载除外。

Windows

适合使用 Migrate to Containers 进行迁移的 Windows 应用包括符合以下所有特征的工作负载：

  • IIS 7 或更高版本、使用 .NET Framework 3.5 或更高版本的 ASP.NET
  • 网络层和逻辑层
  • WS2008 R2 或更高版本

操作系统支持

Migrate to Containers 与这些虚拟机操作系统兼容。

不适合的工作负载

Linux

对于 Linux，不适合使用 Migrate to Containers 进行迁移的应用和服务器包括：

  • 高性能的大型内存数据库
  • 具有特殊内核驱动程序（例如内核模式 NFS）的虚拟机
  • 依赖于特定硬件的依赖项
  • 具备与特定硬件 ID 注册相关联的许可的软件

Windows

对于 Windows，未安装 IIS 7 或更高版本的工作负载不适合进行迁移。不适合进行迁移的其他类型的应用包括：

  • 在 GPU 或 TPU 上具有依赖项的应用
  • 低级层网络应用
  • 桌面、RDP 和 VDI 应用
  • 采用 BYOL 的应用

DNS 和网络访问规则

在迁移到 GKE 之前，请务必了解迁移后的工作负载所使用的网络资源和服务，并确保可通过 Virtual Private Cloud 对其进行访问和寻址。

规划 Kubernetes 服务名称

如果您的工作负载依赖 DNS 来访问服务，则您需要规划 Kubernetes 的命名空间方案、网络政策和服务名称。

迁移过程生成的部署规范包含一个类型为“ClusterIP”的建议无头 Service 对象。“ClusterIP”是指没有负载平衡，并且只能从集群内部访问单个集群内部 IP。Kubernetes 端点控制器将修改 DNS 配置，以返回指向 deployment_spec.yaml 中带有 "app": "app-name" 标签的 Pod 的记录（地址）。

创建并应用服务以连接到 pod 和容器

迁移工作负载后，主机名将不再适用。如需允许连接到您的工作负载，请创建并应用 Service。

识别并配置迁移后的名称和 IP

GKE 管理着 /etc/hosts 文件。在 Migrate to Containers 中，调整来源虚拟机中的主机文件以使其能够用于 GKE 的过程还不是自动进行的。在迁移后的虚拟机上，主机文件中的名称和 IP 需要识别并配置为 hostAliases。

将依赖服务放入同一个命名空间

相互依赖的服务应位于同一个 Kubernetes 命名空间，并使用 DNS 短名称（例如 app 和 db）进行通信。这种配置还有助于复制生产、预演和测试等多个应用环境。

使用 GKE 网络来控制访问界面

GKE 拥有复杂的网络控件。您可以从不同的网络（例如公共互联网、VPC 网络或内部集群网络）访问 pod。这样做有助于进一步控制和限制对工作负载的访问途径，而不会增加管理 VLAN、过滤条件或路由规则的复杂性。

例如，一个典型的三层应用具有前端层、应用层和数据库层。迁移到 Google Cloud 后，前端服务在 VPC 网络上配置了 LoadBalancer。其他层级不能直接从 GKE 集群外部访问。网络访问政策可确保应用服务只能由前端 pod 从内部集群网络进行访问。另一项政策可确保只有应用 pod 才能访问数据库 pod。

NFS

将 NFS 装载定义为永久性卷

您创建迁移计划时，系统会自动发现源虚拟机上的 NFS 客户端装载，并将其添加到生成的方案中。

将装载添加到计划中后，它们会默认处于停用状态。这表示生成迁移工件时，PersistentVolume 和 PersistentVolumeClaim 定义未包含在 deployment_spec.yaml 文件中。如果您希望 Migrate to Containers 生成 PersistentVolume 和 PersistentVolumeClaim 定义，则必须先修改迁移计划以启用 NFS 客户端装载。

如需了解详情，请参阅自定义 NFS 装载。

内核模式 NFS 服务器

以内核模式运行 NFS 服务器的虚拟机无法使用 Migrate to Containers 迁移到 GKE。这些虚拟机必须迁移到 Compute Engine 上的虚拟机中。或者，您也可以在云原生 NFS 解决方案中使用 Filestore。

从来源 NFS 共享中迁移数据

如果来源虚拟机使用的是 NFS 共享装载，则系统无法自动迁移此数据。您可以使用 NFS 永久性卷在迁移后的工作负载容器上装载共享；如果来源 NFS 共享是远程的，您也可以将数据复制到其他文件共享，以提供对集群的短延时访问。

如果您选择复制数据的方式，请参阅以下内容：

  1. Storage Transfer Service 或 Transfer Appliance。

  2. 使用 gsutil rsync 复制数据（从来源文件共享复制到存储分区，然后再从存储分区复制到云端的文件共享）。

  3. 第三方解决方案，例如从 NetApp SnapMirror 复制到 NetApp Cloud Volumes。

  4. OSS 实用程序，例如 Rsync。

确保数据库可访问

如果您的应用依赖于数据库（无论是在虚拟机上本地运行的数据库，还是在外部机器上运行的数据库），您必须确保仍然可以通过新迁移的 Pod 访问该数据库。您需要验证您的网络防火墙政策是否允许从集群访问数据库。

如需将数据库迁移到 Google Cloud，我们建议您使用 Database Migration Service

或者，您也可以在集群内运行数据库。如需了解详情，请参阅在 GKE 上规划数据库部署。

确保注入的元数据可用

如果您的应用依赖于注入的元数据（例如，环境变量），您必须确保 GKE 上提供了这些元数据。如果没有提供相同的元数据注入方法，则 GKE 会提供 ConfigMap 和 Secret。

将必要的服务配置为在运行级别 3 启动

Migrate to Containers 工作负载只能达到运行级别 3。使用 Migrate to Containers 迁移到 GKE 的虚拟机将在 Linux 运行级别 3 的容器中启动。默认情况下，某些服务（例如 X11 或 XDM，用于通过 VNC 进行远程 GUI 访问）配置为仅在运行级别 5 启动。所有必要的服务都应配置为在运行级别 3 启动。

停用不需要的服务

Migrate to Containers 会自动停用特定于硬件或环境的服务，以及在虚拟机上运行的一组预定义的其他服务。将工作负载迁移到容器后，将不再需要这些服务。

例如，Migrate to Containers 会自动停用 iptables、ip6tables 和 firewalld。如需查看 Migrate to Containers 停用的服务的完整列表，请下载 blocklist.yaml 文件。

自定义已停用的服务

默认情况下，Migrate to Containers 会停用上面列出的不需要的服务。您还可以通过自定义迁移计划来定义屏蔽名来，来自行定义在已迁移容器中停用的服务的自定义列表。使用屏蔽名单，您可以在迁移的容器中指定要停用的一个或多个服务。

维护和更新迁移后的虚拟机

使用迁移期间生成的工件，您可以采用应用和用户模式操作系统软件更新、打安全补丁、修改嵌入式配置、添加或替换文件，以及更新 Migrate to Containers 运行时软件。

如需了解详情，请参阅迁移后映像更新。

后续步骤