Kubernetes 集群迁移从自建到托管平台的平滑切换基础设施不需要漂亮话。2024 年上半年我负责了一个 K8s 集群迁移项目从自建 K8s 集群基于 kubeadm 部署迁移到托管 K8s 平台阿里云 ACK。集群规模 80 个节点运行着 400 个 Pod涉及 50 个业务线。迁移过程持续了 3 个月期间做到业务无感知切换。这篇文章记录的是技术方案和踩坑过程。一、为什么要迁移自建集群的运维成本自建 K8s 集群跑了两年初期成本低但规模上来后运维成本指数级上升。成本 1控制平面维护我们有 3 个 master 节点etcd 集群独立部署。平均每个月有 1 次 etcd 性能问题大集群场景下 etcd 的读写延迟会升高需要人工介入优化。etcd 监控关键指标# 我们配置的 etcd 告警规则 groups: - name: etcd rules: - alert: EtcdHighCommitDurations expr: histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[10m])) 0.1 annotations: summary: etcd fsync 延迟过高可能影响集群稳定性成本 2版本升级风险从 K8s 1.20 升级到 1.24我们花了 2 个月准备。要审计所有已部署的 CRD 是否兼容新版本要测试 kubelet 升级后对业务 Pod 的影响还要考虑 CNI 和 CSI 插件的兼容性。最终升级当天还是出了事故Calico 的旧版本不支持 1.24 的新 API导致部分节点的 Pod 网络中断。成本 3灾备方案复杂自建集群的灾备需要自己设计。我们做了 etcd 定期备份 控制平面多可用区部署但应用数据的备份恢复方案一直不完善。2023 年有一次误删 namespace 操作恢复花了 6 小时。综合评估后技术委员会决定迁移到托管平台。核心考量是把控制平面的运维成本转嫁给云厂商团队聚焦在应用层优化。二、迁移方案双活架构平滑切换迁移的核心挑战是如何在不影响业务的情况下把 400 个 Pod 从旧集群迁移到新集群。我们设计的方案是双活架构 渐进式切换阶段 1新集群搭建 基础服务部署2 周先在 ACK 上搭建新集群网络方案选了 Terway阿里云自研的 CNI 插件和 VPC 集成更好。踩坑记录新建集群的 Pod CIDR 和旧集群不一样导致一部分写死 IP 的配置失效。之后我们规范了所有配置必须通过环境变量或 ConfigMap 注入不允许写死 IP。阶段 2双集群同步 灰度流量4 周这是最关键的阶段。我们在两个集群同时部署应用但通过 Ingress 控制流量分配。具体做法新集群部署和业务对等的应用实例配置中心同步配置用自定义同步脚本存储层做双向同步RDS 用 DTSRedis 用双写Ingress 层按百分比分流刚开始 5%无问题后逐步提升到 50%// 流量分配的逻辑简化版 func ShouldRouteToNewCluster(req *http.Request) bool { userID : extractUserID(req) // 按 userID 做一致性哈希保证同一用户始终路由到同一集群 hash : fnv32(userID) % 100 return hash currentPercentage // currentPercentage 从配置中心读取 }阶段 3全量切换 旧集群下线2 周灰度验证通过后把流量 100% 切到新集群旧集群保留 1 周作为应急回滚备份然后下线。三、关键技术点配置同步和存储双写技术点 1配置中心双写我们的配置中心用的是 Apollo旧集群和新集群各有一套 Apollo 实例。需要保证配置变更能实时同步。方案用 Apollo 的开放 API 写了一个同步工具监听旧集群的配置变更事件自动同步到新集群。type ConfigSyncer struct { sourceClient *apollo.Client targetClient *apollo.Client } func (s *ConfigSyncer) Sync() error { // 监听配置变更 events : s.sourceClient.Subscribe() for event : range events { // 过滤掉系统配置只同步业务配置 if strings.HasPrefix(event.Namespace, business.) { err : s.targetClient.Publish(apollo.Release{ Namespace: event.Namespace, Config: event.Config, }) if err ! nil { log.Errorf(同步配置失败: %v, err) // 写入重试队列 s.retryQueue.Push(event) } } } return nil }踩坑第一次同步时把 Apollo 的集群配置也同步过去了导致新集群的应用连到了旧集群的中间件。之后加了命名空间白名单只允许同步业务配置。技术点 2存储双写这是最复杂的部分。我们的存储层有 MySQL、Redis、MongoDB每种都有不同的双写方案。MySQL 双写用阿里云 DTS数据传输服务做单向同步旧集群的数据库 → 新集群的数据库。应用层不需要改代码。但有一个问题DTS 的同步延迟在秒级如果切流量时有未完成的事务可能导致数据不一致。解决方案流量切换前暂停所有写操作 30 秒等 DTS 同步延迟降到 0 后再切换。Redis 双写Redis 没有像 DTS 这样的托管同步工具我们在应用层做了双写type DualWriteRedis struct { oldClient *redis.Client newClient *redis.Client mode SyncMode // 渐进式先读旧写双再读新写新 } func (d *DualWriteRedis) Set(key string, value interface{}) error { // 写旧集群 err : d.oldClient.Set(ctx, key, value, 0).Err() if err ! nil { return err } // 写新集群异步不阻塞主流程 go func() { d.newClient.Set(ctx, key, value, 0) }() return nil }这个方案在切流量前跑了 2 周验证了新集群 Redis 的可用性和性能。四、风险控制三次演练 应急预案迁移这类操作光有方案不够必须演练。我们做了三次全流程演练每次都在测试环境完整跑一遍迁移流程。第三次演练发现了致命问题新集群的 Ingress 配置和旧集群有细微差异导致部分带路径重写的路由规则失效。修复后第四次演练通过才在线上执行。应急预案关键点5 分钟内能回滚保留旧集群 1 周Ingress 配置不删随时可以切回。数据不丢所有数据库在切换前做全量备份。监控全覆盖新旧集群同时接入监控切换过程中实时对比错误率、延迟、吞吐量。五、迁移效果运维成本降低 60%迁移完成 3 个月后我们统计了关键指标运维成本控制平面运维时间从每月 20 人时降到 2 人时K8s 版本升级频率从每年 1 次不敢升到每季度 1 次托管平台自动升级故障恢复时间从平均 2 小时降到 30 分钟托管平台有自动恢复能力性能对比Pod 启动时间从平均 15 秒降到 8 秒ACK 的调度性能更好网络延迟VPC 网络比自建机房的延迟低 20%etcd 性能不再需要关注托管平台负责成本变化计算资源成本上升 15%托管平台收费人力成本下降 60%综合成本下降 30%如果重来一次我会更早做迁移决策。自建集群在小规模时成本低但规模上来后托管平台的经济优势和技术优势都会显现。基础设施不需要漂亮话。选择适合自己团队规模和技术能力的方案比追逐新技术更重要。
)
