前幾天我們利用Docker完成了非同步 S3 微服務的容器化、架設了 Prometheus + Grafana 監控鏈路，並透過 JMeter 壓測驗證有無保護api的差異。

了解 Semaphore 控流、Resilience4j 斷路器、Double-Check 以及優雅停機的保護機制有多重要。不過我們的測試標準都只有局限在 1.5 核 CPU / 512MB RAM 的單一 Docker 容器限制下，接著我們就要來思考如果流量量度超越硬體極限，或是單一結點出問題了，要怎麼處理呢？

今天，我們不寫 Java 程式碼，而是要跳脫單機思維，深入剖析單機架構死穴、理解高可用（HA）的核心靈魂，並手把手教你建立本地端 Kubernetes (Minikube) 開發環境與黃金基礎指令！

單機 Docker 的三大瓶頸

或許大家會有疑問，都已經包成 Docker Image 了，可以適應各種環境，難道還不夠高可用嗎？其實是的，因為在生產環境（Production）中，單一容器架構面臨著三個無法逾越的障礙：

1. 單點故障 (Single Point of Failure, SPOF)

當所有流量都打在同一台宿主機上的單一 Docker 容器時，只要宿主機發生 kernel panic、機房斷電或實體網卡異常，你的服務就會當場崩潰。前面寫再多的 Java 斷路器與 Try-Catch，在物理斷電面前都只是徒勞。

2. 垂直擴展 (Scale-up) 的物理天花板

面對突發海嘯流量時，單機的解決方式是升級硬體（增加 CPU 核心、擴充 RAM）。但單台伺服器的插槽與晶片極限是固定的，升級成本呈指數級暴增，且永遠趕不上極端流量的成長速度。

3. 人工維運悲劇

當單機容器因為不明原因崩潰（例如 OOM 被 OS 殺掉）時，必須依靠工程師在凌晨三點收到 Alert 警報，從床上爬起來手動敲 docker run 或 docker restart。這期間產生的停機時間（Downtime），會無情吞噬公司的商業 SLA。

什麼是真正的高可用 (High Availability, HA)？

要解決單機問題，我們必須釐清一個概念：高可用 (HA) 的核心不是保證單一節點永不崩潰，而是承認節點一定會崩潰，並建立自動化叢集機制，讓系統在節點崩潰時依然無感對外服務！

1. 被動防禦 vs. 主動自癒

• 單機時代（被動防禦）：透過 Semaphore 限流，當流量過載時，無奈地回傳 HTTP 429 或 503 把使用者拒之門外。
• 叢集時代（主動自癒、橫向擴展）：當流量飆高時，系統自動長出新的節點（Scale-out）；當某個節點死亡時，系統自動秒級重啟新節點並切換流量！

2. 企業級 HA 的標準：四個 9（99.99%）

在企業架構中，HA 通常以「Availability Percentage」來衡量：

• 99.9% (三個 9)：一年停機時間不能超過 8.76 小時。
• 99.99% (四個 9)：一年停機時間不能超過 52.6 分鐘（平均每月低於 4.3 分鐘）！

要達到四個 9 的高可用性，自動化故障轉移（Failover）與自我修復（Auto-healing）是唯一的出路。

面對高流量的兩大方法：Scale-Up vs. Scale-Out

當系統面臨高流量時，有兩種截然不同的應對路線：

1. Scale-Up (垂直擴展 / 單機加大)

• 做法：直接升級單台伺服器的硬體規格（例如把 CPU 從 2 核升到 64 核、RAM 從 4GB 加到 256GB）。
• 優點：簡單粗暴，應用程式程式碼與架構幾乎完全不需要修改。
• 缺點：
  • 價格呈指數級暴漲：頂規伺服器的價格不是線性的，而是貴得離譜。
  • 物理天花板：主機板插槽與晶片架構有物理極限，無法無限升級。
  • 依然無法破除 SPOF：一旦這台頂規機器斷電或實體網卡卡死，全站依然當場陪葬。

2. Scale-Out (水平擴充 / 叢集加台數) —— K8s 的核心路線

• 做法：維持單台伺服器為標準規格（如 2 核/4GB），透過網路將成百上千台普通機器串聯成一個「叢集（Cluster）」。
• 優點：
  • 理論上無上限：流量翻倍就加機器，彈性極高。
  • 成本平滑線性：使用大量普通平價機器，CP 值最高。
  • 真正的 HA 高可用：叢集中任何 1 台機器燒毀，其餘 99 台自動接管流量，用戶完全無感！

Kubernetes (K8s)

核心架構 (Control Plane vs Worker)

為了管理由成百上千台伺服器組成的 Scale-Out 叢集，Kubernetes 採用了非常清晰的 控制面 (Control Plane)與工作節點 (Worker Nodes)雙層架構：

1. Control Plane (控制面 —— 叢集大腦樞紐)

