App Engine、Cloud Run、GKE 怎麼選？先看誰負責維運

同一個網站，可以部署在 App Engine、Cloud Run，也可以包成容器放進 GKE。功能都跑得起來時，到底該選哪個？我會先問三件事：現在交付的是原始碼還是容器、需要控制執行環境到什麼程度、團隊願意照顧哪些平台設定。

「無伺服器」也不是沒有伺服器，而是平台幫你處理較多底層工作。這能省掉管理節點的時間，但程式的權限、資料、效能、監控與費用仍是你的責任。

先看要交什麼給平台

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

這不是從「簡單」排到「厲害」的階梯。Kubernetes 確實提供更多編排能力，但如果只要跑一個 HTTP API，先建叢集未必有收穫。反過來說，應用若依賴 Kubernetes API、Operator、特定排程或網路模型，硬塞進 Cloud Run 也不會比較省事。GKE 的模式比較可以幫你檢查哪些設定由平台接手、哪些仍由團隊負責。

現有 App Engine 用得好，不必為了追新搬家

App Engine Standard 適合願意接受平台支援的語言、Runtime 與部署慣例，想把心力留給應用程式的團隊。程式和設定準備好後，可以用 gcloud app deploy 發佈。若既有服務已穩定運作，先看目前痛點：是 Runtime 限制、部署流程、成本，還是缺少自訂環境的彈性？沒有痛點，就不必只因 Cloud Run 更新較多而遷移。

別把 Standard 和 Flexible 混成一種計費與擴縮方式。App Engine 官方比較列得很清楚：Standard 可依設定縮到零個執行個體，Flexible 至少保留一個。Flexible 能更改執行環境，但也代表不同的啟動時間與常駐成本。評估現有服務時，先確認自己到底跑在哪個環境。

Cloud Run：有容器很好，只有原始碼也能試

假設團隊要部署一個影片轉檔 API，需要 FFmpeg 和特定套件，但不需要自己管理 Kubernetes。Cloud Run 服務值得先試，這種需要系統套件的應用可以自行建好容器映像再部署。若是一般、受支援的原始碼專案，也能使用 source deploy，由 Cloud Build 和 buildpacks 建置映像，再存到 Artifact Registry。不是每個 Cloud Run 專案都得先寫 Dockerfile；但程式需要特定系統套件或建置步驟時，就要確認 buildpack 是否支援，必要時自行定義映像。

# 一般受支援的 HTTP 專案：設定好專案、權限與計費後，在程式目錄執行
gcloud run deploy demo-api --source . --region asia-east1

這只是開始。上線前還要確認服務是否要公開、執行身分能存取哪些資源、請求逾時與並行量是否合適，以及新版本怎麼回退。Cloud Run 支援分批導流和回退版本，比「部署成功就讓全部使用者進來」多一層緩衝；實際的導流指令在 GCP-109：Cloud Run 入門。

如果任務是「Cloud Storage 有新檔案時產生縮圖」，可以用 Cloud Run functions搭配 Eventarc 觸發。這個產品在 2024 年 8 月前叫 Cloud Functions（第 2 代），舊教材和題庫寫的 Cloud Functions 多半指它；若標明第 1 代，對應的是現在的 Cloud Run functions (1st gen)。它適合一個入口、一段相對集中的處理邏輯；一般 Cloud Run 服務也能接事件，並不是事件一來就只能選 function。無論哪種方式，都要想好同一事件重送時會怎樣：縮圖是否會重複建立？失敗後能否安全重試？

可縮到零，不等於整張帳單歸零

Cloud Run 預設可隨請求減少執行個體；如果要減少啟動延遲，可以設最小執行個體，但閒置時也可能產生費用。依請求或依執行個體計費也會影響閒置 CPU 的行為和成本。更別忘了 Cloud Build、Artifact Registry、資料庫、網路傳輸等其他資源，不能把「服務沒人呼叫」直接翻成「整個系統零成本」。

同樣，GPU 需求也不是直接跳到 GKE Standard 的理由。Cloud Run 服務和 GKE Autopilot都有 GPU 選項；要比較的是支援的硬體與區域、啟動和載入模型時間、所需容量、費用，以及團隊是否需要 Kubernetes 的控制能力。

什麼時候才值得上 GKE？

當團隊確實要用 Kubernetes 的部署物件、排程、網路政策或既有 Operator，GKE 才開始有明顯價值。這時先看 Autopilot：Google 管理節點，你仍負責 Deployment、Service、資源請求、應用更新和觀測。若需要自行掌握節點配置或更多叢集設定，再比較 Standard。「微服務很多」本身還不足以決定要上 Kubernetes；要看這些服務是否真的用得到它的編排能力。

成本也沒有「Autopilot 一定比 Standard 便宜」的公式。Autopilot 官方文件指出，一般用途的工作負載可按 Pod 資源計費；指定特定硬體的工作負載可能改用節點型計費。沒有工作負載時，Autopilot 能縮到零個節點，但負載平衡器、儲存等相關資源仍要分別估。Standard 則要看節點利用率、叢集與人力維運成本。用自己的 Pod 配置和流量估價，比拿別人的三個 Pod 帳單比較可靠。

選好執行平台，還要把交付流程接起來

容器映像要能找到、能追溯。Artifact Registry負責存放映像與套件；Cloud Build trigger可以在程式碼變更時啟動建置。正式環境最好能回答：這個版本從哪個 commit 建出來？測試有沒有通過？部署用的是哪個映像？出問題時能回到哪個版本？

舊的 Container Registry 已於 2025-03-18 關閉、不能再寫入映像，新專案直接用 Artifact Registry。看到 gcr.io 網址也別急著判定是舊服務：由 Artifact Registry 代管的 gcr.io 網域不受影響。

若原本用 App Engine，想換 Cloud Run，先挑一個低風險服務驗證 Runtime、環境變數、資料存取、冷啟動和費用，別預設 app.yaml 能無痛變成另一平台的設定。若已在 Cloud Run，想搬到 GKE，容器映像也許能沿用，但服務發現、權限、擴縮和發布方式仍要重新設計；那不是只改一行部署指令。

ACE 題目怎麼判斷

• 容器化的 HTTP API，沒流量時要縮到零？ 先看 Cloud Run 服務。
• Cloud Storage 有新檔案就跑一段處理？ Cloud Run functions 搭配事件觸發，並想好同一事件重送時怎麼辦。
• 要用 Kubernetes，但不想管節點？ GKE Autopilot；需要自己掌握節點配置才看 Standard。
• 指名 App Engine Flexible，又要求縮到零？ 這是陷阱：Flexible 至少保留一個執行個體，Standard 才能縮到零。

我的選型順序會是：先寫出不能妥協的執行需求，再用最少維運負擔的平台做小範圍試驗；把延遲、可靠度、費用和團隊操作時間一起記下來。如果沒有 Kubernetes 的明確需求，就不用為了「企業級」三個字先建叢集。準備 ACE 時，把每個平台要你管理到哪一層說清楚，比背價格或關鍵字更有用。

想再細看受管平台的差異，可讀 Cloud Run、Cloud Run functions、App Engine 比較；個別平台的操作在 ACE-212：App Engine與 GCP-111：Cloud Run functions。下一篇 ACE-204：資料與 AI 服務怎麼接會從資料流繼續往下看。