兩種都在做隔離，但層次不同：VM 虛擬化整台機器的硬體、跑自己的 kernel；container 是作業系統層級的虛擬化，所有 container 共用同一個 host kernel。VM 隔離更徹底但笨重，container 輕量但共享 kernel——選哪個，取決於你要多強的隔離、能付多少開銷。
🧠 Intuition
TIP
Container 說穿了是受限的 process：靠 kernel 的 namespaces（自己的 PID、網路介面）、cgroups（資源限制）與類 chroot 的檔案系統，把一組 process 圈起來，讓它以為自己獨佔一台機器——但底下是同一個 kernel。
- VM：hypervisor（type 1 直接跑在硬體上、type 2 跑在一般 OS 上）管理 guest；純軟體模擬慢，實務用 paravirtualization / 硬體輔助（VT-x、AMD-V）貼近原生效能。
- VM 的代價：每台要獨立維護完整 OS（更新、安全、sshd），啟動慢、資源浪費——服務一多，時間與金錢成本就顯著；這正是 container 出現的契機。
- Docker：image 是 container 的檔案系統（用 overlay filesystem 分層堆疊），container 才是跑 process 的實體；改 container 內檔案不會改到 image。網路用 bridge + veth pair + NAT。
- Kubernetes：跨多機管理大量 container 的編排工具，client-server 架構——server 在可用機器上跑 container，client 下指令管理。
⚖️ Tradeoffs
每個服務一台 VM — 隔離強但笨重
- 隔離最徹底（各自完整 OS 與 kernel），適合需要不同 OS、或安全邊界要很硬的場景。
- 但每台 VM 都要單獨維護、開機慢、按實例計費時成本高；小規模看不出、規模一大就痛。
容器化 — 輕量但共享 kernel、有陷阱
- 啟動快、密度高、image 可版控分發；但共用 host kernel，隔離弱於 VM。
- 常見陷阱：overlay 變更在 process 結束後消失（資料要外接 DB／volume）；用
latesttag 會因底層悄悄改變而壞掉，要釘明確版本；用他人 image 等於多一層信任風險；多數工具偏向 web server，其他服務未必合適。 - 「container 不解決所有問題」：應用本來啟動就慢，裝進 container 一樣慢。
🔑 Takeaways
- VM 虛擬化整台機器、各跑自己的 kernel；container 是 OS 層級虛擬化、共用 host kernel——靠 namespaces / cgroups 隔離。
- VM 隔離強但笨重、成本高；container 輕量高密度但隔離弱、資料需外接、版本要釘死。
- 跨多機大量 container 用 Kubernetes 編排；但沒有一種虛擬化能掩蓋應用本身的問題。
No notes yet — jot your takeaways or Q&A here.