Cloud Run 代管容器服務

Cloud Run 簡介

Cloud Run 是 Google Cloud 全代管的無伺服器容器平台。你交給它一個 OCI 映像檔與一個 port 號碼，它就會回給你一個 regional HTTPS 端點，能根據流量從零自動擴充到上千個 instance。PCD 考試將 Cloud Run 視為 stateless 網頁服務、API、事件處理器的預設運算選項，因此理解容器契約、擴縮槓桿與整合表面（VPC、Cloud SQL、Secret Manager、Eventarc）是必修課。

本指南涵蓋完整面向：Cloud Run services 與 Cloud Run jobs、HTTP 契約、並行調整、CPU 配置模式、第二代執行環境、startup CPU boost、sidecars、Direct VPC egress 與舊版 Serverless VPC Access connector、Cloud SQL 連線、Secret Manager 掛載、流量分割、透過全球外部 Application Load Balancer 設定自訂網域、IAM 驅動的呼叫、OIDC service-to-service 認證、Eventarc 觸發器，以及 Cloud Tasks 非同步擴散。

白話文解釋（Plain English Explanation）

三個類比讓你在進入 API 表面之前先抓住 Cloud Run 的直覺。

隨叫隨到的餐車類比

傳統伺服器像租了一間實體餐廳，不論晚餐人潮多寡都要付二十名員工薪水。Cloud Run 像一支餐車車隊，只有客人來了才出現。第一位客人要稍等餐車開過來（cold start）。一旦停妥，那台餐車的廚房可以同時招呼最多八十位客人（並行）。半夜兩點人潮散去，所有餐車開回車庫，你就停止付費——這正是 min-instances=0 的 Cloud Run service 所謂的 scale-to-zero 行為。如果你希望街角永遠停一台餐車待命，讓清晨第一位客人立刻被服務，就把 min-instances 調到 1，並接受閒置成本。

飯店櫃台與清潔班的類比

Cloud Run service 像飯店櫃台人員：坐在前台等客人提出需求（HTTP 流量），逐一快速回應後再回到等候狀態。Cloud Run job 像上午 11 點被派遣去整理所有退房房間的清潔班——沒有任何 inbound 請求，只是一份有限任務清單，被 ephemeral worker 平行執行完就下班。兩者跑的是同一套容器引擎，但一個是請求驅動、一個是任務驅動。挑錯（把每晚的批次任務寫成 service 然後輪詢佇列）是考試最常見的 Cloud Run 反模式。

結帳通道的類比

CPU 配置模式就像超市結帳通道。僅在請求期間配置 CPU 像快速結帳通道：你只有走到收銀台時才有店員，所以等候時不必付費，但店員在每位客人之間就消失。這對純同步 HTTP 服務是完美的。CPU always allocated 則讓店員在你的通道之間也持續站著——當你的容器有背景工作（sidecar 在串流日誌、goroutine 在沖刷緩衝、或 SDK 在請求執行緒外執行清理）時，就需要這種模式。它每秒成本較高，但能讓背景工作真正執行。挑錯模式，你的背景排程器會在 HTTP 請求返回的瞬間默默停擺。

Cloud Run 容器契約

Cloud Run 並不會跑任何你給的 binary。容器必須遵守一份特定契約，否則啟動失敗、逾時、或在請求中途被砍。

監聽於 $PORT

容器必須在 container start timeout（預設 240 秒、最高可調至十分鐘）內啟動 HTTP server，監聽於 0.0.0.0:$PORT。$PORT 是 runtime 注入的環境變數；即使預設是 8080，也不要硬寫——Cloud Run 可以變更。Express、Flask、Gin、Spring Boot 與標準 FaaS framework 都會自動讀 PORT；自製 server 則需要明確處理。

無狀態與 ephemeral 檔案系統

每個 instance 都有一份位於根目錄 / 的記憶體式 tmpfs 可寫檔案系統。寫進去的內容會計入該 instance 的記憶體上限，且 instance 被回收時消失。持續性的狀態必須存進 Cloud Storage、Cloud SQL、Firestore、Spanner 或其他外部服務。Cloud Run 確實支援把 Cloud Storage bucket 以 FUSE 方式掛載為 volume，且第二代執行環境也支援 NFS 掛載，但兩者都不能取代正式的資料儲存層。

