自定义 Linux 虚拟机的迁移计划

在执行迁移计划之前，您应该查看并选择性地自定义。迁移计划的详细信息用于从来源虚拟机中提取工作负载的容器工件，以及生成可用于将容器映像部署到其他集群（如生产集群）的 Kubernetes 部署文件。

本页面介绍迁移计划的内容以及在执行迁移和生成部署工件之前您可以考虑的自定义种类。

须知事项

本主题假设您已经创建了迁移计划并生成了迁移计划文件。

修改迁移计划

复制并分析文件系统后，您可以在指定输出路径 ANALYSIS_OUTPUT_PATH/config.yaml 中创建的新目录中找到迁移计划。

根据需要修改迁移计划，然后保存更改。

查看迁移计划的详细信息和指导性注释以根据需要添加信息。具体而言，请考虑针对以下部分的修改。

指定要从迁移中排除的内容

默认情况下，Migrate to Containers 会排除 GKE 环境中无关的典型虚拟机内容。您可以自定义该过滤条件。

filters 字段值会列出应从迁移中排除且不属于容器映像的路径。该字段的值列出了 rsync 过滤规则，这些规则指定要转移的文件以及要跳过的文件。在每个路径和文件前面加上减号可指定应从迁移中排除的列表项。系统会按照 YAML 中各行的顺序处理该列表，并相应地评估排除项/包含项。

详细了解 rsync 过滤器规则。

太大而无法包含在 Docker 映像中的文件列在 YAML 文件中。这会标记大于 1 GB 的文件供您考虑。太大或大于 15 GB 的 Docker 映像在迁移期间有失败的风险。

您可以修改 YAML 列表以添加或移除路径。请参阅下面的示例 YAML，其中包括示例排除项以及大型文件和稀疏文件的通知。按照内嵌指南执行以下操作之一：

通过取消备注检测到的文件夹并将其放在全局过滤条件部分下进行排除。
通过取消备注检测到的文件夹并将其放在数据文件夹部分下，将检测到的文件夹移至永久性卷中。

您还可以采用同样的方式排除或移动检测到的稀疏文件。

  global:
    # Files and directories to exclude from the migration, in rsync format.
    filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

    ## The data folders below are too large to be included in the docker image.
    ## Consider uncommenting and placing them under either the global filters
    ## or the data folder section.
      # - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

    ## Sparse files will fail the run of a docker image. Consider excluding the below
    ## detected files and any other sparse files by uncommenting and placing them in
    ## the global filters section, or export them to a persistent volume by specifying
    ## them in the data folder section.
      # - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

设置容器映像的名称

image 部分中的 name 字段值定义从用于容器的迁移后的虚拟机创建的映像的名称。如果您希望使用其他名称，可以更改此值。

image:
     # Review and set the name for runnable container image.
     name: linux-system

自定义服务列表

默认情况下，Migrate to Containers 会在将虚拟机迁移到容器时停用不需要的服务。这些服务有时可能会导致已迁移的容器出现问题，或者不为容器上下文所需要。

除了由 Migrate to Containers 自动停用的服务之外，您还可以选择停用其他服务：

Migrate to Containers 会自动发现您可以选择停用的服务并在迁移计划中列出这些服务。迁移后的工作负载可能不需要这些服务（例如 ssh 或网络服务器），但您需要自行做出决定。如有必要，请修改迁移计划以停用这些服务。
Migrate to Containers 不会列出来源虚拟机上运行的所有服务。例如，它省略了与操作系统相关的服务。您可以选择修改迁移计划，添加要在迁移的容器中停用的服务列表。

systemServices 字段指定由 Migrate to Containers 发现的服务列表。例如：

    systemServices:
    - enabled: true|false
      name: service-name
      probed: true|false
    - enabled: true|false
      name: service-name
      probed: true|false
      ...

如要停用服务，请将 enabled 设置为 false。

Migrate to Containers 不会列出来源虚拟机上运行的所有服务，例如与操作系统相关的服务便不会列出。您还可以向该列表添加其他服务。例如，如需停用 service2 和 cron 服务，请运行以下命令：

    systemServices:
    - enabled: true
      name: service1
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

当您执行迁移以生成迁移工件时，Migrate to Containers 会创建 blocklist.yaml 文件。此文件根据迁移计划中的设置列出了要停用的容器服务。例如：

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

以后如需修改已停用服务的列表，请执行以下操作：

修改迁移计划中的服务列表。
执行迁移以重新生成迁移工件，包括更新的 blocklist.yaml。

或者，在执行迁移以生成迁移工件后，您可以直接修改 blocklist.yaml 文件，然后使用 Skaffold 构建和部署容器映像。

