Google PCNE: GKE、容器與應用程式網路 — 學習指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

總覽

Google Kubernetes Engine (GKE) 與 Google Cloud 網路緊密整合。要設計出兼具可靠性與安全性的架構，需要了解 VPC-native IP 位址、私有控制平面、egress (輸出流量)、north–south (南北向) 與 east–west (東西向) 流量、政策強制執行以及多叢集架構。本節提供在 Google Cloud 上針對容器與應用程式網路的設計指南、維運考量以及常見的故障模式。

GKE IP 架構與私有叢集

VPC-native 叢集

使用 VPC 子網路中的別名 IP (alias IP) 搭配兩個次要範圍：一個給 Pods (PodCIDR)，另一個給 Services (ServiceCIDR)。這可以避免在節點上使用基於 iptables 的 SNAT、透過 NEG 啟用容器原生負載平衡，並且比基於路由的叢集有更好的擴展性。
規模規劃指南：
- Pods：分配 PodsPerNode × MaxNodes，再加上預備空間 (20–30%)。例如，目前 10 個節點 × 20 個 Pod，預計成長到 100 × 200，建議使用 /17 的 Pod 範圍；而 Services 通常使用 /21 的範圍就足以容納 2000 個以上的服務。
- Services：每個 ClusterIP 會消耗一個 IP；需將 headless 服務轉換為 ClusterIP 的遷移以及附加元件的預備空間納入考量。
故障模式：
- Pod IP 耗盡：Pods 會一直處於 Pending 狀態，或出現 CNI/IPAM 錯誤；擴展次要 Pod 範圍或減少每個節點的最大 Pod 數量，然後重新建立節點。
- Service IP 耗盡：新的 Service 無法分配到 ClusterIP；擴展 Service 的次要範圍。
- 別名範圍重疊：叢集建立失敗或發生路由黑洞；驗證沒有與其他子網路或對等 VPC 重疊。

私有叢集、控制平面存取與節點 egress

私有叢集將控制平面端點限制在一個私有的 RFC1918 位址，只能透過 producer peering 從您的 VPC 存取。節點不需要外部 IP。
對於維運人員，可選擇：
- 僅使用私有端點：控制平面可從 VPC 子網路和已連線的網路存取。使用堡壘主機 (bastion) 或搭配 Private Service Connect 的 Cloud Shell 來連線。
- 使用具備授權網路的公開端點：將控制平面暴露在一個公開 IP 上，並由特定的來源 CIDR 進行管制。這很方便但會增加曝險；僅在嚴格的 CIDR 範圍和強大的管理員身份控制下使用。
節點 egress：
- 對於沒有外部 IP 的節點，透過 Cloud NAT 提供連向網際網路的 egress 流量。這允許作業系統更新、從外部 registry 拉取容器映像檔，以及存取合作夥伴的 API，同時保持節點的私有性。
- 若要在沒有外部 IP 的情況下存取 Google API 和 Artifact/Container Registry，請在節點子網路上啟用 Private Google Access (PGA)。PGA 會解析 Google API/registry 的流量並將其路由到 Google 的邊緣網路，而無需使用公開來源 IP。建議使用 PGA 來拉取映像檔；如果也需要非 Google 的 egress 流量，則可與 Cloud NAT 結合使用。
- 如果將 0.0.0.0/0 流量傳送到第三方防火牆，仍應啟用 PGA，並為 Google API 的 VIP 範圍新增靜態路由到預設網際網路閘道，以繞過防火牆來存取 Google 服務。

擴展與 IP 問題排解

在子網路次要範圍的層級監控別名 IP 的消耗情況。如果 IP 使用壓力上升：
- 增加次要範圍的大小 (新增更大的範圍，並在需要時重新建立叢集或遷移工作負載)。
- 調整每個節點的最大 Pod 數 (max-pods-per-node)，以在每個節點的 IP 使用量與排程碎片化之間取得平衡。
- 清理廢棄的 Service；headless Service 不會分配 ClusterIP，但將其轉換為 ClusterIP 會消耗 IP。
規劃多區域成長時，應使用不重疊的次要範圍，以避免在使用 Shared VPC、VPC Peering 或多叢集服務時需要重新分配 IP (re-IP)。

Ingress、Gateway API、Services 與 policies

Services 與負載平衡器

Service 類型：
- ClusterIP：僅限叢集內部存取；東西向流量使用 kube-proxy 或 dataplane v2。
- NodePort：在每個節點上分配一個 port；許多 LB 將其用作後端，但應避免直接暴露於網際網路上。
- LoadBalancer：佈建一個雲端負載平衡器。外部或內部 L4 負載平衡器支援 TCP/UDP；當需要時，session affinity ClientIP 可提供跨多種協定的黏性 (stickiness)。
容器原生負載平衡使用 Network Endpoint Groups (NEGs)，讓負載平衡器直接將 Pod 的 IP:port 作為目標，從而改善健康狀態信號傳遞並減少節點跳轉。對於 GKE，請使用 GKE Pod NEG (GCE_POD)。其他 NEG 類型包括 VM_IP_PORT、Internet FQDN 和 PSC。
GKE Ingress 與 Gateway API：
- 對於 HTTP(S) 南北向流量，Ingress 是一個穩定的選擇，可搭配 Google 的全球外部 HTTP(S) 負載平衡器或區域性內部 HTTP(S) 負載平衡器使用。對於標準模式，控制器會自動設定健康檢查和防火牆規則。
- Gateway API 透過 Gateways 和 HTTPRoutes/TCPRoutes 提供了一個更具表達力的模型。它支援多租戶設定、進階路由，以及跨環境的一致性規範。為了未來擴充性，請選擇 Gateway API；在重視簡單性和相容性的情況下，則使用 Ingress。