請求生命週期與逾時

每筆請求的最大逾時是 60 分鐘（2023 年由原本的 5 分鐘提升）。超過後，load balancer 會關閉連線並由 Cloud Run 終止該 instance 的 handler。需要長時間執行的工作負載應該改用 Cloud Run jobs，或以 chunked response 的串流消費者模式處理。

SIGTERM 關機訊號

當 Cloud Run 把某個 instance 縮減掉時，會送出 SIGTERM，等候最多十秒讓你優雅關機，然後才送 SIGKILL。Production service 應該捕捉 SIGTERM 以排乾 in-flight 請求、沖刷日誌並關閉資料庫連線池。

Services 與 Jobs

Cloud Run 提供兩種執行模型。挑對是高分考點。

Cloud Run Services

Service 回應 HTTP、gRPC 或 WebSocket 流量。它根據請求量與 concurrency 自動擴縮、可 scale to zero，並具有穩定的 *.run.app URL。適合 REST API、gRPC 後端、webhook、伺服器端渲染網頁應用，以及 Eventarc 消費者。

Cloud Run Jobs

Job 是沒有 inbound 流量的批次工作負載。你定義 --tasks（平行 task 數量）與 --task-timeout，然後透過 gcloud run jobs execute、Cloud Scheduler、Workflows 或 Eventarc 觸發執行。每個 task 會收到 CLOUD_RUN_TASK_INDEX（從 0 開始）與 CLOUD_RUN_TASK_COUNT，可進行如處理資料集的 N 個分片這類完美平行工作。Job 在同樣語意下不會 scale to zero——它只在執行期間存在。

兩者之間的取捨

一個每秒處理 200 筆請求的 Web API 是 service。每晚渲染 50,000 份 PDF 的發票管線是 job（具體而言，是 --tasks=100、可讓五十個 task 平行跑的 job）。長期執行的佇列消費者屬於灰色地帶：如果它應該永遠跑，用 min-instances=1 加 CPU always allocated 的 service；如果它應該每小時對 backlog 跑一次，用 Cloud Scheduler 觸發的 job。

並行與擴縮槓桿

Cloud Run 的計費與延遲特性由四個旋鈕決定。

每 Instance 並行 (Per-Instance Concurrency)

預設一個 Cloud Run service instance 同時接受最多 80 筆並行請求，可在 1 到 1,000 之間設定。把 concurrency 設為 1 適用於不能共享 instance 的 CPU bound 工作負載（例如影片編碼器）；對於每筆請求大多在等待下游服務的 I/O bound 工作負載，可以調高到超過 80。較高的 concurrency 代表較少的 instance 與較低成本，但若有一筆爛請求把行程搞掛，影響範圍也較大。

Min Instances

--min-instances 永遠保留指定數量的暖機 instance，消除閒置後第一筆請求的 cold start。每個 min-instance 都要支付 request-not-active 的完整 CPU 費率，並非免費。Production 等級服務常以 min-instances=1 或更高運行；開發服務保持 0。

Max Instances

--max-instances 是水平擴充上限，預設 100，第二代執行環境每 region 每 service 可設到 1,000（再經 project 級 quota 提升可更高）。這個上限保護下游系統（例如 Cloud SQL）不被連線洪水淹沒。永遠搭配合理的 concurrency 設定一起調。

Request-only 與 Always Allocated 的 CPU 配置

CPU 配置模式控制請求之間是否把 CPU 節流至幾乎為零。預設是 僅在請求處理期間配置 CPU，較便宜，且對純請求/回應工作負載正確。CPU always allocated 則在以下情境必選：你需要請求返回後背景工作繼續執行、你使用會在請求路徑外消耗 CPU 的 sidecar、或你想讓 WebSocket 連線維持完全回應力。

執行環境世代

Cloud Run 提供兩種行為差異顯著的執行環境。

第一代 (Generation 1)

