企业官网建设流程全解析

1. 迁移背景与核心挑战

在混合云架构中，RKE2/K3s集群经常需要根据业务需求进行网络结构调整。最近我在客户现场遇到一个典型场景：由于公司网络架构升级，需要将运行在本地数据中心的RKE2下游集群整体迁移到公有云的新子网中。这种迁移不仅涉及IP地址变更，还需要确保集群状态、持久化数据和服务发现的连续性。

迁移过程中主要面临三个技术难点：

• 节点IP变更导致kubelet与control plane通信中断
• 持久化存储卷的访问路径失效
• 集群内部服务发现机制（如CoreDNS）需要适配新网络环境

2. 迁移方案设计与原理

2.1 迁移策略选型

经过评估，我们确定了两种可行的迁移路径：

1. 滚动迁移方案：

   • 逐个节点修改网络配置并重启
   • 保持集群控制平面持续可用
   • 适合对可用性要求高的生产环境

2. 蓝绿迁移方案：

   • 在新子网创建完整新集群
   • 通过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

关键检查点：

1. 确认所有节点处于Ready状态
2. 记录所有Pod的当前IP分配
3. 验证etcd快照完整性：

   rke2 etcd-snapshot list

3.2 节点迁移实操流程

以worker节点迁移为例：

1. 驱逐节点负载：

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

2. 修改节点网络配置（以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]

3. 应用网络变更：

   sudo netplan apply

4. 更新RKE2配置：

   sudo nano /etc/rancher/rke2/config.yaml

   添加：

   node-ip: 172.16.2.15 node-external-ip: 172.16.2.15

5. 重启RKE2服务：

   sudo systemctl restart rke2-agent

6. 恢复节点调度：

   kubectl uncordon <node-name>

3.3 控制平面迁移特别处理

对于control plane节点，额外需要：

1. 更新etcd advertise地址：

   etcd: extra-args: advertise-client-urls: https://172.16.2.10:2379 listen-client-urls: https://172.16.2.10:2379

2. 修改kube-apiserver证书SAN：

   sudo openssl x509 -in /var/lib/rancher/rke2/server/tls/server-ca.crt -text

4. 关键组件迁移验证

4.1 网络连通性测试

执行分层验证：

1. 节点层：

   ping 172.16.2.1 traceroute 8.8.8.8

2. 服务层：

   kubectl get svc curl -k https://<new-cluster-ip>:6443

3. Pod层：

   kubectl exec -it <pod-name> -- ping <other-pod-ip>

4.2 存储系统适配

针对常见存储方案的处理：

例如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不匹配
  • 网络策略阻止通信

问题2：CoreDNS解析失败

• 修复步骤：

  kubectl -n kube-system edit configmap coredns

  更新forward插件指向新子网的DNS服务器

5.2 性能优化建议

迁移后建议执行：

1. 网络基准测试：

   kubectl apply -f https://k8s.io/examples/admin/network/network-utils.yaml kubectl exec -it network-utils -- iperf3 -c <target-pod-ip>

2. 调整kubelet参数：

   kubelet-arg: - "node-status-update-frequency=10s"

5.3 后续维护建议

1. 更新监控系统配置：

   • 修改Prometheus的target配置
   • 调整Grafana数据源URL

2. 文档更新清单：

   • 网络拓扑图
   • 应急回滚流程
   • 新子网ACL规则说明

经过实际验证，整个迁移过程平均每个节点耗时约7分钟，业务中断时间控制在秒级。关键是要确保：

• 新旧子网间路由正确配置
• 证书SAN提前规划
• 存储系统预适配

最后分享一个实用技巧：在迁移前使用kubectl的dry-run功能验证资源定义：

kubectl drain <node> --dry-run=client