Compose 与 K8s 怎么选
两者不是升级关系，而是规模不同的两种编排方式。Compose 描述“单机上跑哪几个容器”，用一份 YAML 就能管住依赖顺序、网络与卷；Kubernetes 描述“一个集群里如何调度、自愈与发布”，把节点故障、副本编排、滚动升级都交给控制平面。选型的关键不是功能强弱，而是节点数量、可用性要求与是否有人力长期维护控制平面。单机场景硬上 K8s，运维成本往往远大于收益。
基本信息
| Compose 定位 | 单机多容器编排，docker compose 即可运行，无需额外控制面 |
|---|---|
| K8s 定位 | 多节点集群编排，调度、自愈、发布、扩缩由控制平面完成 |
| Compose 学习成本 | 低，半天到一天可以上手常规用法 |
| K8s 学习成本 | 高，涉及网络插件、存储、权限、升级与容量规划 |
| 共存方式 | 小服务用 Compose，核心链路逐步迁到 K8s |
| 单机 K8s | 轻量发行版适合学习与验证，但不代表省掉运维成本 |
选型要问的问题
- 服务数量与节点数：单机 2 到 10 个服务通常 Compose 就够
- 可用性要求：节点故障时需要自动迁移与自愈，才轮到 K8s
- 发布方式：需要滚动升级与快速回滚，K8s 原生支持更省事
- 运维人力：没有专职维护者，K8s 集群的稳定性往往不如单机 Compose
- 状态服务占比：数据库等有状态组件多时，K8s 的存储与运维复杂度更高
- 交付节奏：团队规模小、迭代快时，简单方案能少犯低级错误
能力对照
| 维度 | Docker Compose | Kubernetes |
|---|---|---|
| 适用规模 | 单机 2 至 10 个服务 | 多节点集群、大量服务 |
| 调度自愈 | 仅进程级重启 | 调度、驱逐、自愈、亲和性 |
| 发布策略 | 重建为主，滚动需外部工具 | 滚动、回滚、自动扩缩原生支持 |
| 网络 | bridge 加端口发布 | CNI 加 Service 与 Ingress |
| 配置密钥 | env_file 与卷 | ConfigMap 与 Secret |
| 学习成本 | 低，半天上手 | 高，需要专职维护 |
判断参考
判断参考
单机部署 / 内部工具 / 开发环境 # 优先 Compose
多节点 / 高可用 / 弹性伸缩 / 复杂发布 # 才考虑 Kubernetes
单机却想上 K8s # 先问清控制平面由谁维护、故障时谁来兜底
已经有稳定 Compose 栈 # 不要一次性全量搬迁，按服务逐步迁移两者可以共存：小服务留 Compose，核心链路逐步迁到 K8s，迁移期间保留对照环境，出问题时有退路。
Kubernetes 的价值来自集群规模与自动化的组合，不是单看某个功能：规模不到时，多数收益体现不出来。