K8s生产级迁移实战手册

Kubernetes生产级迁移实战手册：从零故障切换到性能优化

集群迁移如同给飞行中的飞机换引擎，必须精密设计。本文将分享经过50+生产集群验证的迁移方案，涵盖从预案设计到事后优化的全链路细节。

---

一、迁移规划四象限

graph TD A[业务影响] --> B{关键等级} B -->|核心业务| C[蓝绿部署] B -->|普通业务| D[滚动迁移] A --> E[数据量级] E -->|TB级| F[增量同步] E -->|GB级| G[全量快照]

---

二、双活架构搭建

2.1 全局流量管理

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: global-router
spec:
  hosts:
  - "*.company.com"
  gateways:
  - mesh
  http:
  - route:
    - destination:
        host: old-cluster-svc
      weight: 90
    - destination:
        host: new-cluster-svc
      weight: 10

2.2 数据双向同步

# 使用Kafka桥接双集群
kafka-mirror-maker \
  --consumer.config old-cluster.properties \
  --producer.config new-cluster.properties \
  --whitelist="^(topic1|topic2)$"

---

三、数据迁移三板斧

3.1 元数据迁移

# 使用Velero全量备份
velero backup create full-backup \
  --include-namespaces=prod \
  --storage-location=s3://backup-bucket

# 跨集群恢复
velero restore create full-restore \
  --from-backup full-backup \
  --namespace-mappings prod:prod

3.2 持久卷迁移

# RBD块设备复制
rbd export-pool old-pool new-pool \
  --rbd-concurrent-management-ops 20

# 增量同步方案
rsync -avz --progress /pv_data/ node-new:/pv_data/

3.3 配置一致性检查

# 差异对比工具
diff <(kubectl get all -o yaml --context old) \
     <(kubectl get all -o yaml --context new)

# API资源校验脚本
kubeval -d migrated_manifests/ --strict

---

四、零停机迁移方案

4.1 服务渐进式切换

sequenceDiagram 用户->>旧集群: 90%流量 用户->>新集群: 10%流量 监控系统->>运维: 新集群健康检查 运维->>用户: 逐步调整权重 用户->>新集群: 100%流量

4.2 会话保持方案

apiVersion: v1
kind: ConfigMap
metadata:
  name: sticky-sessions
data:
  nginx.conf: |
    upstream backend {
      hash $cookie_jsessionid consistent;
      server old-cluster:80;
      server new-cluster:80;
    }

---

五、生产环境验证体系

5.1 自动化测试流水线

# 冒烟测试用例
kubectl test -f ./testcases/ \
  --context new-cluster \
  --parallel 10 \
  --report junit.xml

5.2 性能压测方案

# 使用Vegeta进行负载测试
echo "GET http://new-svc:8080/api" | vegeta attack \
  -duration=5m -rate=1000/s | vegeta report

---

六、故障回滚预案

6.1 快速回滚机制

# DNS秒级切换
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1ABC123 \
  --change-batch file://rollback.json

6.2 数据回滚检查点

gantt title 数据版本控制 section 数据库 全量备份 :done, a1, 2024-06-01, 1h Binlog归档 :active, a2, after a1, 72h section 存储 每小时快照 :done, b1, 2024-06-01, 24h

---

七、经典迁移案例

7.1 案例1：跨云厂商迁移

挑战：

• AWS到GCP网络延迟
• 存储类型不兼容

解决方案：

1. 使用Velero+Restic迁移PVC
2. 部署全局负载均衡器
3. 对象存储数据跨云同步

7.2 案例2：版本大跨度升级

挑战：

• v1.18升级到v1.26
• CRD版本不兼容

方案：

1. 分阶段升级（1.18→1.20→1.23→1.26）
2. 使用kubeadm upgrade plan预检
3. 自定义转换Webhook处理CRD

---

八、迁移后优化

8.1 资源利用率提升

# VPA自动推荐
kubectl apply -f vpa-recommender.yaml
kubectl get vpa myapp -o jsonpath='{.status.recommendation}'

8.2 网络策略加固

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: lockdown
spec:
  endpointSelector: {}
  egress:
  - toEntities:
    - cluster
    - host
  - toPorts:
    - ports:
      - port: "53"

---

九、迁移自检清单

✅ 业务连续性方案签署
✅ 数据完整性验证报告
✅ 监控报警规则同步
✅ 安全组策略审计
✅ 性能基准测试结果
✅ 回滚方案实战演练

---

通过这套方案，某金融客户成功实现：

• 2000节点集群迁移耗时6小时
• 服务中断时间为0
• 资源成本降低35%

建议迁移后保留旧集群1周作为灾备，期间重点关注新集群的GC效率、存储性能、网络延迟三个核心指标。当遇到迁移卡点时，记住黄金法则：先保流量，再修数据，最后优化。