Docker还是Kubernetes：何时需要容器集群

Docker和Kubernetes负责不同层次的工作。Docker官方概览说明了镜像构建、分发和容器运行的能力。应用已经能在容器里运行，只证明交付方式可行；是否需要集群，还要看服务必须承受什么故障、如何扩容。

Kubernetes官方概览将其定位为管理容器化工作负载的平台，涵盖调度、故障恢复、受控发布和扩缩容，也明确指出它不负责构建应用。两者因此可以配合使用：团队用Docker制作镜像，再决定用单机部署还是交给Kubernetes管理。生产服务也不因贴上“生产”标签就必须进入集群。

Docker、Compose和Kubernetes各管哪一层

Docker镜像封装应用及其运行所需内容，容器则是镜像的运行实例。一个独立接口、定时任务或内部服务，可以先部署在一台主机上。此时团队仍需处理主机故障、服务重启、数据持久化和备份；容器把运行环境交付得更一致，并不替代这些工作。

当一套应用包含接口、数据库和缓存等多个服务时，Compose可把它们的配置和启动方式放在一起。Docker的Compose生产部署说明给出了单服务器部署、生产配置及重建容器的方法。单机Compose能让部署更有条理，但同机容器仍共享主机故障域；文档提到的Swarm集群是另一种部署安排，不能算作单机Compose已经具备跨主机容错。

Kubernetes管理的是由控制面和工作节点组成的集群。团队声明应用希望保持的副本和部署状态，控制组件再持续调整实际运行状态。它能在节点之间安排工作负载、替换失败实例，也能按配置逐步更新服务；这些能力只有与足够的节点、资源和正确的应用配置配合，才能转化为业务所需的可用性。

从单容器升级到集群，看四项门槛

节点数、故障域、扩容方式和维护责任应放在一起判断。下面的数量是用于比较方案的条件，不是Kubernetes的安装要求或适用于所有业务的采购标准：单节点也能运行Kubernetes，但无法消除该主机的故障点。

单容器：一台主机承载一个主要服务。若主机故障后的人工恢复时间符合业务要求，增加集群不会自动改善最紧迫的问题；先安排重启、监控和数据恢复更直接。
单机Compose：仍是一台主机，但有多个需要共同配置、启动和更新的服务。它适合本地开发、集成测试，也适合能够接受单主机故障域的生产服务；容量上限仍由这台主机决定。
跨主机部署：若要求一台工作节点失联后服务继续运行，至少要有另一台独立节点及足够的剩余容量承接负载。此时才有必要比较Kubernetes与其他跨主机方案，并明确谁维护控制面、网络、存储和发布流程。

这里的“两台”只是分开主机故障域的最低逻辑前提，并非高可用配置的充分条件。两台虚拟机若依赖同一台物理主机，仍可能同时失效；副本若集中在一个节点，增加节点也不会让现有副本自动分散。若要求承受可用区故障，还需核实节点和依赖服务是否真正跨区部署。

高可用的成本不止是增加工作节点

先区分进程退出、整台主机失联和更大范围的故障。进程退出后自动重启，可以在原主机上完成；主机失联时，同机的备用容器也会一起失联。要求服务继续响应，就要考虑副本放置、健康状态、入口流量，以及剩余节点是否装得下转移的工作负载。

Kubernetes生产环境指南把单机学习集群列为存在单点故障的环境，并要求高可用部署考虑控制面冗余、API服务负载均衡、足够的工作节点和随需求变化的容量。指南还涉及证书、etcd备份、访问控制及持续升级。团队若自建集群，这些都是明确的维护工作；采用托管服务可以转移部分控制面责任，仍须管理工作负载和自身依赖。

数据是另一条故障链。可替换的应用容器不等于可恢复的数据库：数据保存在哪里、备份能否恢复、故障后由谁切换，都需要单独设计。如果当前单机服务最难接受的是数据丢失，那么先补齐备份与恢复安排，比先改变编排平台更贴近风险本身。