Share Notes

chundev

View the Project on GitHub latteouka/share-notes

虛擬化 vs 容器化：從 Hypervisor 到 Kubernetes 的完整概念釐清

日期：2026-03-17

TL;DR

虛擬化（VM）是在硬體上模擬多台完整電腦，每台有自己的 OS kernel；容器化是在同一個 OS kernel 上隔離多個 process。Kubernetes 和 OpenShift 不是 OS，只是跑在 Linux 上的管理程式。Hyper-V 看似裝在 Windows 上，但啟用後會把自己插到硬體和 Windows 中間，Windows 變成一個有特權的 VM（Parent Partition）。OpenShift 甚至能在 Kubernetes 上跑 VM，模糊了虛擬化和容器化的邊界。

先看全貌 — 每個技術到底是什麼？

很多技術名詞聽起來很複雜，但本質上都能歸類為三種東西：作業系統、虛擬化平台、容器平台。

技術 本質 白話比喻
ESXi、Proxmox 作業系統（Type 1 Hypervisor） 一棟專門隔套房的大樓
Hyper-V Hypervisor + 特權 VM 房東自己住一間的大樓
RHEL、Ubuntu、Windows Server 通用作業系統 一般的房子
Docker、containerd、CRI-O 容器引擎（一支程式） 在房間裡擺屏風的工人
Kubernetes、K3s 容器編排平台（一組程式） 管理所有隔間的總管
OpenShift Kubernetes + 企業功能 + RHCOS 豪華物業管理公司

接下來從最底層的作業系統開始，一層一層往上講。

第一層：作業系統 — 房子的地基

電腦買來只是一堆硬體（CPU、記憶體、硬碟），就像一塊空地。作業系統就是蓋在空地上的房子，有了房子你才能在裡面做事。

第二層：虛擬化 — 把一棟大樓隔成好幾間套房

以前一台伺服器只能裝一個 OS，很浪費。虛擬化就是把一台電腦假裝成好幾台電腦，每台都有自己完整的作業系統。

一棟大樓（實體伺服器）
├── 套房 A：自己的廚房、廁所、客廳（完整的 Windows）
├── 套房 B：自己的廚房、廁所、客廳（完整的 Linux）
└── 套房 C：同上（另一個 Linux）

每間套房（VM）都有完整的設施（完整的 OS），所以比較佔空間，但套房之間牆壁很厚，互不干擾。

ESXi 和 Proxmox — 專職管大樓的 OS

ESXi 和 Proxmox 都是 Type 1 Hypervisor，本身就是作業系統，直接安裝在裸機上，唯一目的就是建立和管理虛擬機。

硬體 → ESXi / Proxmox（極精簡的 OS）→ VM1, VM2, VM3...

比喻：大樓管理員在管理室（不住大樓裡），所有樓層都是套房。

Hyper-V — 房東自己也住在大樓裡

Hyper-V 最容易被誤解。安裝在 Windows Server 上，看起來像是跑在 OS 之上的一支程式（Type 2），但實際架構是 Type 1。

啟用前：

硬體 → Windows Server（直接跑在硬體上）

啟用後：

硬體 → Hyper-V Hypervisor → ┬─ Parent Partition（原本的 Windows Server）
                             ├─ Child VM 1
                             └─ Child VM 2

啟用 Hyper-V 後，hypervisor 會插到硬體和 Windows 之間。原本的 Windows Server 被包成 Parent Partition — 本質上就是一個 VM，但有三個特權：

  1. 直接摸硬體 — 其他 VM 不行
  2. 代理所有 I/O — 其他 VM 的磁碟、網路都經過它
  3. 管理權 — 可以建立、刪除其他 VM

拿掉這三個特權，它跟 Child VM 沒有本質差異。

  Parent Partition Child Partition
