無伺服器時代：App Engine、Cloud Run 與 GKE 選型策略完全指南

打開 Google Cloud Console 準備部署應用程式，看到 App Engine、Cloud Run、Cloud Run Functions、GKE 一整排選項，你大概會卡一下：「到底該選哪一個？」這不只是技術問題，還牽涉到開發效率、維運成本、團隊能不能 hold 得住，是個關鍵決策。

這幾年無伺服器運算越來越多新專案優先考慮，但它不是萬靈丹——有時候你就是需要 Kubernetes 的完整控制權，有時候 App Engine 一行指令上線反而才是最佳解。

這篇就是要幫你解決「到底選哪個」的糾結。我們會把 App Engine、Cloud Run、Cloud Run functions、GKE 攤開來比，給你一棵決策樹，讓你下次在 Console 前不再卡住。

一、無伺服器時代的來臨：三種運算模式的本質差異

1.1 什麼是「無伺服器」？

無伺服器(Serverless)不是真的沒有伺服器，而是說你不用自己管伺服器。對比一下傳統部署流程：

傳統部署 → 購買/租用主機 → 安裝作業系統 → 配置網路 → 部署應用 → 監控擴充 → 安全更新

無伺服器 → 上傳程式碼 → 完成!

這種簡化是有代價的，就是拿控制權去換:你放掉對基礎設施的完全掌控，換來輕鬆很多的開發體驗和自動擴充。

1.2 三種運算模式比較表

特性	虛擬機器(Compute Engine)	容器(Cloud Run)	無伺服器(App Engine)
抽象層級	最低	中等	最高
控制程度	完全控制 OS/網路/資源	控制容器環境	只控制程式碼
擴充方式	手動/自動擴充 VM	自動擴充容器實例	自動擴充應用實例
啟動時間	分鐘級	秒級	毫秒級
計費方式	按 VM 運行時間	按請求 + CPU 使用	按實例小時
最低成本	始終運行(有免費層)	可縮放至零	可縮放至零
適用場景	舊版應用、特殊 OS	現代容器化應用	快速 Web 應用

1.3 2026 年的選擇建議

根據 Google Cloud 官方部落格,2026 年的定位已經很明確：

• App Engine = 禮賓服務：不想調整 YAML，專注開發功能
• Cloud Run = 中間地帶：Docker 控制 + 無伺服器體驗
• GKE = 專業工具箱：需要調整每個螺絲的團隊

二、Google App Engine：最簡單的起點

2.1 為什麼 App Engine 在 2026 年仍值得考慮？

Google App Engine 是 GCP 最早的產品之一(2008 年就發布了),Cloud Run 出來之後，很多人以為它已經過時。其實沒有。

App Engine 最大的好處就是省事：一行 gcloud app deploy 就上線，連 Dockerfile 都不用寫，負載平衡、SSL 憑證、域名綁定它全幫你配好。小團隊沒有 DevOps 也能自己部署，擴充還是從 0 到數千實例全自動。

代價是你得拿控制權去換。它只支援固定那幾種語言(Python、Java、Node.js、Go、PHP、Ruby)，底層環境動不了，跟平台綁得比較緊、之後想搬到別的雲也比較麻煩。成本上要注意：App Engine Flexible 不能縮放至零(始終有實例在跑、始終在計費),Standard 可以縮到零,但冷啟動和計費粒度都沒 Cloud Run 那麼細。

2.2 什麼情況選 App Engine?

簡單說：當「快」比「彈性」重要的時候。創業團隊趕著上線驗證市場、企業內部流量不大但要穩的管理工具、訓練營不想讓學員先學 Docker、或本來就跑在 App Engine 上的舊專案——這些都是它的甜蜜點。反過來，只要你開始需要自訂底層環境或更精細的成本控制，就該往 Cloud Run 看了。

2.3 實戰範例：部署 Python Flask 應用

# 1. 建立 app.yaml (唯一必要配置檔)
cat > app.yaml <<EOF
runtime: python39
entrypoint: gunicorn -b :$PORT main:app
EOF

# 2. 部署(就這麼簡單!)
gcloud app deploy

# 3. 開啟網站
gcloud app browse

