K8es生产迁移

Kubernetes生产迁移实战指南：零停机搬家的核心策略

---

一、迁移的本质：不是复制粘贴，而是架构重塑

Kubernetes迁移不是简单的资源搬运，而是对现有架构的全面审视。生产迁移必须遵循三个核心原则：

1. 业务连续性：必须确保服务零感知
2. 数据完整性：状态类数据必须零丢失
3. 可回退性：任何阶段都能快速回滚

---

二、迁移全景图：6大关键阶段

graph TD A[环境分析] --> B[迁移方案设计] B --> C[数据备份] C --> D[预迁移演练] D --> E[正式迁移] E --> F[验证与监控] F --> G[旧环境清理]

---

三、生产迁移七步法（附真实案例）

1. 环境深度扫描（发现隐藏炸弹）

# 导出全集群资源配置（含CRD）
kubectl get all,secret,configmap,pvc,ingress --all-namespaces -o yaml > cluster-dump.yaml

# 检查存储类兼容性（跨云迁移核心）
kubectl get storageclass -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.provisioner}{"\n"}{end}'

典型问题：AWS EBS无法直接迁移到Azure Disk

2. 制定迁移策略（不同场景选择）

场景类型	适用工具	停机时间	复杂度
同版本跨集群	Velero	分钟级	★★☆☆☆
跨云迁移	Kubeadm + Rclone	小时级	★★★★☆
K8S大版本升级	kube-upgrade	需滚动重启	★★★☆☆

3. 数据迁移实战（有状态服务处理）

MySQL迁移示例：

# 1. 创建物理备份
mysqldump --single-transaction --master-data=2 -uroot -p dbname > backup.sql

# 2. 使用PVC克隆（CSI支持时）
kubectl create pvc new-pvc --from=pvc/old-pvc

禁忌：直接复制/var/lib/mysql目录可能导致文件锁残留

4. 网络拓扑适配（避免服务雪崩）

# 新集群Ingress测试配置（金丝雀发布模式）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"

5. 迁移执行（Velero生产级用法）

# 创建带快照的备份（需提前配置VolumeSnapshotLocation）
velero backup create prod-backup --include-namespaces=production --snapshot-volumes

# 跨集群恢复（保证storageclass映射正确）
velero restore create --from-backup prod-backup --preserve-nodeports --storage-class-mapping=old-storageclass:new-storageclass

避坑指南：使用--preserve-annotations=kubectl.kubernetes.io/last-applied-configuration保留原有配置

6. 流量切换验证（四层检查法）

1. DNS层：逐步修改TTL值
2. 负载均衡层：添加新集群后端
3. 应用层：对比新旧集群日志
4. 客户端层：抽样用户引流测试

7. 监控与回滚（必须建立熔断机制）

# 实时监控关键指标（Prometheus示例）
sum(rate(container_cpu_usage_seconds_total{cluster="new"}[5m])) / 
sum(kube_pod_container_resource_limits{cluster="new", resource="cpu"}) > 0.8

熔断条件：当任一核心指标超过阈值立即回滚

---

四、生产级迁移工具链

工具类型	推荐工具	适用场景	注意事项
全量迁移	Velero	跨集群迁移	需处理存储类映射
增量同步	Kasten K10	持续数据保护	商业软件成本
配置管理	Kustomize	多环境适配	避免硬编码IP
流量调度	Istio	细粒度控制	学习曲线陡峭
验证工具	Kube-bench	安全合规检查	CIS标准适配

---

五、五大经典故障场景复盘

案例1：时区配置丢失

• 现象：定时任务全部提前8小时
• 解决方案：在迁移工具中保留TZ环境变量

案例2：Secret解码失败

• 现象：新集群出现Invalid API Key
• 根因：base64编码字符集差异
• 修复：使用stringData字段显式声明

案例3：节点亲和性失效

• 现象：Pod堆积在部分节点
• 根因：新旧集群标签体系不同
• 预防：提前执行kubectl get nodes --show-labels对比

案例4：HPA自动缩放异常

• 现象：CPU指标无法触发扩容
• 根因：metrics-server版本不兼容
• 处理：统一监控组件版本

案例5：自定义调度器冲突

• 现象：Pod长期Pending
• 根因：新集群未部署调度插件
• 措施：建立插件白名单制度

---

六、迁移后优化清单

1. 资源回收：旧集群保留至少7天
2. 配置标准化：统一所有环境的Helm Chart版本
3. 文档更新：同步新版架构图到Confluence
4. 成本分析：对比迁移前后资源利用率
5. 复盘会议：产出改进Checklist

---

七、写给架构师的特别建议

1. 灰度迁移法则：按照「非核心业务 -> 核心业务 -> 有状态服务」顺序推进
2. 双活架构设计：迁移完成后保持双集群并行能力
3. 混沌工程验证：使用Chaos Mesh模拟网络分区
4. 法律合规检查：特别注意跨境数据存储合规性

---

实战箴言：成功的迁移不是终点，而是技术债务清理的开始。每次迁移都应成为推动架构优化的契机，而非简单的环境复制。