简介这是一份关于Docker与KubernetesK8S架构的PPT面向需要建立容器与虚拟化技术整体认知的开发、运维及架构人员也适合作为团队内部分享或技术培训的新手入门讲义。它从虚拟化概念切入帮助读者快速厘清全虚拟化、OS层虚拟化与Docker容器化之间的差异避免在庞杂工具链中迷失。压缩包内为单个pptx文件大小仅6.29MB内容系统梳理了Docker的核心概念与原理包括镜像、容器、仓库以及namespace资源隔离、cgroups资源限制和AUFS分层文件系统等关键机制并覆盖Docker镜像/容器常用操作。在此基础上进一步介绍Kubernetes集群管理、服务发现、负载均衡与故障自愈等高阶能力可帮助读者从底层隔离原理到编排调度形成完整链路。目前已有934人学习内容按虚拟化架构、Docker原理、基本操作、Kubernetes架构四个模块由浅入深既适合入门者按章节阅读也方便有经验者快速查阅与二次整理。1. 一张 PPT 装不下 DockerK8S 架构先分清谁在管容器、谁在管集群搜索「DockerK8S架构介绍PPT」的人多半不是缺模板而是被安排了「给团队讲一次容器与编排」的任务。你真正想要的是一套能讲明白、讲完别人敢动手的内容框架。反直觉的结论是Docker 和 K8S 是两个时代的问题——Docker 解决「单机上一个服务怎么打包分发」K8S 解决「几十个服务在多台机器上怎么不死、怎么扩」硬塞进一张图只会让听众记住一堆名词。这篇笔记按我给别人做技术分享的习惯把这两套架构拆成「组件—关系—最小复现—常见坑」四条线新人能照着画 PPT熟手能直接拿去对目录查漏。2. Docker 架构拆成三层看镜像分层、容器运行时与仓库分发2.1 镜像、容器、仓库三个角色的边界讲 Docker 架构最容易犯的错是把镜像和容器混着说。镜像是一个只读模板里面装着操作系统根文件系统、运行库和你写的应用代码容器是镜像启动后的一个进程有自己的文件系统视图、网络栈和命名空间。镜像可以拿来复制出无数个容器但容器里改的东西不会写回镜像。仓库负责存储和分发镜像。你可以把仓库类比成代码的 Git 远端镜像 tag 就是版本号。架构介绍里理想的分工是镜像在构建机产生推送docker push到仓库部署机从仓库拉取docker pull交给运行时启动成容器。这条链路必须在 PPT 里画成一条带箭头的横线顺序是「构建机 → 仓库 → 部署机」箭头方向反了后面所有容器网络、镜像命名的解释全乱。2.2 客户端-守护进程模式docker 命令到底发给谁Docker 采用的是典型的客户端-守护进程架构。你敲docker命令时真正干活的是后台进程dockerd。客户端只是一个把参数翻译成 REST 请求的壳通过一个 Unix socketLinux 下一般是/var/run/docker.sock跟守护进程说话。所有docker ps、docker run、docker build的行为本质都是往这个 socket 发 JSON 请求。为什么会设计成这种模式因为这样可以把构建、容器生命周期、网络配置、数据卷挂载全部收敛到一个可独立升级的守护进程里客户端可以换甚至可以用curl直接调用 API。你在 PPT 上只需要画两列左边是docker CLI右边是dockerd中间 socket下面垫一层containerd负责真正的容器运行。macOS 和 Windows 上跑 Docker Desktop 时这套守护进程跑在虚拟机里所以它依赖虚拟化支持——这也是后面避坑章节里最常见的启动失败源头。2.3 镜像分层是理解 Docker 架构的第一道坎镜像最大的架构特征是分层。Dockerfile 里每一个产生文件系统变化的指令RUN、COPY、ADD都会生成一个新层层与层之间只读叠加。拉镜像时是分层拉取启动容器时在最上面临时加一个可写层容器删除时这个可写层跟着删除。这个设计的价值在于复用与缓存基础镜像层存一份几个应用镜像都基于它磁盘占用不会翻倍构建时某层没变就直接命中缓存不需要重新执行命令。如果你在 PPT 里只放一张 Docker 架构图我建议放分层图因为它能一口气解释三个常见现象镜像下载为什么是「灰条」按层拉、为什么容器里改文件容器删了文件就没了、为什么docker build第二次特别快。把这些讲透听众对 Docker 的认知就不只是「一个装应用的盒子」。2.4 用三条命令观察这套架构理论讲再多不落到命令上听众回去还是会懵。我一般会在分享现场带着跑一遍最小组命令# 1. 看客户端与守护进程各自的版本确认是 C/S 架构 docker version # 2. 观察本机镜像列表里的分层信息能看到 REPOSITORY/TAG/IMAGE ID/SIZE docker images # 3. 查看某个镜像是由哪些镜像层叠出来的 docker history nginx:alpine第一条命令关键看下半部分Server是否存在。如果只有Client没有Server说明守护进程没启动或者当前用户访问不了 socket这也是「命令都认识、服务跑不起来」的直接原因。第三条命令可以观察到CREATED BY列里对应的 Dockerfile 指令能直观看到每一层对应一条构建指令。# 启动一个容器并给容器命名、把宿主机 8080 端口映射到容器 80 端口 docker run -d --name demo-web -p 8080:80 nginx:alpine # 确认容器确实在跑 docker ps # 查看容器的完整配置重点看 NetworkSettings 段 docker inspect demo-web-d是后台运行--name便于后续定位-p 8080:80是把容器 80 端口的流量引到宿主机 8080宿主机上访问http://localhost:8080就能看到页面。docker inspect输出的是一个超长的 JSON不用全看重点看NetworkSettings.IPAddress和Mounts能感受到容器有自己的 IP 和挂载路径。分享时只要说「容器有独立的文件系统、网络栈和进程空间」再让听众看这两段 JSON抽象概念立刻变成可触摸的东西。注意演示一定要先确保镜像能拉下来。很多现场翻车不是命令错是镜像仓库网络问题建议提前docker pull nginx:alpine别在现场等下载。3. K8S 架构不是一张集群图能讲完控制平面、节点平面与最小可用集群3.1 控制平面上四个组件的各自职责K8S 的架构在 PPT 里最容易被画成一堆框加一堆箭头看着专业讲起来忘词。我先给一个主线整个集群分成控制平面Control Plane和节点平面Node Plane。控制平面是大脑节点平面是手脚。大脑负责决策手脚负责执行。控制平面上有四个常驻组件。kube-apiserver是集群唯一的入口所有kubectl请求都打到它这里它做认证、授权和转发不干活只做登记。etcd是集群的数据库存储所有资源对象的状态比如「现在应该有几个副本」「哪个节点上有哪些 Pod」你的kubectl get看到的最终数据都来自这里。kube-scheduler负责决定一个新的 Pod 放在哪个节点上判断依据是节点资源余量、亲和性规则和污点容忍。kube-controller-manager是一组控制器集合其中最核心的是 ReplicaSet 控制器它不断对比「期望副本数」和「实际副本数」发现少了就补多了就删。这四个组件的关系是apiserver 先记录期望状态到 etcdscheduler 把 Pod 分配到合适节点节点上的 kubelet 执行完再通过 apiserver 把实际状态写回 etcdcontroller-manager 发现偏差就继续修正。你可以把这条路画成一条循环线比画出所有框更有效。3.2 节点平面kubelet、kube-proxy 与容器运行时节点平面上的组件要简单得多但容易被忽略。每个节点上常驻三个角色kubelet是控制平面派驻到节点的「监理」负责接收 Pod 定义然后调用容器运行时把容器拉起来并且持续上报节点和 Pod 状态kube-proxy负责维护网络规则让 Service 的虚拟 IP 能转发到对应的 Pod容器运行时本身通常是 containerd负责真正启动和停止容器。在架构分享里很多人会把 container runtime 画成 Docker这不算错但现在主流默认的运行时是 containerdDocker 只是它还保留的一层兼容壳。讲解时建议明确K8S 不直接调用 docker 命令而是通过 CRIContainer Runtime Interface协议与 containerd 通信kubelet 是两者之间的翻译层。能说出这个细节听众会立刻明白 K8S 为什么能跑非 Docker 的其他运行时。3.3 Pod、Deployment、Service三个对象必须讲清楚K8S 的架构里最核心的三个抽象对象是 Pod、Deployment、Service。Pod 是 K8S 的调度最小单元一个 Pod 里可以放一个或多个容器这些容器共享网络命名空间和存储卷。Pod 本身不持久它会被调度、删除、重建重建后 IP 会变。Deployment 是管理 Pod 副本的控制器你声明「我要 3 个副本」Deployment 负责维持这个数字。它内部通过 ReplicaSet 完成滚动更新和回滚。Service 则是一个稳定的访问入口它有一组标签选择器把流量送向后端对应的 Pod。即使后端 Pod 重建换了 IPService 的虚拟 IP 不变客户端仍然能访问。类比得好这一段听众就松口气Pod 相当于「一窝容器」的集合但 IP 会变Deployment 相当于保险保证窝的数量Service 相当于服务门牌号不管里面怎么换人门牌号不变。这样的类比比直接念官方定义好记得多。3.4 用 minikube 在本地复现一个最小集群讲 K8S 架构不落一次地等于白讲。本地最轻量的复现方式是 minikube它能在 Docker 里再起一个单节点集群适合开发机和教学演示。# 用 docker 驱动在本地启动一个单节点集群分配 2 核 2G 内存 minikube start --driverdocker --cpus2 --memory2048 # 确认节点状态Ready 表示控制平面和节点平面连通 kubectl get nodes -o wide # 查看集群里的系统组件能看到 kube-system 命名空间下的核心 Pod kubectl get pods -n kube-system--driverdocker表示让 minikube 在 Docker 容器里创建一个 VM 角色不需要安装 VirtualBox--cpus和--memory按笔记本实际资源调整低于 2G 内存很容易起不来。第一次启动会拉取一堆集群镜像耗时和网络直接相关建议提前minikube start一次预热。kubectl get pods -n kube-system能看到 etcd、apiserver、scheduler、controller-manager 这些组件的容器版本配合前面讲的控制平面组件听众能对照真实对象看到每个组件以 Pod 形态存在。等集群就绪后部署一个最简应用# 创建 deployment跑 2 个 nginx 副本 kubectl create deployment demo --imagenginx:alpine --replicas2 # 扩容到 3 个副本观察期望状态和实际状态 kubectl scale deployment demo --replicas3 # 暴露为 Service端口 8080 转发到 80 kubectl expose deployment demo --port8080 --target-port80这里有一个很关键的现场演示点扩容后立刻执行kubectl get pods -o wide会看到新 Pod 的 IP 和所在节点。如果内存不够新 Pod 会一直 Pending调度器的判断逻辑就现场展示出来了。凡是讲到这里还能顺手补一句「scheduler 是根据节点资源余量来做决定的Pending 说明它找不到合适节点」这次分享基本就稳了。4. 把架构翻译成 PPT目录顺序、一张图套路与五个必答问题4.1 先回答五个必答问题再决定讲什么架构 PPT 失败通常不是因为不专业而是讲了一堆组件名却没回答听众心里的五个问题容器是什么和虚拟机有什么区别镜像怎么构建和分发多台机器跑容器谁负责调度服务挂了怎么办请求怎么找到 Pod我自己要不要上 K8S。这五个问题必须在 PPT 里有明确对应页。推荐处理方式第一段用十分钟把 Docker 架构讲透回答前两个第二段用十五分钟讲 K8S 组件和数据流回答三和四最后留五分钟讲「K8S 的适用边界」回答五。很多人把第五题忽略结果听众回去之后立刻上生产环境然后遇到一堆坑。4.2 页序建议从单机部署的痛点讲到编排价值我一般推荐的页序是 20 页左右按「问题—方案—原理—实操—边界」推进而不是按「Docker 介绍—K8S 介绍」平铺。下表可以直接用来做目录页码段内容时长建议1-2单机部署的痛点一个服务升级要停机、环境不一致、依赖冲突3 分钟3-6容器与镜像文件系统、进程隔离、镜像分层与仓库8 分钟7-9Docker 架构与命令演示CLI 与守护进程run/pull/inspect8 分钟10-12多机部署的新问题服务发现、故障恢复、弹性伸缩5 分钟13-16K8S 架构控制平面、节点平面、Pod/Deployment/Service12 分钟17-20适用边界与演示什么时候不该上 K8S一次完整部署8 分钟这个顺序的核心逻辑是「先制造冲突再给方案」。如果用户没有先看到单机部署的痛点直接讲 K8S 组件他会觉得这是给自己加麻烦而不是解决麻烦。4.3 一张架构图的画法一条主链路而不是网状拓扑架构图是最容易翻车的地方。很多 PPT 把 Docker 守护进程、镜像仓库、K8S 控制平面、etcd 画成密密麻麻的网状关系听众拍完照就再也不看了。我的原则是每张图只表达一条主链路。Docker 的图只需要画一行docker CLI → socket → dockerd → containerd → 容器下面再画一条构建机 → 仓库 → 部署机的横线。K8S 的图画两条一条是用户视角kubectl → apiserver → etcd/scheduler/controller-manager → kubelet → 容器运行时另一条是数据视角Service → Pod。图上一旦超过三条横向链路就拆成两张图。一张图讲一个动作比一个动作塞一张图更合适。4.4 把 Docker 和 K8S 概念放进同一张对照表结尾处放一张 Docker 与 K8S 的概念对照表能帮听众快速把旧知识迁移到新概念上。功能诉求Docker 里的对应物K8S 里的对应物启动一个容器docker runkubectl create deployment管理多个容器docker-compose.ymlDeployment Service YAML网络访问入口docker network、端口映射Service、Ingress健康检查HEALTHCHECK指令livenessProbe / readinessProbe扩缩容手动开多容器kubectl scale deployment --replicasN画完这张表再补一句Compose 管的是「一台机器上的多个容器」K8S 管的是「一个集群里的多个节点」两者不是升级关系而是两种规模下的不同工具。这句话能避免听众回去之后用 K8S 跑单机应用也能避免他们用 Compose 硬撑几十个节点。5. 从 PPT 到可复现Docker 与 k8s 安装部署的路线图与避坑实录5.1 先选路线本地演示用 minikube服务器部署用 kubeadm架构分享通常只做演示不走生产部署。本地演示最省心的是 Docker Desktop 加 minikubeWindows 和 macOS 上直接装官方包即可Linux 桌面环境也一样。服务器上要真实建集群常见做法是用 kubeadm 三个步骤kubeadm init初始化控制平面、kubeadm join让节点加入、安装 CNI 网络插件。两条路线不要混。如果你只是做 PPT 演示贸然上 kubeadm 会在网络、证书、镜像三个环节卡几个小时不值当。5.2 踩坑记录一docker desktop 启动失败虚拟化支持没开现象Windows 上点击 Docker Desktop 后弹窗提示docker desktop failed to start because virtualisation support wasnt detected守护进程永远起不来。原因Docker Desktop 在 Windows 上依赖 Hyper-V 或 WSL2 后端BIOS 里的虚拟化扩展VT-x/AMD-V没开启或 Windows 功能里没有启用「虚拟机平台」和 WSL。解决先重启进 BIOS 打开虚拟化开关再在「控制面板 → 程序 → 启用或关闭 Windows 功能」里勾选「虚拟机平台」和「适用于 Linux 的 Windows 子系统」。如果装的是老版系统还要确认 CPU 是否支持二级地址转换SLAT。这套操作完成后重启笔记本再启动 Docker Desktop。如果你在自己的 PPT 里讲了 Docker 的 C/S 架构正好用这个案例解释「守护进程没起客户端说什么都没用」。5.3 踩坑记录二接入 docker API 报 permission denied现象Linux 上安装 Docker 后执行docker ps正常但脚本或 IDE 里访问 Docker API 时报permission denied while trying to connect to the docker api甚至直接提示/var/run/docker.sock拒绝访问。原因用户不在docker用户组里socket 文件的默认权限只允许 root 用户和 docker 组成员访问。命令在终端走 sudo 时能过但服务、脚本、IDE 往往不走 sudo。解决把当前用户加入 docker 组然后重新登录# 把当前用户加入 docker 组组名因发行版而异 sudo usermod -aG docker $USER # 验证是否生效不刷 sudo 直接执行 docker version --format {{.Server.Version}}注意改完组之后需要退出终端重新登录groups命令看到 docker 才算生效。这一步在交付脚本和自动化发布里尤其关键很多人 debug 半天发现只是权限问题。5.4 踩坑记录三镜像下载总是超时配置 registry-mirrors现象docker pull nginx长时间卡在层下载偶尔进度条走一半报i/o timeout。团队内建 CI 时尤其明显十几分钟拉不下一个基础镜像。原因默认 Docker Hub 公共仓库在当前网络条件下连接不稳定层下载失败后会反复重试CI 里并发拉取还会加剧超时。解决配置镜像加速地址。修改 Docker 的守护进程配置文件/etc/docker/daemon.jsonDocker Desktop 在设置界面里也有对应项把镜像加速服务地址填进去{ registry-mirrors: [https://你的加速地址] }填好之后重启 docker 服务注意registry-mirrors数组可以有多个地址Docker 会按顺序尝试。我可以负责任地说这个环节的坑不在配置本身而在加速地址会失效——建议配置前先确认地址能访问配置完立刻用docker pull验证不要等到 CI 报超时才排查。5.5 踩坑记录四k8s 节点反复 NotReadyswap 与容器运行时没对齐现象kubectl get nodes看到节点一直是NotReadykubectl describe node里的 Kubelet 日志反复重启或容器运行时状态报错。原因新装的 K8S 集群初始化前没关 swapkubelet 默认不允许在启用 swap 的情况下运行另外容器运行时常见是 containerd没和 kubelet 对齐版本也会导致节点上报失败。解决初始化前执行swapoff -a并注释/etc/fstab里的 swap 条目确保重启后不回弹。容器运行时方面确认 containerd 的版本在 kubeadm 兼容列表内然后重启 kubelet# 关闭 swap这是 kubeadm 初始化集群的硬性前提 swapoff -a # 重启 kubelet 和 containerd让其重新注册节点状态 systemctl restart containerd kubelet这里的顺序很关键先关 swap 再重启 kubelet否则 kubelet 起不来节点状态永远不健康。如果你是在 PPT 演示 minikube 时遇到类似现象多半是 minikube 分配的 CPU 或内存不足删除重建比手动排查快得多。5.6 踩坑记录五API server 初始化失败先把镜像拉干净现象kubeadm init卡在 Waiting for the kubelet to boot控制平面的 etcd 和 apiserver Pod 一直CrashLoopBackOff。原因kubeadm 初始化会去拉取一组基础镜像当前网络环境下镜像拉取失败或 ImagePullBackOff导致 Pod 无法启动。常见的错误日志指向沙箱镜像或 pause 镜像缺失。解决初始化前预先拉齐所需镜像再执行 init# 查看当前 kubeadm 需要哪些镜像 kubeadm config images list # 逐个拉取拉不到就配置镜像加速或换源地址 kubeadm config images pull这个坑给 PPT 分享的启示是演示 K8S 集群启动之前提前在你的演示机执行一遍kubeadm config images pull把最耗时的网络环节移到台下。现场看着进度条转三分钟再专业的讲解也会被冲淡。6. 验证一份架构 PPT 是否讲得通十分钟闭卷复述法6.1 闭卷复述法十分钟验证两份架构图每次做完架构 PPT我会先逼自己闭卷重画两张图第一张是 Docker 的「CLI → socket → dockerd → containerd → 容器」链路第二张是 K8S 的「kubectl → apiserver - etcd/scheduler/controller-manager → kubelet → Pod」链路。画不出来或顺序含糊的地方就是分享时最容易卡壳的地方。这个方法叫闭卷复述不看任何笔记白纸上从零画出架构主链路和每个组件的一句职责。画完再对着自己的 PPT 逐页自问「这一页在回答前面五个问题里的哪一个」答不上的页面不是装饰就是跑题。6.2 进阶找个外行当听众让他讲给你听复杂度更高的验证是找一位不熟悉容器技术的同事给他讲十分钟然后让他原样讲给你听。如果他能说出「Docker 负责打包K8S 负责任务调度但服务挂了它自己会拉起来」说明主线通了如果只说出一堆 ECS、Pod 名词说明你又在堆概念。这一步还能帮你发现哪些类比失效比如老说「K8S 是容器编排」对方不一定理解编排到底在编什么换成「它在机器挂了之后把服务挪到别的机器上继续跑」更稳妥。6.3 我的教训先讲问题再讲组件我吃过一次大亏早期做这类分享时开篇直接讲 K8S 组件结果听众全程在记名词散会时问「所以我们要它干嘛」。后来我把顺序改成「先讲单机部署的三个痛点再讲 Docker 解决前两个再讲 K8S 解决第三个」效果立刻不一样。把某次分享收尾时临时用口红在纸巾上画的链路图抽象出来从此成了我的固定流程。希望今天这套拆法帮到你。本文还有配套的精品资源点击获取