目录
- 1. 为什么 K8s 抛弃了 Docker？（历史转折点）
- 2. 现在的主流是什么？
- 3. 最关键的误区：那我以前写的 Dockerfile 废了吗？
- 总结：现在的标准分工模式
一句话回答：不是。
目前主流的 Kubernetes (K8s) 底层已经不再使用 Docker 作为容器运行时（Runtime）了。当前最主流、最默认的底层运行时是 containerd，其次是 CRI-O。
但这其中有一个非常容易混淆的“概念陷阱”。为了让你彻底清楚目前的行业现状，我们需要把“Docker”这个词拆开来看：
1. 为什么 K8s 抛弃了 Docker？（历史转折点）
在早期的 K8s 中，底层确实是调用 Docker 来运行 Pod 的。但是 Docker 本身是一个极其庞大、臃肿的软件（包含网络、存储、API、CLI构建工具等），而 K8s 其实只需要一个非常纯粹的功能：“帮我把容器跑起来”。
为了标准化，K8s 推出了 CRI（容器运行时接口）。
- 尴尬的是，Docker 自身并不支持 CRI 接口。
- 于是 K8s 官方只能自己写了一个叫
dockershim（垫片）的代码，用来把 CRI 指令翻译成 Docker 指令。这多出的一层转发，既消耗性能，又容易出 Bug。
决定性时刻：从 Kubernetes v1.24 版本（2022年发布） 开始，K8s 官方正式彻底删除了 dockershim。这意味着，原生的 K8s 已经无法直接调用 Docker Engine 来启动 Pod 了。
2. 现在的主流是什么？
目前各大云厂商（阿里云 ACK、腾讯云 TKE、AWS EKS、Google GKE等）以及企业自建的 K8s 集群，默认的运行时主要有两个：
- containerd（绝对的主流）：
有趣的是，containerd 其实是 Docker 公司当年从 Docker 引擎中剥离出来的核心组件，后来捐赠给了 CNCF 基金会。它极其轻量、稳定，且原生完美支持 K8s 的 CRI 接口。现在你部署 K8s，90% 以上底层跑的都是 containerd。 - CRI-O：
由 Red Hat（红帽）主导开发，专门为 K8s 定制的轻量级运行时，在 OpenShift 等红帽系生态中是默认选择。
3. 最关键的误区：那我以前写的 Dockerfile 废了吗？
绝对没有废。这是大家最容易误解的地方。
你需要区分 “容器运行时引擎” 和 “容器镜像格式”：
- 引擎换了：K8s 底层不再用 Docker 引擎去启动容器。
- 镜像没变：整个行业早就统一了 OCI（开放容器倡议） 标准。你用
docker build打包出来的镜像，是一个标准的 OCI 镜像。
结论就是：
不管是 containerd 还是 CRI-O，它们都能完美、100% 地兼容并运行你用 Docker 打包出来的镜像。
总结：现在的标准分工模式
- 对于开发人员 (Dev)：你的工作流没有任何变化。你依然在本地电脑上安装 Docker Desktop，写
Dockerfile，用docker build打包，用docker push推送到镜像仓库。 - 对于运维人员 (Ops) / K8s：K8s 节点上不再安装臃肿的 Docker Engine，而是只安装轻巧的
containerd。K8s 直接拉取你的 Docker 镜像，通过 containerd 运行在 Pod 里。
所以，虽然 K8s 里面不跑 Docker 引擎了，但整个生态依然是围绕着“Docker 镜像标准”在运转的。