GKE Dataplane V2

Auf dieser Seite erhalten Sie einen Überblick über die Funktionsweise von GKE Dataplane V2.

Auf dieser Seite wird davon ausgegangen, dass 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 einheitliche Nutzererfahrung für die Vernetzung.
  • 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:

Der 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 die Calico Container Network Interface (CNI) verwendet iptables im Linux-Kernel.

Benutzerdefinierte eBPF-Programme

GKE Dataplane V2 verwendet eBPF-Programme, um den Netzwerkverkehr zu verwalten, einschließlich Routing, Load-Balancing und Durchsetzung von Netzwerkrichtlinien. Da diese Programme für die Netzwerkverbindung unerlässlich sind, unterstützt GKE die Installation benutzerdefinierter eBPF-Programme auf Knoten, die GKE Dataplane V2 verwenden, nicht. Benutzerdefinierte eBPF-Programme können die Programme von GKE Dataplane V2 beeinträchtigen und das Clusternetzwerk stören.

Vorteile von GKE Dataplane V2

GKE Dataplane V2 bietet die folgenden Vorteile:

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 260.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 Edge Google Distributed Cloud Hosted
Anzahl der Knoten pro Cluster 15.000 500 500
Anzahl der Pods pro Cluster 400.000 15.000 27.500
Anzahl der Pods hinter einem Dienst 10.000 1.000 1.000
Anzahl der ClusterIP-Dienste 10.000 1.000 1.000
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 260.000 Einträge enthalten kann. Wenn dieses Limit überschritten wird, funktioniert der Cluster möglicherweise nicht wie vorgesehen.

Knotenlimits

Die maximale Anzahl von Knoten pro Cluster hängt vom Standort Ihres GKE Dataplane V2-Clusters ab:

  • Regionale Cluster: Bis zu 5.000, 15.000 oder 65.000 Knoten pro Cluster. Nicht alle Knotenerhöhungen erfolgen automatisch. Je nach Anzahl der Zielknoten gibt es bestimmte Infrastrukturanforderungen. Möglicherweise müssen Sie sich an Cloud Customer Care wenden. Für die Skalierung auf 65.000 Knoten ist der für die Skalierung optimierte Modus von Dataplane V2 erforderlich, in dem die Durchsetzung von Netzwerkrichtlinien deaktiviert ist. Weitere Informationen finden Sie unter Limits und Anforderungen für die Clustergröße.
  • Zonale Cluster: Bis zu 1.000 Knoten.

Damit Sie in regionalen Clustern Knotenskalierungsgrenzwerte von mehr als 5.000 Knoten erreichen können, muss Ihre Umgebung die folgenden Bedingungen erfüllen:

  • In Ihrem Cluster muss Private Service Connect aktiviert sein. Informationen dazu, ob Ihr Cluster Private Service Connect verwendet, finden Sie unter Cluster mit Private Service Connect.
  • Cluster, die die CiliumNetworkPolicy-CRD verwenden, sind auf zonale Clusterlimits von bis zu 1.000 Knoten beschränkt. Verwenden Sie stattdessen die CiliumClusterwideNetworkPolicy-CRD,um die Skalierung auf bis zu 5.000 Knoten zu unterstützen.

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 LoadBalancer-Dienste bei Verwendung des integrierten Load-Balancing-Modus mit F5. Weitere Informationen finden Sie unter Skalierbarkeit.

Arbeitslasten mit SCTP bereitstellen

Sie können Arbeitslasten, die das Stream Control Transmission Protocol (SCTP) verwenden, in Clustern bereitstellen, die mit GKE Dataplane V2 aktiviert sind. SCTP ist ein Protokoll der Transportschicht, das eine zuverlässige, nachrichtenorientierte Übertragung ermöglicht. Weitere Informationen finden Sie unter Arbeitslasten mit SCTP bereitstellen.

Beschränkungen

GKE Dataplane V2 unterliegt den 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.
  • Manuell erstellte interne Passthrough-Netzwerk-Load-Balancer, die einem Dienst vom Typ NodePort zugeordnet sind, werden nicht unterstützt.
  • GKE Dataplane V2 verwendet cilium anstelle von kube-proxy, um Kubernetes-Dienste 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.
  • 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.

  • Die gemeldete Arbeitsspeichernutzung von GKE Dataplane V2-Agent-Pods (anetd) hängt vom gesamten auf dem Knoten verfügbaren Arbeitsspeicher ab. Auf Knoten mit mehr Gesamtarbeitsspeicher wird eine höhere Arbeitsspeichernutzung für die anetd-Pods gemeldet. Die anetd-Pods verwenden nicht tatsächlich mehr Arbeitsspeicher. Die gemeldete Nutzung steigt, weil dieser Messwert die Arbeitsspeicherreservierung der eBPF-Map umfasst.

    In GKE beträgt die Arbeitsspeicherreservierung für die größten eBPF-Maps 0, 25% des gesamten Knotenspeichers. Möglicherweise wird zusätzlicher Arbeitsspeicher für andere GKE-spezifische Funktionen reserviert.

  • GKE Dataplane V2 verwendet eBPF, um den Netzwerkverkehr Ihres Clusters zu verwalten. Wenn Sie eine Drittanbieteranwendung installieren, die ebenfalls eBPF verwendet, kann dies zu Konflikten mit GKE Dataplane V2 führen. Wenn Sie Retina mit GKE Dataplane V2 verwenden, kann dies beispielsweise verhindern, dass Ihre Pods eine Verbindung zu Diensten herstellen. Das liegt daran, dass die eBPF-Programme von Retina die Art und Weise stören können, wie GKE Dataplane V2 Traffic weiterleitet. Wenn Fehlermeldungen angezeigt werden, die darauf hinweisen, dass Traffic verworfen wird, weil er versucht, die IP-Adresse des Dienstes direkt zu erreichen, liegt möglicherweise dieses Problem vor. Das liegt daran, dass Pods nicht direkt auf die IP-Adresse des Dienstes zugreifen dürfen und der Traffic über die Routingmechanismen von Dataplane V2 geleitet werden muss. Weitere Informationen finden Sie unter Probleme mit der Inkompatibilität mit Retina-Displays.

  • Fragmentierte ICMP-Pakete werden nicht unterstützt und von GKE Dataplane V2 verworfen.

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