您可以将 NCP 集群和 Foundation 从管理器模式迁移到策略模式。
NCP 升级后,可以将 NSX Manager 模式资源迁移到 NSX 策略,从而允许 NCP 在策略模式下运行。在文档中,迁移也称为“导入”。它们所表达的意思相同。用于迁移 TAS Foundation 的功能从 NCP 4.1.2 开始提供;用于迁移 TKGI 集群和 vanilla Kubernetes 集群的功能从 NCP 4.0 开始提供。
必备条件
- 迁移 Kubernetes 集群或 TAS Foundation 可能需要一些时间,并且要求 NSX 上的控制平面停机(不允许执行创建、更新或删除操作)。停机的持续时间将取决于使用的迁移策略,其中有两种策略:
- 策略 1:(建议且对于 TAS 为必需要求)同时在所有集群(以管理器模式或策略模式运行)上调度控制平面停机。停机时间将持续到所有集群均已迁移到策略为止。其优点在于,它允许您在故障和恢复期间使用 NSX 备份和还原功能。
- 策略 2:一次在一个集群上调度控制平面停机。迁移集群后,将在该集群上以策略模式启动 NCP。NSX 备份和还原无法与此策略一起使用,因为在迁移当前集群时,其他集群可能会在 NSX 上创建新的工作负载。如果在迁移和回滚失败时可以接受放弃集群,则可以使用此模式。
- NSX Manager 可以分别由多个集群或 Foundation 共享。一次只能将共享同一 NSX Manager 的其中一个集群/Foundation 迁移到策略。
- 必须将在任何 NCP 创建的区域之间存在的所有手动创建的 DFW 区域移动到 NCP 创建的 DFW 区域范围之外。请参见处理 NSX 管理员创建的 DFW 区域。
- 必须将 NCP 创建的区域内的所有用户创建的规则移出 NCP 创建的区域。请参见处理 NSX 管理员创建的 DFW 区域。
- 管理器模式下 NCP 创建的 LoadBalancer 虚拟服务器不能拥有超过 255 个规则。这意味着,Kubernetes 在默认 LoadBalancer 上不能拥有超过 255 个输入规则。如果输入规则超过 255 个,则必须当 NCP 在管理器模式下运行时将输入拆分为多个 LoadBalancer CRD。
- 如果在 NSX UA 前面使用负载均衡器,则必须在负载均衡器上附加源 IP 持久性配置文件,以便脚本在迁移期间执行的所有 API 调用均可访问同一 NSX 设备。在所有 Foundation/集群迁移到策略 API 后,应移除此持久性配置文件
限制和注意事项
- 我们尚不支持在产品 TAS Foundation、TKGi 和 vanilla Kubernetes 集群之间共享 NSX Manager 的方案。例如,使用同一 NSX Manager 节点运行 1 个或多个 Foundation 以及 1 个或多个 TKGi 集群时。
- 执行迁移并在策略模式下重新启动 NCP 后,NCP 将与 NSX 协调 TAS Foundation 或 TKGi 集群中的现有工作负载。协调时间与现有工作负载大小成正比。在协调期间,Pod 或应用程序实例创建等操作可能会失败,并且创建或删除映射到 TAS 和 TKGi 实体的 NSX 资源时也可能会出现重大延迟。对于非常大的集群或 Foundation,在 NCP 资源使用率接近规模限制的情况下,建议将维护时段至少添加 45 分钟,以使 NCP 能够与后端进行协调。协调完成后,NCP 将自动重试同步失败的操作。
进程详细信息
- 共享 NSX 资源:这些 NSX 资源由管理员手动创建,并通过 TAS/TKGi 中的 Ops Manager UI 或 vanilla Kubernetes 中的 nsx-ncp-config Kubernetes 配置映射提供给 NCP。这些资源可以在 Foundation 和集群之间共享。在 Foundation/集群迁移开始之前,需要在名为 user-spec 的 YAML 文件中手动指定这些资源(请参见 user-spec.yaml 示例)
- 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,然后再次尝试迁移。