Google Kubernetes Engine (GKE) 的網路涵蓋廣泛的概念，包括 Pod、服務、DNS、負載平衡、安全性及 IP 位址管理。雖然文件詳細說明瞭各項功能，但遇到實際問題時，您可能不知道該從何著手。
本文會將常見挑戰連結至可解決這些問題的功能和章節，協助您瀏覽 GKE 網路說明文件。每個應用實例都會呈現情境、指出挑戰，並引導您前往相關說明文件。本文適用於雲端架構師、開發人員和營運團隊，協助他們瞭解及解決 GKE 中常見的網路問題。
如果您已熟悉常見的網路挑戰，並想直接深入瞭解技術細節，請參閱下列資源，建立 GKE 網路的基礎知識：
- 瞭解 GKE 網路基本概念。
- 瞭解 GKE 網路架構。
- GKE 網路術語詞彙表 (快速複習任何不熟悉的術語)。
用途：設計 GKE 的網路基礎
在這個情境中，您是雲端架構師，需要為新的 GKE 平台設計可擴充、安全且可靠的網路基礎。
挑戰：避免 IP 位址耗盡
情境：應用程式的複雜度和用量預計會增加，因此您需要設計可擴充的網路，以處理增加的流量，並支援 Pod、服務和節點的成長。此外，您也需要規劃 IP 位址分配，避免耗盡
解決方法：規劃 IP 位址配置，以因應您需要的節點、Pod 和 Service 數量。這項計畫包括為每個網路選擇適當的 IP 位址範圍、考量 Pod 密度，以及避免與其他網路重疊。詳情請參閱「在 GKE 中管理 IP 位址遷移作業」。
挑戰：強制執行縱深防禦安全措施
情境：您需要保護叢集邊界，並強制執行零信任機制和 Pod 對 Pod 規則。
解決方案：使用防火牆政策設定叢集邊界。詳情請參閱使用網路政策控管 Pod 和服務之間的通訊。
挑戰：將流量轉送至不同類型的應用程式
情境：您需要確保其他服務和使用者可以存取不同類型的應用程式，例如私有後端和公開 HTTP(S) 應用程式。
解決方案：針對私人後端使用內部負載平衡器。如為公開 HTTP(S) 應用程式，請使用 Ingress 或 Gateway API。詳情請參閱關於 GKE 中的負載平衡。
挑戰：使用可觀測性工具監控及排解工作負載問題
情境：您必須修正網路流量問題，並瞭解及監控 GKE 流量，才能有效診斷問題。
解決方案：導入可觀測性工具，監控及排解網路流量問題。詳情請參閱「使用 GKE Dataplane V2 可觀測性功能監控流量」。
用途：公開新的微服務
在這個情境中，您是開發人員，要在 GKE 中部署新的微服務。您需要讓叢集中的其他服務存取微服務，之後也需要讓外部用戶端存取。
挑戰：為 Pod 對 Pod 通訊提供穩定端點
情境：您的應用程式需要 Pod 與其他 Pod 通訊，但 Pod 使用的動態 IP 位址會導致通訊不可靠。
解決方案：建立 Kubernetes 服務。ClusterIP 服務提供穩定的虛擬 IP 位址和 DNS 名稱，並在 Pod 之間進行負載平衡。詳情請參閱「瞭解 Kubernetes 服務」。
挑戰：公開服務以供外部存取
情境：微服務必須可從網際網路連線，才能進行示範。
解決方案：建立 LoadBalancer 服務。GKE 會佈建具有公開 IP 位址的區域外部直通式網路負載平衡器。如果是 HTTP(S) 流量，請考慮使用 Ingress 或 Gateway，這兩者都提供第 7 層功能。詳情請參閱「關於 LoadBalancer 服務」。
挑戰：指派永久且容易記住的網址
情境：服務需要穩定的網域名稱供用戶端使用。
解決方法：預留靜態 IP 位址，並為自訂網域設定 DNS。 詳情請參閱「使用靜態 IP 位址設定網域名稱」。
挑戰：管理進階流量路徑
情境：隨著應用程式成長，您需要更精細地控制流量的轉送方式。舉例來說，您可能需要執行下列操作：
- 在單一負載平衡器上代管多個網站 (例如 api.example.com 和 shop.example.com)，以節省費用。
- 根據網址路徑將要求轉送至不同服務 (例如將
/送至前端工作負載，並將/api/v1送至後端工作負載)。 - 管理傳輸層安全標準 (TLS) 憑證，確保應用程式使用 HTTPS。
- 使用初期測試版分階段安全部署新功能，在全面推出前，先將一小部分流量轉送至新版本。
解決方案：使用 Gateway API。GKE 實作的 Gateway API 提供強大且標準化的方式來管理這類南北向流量，支援路徑式轉送、標頭比對和流量分割等進階功能。詳情請參閱「關於 Gateway API」。
使用案例：為不斷成長的應用程式擴充服務探索功能
隨著微服務型應用程式的流量和複雜度增加，服務之間的 DNS 查詢會大幅增加。雖然開發人員需要瞭解如何在這種環境中建構彈性應用程式，但平台和營運團隊通常負責實作可擴充的網路解決方案。
挑戰：啟用服務間的通訊
情境：Pod 需要可靠的方式來尋找其他服務。
解決方案：GKE 提供叢集內 DNS 服務 (例如 kube-dns 或 Cloud DNS)，可解析服務的穩定 DNS 名稱，確保 Pod 間的通訊可靠無虞。詳情請參閱「服務探索和 DNS」。
挑戰：大規模提升 DNS 效能
情境：查詢量過高導致查詢延遲。
解決方法：啟用 NodeLocal DNSCache。每個節點都會在本機快取 DNS 查詢，以減少延遲。詳情請參閱「設定 NodeLocal DNSCache 總覽」。
挑戰：在虛擬私有雲中提供服務探索功能
情境：Compute Engine VM 需要存取叢集內的服務。
解決方案：與 Cloud DNS 整合，讓服務 DNS 記錄在整個虛擬私有雲中解析。詳情請參閱「將 Cloud DNS 用於 GKE」的說明。
用途：保護多層應用程式
在這個使用案例中，您是平台工程團隊的成員，負責部署三層式應用程式 (前端、帳單、資料庫)，且必須強制執行零信任通訊。
挑戰：強制執行嚴格的流量規則
情境：只有特定服務應彼此通訊。
解決方法：啟用網路政策強制執行功能並套用 default deny 政策，然後定義明確的允許規則 (例如，前端允許流量傳送至帳單，帳單允許流量傳送至資料庫)。詳情請參閱「設定應用程式的網路政策」。
挑戰：稽核及驗證網路政策
情境：安全團隊需要強制執行和可見度的證明。
解決方法：啟用網路政策記錄功能，記錄允許和拒絕的連線。詳情請參閱「使用網路政策記錄」一文。
挑戰：向消費者私下公開服務
情境：後端服務 (例如資料庫或 API) 必須供其他虛擬私有雲網路中的消費者存取，但不得暴露在公開網際網路，也不得處理虛擬私有雲對等互連的複雜問題。
解決方法：使用 Private Service Connect 發布服務。 消費者隨後就能在自己的虛擬私有雲中建立 PSC 端點，以私密且安全的方式存取您的服務。詳情請參閱「透過 Private Service Connect 公開服務」。
應用實例：在多個叢集中實現高可用性
在這個情境中，您是網站可靠性工程師，負責在不同地區的多個 GKE 叢集中，為電子商務公司執行工作負載，以提升可靠性。
挑戰：啟用跨叢集通訊
情境：一個叢集中的服務必須探索並呼叫另一個叢集中的服務。
解決方案：使用 GKE 多叢集服務 (MCS) 建立全域 DNS 名稱，並自動將流量轉送至健康狀態良好的後端。詳情請參閱「多叢集服務」。
挑戰：確保容錯移轉作業具備復原彈性
情境：如果某個區域服務無法使用，流量必須自動重新導向。
解決方案：MCS 提供可感知健康狀態的服務探索功能，讓用戶端將單一 DNS 名稱解析為最近可用叢集中的健全後端。這種做法可實現彈性容錯移轉。詳情請參閱「多叢集服務」。
用途：建構安全有效率的多租戶 GKE 環境
您是平台工程團隊的一員，負責為多個應用程式團隊提供 GKE 叢集。您需要集中控管網路、節省 IP 位址，並強制執行嚴格的安全措施。
挑戰：集中控制網路
情境：多個應用程式團隊需要各自的叢集，但網路必須集中管理。
解決方案：使用共用虛擬私有雲。網路資源位於主專案中，但應用程式叢集會在服務專案中執行。詳情請參閱「設定共用虛擬私有雲的叢集」。
挑戰：有效管理有限的 IP 位址
情境：IP 位址空間有限，需要有效運用。
解決方案：調整每個節點的最大 Pod 數，並視需要為 Pod IP 位址使用非 RFC 1918 範圍。詳情請參閱「在 GKE 中管理 IP 位址遷移作業」。
挑戰：使用現代化且安全的資料平面，並透過新的資料平面佈建叢集
情境：
- 企業需要高效能和內建政策執行功能，才能支援要求嚴苛的工作負載和零信任安全防護。舉例來說，您可能正在執行對網路延遲時間很敏感的大規模微服務，或者您可能需要在多租戶叢集中的應用程式之間強制執行嚴格的安全邊界，以符合法規遵循要求。
- 叢集必須設定為使用新式網路資料平面，才能確保高效能和安全性，且必須部署在機構集中管理的網路架構中。
解決方案：使用 GKE Dataplane V2，這項功能以 eBPF 為基礎，可提供高效能，並內建網路政策強制執行功能。詳情請參閱「GKE Dataplane V2」。
用途：觀察及排解流量問題
身為 SRE，您正在調查結帳服務無法連線至付款服務的原因。
挑戰：解決連線問題
情境：封包遭到捨棄，但原因不明。
解決方法：啟用 GKE Dataplane V2 觀測功能。確認封包遭拒的指標，例如
hubble_drop_total。詳情請參閱「使用 Hubble 進行疑難排解」。
挑戰：找出封包遭捨棄的根本原因
情境：確認網路封包遭到捨棄 (例如使用 hubble_drop_total) 後，找出封鎖服務間流量的特定網路政策。
解決方案：使用 Hubble 指令列介面或 UI 追蹤流程。Hubble UI 會以視覺化方式呈現流量，並醒目顯示拒絕連線的確切政策設定錯誤。這項視覺化功能可協助團隊快速找出問題的根本原因，並修正政策。詳情請參閱「使用 GKE Dataplane V2 可觀測性功能監控流量」。
端對端應用情境：部署及擴充安全零售應用程式
在這個端對端情境中，平台工程團隊會為多個應用程式團隊建構標準化的 GKE 平台。該團隊部署並最佳化三層式零售應用程式 (前端、帳單、資料庫)。這個程序包括確保機器學習工作負載的安全、擴充及提升效能，以及整合進階安全設備。
下圖說明部署在 GKE 的安全多層級零售應用程式端對端架構。架構會經歷下列幾個階段：
- 階段 1：使用 Shared VPC 和 GKE Dataplane V2 建構基礎設定。
- 第 2 階段：使用 Gateway API 和多叢集服務公開應用程式，確保高可用性。
- 第 3 階段：使用 gVNIC 和第 1 層網路加速執行機器學習工作。
- 第 4 階段：使用多重網路支援功能部署進階安全設備。
第 1 階段：建構平台基礎
挑戰：為多個應用程式團隊集中管理網路，並分配足夠的 IP 位址來處理擴充作業。
解決方法：
- 使用共用虛擬私有雲集中控管。
- 規劃 IP 位址，確保可擴充性。
- 啟用 GKE Dataplane V2，打造高效能且安全的資料層。
- 使用 Private Service Connect 安全地連線至 GKE 控制層。
第 2 階段：部署及保護應用程式
挑戰：確保服務與服務間的通訊可靠，並強制執行零信任安全機制。
解決方法：
- 為穩定的內部端點建立 ClusterIP 服務。
- 套用網路政策，並採用預設拒絕的基準和明確允許規則。
第 3 階段：公開應用程式並擴大規模以利成長
挑戰：提供外部存取權，並在流量增加時縮短 DNS 查詢延遲時間。
解決方法：
- 使用 Gateway API 公開前端，進行進階流量管理。
- 指派含 DNS 的靜態 IP 位址。
- 啟用 NodeLocal DNSCache，加快查詢速度。
階段 4：實現高可用性並排解問題
挑戰：確保區域容錯移轉，並偵錯捨棄的流量。
解決方法：
- 使用多叢集服務進行跨區域容錯移轉。
- 啟用 GKE Dataplane V2 觀測功能和 Hubble，診斷並修正設定錯誤的網路政策。
第 5 階段：加速機器學習工作負載
挑戰：消除以 GPU 為基礎的模型訓練網路瓶頸。
解決方法：
第 6 階段：部署進階安全設備
挑戰：部署第三方防火牆和 IDS，並以極低延遲時間，分別管理和處理資料層流量。
解決方法：
- 啟用多網路支援功能，將多個介面附加至 Pod。
- 設定裝置模式網路 (DPDK)。