1. 迁移背景与核心挑战在混合云架构中RKE2/K3s集群经常需要根据业务需求进行网络结构调整。最近我在客户现场遇到一个典型场景由于公司网络架构升级需要将运行在本地数据中心的RKE2下游集群整体迁移到公有云的新子网中。这种迁移不仅涉及IP地址变更还需要确保集群状态、持久化数据和服务发现的连续性。迁移过程中主要面临三个技术难点节点IP变更导致kubelet与control plane通信中断持久化存储卷的访问路径失效集群内部服务发现机制如CoreDNS需要适配新网络环境2. 迁移方案设计与原理2.1 迁移策略选型经过评估我们确定了两种可行的迁移路径滚动迁移方案逐个节点修改网络配置并重启保持集群控制平面持续可用适合对可用性要求高的生产环境蓝绿迁移方案在新子网创建完整新集群通过etcd快照恢复集群状态适合允许短暂停机的测试环境最终选择滚动迁移方案因其具有以下优势业务中断时间可控单个节点影响约2分钟无需重新配置存储类和服务发现保持原有RBAC和网络策略配置2.2 网络架构适配设计新子网需要满足以下技术要求graph TD A[原集群] --|10.0.1.0/24| B[旧网关] C[新集群] --|172.16.2.0/24| D[新网关] B -- E[共享NAT] D -- E实际实施时采用VPC对等连接替代NAT确保迁移期间新旧子网双向互通保留原安全组规则维持原有的网络延迟特性3. 详细迁移操作步骤3.1 预迁移检查清单执行以下命令检查集群健康状态kubectl get nodes -o wide kubectl get pods -A -o wide rke2 etcd-snapshot save --name pre-migration关键检查点确认所有节点处于Ready状态记录所有Pod的当前IP分配验证etcd快照完整性rke2 etcd-snapshot list3.2 节点迁移实操流程以worker节点迁移为例驱逐节点负载kubectl drain node-name --ignore-daemonsets --delete-emptydir-data修改节点网络配置以Ubuntu为例sudo nano /etc/netplan/50-cloud-init.yaml修改内容示例network: version: 2 ethernets: eth0: addresses: [172.16.2.15/24] gateway4: 172.16.2.1 nameservers: addresses: [8.8.8.8]应用网络变更sudo netplan apply更新RKE2配置sudo nano /etc/rancher/rke2/config.yaml添加node-ip: 172.16.2.15 node-external-ip: 172.16.2.15重启RKE2服务sudo systemctl restart rke2-agent恢复节点调度kubectl uncordon node-name3.3 控制平面迁移特别处理对于control plane节点额外需要更新etcd advertise地址etcd: extra-args: advertise-client-urls: https://172.16.2.10:2379 listen-client-urls: https://172.16.2.10:2379修改kube-apiserver证书SANsudo openssl x509 -in /var/lib/rancher/rke2/server/tls/server-ca.crt -text4. 关键组件迁移验证4.1 网络连通性测试执行分层验证节点层ping 172.16.2.1 traceroute 8.8.8.8服务层kubectl get svc curl -k https://new-cluster-ip:6443Pod层kubectl exec -it pod-name -- ping other-pod-ip4.2 存储系统适配针对常见存储方案的处理存储类型适配方案Local PV保持原hostPath不变NFS更新server地址为新子网IPCeph RBD调整monitor endpoints配置Longhorn重建复制卷到新节点例如NFS存储更新命令kubectl patch pv pv-name -p {spec:{nfs:{server:172.16.2.100}}}5. 问题排查与经验总结5.1 典型故障处理问题1节点迁移后处于NotReady状态检查项journalctl -u rke2-agent -b --no-pager | grep error常见原因证书SAN不匹配网络策略阻止通信问题2CoreDNS解析失败修复步骤kubectl -n kube-system edit configmap coredns更新forward插件指向新子网的DNS服务器5.2 性能优化建议迁移后建议执行网络基准测试kubectl apply -f https://k8s.io/examples/admin/network/network-utils.yaml kubectl exec -it network-utils -- iperf3 -c target-pod-ip调整kubelet参数kubelet-arg: - node-status-update-frequency10s5.3 后续维护建议更新监控系统配置修改Prometheus的target配置调整Grafana数据源URL文档更新清单网络拓扑图应急回滚流程新子网ACL规则说明经过实际验证整个迁移过程平均每个节点耗时约7分钟业务中断时间控制在秒级。关键是要确保新旧子网间路由正确配置证书SAN提前规划存储系统预适配最后分享一个实用技巧在迁移前使用kubectl的dry-run功能验证资源定义kubectl drain node --dry-runclient
1. 迁移背景与核心挑战在混合云架构中RKE2/K3s集群经常需要根据业务需求进行网络结构调整。最近我在客户现场遇到一个典型场景由于公司网络架构升级需要将运行在本地数据中心的RKE2下游集群整体迁移到公有云的新子网中。这种迁移不仅涉及IP地址变更还需要确保集群状态、持久化数据和服务发现的连续性。迁移过程中主要面临三个技术难点节点IP变更导致kubelet与control plane通信中断持久化存储卷的访问路径失效集群内部服务发现机制如CoreDNS需要适配新网络环境2. 迁移方案设计与原理2.1 迁移策略选型经过评估我们确定了两种可行的迁移路径滚动迁移方案逐个节点修改网络配置并重启保持集群控制平面持续可用适合对可用性要求高的生产环境蓝绿迁移方案在新子网创建完整新集群通过etcd快照恢复集群状态适合允许短暂停机的测试环境最终选择滚动迁移方案因其具有以下优势业务中断时间可控单个节点影响约2分钟无需重新配置存储类和服务发现保持原有RBAC和网络策略配置2.2 网络架构适配设计新子网需要满足以下技术要求graph TD A[原集群] --|10.0.1.0/24| B[旧网关] C[新集群] --|172.16.2.0/24| D[新网关] B -- E[共享NAT] D -- E实际实施时采用VPC对等连接替代NAT确保迁移期间新旧子网双向互通保留原安全组规则维持原有的网络延迟特性3. 详细迁移操作步骤3.1 预迁移检查清单执行以下命令检查集群健康状态kubectl get nodes -o wide kubectl get pods -A -o wide rke2 etcd-snapshot save --name pre-migration关键检查点确认所有节点处于Ready状态记录所有Pod的当前IP分配验证etcd快照完整性rke2 etcd-snapshot list3.2 节点迁移实操流程以worker节点迁移为例驱逐节点负载kubectl drain node-name --ignore-daemonsets --delete-emptydir-data修改节点网络配置以Ubuntu为例sudo nano /etc/netplan/50-cloud-init.yaml修改内容示例network: version: 2 ethernets: eth0: addresses: [172.16.2.15/24] gateway4: 172.16.2.1 nameservers: addresses: [8.8.8.8]应用网络变更sudo netplan apply更新RKE2配置sudo nano /etc/rancher/rke2/config.yaml添加node-ip: 172.16.2.15 node-external-ip: 172.16.2.15重启RKE2服务sudo systemctl restart rke2-agent恢复节点调度kubectl uncordon node-name3.3 控制平面迁移特别处理对于control plane节点额外需要更新etcd advertise地址etcd: extra-args: advertise-client-urls: https://172.16.2.10:2379 listen-client-urls: https://172.16.2.10:2379修改kube-apiserver证书SANsudo openssl x509 -in /var/lib/rancher/rke2/server/tls/server-ca.crt -text4. 关键组件迁移验证4.1 网络连通性测试执行分层验证节点层ping 172.16.2.1 traceroute 8.8.8.8服务层kubectl get svc curl -k https://new-cluster-ip:6443Pod层kubectl exec -it pod-name -- ping other-pod-ip4.2 存储系统适配针对常见存储方案的处理存储类型适配方案Local PV保持原hostPath不变NFS更新server地址为新子网IPCeph RBD调整monitor endpoints配置Longhorn重建复制卷到新节点例如NFS存储更新命令kubectl patch pv pv-name -p {spec:{nfs:{server:172.16.2.100}}}5. 问题排查与经验总结5.1 典型故障处理问题1节点迁移后处于NotReady状态检查项journalctl -u rke2-agent -b --no-pager | grep error常见原因证书SAN不匹配网络策略阻止通信问题2CoreDNS解析失败修复步骤kubectl -n kube-system edit configmap coredns更新forward插件指向新子网的DNS服务器5.2 性能优化建议迁移后建议执行网络基准测试kubectl apply -f https://k8s.io/examples/admin/network/network-utils.yaml kubectl exec -it network-utils -- iperf3 -c target-pod-ip调整kubelet参数kubelet-arg: - node-status-update-frequency10s5.3 后续维护建议更新监控系统配置修改Prometheus的target配置调整Grafana数据源URL文档更新清单网络拓扑图应急回滚流程新子网ACL规则说明经过实际验证整个迁移过程平均每个节点耗时约7分钟业务中断时间控制在秒级。关键是要确保新旧子网间路由正确配置证书SAN提前规划存储系统预适配最后分享一个实用技巧在迁移前使用kubectl的dry-run功能验证资源定义kubectl drain node --dry-runclient
