尧图网页设计 
简介这是一套聚焦容器与虚拟化技术的架构入门PPT面向运维工程师、开发人员及架构设计者帮助快速建立Docker与Kubernetes的整体认知。压缩包内共有1个PPTX文件大小约6.29MB页面结构完整适合个人自学或团队技术分享。目前已有933人学习下载内容质量获得一定认可。PPT从虚拟化架构概念切入对比全虚拟化、OS层面与硬件层虚拟化差异进而讲解Docker基于LXC的封装原理涵盖镜像、容器、仓库三大核心并深入namespace隔离、cgroups资源限制、AUFS文件系统等关键机制同时给出常用操作命令。后半部分系统介绍Kubernetes作为分布式架构支撑平台在服务注册发现、负载均衡、故障自愈、弹性扩容等方面的能力帮助读者理解从单机容器到集群编排的演进路径可作为入门阶段的系统性参考资料。1. DockerK8S架构介绍PPT先想清楚观众要带走哪三句话周五晚上同事把一版四十多页的DockerK8S架构介绍PPT发到群里配文是「明天讲帮我看下顺序」。这种PPT绝大多数听众是同一个命运看完只记住了「图很复杂」回去问起来只答得上「容器比虚拟机轻K8S能自动扩缩容」。问题出在把架构介绍做成了组件罗列而不是把「资源怎么分、任务怎么调度、故障怎么恢复」讲成一个能自圆其说的故事。我给他的建议很简单先让观众带走三句话——Docker管单机上的进程隔离K8S管集群里的期望状态两者在容器运行时这个点上交接。这篇就按这个顺序把一份可复现的讲解方案写给你先讲Docker的三个盒子再讲K8S的一条时间线中间把边界讲透最后放五条现场最容易翻车的避坑记录。适合要给团队做内部培训、准备技术面试讲题、或者做项目汇报的人刚入门K8S学习的人把这份内容当讲义也不会被绕晕。2. Docker 架构怎么讲进 PPT三个盒子、四张模块页、一条命令验真Docker 部分是整份PPT的暖场但很多人一上来就贴官方架构图把client、dockerd、containerd、containerd-shim、runc五层全画在一张图上十五秒后观众眼里就剩下密密麻麻的箭头。我一般建议控制在一页三个盒子后面的细节拆成独立模块页讲的时候用一条真实命令从头到尾印证一遍。2.1 先把「三个盒子」画对客户端、守护进程、内核隔离能力第一张架构图不要照着官方图抄而是画成左中右三个纵向方框。最左边是Docker CLI也就是你敲docker pull、docker run的地方中间是dockerd守护进程以及它调度的containerd、runc这一整条运行时链路最右边是宿主机内核提供的两大能力namespace负责隔离视图cgroup负责限制资源。三列下面分别写一句话客户端负责「人机交互」守护进程负责「镜像与容器生命周期」内核负责「真正的隔离手段」。这一页的讲解重点放在「容器没有自己的内核」。虚拟机里的应用面对的是一个完整Guest OS容器里的进程直接跑在宿主机内核上只是通过namespace换了它眼中的PID、网络、挂载和用户视图通过cgroup限制住CPU、内存、IO的使用上限。这么一讲观众自然能理解为什么容器镜像只有几百MB、启动只要几百毫秒也理解了为什么容器里执行uname看到的还是宿主内核版本。镜像的分层结构也建议画在这页的底部一个镜像由多层只读的tar层叠加最上面一个可写层供运行期写入。用抽屉来比喻最合适——多个镜像可以共用同一个基础层pull一个大镜像时如果没有这一层就省很多流量。PPT上不需要画出每一层的依赖关系一个「底层共享、上层独立」的示意图足够。2.2 Docker 架构介绍里必放的四张模块页镜像仓库、数据卷、网络模式、Compose 边界看完三个盒子观众会开始关心具体使用场景此时按四个模块逐页展开每页只回答一个高频问题。镜像仓库页回答「镜像从哪来」。讲Registry的概念、镜像的命名规则仓库地址/命名空间/镜像名:tag、公共仓库与私有仓库的区别。docker pull 的行为在这一页可以顺手讲掉因为它是后面K8S时间线的预演。数据卷页回答「容器删了数据怎么办」。容器可写层随着容器销毁而消失持久化要靠Volume。PPT上画两个场景bind mount把宿主目录挂进去named volume由Docker管理目录生命周期。这两条线分别对应用绑定mysql数据目录和redis持久化时最常见的做法。docker run -v与docker volume create的参数差异在这一页用命令对比展示最直观。网络模式页回答「容器之间怎么通」。bridge、host、none三个标准模式各给一个典型用法单机多容器默认走bridge容器需要直接占宿主端口时用host什么都不需要时用none。再补一条端口映射的说明讲清-P发布到宿主后Docker通过iptables做DNAT。这一段在答疑里非常实用因为在「docker网络不通」这类问题里八成是bridge网段冲突或者映射端口忘记开。Compose边界单独给一页避免讲K8S时观众把Compose和Swarm混进来。明确一句Compose解决单机多容器的编排Swarm虽然还在但编排领域事实上已经由K8S接管这份PPT不展开。四页的讲解时长我建议这样分配模块页建议时长画法要点最容易讲岔的点镜像仓库5分钟一条pull命令带出分层把镜像层数说成固定数量数据卷5分钟左边bind、右边volume对比混淆named volume与bind mount网络模式8分钟三个方框加一条NAT箭头以为bridge是自建虚拟网卡Compose边界4分钟一句话加一个示例文件把Compose说成生产编排2.3 现场用一条 docker run 命令反推架构图演示脚本与参数拆解架构介绍最怕「图是图、命令是命令」。我习惯先演示再切回三盒子图讲组件让观众看到架构是从命令行里长出来的。演示环境建议直接用Docker Desktop跨平台一致性好避免现场换到Linux后命令行为不同。# 1先确认Docker daemon已启动并看底层运行时信息 docker info | grep -iE runtime|kernel|server version # 2后台启动一个nginx容器把容器8080端口映射到宿主8080 docker run -id --name demo-nginx -p 8080:80 nginx:1.24 # 3进入容器看进程列表注意PID1是nginx而非bash docker exec demo-nginx ps -ef # 4看容器内主机名与单独IP证明network namespace隔离 docker exec demo-nginx hostname docker inspect demo-nginx --format {{.NetworkSettings.IPAddress}} # 5停止并删除容器确认清理 docker stop demo-nginx docker rm demo-nginx第一条命令用来确认环境健康grep出来的runtime如果是runc说明当前是标准运行时链路。第二条命令里的四个参数是讲解重点-d让容器在后台运行-i保持标准输入打开--name给容器一个稳定名字-p做端口映射。第三步执行ps -ef时观众会看到容器里只有nginx和它派生出的master/worker进程PID为1的不再是宿主init这是PID namespace的直观证据。第四步hostname输出与宿主不同inspect拿到的IP是bridge网段里分配出来的地址对应网络namespace的隔离。最后stop/rm收尾正好回到「容器生命周期由守护进程管理」这句结论。演示完之后切回三个盒子的PPT把命令行每一步用连线标到对应盒子上docker命令进客户端exec和inspect进dockerdps看到的PID1背后是内核namespace。记住图上每个节点都要能对应到一个命令或一个可见现象否则那个节点在讲解时就是多余的。3. K8S 架构怎么讲进 PPT控制面四件套、节点三件套、一次调度时间线K8S是全场的重头戏。架构图不能一张画到底分成两张一张控制面一张工作节点。组件先认全再讲清它们之间靠什么协作最后把一次部署从头到尾串成七步时间线。这样观众离开时能复述出「API Server是入口etcd是账本Scheduler挑房子kubelet搬家」。3.1 一张图拆两张控制面四件套与工作节点三件套别画成星形连接控制面这张图四件套横向排开API Server、etcd、Scheduler、Controller Manager。API Server是唯一入口所有kubectl请求都打到它的6443端口etcd存全量集群状态端口2379Scheduler负责给新Pod选节点Controller Manager后台循环维持期望状态。四者之间不需要画太多连线强调一个事实它们不直接互相调用全部通过API Server读写数据再靠watch机制感知变化。工作节点这张图画一个节点盒子里面放kubelet、kube-proxy与容器运行时三块。kubelet是节点上的「代理」通过10250端口与API Server保持心跳并执行调度指令kube-proxy维护节点上的网络转发规则容器运行时现在用containerd是常态不是Docker daemon。注意不要在这张图里再画一个Docker图标否则会强化「K8S管理Docker容器」这个过时理解。两张图画完后给一张速查表方便观众拍照也方便你回答高可用问题组件归属核心职责默认端口API Server控制面所有交互入口、鉴权、准入控制6443etcd控制面集群状态的唯一事实来源2379Scheduler控制面根据资源与约束为Pod选节点10259Controller Manager控制面持续把实际状态拉向期望状态10257kubelet工作节点维护节点上的Pod生命周期10250kube-proxy工作节点维护Service对应的转发规则动态端口容器运行时工作节点真正拉镜像、启停容器本地socket讲到高可用时用三台master最典型的配置做例子etcd三节点写入必须多数派确认也就是三台里挂一台仍然可用挂两台就失去法定票数API Server前面放一个负载均衡地址三个实例同时服务Scheduler和Controller Manager本来就是多实例选主。如果观众想搭一套三master集群用kubeadm或kubekey这类集群搭建工具都能把拓扑直接生成不必手工初始化太多组件。注意不要在PPT上把Pod画成节点之外的独立盒子。Pod一定是落在某个节点内的调度单元独立画会造成「Pod与节点同级」的错误印象。3.2 用一次 kubectl create 把 K8S 架构串成七步时间线从 kubectl 到 Pod Running认完组件之后给一条真实命令把整个架构激活。这一页是整个PPT里含金量最高的一页因为它是架构图能够回答实际问题的关键。演示命令选最常用的Deployment创建方式# 1创建nginx Deployment声明期望3个副本 kubectl create deployment demo-nginx --imagenginx:1.24 --replicas3 # 2轮流查看Pod状态观察从Pending到Running kubectl get pods -o wide # 3看调度结果落在哪个节点 kubectl get pods -o wide | awk {print $1, $7, $8} # 4查看Pod的Events回放整个调度过程 kubectl describe pod $(kubectl get pod -l appdemo-nginx -o jsonpath{.items[0].metadata.name})第一步里--image指定镜像--replicas声明副本数kubectl create与kubectl apply的区别在于前者偏向直接创建、后者偏向声明式同步面对面讲课时用create更直观。第二步的-o wide能看到Pod实际所在节点与IP这是架构图「调度」两个字的具体呈现。第四步describe里的Events字段是讲解的富矿里面逐条记录着Pulled、Created、Started、Scheduled这些事件。讲的时候在PPT上画七步时间线每步对应一个组件和一句话第1步kubectl把Deployment对象POST给API Server第2步API Server做完认证鉴权后写入etcd第3步Deployment控制器在watch中看到新对象创建ReplicaSet第4步Scheduler扫描未调度的Pod根据资源余量打分选出一个节点第5步目标节点的kubelet通过CRI接口通知containerd拉镜像第6步containerd启动容器并配置网络第7步kubelet向API Server上报Pod状态为Running同时kube-proxy在节点上写入Service转发规则。这七步的每一步都能在PPT上用一条粗箭头和一个组件名对应上。讲的时候反复强调一句话整个系统里没有谁在「指挥」谁而是每个组件都在watchetcd里的期望状态然后各自执行自己的职责。3.3 控制器与 PodK8S 架构介绍里最容易讲岔的两个概念组件认全、时间线讲通之后还要把「控制器」和「Pod」这两个概念单独拿一页出来因为听众的追问基本都集中在这里。控制器的核心是「看预期、调现状」。Deployment负责应用版本与副本数ReplicaSet负责维护固定数量的Pod副本DaemonSet保证每个节点上跑一个实例StatefulSet给有状态应用稳定网络标识和存储。这四个名字不用逐个展开PPT上给一个四行表格每行一句话即可。讲到Operator时顺带提一句Operator本质也是控制器只是把运维经验也写成了控制器逻辑属于进阶内容现场不需要展开。Pod的概念用「房东容器」的比喻来讲。每个Pod创建时先启动一个pause容器这个容器只负责占住网络命名空间、PID命名空间和共享卷应用容器再启动并加入这个「房间」。Pod是K8S里的最小调度单位不是容器本身。这个区分解释了为什么kubectl get pods看到的Ready列写的是1/1而不是容器列表它反映的是Pod里业务容器就绪个数。一个Pod里只有一个业务容器是再常见不过的用法但底层那个pause容器依然存在不要把它和业务容器混为一谈。这一页最后补一张常用命令小表查看节点状态用kubectl get nodes看Pod与所在节点用kubectl get pods -o wide看事件回放用kubectl get events进Pod排查用kubectl exec -it Pod名 -- sh。这几个命令是k8s学习过程中最高频的日常操作放这一页正好作为架构与实操的连接点。4. 把 Docker 和 K8S 的边界讲清楚一条部署路径两种表达习惯到这里观众已经分别理解了单机隔离与集群调度但很多人心里还悬着一个问题这两样东西到底是什么关系这一章把边界讲透用三个层面来组织底层事实、命令对照、微服务视角。4.1 边界的底层事实容器运行时≠Docker编排层与运行时层别混为一谈第一件要纠正的事是不要在PPT上画「Docker在K8S下层、K8S管Docker容器」这种并列结构。正确的说法是K8S的kubelet通过CRI接口对接容器运行时这个运行时被抽象成一个标准接口containerd既可以单独用来跑容器也可以被K8S调用Docker daemon在K8S架构里不是必需组件。Docker的价值不在「被K8S管理」而在于镜像构建与本地开发体验。镜像是用Dockerfile构建的格式遵循OCI标准运行时是K8S底下执行容器的组件遵循CRI标准编排是K8S自己做的事情。用三层模型比用「上下层包含关系」讲得更清楚这也是Docker和K8S区别最准确的口径。给一个三格对照帮助速记层次承担者要解决的事典型命令或API镜像层Docker / OCI把应用与依赖打包、分发docker build、docker pull运行时层containerd / CRI-O拉取镜像、启停容器ctr、crictl、CRI接口编排层K8S调度、扩缩容、自愈、服务发现kubectl apply、kubectl scale提示这一页不要写「Docker是K8S的底层依赖」这句话在纯containerd集群里会被直接反驳现场很难圆回来。4.2 从 docker run 到 kubectl apply同一份镜像两种心智模型的对照表架构讲清楚了观众会问「那我平时写的docker命令到了K8S里变成什么」。这一页做一张命令对照演示视觉冲击很强也最能打通新旧知识。# Docker 侧手工指定镜像、端口、副本数 docker pull nginx:1.24 docker run -d --name web -p 8080:80 nginx:1.24 # K8S 侧声明期望状态系统负责拉齐 kubectl create deployment web --imagenginx:1.24 --replicas2 kubectl expose deployment web --typeClusterIP --port80 --target-port80 kubectl scale deployment web --replicas3Docker命令是典型的手工操作式用户亲自指定端口映射、亲自指定容器名、亲自在前台或后台运行。K8S这边则是声明式kubectl create deployment里没有-p的端口映射概念因为端口暴露是Service层的事不是容器层的事。--replicas2声明副本数kubectl scale再把声明改成3剩下的事情全部由控制器接管。expose这一行特别值得展开。它创建了一个Service对象这个对象会给一组Pod一个稳定访问入口--port是Service对外端口--target-port是Pod容器端口。两个端口不一样是常态这也是Docker里「端口映射」概念在K8S世界的升级版。底层机制从iptables DNAT变成了Service机制但对外表现还是「访问固定入口转发到后端Pod」。这里还建议点一下labels与selector的匹配关系Deployment和Service都靠标签选择器找Pod不靠IP绑定。真正理解这条后面讲微服务故障处理才不虚。Docker的命令与K8S的对应关系用五个词就能收尾build对应镜像构建、run对应Deployment、network对应Service与NetworkPolicy、volume对应PVC、compose对应多工作负载编排但后者只是功能弱对应不是严格等价。4.3 用一个微服务三件套收尾Deployment、Service、Ingress 的讲解顺序架构介绍的最后一块业务拼图就是微服务部署路径。建议按「先内后外」讲三件套。首先讲Deployment它声明一个应用要有几个副本副本挂了谁负责拉起版本升级怎么滚动。这是所有微服务在K8S里的底座。其次讲Service它给一组动态变化的Pod一个固定入口客户端不需要知道Pod具体在哪台机器、IP是否漂移。最后讲Ingress它负责把集群外部的流量按域名或路径转发到不同Service是统一入口网关。这个顺序不要反过来。先讲Ingress会引出太多前置概念先讲Deployment则每步都有自然追问。如果观众问「没有云LB怎么对外暴露服务」给三个兜底答案NodePort在节点上开固定端口LoadBalancer调用云厂商负载均衡器externalIPs手动指定节点IP直接暴露。其中externalIPs在裸金属机房最常用PPT上给一行示例即可。三件套讲完后用一个生产故障场景收尾某服务Deployment副本数只有1所在节点宕机。这时Controller Manager发现副本数不足Scheduler在剩余节点中重新选点kubelet在新节点拉起新Pod——整个过程用户侧看到的是服务短暂中断后自动恢复。这是「期望状态」最生动的案例也是观众最能记住K8S价值的一个故事。k8s生产环境中常见的故障十有六七最后都落到副本数不足或健康检查缺失上讲完这个场景架构介绍就被赋予了具体的业务价值。5. 架构介绍 PPT 的常见翻车点五条避坑记录从环境到提问这一章不是理论是现场执行层面的坑。做架构介绍PPT最容易出问题的往往不是知识本身而是演示环境起不来、命令敲了没反应、台下抛来的问题接不住。每条按现象、原因、解决的顺序写方便你直接对号入座。5.1 现象Docker Desktop 启动失败报 virtualization support not detected双击Docker Desktop后图标一直转圈最终弹窗提示virtualization support not detected或者干脆卡在Engine starting。第一次遇到以为环境坏了重装两遍也没用。原因基本是两个BIOS里的CPU虚拟化没开或者WSL2版本不匹配。Windows上Docker Desktop靠WSL2做后端WSL2又依赖Windows的虚拟化平台任何一个环节没就绪都会报这条。解决路径先打开任务管理器-性能页看「虚拟化」是否显示「已启用」如果是「已禁用」进BIOS打开Intel VT-x或AMD-V然后再执行wsl --status确认WSL2欢迎最后以管理员身份重装一次Docker Desktop。不要在多个虚拟机软件同时开启时排查Hyper-V与第三方虚拟化功能互相叠加会让问题变成玄学先关掉不相关的虚拟化开关再试。5.2 现象命令行执行 docker info 报 failed to connect to the Docker daemon 或 npipe 连接失败终端里执行docker info报cannot connect to the Docker daemonWindows上常见的报错是failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine。很多人以为Docker坏了其实多半是daemon根本没起来或者环境变量被人动过。原因Docker Desktop没有启动、Linux版docker服务未运行、或者DOCKER_HOST环境变量被指向了一个不存在的地址。这个环境变量一旦被手工设置过Docker CLI就不会再去连本机默认socket。解决先打开Docker Desktop确认状态是RunningLinux上执行systemctl status docker然后排查环境变量执行echo $DOCKER_HOSTWindows上是echo %DOCKER_HOST%如果不是空值清理掉再重开终端。最稳的办法是卸载掉DOCKER_HOST这种手工配置让Docker CLI走本机默认socket。5.3 现象kubectl create 之后 Pod 一直 Pending 或 ImagePullBackOff现场演示创建Deployment命令敲完kubectl get pods刷了好几轮Pod要么Pending要么ImagePullBackOff观众已经低头看手机了。原因节点资源不足导致Scheduler无法完成调度、镜像拉取失败、或者集群里没有配置存储类但Deployment挂载了PVC。其中镜像拉取失败最常见现场网络环境下拉一个大镜像是非常容易卡住的。解决演示前先用kubectl get nodes检查每个节点的CPU和内存余量把演示镜像全部换成nginx:alpine这类只有几十MB的小镜像提前在一台空闲机器上手动拉取镜像并确认集群能访问到仓库。做PPT演示有一条铁律所有镜像提前准备好现场只做创建和状态观察不做拉取动作。5.4 现象一页架构图画了二十个方块观众听完只记住了「东西真多」这是讲解设计层面的翻车。把Docker官方架构图和K8S组件图拼到一页每个组件都想标清楚结果没有重点信息全被平均掉。原因把原理图和部署拓扑图混在同一张图上同时缺少视觉层级。观众处理不了这么多陌生名词并存的画面。解决一页只讲一个结论。控制面一张图工作节点一张图七步时间线一张图。组件用颜色分群控制面一种主色工作节点一种主色关键链路加粗并标序号。每一页在结束前用一句话回收重点比如这页只讲「API Server是唯一入口」其他组件以后遇到再讲。架构图上的每个框都要能回答「它是干什么的」和「它跟上一个框什么关系」回答不了的框直接拿掉。5.5 现象台下问「k8s是不是自主可控」「三台master怎么保证高可用」回答散装技术介绍最后常被问到宏观问题。特别是讲到K8S由CNCF托管时观众会追问「是不是自主可控」讲到控制面时又会被问「三台master挂了怎么办」。这两个问题回答不好前面建立的专业感会打折扣。处理口径要提前准备好。「自主可控」这类问题不展开宏观评价只从技术事实回应K8S是CNCF托管的开源项目采用Apache 2.0许可证任何团队都可以基于源码构建自己的发行版真正影响可控性的是你选择了哪个发行版、部署时依赖了哪些外部镜像和组件。把话题收拢到「开源许可证、发行版选择、镜像供应链」这三个技术词汇上不进入其他范畴。三台master高可用是纯技术问题可以给一个标准口径API Server三层实例前置负载均衡统一入口etcd三节点靠Raft多数派确认写入最多容忍一台故障Controller Manager与Scheduler本身支持多实例选主故障时自动切主。再补一句kubeadm或kubekey这类集群搭建工具都能直接产出三master拓扑。整套口径讲完现场问题基本都能收住。6. 用三个「过片子」动作验证 PPT先默讲再跑一次真实调度最后准备两道必答题准备到差不多时千万别直接上台。我有三个验证动作每个三到五分钟能在出发前把PPT里的逻辑漏洞揪出来。第一个动作把架构图全部盖住只凭脑子默讲。从用户请求到容器运行讲一条完整链路控制在三句话以内。如果你卡在某一跳——比如说不清Scheduler选完节点后kubelet收到的是什么东西——那一跳对应的PPT页就是模糊点回去补一个箭头或者补一句说明。PPT图自己能看懂不算数你能不看图还讲得顺才算逻辑闭环。第二个动作在演示集群里把这套流程完整跑一遍然后把事件序列导出来看一遍。命令很简单# 预演一次完整创建观察事件流水 kubectl create deployment prefight --imagenginx:alpine --replicas1 kubectl rollout status deployment/prefight # 导出与prefight相关的事件按时间排序 kubectl get events -A --sort-by.metadata.creationTimestamp \ | grep -E prefight|deployment|replicaset|podkubectl get events输出里会依次出现deployment创建、replicaset创建、pod调度、镜像拉取、容器启动这些事件名。把这些事件名跟PPT里的七步时间线对照你会发现自己架构图上漏掉了哪一步。比如Events里如果有FailedScheduling记录恰恰说明你PPT里该补一条「资源不足时调度器如何重试」的说明。第三个动作提前想好两道必答题。第一道是「一个Pod里能不能只有一个业务容器」答案是可以Pod里始终有infra容器占住namespace但业务容器完全允许只有一个。第二道是「没有DockerK8S能不能跑」答案也是可以只要运行时符合CRI标准containerd和CRI-O都行。这两道题分别检验你对Pod模型和运行时边界的理解能当场答顺大部分追问就都能接住。这几年我做过至少三版同主题的架构介绍PPT最短的那版反而最扛得住提问。它没有把官网组件图伺候齐全只是老老实实讲清了单机怎么隔离、集群怎么调度、请求怎么流转。你按这个顺序讲把时间线跑熟把边界话术备好台下敢提问就是这场介绍立住的信号。希望帮到你。本文还有配套的精品资源点击获取 Docker与K8S架构讲解PPT：组件梳理、调度时间线与避坑指南
简介这是一套聚焦容器与虚拟化技术的架构入门PPT面向运维工程师、开发人员及架构设计者帮助快速建立Docker与Kubernetes的整体认知。压缩包内共有1个PPTX文件大小约6.29MB页面结构完整适合个人自学或团队技术分享。目前已有933人学习下载内容质量获得一定认可。PPT从虚拟化架构概念切入对比全虚拟化、OS层面与硬件层虚拟化差异进而讲解Docker基于LXC的封装原理涵盖镜像、容器、仓库三大核心并深入namespace隔离、cgroups资源限制、AUFS文件系统等关键机制同时给出常用操作命令。后半部分系统介绍Kubernetes作为分布式架构支撑平台在服务注册发现、负载均衡、故障自愈、弹性扩容等方面的能力帮助读者理解从单机容器到集群编排的演进路径可作为入门阶段的系统性参考资料。1. DockerK8S架构介绍PPT先想清楚观众要带走哪三句话周五晚上同事把一版四十多页的DockerK8S架构介绍PPT发到群里配文是「明天讲帮我看下顺序」。这种PPT绝大多数听众是同一个命运看完只记住了「图很复杂」回去问起来只答得上「容器比虚拟机轻K8S能自动扩缩容」。问题出在把架构介绍做成了组件罗列而不是把「资源怎么分、任务怎么调度、故障怎么恢复」讲成一个能自圆其说的故事。我给他的建议很简单先让观众带走三句话——Docker管单机上的进程隔离K8S管集群里的期望状态两者在容器运行时这个点上交接。这篇就按这个顺序把一份可复现的讲解方案写给你先讲Docker的三个盒子再讲K8S的一条时间线中间把边界讲透最后放五条现场最容易翻车的避坑记录。适合要给团队做内部培训、准备技术面试讲题、或者做项目汇报的人刚入门K8S学习的人把这份内容当讲义也不会被绕晕。2. Docker 架构怎么讲进 PPT三个盒子、四张模块页、一条命令验真Docker 部分是整份PPT的暖场但很多人一上来就贴官方架构图把client、dockerd、containerd、containerd-shim、runc五层全画在一张图上十五秒后观众眼里就剩下密密麻麻的箭头。我一般建议控制在一页三个盒子后面的细节拆成独立模块页讲的时候用一条真实命令从头到尾印证一遍。2.1 先把「三个盒子」画对客户端、守护进程、内核隔离能力第一张架构图不要照着官方图抄而是画成左中右三个纵向方框。最左边是Docker CLI也就是你敲docker pull、docker run的地方中间是dockerd守护进程以及它调度的containerd、runc这一整条运行时链路最右边是宿主机内核提供的两大能力namespace负责隔离视图cgroup负责限制资源。三列下面分别写一句话客户端负责「人机交互」守护进程负责「镜像与容器生命周期」内核负责「真正的隔离手段」。这一页的讲解重点放在「容器没有自己的内核」。虚拟机里的应用面对的是一个完整Guest OS容器里的进程直接跑在宿主机内核上只是通过namespace换了它眼中的PID、网络、挂载和用户视图通过cgroup限制住CPU、内存、IO的使用上限。这么一讲观众自然能理解为什么容器镜像只有几百MB、启动只要几百毫秒也理解了为什么容器里执行uname看到的还是宿主内核版本。镜像的分层结构也建议画在这页的底部一个镜像由多层只读的tar层叠加最上面一个可写层供运行期写入。用抽屉来比喻最合适——多个镜像可以共用同一个基础层pull一个大镜像时如果没有这一层就省很多流量。PPT上不需要画出每一层的依赖关系一个「底层共享、上层独立」的示意图足够。2.2 Docker 架构介绍里必放的四张模块页镜像仓库、数据卷、网络模式、Compose 边界看完三个盒子观众会开始关心具体使用场景此时按四个模块逐页展开每页只回答一个高频问题。镜像仓库页回答「镜像从哪来」。讲Registry的概念、镜像的命名规则仓库地址/命名空间/镜像名:tag、公共仓库与私有仓库的区别。docker pull 的行为在这一页可以顺手讲掉因为它是后面K8S时间线的预演。数据卷页回答「容器删了数据怎么办」。容器可写层随着容器销毁而消失持久化要靠Volume。PPT上画两个场景bind mount把宿主目录挂进去named volume由Docker管理目录生命周期。这两条线分别对应用绑定mysql数据目录和redis持久化时最常见的做法。docker run -v与docker volume create的参数差异在这一页用命令对比展示最直观。网络模式页回答「容器之间怎么通」。bridge、host、none三个标准模式各给一个典型用法单机多容器默认走bridge容器需要直接占宿主端口时用host什么都不需要时用none。再补一条端口映射的说明讲清-P发布到宿主后Docker通过iptables做DNAT。这一段在答疑里非常实用因为在「docker网络不通」这类问题里八成是bridge网段冲突或者映射端口忘记开。Compose边界单独给一页避免讲K8S时观众把Compose和Swarm混进来。明确一句Compose解决单机多容器的编排Swarm虽然还在但编排领域事实上已经由K8S接管这份PPT不展开。四页的讲解时长我建议这样分配模块页建议时长画法要点最容易讲岔的点镜像仓库5分钟一条pull命令带出分层把镜像层数说成固定数量数据卷5分钟左边bind、右边volume对比混淆named volume与bind mount网络模式8分钟三个方框加一条NAT箭头以为bridge是自建虚拟网卡Compose边界4分钟一句话加一个示例文件把Compose说成生产编排2.3 现场用一条 docker run 命令反推架构图演示脚本与参数拆解架构介绍最怕「图是图、命令是命令」。我习惯先演示再切回三盒子图讲组件让观众看到架构是从命令行里长出来的。演示环境建议直接用Docker Desktop跨平台一致性好避免现场换到Linux后命令行为不同。# 1先确认Docker daemon已启动并看底层运行时信息 docker info | grep -iE runtime|kernel|server version # 2后台启动一个nginx容器把容器8080端口映射到宿主8080 docker run -id --name demo-nginx -p 8080:80 nginx:1.24 # 3进入容器看进程列表注意PID1是nginx而非bash docker exec demo-nginx ps -ef # 4看容器内主机名与单独IP证明network namespace隔离 docker exec demo-nginx hostname docker inspect demo-nginx --format {{.NetworkSettings.IPAddress}} # 5停止并删除容器确认清理 docker stop demo-nginx docker rm demo-nginx第一条命令用来确认环境健康grep出来的runtime如果是runc说明当前是标准运行时链路。第二条命令里的四个参数是讲解重点-d让容器在后台运行-i保持标准输入打开--name给容器一个稳定名字-p做端口映射。第三步执行ps -ef时观众会看到容器里只有nginx和它派生出的master/worker进程PID为1的不再是宿主init这是PID namespace的直观证据。第四步hostname输出与宿主不同inspect拿到的IP是bridge网段里分配出来的地址对应网络namespace的隔离。最后stop/rm收尾正好回到「容器生命周期由守护进程管理」这句结论。演示完之后切回三个盒子的PPT把命令行每一步用连线标到对应盒子上docker命令进客户端exec和inspect进dockerdps看到的PID1背后是内核namespace。记住图上每个节点都要能对应到一个命令或一个可见现象否则那个节点在讲解时就是多余的。3. K8S 架构怎么讲进 PPT控制面四件套、节点三件套、一次调度时间线K8S是全场的重头戏。架构图不能一张画到底分成两张一张控制面一张工作节点。组件先认全再讲清它们之间靠什么协作最后把一次部署从头到尾串成七步时间线。这样观众离开时能复述出「API Server是入口etcd是账本Scheduler挑房子kubelet搬家」。3.1 一张图拆两张控制面四件套与工作节点三件套别画成星形连接控制面这张图四件套横向排开API Server、etcd、Scheduler、Controller Manager。API Server是唯一入口所有kubectl请求都打到它的6443端口etcd存全量集群状态端口2379Scheduler负责给新Pod选节点Controller Manager后台循环维持期望状态。四者之间不需要画太多连线强调一个事实它们不直接互相调用全部通过API Server读写数据再靠watch机制感知变化。工作节点这张图画一个节点盒子里面放kubelet、kube-proxy与容器运行时三块。kubelet是节点上的「代理」通过10250端口与API Server保持心跳并执行调度指令kube-proxy维护节点上的网络转发规则容器运行时现在用containerd是常态不是Docker daemon。注意不要在这张图里再画一个Docker图标否则会强化「K8S管理Docker容器」这个过时理解。两张图画完后给一张速查表方便观众拍照也方便你回答高可用问题组件归属核心职责默认端口API Server控制面所有交互入口、鉴权、准入控制6443etcd控制面集群状态的唯一事实来源2379Scheduler控制面根据资源与约束为Pod选节点10259Controller Manager控制面持续把实际状态拉向期望状态10257kubelet工作节点维护节点上的Pod生命周期10250kube-proxy工作节点维护Service对应的转发规则动态端口容器运行时工作节点真正拉镜像、启停容器本地socket讲到高可用时用三台master最典型的配置做例子etcd三节点写入必须多数派确认也就是三台里挂一台仍然可用挂两台就失去法定票数API Server前面放一个负载均衡地址三个实例同时服务Scheduler和Controller Manager本来就是多实例选主。如果观众想搭一套三master集群用kubeadm或kubekey这类集群搭建工具都能把拓扑直接生成不必手工初始化太多组件。注意不要在PPT上把Pod画成节点之外的独立盒子。Pod一定是落在某个节点内的调度单元独立画会造成「Pod与节点同级」的错误印象。3.2 用一次 kubectl create 把 K8S 架构串成七步时间线从 kubectl 到 Pod Running认完组件之后给一条真实命令把整个架构激活。这一页是整个PPT里含金量最高的一页因为它是架构图能够回答实际问题的关键。演示命令选最常用的Deployment创建方式# 1创建nginx Deployment声明期望3个副本 kubectl create deployment demo-nginx --imagenginx:1.24 --replicas3 # 2轮流查看Pod状态观察从Pending到Running kubectl get pods -o wide # 3看调度结果落在哪个节点 kubectl get pods -o wide | awk {print $1, $7, $8} # 4查看Pod的Events回放整个调度过程 kubectl describe pod $(kubectl get pod -l appdemo-nginx -o jsonpath{.items[0].metadata.name})第一步里--image指定镜像--replicas声明副本数kubectl create与kubectl apply的区别在于前者偏向直接创建、后者偏向声明式同步面对面讲课时用create更直观。第二步的-o wide能看到Pod实际所在节点与IP这是架构图「调度」两个字的具体呈现。第四步describe里的Events字段是讲解的富矿里面逐条记录着Pulled、Created、Started、Scheduled这些事件。讲的时候在PPT上画七步时间线每步对应一个组件和一句话第1步kubectl把Deployment对象POST给API Server第2步API Server做完认证鉴权后写入etcd第3步Deployment控制器在watch中看到新对象创建ReplicaSet第4步Scheduler扫描未调度的Pod根据资源余量打分选出一个节点第5步目标节点的kubelet通过CRI接口通知containerd拉镜像第6步containerd启动容器并配置网络第7步kubelet向API Server上报Pod状态为Running同时kube-proxy在节点上写入Service转发规则。这七步的每一步都能在PPT上用一条粗箭头和一个组件名对应上。讲的时候反复强调一句话整个系统里没有谁在「指挥」谁而是每个组件都在watchetcd里的期望状态然后各自执行自己的职责。3.3 控制器与 PodK8S 架构介绍里最容易讲岔的两个概念组件认全、时间线讲通之后还要把「控制器」和「Pod」这两个概念单独拿一页出来因为听众的追问基本都集中在这里。控制器的核心是「看预期、调现状」。Deployment负责应用版本与副本数ReplicaSet负责维护固定数量的Pod副本DaemonSet保证每个节点上跑一个实例StatefulSet给有状态应用稳定网络标识和存储。这四个名字不用逐个展开PPT上给一个四行表格每行一句话即可。讲到Operator时顺带提一句Operator本质也是控制器只是把运维经验也写成了控制器逻辑属于进阶内容现场不需要展开。Pod的概念用「房东容器」的比喻来讲。每个Pod创建时先启动一个pause容器这个容器只负责占住网络命名空间、PID命名空间和共享卷应用容器再启动并加入这个「房间」。Pod是K8S里的最小调度单位不是容器本身。这个区分解释了为什么kubectl get pods看到的Ready列写的是1/1而不是容器列表它反映的是Pod里业务容器就绪个数。一个Pod里只有一个业务容器是再常见不过的用法但底层那个pause容器依然存在不要把它和业务容器混为一谈。这一页最后补一张常用命令小表查看节点状态用kubectl get nodes看Pod与所在节点用kubectl get pods -o wide看事件回放用kubectl get events进Pod排查用kubectl exec -it Pod名 -- sh。这几个命令是k8s学习过程中最高频的日常操作放这一页正好作为架构与实操的连接点。4. 把 Docker 和 K8S 的边界讲清楚一条部署路径两种表达习惯到这里观众已经分别理解了单机隔离与集群调度但很多人心里还悬着一个问题这两样东西到底是什么关系这一章把边界讲透用三个层面来组织底层事实、命令对照、微服务视角。4.1 边界的底层事实容器运行时≠Docker编排层与运行时层别混为一谈第一件要纠正的事是不要在PPT上画「Docker在K8S下层、K8S管Docker容器」这种并列结构。正确的说法是K8S的kubelet通过CRI接口对接容器运行时这个运行时被抽象成一个标准接口containerd既可以单独用来跑容器也可以被K8S调用Docker daemon在K8S架构里不是必需组件。Docker的价值不在「被K8S管理」而在于镜像构建与本地开发体验。镜像是用Dockerfile构建的格式遵循OCI标准运行时是K8S底下执行容器的组件遵循CRI标准编排是K8S自己做的事情。用三层模型比用「上下层包含关系」讲得更清楚这也是Docker和K8S区别最准确的口径。给一个三格对照帮助速记层次承担者要解决的事典型命令或API镜像层Docker / OCI把应用与依赖打包、分发docker build、docker pull运行时层containerd / CRI-O拉取镜像、启停容器ctr、crictl、CRI接口编排层K8S调度、扩缩容、自愈、服务发现kubectl apply、kubectl scale提示这一页不要写「Docker是K8S的底层依赖」这句话在纯containerd集群里会被直接反驳现场很难圆回来。4.2 从 docker run 到 kubectl apply同一份镜像两种心智模型的对照表架构讲清楚了观众会问「那我平时写的docker命令到了K8S里变成什么」。这一页做一张命令对照演示视觉冲击很强也最能打通新旧知识。# Docker 侧手工指定镜像、端口、副本数 docker pull nginx:1.24 docker run -d --name web -p 8080:80 nginx:1.24 # K8S 侧声明期望状态系统负责拉齐 kubectl create deployment web --imagenginx:1.24 --replicas2 kubectl expose deployment web --typeClusterIP --port80 --target-port80 kubectl scale deployment web --replicas3Docker命令是典型的手工操作式用户亲自指定端口映射、亲自指定容器名、亲自在前台或后台运行。K8S这边则是声明式kubectl create deployment里没有-p的端口映射概念因为端口暴露是Service层的事不是容器层的事。--replicas2声明副本数kubectl scale再把声明改成3剩下的事情全部由控制器接管。expose这一行特别值得展开。它创建了一个Service对象这个对象会给一组Pod一个稳定访问入口--port是Service对外端口--target-port是Pod容器端口。两个端口不一样是常态这也是Docker里「端口映射」概念在K8S世界的升级版。底层机制从iptables DNAT变成了Service机制但对外表现还是「访问固定入口转发到后端Pod」。这里还建议点一下labels与selector的匹配关系Deployment和Service都靠标签选择器找Pod不靠IP绑定。真正理解这条后面讲微服务故障处理才不虚。Docker的命令与K8S的对应关系用五个词就能收尾build对应镜像构建、run对应Deployment、network对应Service与NetworkPolicy、volume对应PVC、compose对应多工作负载编排但后者只是功能弱对应不是严格等价。4.3 用一个微服务三件套收尾Deployment、Service、Ingress 的讲解顺序架构介绍的最后一块业务拼图就是微服务部署路径。建议按「先内后外」讲三件套。首先讲Deployment它声明一个应用要有几个副本副本挂了谁负责拉起版本升级怎么滚动。这是所有微服务在K8S里的底座。其次讲Service它给一组动态变化的Pod一个固定入口客户端不需要知道Pod具体在哪台机器、IP是否漂移。最后讲Ingress它负责把集群外部的流量按域名或路径转发到不同Service是统一入口网关。这个顺序不要反过来。先讲Ingress会引出太多前置概念先讲Deployment则每步都有自然追问。如果观众问「没有云LB怎么对外暴露服务」给三个兜底答案NodePort在节点上开固定端口LoadBalancer调用云厂商负载均衡器externalIPs手动指定节点IP直接暴露。其中externalIPs在裸金属机房最常用PPT上给一行示例即可。三件套讲完后用一个生产故障场景收尾某服务Deployment副本数只有1所在节点宕机。这时Controller Manager发现副本数不足Scheduler在剩余节点中重新选点kubelet在新节点拉起新Pod——整个过程用户侧看到的是服务短暂中断后自动恢复。这是「期望状态」最生动的案例也是观众最能记住K8S价值的一个故事。k8s生产环境中常见的故障十有六七最后都落到副本数不足或健康检查缺失上讲完这个场景架构介绍就被赋予了具体的业务价值。5. 架构介绍 PPT 的常见翻车点五条避坑记录从环境到提问这一章不是理论是现场执行层面的坑。做架构介绍PPT最容易出问题的往往不是知识本身而是演示环境起不来、命令敲了没反应、台下抛来的问题接不住。每条按现象、原因、解决的顺序写方便你直接对号入座。5.1 现象Docker Desktop 启动失败报 virtualization support not detected双击Docker Desktop后图标一直转圈最终弹窗提示virtualization support not detected或者干脆卡在Engine starting。第一次遇到以为环境坏了重装两遍也没用。原因基本是两个BIOS里的CPU虚拟化没开或者WSL2版本不匹配。Windows上Docker Desktop靠WSL2做后端WSL2又依赖Windows的虚拟化平台任何一个环节没就绪都会报这条。解决路径先打开任务管理器-性能页看「虚拟化」是否显示「已启用」如果是「已禁用」进BIOS打开Intel VT-x或AMD-V然后再执行wsl --status确认WSL2欢迎最后以管理员身份重装一次Docker Desktop。不要在多个虚拟机软件同时开启时排查Hyper-V与第三方虚拟化功能互相叠加会让问题变成玄学先关掉不相关的虚拟化开关再试。5.2 现象命令行执行 docker info 报 failed to connect to the Docker daemon 或 npipe 连接失败终端里执行docker info报cannot connect to the Docker daemonWindows上常见的报错是failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine。很多人以为Docker坏了其实多半是daemon根本没起来或者环境变量被人动过。原因Docker Desktop没有启动、Linux版docker服务未运行、或者DOCKER_HOST环境变量被指向了一个不存在的地址。这个环境变量一旦被手工设置过Docker CLI就不会再去连本机默认socket。解决先打开Docker Desktop确认状态是RunningLinux上执行systemctl status docker然后排查环境变量执行echo $DOCKER_HOSTWindows上是echo %DOCKER_HOST%如果不是空值清理掉再重开终端。最稳的办法是卸载掉DOCKER_HOST这种手工配置让Docker CLI走本机默认socket。5.3 现象kubectl create 之后 Pod 一直 Pending 或 ImagePullBackOff现场演示创建Deployment命令敲完kubectl get pods刷了好几轮Pod要么Pending要么ImagePullBackOff观众已经低头看手机了。原因节点资源不足导致Scheduler无法完成调度、镜像拉取失败、或者集群里没有配置存储类但Deployment挂载了PVC。其中镜像拉取失败最常见现场网络环境下拉一个大镜像是非常容易卡住的。解决演示前先用kubectl get nodes检查每个节点的CPU和内存余量把演示镜像全部换成nginx:alpine这类只有几十MB的小镜像提前在一台空闲机器上手动拉取镜像并确认集群能访问到仓库。做PPT演示有一条铁律所有镜像提前准备好现场只做创建和状态观察不做拉取动作。5.4 现象一页架构图画了二十个方块观众听完只记住了「东西真多」这是讲解设计层面的翻车。把Docker官方架构图和K8S组件图拼到一页每个组件都想标清楚结果没有重点信息全被平均掉。原因把原理图和部署拓扑图混在同一张图上同时缺少视觉层级。观众处理不了这么多陌生名词并存的画面。解决一页只讲一个结论。控制面一张图工作节点一张图七步时间线一张图。组件用颜色分群控制面一种主色工作节点一种主色关键链路加粗并标序号。每一页在结束前用一句话回收重点比如这页只讲「API Server是唯一入口」其他组件以后遇到再讲。架构图上的每个框都要能回答「它是干什么的」和「它跟上一个框什么关系」回答不了的框直接拿掉。5.5 现象台下问「k8s是不是自主可控」「三台master怎么保证高可用」回答散装技术介绍最后常被问到宏观问题。特别是讲到K8S由CNCF托管时观众会追问「是不是自主可控」讲到控制面时又会被问「三台master挂了怎么办」。这两个问题回答不好前面建立的专业感会打折扣。处理口径要提前准备好。「自主可控」这类问题不展开宏观评价只从技术事实回应K8S是CNCF托管的开源项目采用Apache 2.0许可证任何团队都可以基于源码构建自己的发行版真正影响可控性的是你选择了哪个发行版、部署时依赖了哪些外部镜像和组件。把话题收拢到「开源许可证、发行版选择、镜像供应链」这三个技术词汇上不进入其他范畴。三台master高可用是纯技术问题可以给一个标准口径API Server三层实例前置负载均衡统一入口etcd三节点靠Raft多数派确认写入最多容忍一台故障Controller Manager与Scheduler本身支持多实例选主故障时自动切主。再补一句kubeadm或kubekey这类集群搭建工具都能直接产出三master拓扑。整套口径讲完现场问题基本都能收住。6. 用三个「过片子」动作验证 PPT先默讲再跑一次真实调度最后准备两道必答题准备到差不多时千万别直接上台。我有三个验证动作每个三到五分钟能在出发前把PPT里的逻辑漏洞揪出来。第一个动作把架构图全部盖住只凭脑子默讲。从用户请求到容器运行讲一条完整链路控制在三句话以内。如果你卡在某一跳——比如说不清Scheduler选完节点后kubelet收到的是什么东西——那一跳对应的PPT页就是模糊点回去补一个箭头或者补一句说明。PPT图自己能看懂不算数你能不看图还讲得顺才算逻辑闭环。第二个动作在演示集群里把这套流程完整跑一遍然后把事件序列导出来看一遍。命令很简单# 预演一次完整创建观察事件流水 kubectl create deployment prefight --imagenginx:alpine --replicas1 kubectl rollout status deployment/prefight # 导出与prefight相关的事件按时间排序 kubectl get events -A --sort-by.metadata.creationTimestamp \ | grep -E prefight|deployment|replicaset|podkubectl get events输出里会依次出现deployment创建、replicaset创建、pod调度、镜像拉取、容器启动这些事件名。把这些事件名跟PPT里的七步时间线对照你会发现自己架构图上漏掉了哪一步。比如Events里如果有FailedScheduling记录恰恰说明你PPT里该补一条「资源不足时调度器如何重试」的说明。第三个动作提前想好两道必答题。第一道是「一个Pod里能不能只有一个业务容器」答案是可以Pod里始终有infra容器占住namespace但业务容器完全允许只有一个。第二道是「没有DockerK8S能不能跑」答案也是可以只要运行时符合CRI标准containerd和CRI-O都行。这两道题分别检验你对Pod模型和运行时边界的理解能当场答顺大部分追问就都能接住。这几年我做过至少三版同主题的架构介绍PPT最短的那版反而最扛得住提问。它没有把官网组件图伺候齐全只是老老实实讲清了单机怎么隔离、集群怎么调度、请求怎么流转。你按这个顺序讲把时间线跑熟把边界话术备好台下敢提问就是这场介绍立住的信号。希望帮到你。本文还有配套的精品资源点击获取