對比 Cloud Run:需要撰寫 Dockerfile、推送映像、設定服務，步驟更多但更靈活。

三、Cloud Run 與 Cloud Run Functions：現代化無伺服器首選

3.1 Cloud Run functions 重新品牌化(2024-2026 更新)

這個改名很多人沒跟上：2024 年 8 月起，Cloud Functions (2nd gen) 正式叫 Cloud Run functions,併進 Cloud Run 生態系，現在考試和官方文件都用新名字了。對照一下：

舊名稱	新名稱	定位
Cloud Functions (1st gen)	Cloud Functions	舊版，維護模式
Cloud Functions (2nd gen)	Cloud Run functions	新版，推薦使用
Cloud Run	Cloud Run	容器化服務

根據 Google Cloud Functions in 2026，新版的技術特性包括：

• HTTP 請求: 支援長達 60 分鐘
• 事件驅動: 支援 9 分鐘 執行時間
• WebSocket: 原生支援長連線
• 基於 Knative: Knative(一套把容器跑成無伺服器服務的開源標準)讓你的服務不被 GCP 綁死，理論上可跨雲遷移

3.2 Cloud Run vs Cloud Run functions：何時選誰？

兩者雖然都掛在 Cloud Run 品牌下，但定位差很多：

Cloud Run (容器服務)

適合：

• 需要自訂 Docker 環境
• 多語言混用專案
• 複雜微服務架構
• 需要完全控制相依套件

範例場景: 一個需要 Python 3.11 + Node.js 18 + FFmpeg 的影片處理服務

Cloud Run functions (函數服務)

適合：

• 事件驅動工作負載(檔案上傳觸發、Pub/Sub 訊息)
• 單一功能邏輯(Webhook、API Proxy)
• 快速開發不想寫 Dockerfile
• 輕量級 API

範例場景: Cloud Storage 有新檔案上傳時，自動產生縮圖

📝 考場提點

選型題就是看題目丟哪個關鍵字給你：

• 「scale-to-zero 省錢」+「要跑容器」→ Cloud Run
• 「GCS / Pub/Sub 事件觸發」+「單一函式」→ Cloud Run functions
• 「要完整 Kubernetes 控制」+「不想管節點」→ GKE Autopilot
• 「不想寫 Dockerfile」+「只支援特定語言就好」→ App Engine

記住一個常被考的細節：App Engine Standard 能 scale-to-zero、Flexible 不能。題目要你 scale-to-zero 又點名 App Engine Flexible，那選項通常就是陷阱。

3.3 Cloud Run 計費模型(2026 年最新)

Cloud Run 最大的賣點就是可以縮放到零,而且按實際用量計費:

總費用 = CPU 費用 + 記憶體費用 + 請求費用 + 網路費用

CPU 費用 = CPU 核心數 × 使用秒數 × $0.00002400/vCPU-秒
記憶體費用 = GB 數 × 使用秒數 × $0.00000250/GB-秒
請求費用 = 請求次數 × $0.40/百萬請求

關鍵優勢: 沒有流量時 = $0 成本(App Engine 和 GKE 無法做到)

3.4 實戰範例：部署容器化應用到 Cloud Run

# 1. 建立 Dockerfile
cat > Dockerfile <<EOF
FROM python:3.11-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["gunicorn", "-b", ":8080", "main:app"]
EOF

# 2. 使用 Cloud Build 建置並部署(一行指令!)
gcloud run deploy my-service \
  --source . \
  --region asia-east1 \
  --allow-unauthenticated

# 3. 自動完成:
# - 建置 Docker 映像
# - 推送到 Artifact Registry
# - 部署到 Cloud Run
# - 產生 HTTPS 網址

3.5 Cloud Run 進階功能

🆕 Cloud Run GPU 支援（2025-2026 新功能）

根據 Cloud Run GPU 公告，Cloud Run 現已支援 NVIDIA L4 GPU：

核心特性：

• GPU 型號：NVIDIA L4 Tensor Core GPU
• 用途：AI 推論、影片處理、圖像生成、科學運算
• 自動擴縮容：保留 Cloud Run 的無伺服器特性，按實際使用計費
• 適用場景：機器學習模型推論、影像/影片處理、生成式 AI 應用

