一開始接觸 Container 的時候，我也以為它只是一種比較輕量化的 VM，
但是後來發現，它們其實還蠻不一樣的。雖然 VM 和 Container 都可以算是虛擬化技術，但它們虛擬化的方式不一樣，隔離的層次也不一樣。
簡單來說，VM 可以把它想成一台完整的電腦，而 Container 則比較像是在共用同一台電腦的作業系統和硬體資源。

這樣講可能還是有點抽象，所以以下從底層架構來看，這樣兩者的差異會比較明顯。

VM：像是一台完整的電腦

VM 的底層會有一個 Hypervisor，Hypervisor 負責把實體硬體虛擬化，讓我們可以在一台實體主機內建立多台 VM，但是 Hypervisor 不一定都要安裝在完整的 Host OS （e.g. Windows Server, Linux...）裡面。

比較常聽到的 VM 運作手法可能是在 Windows 裡面安裝 VirtualBox、VMware Workstation 或 Hyper-V，然後再透過這些軟體建立 VM，這種方式就是先有一個 Host OS，再由 Host OS 上面的虛擬化軟體去管理 VM。

但另外也有一種方式是像 VMware ESXi 這種平台，它可以直接安裝在實體硬體上，不需要先安裝 Windows 或一般 Linux 作業系統，這個平台本身就負責管理硬體和虛擬機，然後在上面建立多台 VM。

不過不管是哪一種方式，VM 本身都很像我們另外組裝了一台電腦來跑服務，
它需要安裝完整的 Guest OS，也要配置自己的虛擬 CPU、Memory、硬碟和網路介面，這些雖然都是虛擬的，但 VM 裡面的作業系統會把它們當成一台電腦所擁有的硬體來使用：

所以 VM 的好處是它有一個比較完整的 OS 邊界，你可以在同一台實體主機上建立一台 Windows VM，再建立一台 Linux VM，它們各自有自己的作業系統和 Kernel，但相對的每一台 VM 都需要多一份完整的 OS、系統服務、更新和資源配置，因此通常資源需求會比較高，啟動時間也會比較久。

Container：共用 Host Kernel 的應用程式環境

Container 和 VM 不一樣，它不是一台完整的虛擬電腦，而是由 Container Runtime 建立出來的一個應用程式執行環境，不需要另外安裝一套完整的 Guest OS（除了非 Linux OS 要跑 Linux Container 的情況，等等會提），也不需要為每一個 Container 都建立一個獨立的 Kernel。

它主要是使用 Host OS 的 Kernel 和資源，然後透過隔離機制，讓每個 Container 看起來像是在自己的環境裡面執行：

在 Linux 上，Container 會使用 Host 的 Linux Kernel，並透過 namespace 把執行程序、網路、檔案系統等資源隔離開來，另外也會透過 cgroup 去控制和統計 Container 使用的 CPU、Memory 等資源。

這也是後面 Kubernetes 設定 Pod 資源時的底層原理，像 Deployment 裡面的 requests 和 limits，Kubernetes 會先使用 request 判斷這個 Pod 適合放在哪一個 Node，再由 kubelet 和 Container Runtime 透過 cgroup 去套用實際的 CPU 和 Memory 控制，這一部分之後在講 Deployment 和資源管理時會再詳細說明。

也因為 Container 不需要為每個應用程式再啟動一套完整 OS，所以通常會比 VM 更輕量，啟動速度也比較快，能在同一台主機上運行更多服務，所以蠻常聽到有個說法是「秒級部署」，這通常就是在指容器化的情境下，要去啟動/停止站台服務是可以在很短的時間內達成。

不過這並不是說 Container 就一定要取代 VM，VM 和 Container 處理的是不同層次的問題，主要差別在於它們的隔離邊界和執行方式不同，簡單講就是還是得看需求啦～

Linux Container 和 Windows Container

雖然現在大部分的人在討論 Container 時，預設應該都是指 Linux Container，但其實也不是只有 Linux Container，也有 Windows Container：

Linux Container 需要 Linux Kernel，而 Windows Container 理所當然就需要 Windows Kernel，而 Windows Kernel 的 Guest OS 就得是 Windows 系列的作業系統。

所以 Windows Container 不能直接運作在 Linux 系統上，Linux Container 也不能直接交給 Windows Kernel 來執行。

Windows Container 可以用來執行一些依賴 Windows、IIS 或傳統 .NET Framework 的應用程式，不過以我的經驗來看，是比較少人使用 Windows Container 的，因為如果系統本來就綁定 Windows，而且直接使用 IIS 就可以運作，那麼再多引入一層 Windows Container，還要處理 Container image、Runtime 和維護方式，成本並不一定比較低。

為什麼 Windows 和 macOS 可以執行 Linux Container？

我覺得這裡很容易誤會，我自己也是很後來才知道原來是這樣的運作方式！

Windows 和 macOS 並不是直接使用自己的 Kernel 來執行 Linux Container，因為 macOS 與 Windows 沒有 Linux Kernel，所以當然不能直接運行 Linux Container，但若要在這兩種作業系統運行 Linux Container，實際上是會先在背後建立一個 Linux VM，然後再讓 Linux Container 跑在這個 Linux VM 裡面：

例如在 Windows 上使用 Docker Desktop 時，Docker Engine 實際上是運作在 Linux 環境裡面，這個 Linux 環境以現在來說，通常是會由 WSL 2 的虛擬化方式。

所以看起來我們是在 Windows 上執行：

docker run nginx

但實際上這個 Linux Container 是在 Windows 內的 Linux VM 裡面運作，使用的是 Linux Kernel，不是 Windows Kernel。
macOS 也是類似的概念。Docker Desktop 會先提供一個 Linux VM，然後 Container Runtime 再在這個 Linux VM 裡面啟動 Linux Container。

不過如果 Host OS 本來就是 Linux，那就不用再多建立一層 Linux VM（見上方比較圖右側），這時 Container 就可以直接使用 Linux Host 提供的 Kernel 和資源。

結論

VM 可以把它想成一台完整的電腦，它有自己的虛擬硬體、Guest OS 和 Guest Kernel。

Container 則比較像是在同一個 Host OS 上，透過 Container Runtime 建立出隔離的應用程式執行環境，它通常不需要完整的 Guest OS，而是共用 Host OS 的 Kernel。

所以最簡單的區分方式可以看這張圖：

• VM 的隔離層次比較完整，適合需要完整 OS 或特定作業系統的情境。
• Container 則比較輕量，啟動快、資源使用較少，也比較適合現代微服務和雲端平台。

下一篇再繼續說明 Dockerfile、Container image，以及一個應用程式到底是怎麼被建置和啟動的。