• kube-apiserver：所有外部指令（如 kubectl）與內部組件交流的唯一 REST API 門閥。
• etcd：高可用的分散式 Key-Value 資料庫，儲存叢集權威的期望狀態 (Desired State)。
• kube-scheduler：評估機器剩餘算力與資源，進行 Pod 精準派工的調度員。
• kube-controller-manager：7x24 小時巡邏的 Reconciliation Loop（調和迴圈），發現有容器死亡立刻啟動自動補建！

2. Worker Nodes (工作節點 —— 實體算力與負載)

• kubelet：駐紮在各台機器上的駐點班長，負責向 apiserver 匯報機器狀態，並督導容器啟動。
• kube-proxy：維護網路路由與流量轉發的網路警察。
• Container Runtime：底層容器執行引擎（如 containerd 或 Docker）。

資源四層結構：Cluster ➔ Node ➔ Pod ➔ Container

剛接觸 K8s 時，常搞不懂 Node、Pod 與 Container 的關係。先用簡單的飯店與房間比喻：

1. Cluster (叢集 / 整座飯店)：最外層的 K8s 系統全貌，包含了管理大腦 (Control Plane) 與所有工作機器。
2. Node (節點 / 飯店大樓)：實體或虛擬伺服器（例如 Minikube 幫我們蓋的這台 minikube 機器）。它負責提供實體的 CPU 與 RAM 算力。
3. Pod (最小部署單位 / 飯店房間)：K8s 中最小的部署與調度單位！一個 Pod 裡面可以封裝一到多個容器。Pod 擁有獨立的內網 IP 地址，使用的是宿主 Node 的 CPU/RAM 算力。
4. Container (容器 / 房間裡的住戶)：我們用 Docker 打包的一個獨立應用程式（如 s3-service:v1）。

Minikube

在正式生產環境中，部署一個 K8s 叢集通常需要數台實體伺服器，或是在 AWS 租用託管的 EKS 叢集（太花錢啦）。

Minikube 是 K8s 官方推出的「極簡單節點 K8s 模擬器」！
它會把 K8s 的 Control Plane 大腦與 Worker 節點，通通打包封裝在本地端的一個 Docker 容器或虛擬機中。讓工程師不用花一毛錢，就能在自己電腦上體驗 100% 正統的 K8s API 與部署流程！

本地建立 K8s 開發環境

在進入正式部署之前，我們需要在本地開發環境拉起一個輕量級的單節點 K8s 叢集。

1. 安裝核心雙套件：Minikube 、 kubectl

• kubectl：K8s 的 CLI 命令列控制工具（大腦終端）。
• Minikube：在本地端用 Docker 或 VM 模擬運行單節點 K8s 叢集的極簡工具。

🛠️ macOS (Homebrew 安裝)：

brew install kubectl
brew install minikube

🛠️ Windows (Chocolatey / Winget 安裝)：

choco install kubernetes-cli minikube

2. 一鍵啟動本地 K8s 叢集

打開 Terminal，輸入以下指令啟動 Minikube(先執行它建立 K8s 伺服器，後續才能用 kubectl 建立 Pods 與 Deployments)：

# 啟動 Minikube 叢集（預設使用 Docker 作為 Driver）
minikube start --cpus=2 --memory=2048mb

可能會在這個畫面下載停留很久這是正常的

💾  Downloading Kubernetes v1.37.0 preload ...
    > gcr.io/k8s-minikube/kicbase:  470.53 MiB / 470.53 MiB  100.00% 6.15 MiB p

若啟動成功，你會看到類似以下的 Console 輸出：

3. 基礎指令實戰入門

當 Minikube 啟動後，我們可以透過 kubectl 開始與 K8s 叢集對話：

① 檢查叢集資訊與健康狀態

kubectl cluster-info

預期輸出： 印出 Kubernetes Control Plane 與 CoreDNS 的運作 URL。

② 查看叢集節點 (Nodes) 狀態

kubectl get nodes

預期輸出：

NAME       STATUS   ROLES           AGE     VERSION
minikube   Ready    control-plane   2m10s   v1.28.3

③ 建立一個測試用 Pod (Imperative 快速驗證)

kubectl run nginx-test --image=nginx:alpine

④ 查看 Pod 運作狀況

kubectl get pods

預期輸出：

NAME         READY   STATUS    RESTARTS   AGE
nginx-test   1/1     Running   0          15s

⑤ 查看 Pod 日誌與清理測試

# 查看 Pod Log
kubectl logs nginx-test

# 刪除測試 Pod
kubectl delete pod nginx-test

執行結果

總結

今天我們完成了從單機 Docker 瓶頸跨越到K8s叢集高可用的學習：

1. 從單機極限到Scale-Out：水平擴充是打破單機物理天花板與 SPOF 單點故障的唯一解答
2. HA 核心：本質是承認故障的存在，並靠自動化調和 (Reconciliation Loop)實現自動擴展
3. K8s 入門：了解k8s架構、層級關係，Minikube 觀念
4. 工具就位：成功啟動本地 Minikube 叢集，並掌握了 kubectl 的基礎指令

明天，我們將正式把前面幾天精心打包的非同步 S3 微服務，撰寫成正統的 K8s Deployment 與 Service YAML 檔，踏出邁向雲端原生部署的最實戰一步！