01 - 只有 Docker 会遇到什么问题
在 Docker 教程里，我们学会了把应用打包成镜像、用 docker run 跑起来，还用 docker compose 在本地一键拉起一整套环境。很爽。
但当你的应用真正上线、开始扛真实流量、容器越来越多的时候，只靠 Docker 就会开始力不从心。这一章我们先把痛点说清楚——理解了痛点，你才知道 K8s 到底在解决什么。
场景：你的 AI 服务火了
假设你写了一个 AI 服务，打成了镜像，在一台云服务器上 docker run 跑了起来。一开始一切正常。然后问题接踵而至：
痛点 1：容器挂了，没人管
半夜三点，你的容器因为一个内存峰值崩了。
- 用户访问，全是 502。
- 你在睡觉，根本不知道。
- 等你早上起来发现，已经挂了 5 个小时。
你需要有个东西盯着容器，挂了立刻自动拉起一个新的。
痛点 2：一台机器不够用了
流量涨上来，一台服务器扛不住。你想多开几份服务分摊压力，于是：
- 手动登录第 2 台、第 3 台服务器
- 每台都
docker run一遍 - 再手动配一个负载均衡，把流量分给这几台
- 哪台的容器挂了，还得手动去对应机器上重启
机器一多，纯手工管理就变成灾难。
痛点 3：流量忽高忽低，扩缩容全靠手动
白天流量大要 10 个副本，半夜没人用 2 个就够。
- 手动加、手动减，累。
- 加晚了用户已经卡爆，减晚了白烧钱。
你需要一个东西能根据流量自动扩容、缩容。
痛点 4：更新发布像走钢丝
你改了代码要发新版本：
- 直接把旧容器停掉、起新的？中间有一段时间服务是断的。
- 新版本有 bug 怎么办？还得手忙脚乱地滚回旧版本。
你需要一个东西能平滑地滚动更新，出问题能一键回滚，全程用户无感。
痛点 5：几十个容器，跑在哪都不知道
服务拆成好几个，跨了好几台机器，几十个容器：
- 哪个容器在哪台机器上？
- 谁和谁能互相访问？
- 哪台机器资源快满了、哪台还很空？
光靠脑子和 Excel 记，根本管不过来。
问题的本质：从”养一只宠物”到”管一群牛”
有个经典比喻：
- 只有 Docker（手工管） 像养宠物：每台机器、每个容器你都取名字、精心照顾、坏了心疼地手动救。规模小还行，多了就崩溃。
- 需要的理想状态 像放牧一群牛：你不关心具体某一头，你只说”我要维持 100 头健康的牛”，有个牧场系统自动帮你补栏、体检、调度。
[配图：左边一个人手忙脚乱地同时照顾一堆小动物，焦头烂额；右边一个自动化牧场系统整齐地管理着一大群牛]
一句话总结痛点
当容器多起来、跨多台机器、要扛真实流量时，你需要一个”容器总指挥”来自动完成：
- 挂了自动拉起（自愈）
- 自动把容器安排到合适的机器上（调度）
- 流量变化自动扩缩容（弹性伸缩）
- 平滑更新、一键回滚（滚动更新）
- 自动负载均衡、服务发现
手动做这些事，会把人累死，还容易出错。 这，就是 K8s 登场的理由。
小结
- Docker 解决的是”单个容器怎么打包和运行”。
- 但容器一多、跨多机、扛真实流量后，会遇到：自愈、调度、扩缩容、滚动更新、服务管理等一堆难题。
- 手工管理这些，就像手动照顾一大群宠物，不现实。
- 我们需要一个”容器总指挥”来自动化这一切——下一章正式认识它：Kubernetes。
下一章 → 02 - K8s 是什么：容器界的”总指挥” ｜ 回到 README 目录