部署範例：

gcloud run deploy ml-inference \
  --image=asia-east1-docker.pkg.dev/my-project/my-repo/ml-model:latest \
  --region=us-central1 \
  --gpu=1 \
  --gpu-type=nvidia-l4 \
  --memory=16Gi \
  --cpu=4

L4 GPU 官方最低需求是 4 vCPU + 16 GiB 記憶體,記憶體開太小(例如 8Gi)會直接部署失敗，這點很容易踩雷。

成本考量：

• GPU 費用：約 $0.67/GPU-hour（比 GKE GPU 節點便宜）
• 優勢：無流量時 GPU 自動釋放，成本降至 $0
• 適合場景：間歇性 AI 推論需求（例如：批次圖片處理、定時模型預測）

1. 流量分割(Canary Deployment)

# 部署新版本但不切流量
gcloud run deploy --no-traffic --tag v2

# 逐步切換流量(10% v2, 90% v1)
gcloud run services update-traffic --to-revisions v2=10,v1=90

2. Eventarc 事件驅動整合

Eventarc(Google Cloud 的事件路由器，負責把各種服務發生的事件送到你的服務)讓 Cloud Run 可以監聽眾多 Google Cloud 事件來源——官方支援的來源很多(常見說法是 60+,實際數量會隨時間增加):

# Cloud Storage 檔案上傳觸發
@app.post("/")
def handle_storage_event(request):
    data = request.get_json()
    file_name = data['name']
    bucket = data['bucket']

    # 處理新上傳的檔案
    process_file(bucket, file_name)

    return "OK", 200

3. 最小實例數(減少冷啟動)

# 保持至少 1 個實例運行(減少啟動延遲)
gcloud run services update my-service --min-instances 1

權衡: 消除冷啟動 vs 增加成本(因為始終有實例運行)

四、Artifact Registry：容器映像的中央倉庫

4.1 為什麼需要 Artifact Registry?

用 Cloud Run 或 GKE 部署容器時，映像總得放在某個地方。Artifact Registry 就是 GCP 的企業級容器倉庫。舊版 Container Registry（gcr.io）已分階段退役——2025 年 3 月 18 日停止寫入、6 月 3 日停止讀取，10 月 14 日起 gcr.io 端點完全改由 Artifact Registry 接手，新專案一律得用 Artifact Registry。

📝 考場提點

這題很愛考時間點：gcr.io(Container Registry)已分階段退役——2025-03-18 停止寫入，6-03 停止讀取，10-14 完全由 Artifact Registry 接手,新專案一律用 Artifact Registry。考題選項裡如果還出現 gcr.io 或 Container Registry，八成就是要你挑出的「過時 / 錯誤」答案。

順手記另一個常被混淆的點：App Engine Standard 可以 scale-to-zero、Flexible 不行——別把這兩個搞反了。

4.2 核心優勢(2026 年版)

根據 Understanding Artifact Registry vs. Container Registry:

功能	Container Registry（已關閉）	Artifact Registry
存取控制	專案層級	儲存庫層級（細粒度）
支援格式	僅 Docker	Docker, Maven, npm, Python, Helm
區域化	有限	完整區域支援
漏洞掃描	基本	整合 Artifact Analysis（前身 Container Analysis）
部署驗證	無	整合 Binary Authorization

Binary Authorization(部署前的「門禁」，只放行你信任、簽過章的映像上線)能擋掉未經授權的容器跑進正式環境。這塊偏向 PCA / DevOps 範圍，ACE 知道「它是部署時的映像驗證機制」這個定位就夠了。

4.3 儲存庫組織最佳實踐

方案 1: 按環境分離

asia-east1-docker.pkg.dev/
├── my-project/
    ├── dev/          # 開發環境映像
    ├── staging/      # 測試環境映像
    └── prod/         # 正式環境映像

方案 2: 按團隊分離

asia-east1-docker.pkg.dev/
├── my-project/
    ├── team-backend/
    ├── team-frontend/
    └── team-ml/

4.4 映像管理關鍵實踐

1. 避免使用 latest 標籤

❌ 錯誤做法:

docker build -t asia-east1-docker.pkg.dev/my-project/repo/app:latest .

