一、各自诞生背景——为什么需要两个东西
-
Docker（2013，Docker Inc.）
• 目的：解决“我的代码在你机器跑不起来”的经典环境问题。
• 做法：用 Linux 内核的 cgroup/namespace 做轻量隔离，把“应用 + 依赖”打成镜像，单机一条docker run就能起容器。
• 局限：单机玩具。一旦容器多了、机器多了，手动启停、网络互通、故障恢复、滚动升级全成了噩梦。 -
Kubernetes（2014，Google 内部 Borg 系统开源）
• 目的：让成千上万台机器像一台“逻辑超级机”来跑容器。
• 做法：
– 引入 Pod（最小调度单元）、Deployment、Service 等抽象；
– 用控制平面（API Server + Scheduler + Controller Manager + etcd）统一决策；
– kubelet 在每个节点上当“小管家”，真正落地创建/销毁容器。
→ 于是才有了“声明式 YAML → 自动扩缩、滚动升级、自愈、负载均衡”的生产级能力。
────────────────
二、功能定位——“造集装箱” vs “管整个港口”
| 维度 | Docker | Kubernetes |
|---|---|---|
| 设计目标 | 让单个容器能 build/ship/run | 让 N 个容器跨机集群自动编排 |
| 管理范围 | 一台主机 | 几十～几千台主机 |
| 核心对象 | image / container | Pod / Deployment / Service |
| 典型命令 | docker build docker run | kubectl apply -f xxx.yaml |
| 网络/存储 | 单机桥接、卷 | 跨主机 CNI、CSI 插件 |
| 自愈能力 | 无 | 容器挂了自动重启、节点挂了自动漂移 |
| 版本升级 | 手动 stop & run | 声明式滚动升级、回滚 |
| 适用场景 | 本地开发、CI 打镜像、小站点 | 微服务、生产环境、大规模集群 |
────────────────
三、运行时细节——K8s 到底还用不用 Docker？
-
2019 以前
kubelet 通过 dockershim 调用 Docker Engine → 容器跑起来。 -
2020.12（K8s 1.20）
dockershim 被标记弃用；K8s 官方说“Docker 作为高层工具链没问题，但运行时请用更轻量的 containerd 或 CRI-O”。 -
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 守护进程再无关系。
────────────────
四、实战选择建议
| 阶段/需求 | 推荐组合 |
|---|---|
| 个人开发、CI 打镜像 | Docker Desktop / Docker Engine |
| 单机多容器快速原型 | Docker Compose |
| 生产集群（<10 节点） | k3s + containerd |
| 生产集群（>10 节点） | 原生 Kubernetes + containerd/CRI-O |
| 团队不熟 K8s，业务又简单 | Docker Swarm 或云厂商托管 K8s |
