Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Déployer VirtualNetworkRouter dans le cloud-native Contrail Networking

RÉSUMÉ  Cloud-Native Contrail® Networking prend en charge la VirtualNetworkRouter construction (VNR). Cette construction fournit une connectivité entre VirtualNetworks.

Présentation de VirtualNetworkRouter

En règle générale, VirtualNetwork le trafic est isolé pour maintenir la séparation des locataires. Dans Cloud-Native Contrail Networking, VirtualNetworkRouter (VNR) effectue une fuite de route. La fuite de routage établit la connectivité entre VirtualNetworks les instances de routage (RI) et les tables de routage associées à ces instances. En conséquence, les équipements d’une table de routage peuvent accéder aux ressources des équipements d’une autre table de routage.

Le VNR fournit la connectivité pour les deux modèles de réseau courants suivants :

  • Maillage : les pods de tous les équipements connectés VirtualNetworks communiquent entre eux.

  • Hub-spoke : VirtualNetworks connectez-vous à deux types différents de VNR (spoke, hub). VirtualNetworks connectés à des VNR de type spoke communiquent avec VirtualNetworks des VNR de type hub et inversement. VirtualNetworks connectés à des VNR en étoile ne peuvent pas communiquer avec les autres VirtualNetworks VNR connectés à des VNR en étoile.

VNR est une construction Kubernetes déployée dans Cloud-Native Contrail Networking.

Cas d’utilisation de VirtualNetworkRouter

Les exemples suivants sont des cas d’utilisation courants qui démontrent les fonctionnalités de VNR dans Cloud-Native Contrail Networking.

VNR maillé qui connecte deux réseaux virtuels ou plus dans le même espace de noms

  1. Figure 1 : L’utilisateur crée VN1 et VN2 dans l’espace de noms-1. Les pods dans VN1 ne peuvent pas se connecter aux pods dans VN2. C’est le comportement par défaut de VirtualNetworks Cloud-Native Contrail Networking.
  2. Figure 2 : L’utilisateur définit un VNR de type maillage qui sélectionne VN1 et VN2. Ce VNR permet aux pods de VN1 de communiquer avec les pods dans VN2 et vice-versa.
  3. Figure 3 : Les pods dans VN1 se connectent aux pods dans VN2. La cible de route du VNR est importExported à la fois VirtualNetworks.

Retour aux cas d’utilisation de VirtualNetworkRouter

Ajouter de nouveaux réseaux virtuels dans le même espace de noms à un VNR de type maillage existant

  1. Figure 1 : Deux VirtualNetworks (VN1, VN2) se connectent au VNR dans l’espace de noms-1.
  2. Figure 2 : L’utilisateur crée deux nouveaux VirtualNetworks (VN3, VN4).
  3. Figure 3 : VN3 et VN4 se connectent au VNR. En conséquence, tous les VirtualNetworksconnectés au VNR bénéficient d’une connectivité.

Retour aux cas d’utilisation de VirtualNetworkRouter

Deux VNR maillage dans le même espace de noms

  1. Figure 1 : VNR-web et VNR-db de type maillage existent déjà dans l’espace de noms 1. Seuls les VNR connectés aux VNR respectifs communiquent entre eux.
  2. Figure 2 : VNR-web et VNR-db communiquent entre eux.
  3. Figure 3 : toutes les VirtualNetworks connexions VNR-web et VNR-db communiquent entre elles.

Retour aux cas d’utilisation de VirtualNetworkRouter

Deux VNR maillage avec des espaces de noms différents

  1. Fig-1 : VNR-web sélectionne VN1 et VN2. Les pods VN1 et VN2 communiquent entre eux. VN1 et VN2 ne peuvent pas communiquer avec VN3 et VN4.
  2. Fig 2 : VNR-db sélectionne VN3 et VN4. Les pods dans VN3 et VN4 communiquent entre eux. VN3 et VN4 ne peuvent pas communiquer avec VN1 et VN2.
  3. Fig-3 : L’utilisateur met à jour VNR-web pour sélectionner VNR-db.
  4. Fig-3 : L’utilisateur met à jour VNR-db pour sélectionner VNR-web.
  5. Fig 3 : puisque deux VNR se sélectionnent, le RT (cible de routage) de VNR-web est ajouté à VN3 et VN4. Le RT de VNR-db est ajouté à VN1 et VN2. Les pods dans VN1, VN2, VN3 et VN4 communiquent entre eux.

Retour aux cas d’utilisation de VirtualNetworkRouter