✅ 正確做法:

# 使用語意化版本號
docker build -t asia-east1-docker.pkg.dev/my-project/repo/app:v1.2.3 .

# 或使用 Git commit SHA
docker build -t asia-east1-docker.pkg.dev/my-project/repo/app:$(git rev-parse --short HEAD) .

2. 設定清理政策(降低成本)

# 建立清理政策:保留最新 10 個版本,刪除 30 天前的舊版
gcloud artifacts repositories add-cleanup-policy my-repo \
  --location asia-east1 \
  --keep-count 10 \
  --older-than 30d

3. 啟用漏洞掃描

# 啟用 Container Scanning API（專案層級）—— 啟用後所有推送到
# Artifact Registry 標準/遠端 Docker repo 的映像會自動掃描
gcloud services enable containerscanning.googleapis.com

# 建立 repo 時只需保留格式與位置
gcloud artifacts repositories create my-repo \
  --repository-format docker \
  --location asia-east1

4.5 成本優化建議

1. 區域化部署: 建立與 Cloud Run/GKE 相同區域的儲存庫(降低網路傳輸費用)
2. 定期清理: 使用清理政策自動刪除舊映像
3. 多階段建置: 使用 Docker multi-stage builds 減少映像大小

五、GKE:Kubernetes 的企業級選擇

🏆 GKE 2026 Gartner Magic Quadrant 領導者地位

根據 Gartner 2026 Magic Quadrant for Public Cloud Container Services，Google Kubernetes Engine (GKE) 被評選為領導者（Leader）：

核心優勢：

• 創新能力：Autopilot 模式、多叢集管理、AI/ML 整合
• 執行能力：企業級 SLA、全球部署、自動化維運
• 安全性：內建 Binary Authorization、Workload Identity、GKE Security Posture
• 成本優化：Autopilot 按 Pod 計費、Flexible CUDs 跨服務使用

5.1 什麼時候需要 GKE?

如果只是要部署一個簡單的 Web 應用，真的不用動到 GKE。GKE 適合的是這些場景：

場景	為什麼需要 GKE
複雜微服務架構	需要服務發現、流量管理、熔斷機制
混合雲/多雲	Kubernetes 是跨雲標準，可遷移到 AWS EKS/Azure AKS
批次運算	需要精細控制 Pod 調度、GPU 使用
有狀態服務	資料庫、訊息佇列需要持久化儲存
團隊有 K8s 經驗	已投資 Kubernetes 生態系工具

5.2 GKE Autopilot vs Standard:2026 年成本分析

到 2026 年，GKE 一共有兩種模式，而且計費方式差很多:

GKE Autopilot(自動駕駛)

計費模型:

費用 = Pod 請求資源 × 單價 + 系統開銷

系統開銷 = 每個 Pod 約 180m CPU + 512Mi Memory
CPU 單價 = $0.0445 /vCPU-小時
Memory 單價 = $0.005 /GB-小時

優勢:

• Google 管理節點(自動升級、修補、擴充)
• 按 Pod 計費，沒有 Pod = $0
• 內建最佳安全實踐

劣勢:

• 無法 SSH 到節點
• 無法使用特定機器類型
• Pod 資源請求需準確(否則浪費成本)

GKE Standard(標準)

計費模型:

費用 = 節點 VM 成本 + 叢集管理費

叢集管理費 = $0.10/小時 (~$72/月)
節點成本 = Compute Engine VM 價格

優勢:

• 完全控制節點配置
• 可使用 GPU、特定機器類型
• 免費層： $74.40/月 額度(可抵消一個區域叢集)

劣勢:

• 需要管理節點升級、安全更新
• 節點始終運行(即使沒有 Pod)

成本對比實測

根據 GKE Autopilot cost efficiency 的實測案例：

工作負載: 3 個 Pod，每個 0.5 vCPU + 2GB Memory

模式	每日成本	備註
Autopilot	$2.67	按 Pod 資源計費
Standard	$5.56	需運行完整 VM 節點

結論: 中小型、Pod 數不多又不必跑滿整台節點的工作負載，Autopilot 通常更省。上面這組數字來自第三方實測(非官方保證)，會隨配置與區域變動很大，別當成固定折扣——重點是抓住「按 Pod 計費 vs 按整台 VM 計費」這個差異。