原始的執行環境。對某些工作負載 cold start 延遲較低，但缺少多項能力：不支援 NFS 掛載、Linux syscall 表面不完整（特別是無 ptrace、unshare 也有限）、不支援 UDP egress，且與低階網路程式碼相容性較弱。較舊部署的預設值；不建議新服務使用，若你需要任何上述功能更應避免。

第二代 (Generation 2)

完整 Linux 語意相容的執行環境，建構於 gVisor 沙箱的後繼方案之上。支援完整 Linux 語意、NFS 掛載、Cloud Storage FUSE 掛載、更大檔案系統容量，以及 UDP 流量。對部分映像檔 cold start 比 gen1 略長，但相容性優勢對多數工作負載已具決定性。部署時以 --execution-environment=gen2 選用。

Startup CPU Boost

獨立切換的功能（--cpu-boost），在 instance 啟動期間將可用 CPU 加倍，縮短 CPU bound 啟動的 cold start，例如 JVM 暖機或大型依賴樹初始化。費用僅在 boost 期間發生。將 --cpu-boost 搭配 min-instances >= 1 一起用，能在一線服務同時取得兩者優勢。

Sidecars 與多容器服務

Cloud Run 支援多容器 service：一個 revision 可在同一 instance 內跑一個 ingress container 加上最多九個 sidecar 容器，共享 localhost 網路與一份 emptyDir 風格的 volume。

何時使用 Sidecar

常見 sidecar 模式：抓取 metric 並轉送至 Cloud Monitoring 的 OpenTelemetry Collector、處理 IAM 認證資料庫連線的 Cloud SQL Auth Proxy、放在精簡 app 容器前面的 Nginx 或 Envoy、或日誌轉送 agent。Sidecar 生命週期與 ingress container 相同，並有自己的資源上限。

Sidecar 設定

Sidecar 在 service YAML 的 spec.template.spec.containers[] 下宣告。每個 revision 只有一個容器可帶 --port（即 ingress container）。所有容器的資源請求加總後計入 instance 的整體 CPU 與記憶體預算。請審慎規劃——一台 1 vCPU instance 被 app、Envoy、OTel Collector 共用，會把 app 餓死。

網路：VPC Egress 選項

預設 Cloud Run instance 透過 Google 代管 NAT 連到 internet。要到達 VPC 內的私有資源（私有 Cloud SQL、internal load balancer、GCE 上自架的服務），有兩種 egress 路徑。

Direct VPC Egress

建議的現代選項。Cloud Run service 直接掛到你 VPC 的某個 subnet 上；出向流量不經中介 connector 即可進入 VPC。延遲較低、成本較低、隨流量自動擴充。第二代執行環境可用。部署時以 --network 與 --subnet 旗標設定。

Serverless VPC Access Connector（舊版）

原始作法。你佈建一個 connector（位於 /28 subnet 中的 e2-micro instance 池），Cloud Run 將 egress 經由該 connector 路由。Connector 即便閒置仍按小時計費，且高吞吐下池本身可能變成瓶頸。當你需要在多個 serverless 服務間共用 connector，或你的 VPC 早於 Direct VPC egress 出現時有用。新設計應優先選 Direct VPC egress。

Egress 範圍設定

兩種選項都以 --vpc-egress 旗標控制範圍：

• all-traffic：每一個出向封包都經 VPC 路由（當 Cloud Run 需要以 VPC IP 出現在 IAM allowlist 時必要）。
• private-ranges-only：僅 RFC 1918 流量經 VPC；公網流量走 Google 代管 NAT（預設值）。

連線到 Cloud SQL

Cloud Run 透過三條路徑整合 Cloud SQL，取捨各異。

原生 Cloud SQL 連線

最簡單的路徑：部署時加 --add-cloudsql-instances=PROJECT:REGION:INSTANCE。Cloud Run 會跑一個內嵌的 Cloud SQL Auth Proxy，以 service account 上的 roles/cloudsql.client 角色完成認證。連線終結於 Unix domain socket，路徑為 /cloudsql/INSTANCE_CONNECTION_NAME。不需資料庫公網 IP、不需手動管理 proxy。

透過 Direct VPC Egress 連到私有 IP