硬體存取 ✅ 直接存取 ❌ 必須透過 Parent 代理
驅動程式 真正的硬體驅動 虛擬驅動（VSC）
管理權限 可建立/刪除所有 VM 只能管自己
資源限制 無上限 被分配固定 CPU/RAM
關機影響 整台機器關機 只是關一台 VM

所有 Child VM 的 I/O 都要經過 Parent Partition 代理：

Child VM 寫磁碟：
  App → 虛擬驅動（VSC）→ VMBus → Parent 的真實驅動 → 硬體

Parent 寫磁碟：
  App → 真實驅動 → 硬體

⚠️ Parent 掛了 = 所有 VM 停擺（它是 I/O 的唯一通道） ⚠️ Parent 負載高會拖慢所有 VM — Microsoft 建議 Parent 上不要跑其他服務

比喻：房東住在 1 樓最大間，所有套房的水電管線都從房東那邊經過。房東家出事，整棟樓停水停電。

啟用 Hyper-V 要多久？

很快，整個過程約 5-10 分鐘，只需要重開機一次。使用體驗完全不變 — 桌面、Server Manager、RDP 照常用。

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

重開機過程中，Hyper-V hypervisor 先啟動、插在硬體上面，然後把 Windows Server 包成 Parent Partition 開機。就像趁你睡覺時把透天厝改成大樓結構，你醒來完全感覺不到變化。

Hyper-V 的效能考量

因為 I/O 多經過 Parent Partition 一手，理論上效能略低於 ESXi/Proxmox：

項目 影響 說明
CPU 幾乎無差異 三家都用硬體虛擬化指令（VT-x）
記憶體 幾乎無差異 都用硬體輔助（EPT/SLAT）
磁碟 I/O Hyper-V 略慢 經過 Parent 代理
網路 I/O Hyper-V 略慢 經過 Parent 代理

加上 Parent Partition 跑著 Windows Server（Windows Update、防毒、背景服務），都會影響 I/O 代理效率。ESXi 極精簡，不存在這個問題。

補救措施：SR-IOV 可以讓 VM 繞過 Parent 直接存取網卡硬體；Discrete Device Assignment 可直通 PCIe 裝置（如 GPU）。

但選擇 Hyper-V 通常不是因為效能，而是因為生態系 — 全 Windows 環境整合最好、Windows Server Datacenter 授權內含無限 VM、管理工具統一。

第三層：容器化 — 同一間房子裡的隔間

VM 是每間套房都有完整的廚房廁所（完整 OS），很安全但很佔空間。容器是在同一間房子裡用屏風隔出好幾個工作區，共用廚房廁所（共用 kernel）。

虛擬機：
  硬體 → Hypervisor → ┬─ VM1 [完整 OS + kernel + App]
                       └─ VM2 [完整 OS + kernel + App]

容器：
  硬體 → OS → 一個 Linux Kernel → ┬─ Container1 [App + libs]
                                   └─ Container2 [App + libs]

容器不是輕量 VM，而是利用 Linux kernel 的 namespace（隔離）和 cgroups（資源限制）功能，在同一個 OS 上隔離 process。

VM vs Container — 關鍵差異

  VM（套房） Container（隔間）
核心差異 每個 VM 有自己的 kernel 所有容器共用 host kernel
CPU 分配 vCPU，hypervisor 排程 cgroups 限制 CPU time
記憶體 預先分配，開機就佔走 用多少算多少，cgroups 設上限
磁碟 虛擬磁碟，幾十 GB 起跳 overlay filesystem，增量幾 MB
網路 虛擬網卡，完整 TCP/IP stack namespace 隔離，共用 host 網路
啟動時間 分鐘級（要開機、載入 kernel） 秒級（就是起一個 process）
隔離性 硬體級（水泥牆） process 級（屏風）
安全邊界 強 — VM 逃逸困難 弱 — 共用 kernel，逃逸風險較高

一句話：VM 的資源分配是「買斷制」— 分了就佔走；Container 是「用量制」— 用多少算多少。

