Google PCD: 運算、容器與 Serverless 執行階段平台 — 學習指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

屬於 Google Professional Cloud Developer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Google Cloud 提供多種執行階段平台，橫跨無伺服器、容器和虛擬機器。選擇合適的平台取決於工作負載的特性，例如請求模式、狀態管理、建置與發布紀律、維運模型以及網路限制。本節將涵蓋 Cloud Run、App Engine、Cloud Functions、Google Kubernetes Engine (GKE) 和 Compute Engine 的設計原則、故障模式和權衡取捨，以及用於映像檔、身分識別、網路、組態和維運的支援服務。

無伺服器執行階段：Cloud Run、App Engine、Cloud Functions

Cloud Run

模型：全代管容器，可處理 HTTP 請求，或執行容器化的 Job 直到完成。
修訂版本與流量：每次部署都會建立一個不可變的修訂版本。透過百分比將流量分割到不同修訂版本，可實現金絲雀和藍綠部署模式，並能即時復原。範例：

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

並行處理與擴展：預設並行數為 80；對於 CPU 密集型或非執行緒安全的程式碼，請設為 1。較高的並行數可減少冷啟動放大效應和成本，但若每個請求的 CPU/記憶體不足，可能會增加尾部延遲。Cloud Run 會根據傳入的請求率擴展至零或向上擴展；可使用最小/最大執行個體數來控制，以減少冷啟動並限制成本。
CPU 分配：若要在請求之間執行背景工作，請選擇「CPU 始終分配」，但會產生額外費用；否則，CPU 僅在處理請求時分配。
Jobs：Cloud Run Jobs 會平行執行 N 個任務直到完成，可設定每個任務的最大重試次數和整體逾時；適用於 ETL、批次和扇出 (fan-out) 處理。故障模式包括當許多任務指向同一個相依服務時，會造成後端熱點；應加入速率限制和帶有退避機制的重試。
網路：公開、透過 IAM 進行驗證，或透過 Serverless VPC Access 和 Private Service Connect 隱藏在 VPC 後方的私有網路。

App Engine

環境：
- Standard：沙箱化、快速擴展、針對不同語言的固定執行階段；自動擴展下具有低冷啟動延遲；受限制的檔案系統、請求逾時和傳入請求大小限制。對於大型上傳，請使用 Cloud Storage 簽署的 URL。
- Flexible：基於 Docker、具備類似 VM 的能力、自訂執行階段、擴展速度比 Standard 慢、支援背景執行緒和寫入本機磁碟。
服務與版本：一個服務（微服務）可以託管多個版本；可像 Cloud Run 一樣，按百分比將流量路由到不同版本。使用 dispatch.yaml 將特定路徑或主機路由到服務，以實現簡單、集中的路由，無需外部負載平衡器。
擴展：Standard 環境中為手動、基本或自動擴展；Flexible 環境中為基於 VM 數量的擴展。權衡取捨：積極的自動擴展可提高回應速度，但可能增加成本和後端競爭。
常見陷阱：無限制的執行個體擴展若沒有配額，可能會壓垮下游系統；應強制執行配額和斷路器。

Cloud Functions

事件驅動的處理常式：由 HTTP、Pub/Sub、Cloud Storage 或 Eventarc 事件觸發。使用第 2 代以利用 Cloud Run 的執行模型、VPC 出口控制和並行處理能力；第 1 代一次只處理一個請求。
重試與冪等性：背景函式失敗時可以重試；應設計冪等的處理常式並使用去重複鍵，以避免重複處理。HTTP 觸發器不會由平台重試；應在客戶端實作帶有指數退避的重試機制。
執行階段組態：環境變數、Secret Manager 整合，以及每個函式的並行數/最大執行個體數。設定逾時以控制失控的成本。注意大型相依套件會導致長時間的冷啟動；請保持套件精簡。

Google Kubernetes Engine 上的容器

工作負載

Deployments：具有滾動更新的無狀態 Pod。透過 surge/unavailable 限制確保安全地推出更新：

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

StatefulSets：為有狀態服務提供有序、穩定的網路 ID 和持久性磁碟區。
DaemonSets、Jobs、CronJobs：節點層級的代理程式和批次工作負載。

Services 和 Ingress

Service 類型：
- ClusterIP：僅供內部使用。
- NodePort：用於簡單的外部存取（維運上有限制）。
- LoadBalancer：用於區域性的外部/內部負載平衡。
Ingress：HTTP(S) 路由和 TLS 終止；對於 L7 政策，建議使用 Gateway API 或帶有代管控制器的 Ingress。故障模式：因防火牆導致健康檢查失敗；應允許負載平衡器的 IP 範圍存取後端節點。

自動擴展與節點池