對於使用私有 IP 的資料庫（production 預設），把 Cloud Run 透過 Direct VPC egress 掛到同一個 VPC，然後直接連到資料庫的私有 IP。這是延遲最低的選項，也是僅設定 private_network 的 Cloud SQL instance 必要的方式。

以 Sidecar 跑自架 Cloud SQL Auth Proxy

把 Cloud SQL Auth Proxy 當 sidecar 跑。可完整掌控 proxy 版本與設定；當你需要對資料庫使用者啟用 IAM Authentication 或做每連線日誌時很有用。

連線池注意事項

Cloud Run instance 可能迅速被拉起，每個 instance 的連線池乘上 max-instances 必須容納於資料庫的 max_connections 之內。對於 max_connections=100 的 Cloud SQL instance，一個 --max-instances=50 且每 instance 連線池為五的 Cloud Run service 就能塞爆資料庫。常見緩解方式是把 PgBouncer 當 sidecar 跑，或獨立部署成 proxy 層。

Secret Manager 整合

Cloud Run 原生從 Secret Manager 讀 secret。有兩種掛載模式。

環境變數模式

--set-secrets=DATABASE_PASSWORD=db-password:latest 在 instance 啟動時把 secret 注入為 env var DATABASE_PASSWORD。版本在每個 revision 上解析一次；latest 釘住的是部署當下的版本，並非動態。輪換 secret 需要部署新 revision。

檔案 Volume 模式

--set-secrets=/secrets/db=db-password:latest 將 secret 掛載為 /secrets/db 下的檔案。應用程式在 runtime 讀取該檔案路徑。預設與 env var 模式同樣是 revision 釘版，但用 latest 搭配 pinned=false 旗標（支援的情況下）會讓掛載重新解析。

IAM 要求

Cloud Run 的 service account 需要對每個 secret 具備 roles/secretmanager.secretAccessor。沒授權會造成啟動錯誤，且常被誤判為 image pull 失敗——當新部署無法啟動時請先檢查 secret IAM binding。

流量分割與 Revision

每次部署都建立一個不可變的 revision。流量是獨立的原語，可在多個 revision 之間任意分配。

Canary Release

gcloud run services update-traffic --to-revisions=rev-005=10,rev-004=90 把 10% 流量導到新 revision、90% 留在前一個。在 Cloud Monitoring 看錯誤率與延遲，滿意後再以 --to-latest 全量升級。

標記化 Revision

每個 revision 可加上 tag（--tag=preview），會產生形如 preview---my-service-abc.run.app 的 URL。不論流量分割如何，該 URL 100% 路由到標記的 revision——非常適合在不影響 production 流量的情況下做 release candidate 的 QA 測試。

Blue/Green 切換

要做瞬間切換，先以 --no-traffic 部署，透過 tag URL 預熱，然後用一行指令把流量翻到 100%。Rollback 只是同一條指令指回前一個 revision。

自訂網域與全球 Load Balancer

預設的 *.run.app URL 適合後端用，但 production 服務通常會掛上自訂網域。

Cloud Run Domain Mapping

gcloud run domain-mappings create --service=my-service --domain=api.example.com 會簽發代管 TLS 憑證，並透過 Cloud Run 的 regional ingress 路由到 service。每個 mapping 只能落在單一 region，且缺少完整 load balancer 的進階流量管理。

全球外部 Application Load Balancer

production 等級的選項。指向 Cloud Run service 的 serverless NEG（network endpoint group）型別為 SERVERLESS，透過外部 Application Load Balancer 統一接管。優點：全球 anycast IP、Cloud CDN、Cloud Armor 提供 WAF 與 DDoS 防護、IAP 進行 identity-aware proxy、跨多個後端服務的自訂路由規則，以及透過 Certificate Manager 取得代管憑證。這是 Cloud Run 上 production HTTPS 服務的標準架構。

多 Region 部署

把同一個 service 部署到多個 region，全部以 serverless NEG 掛到一個全球 load balancer，流量便會自動路由到最近的健康 region。再搭配 Cloud Storage 與 Spanner，就是完整的全球堆疊。

IAM、認證與 Service-to-Service 呼叫

