探索 GKE 網路說明文件和用途

Google Kubernetes Engine (GKE) 的網路涵蓋廣泛的概念，包括 Pod、服務、DNS、負載平衡、安全性和 IP 位址管理。雖然文件詳細說明瞭各項功能，但遇到實際問題時，您可能不知道該從何著手。

這份文件會將常見問題連結至可解決問題的功能和章節，協助您瀏覽 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)，可解析 Service 的穩定 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 公開服務」。

用途：在多個叢集間實現高可用性

在這個情境中，您是 SRE，負責在不同區域的多個 GKE 叢集中，為電子商務公司執行工作負載，以提升可靠性。

挑戰：啟用跨叢集通訊

情境：某個叢集中的服務必須探索及呼叫另一個叢集中的服務。

解決方案：使用 GKE 多叢集服務 (MCS) 建立全域 DNS 名稱，並自動將流量轉送至運作正常的後端。詳情請參閱「多叢集服務」。

挑戰：確保容錯移轉作業具備復原彈性

情境：如果某個區域服務無法使用，流量必須自動重新導向。

解決方案：MCS 提供健康狀態感知服務探索功能，可讓用戶端將單一 DNS 名稱解析為最近可用叢集中的健康後端。這種做法可提供彈性的容錯移轉機制。詳情請參閱「多叢集服務」。

用途：建構安全有效率的多租戶 GKE 環境

身為平台工程團隊的一員，您需要為多個應用程式團隊提供 GKE 叢集。您需要集中控管網路、節省 IP 位址，並強制執行嚴格的安全措施。

挑戰：集中控管網路

情境：多個應用程式團隊需要專屬叢集，但網路必須集中管理。

解決方案：使用 Shared VPC。網路資源位於主專案中，但應用程式叢集是在服務專案中執行。詳情請參閱「使用 Shared VPC 設定叢集」。

挑戰：有效管理有限的 IP 位址

情境：IP 位址空間有限，需要有效運用。

解決方案：調整每個節點的 Pod 數量上限，並視需要為 Pod IP 位址使用非 RFC 1918 範圍。 詳情請參閱「在 GKE 中管理 IP 位址遷移作業」一文。

挑戰：使用現代化的安全資料層，並透過新的資料層佈建叢集

情境：

  • 企業需要高效能和內建政策強制執行功能，才能支援要求嚴苛的工作負載和零信任安全防護。舉例來說，您可能正在執行對網路延遲相當敏感的大規模微服務，或者需要在多租戶叢集中的應用程式之間強制執行嚴格的安全界線，以符合法規遵循要求。
  • 叢集必須設定為使用現代網路資料層，以確保高效能和安全性，且必須部署在組織集中管理的網路結構中。

解決方案：使用以 eBPF 為基礎的 GKE Dataplane V2，不僅效能優異，還內建網路政策強制執行功能。詳情請參閱「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 階段：使用多重網路支援功能部署進階安全設備。
圖表：GKE 上安全的多層式零售應用程式端對端架構，說明部署和擴充六個階段的網路元件。
圖 1. 這個端對端架構適用於 GKE 上的安全多層零售應用程式，著重說明部署和擴充作業各階段使用的重要網路元件。以下各節將詳細說明每個階段。

階段 1：建立平台基礎

挑戰：集中管理多個應用程式團隊的網路，並分配足夠的 IP 位址來處理資源調度。

解決方法：

第 2 階段：部署及保護應用程式

挑戰：確保服務間的通訊可靠，並強制執行零信任安全防護。

解決方法：

第 3 階段：公開應用程式並擴大規模以利成長

挑戰：提供外部存取權，並在流量增加時縮短 DNS 查詢延遲時間。

解決方法：

階段 4：實現高可用性並排解問題

挑戰：確保區域容錯移轉，並對捨棄的流量進行偵錯。

解決方法：

第 5 階段：加快機器學習工作負載

挑戰：消除以 GPU 為基礎的模型訓練網路瓶頸。

解決方法：

  • 啟用 gVNIC，提高頻寬。
  • 在重要節點上設定第 1 層網路，以達到最大處理量。

第 6 階段：部署進階安全防護設備

挑戰：部署第三方防火牆和 IDS，並以極低延遲率，分別管理和傳輸資料層流量。

解決方法：

後續步驟