容器的「輕量」不是因為技術比較先進，而是因為它共用 host kernel 省掉了最重的那層。代價就是隔離性較弱，所以雲端廠商（AWS Fargate 用 Firecracker、GCP 用 gVisor）會在容器外面再包一層輕量 VM 來補強安全性。

第四層：容器編排 — Kubernetes 與 OpenShift

Kubernetes — 管理所有隔間的總管

容器多了之後，誰來決定容器跑在哪台機器？壞掉的容器誰來重啟？Kubernetes 就是管理所有容器的總管。

它本身不是 OS，就是幾個跑在 Linux 上的程式：

元件 本質 位置
kube-apiserver HTTP API server control plane
etcd key-value database control plane
kube-scheduler 排程器 control plane
kube-controller-manager 一堆 control loop control plane
kubelet agent process 每個 node
kube-proxy 網路規則管理器 每個 node

核心設計是 reconciliation loop（調和迴圈）：每個 controller 不斷比對「期望狀態」和「實際狀態」，有差異就修正。不是什麼智慧 AI，就是一個 for { diff(); fix(); sleep() } 的迴圈。

K3s 更直接地證明了「Kubernetes 就是一支程式」— 它把上面所有元件編譯成單一執行檔。

OpenShift — Kubernetes 的豪華企業版

OpenShift = Kubernetes + Red Hat 加上去的企業功能（Router、OAuth、Registry、Operator、Monitoring…），全部都是跑在 Linux 上的程式。

比喻：Kubernetes 是自己組裝 IKEA 傢俱（免費但要自己動手），OpenShift 是請設計師全屋裝修（貴但省事）。

底層 OS 用 Red Hat CoreOS（RHCOS） — 一個被鎖住的特殊 Linux：

特性 RHEL RHCOS
用途 通用伺服器 專跑 OpenShift
可變性 可以 yum install 隨意裝 不可變（immutable），不讓你亂裝
升級方式 手動 yum update OpenShift 推送 image，整個 OS 換掉
套件管理 yum / dnf rpm-ostree（image-based 更新）

RHCOS 的 immutable 設計確保每台 node 狀態一致。就像物業公司說：「大樓外牆和管線我來管，你不准自己亂接水電。」OpenShift 4.x 的 control plane 強制使用 RHCOS，worker 可選 RHEL。

模糊邊界：OpenShift Virtualization — 在 Kubernetes 上跑 VM

OpenShift 不只能管容器，也能跑虛擬機。這個功能叫 OpenShift Virtualization，底層技術是開源專案 KubeVirt。

原理

把 VM 包成一個 Kubernetes Pod 來管理，底層用的是 Linux kernel 內建的 KVM（Kernel-based Virtual Machine）：

傳統做法：
  硬體 → Hypervisor（ESXi）→ VM

OpenShift Virtualization：
  硬體 → RHCOS → Kubernetes → Pod → KVM/QEMU → VM

VM 變成跟 Pod 一樣的 Kubernetes 資源，用 oc / kubectl 就能管理：

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: my-windows-server
spec:
  running: true
  template:
    spec:
      domain:
        resources:
          requests:
            memory: 8Gi
            cpu: 4
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
      volumes:
        - name: rootdisk
          persistentVolumeClaim:
            claimName: windows-pvc

為什麼 Red Hat 要做這個？

目的 說明
取代 VMware 企業不用再另外買 ESXi 授權
統一管理 VM 和容器在同一個平台，用同一套工具
漸進遷移 舊系統先用 VM 跑，慢慢容器化，不用一步到位

特別是 Broadcom 收購 VMware 後大幅漲價，許多企業正在評估從 VMware 遷移到 OpenShift Virtualization。這個趨勢叫 platform consolidation — 企業不想同時維護 vSphere + Kubernetes + 儲存系統三套平台，希望用一套搞定。

匯入既有 VM — 支援 VMDK、QCOW2、VHD

已經有 VMware 環境的企業最關心：既有的 VM 能不能搬過來？ 可以。

