GKE Dataplane V2

本頁面概略說明 GKE Dataplane V2 的功能和運作方式。

本頁面假設您已瞭解 GKE 叢集內的網路。

GKE Dataplane V2 總覽

GKE Dataplane V2 是專為 Kubernetes 網路最佳化的資料層。GKE Dataplane V2 提供下列功能：

  • 一致的網路使用者體驗。
  • 即時掌握網路活動。
  • 架構更簡單，管理叢集和疑難排解更輕鬆。

所有新的 Autopilot 叢集預設都會啟用 GKE Dataplane V2。

GKE Dataplane V2 的運作方式

GKE Dataplane V2 是使用 eBPF 實作。封包抵達 GKE 節點時，核心中安裝的 eBPF 程式會決定如何轉送及處理封包。與使用 iptables 處理封包不同，eBPF 程式可以使用封包中的 Kubernetes 專屬中繼資料。這樣一來，GKE Dataplane V2 就能更有效率地處理核心中的網路封包，並將加上註解的動作回報給使用者空間，以便記錄。

下圖顯示封包透過使用 GKE Dataplane V2 的節點傳輸的路徑：

封包透過使用 GKE Dataplane V2 的節點傳輸的路徑。

GKE 會將 GKE Dataplane V2 控制器部署為 DaemonSet，並命名為 anetd，然後部署至叢集中的每個節點。anetd 會解讀 Kubernetes 物件，並在 eBPF 中編寫網路拓撲。anetd Pod 會在 kube-system 命名空間中執行。

GKE Dataplane V2 和 NetworkPolicy

GKE Dataplane V2 是使用 Cilium 實作。GKE 的舊版資料層是使用 Calico 實作。

這兩項技術都會管理 Kubernetes NetworkPolicy。Cilium 使用 eBPF，Calico 容器網路介面 (CNI) 則使用 Linux 核心中的 iptables。

自訂 eBPF 程式

GKE Dataplane V2 使用 eBPF 程式管理網路流量，包括轉送、負載平衡和網路政策強制執行。這些程式對網路連線至關重要，因此 GKE 不支援在採用 GKE Dataplane V2 的節點上安裝自訂 eBPF 程式。自訂 eBPF 程式可能會干擾 GKE Dataplane V2 程式，並中斷叢集網路。

如果叢集中偵測到自訂 eBPF 程式，GKE 會提供建議，通知您有該程式。

GKE Dataplane V2 的優點

GKE Dataplane V2 具有下列優點：

擴充性

GKE Dataplane V2 的擴充性特性與舊版資料層不同。

由於 GKE Dataplane V2 不會使用 kube-proxy，也不會依賴 iptables 進行服務轉送，因此 GKE 會移除部分與 iptables 相關的瓶頸，例如服務數量。

GKE Dataplane V2 仰賴 eBPF 對應，所有服務的端點數量上限為 260,000 個。

安全性

在採用 GKE Dataplane V2 的叢集中，Kubernetes NetworkPolicy 一律會啟用。您不必安裝及管理 Calico 等第三方軟體外掛程式，即可強制執行網路政策。

作業

使用 GKE Dataplane V2 建立叢集時，系統會內建網路政策記錄功能。在叢集上設定記錄 CRD，即可查看 Pod 允許和拒絕連線的時間。

一致性

GKE Dataplane V2 提供一致的網路體驗。

詳情請參閱「GKE Dataplane V2 的可用性」。

GKE Dataplane V2 技術規格

GKE Dataplane V2 支援符合下列規格的叢集：

規格 GKE Google Distributed Cloud Edge Google Distributed Cloud Hosted
每個叢集的節點數量 15,000 500 500
每個叢集的 Pod 數量 400,000 15,000 27,500
一個 Service 後方的 Pod 數量 10,000 1,000 1,000
叢集 IP Service 數量 10,000 1,000 1,000
每個叢集的 LoadBalancer Service 數量 750 500 1,000

GKE Dataplane V2 會維護 Service 對應，追蹤哪些 Service 參照哪些 Pod 做為後端。所有 Service 的 Pod 後端數量總和必須符合 Service 對應，最多可包含 260,000 個項目。如果超過這項限制，叢集可能無法正常運作。

節點限制

每個叢集的節點數量上限取決於 GKE Dataplane V2 叢集的位置：

  • 區域叢集：每個叢集最多可有 5,000、15,000 或 65,000 個節點。並非所有節點增加都是自動進行。視目標節點數量而定，您可能需要滿足特定基礎架構需求，或與 Cloud Customer Care 聯絡。如要擴充至 65,000 個節點，必須使用 Dataplane V2 擴充最佳化模式，這會停用網路政策強制執行功能。詳情請參閱「叢集大小限制和規定」。
  • 可用區叢集：最多 1,000 個節點。

如要讓區域叢集的節點擴充限制超過 5,000 個節點，環境必須符合下列條件：

  • 叢集必須啟用 Private Service Connect。如要確認叢集是否使用 Private Service Connect，請參閱「使用 Private Service Connect 的叢集」。
  • 使用 CiliumNetworkPolicy CRD 的叢集，節點數量上限為 1,000 個。請改用 CiliumClusterwideNetworkPolicy CRD，最多可擴充至 5,000 個節點。

Google Distributed Cloud 中的 LoadBalancer 服務

Google Distributed Cloud 支援的 LoadBalancer 服務數量，取決於使用的負載平衡器模式。使用套裝組合負載平衡模式 (Seesaw) 時，Google Distributed Cloud 支援 500 項 LoadBalancer 服務；使用 F5 整合式負載平衡模式時，則支援 250 項。詳情請參閱「擴充性」。