用戶端限制與健康檢查

在 L4 層級，可以透過針對後端執行個體的 VPC 防火牆規則來限制特定來源範圍的用戶端；在 L7 層級，則可透過 HTTP(S) 負載平衡器上的 Cloud Armor 政策來達成。
務必允許 Google 健康檢查程式的來源範圍存取後端目標或 Pod，以確保健康檢查能通過。在某些部署中，GKE 會自動建立 k8s-fw 規則；如果您新增了限制性規則，請務必保留對健康檢查程式範圍的明確允許規則。
L4 後端的範例作法：為節點加上 “application” 標籤，並建立一條防火牆規則，允許來自指定用戶端 CIDR 和 Google 健康檢查範圍的流量存取 tcp:NodePort，同時建立一條更高優先權的 deny 規則來拒絕所有其他來源，並啟用日誌記錄以觀察被丟棄的封包。

Network policies 與 dataplane v2

啟用 Kubernetes NetworkPolicy 並使用 GKE Dataplane V2 進行基於 eBPF 的強制執行，與基於 iptables 的引擎相比，可提升效能和擬真度。
基準姿態：
- 對 namespaces 預設拒絕 egress 和 ingress 流量；明確允許 Pod-to-Pod 和 Pod-to-Service 的流量。
- 使用 namespace 和 podSelectors 建立服務層級（例如 frontend、backend、data），並僅允許最小必要方向和 port 的通訊。
保護服務通訊安全：
- 對於叢集內的零信任架構，mTLS 最好透過 service mesh 來實現；NetworkPolicy 處理 L3/L4，但無法驗證身分。
- 對於南北向流量，將 Cloud Armor 附加到 HTTP(S) LB 上，以實現 WAF、速率限制，並使用預覽模式來測試對可疑攻擊者的 deny 規則，而不會影響到正常使用者。

故障模式與權衡取捨

過多或過於寬鬆的 NetworkPolicies 可能導致非預期的封包丟失；應透過分階段推出、日誌記錄和政策解釋工具進行驗證。
依賴 NodePort 加上外部防火牆規則的作法很脆弱；建議優先使用託管式負載平衡器和 Pod NEG。
Gateway API 帶來了更豐富的功能，但需要成熟的控制器和團隊的熟悉度；應根據不同的 release channel 驗證如基於標頭的路由或 mTLS passthrough 等功能。

多叢集、服務網格與身分識別

多叢集服務與 fleet 網路

將叢集註冊到 fleet 中，以使用 Multi-Cluster Services (MCS) 進行跨叢集服務探索與負載平衡。從每個叢集匯出服務；客戶端解析單一 DNS 名稱，其後端為跨叢集的端點。
跨叢集流量模式：
- 相同 VPC，不同子網路：流量透過私有 RFC1918 傳輸，成本與延遲最佳化。
- 不同 VPC：使用 VPC Peering 進行私有、簡單的連線，但不具備可轉移性；若組織不同或需要透過網際網路加密，則使用 Cloud VPN/Cloud Router。若要集中管理，可使用 Shared VPC，僅將需要的子網路暴露給服務專案。
故障模式：
- 重疊的 CIDR 會阻擋路由；在進行 peering 或 VPN 之前，請確保 PodCIDR 和 ServiceCIDR 沒有重疊。
- DNS split-horizon 問題可能破壞跨叢集解析；請驗證搜尋路徑和 stub domains。

服務網格、東西向流量與可觀測性

部署像 Anthos Service Mesh 這類的服務網格以達成：
- mTLS 搭配強式工作負載身分識別、流量政策（重試、逾時、離群偵測）與流量分割。
- 透過網格聯邦 (mesh federation) 或多主體 (multi-primary) 拓撲，在叢集間實現一致的東西向政策。
- 豐富的遙測資料：每個工作負載的黃金指標 (golden signals)、請求追蹤與政策稽核。
權衡取捨：
- Sidecar 會增加資源開銷；ambient 或 sidecarless 模式可以降低成本，但需驗證其功能對等性。
- 網格增加了對控制平面的依賴；設計時應考慮 HA 控制平面與優雅降級 (graceful degradation)。

工作負載身分識別、密鑰與最小權限