💡 2025-2026 新功能：Flexible Committed Use Discounts (CUDs)

根據 GCP 承諾使用折扣更新，Flexible CUDs 現可跨服務使用：

核心優勢：

• 跨服務共享：一份承諾可同時用於 GKE、Compute Engine、Cloud Run
• 靈活調配：根據實際工作負載動態分配折扣
• 折扣幅度：跨服務的 spend-based Flexible CUD,3 年約 46%、1 年約 28%（要分清楚：Compute Engine 機型專屬的 resource-based CUD 才是 3 年 55%，兩者別搞混）

範例場景：

購買 100 vCPU 的 3 年 Flexible CUD
  ↓
可用於：
- 60 vCPU 分配給 GKE 叢集
- 30 vCPU 分配給 Compute Engine VM
- 10 vCPU 分配給 Cloud Run 服務

成本節省的大方向：

長期穩定的工作負載綁 3 年 Flexible CUD，大致能砍掉四成多的運算費用。實際省多少跟機型、區域、承諾額度都有關，別背死數字——進 GCP 定價計算器 用你自己的用量算一遍最準。

最佳實踐：

• 先分析歷史使用量，再決定承諾數量
• 優先用於長期穩定的工作負載
• 搭配 Autoscaling 處理流量波動

5.3 實戰範例：部署應用到 GKE Autopilot

# 1. 建立 Autopilot 叢集(Google 全託管)
gcloud container clusters create-auto my-cluster \
  --region asia-east1

# 2. 取得認證
gcloud container clusters get-credentials my-cluster --region asia-east1

# 3. 部署應用
kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=LoadBalancer

# 4. 查看服務 IP
kubectl get service nginx

5.4 GKE 進階功能

1. Workload Identity(安全存取 GCP 服務)

Workload Identity(讓 GKE 裡的 Pod 直接「借用」一個 GCP 服務帳號的身分，不必再自己保管金鑰檔)是 GKE 上存取 GCP 服務的官方推薦做法。讓 Pod 安全存取 Cloud Storage、BigQuery 等服務，完全不用管理金鑰：

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: my-app@project.iam.gserviceaccount.com
  name: my-app

2. GKE Autopilot 自動節點升級

# Autopilot 自動升級,無需設定
# Standard 需手動啟用:
gcloud container clusters update my-cluster \
  --enable-autoupgrade \
  --enable-autorepair

3. Multi-cluster Ingress(跨區域流量管理)

Multi-cluster Ingress(把流量同時導到多個區域的 GKE 叢集，做跨區負載平衡與災難復原)實現跨區域容錯。提醒一下：這塊 ACE 不太考,屬於 PCA / DevOps 的深度，初學者先知道有這東西就好，想深入再回頭看。

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: global-ingress
spec:
  template:
    spec:
      backend:
        serviceName: my-service
        servicePort: 80

六、選型決策樹與實戰建議

6.1 完整決策流程圖

開始
  │
  ├─ 需要完全控制 OS/網路/特殊硬體?
  │  └─ 是 → **Compute Engine**(虛擬機器)
  │
  ├─ 已有 Docker 容器?
  │  ├─ 是 → 需要 Kubernetes 編排?
  │  │  ├─ 是 → **GKE** (Autopilot/Standard)
  │  │  └─ 否 → **Cloud Run**
  │  │
  │  └─ 否 → 團隊有 Docker 經驗?
  │     ├─ 是 → **Cloud Run**(學習曲線低)
  │     └─ 否 → **App Engine**(極簡部署)
  │
  └─ 只需要執行函數?
     └─ 是 → **Cloud Run functions**(事件驅動)

6.2 按使用場景選擇

場景	推薦平台	理由
創業 MVP 快速驗證	App Engine	單一命令部署，專注產品開發
容器化微服務	Cloud Run	靈活性 + 無伺服器 + 可縮放至零
事件驅動處理	Cloud Run functions	檔案上傳、Pub/Sub、排程任務
企業級微服務網格	GKE Autopilot	服務發現、流量管理、可觀測性
需要 GPU 運算	GKE Standard	支援 NVIDIA GPU 節點
機器學習訓練	Vertex AI + GKE	AI 平台 + 自訂訓練環境

