一台物理机扛着十来个服务CPU 常年趴在三成以下内存却天天在 90% 边缘晃悠磁盘 IO 一有备份任务就全线卡顿——这种场景我见过太多次。后来大部分团队的选择都是同一套组合拳把重活拆进 Linux 虚拟化里跑把轻活塞进容器化里跑。虚拟机给的是完整的系统边界容器给的是秒级的交付速度两者不是替代关系而是分工关系。这篇东西只聊这两条线在 Linux 上到底怎么落地底层靠什么机制隔离、参数怎么算、命令怎么写、跑起来之后哪些坑一定会踩。不管你是刚接手一台要改造成宿主机的运维还是写业务代码想搞清楚自己那点资源为啥老被抢的开发下面的内容都能直接照着抄。我会把 KVM、QEMU、libvirt 这一套虚拟化链路的职责拆开讲也会把 namespace、cgroup、联合文件系统这层容器地基挖到底最后落到能跑的实验环境和一份排查速查表上。1. 先把边界划清楚虚拟化与容器化各自解决的问题1.1 从一台被浪费的物理机说起早年间一个服务上线标准动作就是申请一台物理机装系统、配环境、把进程拉起来。问题在于绝大多数业务对硬件的胃口远没有想象中大一个内部管理系统吃掉 8 核 32G实际负载连 10% 都用不到剩下 90% 就那么闲着。为了把这些碎片榨出来最直接的想法是一台上跑多个系统于是就有了虚拟化。虚拟机管理器把物理 CPU、内存、磁盘、网卡切成若干份每份包装成一台看起来完全独立的机器里面装自己的内核、自己的驱动、自己的用户态。对这个系统来说它根本不知道自己在共享硬件。这条路解决了资源利用率但也带来了新麻烦每台虚拟机都要跑一个完整内核启动慢占用固定镜像动辄几个 G。一个只跑单个二进制的小服务为了它开一台虚拟机性价比很低。容器化的思路就换了方向不虚拟硬件直接复用宿主内核只把进程看到的世界隔离开——它看到的文件系统、进程表、网络栈、主机名都是独立的一套但底下跑的还是同一个内核。所以容器启动是毫秒级镜像可以做到几十兆。理解这条分界线特别重要虚拟化隔离的是硬件容器隔离的是视图。1.2 硬隔离与软隔离两种思路的本质差异虚拟机里的进程访问内存要经过一层由硬件辅助的地址翻译物理页框的分配权完全在虚拟机管理器手里容器里的进程访问内存走的是宿主内核正常的页表只是被 cgroup 记了一笔账超了就杀。这是两者安全边界的根本区别也决定了它们能用在什么场景。虚拟机里跑一个恶意程序它想突破出去得先攻破虚拟化层难度很高容器里跑一个以 root 身份启动的进程如果没做用户命名空间映射它和宿主上的 root 之间只隔着几层配置。我用一个生活化的比喻虚拟机像是一栋楼里隔出来的独立公寓有自己独立的门户、水电表、承重墙容器像是同一间大开间里用隔断分出来的工位桌子椅子各归各但空调、电路、消防系统是共用的。工位区省钱、灵活、搬起来快但一旦有人点了火整层都跑不掉。所以真正生产环境里的常见形态是混合底层虚拟机负责硬隔离和运维边界上层容器负责应用交付容器跑在虚拟机里而不是直接跑在裸机上。1.3 选型判断什么场景该选哪条路判断维度倾向虚拟机倾向容器需要跑不同内核版本或非 Linux 系统是否单实例启动时间要求秒到分钟级可接受毫秒到秒级多租户且互不信任是需额外加固应用打包与交付频率较低很高资源碎片利用率中等高需要完整系统级调试能力是受限我自己的判断顺序是先看有没有内核态需求自定义内核模块、特定内核参数、非 Linux 系统有就必须虚拟机再看交付节奏如果一天要发好几次版本而每次发版都在配环境上耗时间那就该容器化最后看信任边界凡是多租户、对外暴露、跑不可信代码的场景宁可多花点资源上虚拟机。剩下那些内部服务、无状态、可以随时重建的容器是最省心的选择。2. 虚拟化这条线从硬件指令到一块能用的虚拟磁盘2.1 全虚拟化与半虚拟化的取舍早期没有硬件辅助时虚拟机里的特权指令没法直接执行得靠二进制翻译动态改写成安全调用性能损耗相当可观。后来 CPU 厂商在硬件层面加了支持把处理器分成宿主模式和客户模式客户机执行特权指令时会触发陷入由虚拟机管理器接管处理这就是常说的硬件辅助虚拟化。你在/proc/cpuinfo里看到的vmx对应一类 CPU或svm对应另一类 CPU就是这项能力的标志位。半虚拟化走的是另一条路不假装自己是真硬件而是让客户机知道自己被虚拟了主动配合。典型做法是客户机装上专门的驱动把磁盘和网络的 IO 请求通过共享内存加通知机制直接递给宿主绕开昂贵的设备模拟。现在这套思路基本都以 virtio 的形式存在virtio-blk 负责磁盘virtio-net 负责网卡。所以实践中我的默认配置就是硬件辅助虚拟化打底、virtio 驱动加速 IO这是性能与兼容性最平衡的组合只有在装一些老系统、缺 virtio 驱动时才回退到模拟 IDE 或 e1000 网卡。2.2 KVM、QEMU、libvirt 三者到底谁管什么刚接触这块最容易把三个东西搞混。KVM 是内核里的一个模块加载后让内核具备创建虚拟处理器、管理客户机内存的能力它只管 CPU 和内存这两块最核心的资源QEMU 是一个用户态程序负责模拟磁盘控制器、网卡、串口、显卡这些设备并负责整个虚拟机的生命周期它调用 KVM 的接口来跑客户机代码libvirt 则是一层管理层提供统一的接口和守护进程把配置落到 XML 文件里屏蔽掉不同虚拟化后端和不同版本的差异。分工用一句话概括KVM 管算力和内存QEMU 管设备和组装libvirt 管配置和生命周期。日常运维基本只跟 libvirt 打交道用virsh敲命令用 XML 描述虚拟机真正排查深层次问题时才会下潜到 QEMU 的日志和进程参数。这个分层的好处很明显你的虚拟机定义是一份可版本管理的 XML换机器、改参数、做快照都不需要重新记一套命令。注意QEMU 以什么身份跑很关键。默认走非特权用户加若干辅助组的方式比直接以 root 运行安全得多但如果你要用桥接网络或直通设备就可能需要调整权限组而不是直接把整个进程提权。2.3 CPU 与内存参数怎么算CPU 分配的核心概念是 vCPU 数量与超分比。假设宿主是 32 个逻辑核你要跑 8 台虚拟机每台给 4 个 vCPU加起来正好 32超分比 1:1这是最保守也最稳的做法。如果业务是典型的 Web 服务大部分时间在等 IO把超分比放到 1:3 甚至 1:4 也常见代价是高峰期客户机里的%ststeal time会升高表现出来就是莫名卡顿。判断超分是否过头的直接办法是进到客户机里看top的首行或vmstat 1的st列。我的经验阈值是st稳定在 3% 以内无所谓5% 到 10% 需要观察业务 RT长期超过 15% 就得收敛超分比或者迁走负载。另外同一台宿主机上尽量别把 CPU 密集型的虚拟机堆在一起业务错峰比调参数更有效。内存这边超分比一般控制在 1.2 到 1.5 倍前提是开启内存回收机制。常用手段有三个内存气球让客户机在内存宽裕时把页还给宿主页共享合并把多台虚拟机里内容相同的页比如相同的内核镜像合并成一份交换。前两个默认行为就够用第三个要谨慎宿主机一旦开始大量换页所有虚拟机的延迟会一起飙升。计算示例如下宿主 128G预留 8G 给系统可用 120G按 1.25 倍超分可以分配出去的客户机内存总量约 150G也就是能开 9 台 16G 的虚拟机。这个数字不是让你去顶格用而是给你一个规划上限。2.4 存储格式与网络模式的选型磁盘格式上raw就是一块裸的稀疏文件少一层映射读写路径最短性能最好但不支持快照扩容也麻烦qcow2支持写时复制、快照、压缩、后端文件链功能齐全代价是多一层地址转换和元数据开销。我的做法是数据库这类对 IO 敏感、不需要频繁快照的用raw配预分配普通业务机用qcow2创建时把preallocation设成metadata让元数据提前落盘避免写入时反复分配造成抖动。网络模式三种最常见默认的 NAT 网络宿主做转发客户机可以出外网但外部访问不进来适合做实验桥接网络客户机直接拿到与宿主同网段的地址对外就像一台独立机器生产环境多用这种还有直通类方案把物理网卡或虚拟功能直接分配给客户机性能最好但配置复杂、迁移受限。选哪种先问一句这台机器需不需要被别人直接访问需要就桥接不需要就 NAT别一上来就折腾直通。3. 容器化这条线命名空间与 cgroup 才是真正的地基3.1 六种命名空间划出的隔离边界容器的独立感全部来自命名空间。挂载命名空间让进程看到自己的文件系统树别人的挂载点它看不见进程命名空间让它以为自己是 1 号进程看不到宿主上其它进程网络命名空间给它独立的网卡、路由表、端口空间IPC 命名空间隔开消息队列和共享内存UTS 命名空间让它有自己的主机名用户命名空间做 UID 映射可以把容器里的 root 映射成宿主上的普通用户这是提升安全性的关键一招。除了这几个新版本内核还多了 cgroup 命名空间让容器内看到自己的资源视图和时间命名空间。我在实际排障时最常用的是网络和挂载这两个想知道容器里的端口到底映射到哪就进它的网络命名空间看想知道某个文件是从镜像层来的还是运行时挂进去的就进挂载命名空间看挂载表。这些能力都由内核提供跟具体用哪个运行时无关抓住这一点任何容器工具在你眼里都是一层壳。3.2 cgroup 如何把资源限额真正落实命名空间负责看不见cgroup 负责用不多。它把进程分组然后按组统计和限制资源。现在主流已经切到 v2 版本各项限制集中在一个统一层级下路径一般是/sys/fs/cgroup/。常用的几个控制文件值得记住cpu.max用配额 周期的形式限制 CPU 时间例如50000 100000表示每 100ms 周期内最多用 50ms等价于半个核cpu.weight是相对权重只在争抢时起作用memory.max是硬上限超了触发回收回收不动就杀进程memory.high是软上限超了先限速pids.max限制进程与线程总数防 fork 炸弹io.max按设备限制带宽和 IOPS。这里有个特别容易忽略的点cpu.max限制的是时间片总量一个多线程程序照样能瞬间打满所有核再被节流表现出来的现象是CPU 使用率被压在 50%但响应时间抖得厉害。解决办法不是简单调大配额而是先确认业务是不是真的需要那么多并行度很多时候把线程池调小比加配额更有效。3.3 联合文件系统与镜像分层镜像之所以能小、能快、能复用靠的是分层。每一层是一个只读的文件系统快照多个层叠起来形成最终视图最上面再加一层可写的薄层给容器运行时用。读文件时自顶向下找找到就停写文件时先复制到可写层再改这叫写时复制。所以同一份基础层被一百个容器共享磁盘上只存一份。这套机制有两类实际影响必须提前知道。第一容器删了可写层的数据就没了所有需要持久化的东西必须显式挂出去。第二大量写小文件会触发频繁的复制上抬性能比直接写裸盘差不少所以数据库这类写密集负载我从不放在容器的可写层里跑要么挂卷要么干脆用虚拟机。构建镜像时也要顺着这个逻辑来变化频率低的放前面变化频率高的放后面让缓存尽可能命中构建时间能从几分钟压到十几秒。3.4 手动创建一个最小容器看清全貌光看概念容易飘不如自己捏一个。下面这段操作不需要任何容器运行时只用内核接口就能让一个进程活在自己的世界里# 准备一个最小根文件系统目录 mkdir -p /tmp/miniroot/{bin,proc,sys,dev} cp /bin/busybox /tmp/miniroot/bin/ 2/dev/null || cp /bin/sh /tmp/miniroot/bin/ # 用 unshare 创建新的命名空间再切根 unshare --mount --uts --ipc --pid --net --fork \ chroot /tmp/miniroot /bin/sh -c hostname mini; mount -t proc proc /proc; ps aux执行完你会看到主机名变了进程表里只有自己。原理就是先把几类命名空间新建一份再用chroot换掉根目录最后挂上/proc。真实运行时要做得更细致用pivot_root替代chroot避免逃逸用 cgroup 把资源限制挂上用 capabilities 砍掉不需要的特权用 seccomp 收紧系统调用。但骨架就是这几步理解了它再看各种运行时的高阶参数就不会发懵。4. 实操落地搭一套能跑起来的实验环境4.1 宿主机的前置检查与准备第一步永远是确认硬件能力有没有打开。有些机器在固件里默认关闭了虚拟化支持装完系统才发现起不来白折腾半天。# 1. 确认 CPU 支持硬件虚拟化 grep -Eoc (vmx|svm) /proc/cpuinfo # 结果大于 0 才可用 # 2. 确认内核模块加载 lsmod | grep -E kvm|vfio # 3. 确认内核版本支持所需特性 uname -r # 4. 看 IOMMU 是否开启需要设备直通时才用 dmesg | grep -i -e DMAR -e IOMMU | head如果第一项是 0去固件设置里找虚拟化相关的开关打开这一步绕不过去。模块没加载就手动modprobe kvm再根据 CPU 类型加载对应的子模块。装管理工具时按发行版系别来deb 系用apt装qemu-system、libvirt-daemon-system、virtinst这一套rpm 系用dnf装对应的包组。装完把当前用户加到 libvirt 相关组里然后systemctl enable --now libvirtd并检查virsh list --all有没有正常响应。提示如果你打算跑桥接网络提前把网桥规划好不要等虚拟机装完了再改网络。改网络的代价是全部虚拟机重启而且容易配错导致失联。4.2 用 libvirt 创建并调优一台虚拟机命令行建机器比图形界面可控得多参数写清楚以后复现也方便。# 创建一块 qcow2 磁盘40G 容量元数据预分配 qemu-img create -f qcow2 -o preallocationmetadata /var/lib/libvirt/images/demo01.qcow2 40G # 建虚拟机4 vCPU / 8G 内存 / virtio 磁盘与网卡 virt-install \ --name demo01 \ --memory 8192 \ --vcpus 4,sockets1,cores2,threads2 \ --cpu host-passthrough \ --disk path/var/lib/libvirt/images/demo01.qcow2,formatqcow2,busvirtio,cachenone \ --network networkdefault,modelvirtio \ --graphics none \ --console pty,target_typeserial \ --cdrom /var/lib/libvirt/images/install.iso \ --os-variant detecton几个参数值得单独解释。--cpu host-passthrough让客户机直接看到宿主的 CPU 特性性能最好代价是这台机器不能跨不同型号的宿主迁移如果要做集群迁移改成具体的 CPU 模型名。cachenone绕过宿主页缓存把缓存交给客户机自己管写密集场景更稳但要配合ionative才有意义。--vcpus后面那串拓扑不是装饰它决定了客户机内核怎么组织调度域跟宿主拓扑对齐能减少跨 NUMA 访问。装完之后用virsh dominfo、virsh domblklist、virsh domiflist逐项核对别凭感觉认为配对了。日常操作就那么几条virsh start、virsh shutdown、virsh reboot、virsh snapshot-create-as打快照、virsh edit改配置改完要关机重启才生效热插拔是另一套流程。快照用多了要注意后端文件链不能太长超过十几层之后读写性能会明显下降定期做合并。4.3 容器运行时的资源限制实操容器侧的关键是把限制写死在启动参数里而不是靠它应该不会用那么多。# 限制 CPU 半个核、内存 512M、进程数 100、根文件系统只读 docker run -d --name api01 \ --cpus0.5 \ --memory512m --memory-swap512m \ --pids-limit 100 \ --read-only --tmpfs /tmp \ --cap-drop ALL --cap-add NET_BIND_SERVICE \ --security-opt no-new-privileges \ -p 8080:8080 \ registry.local/api:1.4.2--memory和--memory-swap设成一样大意思是完全禁用交换超限直接杀行为可预期如果 swap 留了余量进程会在被杀之前先卡住一段时间反而更难排查。--pids-limit是我踩过坑之后每次都会加的某个服务线程池配置错误疯狂创建线程直接把宿主的进程号耗尽连带整台机器的新进程都起不来。--read-only加--tmpfs的组合能让大部分应用正常跑同时把运行时偷偷往镜像里写文件的坏习惯堵死。需要校验限制有没有真的生效别只看docker stats的估算值直接读 cgroup 更可靠# 找到容器对应的 cgroup 路径并查看实际上限 cat /sys/fs/cgroup/system.slice/docker-容器ID.scope/memory.max cat /sys/fs/cgroup/system.slice/docker-容器ID.scope/cpu.max # 查看内存事件计数oom 次数是硬指标 cat /sys/fs/cgroup/system.slice/docker-容器ID.scope/memory.events4.4 混合部署时的资源预留虚拟机跑在容器宿主的同一台机器上时最怕的是互相踩踏。我的做法是给虚拟机做整体预留用 cgroup 或 systemd 切片把 QEMU 进程组的内存下限和 CPU 权重固定住保证虚拟机不会因为宿主上某个容器突发而被饿死。反过来容器宿主自身也要留出余量kube-reserved那套思路在这里同样适用——给系统进程预留 5% 到 10% 的 CPU 和 2G 左右内存是让整机在压力下还能 SSH 进去救命的最低保障。5. 常见问题与排查实录5.1 虚拟机启动失败与运行卡顿启动失败先看日志路径通常是/var/log/libvirt/qemu/机器名.logQEMU 的报错原文全在里面。最常见的三类一是权限问题磁盘文件属主或 SELinux 上下文不对日志里会明确写 permission denied二是资源不足内存分配失败这时候要检查宿主剩余内存和 overcommit 设置三是镜像损坏qemu-img check跑一遍能确认。运行卡顿的排查顺序我固定成四步。先看宿主vmstat 1的r列和sy列运行队列长期超过核数说明 CPU 不够再进客户机看%st是超分过头的信号然后看iostat -x 1的await和%util磁盘打满时延迟会成倍上升最后看宿主dmesg有没有内存回收或 OOM 的痕迹。这个顺序的好处是由外向内先排除宿主问题再怀疑客户机配置。5.2 容器被杀与内存水位定位容器突然消失docker ps -a显示退出码 137基本可以断定是被 OOM 杀了。但谁是凶手要看两层如果memory.events里oom_kill计数增加是容器自身超限如果宿主全局内存吃紧内核可能直接挑一个进程下手这时候容器是被殃及。dmesg -T | grep -i -E oom|killed process | tail -20 cat /sys/fs/cgroup/system.slice/docker-ID.scope/memory.events cat /sys/fs/cgroup/system.slice/docker-ID.scope/memory.current还有一种情况是没被杀但响应极慢多半是撞到了memory.high的软限速或者是页缓存被反复回收。我遇到过一例某运行时应用设了 512M 上限JVM 默认按物理机内存算堆大小一启动就逼近上限GC 疯狂触发。解决办法是显式传-XX:MaxRAMPercentage70让堆大小跟着容器配额走而不是跟着宿主机走。这个坑几乎每个 JVM 容器化项目都会踩一遍。5.3 网络不通的分层排查容器或虚拟机的网络问题别一上来就改配置按层往下捋能省很多时间。第一层看链路和地址容器里ip addr、ip route有没有正确网关第二层看宿主转发相关内核参数是否开启转发规则和地址转换规则是否命中第三层看域名解析容器内的解析配置是从宿主继承还是被覆盖过第四层看 MTU特别是走隧道或叠加网络时MTU 不一致会导致小包通、大包不通这种诡异现象。我见过最隐蔽的一次是能 ping 通但 HTTP 请求超时最后定位到是 MTU 1500 碰上链路 1450握手包能过数据包被丢。验证方法很简单用ping -M do -s 1472逐级往下试找到临界值就能确认。5.4 排障速查表现象优先检查点常用命令虚拟机起不来QEMU 日志、磁盘权限、SELinux 上下文virsh start --console、tail -f /var/log/libvirt/qemu/*.log虚拟机卡顿steal time、IO 等待、内存回收virsh domstats、vmstat 1、iostat -x 1容器退出码 137cgroup 内存上限、全局 OOMdmesg -T、memory.events容器 CPU 被压cpu.max配额、线程数cat .../cpu.max、top -H端口不通监听地址、端口映射、转发规则ss -lntp、conntrack -L大包不通MTU 不一致ping -M do -s 1472镜像拉取慢本地缓存、镜像层数docker image history磁盘爆满镜像层、日志、可写层、快照链du -sh、virsh snapshot-list6. 性能与安全的实践取舍6.1 性能开销数字比感觉可靠关于虚拟化损耗多少这个问题我的经验是分场景看别迷信单一数字。纯 CPU 计算型负载在硬件辅助虚拟化加 virtio 的配合下损耗通常落在个位数百分比跑基准测试和物理机差距很小网络 IO 的损耗相对明显小包高并发场景下能到 20% 以上用 virtio 加多队列能把差距拉回来一部分磁盘 IO 受影响最大的是随机小写尤其在不预分配、快照链很长的情况下延迟能翻倍。容器侧的开销主要来自两处一是系统调用被 seccomp 过滤或被安全模块拦截带来的额外判断二是叠加文件系统在小文件写入时的复制上抬。我做过对比同样一个写日志密集的服务容器里把日志写到挂载卷比写可写层吞吐能高出一截。所以性能这件事的最优解往往不是调内核参数而是先把数据写到哪这个决策做对。要自己测就测最小路径CPU 用计算密集型基准工具跑同规模任务比对耗时磁盘用随机读写工具测 4K 和 1M 两档网络用打流工具测小包和大包两档。每次只改一个变量否则测出来的数字没法归因。6.2 容器安全的最小实践清单容器不构成安全边界这句话值得贴在每个人的显示器上。共享内核意味着内核漏洞是所有容器共同的风险面所以下面这几条我建议变成强制规范基础镜像只从内部可信仓库拉并且锁摘要而不是标签容器以非 root 用户运行必要时用用户命名空间做映射启动时统一--cap-drop ALL再按需加回绝大多数业务一个都不需要根文件系统只读需要写的目录显式挂临时卷禁止挂载运行时套接字进容器那等于把宿主的控制权交出去给所有容器加上禁止提权的选项。再往上还有两层加固系统调用白名单把不需要的调用直接拒掉强制访问控制用宿主的安全模块给容器进程打上标签。这两层配置成本高一些但对外暴露的服务值得做。虚拟化在这里的优势就很明显了它有真正的硬件边界同样是被攻破影响面差一个量级。6.3 混合架构里我实际踩过的边界最后说几个只有实际跑起来才会遇到的问题。第一时间同步。虚拟机里如果没配好时钟源长时间运行会漂移容器镜像构建和日志排序都会受影响统一走宿主的时间同步服务最省事。第二磁盘水位。虚拟机磁盘是稀疏文件看着 40G 实际占用可能只有 5Gdu和df的数字对不上很常见监控要盯实际占用而不是表观大小。第三快照别当备份用快照和原盘在同一块存储上存储坏了两个一起没。第四容器里跑的服务要显式处理优雅退出否则每次发版都会有一批请求被硬切断这在滚动更新的场景下会被放大成用户可感知的故障。资源规划上还有个反直觉的点高密度容器宿主不是越密越好。我见过一台机器上塞了两百多个容器单看 CPU 和内存都还有余量但内核的网络栈和追踪表在高并发下成了瓶颈表现为偶发的连接建立失败。把密度降下来问题自己就没了。虚拟化和容器化都是工具能不能跑稳取决于你有没有在规划阶段就把边界和余量想清楚。