RKE2/K3s集群子网迁移实战指南

1. 迁移背景与核心挑战在混合云架构中RKE2/K3s集群经常需要根据业务需求进行网络结构调整。最近我在客户生产环境中遇到一个典型场景由于公司网络架构升级需要将下游集群从原有子网迁移到基础设施提供商如AWS/Azure/本地数据中心的新子网中。这种迁移看似只是IP地址变更实则涉及复杂的网络配置、服务发现和业务连续性保障。迁移的核心难点在于集群节点需要保持原有配置如Kubernetes版本、应用配置不变必须确保ETCD数据一致性不受影响服务发现机制如CoreDNS需要平滑过渡所有网络策略NetworkPolicy和入口控制器Ingress配置需重新适配2. 迁移方案设计与验证2.1 前置检查清单在开始迁移前必须完成以下检查集群健康状态验证kubectl get nodes -o wide kubectl get pods -A -o wide rke2 etcd-snapshot save --snapshot-name pre-migration网络连通性测试新旧子网间路由配置安全组/ACL规则兼容性验证新子网的MTU值是否与原有网络一致关键服务依赖项kubectl get svc -A | grep -E LoadBalancer|NodePort2.2 分阶段迁移方案采用逐个节点滚动迁移策略具体步骤准备阶段在新子网预分配IP地址段准备相同规格的临时节点作为验证节点备份所有自定义资源CRDkubectl get crds -o name | xargs -I {} kubectl get {} -o yaml all-crds.yaml控制平面迁移graph TD A[停止第一个master节点] -- B[在新子网启动新master] B -- C[验证ETCD集群健康] C -- D[重复直到所有master迁移完成]工作节点迁移使用kubectl cordon隔离旧节点批量驱逐Pod注意有状态服务处理kubectl drain node-name --ignore-daemonsets --delete-emptydir-data修改节点配置文件后重新加入集群3. 关键配置调整3.1 网络插件适配根据不同的CNI插件需要特殊处理CNI类型配置变更要点Calico修改IP Pool CIDR更新BGP peer配置Cilium调整cluster-pool-ipv4-cidr更新kube-proxy替代设置Flannel更新--pod-cidr启动参数3.2 服务暴露方式更新LoadBalancer服务# AWS示例更新ELB的安全组 aws elb apply-security-groups-to-load-balancer \ --load-balancer-name my-lb \ --security-groups sg-newsubnetIngress控制器# Nginx Ingress示例 controller: service: annotations: service.beta.kubernetes.io/aws-load-balancer-subnets: subnet-new1,subnet-new24. 验证与回滚方案4.1 迁移后验证基础功能检查# 检查节点状态 kubectl get nodes -o custom-columnsNAME:.metadata.name,INTERNAL-IP:.status.addresses[?(.typeInternalIP)].address # 验证DNS解析 kubectl run -it --rm --imagebusybox testpod -- nslookup kubernetes.default性能基准测试kubectl create deployment perf-test --imageregistry.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-ip4.2 回滚机制设计快照回退方案rke2 etcd-snapshot restore \ --snapshot-name pre-migration \ --data-dir /var/lib/rancher/rke2/server/db网络回切检查点保留旧子网路由规则24小时配置DNS服务的双栈解析5. 实战经验与避坑指南IP冲突预防提前扫描新子网已用IP段使用DHCP保留地址时注意租期重叠问题特殊工作负载处理# 处理有状态工作负载 kubectl get statefulsets -A --no-headers | awk {print $1,$2} | \ xargs -n2 bash -c kubectl scale sts $1 -n $0 --replicas0监控系统调整更新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_VERSIONv1.24.8rke2r1 sh - sudo systemctl enable rke2-server sudo systemctl start rke2-server EOF7. 后续优化方向完成基础迁移后建议考虑网络性能调优测试新子网的网络延迟和吞吐量根据实际负载调整CNI插件参数架构改进graph LR A[旧子网] --|逐步淘汰| B[新子网] B -- C[多AZ部署] C -- D[IPv6双栈支持]文档更新记录所有网络拓扑变更更新灾难恢复手册中的IP参考信息整个迁移过程中最重要的经验是每次变更后立即验证基础服务DNS、API Server、监控出现问题优先回退到上一个稳定状态。在新子网环境稳定运行至少两周后再考虑完全下线旧网络资源。