一、各自诞生背景——为什么需要两个东西

1. Docker（2013，Docker Inc.）
   • 目的：解决“我的代码在你机器跑不起来”的经典环境问题。
   • 做法：用 Linux 内核的 cgroup/namespace 做轻量隔离，把“应用 + 依赖”打成镜像，单机一条 docker run 就能起容器。
   • 局限：单机玩具。一旦容器多了、机器多了，手动启停、网络互通、故障恢复、滚动升级全成了噩梦。

2. Kubernetes（2014，Google 内部 Borg 系统开源）
   • 目的：让成千上万台机器像一台“逻辑超级机”来跑容器。
   • 做法：
   – 引入 Pod（最小调度单元）、Deployment、Service 等抽象；
   – 用控制平面（API Server + Scheduler + Controller Manager + etcd）统一决策；
   – kubelet 在每个节点上当“小管家”，真正落地创建/销毁容器。
   → 于是才有了“声明式 YAML → 自动扩缩、滚动升级、自愈、负载均衡”的生产级能力。

────────────────
二、功能定位——“造集装箱” vs “管整个港口”

────────────────
三、运行时细节——K8s 到底还用不用 Docker？

1. 2019 以前
   kubelet 通过 dockershim 调用 Docker Engine → 容器跑起来。

2. 2020.12（K8s 1.20）
   dockershim 被标记弃用；K8s 官方说“Docker 作为高层工具链没问题，但运行时请用更轻量的 containerd 或 CRI-O”。

3. 2022.5（K8s 1.24）
   dockershim 代码彻底移除。现在 kubelet 通过 CRI（Container Runtime Interface）直接对接 containerd/CRI-O。
   • containerd：Docker 公司捐给 CNCF 的底层运行时，专注“拉镜像 → 起容器 → 杀容器”。
   • CRI-O：红帽主导，完全为 K8s 裁剪，体积更小。

一句话：
– 你仍然可以用 Docker 做镜像（docker build 兼容性最好）；
– 真正在 K8s 节点上跑容器时，默认换成了 containerd/CRI-O，与 Docker 守护进程再无关系。

────────────────
四、实战选择建议