GKE Dataplane V2

Diese Seite bietet einen Überblick über die Funktionsweise von GKE Dataplane V2.

Bevor Sie diese Seite lesen, sollten Sie sich mit dem Netzwerk in GKE-Clustern vertraut gemacht haben.

Übersicht über GKE Dataplane V2

GKE Dataplane V2 ist eine Datenebene, die für das Kubernetes-Netzwerk optimiert ist. GKE Dataplane V2 bietet Folgendes:

  • Eine konsistente Nutzererfahrung in Bezug auf das Netzwerk.
  • Sichtbarkeit der Netzwerkaktivität in Echtzeit.
  • Unkomplizierte Architektur, die die Verwaltung und Fehlerbehebung von Clustern vereinfacht.

GKE Dataplane V2 ist für alle neuen Autopilot-Cluster standardmäßig aktiviert.

Funktionsweise von GKE Dataplane V2

GKE Dataplane V2 ist mithilfe von eBPF implementiert. Sobald Pakete bei einem GKE-Knoten eingehen, entscheiden im Kernel installierte eBPF-Programme über die Weiterleitung und Verarbeitung der Pakete. Im Gegensatz zur Paketverarbeitung mit iptables können eBPF-Programme Kubernetes-spezifische Metadaten im Paket verwenden. Dadurch kann GKE Dataplane V2 Netzwerkpakete im Kernel effizienter verarbeiten und annotierte Aktionen zum Logging an den Nutzerbereich melden.

Das folgende Diagramm zeigt den Pfad eines Pakets durch einen Knoten mit GKE Dataplane V2:

GKE stellt den GKE Dataplane V2-Controller als DaemonSet mit dem Namen anetd für jeden Knoten im Cluster bereit. anetd interpretiert Kubernetes-Objekte und programmiert Netzwerktopologien in eBPF. Die anetd-Pods werden im Namespace kube-system ausgeführt.

GKE Dataplane V2 und NetworkPolicy

GKE Dataplane V2 ist mithilfe von Cilium implementiert. Die Legacy-Datenebene für GKE wird mithilfe von Calico implementiert.

Beide Technologien verwalten die NetworkPolicy von Kubernetes. Cilium verwendet eBPF und das Calico Container Network Interface (CNI) verwendet iptables im Linux-Kernel.

Vorteile von GKE Dataplane V2

Skalierbarkeit

GKE Dataplane V2 hat andere Skalierbarkeitsmerkmale als die Legacy-Datenebene.

Bei GKE-Versionen, in denen GKE Dataplane V2 keinen Kube-Proxy verwendet und keine iptables für das Dienstrouting verwendet, entfernt GKE einige iptables-bezogene Engpässe, darunter die Anzahl der Dienste.

GKE Dataplane V2 verwendet eBPF-Zuordnungen, die in allen Diensten auf 64.000 Endpunkte beschränkt sind.

Sicherheit

Die Kubernetes NetworkPolicy ist in Clustern mit GKE Dataplane V2 immer aktiviert. Sie müssen keine Software-Add-ons von Drittanbietern wie Calico installieren und verwalten, um die Netzwerkrichtlinie zu erzwingen.

Vorgänge

Wenn Sie einen Cluster mit GKE Dataplane V2 erstellen, ist das Logging von Netzwerkrichtlinien integriert. Konfigurieren Sie die Logging-CRD in Ihrem Cluster, um zu sehen, wann Verbindungen von Ihren Pods zugelassen oder abgelehnt werden.

Konsistenz

GKE Dataplane V2 bietet eine konsistente Netzwerkerfahrung.

Weitere Informationen finden Sie unter Verfügbarkeit von GKE Dataplane V2.

Technische Spezifikationen für GKE Dataplane V2

GKE Dataplane V2 unterstützt Cluster mit den folgenden Spezifikationen:

Spezifikation GKE Google Distributed Cloud Google Distributed Cloud
Anzahl der Knoten pro Cluster 5.000 500 500
Anzahl der Pods pro Cluster 50.000 15.000 27.500
Anzahl von LoadBalancer-Diensten pro Cluster 750 500 1.000

GKE Dataplane V2 verwaltet eine Dienstzuordnung, um zu verfolgen, welche Dienste auf welche Pods als Back-Ends verweisen. Die Anzahl der Pod-Back-Ends für jeden Dienst, die über alle Dienste hinweg aggregiert werden, muss in die Dienstzuordnung passen, die bis zu 64.000 Einträge enthalten kann. Wenn dieses Limit überschritten wird, funktioniert der Cluster möglicherweise nicht wie vorgesehen.

Erhöhung des Knotenlimits in Version 1.23

Ab Kubernetes-Version 1.23 wurde das Limit von 500 Knoten pro GKE Dataplane V2-Cluster auf 5.000 erhöht. Dabei gelten die folgenden zusätzlichen Bedingungen für Cluster:

  • Private Cluster oder öffentliche Cluster, die Private Service Connect verwenden. Wenn Sie Prüfen wollen, ob Ihr Cluster Private Service Connect verwendet, finden Sie unter Öffentliche Cluster mit Private Service Connect weitere Informationen.
  • Nur regionale Cluster
  • Nur Cluster, die mit GKE-Version 1.23 oder höher erstellt wurden, haben ein höheres Knotenlimit von 5.000. Bei Clustern, die mit früheren GKE-Versionen erstellt wurden, muss möglicherweise ein Kontingent für die Clustergröße erhöht werden. Wenden Sie sich an den Support, um Unterstützung zu erhalten.
  • Cluster, die Cilium-CRDs (CiliumNetworkPolicy und CiliumClusterwideNetworkPolicy) verwenden, können nicht auf 5.000 Knoten skaliert werden.