Cloud Run 的呼叫模型從底層就是 IAM 驅動。

公開 vs 認證服務

--allow-unauthenticated（或把 roles/run.invoker 授予 allUsers）讓 service 可公開存取。沒有這個設定時，每筆請求都必須帶 Google 簽發的有效 identity token。考試常測你是否預設拒絕公開存取——對內部服務答案通常是「是」。

roles/run.invoker 角色

控制誰能呼叫 Cloud Run service 的單一權限。可授予 service account、使用者、或 allAuthenticatedUsers。搭配 VPC ingress 限制（--ingress=internal 或 internal-and-cloud-load-balancing），就形成 defense-in-depth 防線。

Service-to-Service 的 OIDC ID Token

當 service A 呼叫 service B（兩者都在 Cloud Run）時，service A 必須取得一個 Google 簽發、audience 為 service B URL 的 OIDC ID token。Metadata server 提供：http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://service-b.run.app。將 token 以 Authorization: Bearer <token> 附加在 outbound 呼叫上。Google client library（Python 的 google-auth、Go 的 golang.org/x/oauth2/google）在你建立 IDTokenCredentials 來源後會自動處理。

Ingress 限制

--ingress 接受 all、internal、internal-and-cloud-load-balancing。internal 僅接受同一 VPC network 或 VPC Service Controls perimeter 的流量；internal-and-cloud-load-balancing 另外允許來自全球外部 load balancer 的流量。這是不該被 *.run.app URL 直接打到的 service 的 production 設定。

以 Eventarc 設定事件驅動觸發器

Eventarc 是把 Cloud Run service 接上 Google Cloud 各種事件來源的整合層。

Eventarc Trigger 來源

一個 trigger 把事件來源（Cloud Storage finalize、Pub/Sub topic、任何服務的 Cloud Audit Log、Firestore 文件變更、BigQuery job 完成等）綁定到 Cloud Run service 的 URL。事件以 CloudEvents 格式的 HTTP POST 投遞，type 與 source 在 header 中。

常見模式

處理影像上傳的 Cloud Run service，以 google.cloud.storage.object.v1.finalized 為事件、以特定 bucket 為過濾條件訂閱 Eventarc trigger。合規掃描器以整個 org 範圍訂閱 setIamPolicy 的 Cloud Audit Log。文件解析器訂閱 fronting Apigee webhook 的 Pub/Sub topic。

Trigger 建立

gcloud eventarc triggers create my-trigger --location=us-central1 --destination-run-service=processor --destination-run-region=us-central1 --event-filters="type=google.cloud.storage.object.v1.finalized" --event-filters="bucket=uploads" [email protected]。Trigger 的 service account 需要在目標上具備 roles/run.invoker，並在 project 上具備 roles/eventarc.eventReceiver。

以 Cloud Tasks 做非同步擴散

當同步請求觸發的工作量超過 60 分鐘逾時，可用 Cloud Tasks 把長尾任務卸載出去。

它如何嵌入架構

HTTP 請求 handler 入列 N 筆 Cloud Task 指向 worker 的 Cloud Run service，然後立即回 200。Cloud Tasks 將每筆任務以 HTTP POST 派送至 worker，遵守每佇列的速率上限（max_dispatches_per_second）、並行（max_concurrent_dispatches）與重試策略（max_attempts、exponential backoff）。

Cloud Tasks 與 Pub/Sub 的取捨

Cloud Tasks 提供明確的每任務控制：可排程某筆任務在十五分鐘後執行、依任務名稱去重、取消特定任務。Pub/Sub 吞吐更高、提供 at-least-once 投遞但缺乏每訊息控制。對於每個任務代表一單位進度的擴散工作（每位要寄信的客戶、每個要轉檔的檔案），Cloud Tasks 較乾淨。對於事件串流，優先 Pub/Sub。

認證任務派送

Cloud Tasks 可在每筆 HTTP 派送上附加 OIDC token，與 service-to-service 認證模式相同。佇列的任務設定指定 oidcToken.serviceAccountEmail 與 oidcToken.audience，worker 的 Cloud Run service 即可用與其他認證呼叫者相同的方式驗證。

