分布式容器云平台CCE One容器迁移功能，支持将三方云标准Kubernetes集群应用迁移到天翼云CCE集群，实现应用程序的跨云迁移和统一运维管理。迁移流程如下图所示：
前提条件
已开通天翼云分布式容器云平台CCE One及其关联产品的访问权限。
已打通三方云容器集群与天翼云资源池VPC网络，可选公网或内网方式。其中：
公网方式（推荐）：需要您三方云集群中Pod具备主动访问功能的能力，可通过给容器集群VPC配置公网NAT出口方式实现；
内网方式：需要您将三方云容器网络与天翼云云上VPC网络打通；可选云专线、SD-WAN或VPN方式；另还需参考配置指引，配置正确的云间网关路由及DNS解析转发策略，以确保您三方云容器Pod中可正常访问天翼云相关服务；
适用场景
云备份容灾：备份容灾迁移一体化，快速实现应用云间迁移与数据灾备。
操作指引
本场景迁移，主要包含四个步骤：
步骤一：集群评估与纳管
在这个阶段，您将根据源集群的现状来评估适合迁移的目标集群类型。可以基于必要的开源工具自动或手工收集源集群的信息，包括Kubernetes版本、规模、工作负载、存储等数据，并根据收集到的数据考虑合适的目标集群信息。
为方便后续的数据备份与恢复，或者基于联邦的细粒度应用迁移，您需要将源集群注册到天翼云CCE One注册集群；
步骤二：数据迁移
在这个阶段，您将把镜像和相关依赖服务的数据迁移到天翼云对应云产品中。可基于天翼云上提供的专业云迁移、云备份等迁移工具，或基于云产品提供的专门迁移指引进行迁移。例如：
三方云镜像仓库迁移参考：第三方镜像仓库导入
三方云MySQL迁移请参考：其他云MySQL迁移到RDS For MySQL
三方云PostgreSQL迁移请参考：其他云PostgreSQL迁移到RDS For PostgreSQL
其他类型存储迁移，请参考天翼云上对应云产品提供的迁移指引；
步骤三：天翼云集群创建与纳管
在这个阶段，您将评估目标集群所需规格信息并创建对应的天翼云CCE集群；然后将该目标集群关联到分布式容器云平台CCE One注册集群；
云容器引擎允许用户对集群资源进行个性化选取，以精准匹配其多样化的业务诉求。如下所示的表中，列举了集群的指标参数，并提供了参考规划选择；用户应依据自身业务的确切需求，对相关设置做出合理调配，其间，我们建议尽可能保持与原集群性能配置的一致性水平。
| 主要指标参数 | 指标参数说明 | 本示例规划 |
|---|---|---|
| kubernetes版本 |
| 1.29.3 |
| 网络插件 |
| cubecni |
| apiserver访问 | API Server的访问需要依赖ELB实例，您可根据需要选择合适的ELB规格，系统将根据该规格创建一个私网ELB实例。规格选择请见：了解ELB实例规格 | 标准型I |
| 控制节点数 |
| 3 |
| 节点规格 | 分为控制节点规格和工作节点规格，如何选择可以参考：集群规格推荐规划 | 通用型4C8G |
| 工作节点操作系统 |
| ctyunos23.01 |
在目标CCE集群创建好后，需要进入天翼云分布式容器云平台CCE One控制台，将目标CCE集群关联到CCE One的注册集群以便支持后期的纳管与联邦调度能力；
步骤四：应用迁移
在这个阶段，您将利用CCE One集群联邦多集群应用调度能力，将您三方云容器集群中的应用迁移到天翼云CCE注册集群。
1. 订购天翼云CCE One集群联邦实例，并将三方云源集群和目标天翼云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集群，以实现完整的切流。
