一、各自誕生背景——為什么需要兩個東西
-
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 |