6.3 混合使用策略

實務上的做法: 不同服務用不同平台，各取所長！

舉個架構範例：

使用者請求
   ↓
Cloud Load Balancer
   ├─ Cloud Run (前端 Next.js 應用)
   ├─ Cloud Run functions (API Gateway)
   ├─ GKE Autopilot (後端微服務叢集)
   │   ├─ 使用者服務
   │   ├─ 訂單服務
   │   └─ 支付服務
   └─ Cloud Run (AI 模型推論服務)

6.4 遷移路徑建議

從 App Engine 遷移到 Cloud Run

# 1. 手寫 Dockerfile：app.yaml 沒有一鍵自動轉成 Dockerfile 的通用工具
#    (參考 runtime 對應的官方 base image，把 app.yaml 隱含的啟動方式寫成 CMD/ENTRYPOINT)
#    註：官方有 community helper (GoogleCloudPlatform/migrate-from-app-engine-to-cloud-run)，
#        且下方的 migrate-to-run 已能讀 app.yaml；多數情況用 Buildpacks 免寫 Dockerfile 最省事
#    例如 Python 應用：
#    FROM python:3.12-slim
#    WORKDIR /app
#    COPY . .
#    RUN pip install -r requirements.txt
#    CMD ["gunicorn", "-b", ":8080", "main:app"]

# 2. 或直接用 Cloud Buildpacks，免寫 Dockerfile（自動偵測 runtime 並建置容器）：
gcloud run deploy --source .

# 3. (選用) App Engine 標準環境可用官方遷移指令，沿用既有 app.yaml 設定：
gcloud beta app migrate-to-run

# 4. 比較成本與效能
# 5. 逐步切換流量

從 Cloud Run 遷移到 GKE

# 1. Cloud Run 已經是容器,直接使用相同映像
# 2. 建立 Kubernetes Deployment YAML
kubectl create deployment my-app --image=<cloud-run-image> --dry-run=client -o yaml > deployment.yaml

# 3. 部署到 GKE
kubectl apply -f deployment.yaml

七、Cloud Build CI/CD 流程整合

7.1 為什麼需要 Cloud Build?

手動部署的問題：

• ❌ 開發者本地端建置(環境不一致)
• ❌ 忘記推送最新程式碼
• ❌ 無法追蹤部署歷史
• ❌ 無法自動執行測試

Cloud Build 解決方案：

• ✅ Git Push 自動觸發建置
• ✅ 標準化建置環境(Docker)
• ✅ 自動執行測試、掃描漏洞
• ✅ 部署歷史完整記錄

7.2 完整 CI/CD Pipeline 實戰

目標: Git Push → 自動測試 → 建置 → 部署到 Cloud Run

1. 建立 cloudbuild.yaml

steps:
  # 步驟 1: 執行單元測試
  - name: 'python:3.11'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        pip install -r requirements.txt
        pytest tests/

  # 步驟 2: 建置 Docker 映像
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'build'
      - '-t'
      - 'asia-east1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$COMMIT_SHA'
      - '.'

  # 步驟 3: 推送到 Artifact Registry
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'push'
      - 'asia-east1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$COMMIT_SHA'

  # 步驟 4: 部署到 Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args:
      - 'run'
      - 'deploy'
      - 'my-service'
      - '--image=asia-east1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$COMMIT_SHA'
      - '--region=asia-east1'
      - '--platform=managed'

# 將映像標註為可部署版本
images:
  - 'asia-east1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$COMMIT_SHA'

2. 設定 Git 觸發器

# 當 main 分支有新 commit,自動執行建置
gcloud builds triggers create github \
  --repo-name=my-repo \
  --repo-owner=my-org \
  --branch-pattern="^main$" \
  --build-config=cloudbuild.yaml

3. 進階：多環境部署

# cloudbuild-prod.yaml (正式環境)
substitutions:
  _ENV: 'prod'
  _SERVICE_NAME: 'my-app-prod'
  _REGION: 'asia-east1'