常見陷阱

讓 Cloud Run 使用者反覆吃癟的模式。

忘了綁 0.0.0.0

綁在 127.0.0.1:$PORT 會讓容器在自己的 namespace 內可達，卻無法被 Cloud Run 前端打到。永遠綁 0.0.0.0。

寫到非可寫路徑

雖然檔案系統可寫，許多 base image 將特定目錄設為唯讀。請使用 /tmp 作為暫存空間，並確認你框架的預設 cache 目錄可寫。容器啟動失敗時的「permission denied」常追到這裡。

把 min-instances 誤當作保留容量

min-instances=10 維持十個暖機 instance，但不保留爆量容量。如果流量突然衝到 1,000 筆並行、而 service 設定 concurrency=80，Cloud Run 仍需 cold start 額外 instance。要拿到可預期的爆量行為，請把 min-instances 加上 --cpu-boost 加上調好的 --max-instances。

把背景執行緒當免費

在預設的「僅請求期間 CPU」模式下，背景 goroutine、asyncio task、計時器 callback 都在請求之間被暫停。仰賴定期 flush 的應用程式碼會無聲故障。要嘛開 CPU always allocated，要嘛把工作搬到 Cloud Scheduler 觸發 Cloud Run job。

撞到 Cloud SQL 連線上限

100 max-instance 的 Cloud Run service、每 instance 池為十，尖峰時可能需要一千條連線。Cloud SQL db-custom-2-7680 預設 100 max connections。請選擇：把資料庫規格加大、降低 --max-instances、或在資料庫前面架 PgBouncer。

真實世界案例

一家電商把結帳 API 以 Cloud Run service 跑：--min-instances=5、--max-instances=200、--concurrency=40、--cpu=2、--memory=2Gi、第二代執行、--cpu-boost。Direct VPC egress 連到私有 Cloud SQL Postgres 與私有 Memorystore Redis。Secret Manager 以檔案掛載 Stripe API key。Service 跑在全球外部 Application Load Balancer 後面，前面掛 Cloud Armor 與 Cloud CDN；自訂網域 checkout.example.com 透過 Certificate Manager 對應。

訂單確認信由姊妹 Cloud Run service 處理，並在結帳 service 的 service account 上註冊為 roles/run.invoker。結帳 service 從 metadata server 以信件 service 的 URL 為 audience 取得 OIDC ID token，將訂單 payload POST 過去。信件 service 再把延遲後續（七天後寫評價邀請、三十天後寫補貨提醒）入列 Cloud Tasks。

每晚一支 Cloud Run job 以 --tasks=50、--task-timeout=30m 從 BigQuery 重生產品搜尋索引到 Algolia。Cloud Scheduler 在 02:00 UTC 觸發 job。Eventarc 把 fraud 掃描的 Cloud Run service 訂閱到結帳 service 在訂單金額超過 5,000 美元時送出的 Pub/Sub 訊息。

最終狀態：整個電商堆疊跑在 Cloud Run、自動從閒置擴充到 Black Friday 高峰、沒有伺服器需要打補丁，成本約為兩年前等量永遠開機 Kubernetes 部署的 18%。

考試重點與服務選擇

PCD 考試反覆測試同一組 Cloud Run 決策。背熟以下對應。

