Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

VirtualNetworkRouter in Cloud-nativem Contrail Networking bereitstellen

ZUSAMMENFASSUNG  Cloud-natives Contrail® Networking unterstützt das VirtualNetworkRouter (VNR)-Konstrukt. Dieses Konstrukt sorgt für die Konnektivität zwischen VirtualNetworks.

VirtualNetworkRouter – Übersicht

Üblicherweise wird (VN)-Datenverkehr isoliert, VirtualNetwork um die Trennung der Mandanten aufrechtzuerhalten. In Cloud-nativem Contrail Networking (CN2) VirtualNetworkRouter (VNR) führt Routenlecks durch. Routing-Lecks stellen die Konnektivität zwischen VirtualNetworks dem Importieren von Routing-Instanzen (RI) und den Routing-Tabellen, die diesen Instanzen zugeordnet sind, her. Infolgedessen können Geräte in einer Routing-Tabelle auf Ressourcen von Geräten in einer anderen Routing-Tabelle zugreifen.

Der VNR bietet Konnektivität für die folgenden beiden gängigen Netzwerkmodelle:

  • Mesh: Pods in allen verbundenen Verbindungen VirtualNetworks kommunizieren miteinander.

  • Hub-Spoke: VirtualNetworks Verbinden Sie sich mit zwei verschiedenen VNR-Typen (Spoke, Hub). VirtualNetworks Verbunden mit Spoke-Typ-VNRs kommunizieren mit VirtualNetworks mit Hub-Typ-VNRs und umgekehrt. VirtualNetworks Mit Spoke verbundene VNRs können nicht mit anderen VirtualNetworks an Spoke angeschlossenen VNRs kommunizieren.

VNR ist ein Kubernetes-Konstrukt, das in CN2 bereitgestellt wird.

Anwendungsfälle für VirtualNetworkRouter

Die folgenden Beispiele sind häufige Anwendungsfälle, die die Funktionalität von VNR in CN2 demonstrieren.

Mesh-VNR zur Verbindung von zwei oder mehr virtuellen Netzwerken im selben Namespace

  1. Abbildung 1: Der Benutzer erstellt VN1 und VN2 im Namespace-1. Pods in VN1 können keine Verbindung zu Pods in VN2 herstellen. Dies ist das Standardverhalten von VirtualNetworks CN2.
  2. Abbildung 2: Der Benutzer definiert einen VNR vom Typ Mesh, der VN1 und VN2 auswählt. Dieser VNR ermöglicht Pods in VN1 die Kommunikation mit Pods in VN2 und umgekehrt.
  3. Abbildung 3: Pods in VN1 verbinden sich mit Pods in VN2. Das Routenziel von VNR ist importExported für beide VirtualNetworks.

Zurück zu Anwendungsfällen für VirtualNetworkRouter

Hinzufügen neuer virtueller Netzwerke innerhalb desselben Namespace zu einem vorhandenen Mesh-VNR

  1. Abbildung 1: Zwei VirtualNetworks (VN1, VN2) mit VNR im Namespace-1.
  2. Abbildung 2: Der Benutzer erstellt zwei neue VirtualNetworks (VN3, VN4).
  3. Abbildung 3: VN3 und VN4 verbinden sich mit VNR. Infolgedessen erhalten alle VirtualNetworks, die mit dem VNR verbunden sind, Konnektivität.

Zurück zu Anwendungsfällen für VirtualNetworkRouter

Zwei Mesh-VNRs im selben Namespace

  1. Abbildung 1 und Abbildung 2: VNR-web und VNR-db vom Typ Mesh sind bereits im Namespace-1 vorhanden. Nur VNRs, die mit den jeweiligen VNRs verbunden sind, kommunizieren miteinander.

  2. Abbildung 1 und Abbildung 2: VNR-web und VNR-db kommunizieren miteinander.

  3. Abbildung 3: Alle VirtualNetworks mit VNR-web und VNR-db verbundenen Verbindungen kommunizieren miteinander.

Zurück zu Anwendungsfällen für VirtualNetworkRouter

Zwei Mesh-VNRs mit unterschiedlichen Namespaces

  1. Abbildung 1: VNR-web wählt VN1 und VN2. Pods in VN1 und VN2 kommunizieren miteinander. VN1 und VN2 können nicht mit VN3 oder VN4 kommunizieren.

  2. Abbildung 2: VNR-db wählt VN3 und VN4. Pods in VN3 und VN4 kommunizieren miteinander. VN3 und VN4 können nicht mit VN1 oder VN2 kommunizieren.

  3. Abbildung 3: Der Benutzer aktualisiert VNR-web, um VNR-db auszuwählen.

  4. Abbildung 3: Der Benutzer aktualisiert VNR-db, um VNR-web auszuwählen.

  5. Abbildung 3: Da sich zwei VNRs gegenseitig auswählen, wird VNR-web RT (Route Target) zu VN3 und VN4 hinzugefügt. Die RT von VNR-db wird zu VN1 und VN2 hinzugefügt. Pods in VN1, VN2, VN3 und VN4 kommunizieren miteinander.

Zurück zu Anwendungsfällen für VirtualNetworkRouter

