從選型到配置：架構師的下一步
在前面的課程中，我們學會了「選擇」正確的運算和儲存服務。但 PCA 考試不只考你選什麼，更考你怎麼配——GKE 叢集的節點池要怎麼規劃？Cloud Run 的並行數設多少？磁碟該選 pd-ssd 還是 pd-balanced？這一課我們將深入這些配置層面的實戰知識。
GKE 叢集配置實務
Node Pool 規劃與自動擴縮
GKE Standard 模式下，Node Pool 是管理叢集運算資源的核心單位。每個 Node Pool 可以有獨立的機器類型、映像和擴縮策略：
- Cluster Autoscaler — 根據 Pod 的資源需求自動增減節點數量。當 Pod 因資源不足處於 Pending 狀態時，Autoscaler 會自動新增節點；當節點利用率過低時則縮減
- Horizontal Pod Autoscaler（HPA） — 根據 CPU/記憶體使用率或自訂指標，自動調整 Pod 副本數
- Vertical Pod Autoscaler（VPA） — 自動調整單一 Pod 的 CPU 和記憶體 request/limit，避免手動猜測資源需求
- Node Auto-Provisioning（NAP） — 更進一步，自動建立符合工作負載需求的全新 Node Pool，不需要預先定義機器類型
三層擴縮的協作邏輯：HPA/VPA 調整 Pod 層級 → Cluster Autoscaler 調整節點數量 → NAP 調整節點規格。
💡 考試小提示：HPA 和 VPA 不建議同時對同一個指標使用（例如都根據 CPU 擴縮），因為會互相衝突。常見最佳實踐是 HPA 管水平擴展，VPA 管資源配額。
Release Channels 與維護管理
GKE 提供三個 Release Channels 管理叢集版本升級策略：
| Channel | 特性 | 適用情境 |
|---|---|---|
| Rapid | 最先取得新版本，更新頻率最高 | 開發/測試環境、想搶先試用新功能 |
| Regular | 平衡穩定性與功能更新（預設） | 大多數生產工作負載 |
| Stable | 最晚取得新版本，經過最多驗證 | 高穩定性需求的關鍵業務系統 |
搭配 Maintenance Windows 和 Maintenance Exclusions，你可以精確控制叢集何時允許自動升級——例如排除電商大促期間的升級窗口。
Node Image 選擇
- Container-Optimized OS（cos） — Google 維護的精簡 OS，預設選擇，安全性最高、攻擊面最小
- Ubuntu — 需要額外套件或驅動程式時使用（如特定 GPU 驅動、自訂核心模組）
Cloud Run 進階配置
並行與實例管理
Cloud Run 的效能調校核心在於並行數（Concurrency）和實例數的搭配：
- Concurrency — 單一實例同時處理的最大請求數（預設 80，最高 1000）。CPU 密集型工作應調低；I/O 密集型（如呼叫外部 API）可調高
- Min Instances — 維持最少實例數以避免冷啟動。設為 1 即可大幅改善延遲敏感服務的回應時間，但會產生持續費用
- Max Instances — 設定上限防止意外爆量導致成本失控或下游服務過載
CPU 分配模式
| 模式 | 說明 | 計費 | 適用場景 |
|---|---|---|---|
| Request-based（預設） | 僅在處理請求時分配 CPU | 按請求處理時間 | 一般 Web API |
| Always-on | CPU 持續分配，即使無請求 | 按實例執行時間 | 背景任務、WebSocket、排程處理 |
進階功能
- Startup / Liveness Probes — 設定健康檢查確保實例就緒才接收流量，避免部署時的錯誤回應
- Cloud Run Jobs — 適合批次處理、資料遷移、定時排程等不需要持續監聽 HTTP 的任務，支援平行 task 和重試機制
- Volume Mounts — 可掛載 Cloud Storage（透過 FUSE）或 NFS（Filestore）作為檔案系統，讓無伺服器服務也能存取共享檔案
💡 考試小提示：題目出現「冷啟動延遲」問題時，答案通常是設定 min instances；出現「背景處理」或「WebSocket 長連線」時，選擇 always-on CPU allocation。
持久化儲存選型
GCP 提供多種區塊與檔案儲存選項，配合 Compute Engine 和 GKE 使用：
| 儲存類型 | IOPS（隨機讀） | 吞吐量 | 持久性 | 可共享 | 成本 | 適用場景 |
|---|---|---|---|---|---|---|
| pd-standard | 低（0.75/GB） | 中 | ✅ 持久 | 可 multi-reader | 最低 | 日誌、備份、冷資料 |
| pd-balanced | 中（6/GB） | 中高 | ✅ 持久 | 可 multi-reader | 中 | 一般資料庫、開發環境 |
| pd-ssd | 高（30/GB） | 高 | ✅ 持久 | 可 multi-reader | 較高 | 高效能資料庫（MySQL、PostgreSQL） |
| pd-extreme | 極高（自訂） | 極高 | ✅ 持久 | 否 | 最高 | SAP HANA、Oracle DB |
| Hyperdisk Balanced | 高（可獨立調整） | 高 | ✅ 持久 | 可 multi-reader | 中高 | 一般用途，IOPS/吞吐量/容量可獨立調整 |
| Hyperdisk Extreme | 極高（可獨立調整） | 極高 | ✅ 持久 | 否 | 最高 | 企業級資料庫，取代 pd-extreme |
| Hyperdisk ML | 中 | 極高（唯讀） | ✅ 持久 | ✅ 多實例共享 | 中 | AI/ML 模型載入、大量讀取 |
| Local SSD | 極高（固定） | 極高 | ❌ 暫時 | 否 | 中高 | 快取、暫存、高 IOPS 暫時工作 |
| Filestore | 中高 | 高 | ✅ 持久 | ✅ NFS 共享 | 中高 | 多 VM/Pod 共享檔案、CMS、渲染 |
| Cloud Storage FUSE | 低 | 高（大檔） | ✅ 持久 | ✅ 全域共享 | 最低 | ML 訓練資料讀取、靜態資產 |
選型決策關鍵：
- 需要最高 IOPS → Local SSD（但資料不持久，VM 停止即消失）
- 需要多實例共享 → Filestore（NFS）或 Cloud Storage FUSE
- 一般資料庫 → pd-balanced 是最佳性價比起點
- 企業級資料庫（SAP HANA） → Hyperdisk Extreme 或 pd-extreme 搭配 Memory-optimized VM
- AI/ML 模型載入 → Hyperdisk ML（高吞吐量唯讀共享，適合多 GPU 實例同時讀取模型權重）
- 需要動態調整 IOPS → Hyperdisk Balanced/Extreme（可在不停機情況下獨立調整 IOPS、吞吐量和容量）
💡 考試小提示：Local SSD 的資料在 VM 停止、刪除、搶佔或主機硬體故障時會永久遺失；不過在即時遷移（live migration）期間 Local SSD 資料會被保留。考題中如果強調「資料不能丟失」，絕對不能選 Local SSD。
Spot VM 與成本優化
Spot VM 核心概念
Spot VM 是 Google 利用閒置運算容量提供的低成本 VM，價格較隨選（on-demand）低 60-91%，但 Google 可以隨時回收（preempt）：
- 搶佔通知 — 回收前 30 秒發送 ACPI G2 軟關機信號，應用可利用 shutdown script 做善後處理
- 無最長存活限制 — 不同於舊版 Preemptible VM 的 24 小時上限，Spot VM 沒有固定存活時間
- 不保證可用性 — 不適合需要 SLA 的生產服務
容錯工作負載模式
Spot VM 最適合與 Managed Instance Group（MIG） 搭配使用：
- 批次處理管線 — MIG 混合使用 Spot VM 和標準 VM，設定 Spot VM 優先，標準 VM 作為保底容量
- 分散式運算 — MapReduce、Dataflow 等框架天然支援節點失敗，適合全 Spot
- CI/CD Runner — 建置環境可中斷重來，使用 Spot VM 大幅節省成本
- ML 訓練 — 搭配 checkpoint 機制，被搶佔後從最近的 checkpoint 恢復，GPU Spot VM 節省可觀費用
Sole-tenant Nodes
Sole-tenant Nodes 提供獨佔的實體伺服器，你的 VM 不會與其他租戶共享硬體：
- BYOL 授權合規 — Windows Server、Oracle、SQL Server 等按核心或按插槽授權的軟體，需要在專屬硬體上運行才符合授權條款
- 實體隔離 — 金融、醫療等產業的合規需求，要求工作負載在實體層級隔離
- Node Affinity — 透過 affinity labels 控制 VM 只能排程到特定的 Sole-tenant Node 或 Node Group
💡 考試小提示：當題目提到「bring your own license」或「per-core licensing compliance」，Sole-tenant Nodes 是唯一正確答案。
實戰情境
情境一：ML 訓練管線的成本優化
背景：資料科學團隊每天需要用 8 張 A100 GPU 進行模型訓練，單次訓練約 4-6 小時，可接受中斷重來。
架構決策：
- 使用 A2 Spot VM 掛載 GPU，搭配 MIG 自動重啟被搶佔的實例
- 訓練框架設定每 30 分鐘寫入 checkpoint 至 Cloud Storage，被搶佔後自動從最新 checkpoint 恢復
- 訓練資料存放在 Cloud Storage，透過 Cloud Storage FUSE 掛載到訓練 VM，避免複製大量資料
- 訓練完成的模型存到 Cloud Storage，由 Cloud Run 部署推論服務
- 預估成本節省：Spot VM 折扣 80% 以上，每月省下數萬美元 GPU 費用
情境二：有狀態應用的儲存設計
背景：一個內容管理平台需要在 GKE 上運行 WordPress 叢集（3 個 Pod），共享媒體檔案目錄，並連接 MySQL 資料庫。
架構決策：
- MySQL 使用 Cloud SQL（託管服務）或 GKE StatefulSet 搭配 pd-ssd 持久磁碟，確保資料庫效能和持久性
- 媒體檔案使用 Filestore 掛載為 NFS，讓所有 WordPress Pod 共享同一個
/wp-content/uploads目錄 - 靜態資源（CSS、JS、圖片）部署到 Cloud Storage 搭配 Cloud CDN 加速
- GKE 叢集設定 Cluster Autoscaler（最少 2 節點、最多 10 節點），搭配 HPA 根據 CPU 使用率自動擴展 WordPress Pod
重點整理
- GKE 三層擴縮：HPA/VPA 管 Pod → Cluster Autoscaler 管節點數 → NAP 管節點規格
- Release Channels 控制叢集版本策略：Rapid（搶先）→ Regular（平衡）→ Stable（穩定）
- Cloud Run 調校重點：Concurrency、Min/Max Instances、CPU 分配模式（request-based vs always-on）
- 儲存選型：pd-balanced 是通用起點；需要共享選 Filestore；需要最高 IOPS 選 Local SSD（但資料不持久）
- Spot VM 最高省 91%，務必搭配容錯設計（checkpoint、MIG 自動重啟）
- Sole-tenant Nodes 解決 BYOL 授權合規和實體隔離需求
下一步
在下一課中，我們將探討 AI/ML 架構與 Vertex AI——這是 PCA v6.1 新增的第一級考試主題，涵蓋 Gemini 模型、Agent Builder 與 Model Armor 的架構設計。