• 「stateless HTTP service、要能 scale to zero」 指向 Cloud Run service。Cloud Functions 2nd gen 也合格但它自身就建在 Cloud Run 上；題目暗示自製容器或多端點時選 Cloud Run。
• 「批次工作、有限任務清單、無 inbound HTTP」 指向 Cloud Run jobs。誘餌：用 service 加輪詢迴圈。
• 「需要 HTTP 回應後背景工作繼續」 指向 CPU always allocated。預設模式會在請求之間暫停 CPU。
• 「不用長效 secret 做 service-to-service 認證」 指向從 metadata server 取得的 OIDC ID token，並以 roles/run.invoker 驗證。誘餌：把 API key 放在 Secret Manager。
• 「Cloud Run 必須連到私有 Cloud SQL」 指向 Direct VPC egress 加 --add-cloudsql-instances。誘餌：Serverless VPC Access connector——可行但是舊版。
• 「Cloud Run 前要全球 anycast IP、Cloud CDN、Cloud Armor」 指向全球外部 Application Load Balancer 加 serverless NEG。誘餌：domain mapping（regional only、無 CDN、無 WAF）。
• 「Canary 把 10% 流量切到新 revision」 指向 gcloud run services update-traffic --to-revisions=NEW=10,OLD=90。誘餌：用 --no-traffic 部署再用 Cloud DNS 做權重路由。
• 「物件落地 Cloud Storage bucket 時觸發 Cloud Run」 指向 Eventarc trigger 監聽 google.cloud.storage.object.v1.finalized。誘餌：Cloud Function——也行但題目通常釘 Cloud Run。
• 「Cold start 把 p99 拉爆」 指向 --min-instances >= 1 加 --cpu-boost 加第二代執行。誘餌：改用 App Engine standard。
• 「超過請求逾時的長時間擴散工作」 指向 Cloud Tasks 派送給 worker Cloud Run service。誘餌：把請求逾時拉到 60 分鐘（仍受限）。

常見問題

Q1：Cloud Run service 的最大請求逾時是多少？

A1：每筆請求 60 分鐘，由原本的 5 分鐘上限提升而來。注意全球外部 Application Load Balancer 自身的 backend timeout 預設為 30 秒，因此用 load balancer 接 Cloud Run 時，通常需要把 backend timeout 一起拉高。WebSocket 連線同樣受此上限約束。

Q2：什麼時候該選 Cloud Run jobs 而非 services？

A2：當工作負載沒有 inbound HTTP 流量、且是有限任務清單時選 jobs：每晚報表、批次影像處理、資料庫遷移、或一次性資料回填。Jobs 讓你以 --tasks 設定平行度、以 --task-timeout 最高設到 24 小時。Service 在此處不對：它期待流量、按請求數而非任務數擴縮。

Q3：Cloud Run 如何處理 secret，又如何輪換？

A3：Cloud Run 透過 --set-secrets 原生整合 Secret Manager，可掛載為 env var 或檔案。使用 :latest 會在 revision 建立時解析版本，因此輪換需要新部署。要自動輪換，請以檔案模式掛載並釘 latest 讓 volume 重新解析，或在 Secret Manager 透過 Eventarc 觸發 secretVersionCreated 時，由 Cloud Build pipeline 觸發重新部署。

Q4：Direct VPC egress 與 Serverless VPC Access connector 有什麼差別？

A4：Direct VPC egress 將 Cloud Run service 直接掛到 subnet、隨流量自動擴充、無小時閒置費用，是現代建議。Serverless VPC Access connector 是代管 VM 池當代理——它早於 Direct VPC egress、即便閒置仍按小時收費、高吞吐下可能變吞吐瓶頸，僅為相容舊環境而保留。新設計請選 Direct VPC egress。

Q5：兩個 Cloud Run service 之間如何做 service-to-service 認證？

A5：呼叫方以被呼叫 service URL 為 audience，從 metadata server 取得 Google 簽發的 OIDC ID token，附在 Bearer header，被呼叫方以 roles/run.invoker IAM 驗證並強制呼叫權。Google client library 自動處理 token 取得。沒有共享 secret、沒有長效 API key，且 token 自動輪換。

Q6：Cloud Run service 可以保持 WebSocket 連線嗎？

A6：可以。WebSocket 與 HTTP/2 串流皆受支援，但每個開啟的連線會計入該 instance 的並行上限，且連線壽命由請求逾時限制（最大 60 分鐘）。對於大規模、長期連線工作負載，GKE 或附 load balancer 的 Compute Engine 通常更合適——Cloud Run 的最佳化是針對短而爆發的請求模式。

Q7：如何讓 Cloud Run service 不對外公開？

A7：部署時加 --no-allow-unauthenticated（並從 roles/run.invoker 移除 allUsers），再把 --ingress 設為 internal-and-cloud-load-balancing，讓 *.run.app URL 無法從公網直接打到。之後存取必須是經 roles/run.invoker 認證的請求，或路由經內部或外部 load balancer 並掛 IAP。