Horizontal Pod Autoscaler (HPA)：根據 CPU、記憶體或自訂指標擴展 Pod；與 Pod Disruption Budgets 結合以保護可用性。
Vertical Pod Autoscaler (VPA)：調整 Pod 的 requests/limits 至合適的大小；避免在同一維度上同時使用 HPA+VPA，以防止回饋循環。
Cluster Autoscaler：新增/移除節點以滿足待處理 Pod 的資源請求。
節點池：按工作負載類別分離節點池。使用 taints/tolerations 和 labels 進行排程。對於對成本敏感且能容忍中斷的工作負載，可混合使用 spot/preemptible 執行個體。選擇具有足夠記憶體頻寬/CPU 的機器類型，以滿足每個 Pod 的限制，避免發生節流。

健康狀態與部署更新

Liveness、readiness 和 startup 探測器可防止流量傳送到未就緒的 Pod，並重新啟動鎖死的容器。過於嚴格的 liveness 探測器可能導致連鎖重啟；應調整初始延遲和失敗閾值。
使用 kubectl rollout undo 進行復原。對於金絲雀部署，可使用多個 Deployments 並透過 Ingress/Gateway 在 Service 層級進行流量分割。

用於應用程式工作負載的 Compute Engine

VM 設計

執行個體範本定義了機器類型、映像檔、磁碟、服務帳戶範圍、啟動指令碼和中繼資料。請保持映像檔的精簡；使用啟動指令碼或由 Packer 預先建置 (baked) 的映像檔，以確保確定性的啟動過程。
磁碟：對於延遲敏感的應用程式，請使用平衡或 SSD 永久磁碟。若要在受控執行個體群組 (managed instance group) 之間共享大型唯讀資料集，可透過將一個唯讀永久磁碟掛載到多個執行個體上，以實現低延遲和快速啟動。
網路：使用負載平衡器時，請為健康狀態檢查器 (health checker) 建立防火牆規則。範例如下：

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

受控執行個體群組 (MIGs)

可根據 CPU、負載平衡器每秒請求數、自訂指標或排程進行自動擴展。設定冷卻時間 (cool-downs) 以防止資源抖動 (thrashing)。
自動修復 (Autohealing) 功能會搭配健康狀態檢查來重新啟動不健康的 VM；請確保健康狀態檢查的路徑是測試應用程式的就緒狀態 (readiness)，而不僅僅是連接埠的可達性 (reachability)，以避免對外提供 500 錯誤。
滾動式更新與藍綠部署：建立一個新的執行個體範本，並對一部分執行個體開始進行金絲雀更新 (canary update)。如果錯誤率上升，就回復到先前的範本。執行時間檢查 (Uptime checks) 和基於 SLO 的警示能快速偵測到服務品質的下降。

記錄與監控

安裝代理程式 (agent) 來收集應用程式日誌，無需修改程式碼；將日誌傳送到 Cloud Logging，並透過 Cloud Monitoring 發出警示。使用 Debug Logpoints 進行線上即時診斷，並將服務中斷降至最低。

建置、身分、網路、密鑰與維運

Artifact Registry 與映像檔

使用 Artifact Registry 來存放容器映像檔與語言套件。啟用漏洞掃描與來源證明生成。保持映像檔小巧：
- 使用多階段建置來分離建置與執行階段。
- 最終映像檔中避免包含開發工具；鎖定作業系統與套件版本。範例：

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

升版：使用不可變的標籤（例如 app:1.3.7, app:prod-20240901）來標記映像檔，並透過在 Artifact Registry 中重新標記來進行升版；避免在生產環境中使用可變的 latest 標籤。根據整合與金絲雀測試的結果來決定是否放行升版。

執行階段身分與最小權限

為每個工作負載指派一個專屬的服務帳號，並授予所需的最小 IAM 角色。避免使用如 Editor 這類範圍過廣的角色。在 GKE 中，透過 Workload Identity 將 Kubernetes ServiceAccounts 對應到 Google 服務帳號。對於無伺服器服務，明確設定執行階段的服務帳號，並移除預設的 token 範圍。

VPC 連接器與服務網路

Serverless VPC Access 連接器可將來自 Cloud Run、Cloud Functions 和 App Engine 的出口流量路由到 VPC。選擇出口流量模式：
- 僅限私有範圍：用以存取 RFC1918 位址與 VPC 連線的服務，而公開的出口流量則直接連出。
- 所有流量：透過連接器加上 Cloud NAT，以獲得固定的出口 IP 並實施限制性的對外政策。
私有依賴：對於 Cloud SQL 優先使用 Private IP，對於 Google API 或合作夥伴服務則使用 Private Service Connect。確保連接器與服務在同一區域且大小足以應付吞吐量；監控連接器的 CPU 以避免流量被節流。

設定、密鑰與健康檢查

