您可以将 NCP 集群和 Foundation 从管理器模式迁移到策略模式。

NCP 升级后，可以将 NSX Manager 模式资源迁移到 NSX 策略，从而允许 NCP 在策略模式下运行。在文档中，迁移也称为“导入”。它们所表达的意思相同。用于迁移 TAS Foundation 的功能从 NCP 4.1.2 开始提供；用于迁移 TKGI 集群和 vanilla Kubernetes 集群的功能从 NCP 4.0 开始提供。

必备条件

  1. 迁移 Kubernetes 集群或 TAS Foundation 可能需要一些时间，并且要求 NSX 上的控制平面停机（不允许执行创建、更新或删除操作）。停机的持续时间将取决于使用的迁移策略，其中有两种策略：
    1. 策略 1：（建议且对于 TAS 为必需要求）同时在所有集群（以管理器模式或策略模式运行）上调度控制平面停机。停机时间将持续到所有集群均已迁移到策略为止。其优点在于，它允许您在故障和恢复期间使用 NSX 备份和还原功能。
    2. 策略 2：一次在一个集群上调度控制平面停机。迁移集群后，将在该集群上以策略模式启动 NCP。NSX 备份和还原无法与此策略一起使用，因为在迁移当前集群时，其他集群可能会在 NSX 上创建新的工作负载。如果在迁移和回滚失败时可以接受放弃集群，则可以使用此模式。
  2. NSX Manager 可以分别由多个集群或 Foundation 共享。一次只能将共享同一 NSX Manager 的其中一个集群/Foundation 迁移到策略。
  3. 必须将在任何 NCP 创建的区域之间存在的所有手动创建的 DFW 区域移动到 NCP 创建的 DFW 区域范围之外。请参见处理 NSX 管理员创建的 DFW 区域。
  4. 必须将 NCP 创建的区域内的所有用户创建的规则移出 NCP 创建的区域。请参见处理 NSX 管理员创建的 DFW 区域。
  5. 管理器模式下 NCP 创建的 LoadBalancer 虚拟服务器不能拥有超过 255 个规则。这意味着，Kubernetes 在默认 LoadBalancer 上不能拥有超过 255 个输入规则。如果输入规则超过 255 个，则必须当 NCP 在管理器模式下运行时将输入拆分为多个 LoadBalancer CRD。
  6. 如果在 NSX UA 前面使用负载均衡器，则必须在负载均衡器上附加源 IP 持久性配置文件，以便脚本在迁移期间执行的所有 API 调用均可访问同一 NSX 设备。在所有 Foundation/集群迁移到策略 API 后，应移除此持久性配置文件

限制和注意事项

  1. 我们尚不支持在产品 TAS Foundation、TKGi 和 vanilla Kubernetes 集群之间共享 NSX Manager 的方案。例如，使用同一 NSX Manager 节点运行 1 个或多个 Foundation 以及 1 个或多个 TKGi 集群时。
  2. 执行迁移并在策略模式下重新启动 NCP 后，NCP 将与 NSX 协调 TAS Foundation 或 TKGi 集群中的现有工作负载。协调时间与现有工作负载大小成正比。在协调期间，Pod 或应用程序实例创建等操作可能会失败，并且创建或删除映射到 TAS 和 TKGi 实体的 NSX 资源时也可能会出现重大延迟。对于非常大的集群或 Foundation，在 NCP 资源使用率接近规模限制的情况下，建议将维护时段至少添加 45 分钟，以使 NCP 能够与后端进行协调。协调完成后，NCP 将自动重试同步失败的操作。

进程详细信息

将 Kubernetes/TKGi 集群或 TAS Foundation 迁移到策略模式时，迁移的 NSX 资源分为两类：
  1. 共享 NSX 资源：这些 NSX 资源由管理员手动创建，并通过 TAS/TKGi 中的 Ops Manager UI 或 vanilla Kubernetes 中的 nsx-ncp-config Kubernetes 配置映射提供给 NCP。这些资源可以在 Foundation 和集群之间共享。在 Foundation/集群迁移开始之前，需要在名为 user-spec 的 YAML 文件中手动指定这些资源（请参见 user-spec.yaml 示例）
  2. NCP 创建的 NSX 资源：这些 NSX 资源是由 NCP 为响应 Foundation/集群工作负载而创建的。这些资源会在迁移期间自动推断

注意：仅当所有 NCP 创建的 NSX 资源均处于管理器模式时，NCP Pod 才能在管理器模式下运行。同样，仅当所有 NCP 创建的 NSX 资源均处于策略模式时，NCP Pod 才能在策略模式下运行。

