在同一地理区域内的天翼云CCE One管理的Kubernetes集群间进行迁移，实现资源优化、应用升级或其他管理需求。其迁移流程如下图所示：

前提条件

• 已开通天翼云分布式容器云平台CCE One及其关联产品的访问权限。

• 同资源池情况下，CCE One联邦自动打通与成员集群之间的管理网络（同VPC或跨VPC均可），无需用户额外配置操作。

适用场景

云上资源优化、应用升级或其他管理需求场景。

操作指引

本场景迁移，主要包含四个步骤：

步骤一：集群评估与纳管

在这个阶段，您将根据源集群的现状来评估适合迁移的目标集群类型。

可以基于必要的开源工具自动或手工收集源集群的信息，包括Kubernetes版本、规模、工作负载、存储等数据，并根据收集到的数据考虑合适的目标集群信息；

为方便后续的数据备份与恢复，或者基于联邦的细粒度应用迁移，您需要将源集群注册到天翼云CCE One注册集群；

步骤二：数据迁移

若您的集群使用了云硬盘，需要随集群一起迁往目标AZ，可以通过云备份服务创建云硬盘备份，再使用备份创建新的云硬盘，在配置云硬盘信息时，选择目标可用区即可。

• 具体操作参考：云硬盘备份与恢复 以及 云硬盘数据跨可用区迁移

步骤三：目标集群创建与纳管

在这个阶段，您将评估目标集群所需规格信息并创建对应的天翼云CCE集群；然后将该目标集群关联到分布式容器云平台CCE One注册集群；

云容器引擎允许用户对集群资源进行个性化选取，以精准匹配其多样化的业务诉求。如下所示的表中，列举了集群的指标参数，并提供了参考规划选择；用户应依据自身业务的确切需求，对相关设置做出合理调配，其间，我们建议尽可能保持与原集群性能配置的一致性水平。

在目标CCE集群创建好后，需要进入天翼云分布式容器云平台CCE One控制台，将目标CCE集群关联到CCE One的注册集群以便支持后期的纳管与联邦调度能力；

步骤四：应用迁移

在这个阶段，您将利用CCE One集群联邦多集群应用调度能力，将您源CCE集群中的应用迁移到目标CCE注册集群。

1. 订购天翼云CCE One集群联邦实例，并将源CCE集群和目标CCE集群作为成员加入联邦（通过舰队绑定）；

应用迁移需要基于集群联邦控制面来完成，因此需要用户首先在CCE One联邦管理界面首先创建一个联邦实例。

联邦实例只可以关联一个舰队，注册集群可以加入舰队；注册集群加入已关联联邦的舰队时，即自动作为成员集群加入该联邦。

成员集群和联邦实例之间涉及网络链路打通，建议优先将相关注册集群和联邦创建到相同的资源池和VPC下，这样可以默认内网互通并且无任何额外成本；若源和目标注册集群的确需要跨资源池，可参考指引《打通注册集群与联邦实例之间的联通网络》配置网络，并选择正确的接入链路类型以确保成员集群、联邦网络互通。

成员集群加入联邦成功后，在总览页面，可看到成员集群列表的“接入联邦状态”列，均显示为“已联通”。

2. 将需要迁移的工作负载或相关服务，提升到集群联邦控制面管理；

成员集群加入联邦后，其内部署的工作负载、Service、ConfigMap等还无法通过联邦进行调度，需要首先将相关资源YAML作为配置模板提升到联邦控制面管理，此后，才能再基于联邦进行该工作负载的多集群调度分发。

底层集群工作负载提升到联邦控制面管理的方式有两种，对原始工作负载的影响也不同。需要业务按自身需求按需选择：
 

方式一：工作负载维度接管，并且原集群中工作负载Pod不重启；

假设成员集群member1中存在工作负载default/nginx，其状态为running：

[root@cluster1]# kubectl get deploy nginxNAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           66s[root@cluster1]# kubectl get podNAME                       READY   STATUS      RESTARTS   AGE
nginx-6799fc88d8-sqjj4     1/1     Running     0          2m12s

我们可以基于联邦控制面kubectl方式，执行以下命令来将其提升到联邦控制面管理：

[root@master1]# karmadactl promote deployment nginx -n default -c member1Resource "apps/v1, Resource=deployments"(default/nginx) is promoted successfully

此时，再在联邦控制面中查询该工作负载，可看到已经可以查询到，说明已被联邦实例接管：

[root@master1]# kubectl get deployNAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           7m25s

检查成员集群中对应nginx无状态工作负载，对应Pod并未重启：

[root@cluster1]# kubectl get podNAME                       READY   STATUS      RESTARTS   AGE
nginx-6799fc88d8-sqjj4     1/1     Running     0          15m

方式二：批量提升接管，原集群中工作负载Pod会重启；

对于希望批量提升到联邦控制面接管，以及对Pod重启无感知的的服务或资源，可考虑采用本方式，其执行效率相对更高。

在成员集群中已部署服务非常多或应用较复杂情况下，该方式更适合。可基于更大的粒度，来做资源的接管和提升，例如：

• 以资源为粒度，迁移某种类型的全部资源

• 以应用为粒度，迁移某个应用涉及的所有类型的资源

此时，就需要资源模板结合集群联邦的调度策略PropagationPolicy，来接管相应资源，可以按如下方式操作。

a.将所有资源的 YAML 配置应用到 集群联邦控制面, 作为集群联邦的 ResourceTemplate。此时，资源模板只会存在联邦控制面，并不会下发任何成员集群；

b.编写 PropagationPolicy 调度策略, 并将其应用到集群联邦控制面。 您需要注意以下两个字段：

• spec.conflictResolution: Overwrite：该字段的值必须是 Overwrite。

• spec.resourceSelectors：指定哪些资源需要被迁移。

如果你希望的是将所有Deployment资源提升到联邦控制面管理，则可以配置类似如下的调度策略：

apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata:
  name: deployments-ppspec:
  conflictResolution: Overwrite
  placement:
    clusterAffinity:
      clusterNames:
      - member1
  priority: 0
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
  schedulerName: default-scheduler

当前，除了YAML方式创建外，也支持基于前端页面的引导创建。可进入联邦控制台->策略管理->调度策略->创建调度策略页面进行配置；

在以上调度策略配置完成后，联邦实例将进行联邦资源模板与底层的同步与覆盖。一段时间后即可观测到相关工作负载已被联邦实例接管；

3. 基于集群联邦，将服务逐步迁移到目标集群中；

已接管的工作负载，支持按需调整其调度策略及差异化策略，来实现工作负载多集群之间的灵活调度。此时，您可以在联邦控制面中编辑需要迁移工作负载的实例数或调度策略，使其复制分发到目标成员集群中去。

点击进入工作负载->无状态，选在对应的工作负载实例后，点击后侧“全量替换”操作按钮进行编辑：

在编辑页面中，直接跳过模板配置步骤，进入调度与差异化配置页面。通过设置调整集群调度策略，可将工作负载复制分发到目标集群，或按权重拆分部分副本到新集群。如下：

如上图配置，提交更新后，工作负载将在源集群和目标集群中1：1比例部署。
 

4.  服务验证及终端灰度切流；

该步骤中，用户可基于应用实际架构及服务需求，在验证目标成员服务正常后，实施真实用户流量的逐步切流；

切流过程中，可配合通过调度策略逐步调整工作负载Pod副本在源集群与目标集群之间的分布，并最终全部迁移到天翼云上CCE集群，以实现完整的切流；