使用環境變數來設定非密鑰的組態。將密鑰儲存在 Secret Manager 中，並在執行階段掛載或注入；定期輪替金鑰。在 GKE 中，使用 Secrets 與 Secret Manager 的 CSI 驅動程式。在 App Engine 和 Cloud Run 中，授予服務帳號存取特定密鑰的權限。
健康檢查：
- Cloud Run：執行個體崩潰時會自動重啟；使用請求層級的檢查與延遲 SLI。
- App Engine：內建健康檢查；可為 Flexible 環境自訂 liveness/readiness 檢查。
- GKE：設定 liveness/readiness/startup 探測。
- 負載平衡器後的 Compute Engine：使用 HTTP(S) 健康檢查，並指向應用程式專屬的端點。

故障排除、回滾與發布模式

在 Cloud Run 和 App Engine 上使用流量分割來實現藍綠部署與金絲雀發布；在 GKE 中，使用平行的 Deployments 或漸進式交付控制器；在 MIGs 中，使用執行個體的金絲雀子集。務必根據 SLO 錯誤預算與延遲來定義中止標準。
常見的失敗模式：
- 從零擴展或大規模推出後出現的「驚群效應」；可透過設定最小執行個體數、暖機與速率限制來緩解。
- 超出後端配額或連線限制；應用指數退避與斷路器模式。
- 因映像檔過大或依賴過多造成的冷啟動；可透過精簡映像檔與預先初始化客戶端來改善。

實務問題情境

Acme 零售公司計畫將一個調整圖片大小的 API，從自行管理的 VM 遷移到一個具備可擴展性、成本效益、低延遲回應、能私下存取區域性 Cloud Storage 儲存桶，並能安全進行金絲雀發布的平台。

方法

將服務打包成一個小巧的容器映像檔，並發布到 Artifact Registry。

理由：一個精簡、多階段的 Docker 建置可以最小化冷啟動時間與網路傳輸。Artifact Registry 則集中管理掃描與升版流程。

將 API 部署到 Cloud Run，設定最小執行個體數為 2，並行處理數為 40，並停用 CPU 始終分配。

理由：Cloud Run 提供即時的水平擴展與受託管的 HTTPS。一個小的最小執行個體池可減少每日流量高峰時的冷啟動延遲。40 的並行處理數能在成本與 I/O 密集型的圖片轉換的長尾延遲之間取得平衡。停用 CPU 始終分配可避免為請求之間的閒置運算付費。

建立一個 Serverless VPC Access 連接器，並將出口流量設為僅限私有範圍；在子網路中啟用 Private Google Access，並在需要時為 Cloud Storage 設定 VPC-SC 或 Private Service Connect 端點。

理由：此 API 必須在沒有公開出口流量的情況下私下讀取和寫入圖片。僅限私有範圍模式確保只有 VPC 流量通過連接器，讓公開呼叫保持直接且高效。Private Google Access 或 Private Service Connect 則提供從 VPC 私下存取 Google API 的能力。

授予一個專屬的執行階段服務帳號對目標 Cloud Storage 儲存桶與所需密鑰的最小權限存取。

理由：最小權限原則限制了爆炸半徑。執行階段身分在特定的儲存桶上獲得 storage.objectViewer 和 storage.objectAdmin 權限，並對所需的 Secret Manager 密鑰獲得存取者 (accessor) 權限。

將 API 金鑰與各環境的設定分別儲存在 Secret Manager 和環境變數中；在執行階段注入密鑰。

理由：集中式的密鑰輪替與可稽核的存取。透過環境變數設定非密鑰組態，符合十二因子應用程式 (12-factor) 的實踐。

實作指數退避與冪等寫入，以處理來自 Cloud Storage 的 429/5xx 錯誤。

理由：在流量突增或區域性事件期間，可能會發生暫時性錯誤。帶有抖動 (jitter) 的退避機制可以保護 API 和 Cloud Storage 免於重試風暴。

設定一個金絲雀修訂版本，並將 10% 的流量分割給它；監控錯誤率、P95 延遲與飽和度。

理由：Cloud Run 上的流量分割功能可實現安全的漸進式推出。基於 SLO 的監控器可在錯誤預算消耗過快時提供自動回滾的觸發器。

新增一個會測試下游依賴項的 HTTP 健康端點；在 Cloud Monitoring 的正常執行時間檢查與基於日誌的指標上設定警示。

理由：端到端的健康狀況能及早偵測到依賴項的故障。正常執行時間檢查提供外部視角；基於日誌的指標則能捕捉應用程式特定的失敗模式。

建立自動擴展的限制與預算；設定最大執行個體數以限制支出，並定義處理超載時的 429 行為。

理由：限制擴展規模可防止失控的成本與後端資源耗盡。優雅的超載行為能維持服務的穩定性。

將回滾步驟文件化：用一個指令將 100% 的流量切換回前一個 Cloud Run 修訂版本。

理由：不可變的修訂版本讓回滾既安全又快速，從而最小化平均恢復時間 (MTTR)。

← 雲端原生應用程式架構與服務選擇 · 所有領域 · API 設計、整合與事件驅動開發 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

通過考試 →

瀏覽 Google →