💡 先搞懂問題
虛構公司「晴空食品」有一支訂餐 API，原本跑在兩台 Compute Engine 虛擬機器上。這兩台機器一天 24 小時開著，可是真正忙的只有午餐和晚餐那幾個小時，半夜幾乎沒有人點餐，錢卻照付；遇到週年慶，流量一下子翻好幾倍，工程師得半夜手動加機器。上線新版本也很緊張：新程式直接蓋過舊程式，出錯時所有顧客一起遇到，要回到舊版還得重新部署一次。
於是團隊把 API 包成容器，搬到 Cloud Run。Cloud Run 是全受管的無伺服器容器平台：你交出一個容器映像（或原始碼，由平台幫你建置），它就給你一個 HTTPS 網址，依請求量自動增減執行個體（instance），沒有請求時可以縮到零。新手搬過來之後最常卡在四個地方：以為「無伺服器」就沒有上限也幾乎不花錢；分不清並行數（concurrency，一個執行個體同時處理幾個請求）和執行個體數的關係；不知道每次部署都會產生一個新的修訂版本（revision），而且預設立刻接走全部流量；還有被一串相近的名字搞混，例如 Cloud Run、Cloud Run functions、App Engine、GKE。
名稱先交代清楚：Cloud Run functions 就是原本的 Cloud Functions，2024-08-21 起改名，現行版本（原第二代）本身就部署在 Cloud Run 上，第一代改稱 Cloud Run functions (1st gen)。考試大綱與舊教材可能還寫 Cloud Functions，指的是同一個產品。這一頁以 Cloud Run 服務（service）為主線，因為函式最後也會變成 Cloud Run 上的服務，並行、執行個體、修訂版本、流量分配這些觀念完全通用。
生活比喻：快餐店的外帶窗口
想像一家快餐店，只做外帶，店面有一排可以開關的窗口。沒有客人時，窗口全部拉下來，不用排人站班；第一位客人走近，店員才開一個窗口，開窗需要幾十秒準備，這位客人得稍等。一個窗口的店員可以同時招呼好幾位客人（一邊收錢一邊等餐），排隊的人超過一個窗口忙得過來的量，就再開下一個窗口；店長規定最多開幾個，免得人手和成本失控。午餐尖峰前，店長也可以先指定「至少開一個窗口」，讓第一位客人不必等開窗。
換新菜單時，這家店不會一夜之間全面改賣新餐點。新菜單先在一個掛著「試吃」牌的窗口給員工試，接著讓 10% 的客人拿到新菜單，觀察有沒有人抱怨，沒問題再加到一半、再全面上市；新菜出了狀況，店長一句話就把所有客人導回舊菜單，舊菜單的食譜還在，不用重新研發。
這個比喻有三個地方和實際不同。第一，真實窗口的店員記得剛剛跟誰說過話，Cloud Run 的執行個體卻是無狀態的：平台隨時可能關掉閒置的執行個體，連用最小執行個體保溫的也一樣，所以購物車、登入狀態這類資料要放在 Firestore、Memorystore 或 Cloud SQL 等外部服務。第二，比喻裡「10% 的客人」聽起來像是挑固定的一群人，實際上流量分配預設是依每個請求隨機分到各修訂版本，同一位使用者連續兩次請求可能落到不同版本；需要黏著同一版本時，要另外考慮工作階段相依性（session affinity），而且它只是盡力而為。第三，拉下窗口就完全不花錢，在 Cloud Run 卻要看計費方式：依請求計費時閒置的執行個體不收費（但用最小執行個體保溫的，閒置時仍以較低費率計費），依執行個體計費則是執行個體存在多久就收多久。
🎮 互動實驗室一：成本與並行計算器
先選一個情境，或自己調整左邊的輸入：每月請求數、平均處理時間、尖峰倍數、每個執行個體的並行數、CPU 與記憶體、最小與最大執行個體數。右邊即時算出平均與尖峰需要幾個執行個體，並用示意單價比較「依請求計費」與「依執行個體計費」每月大約多少點。示意單價只保留官方價目表的幾個相對關係（依執行個體計費的每秒單價較低、沒有請求費；最小執行個體閒置時 CPU 以較低費率計費、記憶體照常），不是實際價格，實際費用請以 Cloud Run 定價頁與 Google Cloud Pricing Calculator 為準。每個情境下方有一題「先猜再看」。
一、輸入
| 示意單價（點） | 依請求計費 | 依執行個體計費 |
|---|---|---|
| 每 vCPU-小時 | 10（處理請求時） | 7.5（整段存活期間） |
| 每 GiB-小時 | 1（處理請求時） | 0.75（整段存活期間） |
| 每 1 萬次請求 | 1 | 不收 |
| 最小執行個體閒置時 | vCPU 1、GiB 1 | 同上方費率 |
二、計算結果
需要的執行個體 ≈ A ÷ 並行數（無條件進位；尖峰再乘尖峰倍數）
依請求計費的忙碌時數 ≈ 720 小時 × max(min(A, 1), A ÷ 並行數)
先猜再看
數字查證：2026 年 10 月，依 Cloud Run 官方文件（並行數上限 1,000、控制台新服務預設 80、每個修訂版本預設最多 100 個執行個體、請求逾時預設 5 分鐘最長 60 分鐘、CPU 與記憶體對應表、計費設定）與 Cloud Run 定價頁的計費規則。忙碌時數的公式是簡化估算：假設請求平均分散、能重疊的都重疊；真實流量有隨機起伏，實際執行個體數通常會比這個估計多一些。
🎮 互動實驗室二：修訂版本與流量分配模擬器
晴空食品的訂餐 API 目前只有一個修訂版本 v1，接走全部流量。你要把 v2 安全地推上線：先部署但不接流量、用標籤網址自己測、分 10% 給真實使用者觀察，沒問題再加碼，有問題就一鍵切回。每個按鈕都對應一行真正的 gcloud 指令，會記在指令紀錄裡。按「送出 100 個請求」看看流量怎麼分，紅色方塊是出錯的請求。勾選「v2 藏了一個 bug」可以練習回復；也可以故意先按「部署並立刻接流量」，看看沒有 --no-traffic 會發生什麼事。
行為查證：2026 年 10 月，依 Cloud Run「Rollbacks, gradual rollouts, and traffic migration」文件與 gcloud run deploy、gcloud run services update-traffic 指令參考。修訂版本名稱的隨機後綴、服務網址裡的專案編號與錯誤率都是示意。
🛠️ 操作教學：部署 Cloud Run 服務、掛標籤再分流量
不用登入 Google Cloud，也能先把流程走一遍。左邊是簡化的主控台，照步驟選專案、填映像與服務名稱、設定驗證與計費、調整執行個體與資源，建立後再部署第二個修訂版本並分配流量；右邊同步顯示等效的 gcloud CLI 與 Terraform，黃色底的那幾行就是目前這一步對應的寫法。你可以故意填錯看看驗證訊息，也可以改服務名稱、區域或並行數，看指令怎麼跟著變。
terraform destroy 會刪除這份設定建立的所有資源（Cloud Run 服務在 provider 裡預設開啟 deletion_protection，範例為了練習把它設成 false）。想讓 Google 代管 Terraform 的執行環境與 state，可以用 Infrastructure Manager；舊的 Cloud Deployment Manager 已經在 2026 年 3 月底結束支援，新設計不要再用。
自己動手時要注意
權限：部署者在服務上至少要有 Cloud Run 開發人員（roles/run.developer）角色，另外要能使用服務的執行身分，也就是在那個服務帳戶上有服務帳戶使用者（roles/iam.serviceAccountUser）；映像放在 Artifact Registry 時還需要 Artifact Registry 讀取者（roles/artifactregistry.reader）。管理整個專案的 Cloud Run 可以用 Cloud Run 管理員（roles/run.admin），練習用的個人專案通常已經是擁有者。呼叫「需要驗證」的服務，呼叫者要有 Cloud Run 叫用者（roles/run.invoker）。正式環境建議替服務建立專用的服務帳戶，只給它需要的權限，不要沿用預設的運算服務帳戶。
API 與費用：先啟用 Cloud Run Admin API；用 --source 從原始碼部署時，還會用到 Cloud Build 與 Artifact Registry。依請求計費、最小執行個體為 0 的練習服務，沒有請求時不收運算費，Cloud Run 每月也有免費額度（依請求計費每月 200 萬次請求、18 萬 vCPU-秒、36 萬 GiB-秒，以帳單帳戶計算，查證日期 2026-10-08）；但最小執行個體大於 0、依執行個體計費、以及 Artifact Registry 儲存的映像與 Cloud Build 建置時間都可能產生費用。新帳戶的 Free Trial 是 90 天、300 美元抵用金。
練習完怎麼刪：刪掉服務會一併刪除它的所有修訂版本；如果整個專案只拿來練習，刪除專案最乾淨，專案會先進入停用狀態、一段時間後才永久刪除。
# 刪除練習用的 Cloud Run 服務（所有修訂版本一起刪除）
gcloud run services delete menu-api --region asia-east1
# 用 Terraform 建立的就用 Terraform 刪
terraform destroy
# 整個專案只拿來練習時，刪除專案最乾淨（PROJECT_ID 換成你的專案 ID）
gcloud projects delete PROJECT_ID範例裡的專案 ID、專案編號、群組信箱都是佔位或示意。不要把服務帳戶金鑰、密碼或 API 金鑰寫進映像、環境變數、指令或範本：服務要存取其他 Google Cloud 資源時，直接用服務帳戶身分（不需要金鑰）；機密放在 Secret Manager，再掛成環境變數或檔案；從 GitHub Actions 等外部 CI/CD 部署時，用 Workload Identity Federation 換取短期憑證，不要下載服務帳戶金鑰；自己在電腦上操作則用 gcloud auth login 的使用者憑證。
AWS 互動教學：Lambda 與 API Gateway ↗ Azure 互動教學：App Service 與部署位置 ↗
📘 原理補完
服務、修訂版本、執行個體：三層要分清楚
Cloud Run 的服務是長期存在的東西：它有名稱、區域、對外網址，以及「流量要送到哪裡」的設定。服務名稱在同一個專案與區域內不能重複、最多 49 個字元、以英文字母開頭、不能以連字號結尾，而且建立後不能改名。每次部署或修改設定（映像、環境變數、資源、並行數……），Cloud Run 都會產生一個新的修訂版本，它是當下映像加設定的不可變快照，名稱像 menu-api-00002-b2m。舊的修訂版本不會被刪掉，這就是能夠「一鍵切回」的原因。真正在跑程式的是執行個體，每個執行個體屬於某一個修訂版本，由平台依流量增減。
服務網址有兩種格式：可以事先預測的決定性網址 https://服務名稱-專案編號.區域.run.app，以及每個服務都有、帶隨機識別碼的網址。替修訂版本掛上標籤之後，會多出 https://標籤---服務網址 這種只連到該修訂版本的網址，不受流量百分比影響。
執行個體怎麼增減：並行數、最小與最大執行個體
Cloud Run 的自動調整看兩件事：每個執行個體目前同時處理多少請求（相對於並行上限），以及 CPU 使用率。並行上限是天花板不是目標，CPU 已經很忙時，平台可能少送一點請求給它、提早加開新的執行個體。並行上限可設 1～1,000，控制台建立新服務時預設 80；用 gcloud 或 Terraform 建立時，預設值和 vCPU 數有關，所以正式環境最好明確寫出來。CPU 低於 1 vCPU 時，並行數必須是 1。
最大執行個體數是安全閥：它限制尖峰時最多開幾個，保護後端資料庫的連線數，也替帳單設上限；每個修訂版本預設最多 100 個，到頂之後多出來的請求會排隊，等不到就失敗。最小執行個體數預設 0，設成大於 0 時平台會保留暖好的執行個體，降低冷啟動延遲，代價是閒置時也計費。官方建議在服務層級設定最小與最大執行個體數（gcloud 用 --min、--max，Terraform 用服務的 scaling 區塊）；修訂版本層級的 --min-instances、--max-instances 只有原本就設定過修訂版本層級調整的服務才能用，兩種層級同時設定時，較小的最大值生效。要注意平台隨時可能關掉閒置的執行個體，連最小執行個體也一樣，所以程式不能依賴「某個執行個體一直活著」。
兩種計費方式
Cloud Run 服務有兩種計費設定。依請求計費（預設，舊稱「只在處理請求時分配 CPU」）：執行個體只在啟動、關閉，以及至少有一個請求在處理的期間計費，另外每次請求有請求費；沒有請求時 CPU 幾乎被收回，所以回應送出之後還想在背景繼續做事，可能做不完。依執行個體計費（舊稱「一律分配 CPU」）：執行個體從啟動到結束都計費、至少 1 分鐘，沒有請求費，CPU 每秒單價也比較低，而且整段期間都有 CPU 可以做背景工作；記憶體至少要 512 MiB。gcloud 用 --cpu-throttling／--no-cpu-throttling 切換，Terraform 用 cpu_idle。計費時間都以 100 毫秒為單位無條件進位。
下表整理服務最常用的預設值與上限（查證時間 2026 年 10 月，依 Cloud Run 官方文件；配額相關的上限可能因專案與區域而不同）：
| 項目 | 預設 | 範圍或上限 | gcloud／Terraform |
|---|---|---|---|
| 請求逾時 | 5 分鐘 | 最長 60 分鐘 | --timeout／template.timeout |
| 並行上限 | 控制台 80 | 1～1,000；CPU 低於 1 時必須是 1 | --concurrency／max_instance_request_concurrency |
| 最小執行個體 | 0 | 大於 0 時閒置也計費 | --min／scaling.min_instance_count |
| 最大執行個體 | 每個修訂版本 100 | 依配額 | --max／scaling.max_instance_count |
| CPU | 1 vCPU | 0.08～8；1 以上為 1、2、4、6、8 | --cpu／resources.limits.cpu |
| 記憶體 | 512 MiB | 最大 32 GiB；1 vCPU 最多 4 GiB、2 vCPU 最多 8 GiB、4 vCPU 最多 16 GiB | --memory／resources.limits.memory |
| Cloud Run jobs 任務逾時 | 10 分鐘 | 最長 168 小時；GPU 任務最長 1 小時 | gcloud run jobs |
修訂版本、標籤與流量分配
新服務第一次部署時，流量設定是「最新的修訂版本拿 100%」，之後每次一般部署，新修訂版本都會直接接走全部流量。要漸進上線，部署時加 --no-traffic（控制台是不勾「立即提供這個修訂版本」），再用 --tag 掛標籤取得專屬網址自己先測；確認後用 gcloud run services update-traffic 分配百分比：--to-revisions 以修訂版本名稱指定、--to-tags 以標籤指定、--to-latest 把 100% 給最新版。三者一次只能用一個；指定的百分比最多 100，沒指定到的部分依原比例分給其他正在接流量的修訂版本。
有一個容易忽略的副作用：只要流量被固定分配給指定的修訂版本（不論是分流還是切回舊版），之後的部署都會沿用這個分配，新修訂版本拿 0%，直到你再次用 --to-latest 回到「最新版拿 100%」。這是保護機制，但也常讓人以為「部署成功了怎麼沒生效」。流量分配預設依每個請求隨機決定；需要讓同一位使用者盡量停在同一個版本，可以啟用工作階段相依性，它用 cookie 盡力而為，而且優先於流量比例。
Cloud Run 家族與相鄰服務怎麼選
Cloud Run 底下有三種資源：服務（services）回應 HTTP 請求；工作（jobs）跑到完成就結束，沒有網址，可以手動、排程或由工作流程觸發，適合批次處理；工作者集區（worker pools）是常駐的背景工作者，例如從訊息佇列拉資料處理。Cloud Run functions 讓你只寫函式，平台負責打包成容器並部署成 Cloud Run 服務；觸發方式是 HTTP，或透過 Eventarc 接收事件（Cloud Storage 物件變更、Pub/Sub 訊息、經 Cloud 稽核記錄取得的各種 API 呼叫等）。現行版本的 HTTP 函式最長 60 分鐘、事件函式最長 9 分鐘，每個執行個體最多同時處理 1,000 個請求、最多 16 GiB 記憶體與 4 vCPU；第一代都是 9 分鐘、一次只處理 1 個請求，目前沒有公布淘汰日期，官方提供升級到 Cloud Run 的工具（2026-08-10 GA）。
| 選項 | 你交出什麼 | 怎麼觸發 | 能不能縮到零 | 適合 |
|---|---|---|---|---|
| Cloud Run 服務 | 容器映像或原始碼 | HTTP 請求（也可接 Eventarc、Pub/Sub 推送） | 可以（最小執行個體 0） | API、網站、無狀態微服務、AI 推論 |
| Cloud Run jobs | 容器映像 | 手動、排程、工作流程 | 跑完就結束 | 批次、資料處理、資料庫遷移腳本 |
| Cloud Run worker pools | 容器映像 | 常駐，自己拉工作 | 依設定 | 佇列消費者、長時間背景處理 |
| Cloud Run functions | 函式程式碼 | HTTP 或 Eventarc 事件 | 可以 | 檔案上傳後處理、訊息觸發的小段程式 |
| App Engine | 程式碼（標準）或容器（彈性） | HTTP | 標準環境可以；彈性環境至少 1 個 | 既有 App Engine 應用；新使用者官方建議 Cloud Run |
| GKE | Kubernetes 資源定義 | 依你部署的工作負載 | Pod 可以；叢集本身有管理費 | 大量微服務、有狀態工作負載、需要 Kubernetes API |
從原始碼到上線：周邊服務各管什麼
Cloud Run 只負責「跑」。映像放在 Artifact Registry（舊的 Container Registry 已在 2025-03-18 關閉，gcr.io 路徑要對應到 Artifact Registry 的 gcr.io 儲存庫才能繼續用）；建置交給 Cloud Build，gcloud run deploy --source 背後就是它；要多環境、要核准的持續交付可以用 Cloud Deploy；事件觸發交給 Eventarc。服務本身執行時用的身分是一個服務帳戶，它要存取 Cloud SQL、Cloud Storage 或 Secret Manager，就在那些資源上授權給這個服務帳戶，不需要任何金鑰檔。
判斷步驟
- 先看工作負載的形狀：事件觸發的小段程式選 Cloud Run functions；跑完就結束的批次選 Cloud Run jobs；需要 Kubernetes 的選 GKE；其餘無狀態 HTTP 服務選 Cloud Run 服務。
- 估算並行：平均同時處理中的請求 ≈ 每秒請求數 × 處理秒數，除以並行數就是大概要幾個執行個體；尖峰再乘上倍數，確認沒有超過最大執行個體數，也沒有壓垮下游資料庫。
- 延遲要求高、不能接受冷啟動，就設服務層級的最小執行個體；能接受偶爾慢一點，就保留 0，閒置不付費。
- 選計費方式：流量稀疏、閒置多選依請求計費；流量穩定、執行個體幾乎一直在忙，或回應後還要做背景工作，選依執行個體計費。
- 決定誰能呼叫：內部服務用「需要驗證」並只給必要的人 roles/run.invoker；對外的網站或公開 API 才允許公開存取，必要時前面再加負載平衡器與 Cloud Armor。
- 上線新版：--no-traffic 加 --tag 先測，再用 update-traffic 從小比例開始加，出問題就把 100% 指回舊修訂版本。
容易考錯的地方
把並行數和執行個體數混為一談：題目給每秒請求數與處理時間時，要先算同時處理中的請求，再除以並行數。並行數設成 1 常是干擾選項，它會讓執行個體數暴增，只在程式不能同時處理多個請求時才需要。
冷啟動找錯旋鈕：「第一個請求很慢」對應最小執行個體，不是最大執行個體、不是逾時，也不是改用更大的 CPU（更大的 CPU 只能縮短啟動時間，不能消除從零開始）。
以為部署就是上線：一般部署在「最新版拿 100%」的設定下會立刻接走全部流量；要先測試必須加 --no-traffic。反過來，流量被固定分配後，新部署拿 0%，不是部署失敗。
回復用重新部署：Cloud Run 保留舊修訂版本，最快的回復是 update-traffic 把 100% 指回去。重新建置舊版或刪除服務重建，都是比較慢又有風險的干擾選項。
Cloud Functions 和 Cloud Run functions 當成兩個產品：是同一個產品改名。看到「上傳檔案後自動處理」「收到 Pub/Sub 訊息就執行一小段程式」，答案通常是 Cloud Run functions（大綱可能寫 Cloud Functions）搭配 Eventarc；需要自訂執行環境或多個端點才改用 Cloud Run 服務。
App Engine 與 Cloud Run 的定位：App Engine 沒有被淘汰，但新專案官方建議用 Cloud Run；App Engine 彈性環境不能縮到零，標準環境可以。
相關考試：CDL 會考 Cloud Run 與 Cloud Run functions 的商業價值；ACE 大綱點名在 Cloud Run 管理修訂版本與流量分割，以及事件觸發的無伺服器運算；PCD 有一整節是部署到 Cloud Run，並點名流量分割做漸進發布與回復；PCA 會在架構情境中比較 Cloud Run、GKE 與 Compute Engine。
✅ 自我檢測
6 題原創題，選完立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6