去年上半年，我把自己负责的全部服务搬上了 Kubernetes，半年之后又原路搬了回来。这事儿在朋友圈里发了句吐槽，结果一堆同行私信问为什么。今天干脆写一篇长文，把这次“上上下下”的完整过程记录下来：当初为什么铁了心要上 K8s、迁移方案怎么设计的、后来被哪些问题折磨到崩溃、最终又是怎么一步步迁回轻量架构的。
先说结论，避免你看到最后才骂我：Kubernetes 是一套非常优秀的基础设施平台，但优秀不等于适合所有人。至少对我们这种十几个服务、五六个人、业务流量不算夸张的小团队来说，它带来的运维负担已经超过了收益。这篇文章不是劝退文，也不想吹 K8s 牛，就是一次“祛魅”记录。里面所有的资源数字、踩坑细节、判断标准，都是真实项目里遇到过的，希望能给正在纠结要不要上 K8s 的团队一点参考。
1. 当时为什么非搬不可
1.1 旧架构的痛点到底在哪
在搬上 Kubernetes 之前，我们的架构其实不算太差，但确实已经有一些让人难受的地方。所有服务跑在 6 台云服务器上，每台机器都装了 Docker，服务之间通过 Docker Compose 管理。业务大概分成这么几类：Nginx 入口和前端静态资源、后端业务服务、定时任务、Redis、MySQL、RabbitMQ，以及后来加的几张报表服务。总共十几个容器，环境分了 dev、staging、prod 三套。
在服务少的时候，Docker Compose 是真好用。配置写在一个 compose 文件里，docker compose up -d一把拉起，docker compose logs -f查看日志，整个团队用得很顺。但当服务数量慢慢堆上来，痛点开始变多：
- 每台机器上都是手工维护 compose 文件和
.env，没有任何配置中心，想改一个公共配置要登录五六台机器逐一改。 - 扩容靠复制环境，比如某台机器上的 Redis 顶不住了，就在另一台机器上再起一个，然后业务代码里加配置，手动做分片和主从。
- 发布流程是典型的“登录服务器、scp 新包、
docker compose up -d --build”，一个人发布的时候，其他人最好别动，冲突概率高。 - 没有健康检查和自愈能力，MySQL 一挂，下游服务整个雪崩，等监控告警发到群里已经过去好几分钟了。
- 服务发现靠写死的内网 IP，换一台机器部署，配置文件全都要跟着改。
这些问题在没有专门运维、后端要兼着管服务器的团队里非常普遍。当时我也觉得是架构落后、技术债积压，所以每天都在想“是不是应该上个大家口中更先进的东西”。
1.2 想用 Kubernetes 解决的核心诉求
在翻阅了《Kubernetes 权威指南》第 6 版、看了很多“企业项目实战”文章之后，我给自己列了一个“非上不可”的理由清单：
- 弹性伸缩。业务偶尔会有流量高峰，比如搞活动、做推广，之前每次都要半夜爬起来手动加机器，希望 K8s 能根据 CPU 或 QPS 自动扩容。
- 自愈能力。Pod 挂了自动重启，节点宕了自动把 Pod 调度到其他机器，数据库由云厂商托管、但业务实例想要更高可用。
- 环境一致性。dev、staging、prod 用同一套镜像、同一套编排模板，避免“在我这是好的”这种问题。
- 滚动发布和快速回滚。不再用“停旧起新”的方式发布，而是滚动更新，发挂了能一键回滚。
当时也认真了解了 Kubernetes 的核心概念，Pod、Deployment、Service、Ingress、ConfigMap、Secret，心里觉得自己已经懂了。尤其是看到“Kubernetes Dashboard 里怎么创建一个新的 Pod 作为新服务发布”这类问题，我还真去点过一遍，虽然生产环境后来证明根本不该这么操作，但当时这种学习的热情确实高涨，觉得这套东西虽然复杂，但完全是可掌控的。
1.3 选型时许下的一堆“乐观假设”
现在回头看，当初上 K8s 有一个很大问题：我的整个判断建立在几个没有验证过的假设上。
第一个假设是团队能长期投入学习成本。我们不是大公司，没有专职 SRE，后端开发要写业务、看日志、修 bug、做报表，K8s 只是“额外任务”。当时想的是“大家都学一学就行了”，但现实是：核心成员还能接受，其他同事看 YAML 就头疼，出了问题根本不敢动。
第二个假设是云托管 Kubernetes 可以帮我们解决大部分运维问题。这个想法不能说错，但云托管帮我们搞定了控制面的高可用、etcd 的备份，却搞不定我们自己的误配置和排障困难。K8s 的复杂不会消失，只会转移一部分到你头上。
第三个假设是自动扩容真能控制成本。后来发现，为了高可用，节点数根本不能太少，否则一台挂了连调度目标都没有；节点多了，日常闲置资源也多了。对于流量平稳的场景，这是纯亏。
第四个假设是监控、日志、存储、网关这些周边组件能“平滑集成”。实际上，每一类组件都是一个新的深坑，后面会细说。
说白了，当时上 Kubernetes 不是基于“现在真的需要”，而是基于“未来一定会需要，所以现在就应该上”。这种思路在技术选型里很危险，可我那时候不懂。
2. 迁移过程：一套看起来很美的方案
2.1 集群规划与资源评估
迁移的第一步是搭集群。因为当时团队对高可用有执念，我们直接买了 6 台同规格的云服务器，3 台 Master + 3 台 Worker，单机配置 8C16G。用云厂商的托管版按量付费创建，控制面组件没让我们手工搭，但 Worker 节点还是要自己加。
当时的资源评估方式现在想起来很幼稚。我把现有服务的 Requests 和 Limits 大概列了个表（参考下表），当时真的觉得这样算下来完全够用：
| 资源项 | 现有内存占用 | Requests 预留 | 预期增长系数 |
|---|---|---|---|
| 业务服务容器（约 12 个） | 22G | 26G | 1.2 |
| 中间件容器（Redis/MySQL/RabbitMQ） | 10G | 14G | 1.3 |
| 未来新增服务 | 无 | 6G | - |
| 监控和日志组件 | 无 | 4G | - |
我按 150% 的扩容系数去规划节点，算下来 3 台 Worker（每台 16G 内存，总共 48G）应该很富余。但实际上踩了个大坑：我把 Kubernetes 系统组件、Ingress Controller、存储插件、监控 Agent、日志采集器这些“跑在平台上但不是业务”的进程全给忘了。3 个 Master 节点每台要跑 kube-apiserver、etcd、kube-controller-manager、kube-scheduler、kube-proxy、CoreDNS、Dashboard、metrics-server，长期占用普遍在 2G~3G 内存和 1~2 核 CPU，etcd 还特别吃磁盘 IO。最后等于拿一台半 8C16G 的机器去供控制面。
注意：做 K8s 资源规划时，不能只算业务 Pod 的 “Requests”，一定要把控制面组件、监控 Agent、日志采集器、Ingress Controller、存储 CSI 插件这些“隐性资源”都算进去。小团队一开始别直接上 3 Master，先把 Worker 压满再说。
2.2 从 Docker Compose 到 Helm Chart 的改造
我们早期尝试过直接手写 YAML，但十几个服务的功能清单太杂，Deployment、Service、ConfigMap、Secret、PVC、HPA 全堆在一起，很难维护。后来统一改用 Helm Chart，用 values 区分环境，这才稍微理顺了。
这里有个经验：用工具从 Docker Compose 转 Helm Chart 很香，但别指望它能直接用。我们当时用 compose 转 helm 类工具批量生成 Chart，确实很快，但跑起来就发现一堆问题：环境变量引用不对、健康检查探针没有自动生成、端口暴露方式混乱、有状态服务的 volume 挂载需要手工修正。所以真正花时间的不是“自动转换”，而是把每个服务的依赖关系梳理清楚。比如有个后端服务依赖 Redis 的地址，在 Compose 里直接写服务名就行，在 K8s 里要走 Service DNS，Pod 名是随机后缀，不能用<container_name>直接访问。这种隐藏差异在迁移期反复折磨我们，日志里全是 DNS 解析不通的错误。
2.3 网关、存储与配置中心的落地
入口我们在迁移初期选的是 Nginx Ingress Controller，确实比之前自己维护的裸 Nginx 高级一些，像基于 Host/Path 的路由规则、注解配置、证书管理都集中在一个地方，看起来很香。但问题在于，Ingress 的兼容性、注解语法在不同版本之间有差异，网上抄的配置经常在当前版本不生效，要花很多时间试错。
配置管理这块，我们一开始直接把敏感信息放在 Secret 里，后来知道这样不安全，又接了 Sealed Secrets 做加密。但是整个加解密流程需要安装 CLI 工具、管理证书密钥、把加密后的 CRD 提交到 Git，团队里的前端写手和后端开发都嫌麻烦，最后变成了只有我一个人在维护配置。
存储部分踩的坑最大。MySQL、Redis、RabbitMQ 这些有状态服务，一开始都放在 K8s 集群内的 PVC 上，使用的还是本地硬盘的 StorageClass。Pod 被 reschedule 到另外一台节点后，旧数据并不会自动跟着走，除非用 Node 亲和性把 Pod 固定在原节点，否则重新调度等于数据丢了。后来我们换了云盘 CSI 插件，Pod 重建期间要等待云盘 attach/detach 完成，MySQL 这类需要快速恢复的服务经常卡得让人心慌。老实说，对没有专职基础设施团队的团队，有状态服务就不应该放进 K8s 集群里辛辛苦苦做存储编排，直接上云厂商托管版 RDS 是最省心的选择。
2.4 灰度发布和发布平台改造
在旧架构里，整个发布流程是一台机器登录上去敲命令。搬到 K8s 之后，我把 CI 流程改成：提交代码 -> 构建镜像并推送到镜像仓库 -> 更新仓库里 Helm Chart 的镜像 tag -> 执行helm upgrade --install。这套流程本身很顺，但对于团队其他成员，改动比较大，权限控制也复杂，普通开发根本没有 kubectl 权限，要让我来操作。
灰度发布我们也做了，用的是 Argo Rollouts。它确实支持按流量比例灰度、基于 Metrics 分析自动回滚，但配置复杂度极高，一套可以稳定用的灰度规则，要同时搞定 AnalysisTemplate、Rollout 配置、Service 切换，团队里没人愿意花精力去读懂这些 YAML。最后基本就是“新版本发上去 -> 手动看监控 -> 有问题再快速回滚”的流程，和用 Compose 的时候没什么区别。
另外有同事问过我，是不是能直接在 Kubernetes Dashboard 里创建 Pod 作为新服务发布。我只能说 Dashboard 适合开发和调试，查看资源状态、看日志确实方便，但在生产环境想发布一个新服务，应该走 GitOps 或 CI/CD 流程，维护好 Deployment/Helm Chart 再 apply，而不是在网页上点来点去。临时在一个 Pod 里执行命令甚至起个 shell 做排查可以，但把这个当作发布手段，后面维护成本会很大。
3. 搬回来之前，我到底被什么逼疯了
3.1 控制面和学习成本是隐性债务
很多人误以为 Kubernetes 的核心成本就是那几台服务器。真正贵的是学习曲线、故障排查消耗的时间、以及因为“没人敢动”导致的发布延迟。
我们团队最初只有两个核心后端对 K8s 比较熟，其他同事遇到问题第一反应是截图发群里，问“这个 Pod 一直 CrashLoopBackOff 是什么意思”“Ingress 配置了怎么访问不通”“Cert-manager 证书怎么不自动续期”。这些问题每一个都要有人去解释、去查。等这两个核心成员休假，其他人连kubectl drain都不敢执行。没有冗余的基础设施能力，K8s 就会变成团队的定时炸弹。
更让我压力大的是，K8s 的故障模式五花八门：etcd 空间不足、证书过期、节点 NotReady、CNI 插件出问题、CoreDNS 因资源限制被杀死、PVC 容量不足导致数据库写入失败。在传统 Docker 时代，我们真的没遇过这么多“平台层”故障。K8s 本身从设计上非常出色，但出了问题，你需要掌握的内功也是成倍增加的。
3.2 资源开销和成本控制失控
当时我们为了 HA，买了 6 台 8C16G 的云服务器。3 个 Master 长期空转，Work 资源算下来也没有比原来省。再加上为了观察集群状态，又部署了 Prometheus、Grafana、Loki 或 Elastic Stack 这种日志体系，这些监控和日志组件占用的资源比某些实际业务还多。
我在月底看账单的时候心态直接崩了：服务器成本比迁移前高了 40% 多，业务可用性却没有明显提升。云厂商的负载均衡 Sky 费用也在增加，每个 LoadBalancer 类型 Service 都要额外花钱，Ingress Controller 如果做成 LoadBalancer 又是一笔。原来用 Docker Compose 时，流量入口就是一台云服务器上的 Nginx，费用趋近于零。
注意：如果你在用 K8s 时发现“监控组件比业务组件吃资源”，说明你的规模可能还不到用 K8s 的时候。监控应该做减法，而不是做加法，先做到“出问题能看日志、看指标”即可。
3.3 存储、网络和中间件的细节灾难
存储和网络是 K8s 里最容易黑化人的地方。我们自建过一个 NFS 服务器当共享存储，跑起来之后发现 IO 延迟高得离谱，某个服务写入稍微频繁一点，整个 NFS 就变成瓶颈。后来换云盘 CSI，IO 是好了，但 Pod 重建和迁移要等很长的 attach/detach 时间，中间件一飘就非常痛苦。
网络方面，我们用 Calico，用的是 IPIP 模式，排查跨节点通信问题时要看的东西特别多。kubectl exec进 Pod 里 ping 别的 Pod 通不通、宿主机上抓包、看路由表、看 iptables 规则，这些操作对于没专门学过网络的人来说门槛很高。尤其当服务多了之后，网络策略（NetworkPolicy）一开始没上，后面想补，又怕误杀线上流量，就一直不敢开。结果整个集群的网络处于“能通但没人说得清怎么通”的状态。
3.4 排障链路太长，日常效率反而下降
老架构里服务挂了，我登录服务器，先docker ps看容器状态，再docker logs --tail 200看错误，快的话一分钟能定位。K8s 下日志分散在不同 Pod，要看更多东西，过程大概是：查看 Pod 状态、kubectl describe 看事件、kubectl logs 看业务日志、如果日志不够还要看上一个容器实例、再翻监控面板。不需要否认，这套流程专业且强大，但对多数业务问题来说是过度绕路。
发布流程也一样。以前 build 好新镜像，改 Compose 配置，docker compose up -d搞定。K8s 下要保证镜像仓库能访问、ConfigMap 是新的、Secret 存在、PVC 能绑定、Ingress 路径正确，任何一环配置错了，服务就起不来。而且报错信息对初学者不友好，一个镜像拉取失败会表现成各种奇怪的症状。
3.5 升级和版本维护的焦虑感
最后压垮我的是升级恐惧。Kubernetes 版本迭代非常快，每年多个小版本，跨版本升级要准备一堆工作：检查 API 兼容性、确认废弃字段、备份 etcd、先升控制面再升节点。每次升级都像一次小规模重构，而我们没有专职 SRE。尤其遇到 Ingress 从旧的 API 版本换到新的版本时，虽然网上有迁移文档，但真要全部改一轮 YAML，还是会出各种兼容性差错。花了周末时间升级，换来的却是周一新的兼容性问题，这对我来说已经完全不值了。
4. 搬回来的决策与落地过程
4.1 判断到底该不该“退”的标准
决定“撤退”之前，我做了个很直白的复盘。我给 K8s 带来的价值和它的成本分别打分，我不看“业界趋势”，只看“我们自己的真实收益”:
| 指标 | 上 K8s 前的状态 | 上 K8s 后半年 | 我的判断 |
|---|---|---|---|
| 弹性伸缩 | 手动扩容，偶尔滞后 | 自动伸缩，但没有大流量场景 | 收益约等于 0 |
| 自愈恢复 | 手动重启 | Pod 重启快，但节点故障还是得人工处理 | 收益有限 |
| 发布效率 | 每人会发 | 只有两个人能完整操作 | 效率下降 |
| 排障效率 | 日志一把梭 | 链路太长，平台问题影响业务判断 | 效率下降 |
| 资源成本 | 6 台 8C16G 以下 | 6 台 8C16G + 负载均衡 + 存储 | 成本上升 |
| 团队负担 | 全部能上手 | 学习曲线陡，依赖核心一两人 | 负担加重 |
先别急着说“你们太小了，K8s 才不适合”或者“K8s 本来就不是给你们用的”。这些批评都对，但当一个技术方案在团队里变成一种负担时，及时止损是一种理性选择。K8s 不会走，业界也不会倒退，但我们的业务要持续交付。决定要退之后，目标架构想得很清楚：回到轻量级 Docker Compose，但保留迁移过程中学到的好习惯，比如服务镜像化、滚动发布、配置与代码分离。
4.2 目标架构：轻量 Compose + 云负载均衡 + 对象存储
退回来不是“回到过去的老样子”，而是基于这几个月的经验做一个更优的轻量架构：
- 应用层：2 台高配服务器（比如 8C32G）跑 Docker Compose，所有无状态服务都容器化。
- 入口层：用云负载均衡接 Nginx，Nginx 做反向代理、SSL 终止、静态文件服务。
- 数据层：MySQL、Redis 等中间件直接用云厂商托管服务，不自己维护，省去备份和主从切换的心力。
- 存储层：静态资源、上传的文件统一走对象存储，挂了 CDN。
- 监控日志：不做全套监控平台，只做简单的 node_exporter + 容器状态检查 + 日志文件采集告警。
这套架构的逻辑是：能用云服务解决的绝不自建，能少一个组件就少一个组件。K8s 帮我们专业化了容器编排，但团队人力和业务规模支撑不起这套生态，云托管的数据服务和对象存储才是真正提升效率的地方。
4.3 迁回步骤：从集群解耦到数据回迁
迁回不能一把梭，我分成了五步走，每一步都有验证点：
先把无状态服务从集群内部迁回到 Compose。这个阶段保留 K8s 集群作为“备份环境”，业务切换后观察日志、监控是否有异常。因为无状态服务直接挂到新的入口，改动小，风险可控。
数据层迁移。集群内的 MySQL、Redis、RabbitMQ 先在云托管服务上创建实例，再通过数据同步、增量追平，最后切换连接串。这里要重点测试应用的“重连机制”，如果代码里连接池配置不对，切换瞬间可能连接全部报错。
入口切换。改变 DNS 解析，把流量从原来的 Ingress/负载均衡切到新的 Nginx 上。这个步骤最好在低峰期进行，保留旧入口至少几天，方便快速回切。
清理集群资源。确认所有服务稳定运行一周后，再逐个下线 Worker 节点和 Master 节点，释放按量付费资源。千万别刚切完就删集群，万一回滚还需要它。
完善新的部署脚本和告警。更新部署脚本、备份任务、日志路径，确保团队能在一个地方完成发布和排查。
迁移过程中我重新整理了一个示例版的docker-compose.yml，结构非常简单，但已经能满足我们整个业务的发布需求：
version: "3.8" services: nginx: image: nginx:1.25 restart: always ports: - "80:80" - "443:443" volumes: - ./nginx/conf.d:/etc/nginx/conf.d - ./static:/usr/share/nginx/html depends_on: - backend backend: image: registry.example.com/backend:2.4.0 restart: always env_file: - ./env/backend.env depends_on: - redis - mysql redis: image: redis:7-alpine restart: always command: redis-server --appendonly yes mysql: image: mysql:8.0 restart: always environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} volumes: - mysql-data:/var/lib/mysql volumes: mysql-data:4.4 现在的自动化程度和发布流程
不要以为 Compose 就意味着全部手工。我们只是把复杂度降到了团队能 handle 的层次。现在每个服务都有一个deploy目录，里面包含docker-compose.yml、.env、部署说明。发布流程是：
- 开发推代码到 git 仓库，CI 里构建并推送镜像到私有仓库。
- 服务器上通过一个脚本拉取最新镜像，做容器重建。用
docker compose up -d --no-deps完成滚动式替换（先起新容器，确认健康后删旧容器）。 - 数据库变更走专门的 migration 脚本，发布流程中按顺序执行。
- 日志由 docker 的 json-file 驱动，OS 层用 filebeat 或简单的 syslog 采集，出了问题直接在日志平台里查。
没上 K8s 的自动伸缩，但我们在需要时写了一个简单的扩容脚本：复制 Compose 里的某个服务实例，挂到 Nginx upstream 里，自动 reload。虽然不像 HPA 那样做到秒级弹性，但对我们这种峰值可预测的业务已经够用。
5. 这套折腾下来，我的真实总结
5.1 Kubernetes 究竟适合谁
经过这次折腾，我对 K8s 的认知从“牛所以要用”变成了“适合所以用”。现在如果让我给别人提建议，我会先问几个问题：
- 你们团队有专职 SRE 或专门的平台工程师吗？如果只有后端顺带管运维，K8s 会占掉大量研发精力。
- 服务数量达到几十个甚至上百个了吗？如果只有十几个，Compose 或轻量容器编排足够。
- 业务流量真的需要秒级弹性吗？如果活动高峰可以提前几小时扩容，HPA 的价值会大打折扣。
- 你们能否接受为了“高可用”多养几台 Master/控制面节点？成本账要提前算清楚。
不是说小团队就不能用 K8s，而是要用，就得把它当成一个长期投资项目。团队必须有足够的人力、意愿和预算去接住它带来的复杂度，否则技术先进性和实际收益之间会出现很大的断层。像我们这种没有追加人手的团队，硬上只会让业务交付变慢。
5.2 如果再来一次，我会先做这三件事
第一件事：先“云化”有状态服务。迁移 K8s 前，先把 MySQL、Redis、RabbitMQ、对象存储这些全部换成云托管服务。这样 Pod 才能真正做到无状态，无状态化的 K8s 才谈得上便利。把有状态服务塞进 K8s 里，等于把最复杂的一块留给了最不擅长的自己。
第二件事：先上 K3s 或单节点集群尝试，而不是一开始就 3 Master 高可用。对一个十几个服务的团队，K3s 安装简单、资源占用又低，能快速验证“这套编排到底适不适合我们”。直接上生产级高可用集群，是对控制面的过度投资。
第三件事：先把监控、日志、告警设计好。K8s 集群上线后，如果不先把日志链路和指标告警打通，遇到问题只能靠人肉 kubectl，那种无助感很痛。先有“能观测”的能力，再谈“自动调度”。
5.3 小团队可以先试试的轻量替代方案
如果你的团队也面临“要不要上 K8s”的选择，但又怕一步跨太大，有几个介于 Compose 和 K8s 之间的过渡方案可以试试：
- Docker Compose + 一个管理面板（类似 Portainer）加自动更新工具，这是目前我们用的方式。简单直接，团队上手快，适合无状态服务为主的小团队。
- K3s 或 MicroK8s。想体验 K8s API、想保留未来迁移可能的团队，可以从这里开始。安装和运维成本比完整版低得多。
- HashiCorp Nomad。如果你只是想要“调度”而不是“全平台”，Nomad 更简单，不管是学习成本还是运维成本都低很多。
- 云厂商的 Serverless 容器实例作为弹性补充。日常用传统架构，大促或突发流量时把部分无状态服务单独打成镜像跑弹性实例，不用时释放。
注意：不要为了“上 K8s”而上 K8s。如果你能说清楚“当前架构具体哪一天、哪个环节拖累了你”，那才有足够证据去换平台；如果只是觉得“别人都上了我不上落后”，大概率会重蹈我的覆辙。
5.4 这段经历给我留下的几个改变
这次折腾最后没有白费。虽然服务搬回来了，但原本那些“土办法”已经被我们升级了一遍：所有服务都镜象化，发布不再是登录机器乱敲命令；配置和代码分离，敏感信息用环境变量和密钥文件管理；日志不再散落在各个目录，统一采集便于检索；数据层全部托管，日常不再半夜爬起来做主从切换。
我用这些“K8s 教我们的最佳实践”武装了原本的 Compose 架构，得到的是一套团队能真正维护、成本可控、发布不慌的部署体系。那套 K8s 集群已经删了半年，我再没有因为“平台层故障”被半夜叫起来过。
如果以后我们的服务规模真的到了五十个、一百个，或者业务开始有明显且频繁的流量波动，我会再考虑回到 Kubernetes，而且这次一定会先招聘或培养一个专门的平台工程师，再上生产集群。最后一个很个人的体会：技术选型的成熟，不在于你用了多少“业界标准”，而在于你是否清楚每个复杂度背后的代价，并且愿意为它买单。我们这次算是把学费交明白了，希望读到这里的你，能少走一点弯路。
