理解運算資源維運
在建立資源之後，真正的挑戰才剛開始：如何管理它們的生命週期？隨著業務增長，你可能需要調整 VM 的規格、擴展 GKE 的容量，或者在不中斷服務的情況下發布新版本的代碼。對於 Associate Cloud Engineer (ACE) 來說，這一章節測試的是你的「實戰管理能力」——如何在運行中的環境中進行變更。
這涵蓋了從簡單的 VM 調整到複雜的容器編排和無伺服器流量分配。
白話文解釋
1. 餐廳的擴張與升級 (瑞士刀類比)
- 實例規格調整 (Instance Resizing): 就像是把廚房裡的舊爐灶換成火力更強的新爐灶。你必須先熄火（停止 VM），換好零件（修改機器類型），再重新開火。
- GKE 擴展 (GKE Scaling): 就像是餐廳客滿了，你趕快在隔壁再租一間店面並多請幾位廚師（增加節點）。
- 流量分配 (Traffic Splitting): 就像是開發了一道新菜色（新版本），先讓 10% 的老客戶試吃，如果反應好再全面上架。
2. 船隊的維護 (工地類比)
- 快照/映像檔管理 (Snapshot/Image Management): 就像是為整艘船拍一張設計圖和現況照。如果船在海上壞了，你可以根據照片立刻造出一台一模一樣的船來替換。
- GKE Pod 管理: 就像是船上的小救生艇。GKE 系統（調度員）會不斷檢查救生艇是不是都在位置上，如果有一台翻了，它會立刻自動補上一台新的。
3. 公路維修 (交通號誌類比)
- 更新與發布 (Updates & Rollouts): 就像是在修路。你不能一次把路全封了，你必須封一條車道（排空一個節點），修好後再開放，接著換下一條。這就是滾動更新 (Rolling Updates)。
修改 VM 實例與節點池
調整 VM 實例規格
要修改 VM 的機器類型（例如從 e2-micro 升級到 e2-standard-4），VM 必須處於 TERMINATED (已停止) 狀態。你不能在 VM 運行時修改它的 CPU 或 RAM 配額。 Source ↗
管理 GKE 節點池 (Node Pools)
節點池是 GKE 的運算力基礎。
- 水平擴展 (Horizontal Scaling): 增加或減少節點的數量。
- 垂直擴展 (Vertical Scaling): 修改節點的機器類型。由於節點是 VM，通常建議建立一個「新機器類型」的節點池，將 Pod 遷移過去後再刪除舊池。
Cloud Run 與 App Engine 的流量分配
這是實現「零停機發布」和「金絲雀發布 (Canary Release)」的關鍵工具。
Cloud Run 流量分配
- 修訂版本 (Revisions): 每次部署產生的不可變版本。
- 標記 (Tags): 你可以為特定修訂版本加上標記（如
test），透過test---myservice-url.run.app進行私下測試，而不影響主流量。
App Engine 流量分配
App Engine 支援按「IP 位址」、「Cookie」或「隨機」進行流量分配。這讓你能夠精確控制哪些使用者會看到新版本。 Source ↗
# 將 10% 流量導向新版本
gcloud app services set-traffic default --splits v2=0.1,v1=0.9
管理 GKE Pods, Services 與 Deployments
作為 ACE，你必須熟練使用 kubectl 來維護容器化應用。
Deployment 更新
- 滾動更新 (Rolling Update，預設): 逐個替換 Pod，確保始終有可用實例。
- 重新建立 (Recreate): 先殺掉所有舊 Pod，再啟動新 Pod。會導致短暫停機。
Pod 故障排除
當 Pod 處於 CrashLoopBackOff 狀態時，通常意味著容器啟動後立即崩潰。你需要使用 'kubectl logs [POD_NAME]' 或 'kubectl describe pod [POD_NAME]' 來查看原因。 Source ↗
備份的快照與映像檔管理
快照 (Snapshot) 最佳實踐
- 一致性: 建議在製作快照前先「凍結」檔案系統或停止應用程式，以確保數據一致性。
- 排程: 使用 快照排程 (Snapshot Schedules) 自動執行定期備份，並設定保留期限以節省成本。
自定義映像檔 (Custom Image) 管理
如果你需要跨專案共用一個配置好的環境，你應該將 VM 磁碟轉換成自定義映像檔 (Custom Image)。映像檔可以被標記為 'Deprecated' (不建議使用)、'Obsolete' (已淘汰) 或 'Deleted' (已刪除)，這有助於版本控制。 Source ↗
資源維護與更新
即時遷移 (Live Migration)
Google Cloud 的一項黑科技是即時遷移 (Live Migration)。當底層硬體需要維護或升級時，Google 會在不停止你的 VM 的情況下，將它遷移到另一台主機上。你的應用程式不會感覺到任何中斷。 Source ↗
GKE 節點升級
GKE 會定期更新 Kubernetes 版本。
- 激增更新 (Surge Upgrades): 升級時多建立幾個節點，確保處理能力不下降。
透過 gcloud 與 kubectl 管理維運
# 修改 VM 標籤
gcloud compute instances add-tags my-vm --tags http-server,https-server
# 擴展 GKE 節點池
gcloud container clusters resize my-cluster --node-pool default-pool --num-nodes 5
# 回滾 GKE 部署
kubectl rollout undo deployment/my-app
# 查看 App Engine 日誌
gcloud app logs tail -s default
運算資源維運最佳實踐
- 基礎架構即代碼 (IaC)：優先使用 Terraform 或 Deployment Manager，而非手動在主控台點選。
- 自動化備份：永遠不要依賴手動快照。
- 監控與警報：當 CPU 負載過高或磁碟空間不足時，應自動發送通知。
- 標籤管理：為所有資源加上
env(prod/dev) 和team標籤。
ACE 考試的常見場景
- 情境：你發現某個 App Engine 版本有嚴重的 Bug，需要立刻恢復。
- 解決方案：在主控台將 100% 流量切換回之前的穩定版本。
- 情境：你需要為一個正在運行的資料庫 VM 增加磁碟空間。
- 解決方案：你可以在 VM 運行時增加持久性磁碟 (Persistent Disk) 的大小，但隨後需要在作業系統內部擴充磁碟分割區。
常見問題 (FAQ)
Q1: 修改 VM 機器類型會更改它的 IP 嗎？ 答：只要你不刪除 VM，內部 IP 通常保持不變。但如果你沒有分配「靜態外部 IP」，重啟後外部 IP 可能會變。
Q2: 什麼是滾動更新的 'maxSurge'？ 答：這是指在更新過程中，允許超過預期 Pod 數量的最大百分比。這能加速更新並提供額外的安全餘裕。
Q3: 我可以跨區域 (Region) 恢復快照嗎？ 答：可以。快照是全域資源，你可以在 A 區域製作快照，在 B 區域建立磁碟。
Persistent Disk 可以在 VM 運行時線上擴增容量，但只能擴大、不能縮小。擴增完磁碟後，你還必須在 OS 層執行對應指令（Linux ext4 用 resize2fs、Windows 用磁碟管理工具）把檔案系統撐到新容量，否則多出來的空間在應用程式眼裡是看不到的。
Source ↗
Live Migration 聽起來無所不能，但掛載 GPU 或 Local SSD 的 VM 是例外——主機進行維護時，這類 VM 會被 TERMINATED 後重啟，並不會無縫遷移。如果 ACE 情境題裡為 GPU 訓練 VM 選「Migrate」維護政策，那就掉進陷阱了；正解是用快照、Instance Templates 或 MIG 自我修復來設計可優雅重啟的架構。 Source ↗
Q4: GKE 的「可先佔節點 (Preemptible Nodes)」適合什麼負載？ 答：適合可以被隨時中斷且能自動重啟的工作負載，如分散式轉碼或批次處理計算。
Q5: 什麼是藍綠部署 (Blue-Green Deployment)？ 答：同時運行兩個完全相同的生產環境。Blue 是目前版，Green 是新版。測試通過後直接將所有流量從 Blue 切換到 Green。
ACE 總結清單
- 理解修改 VM 規格的前提是先停止它。
- 掌握
kubectl rollout系列指令。 - 清楚 Cloud Run 與 App Engine 的流量分配邏輯。
- 知道如何設定自動化快照排程。
- 了解即時遷移如何幫助減少計劃內停機。