1. 迁移背景与核心挑战

在混合云架构中，RKE2/K3s集群经常需要根据业务需求进行网络结构调整。最近我在客户生产环境中遇到一个典型场景：由于公司网络架构升级，需要将下游集群从原有子网迁移到基础设施提供商（如AWS/Azure/本地数据中心）的新子网中。这种迁移看似只是IP地址变更，实则涉及复杂的网络配置、服务发现和业务连续性保障。

迁移的核心难点在于：

• 集群节点需要保持原有配置（如Kubernetes版本、应用配置）不变
• 必须确保ETCD数据一致性不受影响
• 服务发现机制（如CoreDNS）需要平滑过渡
• 所有网络策略（NetworkPolicy）和入口控制器（Ingress）配置需重新适配

2. 迁移方案设计与验证

2.1 前置检查清单

在开始迁移前，必须完成以下检查：

1. 集群健康状态验证：

   kubectl get nodes -o wide kubectl get pods -A -o wide rke2 etcd-snapshot save --snapshot-name pre-migration

2. 网络连通性测试：

   • 新旧子网间路由配置
   • 安全组/ACL规则兼容性
   • 验证新子网的MTU值是否与原有网络一致

3. 关键服务依赖项：

   kubectl get svc -A | grep -E 'LoadBalancer|NodePort'

2.2 分阶段迁移方案

采用"逐个节点滚动迁移"策略，具体步骤：

1. 准备阶段：

   • 在新子网预分配IP地址段
   • 准备相同规格的临时节点（作为验证节点）
   • 备份所有自定义资源（CRD）：

     kubectl get crds -o name | xargs -I {} kubectl get {} -o yaml > all-crds.yaml

2. 控制平面迁移：

   graph TD A[停止第一个master节点] --> B[在新子网启动新master] B --> C[验证ETCD集群健康] C --> D[重复直到所有master迁移完成]

3. 工作节点迁移：

   • 使用kubectl cordon隔离旧节点
   • 批量驱逐Pod（注意有状态服务处理）：

     kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

   • 修改节点配置文件后重新加入集群

3. 关键配置调整

3.1 网络插件适配

根据不同的CNI插件需要特殊处理：

3.2 服务暴露方式更新

1. LoadBalancer服务：

   # AWS示例：更新ELB的安全组 aws elb apply-security-groups-to-load-balancer \ --load-balancer-name my-lb \ --security-groups sg-newsubnet

2. Ingress控制器：

   # Nginx Ingress示例 controller: service: annotations: service.beta.kubernetes.io/aws-load-balancer-subnets: "subnet-new1,subnet-new2"

4. 验证与回滚方案

4.1 迁移后验证

1. 基础功能检查：

   # 检查节点状态 kubectl get nodes -o custom-columns=NAME:.metadata.name,INTERNAL-IP:.status.addresses[?(@.type=="InternalIP")].address # 验证DNS解析 kubectl run -it --rm --image=busybox testpod -- nslookup kubernetes.default

2. 性能基准测试：

   kubectl create deployment perf-test --image=registry.k8s.io/e2e-test-images/jessie-dnsutils:1.3 -- /bin/sh -c "while true; do sleep 1; done" kubectl exec perf-test-<pod> -- dnsperf -d test-queries.txt -s <new-dns-service-ip>

4.2 回滚机制设计

1. 快照回退方案：

   rke2 etcd-snapshot restore \ --snapshot-name pre-migration \ --data-dir /var/lib/rancher/rke2/server/db

2. 网络回切检查点：

   • 保留旧子网路由规则24小时
   • 配置DNS服务的双栈解析

5. 实战经验与避坑指南

1. IP冲突预防：

   • 提前扫描新子网已用IP段
   • 使用DHCP保留地址时注意租期重叠问题

2. 特殊工作负载处理：

   # 处理有状态工作负载 kubectl get statefulsets -A --no-headers | awk '{print $1,$2}' | \ xargs -n2 bash -c 'kubectl scale sts $1 -n $0 --replicas=0'

3. 监控系统调整：

   • 更新Prometheus的node_exporter目标
   • 修正Grafana仪表板中的IP过滤条件

关键提示：迁移过程中务必保持原有子网的网络连通性，直到所有验证完成。曾遇到客户因过早删除旧路由导致监控数据丢失的案例。

6. 自动化迁移脚本示例

以下是一个master节点迁移的参考脚本：

#!/bin/bash OLD_MASTER=$1 NEW_MASTER=$2 CLUSTER_TOKEN=$3 # 从旧节点获取配置 ssh $OLD_MASTER "sudo cat /etc/rancher/rke2/config.yaml" > new_master_config.yaml # 修改网络配置 sed -i "s/server: https:.*/server: https:\/\/${NEW_MASTER}:9345/" new_master_config.yaml # 启动新master scp new_master_config.yaml $NEW_MASTER:~/ ssh $NEW_MASTER <<EOF sudo mkdir -p /etc/rancher/rke2/ sudo mv ~/new_master_config.yaml /etc/rancher/rke2/config.yaml curl -sfL https://get.rke2.io | INSTALL_RKE2_VERSION=v1.24.8+rke2r1 sh - sudo systemctl enable rke2-server sudo systemctl start rke2-server EOF

7. 后续优化方向

完成基础迁移后，建议考虑：

1. 网络性能调优：

   • 测试新子网的网络延迟和吞吐量
   • 根据实际负载调整CNI插件参数

2. 架构改进：

   graph LR A[旧子网] -->|逐步淘汰| B[新子网] B --> C[多AZ部署] C --> D[IPv6双栈支持]

3. 文档更新：

   • 记录所有网络拓扑变更
   • 更新灾难恢复手册中的IP参考信息

整个迁移过程中，最重要的经验是：每次变更后立即验证基础服务（DNS、API Server、监控），出现问题优先回退到上一个稳定状态。在新子网环境稳定运行至少两周后，再考虑完全下线旧网络资源。