條件 1
是否必須控制 OS、核心或既有 VM 相容性？
先列出無法改變的軟體、驅動、授權與主機需求。能跑容器本身不是使用 Kubernetes 的理由。
還要確認： 確認受支援映像、機型、修補與復原責任。
服務選型速查
GCP 運算服務怎麼選？
先看工作型態與責任，再比較功能與成本。
查看比較範圍與版本條件
五個服務家族、六種選項：App Engine 分為 Standard／Flexible；Cloud Run functions 以 Cloud Run service 執行。
官方資料查核：
選型前先問這 6 件事
這些條件可能同時成立。先找候選，再驗證限制；不能只靠一個關鍵字決定架構。
條件 2
是否確實需要 Kubernetes API、生態系或排程能力？
例如自訂 controller 或團隊已有 Kubernetes 平台契約；再比較 Autopilot 與 Standard 的功能限制。
還要確認： 檢查必需的節點／特權能力、Pod requests、節點擴縮與管理費。
條件 3
是處理請求，還是有開始與結束的工作？
HTTP／gRPC 服務先比較 Cloud Run service；有限的容器批次可評估 Jobs，不能套用同一個逾時上限。
還要確認： 分清 request 與 task、GPU task 例外、並行數及重試的副作用。
條件 4
需要哪一種 GPU、多少張、在哪個區域？
GPU 不是 VM 的專屬能力。Cloud Run、GKE 與 Compute Engine 都可能符合，差別在數量、機型、控制能力與限制。
還要確認： 確認單實例 GPU 數、配額、供應、計費模式與資料位置。
條件 5
用一個 HTTP／CloudEvent 函式進入點是否足夠？
函式是從原始碼建置到 Cloud Run 的程式模型。若需要完整容器控制，也可以直接用一般 service。
還要確認： 確認版本、部署 API、觸發器逾時、重試與冪等性。
條件 6
是否有保留 App Engine 服務與版本管理的需求？
先確認 Standard runtime 能否滿足；需要自訂 Docker runtime 時再評估 Flexible，同時比較其他容器平台。
還要確認： Standard 的擴縮模式會改變逾時；Flexible 每個 active version 至少保留一個實例。
維運責任怎麼分？
代管程度不能當成成本或能力的排名。每個平台都還需要應用安全、IAM、資料與復原設計。
Compute Engine Google 管實體基礎設施；你管理 guest OS、修補、應用、容量及復原。 GKE Google 管控制平面。Standard 由團隊管理節點池；Autopilot 進一步代管節點，但應用、IAM 與資料仍由你負責。 Cloud Run Google 管主機與執行平台；你管理容器、IAM、並行數、擴縮限制、資料與重試。 App Engine Standard Google 管受支援 runtime 與平台；你管理應用、擴縮模式、版本流量、IAM 與資料。 App Engine Flexible Google 管 App Engine 平台與底層 VM 生命週期；你管理應用、自訂容器及相關相依套件。 Cloud Run functions 平台建置函式並以 Cloud Run service 執行；你管理進入點、IAM、觸發器、重試與冪等性。
依條件比較
「支援」仍有設定與版本條件。逾時欄分別描述請求、task 或平台邊界，並非相同的計時單位。
表格可左右捲動；鍵盤可按 Tab 聚焦表格，再用左右方向鍵查看欄位。
| 比較條件 | Compute Engine | GKE | Cloud Run | App Engine Standard | App Engine Flexible | Cloud Run functions |
|---|---|---|---|---|---|---|
| 執行模型 | IaaS | 託管 Kubernetes | Serverless 容器 | PaaS 標準環境 | PaaS 彈性環境 | Cloud Run 上的函式 |
| 擴縮單位 | 以 MIG 設定擴縮訊號、上下限與排程 | HPA 調 Pod 數、VPA 調資源需求；節點由 Cluster Autoscaler／Autopilot 調整，三者用途不同 | Service 可依請求／CPU 擴縮；Jobs 依 task 數與 parallelism 執行，不是 HTTP 自動擴縮 | 支援 automatic、basic、manual；生命週期與請求逾時依模式不同 | 支援 automatic 或 manual；擴展需要 VM 啟動 | 現行函式以 Cloud Run service 擴縮；1st gen 的行為與限制不同 |
| 縮至零的條件 | 有條件：MIG 可手動調為 0；自動縮至 0 須使用不依賴運行中 VM 的訊號，且最低數量為 0、沒有要求容量的排程 | 分層判斷：Autopilot 無工作負載時可縮至 0 節點；Standard 不會自動把整個叢集縮至 0，個別節點池可為 0 | Service 在自動擴縮且最小實例為 0 等條件下可縮至 0；Jobs 完成後結束該次執行 | automatic／basic 在閒置且設定允許時可縮至 0；manual 會保留設定的實例 | 不能：每個 active version 至少 1 個 instance | 可縮至 0，仍須核對最小實例與其他服務費用 |
| 請求／工作逾時 | 沒有平台統一的 HTTP 請求逾時；仍受應用、代理及 VM 生命週期限制 | Kubernetes 沒有統一的 HTTP 逾時；應用、Ingress／負載平衡器與 Job 設定各自限制 | Service：單次請求最長 60 分鐘；Jobs：每個 task 最長 168 小時（7 天），GPU task 最長 1 小時 | 依 runtime／擴縮模式；一般 automatic 請求 10 分鐘，basic／manual 請求可達 24 小時 | 單次請求最長 60 分鐘 | HTTP 最長 60 分鐘；以 Functions v2 API 建立的事件函式最長 9 分鐘。排程／Task queue 函式與 1st gen 另有配額 |
| OS／runtime 控制 | 支援的 Linux／Windows OS 與自訂映像；可自行管理核心與軟體堆疊 | 符合節點 OS／架構的容器；節點與特權能力依 Standard／Autopilot 限制 | 符合容器契約的 Linux 64-bit 映像；不是任意 OS，也不支援 privileged 容器 | 使用平台支援的 runtime／版本；不能像 Flexible 自訂 Docker runtime | 支援以 Dockerfile 定義自訂 runtime | 使用支援的語言 runtime 與 Functions Framework；任意自訂映像改評估一般 Cloud Run service |
| GPU 支援 | 支援多種 GPU；機型、區域、配額與供應情況須另查 | 支援 GPU 工作負載；確認模式、加速器、區域與配額 | 支援；每個 instance 1 張 GPU，需符合區域、資源與 instance-based billing 條件 | 不支援直接配置 GPU | 不支援直接配置 GPU | 現行 Cloud Run 部署可設定 GPU；仍受 Cloud Run 資源與區域限制 |
| 狀態與耐久性 | 可搭配耐久磁碟；備份、複寫與故障復原仍要設計 | 可用 StatefulSet 與 PersistentVolume；不會因此自動得到備份或跨區容錯 | 狀態放在外部耐久儲存；實例本機檔案與記憶體不作唯一資料來源 | 記憶體與 /tmp 不作耐久資料來源；狀態另存資料服務 | 可寫本機磁碟，但磁碟會隨 VM 啟動重新初始化；耐久狀態仍要外置 | 把狀態存到外部耐久儲存；事件重送時避免重複副作用 |
| 啟動時間的變因 | 包含 VM 開機、啟動腳本與應用初始化；依映像與配置量測 | 受 Pod 排程、映像拉取及節點佈建影響；空叢集須先取得節點 | 受映像、資源配置及應用初始化影響；須用負載測試驗證，最小實例仍可能被重新啟動 | 依 runtime 與初始化量測；不能用固定毫秒數保證 | 需佈建／啟動 VM，依映像與初始化量測 | 包含執行個體與語言 runtime 初始化；依相依套件和配置量測 |
| 計費視角 | 依 VM 機型、執行時間及附屬資源計費 | 兩種模式都有叢集管理費；工作負載資源依模式與硬體計費 | Service 可選 request-based 或 instance-based；Jobs 使用 instance-based billing | 依執行個體類別與時數；免費額度有配置與用量條件 | 依底層 vCPU、記憶體、磁碟等資源計費 | 現行版使用 Cloud Run 計費；1st gen 使用自己的計費規則 |
服務說明與官方依據
本頁的場景與判斷是教學整理；產品限制依連結的官方文件核對，實際部署仍需確認區域、配額及當期支援。
IaaS
Compute Engine
自行管理 OS 的虛擬機器
- 適合先評估
- 既有 VM 遷移、Windows 軟體、需要 OS／核心或特定硬體控制的工作。
- 需要換個方向時
- 若只需要代管的 HTTP 容器且不想維護 OS，先比較 Cloud Run；事件處理並非不能用 VM，而是需自行維運。
- 縮至零
- 有條件：MIG 可手動調為 0；自動縮至 0 須使用不依賴運行中 VM 的訊號，且最低數量為 0、沒有要求容量的排程
- 逾時邊界
- 沒有平台統一的 HTTP 請求逾時；仍受應用、代理及 VM 生命週期限制
- 計費提醒
- 停機不代表磁碟、保留 IP 等附屬資源也停止計費。Spot 可被回收，不能只按折扣決定可靠性設計。
複習時分清楚： 先找 OS／相容性硬限制，再決定單台 VM 或 MIG；能縮至零與能從零自動擴回來是兩個條件。
延伸閱讀：Compute Engine 教學託管 Kubernetes
GKE
需要 Kubernetes API 與生態系時
- 適合先評估
- 確實需要 Kubernetes API、自訂 controller、排程或既有 Kubernetes 平台能力的容器工作。
- 需要換個方向時
- 只有容器不代表需要叢集；若團隊只想代管幾個 HTTP API，先比較 Cloud Run 的營運負擔。
- 縮至零
- 分層判斷：Autopilot 無工作負載時可縮至 0 節點；Standard 不會自動把整個叢集縮至 0，個別節點池可為 0
- 逾時邊界
- Kubernetes 沒有統一的 HTTP 逾時；應用、Ingress／負載平衡器與 Job 設定各自限制
- 計費提醒
- 每個叢集基本管理費 US$0.10／小時，延長支援等額外費用另計。每個帳單帳戶每月 US$74.40 抵用額只抵 Autopilot／zonal Standard 的管理費，不能抵 regional Standard 或運算費；一般 Autopilot 常按 Pod requests，指定硬體可能按節點計費。
複習時分清楚： 不要把 Autopilot 當成自動把應用 Pod 縮到零，也不要把 Standard 當成免費叢集。先分清 Pod、節點與管理費。
延伸閱讀：GKE 教學Serverless 容器
Cloud Run
容器服務與有開始、結束的 Jobs
- 適合先評估
- HTTP／gRPC API、容器化服務、事件接收器；有限的批次工作可評估 Jobs。
- 需要換個方向時
- 必須修改主機核心、使用 privileged 容器，或把單一實例的本機狀態當作耐久資料。
- 縮至零
- Service 在自動擴縮且最小實例為 0 等條件下可縮至 0；Jobs 完成後結束該次執行
- 逾時邊界
- Service：單次請求最長 60 分鐘；Jobs：每個 task 最長 168 小時（7 天），GPU task 最長 1 小時
- 計費提醒
- 不要只算請求數。最小實例、GPU、持續執行的實例、建置、映像儲存及網路等都可能產生費用；縮至零不等於整個專案免費。
複習時分清楚： 先分 Service 的 request 與 Jobs 的 task；Service 請求 timeout 不等於整個容器被停止，應用仍須處理取消、重試與重複副作用。
延伸閱讀：Cloud Run 教學PaaS 標準環境
App Engine Standard
支援語言 runtime 的 Web 應用
- 適合先評估
- 符合受支援 runtime、需要 App Engine 服務／版本與流量管理的 Web 應用。
- 需要換個方向時
- 需要自訂 OS／Docker runtime、GPU 或平台不支援的底層能力；先確認 runtime 限制。
- 縮至零
- automatic／basic 在閒置且設定允許時可縮至 0；manual 會保留設定的實例
- 逾時邊界
- 依 runtime／擴縮模式；一般 automatic 請求 10 分鐘，basic／manual 請求可達 24 小時
- 計費提醒
- 是否有閒置費用取決於擴縮模式與最小實例；還要計入其他服務與網路費用。
複習時分清楚： Standard 能否縮至零、請求能跑多久，都要一起看擴縮模式，不能只記「Standard = 10 分鐘」。
延伸閱讀：App Engine Standard 教學PaaS 彈性環境
App Engine Flexible
保留 App Engine 的自訂容器環境
- 適合先評估
- 需要 App Engine 服務／版本管理，同時需要自訂 runtime 或 native 相依套件。
- 需要換個方向時
- 必須縮至零、直接配置 GPU 或需要完整主機 OS 控制的工作。
- 縮至零
- 不能：每個 active version 至少 1 個 instance
- 逾時邊界
- 單次請求最長 60 分鐘
- 計費提醒
- 低流量也會有維持實例的成本；多個 active versions 也要分別評估容量與費用。
複習時分清楚： 自訂容器不等於自行管理主機；Flexible 每個 active version 的最小容量都要計入成本。
延伸閱讀：App Engine Flexible 教學Cloud Run 上的函式
Cloud Run functions
從原始碼建置的函式程式模型
- 適合先評估
- 以 HTTP 或 CloudEvent 進入點處理 webhook、檔案事件與單一用途邏輯。
- 需要換個方向時
- 需要自行控制完整容器入口或超出該部署 API／觸發器逾時的工作；有限批次可比較 Cloud Run Jobs。
- 縮至零
- 可縮至 0，仍須核對最小實例與其他服務費用
- 逾時邊界
- HTTP 最長 60 分鐘；以 Functions v2 API 建立的事件函式最長 9 分鐘。排程／Task queue 函式與 1st gen 另有配額
- 計費提醒
- 從原始碼部署也可能有 Cloud Build、Artifact Registry、Eventarc 等相關費用；不要把舊版免費呼叫數當成所有版本的統一計價。
複習時分清楚： 現行版與 Cloud Run 是共用平台，不是兩套互斥基礎設施。讀題時辨認 1st gen、Cloud Run Admin API 或 Functions v2 API。
延伸閱讀：Cloud Run functions 教學用情境檢查你的判斷
先寫下候選與排除理由，再展開參考判斷。能說明限制，比只選對服務名稱更有用。
情境一：每天一次、約 36 小時的 CPU 轉檔
轉檔程式已容器化，不需要 GPU 或對外 HTTP server；工作可分段保存 checkpoint。有人因為「Cloud Run 只能跑 24 小時」而直接改用 VM，你會怎麼核對？
查看參考判斷與檢核標準
先評估 Cloud Run Jobs。36 小時低於目前每個一般 task 的 168 小時上限；這不表示一定能成功，仍要確認 CPU／記憶體、區域、配額、資料輸出與失敗重試。若改用 GPU，task 上限是 1 小時，必須重設計分段或評估其他平台。
自行檢核
- 說出 task 與 HTTP request 的差別，不能拿 service 的 60 分鐘限制套到 Jobs。
- 指出 checkpoint、重試與輸出的冪等性；說明 GPU 會改變適用條件。
情境二：regional Standard 叢集與免費抵用額
團隊要建立 regional Standard 叢集，以為「Standard 管理費免費」，又打算把每月 US$74.40 credit 用來抵節點費。這份估價少了什麼？
查看參考判斷與檢核標準
Standard 與 Autopilot 叢集都會產生每叢集 US$0.10／小時的基本管理費。US$74.40 是每個帳單帳戶的每月抵用額，只適用 Autopilot 與 zonal Standard 的管理費；不能抵 regional Standard，也不能抵運算費。另估節點、磁碟、負載平衡器與網路，不能把這個 credit 當成專案零成本保證。
自行檢核
- 分清 zonal 與 regional，以及帳單帳戶與叢集的範圍。
- 將管理費、運算資源與附屬服務拆開估價，不套用通用的最便宜排名。
情境三：沒有流量，是否就沒有費用？
一個 Cloud Run service 設了兩個最小實例並使用 GPU；另一個 Compute Engine MIG 只用 CPU utilization 擴縮。可以說前者會自動免費、後者永遠不能縮至零嗎？
查看參考判斷與檢核標準
兩個說法都過度簡化。Cloud Run 保留的最小實例會有費用，GPU 又要求 instance-based billing；還可能有建置、映像與網路費。MIG 可以手動縮至零，但只靠運行中 VM 的 CPU 訊號不符合自動縮至零條件；若改用可從群組外取得的訊號，仍要符合最低數量與排程條件，並確認能從零擴回。
自行檢核
- 把縮至零、最小實例、GPU 計費與整個專案費用分開判斷。
- 指出 MIG 自動縮至零與從零擴出的訊號條件，而不是只回答可以／不可以。
複習時帶走的重點
- 先辨認工作型態與不能改變的限制，再比較維運責任、SLO 與成本。管理越多或越少都不是自動比較好的選擇。
- Compute Engine 的 MIG 可有條件縮至零；GKE 要分清 Pod、節點池與整個叢集，不能把這些數量當成同一件事。
- Cloud Run service 比 request timeout；Jobs 比每個 task timeout。GPU task 有不同上限，平台上限也不代表工作可不做 checkpoint 或重試。
- Standard 與 Autopilot 都有 GKE 管理費；免費抵用額有帳單帳戶與叢集類型的適用範圍。
- App Engine Standard 的請求限制依 runtime 與擴縮模式；Flexible 每個 active version 至少保留一個實例。
- Cloud Run functions 的現行版以 Cloud Run service 執行；部署 API、觸發器與 1st gen 差異必須辨認。
- 狀態能放在哪裡、如何備份與復原，是另一個設計問題。能縮至零與有免費額度，不能證明整個方案最低成本。