【K8s】解惑：K8s 与 Docker 的关系

目录引言一个绕不开的问题一句话说清K8s与Docker的关系澄清三个误解从命令的角度直观对比引言一个绕不开的问题在学习云原生技术的路上几乎每个人都会遇到这样一个困惑“有了 KubernetesK8s是不是就不用 Docker 了”“K8s 是不是要取代 Docker”搜索引擎里输入“K8s Docker”跳出来的结果常常让人更加迷惑。有人说“Docker 被淘汰了”有人说“K8s 离不开 Docker”还有人说“现在都用 containerd 了”……真相到底是什么一起来看看。一句话说清K8s与Docker的关系K8s不是取代Docker,是配合工作Docker是一个容器运行时工具它的核心能力是构建镜像、拉取镜像、启动/停止容器。我们可以把它理解为“集装箱生产商”和“本地搬运工”。K8s是一个容器编排平台它的核心能力是调度、扩缩容、服务发现、自动恢复。我们可以把它理解为“全球物流调度中心”。它们不是竞争关系而是不同层次的分工。Docker负责“干活”K8s负责“调度”。如果把容器技术比作一家餐厅的后厨那么 Docker 就是那位炒菜装盘的厨师——无论在小型场景还是大规模集群中它的本职工作从未改变构建镜像、启动容器、停止容器。而 K8s 扮演的是领班的角色。在小饭馆里领班的工作只能靠人工协调盯着哪个灶台空闲、决定哪道菜先做、厨师请假了还得自己顶上。但到了大型连锁餐厅面对几十个厨师同时工作K8s 这个“智能领班”就能自动发挥作用——它知道把新来的“做菜任务”也就是 Pod分配给最合适的厨师忙的时候自动多叫几个厨师来帮忙闲的时候让多余厨师休息省电甚至某个厨师突然“请假”节点宕机时它也能立刻安排其他人顶上确保菜品不断供。简单来说小饭馆靠一个人工领班勉强能管好一个厨师但大型连锁餐厅必须靠 K8s 这样的智能调度系统才能让几十个 Docker 厨师高效协作、井然有序。澄清三个误解误解一K8s 自带容器功能不需要 DockerK8s 本身不包含容器运行能力。它只是一个编排系统负责决定“在哪里运行什么容器”但真正执行“启动容器、停止容器”这个动作的是底层的容器运行时。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 在设计之初就考虑到了运行时的可替换性。它通过 容器运行时接口CRIContainer Runtime Interface 抽象了底层运行时。只要实现了 CRI 标准任何容器运行时都可以被 K8s 使用。Docker 只是其中之一。从命令的角度直观对比操作用 Docker 直接管理用 K8s 管理运行一个 Nginx 容器docker run nginx编写 Deployment YAMLkubectl apply -f扩展到 10 个实例手动执行 10 次docker run或docker-compose up --scale修改 replicas: 10K8s 自动完成容器挂了重启手动docker restart或加--restartalwaysK8s 自动检测并重新创建负载均衡需要额外配置 Nginx/HAProxyK8s Service 自带负载均衡滚动更新docker service updateSwarm 模式或手动逐个更新kubectl rollout自动滚动更新 一键回滚跨机器通信需要手动配置网络或使用 Swarm/ComposeK8s 内置跨节点网络开箱即用