自定义服务端点

迁移计划包含 endpoints 数组，用于定义用于创建迁移后工作负载提供的 Kubernetes 服务的端口和协议。您可以添加、修改或删除端点定义以自定义迁移计划。

如需检索端点端口，请检查监听端口的程序：

sudo netstat --programs --listening --tcp --udp [--sctp]

对于每个 Service 端点，请将以下定义添加到迁移计划中：

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

其中：

PORT_NUMBER 用于指定向服务发送请求的目标容器端口号。
PORT_PROTOCOL 指定端口协议，例如 HTTP、HTTPS 或 TCP。如需查看协议的完整列表，请参阅支持的协议。
PORT_NAME 指定用来访问 Service 端点的名称。Migrate to Containers 会为每个生成的端点定义生成唯一的 PORT_NAME。

例如，Migrate to Containers 会检测以下端点：

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

为了设置 name 属性的值，Migrate to Containers 会将来源虚拟机名称（本示例中为 backend-server）与 Service 的程序名称合并。生成的名称与 Kubernetes 命名惯例兼容，并在迁移计划中具有唯一性。例如，上述迁移计划会创建一个通过 HTTP 以端口 80 为目标的 Nginx 的 Service。

对于任何重复名称，Migrate to Containers 都会附加一个计数器后缀。例如，如果 Nginx 与两个端口相关联，则会将 -2 后缀到第二个定义中的 name。

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 8080
      protocol: HTTPS
      name: backend-server-nginx-2
    - port: 6379
      protocol: TCP
      name: backend-server-redis

当您执行迁移以生成迁移工件时，Migrate to Containers 会在 deployment_spec.yaml 文件中为每个端点创建一个 Service 定义。

例如，下面显示了 deployment_spec.yaml 文件中的 Service 定义：

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: backend-server-nginx
spec:
  ports:
  - port: 80
    protocol: HTTP
    targetPort: 80
  selector:
    app: backend-server
status:
  loadBalancer: {}

自定义 NFS 装载

Migrate to Containers 会在生成的迁移计划中包含 NFS 装载。此信息从 fstab 文件中收集，并写入迁移计划中的 nfsMounts 数组。您可以添加或修改 NFS 装载点定义，以自定义迁移计划。

生成迁移计划时，Migrate to Containers 会执行以下操作：

忽略 /sys 和 /dev 的 NFS 装载。
忽略类型不是 nfs 或 nfs4 的 NFS 装载。

迁移计划中的每个 NFS 装载都包括服务器的 IP 地址和本地装载路径，格式如下：

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

其中：

MOUNT_POINT 指定从 fstab 获取的装载点。
DIR_NAME 指定共享目录的名称。
IP 指定托管装载点的服务器的 IP 地址。
OPTION_N 指定从 fstab 为装载点提取的所有选项。

例如，对于 fstab 中的以下条目：

<file system>       <mount point>   <type>  <options>   <dump>  <pass>
10.49.232.26:/vol1  /mnt/test       nfs     rw,hard     0       0

Migrate to Containers 会在迁移计划中生成以下条目：

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

如需将 Migrate to Containers 配置为处理 nfsMounts 数组中的条目，请将 mountPoint 条目的 enabled 设置为 true。您可以启用一个、部分或所有 mountPoints 条目，修改条目，或者添加您自己的条目。

当您执行迁移以生成迁移工件时，Migrate to Containers 会在 deployment_spec.yaml 文件中为每个已启用的 NFS 装载创建一个 volumes 和 volumeMounts 定义以及一个 PersistentVolume 和 PersistentVolumeClaim 定义。

例如，下面显示了 deployment_spec.yaml 文件中的 volumeMounts 定义：

    spec:
      containers:
          - image: gcr.io/myimage-1/image-name
            name: some-app
            volumeMounts:
                   - mountPath: /sys/fs/cgroup
                     name: cgroups
                   - mountPath: /mnt/test
                     name: nfs-pv

其中，name 的值是由 Migrate to Containers 生成的唯一标识符。

下面显示了 deployment_spec.yaml 文件中的 PersistentVolumeClaim 和 PersistentVolume 定义示例：

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
  storageClassName: ""
  volumeName: nfs-pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  mountOptions:
    - rw
    - hard
  nfs:
    path: /vol1
    server: 10.49.232.26

自定义写入 Cloud Logging 的日志数据

通常，来源虚拟机会将信息写入一个或多个日志文件中。在迁移虚拟机的过程中，您可以配置迁移后的工作负载，以将日志信息写入 Cloud Logging。

