GKE Dataplane V2

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

Auf dieser Seite wird davon ausgegangen, dass Sie mit der Vernetzung in GKE-Clustern vertraut sind.

Ü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 den Netzwerken.
• 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 Kubernetes NetworkPolicy. Cilium verwendet eBPF und das 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 Netzwerkkonnektivität 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 stören und die Clustervernetzung unterbrechen.

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:

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. Abhängig von der Zielknotenanzahl gibt es bestimmte Infrastrukturanforderungen und Sie müssen sich möglicherweise 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, der die Durchsetzung von Netzwerkrichtlinien deaktiviert. Weitere Informationen finden Sie unter Limits und Anforderungen für die Clustergröße.
• Zonale Cluster: Bis zu 1.000 Knoten.

Um die Knotenlimits von mehr als 5.000 Knoten in regionalen Clustern zu erreichen, 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 der Google Distributed Cloud

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

Maglev-Unterstützung

Bei GKE-Clustern mit Version 1.36.0-gke.2882000 und höher können Sie Dienste so konfigurieren, dass der Maglev-Algorithmus für konsistente Hashfunktionen für die Back-End-Auswahl verwendet wird.

Standardmäßig verwenden Kubernetes-Dienste den Algorithmus random, um Back-Ends auszuwählen. Der Algorithmus random kann dazu führen, dass fehlerfreie Verbindungen umgeleitet und zurückgesetzt werden, wenn sich die Gruppe der Back-End-Pods ändert (z. B. bei Skalierungsereignissen). Maglev verhindert dies, indem der Traffic weiterhin an das zugewiesene Back-End 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 die folgenden Vorteile:

• Er kann die Verbindungsstabilität verbessern, indem er Traffic für eine Verbindung an dasselbe Back-End weiterleitet.
• Er kann Verbindungsprobleme vermeiden, wenn Back-End-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:

• Er kann in jedem Cluster zu einer erhöhten Arbeitsspeichernutzung auf anetd führen. Weitere Informationen finden Sie im nächsten Abschnitt „Überlegungen zur Arbeitsspeichernutzung von Maglev“.
• Er kann bei Back-End-Änderungen zu einer höheren CPU-Auslastung von anetd führen (bis zu dreimal mehr).

Überlegungen zur Arbeitsspeichernutzung von Maglev

Um Verbindungen und Back-Ends zu verfolgen, verwendet der Maglev-Algorithmus eine Hashtabelle. Dabei wird das 5-Tupel des Pakets gehasht (Quell-IP-Adresse, Ziel-IP-Adresse, Quellport, Zielport und Protokoll).

Die Größe der Lookup-Tabelle 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 Arbeitsspeichers jedes Knotens.

Maglev-Algorithmus anwenden

Wenn Sie den Maglev-Algorithmus auf einen Dienst vom Typ NodePort oder LoadBalancer, fügen Sie bei der Diensterstellung 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 Diensterstellung 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 den Dienst neu zu erstellen, führt dies zu inkonsistentem Verhalten. anetd auf neuen Knoten versucht, den neu konfigurierten Algorithmus zu verwenden, während vorhandene Pods weiterhin den vorherigen Algorithmus verwenden.

Arbeitslasten mit SCTP bereitstellen

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

Beschränkungen

GKE Dataplane V2 unterliegt den folgenden Beschrä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 insgesamt auf dem Knoten verfügbaren Arbeitsspeicher ab. Bei Knoten mit mehr Arbeitsspeicher wird eine höhere Arbeitsspeichernutzung für die anetd-Pods gemeldet. Die anetd Pods verwenden nicht tatsächlich mehr Arbeitsspeicher. Die gemeldete Nutzung steigt, da dieser Messwert die Speicherreservierung der eBPF-Zuordnung umfasst.

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

• GKE Dataplane V2 verwendet eBPF, um den Netzwerktraffic 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 beispielsweise Retina mit GKE Dataplane V2 verwenden, können Ihre Pods keine Verbindung zu Diensten herstellen. Das liegt daran, dass die eBPF-Programme von Retina die Weiterleitung des Traffics durch GKE Dataplane V2 stören können. Wenn Fehlermeldungen angezeigt werden, die darauf hinweisen, dass Traffic verworfen wird, weil versucht wird, 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 die Routingmechanismen von Dataplane V2 durchlaufen muss. Weitere Informationen finden Sie unter Inkompatibilitätsprobleme mit Retina.

• 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

• GKE Dataplane V2 verwenden
• Informationen zur Beobachtbarkeit von GKE Dataplane V2
• Logging von Netzwerkrichtlinien verwenden .
• Hier finden Sie eine Liste der GKE-Clusterumgebungen, auf denen GKE Dataplane V2 verfügbar ist.