Google ACE: 容器、應用程式託管與無伺服器平台 — 學習指南
屬於 Google Associate Cloud Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.
總覽
Google Cloud 提供了一系列的平台來執行容器和應用程式，從全代管的無伺服器平台到可自行設定的 Kubernetes 叢集。要選擇並操作合適的平台，需要了解其控制平面、擴展模型、發布機制、網路和安全性。本節彙整了 Google Kubernetes Engine (GKE)、Artifact Registry、Cloud Run、App Engine 和 Cloud Functions 的操作指南，以及關於密鑰、安全部署和診斷的實踐模式。
Kubernetes Engine：叢集、工作負載與網路
GKE 叢集提供一個代管的 Kubernetes 控制平面，以及可由您自行調整大小和保護安全的節點池。若要將操作負擔降至最低並採用預設的最佳實踐，請選擇 Autopilot 模式；若要對節點、網路和附加元件進行精細控制，請選擇 Standard 模式。使用發布通道和節點自動升級，以實現可預測且安全的升級；並啟用節點自動修復。除非特定套件需要 Ubuntu，否則優先選擇 Container-Optimized OS 以獲得強化的節點。
節點池與排程
- 根據工作負載類別（例如：通用、GPU、spot）來區分節點池，並使用 taints/tolerations 來引導 Pod 的排程。
- 啟用叢集自動擴展器，並為每個節點池設定最小/最大值。請注意，PodDisruptionBudgets 和資源請求可能會阻擋縮減（scale-in），或在請求超過可用節點規格時導致 Pod 處於待處理（pending）狀態。
- Spot/可搶佔節點可降低成本，但會帶來被驅逐的風險；可結合 Deployment 的 surge 預算和 Pod 拓撲約束以提高彈性。
命名空間與多租戶
- 使用命名空間來分割配額、政策和 RBAC。應用 NetworkPolicies 來限制東西向流量。在命名空間範圍內強制執行 Pod 安全性標準，以避免特權工作負載。
工作負載
- Deployments 管理無狀態的 Pod，提供滾動更新、surge/unavailable 預算和快速回滾。使用 readiness probes 來閘控流量，並使用 liveness/startup probes 來進行自動修復。設定錯誤的 readiness probes 可能會導致流量黑洞；在生產環境部署前請務必測試。
- StatefulSets 為資料庫和基於仲裁（quorum-based）的系統提供穩定的身份和有序的擴展。使用 headless Service 和支援動態配置的 StorageClass；並規劃區域性 PV 的本地性。
- DaemonSets 會在每個節點上排程一個 Pod（例如：日誌/監控代理程式）。它們會遵循自動擴展和節點清空（drain）事件，非常適合用於全節點的遙測。
Services 與 Ingress
- ClusterIP 提供叢集內的 DNS 和負載平衡。NodePort 主要用於故障排除。LoadBalancer 會配置一個 Google Cloud 外部或內部的 TCP/UDP 負載平衡器；對於私有服務，請使用內部負載平衡器。
- GKE Ingress 設定全域 HTTP(S) 負載平衡，並提供代管憑證、URL 映射和 Cloud Armor。為了實現現代化的流量管理，建議優先使用容器原生負載平衡 (NEG)，以進行每個 Pod 的健康檢查並達到更快的收斂速度。請確保 readiness 端點能反映應用程式的真實健康狀況；否則後端會變得不健康，導致 502 錯誤。
自動擴展
- Horizontal Pod Autoscaler 根據 CPU 等指標或透過 Cloud Monitoring 的自訂指標來擴展副本數量；請確保 Metrics Server 運作正常。Vertical Pod Autoscaler 可以為請求找到合適的大小 (right-size)；為避免與 HPA 衝突，對於由 HPA 管理的工作負載，請在「建議」模式下使用 VPA，或謹慎使用 HPA+VPA 相容模式。
- Cluster autoscaler 會新增/移除節點以容納 Pod。如果 Pod 請求的資源超過任何節點規格所能提供，它們將永遠無法被排程；請將請求/限制與節點池的規格對齊。
簡短範例：
回滾有問題的版本：
undefined
快速檢查另一個 context：
undefined
Artifact 管理、供應鏈安全與安全發布
Artifact Registry 按區域託管容器映像檔，並支援 VPC Service Controls。為不同環境採用獨立的 repo (或前綴)，並強制使用不可變的標籤；透過 digest 進行部署以消除歧義。整合 Cloud Build 或您的 CI，以在建置和推送時附上來源元數據 (provenance metadata)。
弱點管理
- 啟用 Artifact Analysis 來掃描映像檔中的作業系統和程式語言 CVE。當發現高嚴重性問題時，中斷建置或阻擋升級。結合 Binary Authorization，要求在准入 GKE 之前必須有簽章/證明（例如：通過弱點政策、SLSA 來源證明）。
映像檔升級
- 透過將映像檔 digest 從開發 repo 複製到預備/生產 repo，或在一個專門的升級 repo 中重新標記來進行升級；避免使用可變的「latest」標籤。使用 Cloud Build 觸發器，根據測試和掃描結果自動化此流程。
密鑰與設定
- 優先使用 Secret Manager 並遵循最小權限原則。在 GKE 上，使用 Secret Manager CSI 驅動程式搭配 Workload Identity，這樣節點就永遠不會接觸到長期的密鑰。對於 KRM 設定，將 ConfigMap (非機密) 與 Secret (敏感) 分開，並以唯讀方式掛載。
- 對於無伺服器平台，透過直接的 Secret Manager 綁定來掛載密鑰；除非絕對必要，否則避免將密鑰嵌入環境變數中。
回滾與發布模式
- Kubernetes：使用滾動更新，設定 maxUnavailable=0 以實現零停機時間，並根據容量調整 maxSurge；使用兩個 Deployment 搭配一個 Service 進行金絲雀部署，或使用 Service mesh 進行漸進式百分比部署。使用 PodDisruptionBudgets 和 minReadySeconds 保護關鍵工作負載。
- Cloud Run 和 App Engine：使用修訂版本/版本和流量分割來進行金絲雀和藍綠部署。保持先前的修訂版本處於暖機狀態，以減少回滾延遲。
- 失敗模式：可變標籤的漂移、掃描時間差以及設定錯誤的 readiness probes 是造成服務中斷的常見原因。應使用映像檔 digest、部署前檢查和綜合健康探測 (synthetic health probes) 來應對。
無伺服器應用程式平台
Cloud Run 提供容器原生、由請求驅動的運算，具備自動擴展至零與依請求強制執行身分識別的功能。
Cloud Run 服務與任務
- 服務 (Services) 處理 HTTP；並行處理 (concurrency) 控制每個執行個體同時處理的請求數量 (可調整以在延遲與效率間取得平衡)。任務 (Jobs) 處理非 HTTP 的批次/cron 工作，且可以平行化執行。
- 修訂版本 (Revisions) 是不可變的快照。流量分割 (Traffic splitting) 可依百分比啟用 Canary 部署。設定最小執行個體 (min instances) 以減少冷啟動；若需要在閒置時執行背景工作，可使用閒置時分配 CPU 的功能。
- 身分識別：為每個服務/修訂版本指派一個具備最低權限的專用服務帳戶。透過 IAM (Cloud Run Invoker 角色) 限制叫用，或在必要時設為公開。對於終端使用者驗證，可使用已簽署的 IAP token 或 Cloud Run 內建的 Identity Platform 驗證機制。
網路
- 使用 Serverless VPC connectors 來存取私有 VPC 資源。選擇出口 (egress) 方式：所有流量都通過 connector，或僅限私有 RFC1918 範圍的流量。注意 connector 的吞吐量配額；擴展 connector 的大小並使其與服務位於相同地區。對於僅有私有 IP 的資源要連到外部網際網路，需搭配 Cloud NAT 使用。
- Private Service Connect 可用來私密地取用生產者服務或暴露內部端點。若要透過外部 HTTP(S) 進行傳入 (ingest)，可使用 Cloud Load Balancing 搭配 serverless NEGs。
App Engine 提供兩種環境：
- 標準環境 (Standard)
- 沙箱化環境，可快速擴展，支援自動、基本或手動擴展。自動擴展搭配 min_idle_instances 可提供預先暖機的容量。冷啟動速度快且部署模型簡單；但作業系統層級的客製化有限，且執行階段環境 (runtime) 為固定選項。
- 彈性環境 (Flexible)
- 在 Compute Engine VM 上執行 Docker，對系統函式庫和網路有更多控制權。執行個體生命週期較慢且基礎成本較高；適合需要自訂執行階段環境或原生函式庫的場景。
- 服務與版本
- 依版本分割流量 (隨機、cookie 或 IP)。每個服務都可以獨立擴展。使用漸進式推出 (gradual rollouts) 並保留前一個版本以便即時回復。
Cloud Functions 提供事件驅動的單一用途函式。
- 觸發條件：Pub/Sub、Cloud Storage、HTTP、以及用於多種來源的 Eventarc。確保處理常式 (handler) 具備冪等性 (idempotent)；某些觸發條件在失敗時會重試，可能導致重複處理。
- 執行階段設定：環境變數、Secret Manager 綁定、最大執行個體數、記憶體/CPU。控制 HTTP 函式的並行處理以平衡延遲和成本。
- 常見陷阱：無限制的並行處理或非冪等性的副作用會導致資料重複；確保為 Pub/Sub 設定 DLQ (Dead-Letter Queue)；設定適當的逾時時間。
平台選擇、網路與維運所有權
根據所需的控制權、擴展特性、可攜性需求以及維運預算來選擇平台。
控制權 vs. 維運開銷
- 最高控制權：GKE Standard (節點作業系統、網路、安全附加元件)，伴隨相應的維運開銷。
- 平衡：GKE Autopilot (無節點管理、預設配置的安全機制)。
- 最低開銷：Cloud Run、App Engine、Cloud Functions (無節點、託管式擴展)，但受限於執行環境與請求模型。
擴展與工作負載適用性
- 流量突增的工作負載：Cloud Run/App Engine Standard 表現出色；Functions 適用於事件驅動的處理程式。
- 有狀態或自訂網路：GKE 搭配 StatefulSets 與 CNI 功能。
- 可攜性：GKE/Cloud Run 上的容器；由於 FaaS 模型，Functions 的可攜性較差。
無伺服器網路、出口流量與私有服務
- 使用 VPC 連接器進行私有存取；監控連接器的使用率以避免流量限制。僅在必要時將出口流量設為「全部」；否則應限制在私有範圍以降低成本與風險。
- 對於私有入口流量，可考慮使用內部 HTTP(S) 負載平衡搭配無伺服器 NEG 或 Private Service Connect。
- 為了控制資料外洩，可搭配支援的 VPC Service Controls，並透過防火牆與 Cloud NAT 限制出口路由。
診斷與維運所有權
- 以 Cloud Logging 搭配結構化日誌 (JSON) 與跨服務的追蹤/span ID 作為標準，以便進行關聯分析。使用 Cloud Monitoring 儀表板、執行時間檢查、SLO 與警示政策。
- 對於 GKE：啟用 Cloud Ops for GKE，透過 Prometheus 或 Cloud Monitoring 抓取應用程式指標，並使用 DaemonSets 進行節點層級的遙測。
- 對於無伺服器：利用內建的請求日誌、Error Reporting、Trace 與 Profiler。針對延遲、錯誤率與飽和度 (並行處理、執行個體 CPU) 設定每個服務的 SLO 與警示。
- 所有權模型：定義誰擁有執行期參數 (擴展、並行處理)、IAM 與發布管道。定期測試回滾與災難情境。
實務問題情境
Acme Retail 計劃在現代化內部服務的同時，推出一個新的結帳 API。需求包括：具備金絲雀部署能力的低延遲公開 API、對 VPC 內部的庫存資料庫進行私有存取、供應鏈強制執行，以及清晰的回滾機制與最小的維運開銷。
- 為公開 API 選擇 Cloud Run，為內部庫存服務選擇 GKE Autopilot。
- 理由：Cloud Run 為無狀態 HTTP 最小化了維運開銷，並支援修訂版本與流量分割；GKE Autopilot 為有狀態/內部服務提供 Kubernetes 功能，且無需管理節點。
- 在 Artifact Registry 中建置、掃描並儲存映像檔，並附上來源證明。
- 理由：Cloud Build 產生容器映像檔；Artifact Analysis 掃描 CVE。儲存摘要與來源證明，讓 Binary Authorization 能夠強制只執行經過掃描與簽署的映像檔。
- 強制執行准入政策。
- 理由：在 GKE 叢集上啟用 Binary Authorization，以要求簽章與政策證明。對於 Cloud Run，設定部署自動化流程，根據弱點掃描政策是否通過來決定是否放行部署。
- 設定 Serverless VPC 連接器與 Cloud NAT 的網路。
- 理由：Cloud Run API 必須能私下連線到庫存服務與 Cloud SQL。VPC 連接器允許私有 RFC1918 出口流量；Cloud NAT 為私有資源提供對外網際網路連線以下載相依套件，而無需外部 IP。將連接器與服務保持在同一區域，並適當調整其吞吐量。
- 保護身分與權限。
- 理由：為 Cloud Run 服務指派一個專用服務帳戶，並遵循最小權限原則 (例如，Cloud SQL Client，以及在需要時，叫用內部端點的權限)。對於 GKE，使用 Workload Identity，讓 Pods 能在沒有節點層級憑證的情況下，擔任服務帳戶的角色。
- 實作安全的發布與回滾。
- 理由：將 API 部署到一個新的 Cloud Run 修訂版本，並分割 5% 的流量進行金絲雀測試。監控延遲、錯誤率與飽和度；然後逐步增加到 100% 或透過將流量還原到先前的修訂版本來立即回滾。在 GKE 中，使用帶有 readiness probe 的 Deployment 滾動更新，並在同一個 Service 後方部署一個小型的金絲雀 Deployment，以便在全面推出前進行驗證。
- 設定可觀測性與 SLO。
- 理由：從兩個平台發送帶有追蹤 ID 的結構化 JSON 日誌到 Cloud Logging。針對 p95 延遲與 5xx 錯誤率建立 SLO；並附加警示政策。使用 Error Reporting 與 Trace 進行根本原因分析。對於 GKE，部署一個 DaemonSet 以收集節點指標，並啟用 Cloud Ops for GKE。
- 驗證故障模式與容量。
- 理由：進行負載測試以驗證 VPC 連接器的吞吐量、Cloud Run 的並行處理能力以及 GKE HPA 的行為。確認 readiness probe 的準確性以防止流量黑洞。測試 binary authorization 的拒絕路徑以及透過摘要進行映像檔回滾，以確保在供應鏈強制執行下的可恢復性。
此方法提供了一個低維運開銷、安全的公開 API、受控的內部服務、私有網路、可強制執行的供應鏈安全，以及快速回滾的能力，完全符合 Google Cloud 的最佳維運實踐。
← Compute Engine 與虛擬機器操作 · 所有領域 · VPC 網路、連線能力與流量管理 →
練習這些題目 → · 在 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.
通過考試 →