今日目標

• 了解軟體部署架構的三次重大演進：實體機（Bare Metal）➔ 虛擬化（VM）➔ 容器化（Container）。
• 搞懂 Docker 解決的痛點，以及當容器數量暴增時所產生的新挑戰。
• 理解為什麼需要容器編排（Container Orchestration）工具，以及 Kubernetes 的核心價值。

軟體部署的三大演進時代

在聊 Kubernetes 之前，我們需要先看看歷史：我們究竟是如何一路走來的？

1. 傳統實體機時代 (Bare Metal)

最早期的部署方式是直接把作業系統與應用程式安裝在實體伺服器上。

• 優點：硬體效能完全發揮，沒有虛擬化層的損耗。
• 痛點：
  • 資源浪費：一台強大的伺服器如果只跑一個小型 Web 服務，大部分 CPU/RAM 都被閒置。
  • 環境衝突：若在同一台機器跑多個服務，容易發生套件版本相衝（例如：App A 需要 Python 2.7，App B 需要 Python 3.8）。
  • 擴展極慢：買新伺服器、上架、裝 OS 需要數天甚至數週。

2. 虛擬化時代 (Virtual Machines, VM)

為了提高硬體利用率，Hypervisor 技術（如 VMware, VirtualBox）誕生了。它允許我們在一台實體伺服器上劃分出多個獨立的「虛擬機」。

• 優點：硬體資源隔離性高，不同 VM 之間互不干擾。
• 痛點：
  • 資源開銷大（Overhead）：每一台 VM 都必須包含完整的 Guest OS（作業系統内核），動輒佔用數 GB 的記憶體與硬碟空間。
  • 啟動較慢：每次啟動 VM 都等於讓作業系統重新開機，需要幾分鐘的時間。

3. 容器化時代 (Container & Docker)

Docker 的出現帶動了容器化革命。容器與 VM 最大的不同在於：容器共享宿主機（Host）的 OS Kernel，只在應用程式層面進行隔離（利用 Linux Namespace 與 cgroups）。

• 優點：
  • 極度輕量：容器映像檔（Image）通常只有幾百 MB 甚至幾十 MB。
  • 秒級啟動：不需要開機過程，幾毫秒內就能跑起來。
  • 環境一致性：「Build once, run anywhere」，徹底解決「在我的電腦可以跑，上線就壞掉」的世紀難題。

容器化後的「幸福煩惱」：為什麼單靠 Docker 不夠？

當團隊把系統拆分成微服務架構並全面容器化後，新的問題誕生了。想像一下，當你的系統從 5 個 Docker 容器爆炸成長到 200 個容器時：

1. 容器掛了誰來救？ 如果某個後端 API 容器晚上 3 點 Crash，誰去手動執行 docker run 重啟它？
2. 流量來了怎麼辦？ 當雙十一或突發流量進來時，如何自動把 5 個 API 容器擴展成 50 個？流量退去後又如何縮減？
3. 版本更新如何不中斷？ 更新程式碼時，如何一台一台替換容器，做到使用者完全無感的 Zero-downtime 部署？
4. 服務之間如何互相尋找？ 容器 IP 是動態變化的，前端容器要怎麼穩定找到後端容器？

單靠 docker run 或 docker-compose 只能管理單機上的幾個容器，無法處理跨跨機器的集群調度與自動維運。

Kubernetes 登場：容器的船長

Kubernetes (K8s) 正是為了解決上述大規模容器管理難題而生的「容器編排工具（Container Orchestrator）」。

如果說容器是海上的一個個「貨櫃」，那麼 K8s 就是整艘貨櫃船的「船長」。你只需要告訴 K8s 你想要的期望狀態（Desired State）（例如：「我需要 3 個負載平衡的 API 容器」），K8s 就會自動幫你做到：

• 自癒能力 (Self-healing)：容器掛掉自動重啟，節點損壞自動移轉。
• 自動擴縮容 (Auto-scaling)：根據 CPU/Memory 負載自動調整容器數量。
• 服務發現與負載平衡 (Service Discovery & Load Balancing)：自動分配流量與提供穩定 DNS 名稱。
• 滾動更新 (Rolling Updates)：零停機更新與一鍵退回舊版本（Rollback）。

本日小結

今天我們搞懂了軟體部署從實體機、VM 到 Docker 的演進歷程，也明白了當容器數量規模化後，K8s 登場的歷史必然性。

明天 Day 03，我們將正式進入 K8s 的世界，拆解它的核心架構：「K8s 的大腦與手腳：Control Plane 與 Worker Node 架構拆解」！