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 版本未使用 kube-proxy，且不依賴 iptables 進行服務路由，GKE Dataplane V2 就能移除部分 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
單一服務後方的 Pod 數量 10,000 1,000 1,000
Cluster IP 服務數量 10,000 1,000 1,000
每個叢集的 LoadBalancer Service 數量 750 500 1,000

GKE Dataplane V2 會維護服務對應表，追蹤哪些服務參照哪些 Pod 做為後端。每個服務的 Pod 後端數量加總必須全部符合服務地圖，最多可包含 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

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

根據預設，Kubernetes 服務會使用 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 類型的服務，請在建立服務時，將 gke.networking.io/lb-algorithm: "maglev" 註解新增至服務的中繼資料。

範例：

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 註解會在服務建立期間生效。如要變更現有服務的演算法，請刪除並重新建立服務。如果變更註解值，但未重新建立註解，就會導致行為不一致。anetd 的新節點會嘗試使用新設定的演算法，現有 Pod 則會繼續使用先前的演算法。

使用 SCTP 部署工作負載

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

限制

GKE Dataplane V2 具有下列限制：

  • 只有在建立新叢集時，才能啟用 GKE Dataplane V2。現有叢集無法升級，因此無法使用 GKE Dataplane V2。
  • 不支援與 NodePort 類型服務相關聯的手動建立內部直通式網路負載平衡器。
  • GKE Dataplane V2 會使用 cilium (而非 kube-proxy) 實作 Kubernetes 服務。kube-proxy 由 Kubernetes 社群維護及開發，因此服務的新功能較有可能先在 kube-proxy 中實作，然後才在 cilium 中實作，以供 GKE Dataplane V2 使用。
  • 在某些情況下，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 無法連線至服務。這是因為 Retina 的 eBPF 程式可能會中斷 GKE Dataplane V2 的流量路徑。如果看到錯誤訊息，指出流量因嘗試直接連線至服務的 IP 位址而遭到捨棄，您可能遇到這個問題。這是因為 Pod 不得直接存取 Service 的 IP 位址，流量必須通過 Dataplane V2 的路由機制。詳情請參閱「Retina 不相容問題」。

  • GKE Dataplane V2 不支援 ICMP 封包片段，因此會捨棄這類封包。

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

如要在未使用 GKE Dataplane V2 的叢集中啟用網路政策強制執行服務，請參閱「使用網路政策強制執行服務」一文中的操作說明。

後續步驟