使用 Workload Identity 將 Kubernetes Service Accounts (KSAs) 對應到 Google service accounts (GSAs)，以消除長期存在的金鑰。用 GSA 的電子郵件來註解 (annotate) KSA，並授予 GSA 最小的 IAM 角色。
密鑰管理：
- 優先使用 Secret Manager 搭配 CSI 驅動程式，在執行期掛載密鑰；移除用於敏感資料的純文字 Kubernetes Secrets，若要保留，則使用 CMEK 進行靜態加密。
- 在 GSA 層級授予對密鑰和儲存桶的最小權限存取。避免使用專案層級的角色；在適用情況下，將範圍縮小到資源層級的角色，例如 storage.objectViewer。

彈性與安全平台設計考量

使用區域級叢集以達成高可用性；將節點分散到不同可用區。對於南北向流量，使用全球 HTTP(S) 負載平衡，為全球使用者提供最低延遲。
控制平面連線：選擇私有控制平面；除非有嚴格必要，並搭配 Authorized Networks，否則應避免公開暴露。
出口流量 (Egress)：沒有外部 IP 的節點搭配 Cloud NAT 和 PGA，在安全性與功能性之間取得平衡。
可觀測性：啟用防火牆日誌、VPC Flow Logs 和網格遙測，以快速診斷政策丟棄或延遲飆升問題。

實際問題情境

Contoso Retail 在 us-east1 和 europe-west1 營運兩個私有的 GKE 區域級叢集。需求：節點上沒有外部 IP、安全地將入口流量限制在公司 CIDR 內、為店面服務提供全球可用性、在沒有網際網路暴露的情況下拉取映像檔，以及 API 層的跨叢集容錯移轉。他們先前在流量高峰時曾遇到 Pod IP 耗盡的問題。

解決方法

設計 VPC-native 子網路，並提供寬裕的次要範圍。
- 理由：每個區域分配一個 /17 的 Pod 範圍和一個 /21 的服務範圍，以涵蓋 100 個節點 × 每個節點 200 個 Pod，以及 1,500 個服務，並保留 20–30% 的預備空間。這可以防止 Pod IP 耗盡問題再次發生，並避免在成長過程中重新規劃 IP。
建立具有私有控制平面端點的私有叢集。
- 理由：將控制平面的暴露限制在 VPC 內部。操作人員透過位於管理子網路上的跳板機 (bastion) 進行連線。與使用 Authorized Networks 的公開端點相比，這減少了攻擊面。
在節點子網路上啟用 Cloud NAT 和 Private Google Access。
- 理由：節點沒有外部 IP，但仍需要從 Artifact Registry 拉取映像檔並存取作業系統/套件鏡像站。PGA 確保在沒有公開來源 IP 的情況下存取 Google API；Cloud NAT 則處理必要的非 Google 出口流量。
使用 Gateway API 搭配 Pod NEGs 實作全球 HTTP(S) 入口流量。
- 理由：單一的全球 anycast VIP 為全球使用者降低了延遲。GKE Pod NEGs 直接將健康檢查傳送到 Pod，並改善了故障偵測。Gateway API 在基礎設施的 Gateways 和應用程式擁有的 Routes 之間提供了清晰的分離。
限制客戶端存取並允許健康檢查。
- 理由：附加一個 Cloud Armor 政策，只允許公司 CIDR，並設定預設拒絕和預覽模式，以安全地評估新的封鎖規則。此外，確保 VPC 防火牆規則允許 Google 健康檢查來源範圍存取後端 NEGs，以保持健康檢查為綠燈狀態。
使用 GKE Dataplane V2 應用 NetworkPolicy。
- 理由：每個命名空間預設拒絕入口和出口流量；僅允許前端到後端以及後端到資料庫的連接埠。Dataplane V2 使用 eBPF 高效地強制執行政策，縮小了受感染 Pod 的爆炸半徑。
在 fleet 中啟用 Multi-Cluster Services。
- 理由：在兩個區域中匯出 API 服務，並發布一個單一的 DNS。客戶端會自動容錯移轉到跨叢集的健康端點。由於兩個叢集都在同一個 VPC 中，並使用區域性子網路，跨區域流量保持私有，且只產生極小的額外開銷。
採用服務網格以實現東西向流量的安全性與可觀測性。
- 理由：在服務之間強制執行 mTLS，增加重試/逾時預算，並獲取每個路由的指標和追蹤。網格層級的政策與 NetworkPolicy 互補：NetworkPolicy 控制 L3/L4 的可達性；網格則在 L7 驗證和授權服務身分。
強化工作負載身分識別與密鑰。
- 理由：透過 Workload Identity 將 KSA 對應到範圍嚴格限定的 GSA；僅授予必要的角色，例如給報表擷取器授予 storage.objectViewer。透過 Secret Manager CSI 提供憑證，以避免在設定檔 (manifests) 中使用靜態密鑰。
實作容量與日誌記錄的防護機制。
- 理由：審慎設定 max-pods-per-node 以平衡 IP 使用量。監控次要範圍的使用率和 VPC Flow Logs。建立一個明確的高優先級 deny-all 防火牆規則，並在應用程式標籤上啟用日誌記錄，以便在保留允許路徑的同時，突顯出非預期的客戶端流量。