LoadBalancer-Dienste in Google Distributed Cloud

Die Anzahl der LoadBalancer-Dienste, die in Google Distributed Cloud unterstützt werden, hängt vom verwendeten Load Balancer-Modus ab. Google Distributed Cloud unterstützt 500 LoadBalancer-Dienste bei Verwendung des gebündelten Load Balancing-Modus (Seesaw) und 250 bei Verwendung des integrierten Load-Balancing-Modus mit F5. Weitere Informationen finden Sie unter Skalierbarkeit.

Beschränkungen

Für GKE Dataplane V2 gelten die folgenden Einschränkungen:

  • GKE Dataplane V2 kann nur beim Erstellen eines neuen Clusters aktiviert werden. Vorhandene Cluster können nicht für die Verwendung von GKE Dataplane V2 aktualisiert werden.
  • Wenn Sie in GKE-Versionen vor 1.20.12-gke.500 GKE Dataplane V2 mit NodeLocal DNSCache aktivieren, können Sie keine Pods mit dnsPolicy: ClusterFirstWithHostNet konfigurieren oder dann treten DNS-Auflösungsfehler auf.
  • Ab der GKE-Version 1.21.5-gke.1300 unterstützt GKE Dataplane V2 keine CiliumNetworkPolicy- oder CiliumClusterwideNetworkPolicy-CRD APIs. Ab den GKE-Versionen 1.28.6-gke.1095000 und 1.29.1-gke.1016000 können Sie CliumClusterwideNetworkPolicy auf neuen oder vorhandenen Clustern aktivieren.
  • Manuell erstellte interne Passthrough-Netzwerk-Load-Balancer, die einem Dienst vom Typ NodePort zugeordnet sind, werden nicht unterstützt.
  • Da GKE Dataplane V2 die eBPF-Kernel-Paketverarbeitung mithilfe von eBPF optimiert, kann dies die Pod-Leistung beeinträchtigen, wenn Sie Arbeitslasten haben, die eine hohe Pod-Abwanderung haben. Der Schwerpunkt von GKE Dataplane V2 liegt auf dem Erreichen optimaler eBPF.
  • Es gibt ein bekanntes Problem bei Multi-Cluster-Diensten mit mehreren (TCP/UDP)-Ports in GKE Dataplane V2. Weitere Informationen finden Sie unter MCS-Dienste mit mehreren Ports.
  • GKE Dataplane V2 verwendet cilium anstelle von kube-proxy, um Kubernetes-Services zu implementieren. kube-proxy wird von der Kubernetes-Community verwaltet und entwickelt: Neue Features für Dienste werden daher wahrscheinlich eher in kube-proxy implementiert, bevor sie in cilium für GKE Dataplane V2 implementiert werden. Ein Beispiel für ein Dienste-Feature, das zuerst in kube-proxy implementiert wurde, ist KEP-1669: Proxy-Beendigung von Endpoints.
  • Für NodePort-Dienste, auf denen Version 1.25 oder früher ausgeführt wird und die Standard-SNAT- und PUPI-Bereiche verwenden, müssen Sie den PUPI-Bereich der Pods in nonMasqueradeCIDRs in der ConfigMap ip-masq-agent hinzufügen, um Verbindungsprobleme zu vermeiden.
  • In bestimmten Fällen können GKE Dataplane V2-Agent-Pods (anetd) eine erhebliche Menge an CPU-Ressourcen verbrauchen, bis zu zwei oder drei vCPUs pro Instanz. Dies tritt auf, wenn eine große Anzahl von TCP-Verbindungen auf dem Knoten schnell geöffnet und geschlossen wird. Zur Behebung dieses Problems empfehlen wir, Keep-Alives für HTTP-Aufrufe und Verbindungs-Pooling für die entsprechenden Arbeitslasten zu implementieren.
  • GKE Dataplane V2-Cluster, auf denen die Steuerungsebenen-Version 1.27 oder niedriger ausgeführt wird, unterstützen das Feld .spec.internalTrafficPolicy des Dienstes nicht. Die geltende Richtlinie für internen Traffic für einen Dienst lautet Cluster. Back-Ends auf einem beliebigen Knoten werden als Kandidaten für die Dienstauflösung betrachtet. Weitere Informationen zu diesem Feld finden Sie unter Richtlinie für internen Traffic von Diensten.

GKE Dataplane V2 und kube-proxy

GKE Dataplane V2 verwendet kube-proxy nur in Windows Server-Knotenpools mit den GKE-Versionen 1.25 und früher.

Durchsetzung von Netzwerkrichtlinien ohne GKE Dataplane V2

Unter Erzwingung von Netzwerkrichtlinien finden Sie Anleitungen zum Aktivieren der Durchsetzung von Netzwerkrichtlinien in Clustern, die GKE Dataplane V2 nicht verwenden.

Nächste Schritte