Docker Compose 和 Kubernetes 有什么区别？
Compose 管单机上的多容器应用（简单 YAML、单机网络）；K8s 管跨主机集群的容器编排（扩缩容、自愈、滚动发布、服务发现）。小项目/单机用 Compose，生产集群用 K8s。本文全面对比。
一句话区别：Compose 编排一台主机上的多个容器，配置文件简单、上手即用，适合开发环境与小型部署；Kubernetes 编排一个集群——跨多主机调度、自动扩缩容、故障自愈、滚动发布、服务发现，相关能力需要配置对应控制器、指标与网络存储等依赖，复杂度与运维成本取决于部署。
全面对比
| 维度 | Docker Compose | Kubernetes |
|---|---|---|
| 管理范围 | 单台 Docker 主机 | 单节点或多节点集群；高可用需跨故障域设计 |
| 配置形式 | Compose YAML，可组合多个文件 | 多资源 YAML（Deployment/Service/Ingress…） |
| 扩缩容 | 手动 --scale |
声明副本数；HPA 需配置指标来源、目标与资源设置 |
| 故障自愈 | 重启策略 | 控制器自动重建、跨节点重调度 |
| 滚动发布/回滚 | 无内置 | 原生支持 |
| 服务发现/负载均衡 | 项目内 DNS | Service/Ingress/CoreDNS 完整体系 |
| 学习成本 | 半天 | 周级以上 |
| 运维成本 | 仍需管理主机、备份、升级与恢复 | 需要集群管理（或买托管服务） |
怎么选
用 Compose：本地开发环境、个人项目、小团队单机部署、边缘设备、demo/测试环境。
用 K8s：多副本高可用要求、流量弹性、多团队协作、需要通过额外流量治理或发布工具实现的金丝雀/蓝绿发布、多云/混合云环境管理。单个集群并不会自动完成跨云容灾。
中间地带：Docker Swarm（简单集群编排，但生态已明显向 K8s 收敛）、轻量 K8s 发行版 k3s（单机也能跑，向上兼容）。
迁移路径
Compose 文件不能保证等价迁移到 K8s：kompose convert 能把 compose 配置转成 K8s 清单草稿，仍需复核卷、网络、探针、资源与密钥等语义。很多团队的实际路径：Compose 开发联调 → K8s 测试/生产。
常见问题（FAQ）
Q：Compose 能用于生产吗？
A：可以（小规模、单机能扛的业务），但要有单机故障的心理准备与备份预案；Compose 本身也能运行多副本，但同一主机的故障域不变；需要跨主机调度与恢复时再评估 K8s。
Q：K8s 是不是太重了？
A：自建集群需要持续维护；托管 K8s 或 k3s 可简化部分管理，但仍需确认网络、存储、升级、备份及发行版组件差异，不能承诺固定比例的成本下降或全部功能默认具备。
Q：学了 Compose 的知识到 K8s 会浪费吗？
A：不会。服务、网络、卷、环境变量的心智模型一脉相承，K8s 只是把它们集群化、API 化。
