Compose 用得好好的，要不要上 K8s：目录站在编排上的取舍

容器化之后下一步通常就是编排。看到别人都在写 YAML，很容易觉得不上 K8s 就是落后了。我自己的站到现在还是单机 Compose，加了一套健康检查和滚动重启脚本，跑得挺好。这中间不是懒，是算过账。

先说结论：编排解决的问题是"多台机器上的服务怎么调度"。如果你只有一台机器，它解决不了任何你真正遇到的问题。

图片来源：网络，版权归原作者所有，侵权请联系删除

什么信号说明该上了

信号	说明什么	不上行不行
服务跨了多台机器	需要统一的调度和服务发现	勉强，但运维成本陡增
要求单机故障自动恢复	需要控制器自动重建	可以靠脚本加守护，粗糙但能用
一天发布好几次，且不能中断	需要滚动更新和就绪探针	Compose 加脚本也能做
流量波动明显，要按负载扩缩	需要自动扩缩容	只能提前加机器，浪费

四个里命中两个以上，值得认真考虑。只命中一个，通常是能用更简单的办法解决的。

上 K8s 的真实代价

代价不在部署那天，在之后每一次排错。网络、存储、日志、监控、证书这五样在单机上是现成的，到了集群里都要重新选型和接线。一个 502 错误，单机上三十秒能定位，集群里可能要在 ingress、service、pod、探针之间绕一圈。

配置文件数量也是实打实的成本。一套简单的 Web 服务加定时任务，对应的 YAML 文件轻松上十个，还不包括 Helm 模板。团队里如果只有一两个人能看懂，这就是风险集中点。

还有个容易被忽略的：本地开发环境。容器也不是装上就完事，时区、日志、健康检查这几样在装进容器之后那篇里列过。上了集群之后，本地怎么跑起来、怎么连集群里的依赖，会消耗比预期多得多的时间。

中间档位不少

很多人以为只有 Compose 和 K8s 两个选项。其实中间还有几档：单机版的轻量发行版、Docker Swarm、云厂商的托管容器服务。托管服务是个不错的折中，你写 Compose 风格的配置，它负责调度和自愈，出了问题还能看控制台。

对目录站来说，这个折中特别合适——规模通常在一两台到四五台之间，用不上完整的集群能力，但又想要自动重启和滚动发布。

目录站自己的判断

导航目录站的流量结构有个特点：绝大部分请求是列表页和条目页，这些页面缓存命中率极高，真正打到应用的是一小部分。需要弹性的其实是三类东西：接口、搜索、后台任务队列。

所以最常见的合理架构是：页面层用缓存扛住，保持简单；把接口和任务队列单独拆出来，这部分上编排。整个站一起迁，收益和代价不成比例。

不管上不上，发布都不能断抓取

这条和上不上 K8s 无关。滚动更新的核心是就绪探针：新实例真正能服务了才接入流量，否则请求会打到还没起来的进程上，返回一堆 502。搜索引擎碰到连续几天的 5xx，会判定这个 URL 有问题，严重的会移出索引。

我的建议是先把"发布时前端零 5xx"这件事在单机上做到，再考虑编排。连单机发布都会抖的团队，上集群只会把问题放大，因为变量更多了。