简介一份面向容器技术初学者的Docker与K8S架构介绍PPT适合运维工程师、后端开发及系统架构师快速建立容器化知识框架解决对虚拟化、Docker容器与Kubernetes编排概念模糊、难以理顺相互关系的问题。包内仅有1个pptx文件压缩包整体6.29MB以图示化方式系统梳理四大部分先对比全虚拟化、OS层面虚拟化与平台硬件层虚拟化的架构差异再展开Docker原理涵盖镜像、容器、仓库三大核心概念介绍基于LXC技术、Go语言实现及Apache 2.0协议的开源背景并详解namespace隔离、cgroups资源限制、AUFS文件系统等底层机制随后演示docker pull/images/run等基本操作命令。最后延伸到Kubernetes讲解它是完备的分布式系统支撑平台具备集群管理、安全准入、多租户支撑、服务注册发现、智能负载均衡、故障自愈、滚动升级、在线扩容、自动资源调度与多粒度资源配额管理等能力让人理解容器编排的整体价值。整套PPT目录结构清晰已吸引933人学习内容精炼、从基础到原理再到平台均有覆盖适合作为内部培训分享或自学入门材料可帮助读者快速构建Docker与K8S的体系化认知为后续实战操作与架构设计打底。1. 为什么一份DockerK8S架构介绍PPT值得认真讲它讲的是两套系统的协作边界“DockerK8S架构介绍PPT”这个标题我一年里至少要接三回一回是新员工容器化培训一回是内部系统改造前的技术预研还有一回是给业务方解释“为什么测试环境又连不上”。它看起来只是把两个词并排放在一起真正难的是讲清楚 Docker 管到哪一层、K8S 从哪一层接手以及两层之间的衔接是实心还是空心。很多人把 Docker 和 K8S 打包成一个词架构图上镜像、容器、Pod、Node 全堆在一张图里讲完之后听众依然不知道谁负责启动容器谁负责在机器宕机后把容器重新拉起来。这篇内容就按“做这份PPT”的视角来拆。每一章对应 PPT 里一个必须讲透的架构问题并且配一组可以在命令行里验证的步骤。你要给别人讲得明白自己得先在本地把容器跑起来再把一个最小集群拉起来照着真实的对象去画图而不是背概念。适合想给团队做技术分享的工程师也适合刚接触 Docker 和 K8S、需要快速建立整体架构观的开发者。读完你不仅能复述组件名字还能画出两张图一张讲单机容器怎么跑一张讲多机集群怎么维持期望状态。2. Docker 的架构镜像、容器、运行时与仓库的四层解剖一份讲 Docker 架构的 PPT最常见的错误是从“什么是容器”开始而不是从“镜像怎么变成容器”开始。我的做法是先讲清楚四个对象镜像、容器、运行时、仓库。这四个对象的关系就是 Docker 的完整架构剩下的网络和数据卷是它们的附属品。这一章按照“镜像分层 → 容器生成 → 运行时分工 → 仓库与网络/卷”的顺序拆每一节最后都留一个可以复现的命令。2.1 从镜像到容器一套可启动的只读模板镜像不是一个装满文件的大压缩包而是一组按层堆积的只读文件系统。每一层对应 Dockerfile 里的一条指令比如FROM、RUN、COPY。多个镜像可以共享底层这也是为什么公司内部的 Docker 仓库能省大量磁盘。容器的写操作发生在最上层的可写容器层一旦容器删除这一层也消失容器内改过的文件全部复位。讲解 PPT 时我习惯用一张“千层蛋糕”图来说明层叠关系然后用两条命令让听众自己看分层。先拉一个体积很小的镜像再逐层看它由什么组成。docker history能列出镜像的构建历史和每一层的大小docker image inspect能看 RootFS 的层信息。# 拉取一个约 50MB 的轻量镜像适合做分层演示 docker pull alpine:3.19 # 查看镜像的构建历史每一行对应一层 docker history alpine:3.19 # 查看镜像的 RootFS.Layers 字段确认它的底层由几层组成 docker image inspect alpine:3.19history的输出里CREATED BY列会显示生成该层的 Dockerfile 指令例如/bin/sh -c #(nop) CMD [/bin/sh]。SIZE列是这一层新增的数据量不是镜像解压后的实际占用。换做带RUN apk add的镜像你会看到某一层体积突然增大这就是“层”的单位也是后续做镜像瘦身时定位大文件的依据。image inspect的RootFS.Layers是一个字符串列表每个字符串是层的哈希 ID。同一宿主机上如果两个镜像共享底层这部分哈希会在本地复用。PPT 里讲到“镜像分层”时这句话是最有力的佐证分层不只是设计磁盘上真的按层存储。2.2 容器运行时与操作系统共享内核的实现容器不是虚拟机没有自己的内核它复用宿主机内核只隔离进程视角。Docker 默认的容器运行时是 containerd底层再调 runc 完成最终的进程创建。这个过程在 PPT 上通常画成三层最上面是用户用docker命令中间是 dockerd 负责解析请求并管理镜像与容器生命周期再往下是 containerd 与宿主机内核交互。实际生产环境里 containerd 也可以脱离 Docker 单独作为 K8S 的运行时这也是为什么很多 K8S 节点上根本看不到docker命令却一样能跑容器。验证这一层关系最直接的办法是在容器内看内核版本和/proc下的关键文件然后对比宿主机。# 查看宿主机内核版本 uname -r # 进入容器后查看容器内看到的内核版本 docker run --rm alpine:3.19 uname -r # 查看容器内挂载的 cgroup 版本 docker run --rm alpine:3.19 cat /sys/fs/cgroup/cgroup.controllers两条命令的内核版本输出完全一致这就是“共享内核”的直接证据。cgroup 文件在容器内是只读的但能看到文件存在说明容器的资源限制是由宿主机内核工具实现的。PPT 上如果画“每个容器内有一个完整 OS”这张架构图就废了正确的画法是宿主机内核与容器之间没有虚线隔开只有 Namespace 和 Cgroup 这一层隔离边界。这里我会顺手讲一个选型理由运行时为什么从 Docker 迁到 containerd。原因是 K8S 从 1.20 起逐步弃用 dockershimkubelet 直接通过 CRI 与 containerd 通信少一层docker命令的转发故障面和调用链都更短。做架构介绍时不需要堆版本号但必须把这个“短链”画出来kubelet - containerd - runc - 宿主机内核。2.3 仓库、网络与数据卷PPT 里最容易画错的三个对象Docker 架构图里镜像仓库、容器网络、数据卷是三个高频出错点。仓库常被画成“下载镜像的地方”实际上它是分发系统支持私有部署、镜像签名和拉取认证网络常被画成一个eth0实际上一个容器至少有 lo 和 eth0 两个网络接口eth0 默认走 bridge 模式数据卷常被画成“容器里的一个目录”实际上卷的生命周期独立于容器容器删了卷还在。把三者并列放在一张表格里对比听众的遗忘率会低很多。下面的表格可以直接搬进 PPT。对象说明生命周期PPT 推荐画法镜像仓库存储与分发镜像的地方支持镜像标签与认证与容器无关独立云状图标标注 Registry容器网络默认 bridge 模式端口映射到宿主机随容器创建销毁容器旁画一个网桥和 eth0数据卷宿主机目录挂载进容器容器内路径与宿主机路径打通独立于容器容器外部画一个硬盘图标用一条命令证明“卷的生命周期独立”最直接。先创建一个卷再启动一个容器挂载它容器删除后卷依然存在。# 创建一个命名数据卷 docker volume create demo-vol # 启动容器并挂载卷到 /data 目录 docker run -d --name demo-container -v demo-vol:/data alpine:3.19 sleep 3600 # 删除容器确认卷仍然存在 docker rm -f demo-container docker volume ls-v demo-vol:/data的语法是卷名:容器内路径。如果卷不存在Docker 会自动创建。容器内往/data写文件宿主机上对应的卷目录里能看到反之在宿主机卷目录放文件容器内也能读。这个特性决定了 K8S 里很多有状态应用的数据恢复逻辑——容器可以随意重建数据不丢。网络部分我只演示一条因为后面讲 K8S Service 时还要深入。docker network ls能看默认三种网络bridge、host、none。跨宿主机网络在单机 Docker 上是不存在的真正解决多机容器互联的是 K8S 的 Overlay 网络。PPT 讲到这一步时我会明确说一句Docker 默认只解决“单机”的容器网络多机容器互联是 K8S 的活。这句话为下一章埋好线。3. K8S 的架构控制面、工作节点与声明式 APIK8S 的架构图比 Docker 复杂得多但对内行来说就两句话控制面决定集群该长什么样工作节点负责让容器真跑起来。这一章先拆控制面四大组件再拆节点代理三件套最后讲清楚声明式 API 和控制器模型。这三块讲完K8S 架构的介绍主体就结束了剩下的网络、存储、高可用都是它们的延伸。3.1 控制面的四个核心组件API Server、etcd、Scheduler、Controller Manager控制面四个组件各有不可替代的职责。API Server 是唯一与外部交互的入口任何人或组件想读集群状态都得走它它负责认证、授权和校验请求。etcd 是集群的“黑匣子”存储所有期望状态和实际状态数据一致性靠 Raft 协议保证。Scheduler 负责把新创建的 Pod 分配到某个工作节点决策依据是节点资源、亲和性、污点等参数。Controller Manager 是一堆控制器的集合比如副本控制器、节点控制器、ServiceAccount 控制器它们不断对比期望状态与实际状态并纠正偏差。这四者的协作关系用一个新建 Deployment 的过程就能讲清楚。用户请求打到 API ServerAPI Server 写一条记录到 etcdScheduler 监听到有新 Pod 需要调度计算后把 Pod 与节点绑定Controller Manager 中的 Deployment 控制器看到副本数不足创建 ReplicaSet再由 ReplicaSet 控制器补齐 Pod。PPT 上我一般画成“用户 - API Server - etcd”的箭头再画 Scheduler 和 Controller Manager 在旁边监听 API Server。用一条命令可以快速看当前集群的控制面状态。kubectl cluster-info会把 API Server 的地址直接打出来。# 查看集群控制面信息确认 API Server 与 CoreDNS 是否健康 kubectl cluster-info # 在三个控制面组件的容器里做健康检查适用于 kubeadm 部署 kubectl get pods -n kube-system -o widecluster-info输出里的Kubernetes control plane行就是 API Server 的访问地址测试环境通常是https://127.0.0.1:6443或类似的内网地址。kubectl get pods -n kube-system能看到 etcd、kube-apiserver、kube-scheduler、kube-controller-manager 是否处于 Running 状态。如果某个控制面组件反复重启第一反应应该是看它的 Pod 日志而不是先重建整个集群。需要提醒的是高版本 K8S 已经废除kubectl get cs查看组件状态的方式新版本里 componentstatuses 接口默认不可用。我一般用kubectl get --raw/readyz或直接看 Pod 状态代替避免在演示时被版本差异卡住。3.2 工作节点上的三个代理kubelet、kube-proxy、容器运行时工作节点上真正干活的三个进程是 kubelet、kube-proxy 和容器运行时。kubelet 是节点上的“管家”它接收 API Server 下发的 Pod 定义调用容器运行时把容器拉起来然后持续上报节点状态和 Pod 状态。kube-proxy 负责维护节点的网络规则最核心的是 Service 的虚拟 IP 转发。容器运行时则是上一章讲的 containerd没有它 kubelet 无法创建容器。这里有一个高频疑惑为什么节点上跑着容器却不用 docker 命令操作答案就在架构上——kubelet 通过 CRI 接口直接与 containerd 通信docker命令只是个客户端可有可无。所以演示时我不主张在 K8S 节点上执行docker ps那会漏掉大量以 containerd 运行时的细节。目前最直观的验证方式是用kubectl get nodes看节点状态再登录节点查看 kubelet 与 containerd 进程。# 查看集群里有多少节点以及每个节点的角色和版本号 kubectl get nodes -o wide # 在任意工作节点上确认三个关键进程存在 systemctl status kubelet --no-pager-o wide会额外显示节点的内网 IP、容器运行时版本和操作系统版本。如果一个节点显示NotReady大概率是 kubelet 与 API Server 的连接受阻这时候排查顺序是先看节点上的 kubelet 日志再看网络策略是否放行 6443 端口最后看容器运行时是否存活。PPT 里我会把这三个进程画在同一台“节点”矩形内矩形外面连一条到 API Server 的实线表示 kubelet 主动向外上报。kube-proxy 的讲解要注意分寸。它管的是 Service 的 ClusterIP 与负载均衡规则传统实现是 iptables新一代是 IPVS。对听众而言只需要记住Pod 的 IP 是 veth 虚拟网卡分配的Service 的 ClusterIP 是虚拟的必须在每个节点上都有转发规则Pod 才能通过 Service 名字互相访问。这条规则是分布式实现不是集中式代理。3.3 声明式 API 与控制器PPT 里讲清“调谐循环”的一组类比声明式 API 是 K8S 区别于早期容器编排工具的核心。用户提交的不是“在节点 A 上启动容器”而是一份“我期望有 3 个副本”的描述文件。系统持续对比这个期望状态和当前实际状态有偏差就自动纠正。这个机制叫调谐循环可以类比成空调恒温器你设定 26 度空调不断感知当前温度低了就加热高了就制冷。在 PPT 上直接讲控制器循环不容易放一个最小 Deployment 文件再现场kubectl apply听众能直观看到“声明”的效果。我会用一个无状态服务它只需要一个对外开放端口的镜像。apiVersion: apps/v1 kind: Deployment metadata: name: demo-web spec: replicas: 3 selector: matchLabels: app: demo-web template: metadata: labels: app: demo-web spec: containers: - name: nginx image: nginx:1.27-alpine ports: - containerPort: 80文件里replicas: 3就是声明期望状态。把这份文件交给 K8S 后控制器会自动保证任何时刻都接近 3 个 Pod 在跑。手动删掉一个 Pod控制器会立刻创建一个新的补位这个“永远拉平”的动作就是调谐循环的最小演示。执行和观察步骤值得一条条做# 应用这份描述文件 kubectl apply -f demo-web.yaml # 等待 Pod 全部就绪 kubectl rollout status deployment/demo-web # 故意删除一个 Pod观察控制器自动重建 kubectl delete pod -l appdemo-web kubectl get pods -o widekubectl apply与kubectl create的区别在这里最容易说明apply 是声明式后续修改只需要更新 YAML 再 apply 一次create 是命令式重跑会报已存在。delete pod -l appdemo-web会删掉所有带该标签的 Pod紧接着get pods能看到一批名字后缀不同的新 Pod它们的AGE只有几秒钟。这个现象强烈说明用户不直接操作 PodPod 是控制器的“产物”。讲到这里PPT 的架构图已经齐了控制面四个组件、工作节点三件套、以及 API Server 与 etcd 之间的状态流。后面再画 Pod、Service、Ingress都是在给这张骨架上添肉。3.4 Pod、Service、Ingress 的关系给架构图补上调度入口这一小节不是可选项。前面讲的是骨架但听众最终看到的是一个 Pod 被 Service 暴露、被 Ingress 接入流量。Pod 是调度的最小单位一个 Pod 里可以有多个容器共享网络和存储Service 是一组 Pod 的稳定访问入口Ingress 是七层转发入口通常对应域名和 URL 规则。三者的关系用一条访问链路说清用户请求域名 - Ingress Controller - Service - Pod。验证链路最稳的方法是在已有 Deployment 上创建 Service。命令运行后看kubectl get svc输出的 ClusterIP 和端口再单独跑一个临时 Pod 去访问。# 暴露 demo-web 的 80 端口为 ClusterIP 服务 kubectl expose deployment demo-web --port80 --target-port80 # 查看生成的 Service 与它的 ClusterIP kubectl get svc demo-web # 启动一个临时 Pod用 wget 访问 Service 名验证服务发现 kubectl run curl-test --imagecurlimages/curl --rm -it --restartNever -- curl http://demo-webexpose生成的 Service 会在集群内部获得一个虚拟 IP同一命名空间内的其他 Pod 可以直接用服务名demo-web访问。--rm参数让临时 Pod 在命令结束后自动删除避免污染演示环境。这段验证放在 PPT 演示环节里非常提气因为它同时证明了服务发现、负载均衡和 DNS 解析三个能力。Ingress 需要在集群里事先装好 Ingress Controller常见的开源实现是 ingress-nginx。PPT 上只需要把链路图标画对不需要现场演示因为本地测试环境经常没有现成域名。我会在图上标注Service 是四层 TCP 负载入口Ingress 是七层 HTTP 路由入口。4. 把 PPT 做成能讲明白的架构叙事从单机到集群的六页递进架构内容拆完接下来是 PPT 的成稿逻辑。上一章的组件是静态知识这一章解决“怎么排序才能让听众跟得上”。我的经验是六页递进一页引子一页边界两页架构一页演示一页学习路径。每一页都有独立使命组合起来就是一个完整的架构介绍。4.1 第一页容器与虚拟机对比回答“为什么要 Docker”如果听众里有没接触过容器的人开篇不能直接砸术语而是回答“为什么要用容器”。最直观的对比对象是虚拟机。表格一放三分钟讲清楚差异。对比项虚拟机容器内核每个 VM 自带一个客户机内核共享宿主机内核启动时间分钟级要引导完整系统秒级直接启动进程隔离级别硬件虚拟化隔离Namespace 与 Cgroup 隔离镜像大小通常数 GB通常数十到数百 MB资源开销每个 VM 都有完整 OS仅包含应用和依赖这一页的核心结论不是“容器比虚拟机好”而是“两者解决不同问题”。虚拟机适合强隔离场景比如运行不受信任的代码容器适合快速交付和高密度部署。PPT 上别把虚拟机画成“笨重”而否掉它听众里一定有人靠虚拟机支撑线上业务一句话否定会引发争辩。技术分享课上的引导思路拿出同一个业务在 VM 和容器上的部署时长对比VM 从模板创建到服务就绪往往 3 分钟起步容器在镜像已拉取的情况下 10 秒内完成。这个对比能直接引到 Docker 的定位把“环境”也打包进交付物里不再有“在我机器上是好的”这类口头禅。4.2 中间页Docker 与 K8S 的职责分界这一页是全篇最容易跑偏的地方。很多人花大量时间讲 Docker 命令又花大量时间讲 K8S 对象唯独没有画出边界。边界其实一句话Docker 负责“在单台机器上把镜像运行为容器”K8S 负责“在多台机器上维持容器的期望规模和网络连通性”。前者是单机进程管理后者是分布式集群调度。我常用一张二分图左边写“单机容器”放 Docker Engine、Image、Container、Volume右边写“集群编排”放 Control Plane、Node、Pod、Service。中间一条粗线表示 K8S 通过 CRI 接口调用容器运行时但不再依赖docker命令。这条线解释了为什么 K8S 节点的常见运行时从 Docker 换成 containerd 而不是反过来。这一页还应该顺手回答一个群聊里反复出现的问题有 Docker 了为什么还要 K8S答案是你的业务跑在一台机器上可以只用 Docker但当你有 10 台机器、需要滚动升级、需要自动拉起宕机节点上的容器时手写脚本维护成本会迅速超过跑一个编排系统。K8S 不是 Docker 的替代品是 Docker 之上的“操作系统”。这个类比可以帮助新手快速定位两套技术的关系。4.3 演示页用 docker desktop 跑通的最小验证命令到了 PPT 的第 5 页必须插入现场演示。演示环境我推荐 Docker Desktop原因是 Windows 和 macOS 上装完即用自带图形界面排错也直观。需要提醒的是 Docker Desktop 在 Windows 上依赖 WSL2 或 Hyper-V如果启动时报“virtualization support not detected”或连接 docker api 的 pipe 错误优先检查 BIOS 里的虚拟化开关和 WSL 版本。演示不要贪多三组命令足够让听众看懂“镜像到容器再到端口访问”的完整链路。# 拉一个轻量 Web 服务器镜像 docker pull nginx:alpine # 启动容器把宿主机 8080 端口映射到容器 80 docker run -d --name demo-web -p 8080:80 nginx:alpine # 查看容器运行状态与端口映射 docker ps第一条命令pull从仓库拉取镜像对应 PPT 里的“仓库”图标。第二条run -d在后台启动容器-p 8080:80的含义是访问宿主机 8080 端口时流量进入容器 80 端口。第三条docker ps展示当前存活的容器与映射关系。如果浏览器打开http://localhost:8080能看到 Nginx 首页整个演示完成。遇到起不来要会读日志docker logs demo-web看容器内部的标准输出和错误输出docker inspect demo-web看配置与挂载。常见状况是端口被占换一个端口即可。PPT 这一页我会放这三条命令的截图旁边标出“拉取”、“启动”、“验证”三个动作分别对应架构图里的哪个环节。4.4 最后一页从单机到集群的学习路径收尾页不能停在演示结束要给出可继续深入的路径。通常分三步第一步把 Docker 跑熟理解镜像、容器、存储和网络第二步用 kind 或 minikube 在本地起一个单节点 K8S对照着跑一遍 Deployment第三步用 kubeadm 或 kubekey 在虚拟机里搭一个多节点集群体验真实调度。学习路径用一张表格列出三个工具的区别。工具适合场景集群规模注意点docker desktop演示与本地调试单节点依赖 WSL2 或 Hyper-VkindCI 与本地测试单节点或多节点用 Docker 容器模拟节点kubeadm生产搭建与考试练习多节点需要提前准备容器镜像这一页的核心价值是让听众带着“下一步做什么”走出会议室而不是带着一堆名词空手而归。我会特别提一句学习 K8S 不要一上来就搭生产级高可用控制面三个节点加外部 etcd 的方案在裸机上踩坑成本很高先用单节点把 Pod、Service、Deployment 的关系玩熟再谈多 master 高可用。5. 架构讲解中的五大避坑从演示环境到生产边界架构知识讲起来容易但演示和实战里有些坑年年有人踩。这一章列五条我遇到过的高频问题每条都按“现象 - 原因 - 解决”的顺序写。你做 PPT 时可以直接把这几条做成“常见疑问”页能省很多答疑时间。5.1 现象把 Docker Swarm 与 K8S 混为一谈导致听众概念混乱有人讲 Docker 架构时顺手提到 Swarm再跳到 K8S听众会以为 Swarm 是 K8S 的一个组件。原因在于 Docker 早期确实自带容器编排功能 SwarmK8S 流行之后 Swarm 的声音变小但旧教程和旧 PPT 仍然在。解决在架构图里明确标注 Swarm 与 K8S 是并列的编排系统不是包含关系。一句话总结Swarm 是 Docker 官方的轻量编排K8S 是云原生生态的主流编排二者选其一即可日常分享聚焦 K8S 就好。5.2 现象在 K8S 节点上用 docker run 启动容器容器莫名其妙退出有人习惯了 docker 命令行到了 K8S 环境还是手动 docker run。启动后容器退出日志也看不到内容。原因K8S 的 Pod 里容器启动后如果主进程退出Pod 会按重启策略不断重启更根本的问题是用户绕过 kubelet 直接操纵运行时这违背了 K8S 的声明式管理方式。解决引导改用 kubectl run 或 kubectl apply 创建 Pod靠 Deployment 管理生命周期。实在要看容器内进程用kubectl exec -it pod名 -- /bin/sh不要在节点上 docker exec。5.3 现象把 etcd 画成外部数据库K8S 集群重启后状态丢失PPT 架构图里有人为了突出数据存储把 etcd 画在集群外部一个独立框里看起来像独立的中间件。这个画法本身没错但会导致听众以为 etcd 可以单独运维而不影响 K8S。实际 etcd 是控制面的一部分存着所有集群状态etcd 挂了集群就失去读写能力。解决架构图把 etcd 放在控制面框内但标注“建议独立部署或至少独立存储”。生产环境如果担心高可用把 etcd 放到单独节点上但不要画成“与 K8S 无关的数据库”。5.4 现象Docker Desktop 启动失败报错含 virtualization support not detected 或 npipe 连接失败Windows 上启动 Docker Desktop 常见两类报错。一类是“virtualization support not detected”原因多为 BIOS 未开启虚拟化或 WSL2 内核未更新另一类是“failed to connect to the docker api at npipe://...”原因多为 Docker Desktop 引擎没起来或版本与 Windows 系统不匹配。解决先开 Windows 功能里的“虚拟机平台”和“适用于 Linux 的 Windows 子系统”再执行wsl --update最后重启 Docker Desktop。如果还不行把 Docker Desktop 的 Engine 从 WSL2 切到 Hyper-V 再切回来强制重建虚拟交换机。5.5 现象画高可用架构时只画三个 master忽略 etcd 仲裁与网络分区很多人画 K8S 高可用画三个控制面节点就完事但没提 etcd 的仲裁规则。etcd 在 quorum 模式下三节点最多容忍一个节点故障网络分区时如果多数派节点选不出 leader整个集群会拒绝写入。解决PPT 上高可用章节要加一行说明etcd 的高可用比控制面组件的高可用更敏感必须关注心跳间隔与磁盘延迟。另外尽量别在生产环境用三个 master 共用一个存储的方案etcd 的数据目录独立且定期备份才是防丢状态的唯一后悔药。6. 用一张可验证的架构图收尾我的检查清单与两个验证技巧前面五章已经把 Docker 与 K8S 的架构拆完最后分享我在分享前必做的两个验证动作。它们不复杂但能在开讲前把“图纸”和“实物”对齐避免讲完架构图结果演示翻车。第一个验证动作是开讲前一天在本地跑一遍最小集群观察链路。我的习惯是先用 kind 创建集群再用kubectl get nodes -o wide与kubectl get pods -A确认节点与控制面组件全部正常。然后手动创建一个 Deployment故意删除 Pod看它自动重建。这一个动作同时验证了 API Server、Scheduler、Controller Manager、kubelet 和容器运行时五条线只要重建成功说明整个控制链路是通的。# 用 kind 创建临时集群注意映射 80 端口便于访问 kind create cluster --name demo # 等待集群就绪后检查节点与控制面 Pod kubectl get nodes -o wide kubectl get pods -n kube-system # 创建一个 Deployment 并观察自动重建 kubectl create deployment demo --imagenginx:alpine --replicas2 kubectl scale deployment demo --replicas3第二个验证动作是检查 Service 的访问链路。我会新开一个临时 Pod 去访问 ClusterIP验证集群内部 DNS 与服务发现生效。经验上这一步最容易暴露网络插件问题如果临时 Pod 访问不到 Service优先检查 kube-proxy 是否以 IPVS 模式运行、节点是否有防火墙拦截。用kubectl describe svc查看 Endpoints 列表确认后端 Pod 的 IP 都挂在 Service 下面链路就大概率是通的。做完这两步我对架构图的每个组件都有了实感。后面在 PPT 上无论怎么简化图形都会坚持一条控制面必须画 API Server 与 etcd 的强关联工作节点必须画 kubelet 与容器运行时的调用链Docker 只占据“单机容器运行时”这一段。这套讲法我用了两年每次听众提出“Pod 重建了IP 变了怎么办”“Service 和 Deployment 谁先创建”这类问题都能顺着这张图找到答案。希望帮到你。本文还有配套的精品资源点击获取