Hub-and-Spoke-VNRs im selben Namespace

  • Abbildung 1: Pods in VN1 können nicht mit Pods in VN2 kommunizieren. VN1 und VN2 können nicht mit VN3 kommunizieren.

  • Abbildung 2: Der Benutzer erstellt einen VNR vom Typ "Spoke" und "Hub". VNR-Spoke und VNR-Hub importieren sich gegenseitig die RTs.

  • Abbildung 3: Die RTs des VNR-Spokes und des VNR-Hubs werden zu VN1, VN2 und VN3 hinzugefügt, weil sie sich gegenseitig RTs importieren. Infolgedessen kommunizieren Pods in VN1 und VN2 mit VN3. Pods in VN1 und VN2 können nicht miteinander kommunizieren.

Zurück zu Anwendungsfällen für VirtualNetworkRouter

Hub-and-Spoke-VNRs in verschiedenen Namespaces

Zurück zu Anwendungsfällen für VirtualNetworkRouter

Dieselben virtuellen Netzwerke unter mehreren VNRs

  • Abbildung 1: Pods in VN1 und VN2 können nicht miteinander kommunizieren. Auch Ressourcen auf VN3 und VN4 können miteinander kommunizieren.

  • Abbildung 2: Sie erstellen eine VNR-Spoke, indem Sie VN1 und VN2 auswählen. Sie erstellen einen VNR-Hub, indem Sie VN3 und VN4 auswählen. Sie erstellen ein VNR-Mesh, indem Sie VN3 und VN4 auswählen.

  • Abbildung 3: VNR-Spoke stellt sicher, dass VN1 und VN2 nicht miteinander kommunizieren können, der VNR-Hub lässt VN1 und VN2 VN3 und VN4 erreichen, und VNR-Mesh ermöglicht die Kommunikation zwischen VN3 und VN4.

Zurück zu Anwendungsfällen für VirtualNetworkRouter

Erklärung für Anwendungsfälle

In diesem Abschnitt werden die folgenden zwei VNR-Anwendungsfälle zusammen mit end-to-End-Erklärungen für jeden Anwendungsfall dargestellt:

Standard-Anwendungsfall: Ein einziger VNR verbindet zwei virtuelle Netzwerke

Dieser Anwendungsfall umfasst folgendes:

  • Zwei VirtualNetworks (vn-1 und vn-2) im Namespace ns-single-mesh. Beide virtuellen Netzwerke verfügen über die label vn: web. Jeder VirtualNetwork enthält einen einzelnen Pod. Der VirtualNetwork vn-1 enthält pod-vn-1. Der VirtualNetwork vn-2 enthält pod-vn-2.

  • Ein type: mesh VNR mit dem Namen vnr-1. Dieser VNR stellt die Konnektivität zwischen den beiden VirtualNetworks verwenden, matchExpressions und vn: web. er VNR importiert die RI- und Routing-Tabelle von vn-1 und vn-2 umgekehrt. Da vnr-1 es sich um einen Mesh-VNR handelt, kommunizieren alle miteinander verbundenen VirtualNetworks Pods.

Anwendungsfall update: Einzelne vNR verbindet zwei weitere virtuelle Netzwerke

Dieser Anwendungsfall ähnelt dem Standard-Anwendungsszenario, außer dass in diesem Anwendungsfall der Benutzer die YAML-Datei mit einem zusätzlichen type: mesh VNR aktualisiert, um zwei neue VirtualNetworks (vn-3 und vn-4) im Namespace ns-single-meshzu verbinden. Beachten Sie Folgendes:

  • Der angezeigte VNR hat den Namen vnr-2 im Namespace ns-single-mesh mit matchExpressions: db, middlware.

  • Das VirtualNetwork vn-3 hat das Label vn: dbund vn-4 das Label vn: middleware.

Als Ergebnis vnr-2 importiert die RI- und Routing-Tabelle von vn-3 zu vn-4 und umgekehrt.

VirtualNetworkRouter-Konfiguration

Der folgende Abschnitt enthält YAML-Konfigurationsinformationen für die folgenden Ressourcen:

API-Typ (Schema)

Mesh-VNR

Die vorhergehende YAML-Datei ist ein Beispiel für einen Mesh-VNR mit dem Namen vnr-1 im Namespace frontend, mit dem labels vnr: web und ns: frontend. Dieser VNR importiert sein Routenziel in einen beliebigen VNR im Namespace backend mit matchLabel vnr: db.

Spoke VNR

Die vorhergehende YAML-Datei ist ein Beispiel für einen Spoke-VNR mit dem Namen vnr-1 im Namespace frontend mit dem labels vnrgroup: spokes und ns: frontend. Dieser VNR importiert seine Routenziele in einen beliebigen VNR im Namespace backend mit matchLabel vnrgroup: hubs.

Hub VNR

Die vorhergehende YAML-Datei ist ein Beispiel für einen Hub-VNR mit dem Namen vnr-2 im Namespace backend mit labels vnrgroup: hubs und ns: backend. Dieser VNR importiert seine Routenziele in einen beliebigen VNR im Namespace frontend mit matchLabels vnrgroup: spokes.