Multi-Netzwerk-Unterstützung für Pods


Auf dieser Seite wird die Unterstützung von mehreren Netzwerken für Pods beschrieben, einschließlich Anwendungsfällen, relevanter Konzepte, Terminologie und Vorteilen.

Übersicht

Google Cloud unterstützt mehrere Netzwerkschnittstellen auf VM-Instanzebene. Sie können eine VM mit bis zu acht Netzwerken mit mehreren Netzwerkschnittstellen, einschließlich des Standardnetzwerks, und sieben weiteren Netzwerken verbinden.

Das Google Kubernetes Engine-Netzwerk (GKE) erweitert die Multi-Netzwerk-Funktionen auf Pods, die auf den Knoten ausgeführt werden. Mit der Multi-Netzwerk-Unterstützung für Pods können Sie mehrere Schnittstellen auf Knoten und Pods in einem GKE-Cluster aktivieren. Durch die Unterstützung mehrerer Netzwerke für Pods wird die Beschränkung für eine einzelne Schnittstelle für Knotenpools aufgehoben. Dadurch werden die Knoten auf eine einzige VPC für das Netzwerk beschränkt.

Network Function Optimizer (NFO) ist ein Netzwerkdienst für GKE, der Multinetzwerkunterstützung, nichtflüchtige IP-Adressen und eine leistungsstarke Kubernetes-native Datenebene bietet. NFO aktiviert containerisierte Netzwerkfunktionen in GKE. Das Multi-Netzwerk ist eine der grundlegenden Säulen von NFO.

Informationen zur Nutzung der Multi-Netzwerk-Unterstützung für Ihre Pods und Knoten finden Sie unter Unterstützung mehrerer Netzwerke für Pods einrichten.

Terminologie und Konzepte

Auf dieser Seite werden die folgenden Konzepte verwendet:

Primäre VPC: Die primäre VPC ist eine vorkonfigurierte VPC, die mit einer Reihe von Standardeinstellungen und -ressourcen ausgestattet ist. Der GKE-Cluster wird in dieser VPC erstellt. Wenn Sie die vorkonfigurierte VPC löschen, wird der GKE-Cluster in der primären VPC erstellt.

Subnetz: In Google Cloud ist ein Subnetz die Möglichkeit, ein CIDR-Routing (Classless Inter-Domain Routing) mit Netzmasken in einer VPC zu erstellen. Ein Subnetz hat einen einzelnen primären IP-Adressbereich, der den Knoten zugewiesen ist und mehrere sekundäre Bereiche haben kann, die zu Pods und Services gehören können.

Knotennetzwerk: Das Knotennetzwerk bezieht sich auf eine dedizierte Kombination aus VPC- und Subnetzpaar. Innerhalb dieses Knotennetzwerks werden den Knoten, die zum Knotenpool gehören, IP-Adressen aus dem primären IP-Adressbereich zugewiesen.

Sekundärer Bereich: Ein sekundärer Google Cloud-Bereich ist ein CIDR und eine Netzmaske, die zu einem Subnetz gehören. GKE verwendet dies als Layer 3-Pod-Netzwerk. Ein Pod kann eine Verbindung zu mehreren Pod-Netzwerken herstellen.

Pod-Netzwerk: Ein Netzwerkobjekt, das als Verbindungspunkt für Pods dient. Die Verbindung kann entweder vom Typ Layer 3 oder vom Typ Device sein. Sie können Netzwerke vom Typ Device im Modus netdevice oder im Data Plane Development Kit (DPDK) konfigurieren.

Layer 3-Netzwerke entsprechen einem sekundären Bereich in einem Subnetz. Ein Device-Netzwerk entspricht einem Subnetz in einer VPC. Das Datenmodell für das Pod-Netzwerk in einem GKE-Multi-Netzwerk:

  • Für Layer 3-Netzwerk: VPC -> Subnetzname -> Name des sekundären Bereichs

  • Für Device-Netzwerk: VPC -> Subnetzname

Standard-Pod-Netzwerk: Google Cloud erstellt während der Clustererstellung ein Standard-Pod-Netzwerk. Das Standard-Pod-Netzwerk verwendet die primäre VPC als Knotennetzwerk. Das Standard-Pod-Netzwerk ist standardmäßig auf allen Clusterknoten und Pods verfügbar.

Pods mit mehreren Schnittstellen: Mehrere Schnittstellen auf den Pods können keine Verbindung zum selben Pod-Netzwerk herstellen.

Das folgende Diagramm zeigt eine typische GKE-Clusterarchitektur mit Layer 3-Netzwerken:

Multi-Netzwerk-Cluster

Bei Netzwerken vom Typ Device, die im Modus netdevice oder DPDK konfiguriert werden können, wird die VM vNIC als Ressource verwaltet und an den Pod übergeben. Das Pod-Netzwerk ist in diesem Fall direkt dem Node-Netzwerk zugeordnet. Für Netzwerke vom Typ Device sind keine sekundären Bereiche erforderlich.