VNR en étoile dans le même espace de noms

  • Figure 1 : Les pods de VN1 ne peuvent pas communiquer avec les pods dans VN2. VN1 et VN2 ne peuvent pas communiquer avec VN3.
  • Figure 2 : L’utilisateur crée un VNR de type « spoke » et « hub ». VNR-spoke et VNR-hub s’importent les RT de l’autre.
  • Figure 3 : les RT en étoile VNR et VNR-hub sont ajoutés à VN1, VN2 et VN3 parce qu’ils importent les RT les uns des autres. En conséquence, les pods de VN1 et VN2 communiquent avec VN3. Les pods VN1 et VN2 ne peuvent pas communiquer.

Retour aux cas d’utilisation de VirtualNetworkRouter

VNR en étoile dans différents espaces de noms

Retour aux cas d’utilisation de VirtualNetworkRouter

Mêmes réseaux virtuels sous plusieurs VNR

  • Figure 1 : Les pods VN1 et VN2 ne peuvent pas communiquer entre eux. mais VN3, VN4. Les ressources sur VN3 et VN4 peuvent également communiquer entre elles
  • Figure 2 : Création de VNR-spoke de sélection VN1, VN2, VNR-hub sélectionnant VN3, VN4, VNR-mesh sélectionnant VN3, VN4
  • Figure 3 : VNR-spoke garantit que VN1 et VN2 ne peuvent pas communiquer entre eux, VNR-hub permet à VN1, VN2 d’atteindre VN3, VN4 tandis que le maillage VNR permet de communiquer entre VN3 et VN4

Retour aux cas d’utilisation de VirtualNetworkRouter

Explication du cas d’utilisation

Cette section comprend les deux cas d’utilisation VNR suivants, ainsi que des explications de bout en bout de chaque cas d’utilisation :

Cas d’utilisation standard : un seul VNR connectant deux réseaux virtuels

Ce cas d’utilisation comprend deux VirtualNetworks (vn-1, vn-2) dans l’espace de noms ns-single-mesh. Les deux réseaux virtuels ont le . label vn: web Chacune VirtualNetwork contient un seul pod. Le VirtualNetwork vn-1 contient pod-vn-1. Le VirtualNetwork vn-2 contient pod-vn-2. Un type: mesh VNR du nom vnr-1 établit la connectivité entre les deux VirtualNetworks à l’aide de matchExpressions vn: web. Le VNR importe le RI et la table de routage vers vn-1 vn-2 et inversement. Étant vnr-1 donné qu’il s’agit d’un VNR maillé, tous les pods connectés VirtualNetworks communiquent entre eux.

Cas d’utilisation de mise à jour : un seul VNR connecte deux réseaux virtuels supplémentaires

Ce cas d’utilisation est similaire au cas d’utilisation standard, sauf que dans ce cas d’utilisation, l’utilisateur met à jour le YAML avec un VNR supplémentaire type: mesh pour connecter deux nouveaux VirtualNetworks (vn-3, vn-4) dans l’espace de noms ns-single-mesh. Le VNR affiché a le nom vnr-2 dans l’espace de noms ns-single-mesh avec matchExpressions: db, middlware. Le VirtualNetwork vn-3 label vn: db et vn-4 le label vn: middleware. En conséquence, vnr-2 importe le RI et la table de routage de vn-3 vers vn-4 et vice versa.

VirtualNetworkRouter Configuration

La section suivante fournit des informations de configuration YAML pour les ressources suivantes :

Type d’API (schéma)

VNR maillage

Ce YAML est un exemple d’un VNR maillage avec le nom vnr-1 dans l’espace de noms frontend, avec le labels vnr: web et ns: frontend. Ce VNR importe sa cible de routage vers n’importe quel VNR de l’espace de noms backend avec matchLabel vnr: db.

VNR en réseau

Ce YAML est un exemple d’un VNR en spoke dont le nom vnr-1 est dans l’espace de noms frontend avec le labels vnrgroup: spokes et ns: frontend. Ce VNR importe ses cibles de routage dans n’importe quel VNR de l’espace de noms backend avec matchLabel vnrgroup: hubs.

Hub VNR

Ce YAML est un exemple d’un VNR hub dont le nom vnr-2 est dans l’espace de noms backend avec labels vnrgroup: hubs et ns: backend. Ce VNR importe ses cibles de routage dans n’importe quel VNR de l’espace de noms frontend avec matchLabels vnrgroup: spokes.