迁移

背景与问题界定 某 SaaS 创业公司的早期技术栈完全构建在 Docker Compose 之上：一台 32C/128G 的裸机服务器运行着 20 多个容器，通过 depends_on 控制启动顺序，所有数据卷挂载在 NFS 共享存储上，服务发现依赖静态 links 和 network_mode: host。随着业务增长到日处理 100 万请求，这台"胖单体"服务器成了漂移的单点故障——一次 Docker daemon OOM 导致全站宕机 45 分钟。更糟糕的是，由于所有服务共用一个网络命名空间，端口冲突频发，版本升级无法滚动更新，回滚必须在 10 分钟内重装所有容器。Kubernetes 迁移势在必行，但需要一套渐进式、可回滚的迁移方案。 目标拆解与工程约束 零停机迁移：迁移过程中不能有超过 30 秒的服务中断窗口，用户请求必须在 Docker Compose 和 Kubernetes 两个"世界"之间平滑切换，支持新旧基础设施并行的灰度过渡期。 配置无感知适配：现有的 .env 文件、Compose 中的 environment 变量和 volumes 绑定挂载必须在 Kubernetes 中以等效语义运行，不能要求开发团队大量修改应用代码来适配新的运行环境。 有状态服务平滑迁移：MySQL、Redis 和 RabbitMQ 等有状态服务的数据不能丢失，需要在 Kubernetes 的 StatefulSet 中重建并同步数据，同时保证混合运行期间数据一致性。 成本可控性：从单机 Compose 到多节点 K8s 集群，基础设施成本预期会增加，必须通过合理的 namespace 规划、节点池划分和资源 requests/limits 策略控制溢出成本增长在 30% 以内。 方案设计 采用"绞杀者模式"（Strangler Fig Pattern）分阶段迁移。第一阶段是网络和数据平面的打通：在 Compose 服务器和 K8s 集群之间通过 WireGuard 组建扁平化 overlay 网络，利用 CoreDNS 的双向 DNS 解析让双方服务能互相发现。K8s 集群中的 Service 通过 externalIPs 或 metallb 暴露，Compose 服务通过 extra_hosts 指向 K8s Service IP。 ...