导入过程包含四个阶段。

阶段 1

从管理器 API 检索所有资源。根据 Kubernetes 集群标记 (ncp/cluster) 或 user-spec.yaml 中指定的共享资源筛选资源。开始生成要发送到迁移服务器的请求正文。如果无法生成任何请求，NCP 将不会迁移集群并退出。

预期故障和解决方案：
  • 由于连接问题，无法从管理器 API 检索资源

    解决方案：修复连接问题后重试

  • Kubernetes 不包含从管理器 API 检索的资源

    解决方案：再次在管理器模式下运行 NCP，直到 NCP 达到空闲状态为止，这意味着它未在执行任何 CRUD（创建、读取、更新、删除）操作。您应至少等待 10 分钟，因为这是 NCP 发送重试请求之前的最大时间间隔。如果 NCP 日志中没有错误，则该问题应得以修复。

阶段 2

开始将在阶段 1 中创建的导入请求发送到迁移 API。成功处理请求后，在客户端的本地磁盘上记录请求中包含的 manager_id。如果任何请求失败，则使用在本地磁盘上存储的 manager_id 回滚已导入的资源。如果迁移 API 指示这是重复请求，导入程序将从请求正文中移除其 manager_id，然后再次发送该请求。

预期故障和解决方案：
  • 连接问题

    解决方案：修复连接问题后重试

  • 迁移 API 返回错误

    解决方案：在一段时间后重试，因为可能是策略 API 或迁移 API 出现故障。如果问题仍然存在，请在导入程序意外停止时使用 config.yaml 中的 rollback_imported_resources 选项回滚所有导入的资源。默认情况下，如果在此阶段出现任何问题，导入程序将会回滚。但是，如果在回滚过程中出现问题，您必须手动重试。如果使用 mp_to_policy_importer 进行回滚失败，则必须将 NSX Manager 从备份中还原到导入 Kubernetes 集群之前的状态。

注意：如果已导入 DFW 区域和规则，且之后资源导入请求失败，则必须使用创建的备份还原管理器的状态，然后再次启动集群导入过程。

阶段 3

在策略中为所有已导入的资源推断需要在资源上添加/移除的标记。如果无法推断任何标记（原因可能是缺少相应的 Kubernetes 资源），则导入程序将使用在本地磁盘上存储的 manager_id 回滚已导入的资源。如果处于管理器模式下的 NCP 在事务中间停止工作，可能会发生这种情况。因此，您应当在管理器模式下再次启动 NCP，然后等待一段时间。

预期故障和解决方案：
  • Kubernetes 不包含从管理器 API 检索的资源

    解决方案：回滚后，再次在管理器模式下运行 NCP，直到 NCP 达到空闲状态为止。您应至少等待 10 分钟，因为这是 NCP 发送重试请求之前的最大时间间隔。如果 NCP 日志中没有错误，则该问题应得以修复。

阶段 4

这是最关键的阶段。强烈建议在此阶段不要出现任何意外故障。在此阶段，导入程序将使用新标记和/或其他信息更新策略中的资源（例如，导入程序将更新分段的 display_name）。如果此时无法更新资源，则导入程序会将更新的策略资源正文和策略资源 URL 存储在客户端的本地磁盘上，并要求您在修复问题后重试（该问题存在于策略 API 中或属于连接问题）。

预期故障和解决方案：
  • 连接问题

    解决方案：修复连接问题后重试

在所有四个阶段，还存在出现意外电源故障和其他问题的风险，有关这些故障和问题的处理方法，请参见故障和恢复中所述。