简介《DockerK8S架构介绍》PPT面向容器云入门者与需要系统梳理架构的技术人员内容以虚拟化架构对比开篇解释了全虚拟化、OS层面虚拟化与平台硬件层虚拟化的差异并通过资源抽象、共享资源池等视角帮助理解容器技术诞生的背景。随后进入Docker部分介绍其基于LXC的轻量级容器引擎定位详细说明命名空间实现环境隔离、cgroups限制资源使用、AUFS分层文件系统组织镜像同时涵盖镜像、容器、仓库三大核心对象及常用操作命令让读者能快速上手基础操作。后半部分介绍Kubernetes作为分布式系统支撑平台的主要能力包括集群管理、安全防护、服务注册发现、智能负载均衡、故障发现与自愈、滚动升级、资源自动调度与多粒度配额管理帮助建立从单机容器到集群调度的完整认知。资源包内为1个PPTX演示文稿压缩包容量6.29MB图文结合、目录清晰适合技术分享、课程培训或自学速览。目前已有934人学习下载对快速理解Docker与K8S架构要点有较高参考价值。1. Docker 与 K8S 这份架构资料先看懂三个反直觉结论这份 Docker 与 K8S 架构介绍 PPT 我拆了两遍。第一遍觉得它就是虚拟化、容器、编排三章科普第二遍才反应过来它把 Docker 能火的原因讲透了——容器不是更轻的虚拟机而是把进程从「跑在操作系统里」改成「跑在分层镜像里」再把多台机器的资源统一交给 Kubernetes 调度。读者如果是准备给团队做容器化分享、做技术答辩或者刚接手 K8S 集群想补架构底子这份资料可以直接当讲义骨架。下面按「虚拟化分水岭 → Docker 原理 → 基本操作 → 避坑 → K8S」的顺序把关键参数和坑都补上。2. 虚拟化三架构全虚拟化、OS 层虚拟化与平台级虚拟化的分水岭2.1 虚拟化之前与之后资源从「独立」到「共享池」虚拟化是一种资源管理技术把服务器、网络、内存、存储这些实体资源抽象出来打破「一台物理机只能给一个应用用」的约束。材料里那张「虚拟化前/后」对比图把逻辑说得很直白虚拟化前操作系统与硬件紧密耦合一台机器上的资源互相独立一个业务吃不满就浪费虚拟化后资源被抽象成共享资源池上层系统从池子里动态申请分配密度和灵活性都上来了。这个「池化」概念是整个 PPT 的底层逻辑后面的 Docker 和 K8S 都建立在它上面。2.2 三种虚拟化架构轻量级、重量级与直通型材料把虚拟化架构分成三类全虚拟化架构、OS 层面虚拟化架构、平台硬件层虚拟化架构。这三类在隔离粒度、性能开销和使用场景上是三个方向我按常见落地方案给你对齐一下全虚拟化架构Guest OS 不知道自己跑在虚拟化环境里指令由 hypervisor 翻译或捕获执行。典型代表是 QEMU 软件模拟、VMware Workstation。兼容性好、隔离性强但指令翻译开销大适合需要完整系统环境、对性能不敏感的桌面虚拟化场景。OS 层虚拟化架构宿主机内核被多个隔离环境共享进程看起来在自己独立空间里运行实际上共用宿主内核。典型代表是 LXC、Docker。启动秒级、内存开销小但容器内不能运行与宿主不同内核的系统。平台硬件层虚拟化架构hypervisor 直接跑在硬件上利用 CPU 的 VT-x/AMD-V 硬件辅助虚拟化。典型代表是 KVM、Xen、VMware ESXi。性能最接近物理机是数据中心里虚拟机的主流底座。架构类型隔离粒度内核典型代表性能开销全虚拟化内核级每台 Guest 独立QEMU、VMware Workstation高OS 层虚拟化进程级共享宿主机内核LXC、Docker极低平台硬件层虚拟化内核级每台 Guest 独立KVM、Xen、ESXi低2.3 为什么 Docker 属于 OS 层虚拟化共享内核是省资源的根源材料把 Docker 放在 OS 层虚拟化这一类里这个归档非常关键。Docker 容器和宿主机共享同一个 Linux 内核不像虚拟机那样每个 Guest 都要带一套完整内核所以容器启动不用走 BIOS、不用引导内核内存只算应用本身。代价是容器里进程依赖的内核模块必须和宿主内核兼容否则容器可能起来就退出。我见过不少人把 CentOS 7 主机上跑 Debian 镜像遇到的问题归咎于 Docker其实根因是共享内核带来的版本边界没看清。2.4 从虚拟化到容器的选型判断选 VM 还是选容器我一般用三个硬指标判断需要不同操作系统内核共存比如 Windows 和 Linux 混布在同一台物理机上就上 VM业务要秒级扩容、弹性伸缩、按实例数横向扩就上容器要 GPU 直通、高性能计算虚拟机或裸机更合适。材料里那句「虚拟化作用能充分利用资源」后面跟着一个追问装了多个操作系统能否同时运行答案是不一定因为资源分配取决于调度机制不是装了虚拟机就能最大化利用硬件。这段话放在 PPT 最前面是为了铺垫后面 Kubernetes 要解决的问题单机装虚拟机解决不了集群层面的资源调度容器编排才是答案。3. Docker 原理拆解namespace、cgroups 与 AUFS 分层文件系统这一章是材料知识点最密的部分。Docker 是一个基于 LXC 技术之上搭建的 Container 容器引擎Go 语言实现Apache 2.0 协议开源实现了应用级别的资源隔离与配额。材料给的三个核心概念是镜像、容器、仓库镜像是一组特殊文件用来创建容器容器是镜像创建的运行实例可被启动、停止、删除仓库是集中存放镜像文件的场所分公有仓库和私有仓库。这套三分法贯穿 Docker 全部操作先记住它后面命令都好理解。3.1 namespace进程眼中的「独立世界」Docker 使用 Linux namespace 隔离运行环境让容器里的进程「看起来」像在一个独立操作系统中运行。实际 namespace 不止一层PID namespace 隔离进程编号net namespace 隔离网络栈mount namespace 隔离挂载点UTS namespace 隔离主机名IPC namespace 隔离进程间通信。容器里执行ps看不到宿主机其他进程就是 PID namespace 在起作用。用大白话说namespace 负责「看不见」——把进程关进一个只有自己视角的隔间里。验证 namespace 效果最直接的方式是进入容器看进程列表# 运行一个容器并查看容器内的进程 docker run -d --name test nginx:alpine docker exec test ps -ef这段命令先启动一个 nginx 容器再用exec进入容器执行ps -ef。对比宿主机上执行ps -ef的结果你会发现容器内的 PID 列表短得多而且所有进程的 PID 空间是独立的。exec是进入运行中容器执行命令的标准方式后面调试容器时基本离不开它。3.2 cgroups限制资源不是靠自觉材料原文点了一句只有 namespace 隔离还不够进程仍然可能不受限制地使用系统资源所以 Docker 用 Linux cgroups 限制容器中进程允许使用的 CPU、内存等资源。这条逻辑是判断一个人是否真懂 Docker 的分水岭——隔离负责「看不见」配额负责「抢不过」。两个机制一配合容器才能既安全又不拖垮宿主机。# 限制容器最多使用 1.5 个 CPU 核心和 512MB 内存 docker run -d --name c1 --cpus1.5 -m 512m nginx:alpine--cpus传入的是核心数支持小数-m传入内存上限超限后进程可能被 OOM Killer 杀掉。这两个参数是生产环境最常用的配额手段。如果业务流量涨了直接docker update --cpus2 -m 1g c1在线调整不用重建容器。3.3 AUFS 分层文件系统镜像为什么能「一次构建到处运行」材料里 AUFS 这段值得细读。AUFS 是一种 Union FS支持把不同目录挂载到同一个虚拟文件系统下。Docker 镜像就利用这个特性做了分层每一层镜像下面一层称为父镜像第一层叫 Base Image容器运行在最顶层下面的所有层都是只读的只有容器层可写。这个设计带来两个直接好处一是多镜像可以共享底层只读层磁盘占用大幅减少二是构建镜像时每层都有缓存改一层只重建一层不用全部重来。容器在最顶层、下层全部只读这意味着一件事删除容器不会影响镜像本身更不会影响下面的只读层。这是新人最容易产生误解的地方以为容器退出了镜像就没了。镜像还在换一个容器实例几秒钟就能再拉起来。3.4 Docker 与虚拟机的本质差别材料里放了 Docker 和 VM 的对比图核心就一句话——VM 里跑的是完整操作系统Docker 里跑的是带着自己文件系统的进程。虚拟机要多占一套内核和系统资源容器只多占几个 namespace 和 cgroups 管理条目。这就是「容器性能开销极低」的来源。对比项虚拟机Docker 容器启动速度分钟级秒级内存占用每台 Guest 一套完整 OS只算应用进程隔离粒度内核级进程级 内核共享内核Guest 独立内核共享宿主机内核打包分发镜像文件大分层镜像复用率高4. Docker 实操入门镜像与容器常用操作命令与参数说明材料在基本操作部分给了三大核心对应的命令镜像操作、容器操作、仓库操作。下面按实际使用频率把命令串起来照着敲就能把一套容器环境跑通。4.1 镜像操作列表、拉取、搜索与删除# 查看本地镜像列表 docker images # 拉取镜像明确标签避免踩 latest 的坑 docker pull centos:7 # 搜索仓库中的镜像 docker search tomcat # 删除指定镜像 docker rmi centos:7docker images会列出仓库名、标签、镜像 ID、创建时间和大小是排查本地环境的第一步。docker pull默认从 Docker Hub 拉取标签不写时默认取latest。注意latest不是版本号它只是默认指针不同时间点拉到的内容可能完全不同生产环境务必写明标签。rmi是 remove image 的缩写只能删除没有被容器引用的镜像否则会报错具体处理方式放在下一章避坑清单里。4.2 容器生命周期创建、查看、停止与删除# 创建并启动一个交互式容器退出后容器停止 docker run -it --name c1 centos:7 /bin/bash # 查看当前运行的容器 docker ps # 查看所有容器包括已退出的 docker ps -a # 删除一个容器 docker rm c2-i表示保持标准输入打开-t分配一个伪终端两个参数配合才能进入交互式 shell--name给容器起名方便后面用名字操作。docker ps只显示运行中的容器排错时习惯性加-a才能看到那些启动失败、已退出的容器它们的退出状态码是判断问题的关键线索。docker rm只能删已停止的容器运行中容器要先docker stop再删。4.3 容器调试三板斧exec、logs、inspect容器起不来、起起退退是高频故障调试基本靠三个命令# 进入运行中的容器执行命令 docker exec -it c1 /bin/bash # 查看容器最近 50 行日志 docker logs --tail 50 c1 # 查看容器完整配置和状态 docker inspect c1docker exec是在不打断容器运行的前提下进容器排查比attach更可控适合看进程、测网络。logs加--tail只看最近日志避免日志刷屏容器疯狂重启时一般先看日志里最后几行MySQL、Nginx 这类镜像的初始化错误都会打在这里。docker inspect输出 JSON 结构重点看 State 字段里的 Status、ExitCode、Error 三项退出码 137 通常是内存超限被 OOM退出码 1 多半是应用启动时配置错误。4.4 镜像搬运离线环境用 save 与 load内网环境不能直接访问 Docker Hub 时镜像搬运是必备技能# 导出镜像为 tar 包 docker save -o centos7.tar centos:7 # 在目标机器导入镜像 docker load -i centos7.tar-o指定输出文件路径-i指定输入文件。save对镜像打包load把包导入本地镜像库。要注意save和export不一样save保留镜像分层结构和标签信息load后能直接用export只导出容器文件系统会丢历史层导入后无法追溯镜像来源。离线交付我通常用save而不是export。5. 落地避坑Docker Desktop 启动失败、镜像拉取慢与权限报错下面这几条是这两年团队工单里高频出现的翻车现场按「现象 → 原因 → 解决」的格式写。架构 PPT 讲得再漂亮落地时被这几个坑绊倒的大有人在。5.1 启动失败Docker Desktop 报 virtualisation support wasnt detected现象Windows 上双击 Docker Desktop等待后提示 failed to start because virtualisation support wasnt detected任务栏图标一直转圈。原因CPU 的虚拟化功能没开启或者 Windows 的「虚拟机平台」组件没启用。Docker Desktop 依赖 Hyper-V 或 WSL2 后端这两者都需要 CPU 虚拟化指令支撑。解决重启进 BIOS/UEFI开启 Intel VT-x 或 AMD-V在 Windows 功能里勾选「虚拟机平台」和「适用于 Linux 的 Windows 子系统」然后以管理员身份执行bcdedit /set hypervisorlaunchtype auto重启后再启动 Docker Desktop。检查任务管理器「性能」页的虚拟化状态确认显示「已启用」才算过这一关。5.2 权限报错permission denied while trying to connect to the docker api现象Linux 上执行docker ps报 permission denied while trying to connect to the docker api加了sudo又正常。原因docker 命令走的是/var/run/docker.sock这个 Unix socket当前用户不在 docker 组里socket 的权限不允许你的用户访问。Ubuntu、CentOS 上装完 Docker 后最常见的坑就是这个。解决把当前用户加入 docker 组然后重新登录会话sudo usermod -aG docker $USER newgrp dockernewgrp docker让当前终端立即生效不用退出重连。如果你用的是远程 SSH新的 SSH 会话也会带上 docker 组权限。加入 docker 组等于把 root 权限开放给了这个用户生产环境要认真评估再操作。5.3 镜像下载慢从 Docker Hub 拉取卡住不动现象docker pull centos:7卡在等待状态进度条几乎不动最后超时失败。原因默认从 Docker Hub 官方源拉取网络链路不稳定或受限。这是国内环境最普遍的问题不是 Docker 本身的问题。解决配置镜像加速。编辑/etc/docker/daemon.json写入镜像源配置然后重启 Dockersudo tee /etc/docker/daemon.json EOF { registry-mirrors: [https://mirror.example.com] } EOF sudo systemctl restart docker注意两个点一是加速器地址是会流动的正规渠道维护的地址列表要定期核对不要长期依赖某个具体域名二是配置只对之后pull的镜像生效之前没拉下来的镜像要重新拉。改完配置后建议先执行docker info看 Registry Mirrors 段落是否生效确认完再大规模拉镜像。5.4 MySQL 容器起不来端口、权限与架构三连坑现象执行docker run -d -p 3306:3306 mysql容器几十秒后退出了docker logs报错或直接看不到有用日志。原因常见有三个为主的场景。一是宿主机 3306 端口被本机 MySQL 或其他进程占用容器端口绑定冲突二是用-v挂载数据目录时目录权限不对MySQL 进程期望的 uid 和宿主机目录属主不一致三是机器架构和镜像架构不匹配比如 ARM 平台默认拉取到了 x86_64 的镜像进程起不来。解决先换端口用-p 3307:3306试跑能起来基本说明端口冲突挂载目录先chown到 MySQL 官方镜像的 uid一般 999ARM 机器拉镜像时显式指定平台docker pull --platform linux/amd64 mysql。镜像本身是分层打包的架构产物拉错了架构就像往 Windows 机器上装 Linux 的 exe跑不起来的。5.5 删除镜像失败image is being used by container现象docker rmi nginx:latest报错 image is being used by container明明docker ps看不到任何容器在运行。原因docker ps默认只显示运行中的容器那些已经退出但没删除的容器仍然引用着镜像镜像的引用计数不为零不能删除。解决docker ps -a找到引用该镜像的容器先删容器再删镜像docker ps -a --filter ancestornginx:latest docker rm container_id docker rmi nginx:latest有一种省事的做法是docker rmi -f强制删除但我不建议这么干。强制删除会把镜像从本地库移除遗留的容器会变成「悬空」状态后续无法正常操作还占着磁盘空间。这个后悔药不太好买先清容器再删镜像流程上多一步但干净。6. 从 Docker 到 Kubernetes用一份验证清单理解集群自愈Docker 解决「一台机器上的进程如何隔离、分发、运行」Kubernetes 解决「多台机器上的容器如何调度、服务发现、自愈」。材料里列的 K8S 能力——透明的服务注册与服务发现、内建智能负载均衡、故障发现与自我修复、服务滚动升级与在线扩容——对应到操作上其实就是一套可以反复演示的验证清单# 1. 查看集群节点是否就绪 kubectl get nodes # 2. 创建一个 nginx 工作负载 kubectl create deployment nginx --imagenginx:1.25 # 3. 扩容到 3 个副本 kubectl scale deployment nginx --replicas3 # 4. 删掉一个 Pod观察控制器是否自动重建 kubectl delete pod nginx-xxxx第 4 步是整个演示最直观的部分删掉一个 Pod几秒钟后kubectl get pods里会出现一个新 Pod状态从 ContainerCreating 变 Running。这个「删了又活过来」的动作比任何架构图都更能讲清楚 Deployment 控制器的自愈循环。要验证滚动升级用kubectl set image deployment nginx nginxnginx:1.26 --record触发新版本发布再用kubectl rollout status deployment nginx观察更新过程。这份 PPT 的定位是架构认知不是安装手册。真正把它落到自己环境里还差三步操作装好 Docker 后先跑一次docker run hello-world验证引擎按第 5 章把镜像源配置好再拉大镜像最后用 minikube 或 kind 把 Kubernetes 控制面跑起来复现上面这条验证清单。这几年每次给团队做容器化分享最后一页我都放这四条命令反馈比任何架构图都直观。从那以后我做的每一份容器化讲义都强制走一遍「先讲隔离、再讲分发、最后讲调度」的顺序希望帮到你。本文还有配套的精品资源点击获取
