illegalCreed

中文

English

中文

English

Appearance

入门：虚拟化动机与虚拟机/容器之分 ​

基于通用操作系统概念 · 核于 2026-08

速查 ​

  • 虚拟化的动机：一台物理机的 CPU/内存利用率常低于 20%，把多套系统/应用"挤"进同一台机器 → 资源利用率飙升、隔离故障、灵活调度——这是云计算的成本基础。
  • 两大技术路线：①虚拟机（VM）——每个 VM 自带完整内核（Guest OS），由 Hypervisor 调度，硬件级强隔离；②容器——所有容器共享宿主内核，靠 namespace/cgroups 做进程级隔离，轻量但隔离弱。
  • 核心分水岭：是否共享内核。VM 各自带内核（隔离强、开销大）；容器共享宿主内核（开销小、隔离弱）。这一条决定了启动速度、资源占用、安全边界、可运行负载的差异。
  • Hypervisor（VMM）：管理 VM 的软件层，负责把 CPU/内存/设备虚拟化分给各 VM。分两类：Type 1（裸机，直接跑在硬件上，ESXi/Hyper-V）与 Type 2（托管，跑在宿主 OS 之上，VirtualBox/VMware Workstation）。
  • 硬件辅助虚拟化：Intel VT-x / AMD AMD-V 引入 root/non-root 两种 CPU 模式 + 新指令（VMLAUNCH/VMRESUME/VMEXIT），让 Hypervisor 在 root 模式管控、Guest 在 non-root 模式直接跑大部分指令——告别纯软件模拟的慢。
  • 全虚拟化 vs 半虚拟化：全虚拟化（Full Virtualization）不改 Guest 内核，靠硬件或二进制翻译模拟全部指令；半虚拟化（Para-Virtualization）改 Guest 内核，把敏感指令换成主动 hypercall——性能更好但需改源码（Xen/Linux 早期）。
  • 容器本质：一个被 namespace + cgroups "包装"的普通 Linux 进程。它不是轻量 VM，没有自己的内核——这就是为什么容器启动只需几百毫秒、镜像只有几十 MB。
  • namespace 六种：PID（进程号隔离）、网络（独立网卡/端口/路由）、挂载（独立文件系统视图）、UTS（hostname/domain）、IPC（消息队列/共享内存）、用户（UID 映射，容器内 root = 宿主 nobody）。
  • cgroups：限制/计量进程组的 CPU、内存、IO、设备等资源——防止一个容器吃光整机资源（OOM、CPU 饿死其他容器）。
  • Docker 两概念：镜像（image）= 分层只读的文件系统快照（base + 每层改动叠加）；容器（container）= 镜像 + 一层可写层 + 运行中的进程。
  • VM vs 容器开销：VM 启动分钟级、占用 GB 级（要装 Guest OS）；容器启动秒级、占用 MB 级（共享内核，只存应用）。
  • K8s 引入：单机多容器靠 Docker 自带编排不够用 → K8s 用 Pod（共网络/存储的容器组）+ Service（稳定访问入口）+ 调度器（按资源/亲和把 Pod 调到合适节点）实现集群级编排。
  • 进阶顺序：虚拟机与 Hypervisor → 容器：namespace 与 cgroups → 参考。

一、为什么要虚拟化：从独占到共享 ​

早期一台物理机只跑一个应用——数据库服务器、Web 服务器各占一台机器。问题很明显：

  • 资源浪费：CPU 平均利用率仅 10-20%，内存也大量闲置，但机器、机房、电费、运维成本照付。
  • 部署僵化：上线一个新服务要采购机器、上架、装系统，周期以周计；扩容要提前买机器。
  • 故障传染：多个应用挤在一台机器（不虚拟化的话），一个应用的 bug/OOM/漏洞会拖垮所有应用。

虚拟化的解法：在硬件之上加一层抽象，把一台物理机切成多个相互隔离的虚拟环境（VM 或容器），每个环境独立部署、独立故障、独立调度。这样一台物理机能跑几十上百个负载，利用率从 20% 提到 60-80%，是云计算"按需付费、弹性扩缩"的成本基础。

二、两条路线：虚拟机 vs 容器 ​

虚拟化有两条技术路线，核心差异只有一个——是否共享内核：

  【虚拟机 VM】                         【容器 Container】
  ┌────────┐ ┌────────┐                ┌────┐ ┌────┐ ┌────┐
  │ App A  │ │ App B  │                │AppA│ │AppB│ │AppC│
  │ libs   │ │ libs   │                │lib │ │lib │ │lib │
  │Guest OS│ │Guest OS│  ← 各自带内核   └─┬──┘ └─┬──┘ └─┬──┘
  └───┬────┘ └───┬────┘                  │namespace + cgroups
   ┌──┴──────────┴──┐                 ┌──┴──────┴──────┴──┐
   │   Hypervisor   │  ← 管理层       │  宿主内核 (共享)    │  ← 共享一个内核
   └────────┬───────┘                 └─────────┬─────────┘
            │                                   │
        物理硬件                           物理硬件
维度虚拟机（VM）容器（Container）
内核各自带 Guest OS 内核共享宿主内核
隔离强度硬件级强隔离进程级软隔离
启动时间分钟级（要引导内核）秒/毫秒级（启进程）
资源开销GB 级（含完整 OS）MB 级（只含应用）
安全边界内核漏洞不跨 VM内核漏洞可逃逸
密度一台机器十几个一台机器几百个
典型代表KVM、ESXi、Hyper-VDocker、containerd

一句话：VM 用"多内核"换强隔离，容器用"共享内核"换高密度。两者常组合使用——容器跑在 VM 里（VM 当强隔离边界，容器当高密度载体）是公有云的标配。

三、虚拟化与容器化的关系 ​

一个常见误解是"容器淘汰了虚拟机"。实际上两者互补：

  • VM 擅长强隔离：不同租户、不可信代码、内核版本要求不同的负载，用 VM 隔离（如公有云的实例、银行核心系统）。
  • 容器擅长高密度：同一团队、可信负载、微服务化场景，用容器（如内部微服务、CI/CD 流水线、Serverless 函数冷启动）。
  • 组合方案：AWS ECS、GCP GKE、Azure AKS 实际上是"每个租户一个 VM，VM 内跑多个容器"——VM 提供租户间强隔离，容器提供租户内高密度部署。安全沙箱容器（gVisor、Kata Containers）则是"用 VM 技术给容器加一层强隔离"，融合两者优势。

下一步 ​

理解了虚拟化动机与 VM/容器的核心差异后，下一步分别深入两条线——虚拟机与 Hypervisor（Type 1/Type 2、VT-x、全/半虚拟化），以及容器：namespace 与 cgroups（容器原理、Docker 模型、K8s 编排引入）。