vanilla Kubernetes 集群的迁移由名为“nsx-ncp-migrate-mp2p”的 Kubernetes 作业驱动，而 TKGi 集群和 TAS Foundation 的迁移则由名为“migrate-mp2p”的任务驱动。该作业/任务执行 python 程序以迁移共享 NSX 资源或 NCP 创建的 NSX 资源。python 程序在两种模式下运行：迁移（请参阅“迁移阶段”一节）和回滚（请参阅“回滚模式”一节）。在触发该任务/作业之前，必须先停止共享 NSX 网络的所有集群（管理器集群和策略集群）中的 NCP，然后创建 NSX 备份。在介绍如何迁移 Kubernetes 集群或 TAS Foundation 的章节中提供了详细的步骤。

迁移模式

迁移模式分为 4 个逻辑上相互独立的阶段。

阶段 1

使用搜索 API 从管理器 API 中检索所有 NSX 资源。根据集群标记（迁移 NCP 创建的资源时）或用户规范文件中指定的共享资源（迁移共享资源时）来筛选资源。开始生成要发送到迁移服务器的请求正文。如果无法生成任何请求，则不会迁移任何 NSX 资源。

可能的问题：
  • 与 NSX 的连接问题
  • Kubernetes API 服务器不包含迁移 NSX Manager 资源所需的资源

阶段 2

开始将在阶段 1 中创建的迁移请求发送到在 NSX 中运行的迁移协调器服务。NSX 成功处理请求后，会将通过请求迁移的 NSX 资源的 MP ID 存储在本地磁盘上（这些称为“迁移记录”）。如果出现问题，程序会使用存储在本地磁盘上的 MP ID，将在当前执行期间迁移的所有 NSX 资源回滚到管理器模式。

可能的问题：
  • 与 NSX 的连接问题
  • 迁移 API 返回错误

阶段 3

推断应在当前执行中对迁移的 NSX 资源进行的更新。这些仅包含 NSX 资源的标记和/或显示名称中的更新。如果无法推断更新（原因可能是缺少相应的 Kubernetes 资源），则会回滚所有 NSX 资源。

可能的问题：
  • 与 NSX 的连接问题。
  • Kubernetes API 服务器不包含更新 NSX 策略资源所需的资源。

阶段 4

使用阶段 3 中推断的信息更新 NSX 策略资源。如果此时无法更新 NSX 资源，则会将更新的策略资源正文和策略资源 URL 存储在本地磁盘上。

可能的问题：
  • 与 NSX 的连接问题。

如果在迁移过程中遇到任何问题，请参见“故障和恢复”一节。

回滚模式

在此模式下，python 程序会尝试回滚其 MP ID 存在于本地存储上的迁移记录中的所有 NSX 资源（请参见迁移阶段 2）。成功回滚 NSX 资源后，将删除这些资源的迁移记录。如果在回滚期间出现故障，则执行将停止，并且必须再次运行任务/作业。

程序启动后，如果在本地存储上发现任何迁移记录，它将自动在回滚模式下运行（请参见迁移阶段 2）。

故障和恢复

由于外部问题（如电源故障、磁盘耗尽、连接问题、功能问题等），迁移过程可能会无法成功完成。在此类场景中，有多种恢复方法。

我们建议首先检查迁移任务/作业的日志。它们可能会指示接下来要采取的操作。具体可能属于以下操作之一：
  • （如果日志未指示，则采用默认解决方案）再次运行迁移任务/作业。
    • 如果上次故障发生在阶段 1、2 或 3，则迁移任务/作业将尝试使用迁移记录回滚 NSX 资源（请参见阶段 2）。必须执行此操作，直到回滚了所有 NSX 资源。
    • 如果上次故障发生在阶段 4，则迁移任务/作业将再次尝试在策略模式下更新 NSX 资源。必须执行此操作，直到成功更新了所有 NSX 资源。
  • 在管理器模式下运行 NCP，然后重试迁移。如果迁移任务/作业无法迁移集群，则 NCP 需要在此集群/Foundation 中以管理器模式再次运行。但是，这会使 NSX 备份无效。因此，请暂时跳过此集群的迁移。将所有其他集群迁移到策略模式后，在此集群中以管理器模式启动 NCP，并在所有其他集群中以策略模式启动 NCP。等待至少 60 分钟，然后从头开始再次按照迁移步骤重试集群迁移。

在极少数情况下，如果无法通过上述步骤进行恢复，请将 NSX Manager 还原到在将任何集群迁移到策略之前创建的上一个备份点，在与执行 NSX 备份时相同的模式下重新启动所有集群中的 NCP，然后再次尝试迁移。