我们为什么决定把项目迁到 K8s

踱鸽&水晶蟹2023-01-152026-04-27

一、迁移前的现状

2022 年底，我们的部署方式是 Docker Compose，一套文件管着大概 12 个服务。

在早期，这套方式挺好用的——本地起环境方便，测试环境和生产环境的配置差异一目了然，出了问题 docker logs 一看就能定位。但随着服务数量增多，问题开始出现：

每次发布都需要登上服务器，手动 docker-compose pull 再 docker-compose up -d，几个服务要挨个操作，容易漏。一个服务挂了没有自愈机制，要人肉发现、手动重启。

最直接的痛：有一次一个内存泄漏的问题，订单服务每隔几个小时 OOM 重启一次，凌晨两点告警打过来，我爬起来上服务器 restart。这不是偶发的，差不多持续了一个月，直到问题修完。

能自动重启、能自动扩容、发布时不停服——这些需求越来越迫切。

真正让我下定决心要迁的，是一次大促前的部署演练。

我们做了一次压测，模拟高峰流量，发现有两个服务在大流量下响应变慢，需要加实例。手动扩容的流程是：登服务器 → 改 docker-compose.yml 的 replicas → 重启服务。整个过程我操作了大概 25 分钟，中间因为一个配置写错了还回滚了一次。

那一刻我很清楚：如果真的是大促当天，这 25 分钟是不可接受的。

我们认真评估过 Docker Swarm——上手简单，和 Docker Compose 的概念相近，迁移成本低。

但最后选了 K8s，核心理由有两个：

生态工具链更完善。 HPA 自动扩缩容、滚动发布、探针机制、Helm Charts——K8s 的周边工具已经相当成熟，很多问题都有标准解法。Swarm 在这方面要弱很多。

面向未来。 K8s 已经成为容器编排的事实标准，团队熟悉了之后，招聘、技术分享、和其他团队协作都会更顺畅。Swarm 的社区活跃度在下滑，长期来看是个风险。

反对意见主要集中在两点：

学习成本太高。 K8s 的概念体系比 Docker Compose 复杂得多——Pod、Deployment、Service、Ingress、ConfigMap、PVC……光把这些搞清楚就要花不少时间。有同学说：我们只是要解决部署问题，有必要引入这么多新东西吗？

现有方案也够用。 Docker Compose 跑了两年多，大问题没有，何必折腾？

我的处理方式：不争论，先做一个可运行的 Demo。花了一周时间，把一个无状态的服务迁到了本地搭的 K8s 集群上，做了一次滚动发布的演示，再把 HPA 配置好，当着大家的面手动打压，让扩容自动触发。

看到实际效果之后，大家的态度转变了很多。

迁移的决策是对的，但当时低估了几件事：

运维复杂度比预想高。 Docker Compose 出了问题，大多数情况下自己能解决。K8s 出了问题，有时候要花很长时间查日志、看事件、翻文档——特别是网络问题，调试成本明显更高。

DNS 和服务发现有坑。 这块在迁移过程中踩了不少坑，在技术学习篇有详细记录（见：[202307-从DockerCompose迁到K8s踩坑实录]）。

数据类服务不适合一开始就迁。 MySQL 和 Redis 我们最后是保留在 Docker Compose 上，没迁进 K8s。一开始有人提议一起迁，最后证明那个决定是对的——有状态服务的迁移复杂度远高于无状态服务。

做这个决策最重要的判断：K8s 的学习曲线是一次性的，越早投入，收益越早显现。拖着不迁，每次手动操作的时间成本会一直在。