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 Kubernetes-Ressource NetworkPolicy. 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 die Clustervernetzung stören.

Wenn in Ihrem Cluster ein benutzerdefiniertes eBPF-Programm erkannt wird, stellt GKE eine Empfehlung bereit, die Sie über das Vorhandensein des Programms informiert.

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 einheitliche 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 Service 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 Clustergrößenlimits und -anforderungen.
  • Zonale Cluster: Bis zu 1.000 Knoten.

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

  • In Ihrem Cluster muss Private Service Connect aktiviert sein. Wenn Sie prüfen möchten, ob Ihr Cluster Private Service Connect verwendet, lesen Sie den Abschnitt 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 bei Verwendung des integrierten Load-Balancing-Modus mit F5. Weitere Informationen finden Sie unter Skalierbarkeit.

Maglev-Unterstützung

Für GKE-Cluster mit Version 1.36.0-gke.2882000 und höher können Sie Dienste so konfigurieren, dass sie den Maglev-Algorithmus für konsistentes Hashing für die Back-End-Auswahl verwenden.

Standardmäßig verwenden Kubernetes-Dienste den random-Algorithmus, um Backends auszuwählen. Der random-Algorithmus kann dazu führen, dass fehlerfreie Verbindungen umgeleitet und zurückgesetzt werden, wenn sich die Gruppe der Backend-Pods ändert (z. B. bei Skalierungsereignissen). Maglev mindert dieses Problem, indem der Traffic weiterhin an das zugewiesene Backend einer Verbindung weitergeleitet wird, solange es fehlerfrei ist, auch wenn andere Pods hinzugefügt oder entfernt werden.

Vorteile der Verwendung des Maglev-Algorithmus

Die Verwendung des Maglev-Algorithmus bietet folgende Vorteile:

  • Dadurch kann die Verbindungsstabilität verbessert werden, da der Traffic für eine Verbindung an dasselbe Backend weitergeleitet wird.
  • So können Verbindungsprobleme vermieden werden, wenn Backend-Pods hinzugefügt oder entfernt werden, z. B. bei Pod-Neustarts.

Einschränkungen bei der Verwendung des Maglev-Algorithmus

Die Verwendung des Maglev-Algorithmus kann ressourcenintensiv sein:

  • Dies kann zu einer erhöhten Arbeitsspeichernutzung auf anetd in jedem Cluster führen. Weitere Informationen finden Sie im nächsten Abschnitt „Überlegungen zur Maglev-Arbeitsspeichernutzung“.
  • Dies kann mit einer höheren anetd-CPU-Auslastung (bis zu dreimal mehr) während Backend-Änderungen zusammenhängen.

Überlegungen zur Arbeitsspeichernutzung bei Maglev

Zum Nachverfolgen von Verbindungen und Back-Ends verwendet der Maglev-Algorithmus eine Hashtabelle. Dazu wird das 5-Tupel des Pakets (Quell-IP-Adresse, Ziel-IP-Adresse, Quellport, Zielport und Protokoll) gehasht.

Die Größe der Suchtabelle ist auf 16.381 Einträge konfiguriert. Da jeder Eintrag eine Größe von 4 Byte hat, benötigt ein Dienst, der für die Verwendung des Maglev-Algorithmus konfiguriert ist, 65,5 KB (16.381 × 4 Byte) des zuweisbaren Speichers jedes Knotens.

Anzahl der Dienste mit aktiviertem Maglev Zusätzliche Arbeitsspeichernutzung
100 6,5 MB
1.000 65 MB
10.000 650 MB

Maglev-Algorithmus anwenden

Wenn Sie den Maglev-Algorithmus auf einen Dienst vom Typ NodePort oder LoadBalancer anwenden möchten, fügen Sie beim Erstellen des Dienstes die Annotation gke.networking.io/lb-algorithm: "maglev" zu den Metadaten des Dienstes hinzu.

Beispiel:

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

Die Annotation gke.networking.io/lb-algorithm wird bei der Erstellung des Dienstes wirksam. Wenn Sie den Algorithmus eines vorhandenen Dienstes ändern möchten, müssen Sie den Dienst löschen und neu erstellen. Wenn Sie den Annotationswert ändern, ohne die Annotation neu zu erstellen, kann das zu inkonsistentem Verhalten führen. anetd auf neuen Knoten versucht, den neu konfigurierten Algorithmus zu verwenden, während für vorhandene Pods weiterhin der vorherige Algorithmus verwendet wird.

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 Transportprotokoll, 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 mehr Arbeitsspeicher. Die gemeldete Nutzung steigt, weil in dieser Messgröße die Arbeitsspeicherreservierung der eBPF-Map enthalten ist.

    In GKE beträgt die Arbeitsspeicherreservierung für die größten eBPF-Maps 0, 25% des gesamten Knotenspeichers. Zusätzlicher Speicherplatz kann für andere GKE-spezifische Funktionen reserviert werden.

  • GKE Dataplane V2 verwendet eBPF, um den Netzwerkverkehr Ihres Clusters zu verwalten. Wenn Sie eine Drittanbieteranwendung installieren, die ebenfalls eBPF verwendet, kann dies die Funktion von GKE Dataplane V2 beeinträchtigen. Wenn Sie beispielsweise Retina mit GKE Dataplane V2 verwenden, kann dies 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 Sie Fehlermeldungen sehen, 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 von 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