自定义 Linux 虚拟机的迁移计划
在执行迁移计划之前，您应该查看并选择性地自定义。迁移计划的详细信息用于从来源虚拟机中提取工作负载的容器工件，以及生成可用于将容器映像部署到其他集群（如生产集群）的 Kubernetes 部署文件。
本部分介绍迁移计划的内容以及在执行迁移和生成部署工件之前您可以考虑的自定义种类。
准备工作
本主题假设您已经创建了迁移并生成了迁移计划文件。
修改迁移计划
您可以使用 migctl 工具或 Google Cloud 控制台修改迁移计划。
migctl
您必须先下载迁移计划，然后才能对其进行修改：
下载迁移计划。Linux 工作负载的迁移计划由 LinuxMigrationCommonSpec 表示：
migctl migration get my-migration
在文本编辑器中修改下载的迁移计划
my-migration.yaml。修改完成后，保存并上传修改后的迁移计划：
migctl migration update my-migration --main-config my-migration.yaml
如果需要进行更多修改，请重复上述步骤。
控制台
使用 YAML 编辑器在 Google Cloud 控制台中修改迁移计划。Linux 工作负载的迁移计划由 LinuxMigrationCommonSpec CRD 表示：
打开 Google Cloud 控制台中的 Migrate to Containers 页面。
点击迁移标签页以显示包含可用迁移的表。
在所需迁移所在的行中，选择迁移名称以打开详情标签页。
选择 YAML 标签页。
根据需要修改迁移计划。
修改完成后，您可以执行以下任意操作：
CRD
您必须下载迁移计划，进行修改，然后应用。Linux 工作负载的迁移计划由 LinuxMigrationCommonSpec CRD 表示：
获取
AppXGenerateArtifactsFlow的名称：kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration命名模式以
appx-generateartifactsflow-id的形式返回。按名称获取迁移计划并写入名为
my-plan.yaml的文件：kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml根据需要修改迁移计划。
应用此文件：
kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id
指定要从迁移中排除的内容
默认情况下，Migrate to Containers 会排除 GKE 环境中无关的典型虚拟机内容。您可以自定义该过滤条件。
filters 字段值会列出应从迁移中排除且不属于容器映像的路径。该字段的值列出了 rsync 过滤规则，这些规则指定要转移的文件以及要跳过的文件。在每个路径和文件前面加上减号可指定应从迁移中排除的列表项。系统会按照 YAML 中各行的顺序处理该列表，并相应地评估排除项/包含项。
如需了解详情，请参阅 rsync 手册页的“INCLUDE/EXCLUDE PATTERN RULES”部分
太大而无法包含在 docker 映像中的文件将列在 YAML 文件中。这会标记大于 1GB 的文件供您考虑。太大或大于 15GB 的 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 字段值定义从迁移后的虚拟机创建的两个映像的名称和位置。如果您希望使用其他名称，可以更改这些值。
在迁移期间，Migrate to Containers 会默认将代表迁移的工作负载的文件和目录复制到 Container Registry，以供迁移时使用。迁移过程会将提取的工作负载调整为可在 GKE 上运行的映像。
Migrate to Containers 会将来自原始虚拟机的文件和目录保留在注册表的 base 路径下。此映像充当不可运行的基础层，其中包含提取的工作负载文件；这些文件随后将与 Migrate to Containers 运行时软件层组合以构建可执行容器映像。
使用不同的层可让您根据需要对基础层或 Migrate to Containers 软件层进行单独更新，从而简化了容器映像的后续更新。
此映像不可运行，但 Migrate to Containers 可以在升级时从该原始映像更新容器。
base 和 name 字段值指定在注册表中创建的映像。
base- 根据从来源平台复制的虚拟机文件和目录创建的映像的名称。此映像无法在 GKE 上运行，因为它不适合在其中进行部署。name- 用于容器的可运行映像的名称。此映像包含来自来源虚拟机的内容，以及 Migrate to Containers 运行时（用于使该映像可运行）。
image:
# Review and set the name for extracted non-runnable base image,
# if an image tag is not specified, a random tag is auto-generated when the image is built.
base: "centos-mini-non-runnable-base"
# Review and set the name for runnable container image,
# if an image tag is not specified, a random tag is auto-generated when the image is built.
name: "centos-mini"
默认情况下，与迁移的时间戳对应的标记会自动应用于这些值。此标记的格式如下：
MM-DD-YYYY--hh:mm:ss
如需应用您自己的标记（替换默认标记），请修改 CRD 并按如下方式添加它：
image:
# Review and set the name for extracted non-runnable base image,
# if an image tag is not specified, a random tag is auto-generated when the image is built.
base: "centos-mini-non-runnable-base:tag"
# Review and set the name for runnable container image,
# if an image tag is not specified, a random tag is auto-generated when the image is built.
name: "centos-mini:tag"
自定义服务列表
默认情况下，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文件、deployment_spec.yaml文件和 Dockerfile。
或者，在执行迁移生成迁移工件之后，您可以直接修改 blocklist.yaml 文件，然后自行重新构建和推送容器映像。例如：
更新
blocklist.yaml文件。重新构建和推送容器映像。
构建和推送容器映像的方式取决于您的构建环境。您可以使用：
重新构建并推送新映像后，在编辑器中打开
deployment_spec.yaml文件以更新映像位置：spec: containers: - image: new-image-location
例如，如果您使用
gcloud重新构建映像并将其推送到 Container Registry，则 new-image-location 可以为my-new-image:v1.0。
自定义服务端点
迁移计划包含 endpoints 数组，用于定义用于创建迁移后工作负载提供的 Kubernetes 服务的端口和协议。您可以添加、修改或删除端点定义以自定义迁移计划。
对于每个 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 的对应字段共享相同的功能
- 活跃性探测 - 活跃性探测用于了解何时重启容器。
- 就绪性探测 - 就绪性探测用于了解容器何时准备好开始接受流量。如需仅在探测成功时开始将流量发送到 Pod，请指定就绪性探测。就绪性探测的作用可能类似于活跃性探测，但规范中的就绪性探测表示 Pod 会在未收到任何流量的情况下启动，并且仅在探测成功后开始接收流量。
发现后，探测配置将添加到迁移计划中。探测可以在其默认配置中使用，如下所示。如需停用探测，请从 yaml 中移除 probes 部分。
v2kServiceManager: true
deployment:
probes:
livenessProbe:
exec:
command:
- gamma
- /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 就绪性探测以及实现逻辑的脚本。
后续步骤
- 了解如何执行迁移。