OpenShift Virtualization 透過 Containerized Data Importer（CDI） 匯入既有磁碟映像，支援 VMDK（VMware）、QCOW2（KVM/Proxmox）、VHD/VHDX（Hyper-V）等格式：

VMDK（VMware 匯出）
  → CDI 轉換成 raw/qcow2
    → 寫入 PersistentVolumeClaim
      → KubeVirt VM 掛載使用

匯入來源：

來源 方式
HTTP/HTTPS URL 把 VMDK 放在 web server 上，CDI 下載
S3 / 物件儲存 從 S3 bucket 拉
Container Registry 把磁碟包成 container image 推到 registry
本地上傳 透過 virtctl CLI 直接上傳

從 URL 匯入的 YAML 範例：

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: imported-vm-disk
spec:
  source:
    http:
      url: "https://fileserver.example.com/my-vm.vmdk"
  pvc:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 50Gi

或用 CLI 從本地上傳：

virtctl image-upload dv imported-vm-disk \
  --size=50Gi \
  --image-path=/path/to/disk.vmdk \
  --uploadproxy-url=https://cdi-uploadproxy.example.com

匯入後的注意事項

匯入本身不難，匯入後的調整才是重點 — 就像把硬碟拔出來裝到另一台電腦，資料都在，但驅動程式要重新裝：

項目 說明
⚠️ 驅動程式 VMware 用 PVSCSI / VMXNET3，匯入後要換成 VirtIO 驅動才有好效能，Windows VM 需先裝 VirtIO driver
⚠️ Guest Agent 移除 VMware Tools，改裝 QEMU Guest Agent
⚠️ 網路設定 IP、DNS 可能要重設，因為虛擬網卡變了
⚠️ Windows 授權 可能觸發重新啟動驗證
⚠️ 效能 沒裝 VirtIO 會 fallback 到模擬模式，磁碟 I/O 非常慢

批次遷移工具 — MTV

手動匯入 VMDK 適合少量 VM。大規模遷移可以用 Red Hat 的 MTV（Migration Toolkit for Virtualization），直接對接 VMware vSphere，自動處理驅動轉換和網路映射，是 Red Hat 搶 VMware 客戶的關鍵武器。

與專業 Hypervisor 的比較

  專業 Hypervisor（ESXi / Proxmox） OpenShift Virtualization
VM 功能成熟度 ✅ 非常成熟，20+ 年 ⚠️ 相對年輕，持續追趕中
進階功能 vMotion、HA、DRS 完整 Live Migration 有，但功能較少
效能 直接用 hypervisor 管 VM 多了 Kubernetes 這一層
適合場景 大量 VM 為主的環境 VM + 容器混合的環境

OpenShift Virtualization 不是要取代 ESXi 的所有功能，而是讓你在已經用 Kubernetes 的環境裡，不用再另外維護一套虛擬化平台。

底層的 KVM 跟 Proxmox 用的虛擬化技術是同一個，差別在於 Proxmox 自己管 VM 生命週期，KubeVirt 則是把這件事交給 Kubernetes 的 controller 機制來管。

什麼時候用什麼？

場景 選擇 原因
多租戶、不信任的 workload VM 需要強隔離
跑不同 OS（Windows + Linux） VM 容器只能跑 host 同系列 OS
微服務、大量部署 Container 輕量、快速擴縮
CI/CD pipeline Container 秒級啟動、用完即丟
VM + 容器混合環境 OpenShift Virtualization 一個平台統一管理
現實中 兩者混用 VM 當 node，上面跑容器

現實中的典型架構 — 虛擬化和容器化不是二選一，而是一層套一層：

實體伺服器
  └─ Proxmox / ESXi（虛擬化）
       └─ VM（Linux）
            └─ K3s / Kubernetes（容器編排）
                 ├─ Container A（網站）
                 ├─ Container B（資料庫）
                 └─ Container C（監控）

學到的事

參考資料