目录

引言：一个绕不开的问题

一句话说清K8s与Docker的关系

澄清三个误解

从命令的角度，直观对比

---

引言：一个绕不开的问题

在学习云原生技术的路上，几乎每个人都会遇到这样一个困惑：

“有了 Kubernetes（K8s），是不是就不用 Docker 了？”

“K8s 是不是要取代 Docker？”

搜索引擎里输入“K8s Docker”，跳出来的结果常常让人更加迷惑。有人说“Docker 被淘汰了”，有人说“K8s 离不开 Docker”，还有人说“现在都用 containerd 了”……

真相到底是什么？一起来看看。

一句话说清K8s与Docker的关系

K8s不是取代Docker,是配合工作！

Docker是一个容器运行时工具，它的核心能力是构建镜像、拉取镜像、启动/停止容器。我们可以把它理解为“集装箱生产商”和“本地搬运工”。

K8s是一个容器编排平台，它的核心能力是调度、扩缩容、服务发现、自动恢复。我们可以把它理解为“全球物流调度中心”。

它们不是竞争关系，而是不同层次的分工。Docker负责“干活”，K8s负责“调度”。

如果把容器技术比作一家餐厅的后厨，那么 Docker 就是那位炒菜装盘的厨师——无论在小型场景还是大规模集群中，它的本职工作从未改变：构建镜像、启动容器、停止容器。而 K8s 扮演的是领班的角色。在小饭馆里，领班的工作只能靠人工协调：盯着哪个灶台空闲、决定哪道菜先做、厨师请假了还得自己顶上。但到了大型连锁餐厅，面对几十个厨师同时工作，K8s 这个“智能领班”就能自动发挥作用——它知道把新来的“做菜任务”（也就是 Pod）分配给最合适的厨师，忙的时候自动多叫几个厨师来帮忙，闲的时候让多余厨师休息省电，甚至某个厨师突然“请假”（节点宕机）时，它也能立刻安排其他人顶上，确保菜品不断供。简单来说：小饭馆靠一个人工领班勉强能管好一个厨师，但大型连锁餐厅必须靠 K8s 这样的智能调度系统，才能让几十个 Docker 厨师高效协作、井然有序。

澄清三个误解

误解一：K8s 自带容器功能，不需要 Docker

K8s 本身不包含容器运行能力。它只是一个编排系统，负责决定“在哪里运行什么容器”，但真正执行“启动容器、停止容器”这个动作的，是底层的容器运行时。

Docker 是容器运行时的一种，也是最流行的一种。K8s 需要调用 Docker（或其他运行时）来完成具体的容器操作。

误解二：K8s 要取代 Docker

这个误解的源头是 2020 年底的一个新闻：K8s 宣布在 v1.20 版本中弃用对 Docker 作为容器运行时的直接支持。

很多人看到“弃用”两个字就慌了，以为 K8s 要把 Docker 踢出局。

真相是，K8s 只是不再使用 Docker 作为默认的容器运行时，转而推荐使用 containerd（它本身就是从 Docker 项目中拆分出来的核心组件）。但 Docker 构建的镜像依然可以在 K8s 中完美运行，Docker 命令依然可以用来构建和测试镜像。

事实上，Docker 公司在 2017 年就将自己的容器编排工具 Swarm 模式内置进 Docker，但 Swarm 并没有打败 K8s。后来 Docker 公司甚至在自己的产品中原生支持 K8s，这说明两者是合作关系，而非对立关系。

误解三：K8s 只能配合 Docker 使用

K8s 在设计之初就考虑到了运行时的可替换性。它通过 容器运行时接口（CRI，Container Runtime Interface） 抽象了底层运行时。

只要实现了 CRI 标准，任何容器运行时都可以被 K8s 使用。Docker 只是其中之一。

从命令的角度，直观对比

操作	用 Docker 直接管理	用 K8s 管理
运行一个 Nginx 容器	docker run nginx	编写 Deployment YAML，kubectl apply -f
扩展到 10 个实例	手动执行 10 次 docker run，或 docker-compose up --scale	修改 replicas: 10，K8s 自动完成
容器挂了重启	手动 docker restart 或加 --restart=always	K8s 自动检测并重新创建
负载均衡	需要额外配置 Nginx/HAProxy	K8s Service 自带负载均衡
滚动更新	docker service update（Swarm 模式）或手动逐个更新	kubectl rollout，自动滚动更新 + 一键回滚
跨机器通信	需要手动配置网络或使用 Swarm/Compose	K8s 内置跨节点网络，开箱即用