Maglev 支援

如果 GKE 叢集執行 1.36.0-gke.2882000 以上版本，您可以設定 Service，使用 Maglev 一致性雜湊演算法選取後端。

根據預設，Kubernetes Service 會使用 random 演算法選取後端。當一組後端 Pod 發生變更時 (例如在資源調度事件期間)，random 演算法可能會導致健康連線重新規劃路線並重設。Maglev 則會持續將流量轉送至連線指派的後端 (只要後端保持健康狀態)，即使新增或移除其他 Pod 也不會影響，因此能降低這類問題。

使用 Maglev 演算法的好處

使用 Maglev 演算法有下列好處：

  • 這項功能可將連線流量導向同一個後端，提升連線穩定性。
  • 新增或移除後端 Pod 時 (例如重新啟動 Pod)，這項功能可減少連線問題。

使用 Maglev 演算法的限制

使用 Maglev 演算法可能會耗用大量資源：

  • 這可能會導致每個叢集中 anetd 的記憶體用量增加。詳情請參閱下一節「Maglev 記憶體用量注意事項」。
  • 這可能與後端變更期間，anetd CPU 使用率較高 (最多高出三倍) 有關。

Maglev 記憶體用量注意事項

為追蹤連線和後端，Maglev 演算法會使用雜湊表，對封包的 5 元組 (來源 IP 位址、目的地 IP 位址、來源通訊埠、目的地通訊埠和通訊協定) 進行雜湊處理。

查詢資料表的大小設為 16,381 個項目。由於每個項目的大小為 4 位元組，因此設定為使用 Maglev 演算法的服務，需要每個節點可分配記憶體的 65.5 KB (16,381 × 4 位元組)。

已啟用 Maglev 的服務數量 額外記憶體用量
100 6.5 MB
1,000 65 MB
10,000 650 MB

套用 Maglev 演算法

如要將 Maglev 演算法套用至 NodePort 或 LoadBalancer 類型的 Service，請在建立 Service 時，將 gke.networking.io/lb-algorithm: "maglev" 註解新增至 Service 的中繼資料。

範例：

apiVersion: v1
kind: Service
metadata:
  name: maglev-service
  annotations:
    gke.networking.io/lb-algorithm: "maglev"
spec:
  type: LoadBalancer
  selector:
    app: application
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

gke.networking.io/lb-algorithm 註解會在建立 Service 時生效。如要變更現有 Service 的演算法，必須刪除並重新建立 Service。如果變更註解值，但未重新建立，會導致行為不一致。新節點上的 anetd 會嘗試使用新設定的演算法，而現有 Pod 則繼續使用先前的演算法。

部署採用 SCTP 的工作負載

您可以在啟用 GKE Dataplane V2 的叢集上，部署使用串流控制傳輸通訊協定 (SCTP) 的工作負載。SCTP 是傳輸層通訊協定，可提供可靠的訊息導向傳輸。詳情請參閱「使用 SCTP 部署工作負載」。

限制

GKE Dataplane V2 有下列限制：

  • GKE Dataplane V2 只能在建立新叢集時啟用。現有叢集無法升級為使用 GKE Dataplane V2。
  • 不支援手動建立的內部直通式網路負載平衡器，且該平衡器與 NodePort 類型的 Service 相關聯。
  • GKE Dataplane V2 使用 cilium 而非 kube-proxy 來實作 Kubernetes 服務。kube-proxy 是由 Kubernetes 社群維護及開發，因此 Service 的新功能更有可能先在 kube-proxy 中實作，然後才在 GKE Dataplane V2 的 cilium 中實作。
  • 在某些情況下，GKE Dataplane V2 代理程式 Pod (anetd) 可能會耗用大量 CPU 資源，每個執行個體最多可達兩或三個 vCPU。如果節點上快速開啟及關閉大量 TCP 連線，就會發生這種情況。為減輕這個問題，建議您為 HTTP 呼叫實作持續連線，並為相關工作負載實作連線集區。

  • GKE Dataplane V2 代理程式 Pod (anetd) 的回報記憶體用量，取決於節點的可用記憶體總量。總記憶體較高的節點，會回報 anetd Pod 的記憶體用量較高。anetd Pod 實際上並未使用更多記憶體，回報的用量增加是因為這項指標包含 eBPF 對應的記憶體預留量。

    在 GKE 中，最大 eBPF 對應的記憶體預留量為節點記憶體總量的 0.25%。其他 GKE 專屬功能可能會保留額外記憶體。

  • GKE Dataplane V2 使用 eBPF 管理叢集的網路流量。如果您安裝的第三方應用程式也使用 eBPF，可能會干擾 GKE Dataplane V2。舉例來說，搭配使用 Retina 與 GKE Dataplane V2，可能會導致 Pod 無法連線至 Service。這是因為 Retina 的 eBPF 程式可能會干擾 GKE Dataplane V2 轉送流量的方式。如果看到錯誤訊息，指出流量因嘗試直接連至 Service 的 IP 位址而遭捨棄，就可能遇到這個問題。這是因為 Pod 不得直接存取 Service 的 IP 位址，且流量必須經過 Dataplane V2 的轉送機制。詳情請參閱「Retina 不相容問題」。

  • GKE Dataplane V2 不支援片段 ICMP 封包，會將其捨棄。

不使用 GKE Dataplane V2 強制執行網路政策

如要瞭解如何在不使用 GKE Dataplane V2 的叢集中啟用網路政策強制執行功能，請參閱「使用網路政策強制執行功能」。

後續步驟