Google ACE: VPC 網路、連線能力與流量管理 — 學習指南
屬於 Google Associate Cloud Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.
總覽
Google Cloud 上的 Virtual Private Cloud (VPC) 網路提供軟體定義的全球性網路基元，可精細控制定址、路由、安全性和流量管理。本節重點介紹實用的設計和維運主題，您將用來建構具備彈性、安全且可觀測的網路，以互連 Google Cloud 服務、地端環境和公用網際網路。
VPC 核心架構與 IP 規劃
VPC 網路與子網路
- VPC 是一種全球性資源；其子網路 (subnet) 是區域性的，且可橫跨可用區 (zone)。該區域內任何可用區的執行個體 (instance) 都可以使用同一個子網路。
- 生產環境請使用自訂模式 (custom mode) 的 VPC。自動模式 (auto mode) 會在每個區域預先建立一個子網路，使用一組預先定義的 CIDR 範圍，這可能導致 IP 重疊的限制、浪費位址空間，以及在擴展時重構的痛苦。
- 子網路上的次要 IP 範圍 (secondary IP range) 可用於 GKE Pod/Service IP 和 VM 的別名 IP (alias IP)。請預先規劃主要和次要 CIDR，以避免日後需要重新編號。
IP 位址規劃
- 為所有目前和未來可能連接的 VPC 及地端網路，選擇不重疊的 RFC1918 位址空間。為未來的區域和服務預留成長用的區塊。
- 為子網路規劃適當的大小（例如 /24 到 /20）以因應成長，並避免使用過大的範圍，以免增加 ACL 和診斷的複雜性。
- 記錄 IP 使用情況：主要範圍用於工作負載，次要範圍用於 GKE，以及為 NAT 集區或服務端點預留的區塊。
範例
undefined
undefined
路由、防火牆與政策階層
路由與動態路由模式
- 每個 VPC 都有一個路由表，由系統產生的子網路路由、預設路由以及自訂的靜態或動態路由組成。
- 動態路由模式：
- 區域性 (Regional)：透過 Cloud Router 學習到的動態 (BGP) 路由，僅供同一區域內的資源使用。
- 全球性 (Global)：動態路由可供 VPC 中所有區域的資源使用。對於需要從多個區域連回地端的混合雲網路，建議優先選擇全球模式。
- 下一個躍點 (Next hop)：預設網際網路閘道 (0.0.0.0/0)、VPN 通道、Cloud Router (BGP)、執行個體 (路由設備)，或用於虛擬設備的內部負載平衡器。
- 路由優先級：數字越小，優先級越高。設定錯誤的優先級可能會造成流量黑洞，或將其洩漏到非預期的下一個躍點。使用明確的慣例（例如，1000 用於預設出口，900 用於更具體的路由）。
防火牆階層
- VPC 防火牆規則是狀態性的 (stateful)，並在封包轉送前進行評估。它們存在於 VPC 層級，並適用於所有子網路。
- 階層式防火牆政策 (附加於組織、資料夾或專案) 會在 VPC 規則之前強制執行允許/拒絕。使用它們來實作中央防護機制（例如，拒絕暴露於網際網路的管理埠）。
- 隱含規則：在最低優先級存在一條隱含的允許出口 (egress) 和一條隱含的拒絕入口 (ingress) 規則；它們無法被移除。所有連線都需要明確的入口允許規則。
防火牆規則、標籤、服務帳號、安全標籤
- 目標設定：使用網路標籤 (network tag) 或服務帳號 (service account) 將規則應用於特定的 VM；以服務帳號為目標可提供更嚴格的基於身份的控制。
- 安全標籤 (Secure tag) 提供集中管理、受 IAM 保護的標籤，用於政策目標設定；它們能防止工作負載自行附加標籤，並支援零信任分割 (zero-trust segmentation)。
- 日誌記錄：針對高價值的規則選擇性地啟用防火牆日誌，以在可見性與成本之間取得平衡；僅取樣封包，而非完整酬載 (payload)。
- 常見的失敗模式：缺少健康檢查的來源範圍、非對稱路由導致回應封包被丟棄、過於寬鬆的來源範圍造成非預期的曝險。
範例
undefined
負載平衡、IP、DNS 與流量管理
Cloud Load Balancing 類型與行為
- 全域代理型 (Global proxy-based)：External HTTP(S)、External TCP Proxy、External SSL Proxy。在 Google 的邊緣終止用戶端連線，支援 anycast 全域 VIP，並插入標頭 (例如 X-Forwarded-For)。原始用戶端 IP 可透過標頭或 PROXY protocol (適用於 TCP) 取得，而非保留為 L3 來源。
- 區域穿透型 (Regional passthrough)：External Network Load Balancer 和 Internal TCP/UDP Load Balancer 在 L4 路由流量並保留用戶端 IP。當您需要在後端看到來源 IP 且不使用 PROXY protocol 時，請使用此類型。
- Internal HTTP(S) Load Balancer：適用於內部服務的區域性 L7 代理，提供進階路由和 mTLS 選項。
後端服務、健康狀態檢查與流量政策
- 後端服務 (Backend services) 定義後端 (執行個體群組、NEG/VM/Endpoint、GKE 服務)、平衡模式 (UTILIZATION 或 RATE)、容量限制、工作階段親和性 (session affinity) 和連線排空 (connection draining)。
- 健康狀態檢查 (Health checks) 必須允許來自 Google 健康狀態檢查程式的流量通過防火牆。不健康的後端會被自動移除；設定錯誤的健康狀態檢查可能導致服務完全中斷。
- 流量政策 (Traffic policies) 包括位置偏好 (區域/可用區)、溢流 (overflow) 和容錯移轉 (failover) 後端，以及在某些 LB 類型上用於漸進式部署的加權流量分割。
外部與內部 IP、轉送規則
- 外部和內部 IP 位址可以是臨時的 (ephemeral) 或保留的靜態 (static) 位址。全域靜態外部位址由全域 LB 使用；大多數其他位址是區域性的。
- 轉送規則 (Forwarding rules) 將一個 IP:port 對應到一個目標 (例如 targetHttpProxy 或 backend service)。選擇全域或區域規則以匹配 LB 類型；不匹配會導致建立失敗。
Cloud DNS
- 區域 (Zones)：公開區域 (public zones) 在公開網際網路上解析；私有區域 (private zones) 僅能從授權的 VPC 內解析。使用代管記錄 (A/AAAA、CNAME、TXT、MX、SRV 等)。
- 分割水平 (Split-horizon)：為同一個網域建立公開和私有區域，以便內部解析器收到私有答案 (例如 ILB IP)，而公開使用者則獲得面向網際網路的 IP。
- 私有 DNS 轉送：使用 Cloud DNS 政策進行輸入和輸出轉送，以與地端解析器整合；在 VPC 之間使用 DNS peering 來共享私有區域，而無需完整的對等互連連線。
範例
undefined
混合與私有連線
Cloud Router、Cloud NAT 與 Private Google Access
- Cloud Router 透過 BGP 與地端交換路由、通告 VPC 子網路，並匯入地端前綴。當多個區域需要地端連線能力時，請使用全域動態路由。
- Cloud NAT 為沒有外部 IP 的私有 VM 和 GKE 節點提供網際網路出口。規劃 NAT IP 集區的大小以避免連接埠耗盡；監控日誌中是否有被捨棄的連線，並相應地擴展 IP 位址。
- Private Google Access (PGA) 讓私有 VM 可以透過預設路由路徑，在沒有外部 IP 的情況下存取 Google API。用於 Google API 的 Private Service Connect (PSC) 在您的 VPC 中提供具有政策控制的私有 IP 端點，並完全避免公開出口；若要進行更嚴格的出口控制和一致的 DNS，請優先選用 PSC 端點。
Private Service Connect (生產者與消費者服務)
- 在生產者專案 (producer project) 中，透過服務附件 (service attachment) 公開內部服務，並在消費者專案 (consumer project) 中透過私有端點 (private endpoints) 使用。透過 DNS 對應和明確的允許政策來控制存取。與 VPC Peering 相比，這改善了隔離性並集中化了服務發布。
VPC Network Peering、Shared VPC 與網路分段
- VPC Peering 提供 VPC 之間的低延遲私有連線。它不具備可轉移性 (non-transitive)，且不允許重疊的 IP。可選的自訂路由匯入/匯出擴展了連線範圍，但仍不會建立可轉移的路由；請謹慎規劃 hub-and-spoke 架構。
- Shared VPC 將子網路集中在一個宿主專案 (host project) 中，供服務專案 (service projects) 使用。這使得集中式路由、防火牆、NAT 和 LB 成為可能，同時將每個應用程式的 IAM 權限委派出去。結合階層式防火牆和安全標籤 (secure tags) 進行網路分段。
- Network Connectivity Center (NCC) 提供一個中心 (hub) 來協調輻射點 (spokes) (VPN、Interconnect、路由器設備、VPC spokes)，並一致地管理企業 WAN 拓撲。
Cloud VPN、Cloud Interconnect 與 BGP
- Cloud VPN：使用具有動態路由 (BGP) 的 HA VPN 以實現高可用性和自動路由容錯移轉。盡可能為每個對等點 (peer) 建立兩個通道，並將它們建置在獨立的 Cloud VPN 介面和不同的地端設備/鏈路上。
- Cloud Interconnect：Dedicated Interconnect 提供私有的 10–100 Gbps 鏈路；Partner Interconnect 則使用服務供應商。為了彈性，請在不同的邊緣可用性網域 (edge availability domains) 中部署備援的 interconnect，並在支援的情況下將 BFD 與 BGP 搭配使用。
- 故障網域 (Failure domains)：按區域、可用區、設備和供應商進行隔離。定期測試容錯移轉；非對稱路徑可能會破壞地端的狀態式防火牆。
範例
undefined
undefined
undefined
可觀測性與故障排除
- 連線能力測試
- 模擬並驗證來源與目的地之間的連線能力，無論是跨 VPC、地端 (透過混合式連結) 或負載平衡器。此工具會評估路由、防火牆規則和設定，以便在生產環境變更前，找出流量丟失或路由錯誤之處。
- 範例：
undefined
VPC 流量日誌
- 在子網路層級啟用，以即時洞察 5-tuple 流量、位元組、丟包和延遲。可匯出至 Cloud Logging、Pub/Sub 或 BigQuery 進行分析。調整取樣和中繼資料層級以控制成本。
- 使用案例：驗證防火牆有效性、偵測資料外洩、容量規劃及 SLO 監控。
封包鏡像
- 將 VM 或 GKE 的流量鏡像到收集器端點，以進行深度封包檢測 (DPI) 或入侵偵測系統 (IDS)。可按子網路、標籤或執行個體來界定鏡像範圍。需了解其效能開銷，並確保收集器能處理鏡像過來的流量。當您需要原始標頭時，應避免鏡像 NAT 轉換後的流量。
常見的診斷模式
- 黑洞 (Blackhole)：路由存在，但回覆路徑被防火牆或非對稱路由阻擋；使用連線能力測試和雙邊的流量日誌進行驗證。
- 健康檢查失敗：確認防火牆允許來自健康檢查來源的流量，且後端在正確的連接埠上監聽；可從同一子網路中的 VM 進行本機測試。
- NAT 耗盡：尋找原因為「無可用 NAT 連接埠」而被拒絕的流量；增加更多 NAT IP 或減少每個 VM 的連接埠上限。
實務問題情境
Acme Retail 經營一個多區域的電子商務平台，包含私有後端、公開的網站入口，以及地端的 ERP 系統。他們必須分割工作負載、提供對 Google API 的私有出口、啟用所有區域的混合式連線能力，並在維持可觀測性的同時強化安全性。
- 建立一個自訂模式的 Shared VPC 以進行集中控制
undefined
- 理由：自訂模式可避免自動指派的 CIDR，並能進行審慎的 IP 規劃。Shared VPC 將路由、防火牆和 NAT 集中在一個宿主專案中，同時讓服務專案能安全地進行部署。
- 規劃並建立帶有 GKE 次要範圍的子網路
undefined
- 理由：不重疊的主要和次要範圍可防止未來的對等互連衝突，並允許 GKE 使用別名 IP，而不會造成 IP 耗盡。
- 將 VPC 動態路由設為全域並部署 Cloud Router
undefined
undefined
- 理由：全域模式讓所有區域都能使用透過 BGP 學習到的地端路由，簡化了混合式連線能力和故障轉移。
- 建立 HA VPN 到地端並宣告子網路
- 跨越多個不同的地端設備建立兩個 HA VPN 通道。使用 BGP 交換前綴並啟用平滑的故障轉移。
- 理由：雙通道消除了單點故障；BGP 在維護或中斷期間能快速收斂路由。
- 部署 Cloud NAT 以供私有出口，並部署 PSC 以供 Google API 使用
undefined
- 建立 Private Service Connect 端點給 Google API，並更新私有 DNS，將 API 端點對應到 PSC。
- 理由：NAT 允許在沒有外部 VM IP 的情況下進行網際網路出口；PSC 則將 API 流量保持在私有 IP 上，並受到明確的政策控制，從而消除了公有出口路徑。
- 前端使用全域外部 HTTP(S) 負載平衡器；內部服務透過內部 HTTP(S)
- 建立一個帶有代管憑證和指向 NEG 後端的後端服務的全域外部 HTTP(S) LB。
- 為服務間的流量建立區域性內部 HTTP(S) LB，並在微服務之間使用 mTLS。
- 理由：全域代理 LB 提供 anycast、自動擴展和 CDN；內部 L7 LB 則為東西向流量提供豐富的路由和安全性。
- 實作階層式防火牆政策與工作負載身分識別目標
- 附加一個組織層級的政策，拒絕來自網際網路的管理連接埠；僅允許 LB 健康檢查來源。
- 建立針對服務帳號的 VPC 規則，以實現各層之間的最小權限存取；使用安全標籤進行動態分割。
- 理由：階層式結構可集中強制執行安全防護；以身分識別為基礎的目標設定可抵抗標籤欺騙並簡化自動化。
- 設定具有分割水平 (split-horizon) 和轉送功能的 Cloud DNS
- 建立公開區域 acme.com 給網站 VIP，以及私有區域 acme.com 給對應到 ILB 的內部服務名稱。
- 設定對地端 DNS 的出站轉送，以及讓地端能解析私有區域的入站轉送。
- 理由：分割水平可防止資料洩漏，並確保根據來源網路進行正確的名稱解析；轉送功能則整合了舊有的命名空間。
- 使用連線能力測試、流量日誌和封包鏡像來提升可視性
- 為關鍵路徑（使用者到網站 LB、網站到內部服務、服務到地端 ERP）建立測試。
- 在子網路上啟用流量日誌；匯出到 BigQuery 進行趨勢分析。在事件應對期間暫時啟用封包鏡像。
- 理由：主動驗證和遙測數據可縮短 MTTR、揭露設定錯誤，並提供容量洞察。
- 文件化並測試故障情境
- 模擬 VPN 通道、一個區域和一個後端 MIG 的遺失。驗證 BGP 故障轉移、LB 健康檢查移除和 DNS 的正確性。
- 理由：定期的實戰演練可確認對備援的假設，並在設定飄移造成中斷之前將其暴露出來。
← 容器、應用程式託管與無伺服器平台 · 所有領域 · 儲存、資料庫與資料服務 →
練習這些題目 → · 在 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.
通過考試 →