Google PCNE: VPC 架構、子網路與位址規劃 — 學習指南
屬於 Google Professional Cloud Network Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.
路由：隱含路由、自訂路由、優先順序、標籤與下一躍點 (next hops)
隱含（系統產生）路由
- 子網路路由：每個主要子網路和每個次要範圍各一個，目的地等於 CIDR，下一躍點是子網路本身。
- 預設路由：預設會建立一條 0.0.0.0/0 到預設網際網路閘道的路由；連到網際網路的輸出流量需要外部 IP 或 NAT。
自訂路由與選擇邏輯
- 最長前綴匹配者獲勝。如果多個路由有相同的前綴長度，則優先順序數字最低者獲勝（預設優先順序為 1000）。
- 標籤與服務帳戶
- 沒有標籤的路由適用於所有 VM。有標籤範圍的路由僅適用於具有相符網路標籤的執行個體。
- 基於身分識別的防火牆規則可以匹配服務帳戶；在可能的情況下，使用它們來進行比標籤更精細的控制。
下一躍點 (Next hops)
- 自訂路由支援的下一躍點包括：
- 預設網際網路閘道（0.0.0.0/0 或更具體的輸出前綴）
- 執行個體（需要啟用 IP 轉送來為其他執行個體路由流量；用於虛擬應用裝置）
- Cloud VPN 通道（靜態路由）
- 區域性內部負載平衡器作為下一躍點（用於可擴展的應用裝置模式）
- 您無法將下一躍點設定為 VPC 對等互連連線；對等互連會自行處理路由交換。
- 自訂路由支援的下一躍點包括：
流量導向範例（虛擬應用裝置）
- 建立一個比子網路路由更具體的路由，其下一躍點指向一個已啟用 IP 轉送的執行個體，範圍由來源 VM 上的標籤界定。
範例：
undefined
- 無需外部 IP 即可輸出流量至 Google API
- 選項 1：在子網路上啟用 Private Google Access (PGA)，然後為 Google API VIP 新增自訂路由，指向預設網際網路閘道，以便在必要時繞過第三方的預設輸出路徑。
- 選項 2：使用 Cloud NAT 搭配 PGA，為私有 VM 提供輸出至 Google 服務的流量路徑。
- 選項 3：使用 Private Service Connect 連接 Google API，實現無網際網路的存取；流量會保留在 Google 的網路上，並在您的 VPC 中使用一個私有的 RFC1918 端點。
- 若要進行受限存取，請將用戶端指向受限的 Google API VIP，並強制執行輸出控制。
Shared VPC、對等互連 (peering)、委派管理與服務帳戶
Shared VPC
- 宿主專案 (Host project) 擁有一或多個集中管理的 VPC 和子網路。服務專案 (Service project) 將工作負載附加到選定的共用子網路上。
- 委派管理
- Shared VPC 管理員設定附加項目和子網路共用。
- 網路管理員在宿主專案中管理路由、子網路和防火牆。
- 服務專案中的專案層級 IAM 控制工作負載的部署；您可以只共用必要的子網路，以限制爆炸半徑和路由可見性。
- 服務帳戶
- 偏好使用基於服務帳戶的防火牆政策，以實現跨團隊、確定性、由身分驅動的控制。
- 為每個層級和環境使用專用的服務帳戶，並為資料存取指派最低權限的角色（例如，將 Storage Object Viewer 角色授予讀取 Cloud Storage 的服務帳戶）。
VPC Network Peering
- 限制
- 非遞移性：A↔B 和 B↔C 並不代表 A↔C。如果需要，請建立一個全網狀 (full mesh) 的拓撲。
- 對等互連的網路之間 IP 範圍不能重疊。
- 路由交換僅限於子網路路由（包括次要範圍）；不支援透過對等互連進行下一躍點的導向。
- 當不同的 VPC 必須在管理上保持獨立時，可使用對等互連來實現低延遲、私有、組織內部的連線，且營運開銷極小。
- 限制
混合式連線
- 在 Shared VPC 宿主專案中集中管理 Dedicated Interconnect 和 Cloud Router，以便與各部門的服務專案共用高容量的連線。
- 使用 HA VLAN 附件、多樣化的邊緣位置、雙 Cloud Router 和全域動態路由，以確保彈性並將路由傳播到所有需要的地區。
營運：擴充、HA、私密存取、驗證與疑難排解
子網路擴充與遷移限制
- 當子網路接近容量上限時，進行原地擴充；驗證所有連接的網路以確保沒有重疊，並確保相依的 GKE 次要範圍仍然足夠。
- 如果 IP 範圍與跨組織或合作夥伴的範圍重疊，請採用 NAT 或分階段重新編號。您無法對等互連重疊的 VPC，也無法安裝重疊的動態路由。
區域性部署與高可用性
- 將子網路放置在最接近使用者和資料的區域。對於橫跨大西洋的使用者群，一個在 us-east1 和 europe-west1 擁有區域性子網路的單一 VPC，可提供直接的私密連線，並達到最佳延遲，且 VPC 內部無出口費用。
- 將工作負載分散到不同可用區；使用區域級受控執行個體群組和區域級內部/外部負載平衡器，以實現可用區容錯能力。
- 對於混合雲，每個區域或邊緣位置部署雙 Cloud Router 與附件；在支援的情況下啟用 BFD；使用全域動態路由進行容錯移轉。
Private Google Access 與受限制的端點
- 在託管沒有外部 IP 的執行個體的子網路上啟用 PGA。
- 為防止一般的網際網路出口流量，同時允許存取 Google API：
- 將預設流量路由到您的 NGFW。
- 為 Google API VIPs 新增更明確的靜態路由到預設網際網路閘道，或部署 PSC 端點到 Google API。
範例：
undefined
- 拓撲驗證與疑難排解
- 使用 Network Intelligence Center：
- 使用 Connectivity Tests 驗證可達性，並模擬路由、防火牆和閘道決策。
- 使用 Performance Dashboard 和 Topology 將路徑與健康狀態視覺化。
- 紀錄與遙測：
- 使用 VPC Flow Logs 觀察每個介面的允許/拒絕以及延遲。
- 使用 Firewall Rules Logging 確認規則匹配。
- 針對沒有外部 IP 的出口流量問題，查看 Cloud NAT 紀錄與健康狀態。
- 針對後端整備度，查看負載平衡器與健康檢查紀錄。
- CLI 檢查：
- 使用
- 使用 Network Intelligence Center：
undefined
和
undefined
確認有效政策。 - 從測試 VM 執行
undefined
和
undefined
；需要時使用封包鏡像進行深度檢測。
實務問題情境
Acme 零售集團需要一個多區域、低延遲的 Google Cloud 網路，具備集中式控管、讓私密執行個體無需透過網際網路即可存取 Google API，並在不需要通訊的部門之間實現嚴格隔離。有些團隊執行 GKE 且有高 Pod 密度。Acme 也將一般出口流量導向第三方防火牆，但希望 Google API 流量避開該防火牆。
- 在一個主機專案中，以自訂模式建立一個單一的 Shared VPC，並啟用全域動態路由，然後在 us-east1 和 europe-west1 中建立區域性子網路，並為 GKE 保留次要範圍。
- 理由：單一 VPC 使用 RFC1918 位址提供私密、零成本、跨區域的連線，以達到最佳效率。自訂模式和全域動態路由支援精確的 IP 規劃和多區域路由傳播。
- 只將每個部門的服務專案所需的特定子網路分享給它們；建立三個服務專案（Sales、Finance、Marketing），並只將必要的子網路暴露給每個專案。
- 理由：依子網路分享可限制爆炸半徑與路由暴露，強制執行隔離，同時實現集中式營運。委派的 IAM 讓中央網路管理員管理防火牆和路由，而應用程式團隊可以獨立部署工作負載。
- 對於必須通訊的部門，對等互連其專屬的 VPC 或將它們放在同一個 Shared VPC 子網路中；對於需要隔離的部門，則不進行對等互連，也不分享重疊的子網路。
- 理由：對等互連以最少的營運開銷提供低延遲的私密連線。非傳遞性要求僅在需要的地方建立明確的網狀連線，這在預設情況下保留了隔離性。
- 在所有共享子網路上啟用 Private Google Access，並部署 Private Service Connect 端點到 Google API；保留指向第三方防火牆的預設路由，並為 Google API VIPs 新增更明確的靜態路由到預設網際網路閘道。
- 理由：PGA 和 PSC 讓私密 VM 無需透過網際網路即可使用 API。更明確的路由確保 API 流量繞過 NGFW，而非 Google 的網際網路出口流量則繼續通過檢測路徑。
- 分配具有成長空間的主要和次要 CIDR：對於 GKE，在每個繁忙的區域規劃一個 Pod 次要範圍（例如 /17）和一個 Services 次要範圍（/21）；為 Pod 和 Service 使用別名 IP，並建立綁定到這些範圍的 VPC 原生叢集。
- 理由：次要範圍和別名 IP 可防止節點 IP 耗盡並允許高密度排程。為未來需求規劃規模可避免破壞性的規模調整和次要範圍重新編號。
- 為混合雲與應用裝置流量實作 HA：視需要部署雙 Cloud Router 和 HA VPN 或 Interconnect；當需要將流量導向虛擬應用裝置時，使用一個更明確的自訂路由，其下一個躍點設為區域級內部負載平衡器或已啟用 IP 轉送的執行個體，並依標籤限定適用範圍。
- 理由：在邊緣實現 HA 可確保故障期間的連續性。依標籤限定路由範圍可避免意外的流量髮夾彎 (hairpinning)，並只讓選定的執行個體走應用裝置路徑。
- 使用 Network Intelligence Center Connectivity Tests、VPC Flow Logs 和 Firewall Rules Logging 進行驗證與營運；使用服務帳戶強制執行基於身分識別的防火牆政策，並維護 IPAM 紀錄，為每個區域和功能保留緩衝區。
- 理由：主動驗證可防止變更期間發生中斷。基於身分識別的政策比僅基於標籤的方法更穩固。嚴謹的 IPAM 紀律可防止因 IP 重疊而阻礙對等互連或抑制學習到的路由。
所有領域 · 防火牆政策、Cloud Armor 與網路安全 →
練習這些題目 → · 在 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.
通過考試 →