跳至主要內容
登雲學院 CloudOn 登雲學院.
ESC
ACE 架構設計 — 第 3/5 篇

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

5min Bobo Chen
ACE-203

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

2024 到 2026 年,無伺服器運算已經不是「未來趨勢」,而是「現在進行式」。根據產業報告,超過 70% 的新專案會優先考慮無伺服器架構。但無伺服器不是萬靈丹,有時候你就是需要 Kubernetes 的完整控制權,有時候 App Engine 的簡單部署反而才是最佳解。

讀完這篇文章,你將學到:

  • 三大運算平台(App Engine、Cloud Run、GKE)的核心差異
  • 如何用決策樹選出最適合你專案的平台
  • 2026 年各平台最新技術更新(Cloud Run functions 重新品牌化、GKE Autopilot 成本優化)
  • Artifact Registry 容器映像管理最佳實踐
  • Cloud Build CI/CD 流程整合實戰

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

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 還是有它自己的優勢:

✅ 優勢

  1. 極簡部署:單一命令 gcloud app deploy,無需撰寫 Dockerfile
  2. 全自動擴充:從 0 到數千實例,完全自動
  3. 整合服務:自動配置負載平衡、SSL 證書、域名綁定
  4. 適合小團隊:不需要 DevOps 專家,開發者即可部署

❌ 限制

  1. 語言限制:僅支援特定語言(Python、Java、Node.js、Go、PHP、Ruby)
  2. 客製化受限:無法自訂底層環境
  3. 遷移困難:與平台綁定,遷移到其他雲端較困難
  4. 成本較高:App Engine Flexible 無法縮放至零;Standard 雖可縮放至零,但冷啟動與計費粒度不如 Cloud Run 精細

2.2 適用場景

場景說明
快速驗證 MVP創業團隊需要快速上線測試市場
內部工具企業內部管理系統,流量不大但需要穩定
教學專案教育機構或訓練營,學員不需學 Docker
舊專案遷移已經在 App Engine 上運行的專案

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 月,Google 宣布 Cloud Functions (2nd gen) 正式更名為 Cloud Run functions,併進 Cloud Run 生態系。也就是說:

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

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

  • HTTP 請求: 支援長達 60 分鐘
  • 事件驅動: 支援 9 分鐘 執行時間
  • WebSocket: 原生支援長連線
  • 基於 Knative: 開源標準,可跨雲遷移

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 有新檔案上傳時,自動產生縮圖

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=8Gi \
  --cpu=4

成本考量：

  • GPU 費用：約 $0.70/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 事件驅動整合

Cloud Run 可監聽 60+ Google Cloud 事件來源:

# 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 日關閉，gcr.io 的流量從此都由 Artifact Registry 接手，新專案一律得用 Artifact Registry。

4.2 核心優勢(2026 年版)

根據 Understanding Artifact Registry vs. Container Registry:

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

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.04 /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 節點

結論: 中小型工作負載,Autopilot 可節省 40-52% 成本

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

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

核心優勢：

  • 跨服務共享：一份承諾可同時用於 GKE、Compute Engine、Cloud Run
  • 靈活調配：根據實際工作負載動態分配折扣
  • 最高折扣：3 年承諾可享 55% 折扣

範例場景：

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

成本節省計算：

原始成本：100 vCPU × $0.0475/hour × 730 hours = $3,468/月
使用 3 年 CUD（55% 折扣）：$1,561/月
節省：$1,907/月（55%）

最佳實踐：

  • 先分析歷史使用量，再決定承諾數量
  • 優先用於長期穩定的工作負載
  • 搭配 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 服務)

讓 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(跨區域流量管理)

實現跨區域負載平衡,災難復原:

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 + GKEAI 平台 + 自訂訓練環境

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. App Engine 沒有官方的 app.yaml → Dockerfile 自動轉換工具，需手動撰寫 Dockerfile
#    (參考 runtime 對應的官方 base image，把 app.yaml 隱含的啟動方式寫成 CMD/ENTRYPOINT)
#    例如 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: 中小型工作負載,可節省 40-52% 成本
  5. GKE Standard: 需要完全控制時選擇
  6. Artifact Registry: 企業級容器倉庫,取代舊版 Container Registry
  7. Cloud Build: Git Push 自動部署,標準化 CI/CD 流程

8.2 2026 年趨勢預測

從產業的走向來看,接下來幾個趨勢值得留意:

  1. Serverless First: 新專案優先考慮無伺服器架構
  2. Knative 標準化: 基於 Knative 的跨雲遷移能力
  3. FinOps 文化: 精細化成本管理(Autopilot 是典範)
  4. AI 原生應用: Cloud Run + Vertex AI 整合更深入
  5. 邊緣運算: Cloud Run 擴展到邊緣節點

8.3 延伸學習資源

官方文件

實作教學

認證準備

  • 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 Functions（Cloud Run functions）適合事件觸發的單一函式
  4. GKE Autopilot 全託管節點管理；Standard 你管節點
  5. Artifact Registry 取代 Container Registry（已於 2025 年停用）

常見陷阱題：

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

Q：GCS 上傳檔案後自動觸發圖片壓縮，選什麼？ A：Cloud 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 生態系。

ACE 架構設計 — 3/5 完成 查看系列全覽 →

相關文章

您可能也會對這些文章感興趣

ACE-203
GCPComputeServerless

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

比較 App Engine、Cloud Run(含 Functions/Jobs)與 GKE(Autopilot/Standard),用決策樹與成本/維運角度選出最適合的 GCP 運算平台。

時事
5min
ACE-202
GCPComputeNetworking

打造不當機的系統：GCP 高可用架構設計實戰

完整掌握 GCP 高可用架構設計：從 Managed Instance Group 自動擴縮容、負載平衡器選型、Cloud CDN 全球加速，到多區域容錯設計。包含 2026 最新功能如 Predictive Autoscaling、Ser...

時事
4min
ACE-204
Data-AIBigQueryVertex AI

GCP AI 與大數據：從 BigQuery 到生成式 AI 的完整工具鏈

完整掌握 GCP 大數據與 AI 工具鏈：從 BigQuery 資料倉儲、Dataflow/Dataproc 數據處理、Pub/Sub 訊息佇列，到 Vertex AI 機器學習與 Gemini API 生成式 AI。包含實戰案例：智能客服...

時事
4min

相關學習資源

GCP 核心服務速查表41 個服務一頁掌握
速查
GCP 運算服務比較CE vs GKE vs Cloud Run vs App Engine
比較
ACE 模擬題練習30 題原創練習 + 詳解
練習
ACE 閃卡練習50 張核心概念翻轉閃卡
複習

查看全部資源 →

留言討論

徽章解鎖！