steps:
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args:
      - 'run'
      - 'deploy'
      - '${_SERVICE_NAME}'
      - '--image=asia-east1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$COMMIT_SHA'
      - '--region=${_REGION}'
      - '--set-env-vars=ENV=${_ENV}'

7.3 整合安全掃描

steps:
  # 漏洞掃描(使用 Trivy)
  - name: 'aquasec/trivy'
    args:
      - 'image'
      - '--severity=HIGH,CRITICAL'
      - '--exit-code=1'
      - 'asia-east1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$COMMIT_SHA'

---

八、總結與下一步

8.1 核心要點回顧

1. App Engine: 最簡單的起點，適合快速驗證與小團隊
2. Cloud Run: 現代化首選，容器化 + 無伺服器 + 可縮放至零
3. Cloud Run functions: 事件驅動專用，2024 年整合進 Cloud Run 品牌
4. GKE Autopilot: 按 Pod 計費，Pod 數不多的中小型工作負載通常更省(實際幅度依配置而定)
5. GKE Standard: 需要完全控制時選擇
6. Artifact Registry: 企業級容器倉庫，取代舊版 Container Registry
7. Cloud Build: Git Push 自動部署，標準化 CI/CD 流程

8.2 對考生真正重要的兩個趨勢

其他預測就不一一列了，跟你考 ACE 真正有關的就兩件事：一是 scale-to-zero 成本意識——沒流量就不該付錢，選型時優先想「這個服務閒下來會不會還在燒錢」；二是 FinOps 成本管理,GKE Autopilot 按 Pod 計費就是這套思維的代表。把這兩條內化成直覺，選型題大半都能憑感覺先刪掉一半選項。

8.3 延伸學習資源

官方文件

• Cloud Run 官方文件
• GKE 官方文件
• Artifact Registry 最佳實踐

實作教學

• Cloud Run Quickstarts
• GKE Autopilot 教學
• Cloud Build CI/CD 教學

認證準備

• Associate Cloud Engineer: 涵蓋 App Engine、Cloud Run 基礎
• Professional Cloud Architect: 深入 GKE、微服務架構設計
• Professional Cloud DevOps Engineer: CI/CD、SRE 實踐

ACE 考試重點整理

📝 考場提點

進考場前把這幾條再掃一遍：

1. Cloud Run 預設 scale-to-zero，支援任何容器，最大請求時間 60 分鐘
2. App Engine Standard 可 scale-to-zero + 免費層，但語言受限；Flexible 不能 scale-to-zero
3. Cloud Run functions(原 Cloud Functions 2nd gen)適合事件觸發的單一函式
4. GKE Autopilot 全託管節點管理；Standard 你管節點
5. Artifact Registry 取代 Container Registry(gcr.io 2025-03-18 停止寫入、完全關閉 2025-10-14)

幾題常見的選型陷阱，先自己想再看答案：

Q：需要部署一個 Docker 容器化的 REST API，要 scale-to-zero 省錢，選什麼？ A：Cloud Run。App Engine Flexible 不能 scale-to-zero；GKE 成本較高。

Q：GCS 上傳檔案後自動觸發圖片壓縮，選什麼？ A：Cloud Run functions（GCS 觸發器最自然的搭配）。Cloud Run 服務本身要額外設定 Eventarc 才能接事件。

Q：團隊需要完整的 Kubernetes 控制權但不想管節點，選什麼？ A：GKE Autopilot。Google 管理節點，你只管 Pod。

---

8.4 下一步行動

1. 立即實作: 使用 Cloud Run 部署你的第一個容器應用
2. 成本試算: 使用 GCP 定價計算器 比較 App Engine vs Cloud Run vs GKE 成本
3. 建立 CI/CD: 設定 Cloud Build 自動化部署流程
4. 學習 Kubernetes: 如果團隊有需求，考慮 GKE Autopilot 入門

準備好了嗎？ 打開 Cloud Console，挑一個最適合你的平台，開始動手做你的無伺服器應用吧！

📖 延伸閱讀：更深入的 Serverless 選型分析請參考 Cloud Run vs Cloud Functions vs App Engine 完整比較。

下一課 ACE-204：GCP AI 與大數據工具鏈，學習從 BigQuery 到 Gemini 的完整 AI/ML 生態系。