生成迁移计划时，Migrate to Containers 会自动在来源虚拟机上搜索日志目标文件。然后，Migrate to Containers 会将检测到的文件的相关信息写入迁移计划的 logPaths 区域：

deployment:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

例如：

deployment:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

生成迁移工件时，Migrate to Containers 会从迁移计划生成 logs.yaml 文件。此文件包含在来源虚拟机上检测到的日志文件的列表。例如，在上面的 logsPath 定义中，logs.yaml 包含：

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

在此示例中，当您部署迁移后的工作负载时，写入 catalina.out 的日志信息会自动写入 Cloud Logging。

每个条目将按如下格式显示在日志的某一行中：

DATE TIME APP_NAME LOG_OUTPUT

以下示例演示了 Tomcat 条目的格式：

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

如需配置日志记录，您可以执行以下任一操作：

在生成迁移工件之前修改迁移计划，以添加、移除或修改 logPaths 条目。生成迁移工件时，这些修改会反映在 logs.yaml 文件中。
生成迁移工件后修改 logs.yaml，以添加、移除或修改 logs 条目。

修改迁移计划的优势在于，每次生成工件时，您的修改都会反映在 logs.yaml 中。如果您直接修改 logs.yaml，则在您由于某种原因而重新生成工件时，您必须将修改重新应用于 logs.yaml。

设置 Linux v2kServiceManager 健康状况探测

您可以通过在 Tomcat Web 服务器的迁移计划中指定探测来监控代管式容器的停机时间和就绪状态。健康状况探测监控有助于减少迁移后的容器的停机时间，并更好地进行监控。

未知的健康状况可能导致可用性降级、误报的可用性监控以及潜在的数据丢失。如果没有健康状况探测，kubelet 只能假设容器的健康状况并可能将流量发送到尚未就绪的容器实例。这可能会导致流量丢失。Kubelet 可能也无法检测到处于冻结状态的容器，并将不会重启容器。

健康探测通过在容器启动时运行小型脚本语句来执行。该脚本会在每个周期检查成功条件（由使用的探测类型定义）。周期由迁移计划中的 periodSeconds 字段定义。您可以手动运行或定义这些脚本。

如需详细了解 kubelet 探测，请参阅 Kubernetes 文档中的配置活跃性、就绪性和启动探测。

有两种类型的探测可供配置，两种探测都是在 probe-v1-core 参考文档中定义的 probe-v1-core，并且与 container-v1-core 的对应字段共享相同的功能

活跃性探测 - 活跃性探测用于了解何时重启容器。

注意：如果容器中的进程在出现问题或健康状况不佳时能够自行崩溃，则不一定需要活跃性探测。kubelet 会根据 Pod 的 restartPolicy 自动执行正确的操作。

就绪性探测 - 就绪性探测用于了解容器何时准备好开始接受流量。如需仅在探测成功时开始将流量发送到 Pod，请指定就绪性探测。就绪性探测的作用可能类似于活跃性探测，但规范中的就绪性探测表示 Pod 会在未收到任何流量的情况下启动，并且仅在探测成功后开始接收流量。

发现后，探测配置将添加到迁移计划中。探测可以在其默认配置中使用，如下所示。如需停用探测，请从 yaml 中移除 probes 部分。

deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - /ko-app/service-manager-runtime
        - /probe

    readinessProbe:
      exec:
        command:
        - gamma
        - /probe
      initialDelaySeconds: 60
      periodSeconds: 5

image:
  # Disable system services that do not need to be executed at the migrated workload containers.
  # Enable the 'probed' property to include system services in the container health checks.
  systemServices:
  - enabled: true
    name: apache2
    probed: true
  - enabled: true
    name: atd
    probed: false

默认情况下，所有服务探测都处于停用状态。您必须定义要监控的服务子集。

使用探测检查容器有四种预定义的方法。每个探测必须定义以下四种机制之一：

exec - 在容器内执行指定的命令。如果退出状态代码为 0，则执行会被视为成功。
grpc - 使用“gRPC”执行远程过程调用。“gRPC”探测是一项 Alpha 版功能。
httpGet - 在指定端口和路径上对 Pod 的 IP 地址执行 HTTP GET 请求。如果状态代码大于或等于 200 且小于 400，则请求会被视为成功。
tcpSocket - 在指定端口上对 Pod 的 IP 地址执行 TCP 检查。如果该端口打开，则诊断会被视为成功。

默认情况下，迁移计划启用 exec 探测方法。对迁移计划使用手动配置可启用其他方法。

如需为就绪性探测添加外部依赖项，同时使用默认活跃性探测，请定义 exec 就绪性探测以及实现逻辑的脚本。

后续步骤

了解如何执行迁移。