简单来说，Docker 关注的是“集装箱”本身（打包、运行），而 Kubernetes (K8s) 关注的是“货运调度” （在大规模集群中如何管理成千上万个集装箱）。
当你的业务规模从“单机作业”转向“分布式集群”时，单纯靠 Docker（或 Docker Compose）就会显得力不从心。
以下是 Docker 无法解决、必须请出 Kubernetes 的核心场景：
1. 跨机器的资源调度 (Resource Scheduling)
- Docker 的局限： Docker 通常运行在单台服务器上。如果你有 10 台服务器，你必须手动决定容器跑在哪一台，并手动去那台机器上执行命令。
- K8s 的方案： K8s 屏蔽了底层服务器的差异。你只需要告诉它：“我要运行 5 个 Nginx 副本”，K8s 会自动观察哪台机器 CPU/内存最空闲，然后把容器塞进去。
2. 自愈能力 (Self-healing)
- Docker 的局限： 如果单机上的容器崩溃了，Docker 可以重启它。但如果整台服务器宕机了，Docker 无能为力，你的服务就下线了。
- K8s 的方案： K8s 会持续监控节点状态。一旦发现 Node A 挂了，它会立即在 Node B 上启动新的容器来弥补缺失的副本，确保服务永不下线。
3. 自动化扩缩容 (Auto-scaling)
- Docker 的局限： 面对突发流量（如双 11 或抢购），你必须人工手动增加容器数量。
- K8s 的方案： K8s 可以根据 CPU 利用率或自定义指标，自动增加（Horizontal Pod Autoscaler）或减少容器数量。流量大时自动加机器，流量小时自动撤，省钱又省心。
4. 复杂的服务发现与负载均衡
- Docker 的局限： 当容器跨越机器部署时，它们之间的 IP 通信非常麻烦，传统的负载均衡器很难实时追踪不断变化的容器 IP。
- K8s 的方案： K8s 内置了 Service 概念，提供统一的入口 IP 和 DNS 名称。无论后端容器如何漂移、重启，前端访问地址永远不变，且自带内部负载均衡。
5. 滚动更新与回滚 (Rolling Updates)
- Docker 的局限： 更新镜像通常意味着先停掉旧容器，再起新容器，这期间会有服务中断（Downtime）。
- K8s 的方案： K8s 支持滚动更新，每次只替换一两个容器，确保始终有存活的容器在提供服务。如果发现新版本有 Bug，一个指令就能秒级回滚到上一个稳定版。
总结对比
| 维度 | Docker (单机/原生) | Kubernetes (集群管理) |
|---|---|---|
| 管理规模 | 适合少量容器 (1-20个) | 适合大规模集群 (成百上千个) |
| 高可用 | 容器挂了能重启，机器挂了没办法 | 机器挂了自动迁移容器，保障高可用 |
| 扩容方式 | 手动操作 | 自动根据负载伸缩 |
| 网络通信 | 跨主机通信配置复杂 | 内置强大的插件化网络方案 |
| 适用对象 | 开发环境、小微型应用 | 生产环境、微服务架构 |
一句话建议：
如果你只是想让程序在任何地方都能跑起来，Docker 就够了；如果你需要管理一个即便服务器炸了、流量爆了也能自动恢复并正常工作的生产系统，那你必须用 Kubernetes。
你想了解如何将现有的 Docker Compose 项目迁移到 Kubernetes 吗？