Pod- und Knotennetzwerke

Anwendungsfälle

Die Multinetzwerkunterstützung für Pods berücksichtigt folgende Anwendungsfälle:

  • Containerisierte Netzwerkfunktionen bereitstellen: Wenn Sie die Netzwerkfunktionen in Containern ausführen, die separate Daten- und Verwaltungsebenen haben. Mehrere Netzwerke für Pods isolieren Netzwerke für verschiedene Nutzerebenen, hohe Leistung/niedrige Latenz von bestimmten Schnittstellen oder Mehrinstanzenfähigkeit auf Netzwerkebene. Dies ist für Compliance, Dienstqualität und Sicherheit erforderlich.
  • VPC innerhalb derselben Organisation und desselben Projekts verbinden: Sie möchten GKE-Cluster in einer VPC erstellen und eine Verbindung zu Diensten in einer anderen VPC herstellen. Sie können die Option für Multi-NIC-Knoten für direkte Verbindungen verwenden. Dies kann an einem Hub-and-Spoke-Modell liegen, bei dem ein zentraler Dienst (Logging, Authentifizierung) innerhalb einer Hub-VPC ausgeführt wird und die Spokes eine private Verbindung benötigen. Sie können den Multi-Netzwerk-Support für Pods verwenden, um die im GKE-Cluster ausgeführten Pods direkt mit der Hub-VPC zu verbinden.
  • DPDK-Anwendungen mit VFIO ausführen: Sie möchten DPDK-Anwendungen ausführen, die über den VFIO-Treiber Zugriff auf NIC auf dem Knoten benötigen. Sie können die optimale Paketrate erreichen, wenn Sie den Kernel, Kubernetes und GKE Dataplane V2 vollständig umgehen.
  • Direkten Zugriff auf vNIC aktivieren, um Kubernetes und GKE Dataplane V2 zu umgehen: Sie führen die Netzwerkfunktionen in Containern aus, die direkten Zugriff auf die Netzwerkschnittstellenkarte (Network Interface Card, NIC) auf dem Knoten erfordern. Beispiel: Hochleistungs-Computing-Anwendungen (HPC), die Kubernetes und GKE Dataplane V2 umgehen möchten, um die niedrigste Latenz zu erreichen. Einige Anwendungen möchten auch Zugriff auf PCIe-Topologieinformationen der NIC haben, um sie mit anderen Geräten wie GPUs zu verknüpfen.

Vorteile

Die Multi-Netzwerk-Unterstützung für Pods bietet folgende Vorteile:

  • Traffic-Isolierung: Mit der Unterstützung mehrerer Netzwerke für Pods können Sie Traffic in einem GKE-Cluster isolieren. Sie können Pods mit mehreren Netzwerkschnittstellen erstellen, um den Traffic basierend auf Funktionen wie Verwaltung und Datenebene innerhalb von Pods zu trennen, in denen bestimmte cloudnative Funktionen (CNFs) ausgeführt werden.
  • Dual Homing: Beim Dual-Hoting kann ein Pod mehrere Schnittstellen haben und den Traffic an verschiedene VPCs weiterleiten, sodass der Pod Verbindungen mit einer primären und sekundären VPC herstellen kann. Wenn Probleme mit einer VPC auftreten, kann die Anwendung auf die sekundäre VPC zurückgreifen.
  • Netzwerksegmentierung: Pods können je nach Arbeitslastanforderungen eine Verbindung zu internen oder externen Netzwerken herstellen. Abhängig von den spezifischen Anforderungen Ihrer Arbeitslasten können Sie auswählen, welche Pods oder Gruppen von Pods mit jedem Netzwerk verbunden werden. Sie können beispielsweise ein internes Netzwerk für die Ost-West-Kommunikation und ein externes Netzwerk für den Internetzugriff verwenden. So können Sie die Netzwerkverbindung Ihrer Arbeitslasten an ihre spezifischen Anforderungen anpassen.
  • Optimale Leistung mit DPDK: Durch die Unterstützung mehrerer Netzwerke für Pods in GKE können DPDK-Anwendungen in GKE-Pods ausgeführt werden. Dies bietet eine optimale Paketverarbeitungsleistung.
  • Host-NIC direkt im Pod verfügbar: Die NIC-Unterstützung im netdevice-Modus mit Multi-Netzwerk übergibt die VM-NIC direkt an den Pod und umgeht Kubernetes und GKE Dataplane V2. Dies kann die niedrigste Latenz für die Zusammenarbeit zwischen Geräten erreichen.
  • Leistung: Zur Verbesserung der Leistung Ihrer Anwendungen können Sie die Anwendungen mit dem Netzwerk verbinden, das für die Anforderungen Ihrer Anwendungen am besten geeignet ist.

Nächste Schritte