SUR CETTE PAGE
VNR maillé qui connecte deux réseaux virtuels ou plus dans le même espace de noms
Ajouter de nouveaux réseaux virtuels dans le même espace de noms à un VNR de type maillage existant
Cas d’utilisation standard : un seul VNR connectant deux réseaux virtuels
Cas d’utilisation de mise à jour : un seul VNR connecte deux réseaux virtuels supplémentaires
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
VirtualNetworkscommuniquent entre eux. -
Hub-spoke :
VirtualNetworksconnectez-vous à deux types différents de VNR (spoke, hub).VirtualNetworksconnectés à des VNR de type spoke communiquent avecVirtualNetworksdes VNR de type hub et inversement.VirtualNetworksconnectés à des VNR en étoile ne peuvent pas communiquer avec les autresVirtualNetworksVNR 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.
Cas d’utilisation de maillage
Cas d’utilisation en étoile
VNR maillé qui connecte deux réseaux virtuels ou plus dans le même espace de noms
- 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
VirtualNetworksCloud-Native Contrail Networking. - 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.
- Figure 3 : Les pods dans VN1 se connectent aux pods dans VN2. La cible de route du VNR est
importExportedà la foisVirtualNetworks.
Ajouter de nouveaux réseaux virtuels dans le même espace de noms à un VNR de type maillage existant
- Figure 1 : Deux
VirtualNetworks(VN1, VN2) se connectent au VNR dans l’espace de noms-1. - Figure 2 : L’utilisateur crée deux nouveaux
VirtualNetworks(VN3, VN4). - Figure 3 : VN3 et VN4 se connectent au VNR. En conséquence, tous les
VirtualNetworksconnectés au VNR bénéficient d’une connectivité.
Deux VNR maillage dans le même espace de noms
- 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.
- Figure 2 : VNR-web et VNR-db communiquent entre eux.
- Figure 3 : toutes les
VirtualNetworksconnexions VNR-web et VNR-db communiquent entre elles.
Deux VNR maillage avec des espaces de noms différents
- 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.
- 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.
- Fig-3 : L’utilisateur met à jour VNR-web pour sélectionner VNR-db.
- Fig-3 : L’utilisateur met à jour VNR-db pour sélectionner VNR-web.
- 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.
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.
VNR en étoile dans différents espaces de noms
- La figure 1-Figure-3 est la même que les VNR en étoile dans le même espace de noms, sauf que VNR-spoke et VNR-hub fonctionnent dans différents espaces de noms.
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
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
apiVersion: v1
kind: Namespace
metadata:
name: ns-single-mesh
labels:
ns: ns-single-mesh
spec:
finalizers:
- kubernetes
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: Subnet
metadata:
namespace: ns-single-mesh
name: subnet-1
annotations:
core.juniper.net/display-name: subnet_vn_1
spec:
cidr: "10.10.1.0/24"
defaultGateway: 10.10.1.254
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: Subnet
metadata:
namespace: ns-single-mesh
name: subnet-2
annotations:
core.juniper.net/display-name: subnet_vn_2
spec:
cidr: "10.10.2.0/24"
defaultGateway: 10.10.2.254
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: VirtualNetwork
metadata:
namespace: ns-single-mesh
name: vn-1
annotations:
core.juniper.net/display-name: vn-1
labels:
vn: web
spec:
v4SubnetReference:
apiVersion: core.contrail.juniper.net/v1alpha1
kind: Subnet
namespace: ns-single-mesh
name: subnet-1
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: VirtualNetwork
metadata:
namespace: ns-single-mesh
name: vn-2
annotations:
core.juniper.net/display-name: vn-2
labels:
vn: web
spec:
v4SubnetReference:
apiVersion: core.contrail.juniper.net/v1alpha1
kind: Subnet
namespace: ns-single-mesh
name: subnet-2
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: VirtualNetworkRouter
metadata:
namespace: ns-single-mesh
name: vnr-1
annotations:
core.juniper.net/display-name: vnr-1
labels:
vnr: web
spec:
type: mesh
virtualNetworkSelector:
matchExpressions:
- key: vn
operator: In
values:
- web
---
apiVersion: v1
kind: Pod
metadata:
name: pod-vn-1
namespace: ns-single-mesh
annotations:
k8s.v1.cni.cncf.io/networks: vn-1
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: agent-mode
operator: NotIn
values:
- dpdk
containers:
- name: pod-vn-1
image: svl-artifactory.juniper.net/atom-docker/cn2/bazel-build/dev/google-containers/toolbox
command: ["bash","-c","while true; do sleep 60s; done"]
securityContext:
privileged: true
imagePullPolicy: IfNotPresent
restartPolicy: OnFailure
---
apiVersion: v1
kind: Pod
metadata:
name: pod-vn-2
namespace: ns-single-mesh
annotations:
k8s.v1.cni.cncf.io/networks: vn-2
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: agent-mode
operator: NotIn
values:
- dpdk
containers:
- name: pod-vn-2
image: svl-artifactory.juniper.net/atom-docker/cn2/bazel-build/dev/google-containers/toolbox
command: ["bash","-c","while true; do sleep 60s; done"]
securityContext:
privileged: true
imagePullPolicy: IfNotPresent
restartPolicy: OnFailure
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
apiVersion: v1
kind: Namespace
metadata:
name: ns-single-mesh
labels:
ns: ns-single-mesh
spec:
finalizers:
- kubernetes
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: Subnet
metadata:
namespace: ns-single-mesh
name: subnet-2
annotations:
core.juniper.net/display-name: subnet_vn_1
spec:
cidr: "10.10.3.0/24"
defaultGateway: 10.10.3.254
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: Subnet
metadata:
namespace: ns-single-mesh
name: subnet-4
annotations:
core.juniper.net/display-name: subnet_vn_2
spec:
cidr: "10.10.4.0/24"
defaultGateway: 10.10.4.254
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: VirtualNetwork
metadata:
namespace: ns-single-mesh
name: vn-3
annotations:
core.juniper.net/display-name: vn-1
labels:
vn: db
spec:
v4SubnetReference:
apiVersion: core.contrail.juniper.net/v1alpha1
kind: Subnet
namespace: ns-single-mesh
name: subnet-3
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: VirtualNetwork
metadata:
namespace: ns-single-mesh
name: vn-4
annotations:
core.juniper.net/display-name: vn-2
labels:
vn: middleware
spec:
v4SubnetReference:
apiVersion: core.contrail.juniper.net/v1alpha1
kind: Subnet
namespace: ns-single-mesh
name: subnet-4
---
apiVersion: core.contrail.juniper.net/v1alpha1
kind: VirtualNetworkRouter
metadata:
namespace: ns-single-mesh
name: vnr-2
annotations:
core.juniper.net/display-name: vnr-1
labels:
vnr: db
vnr: middleware
spec:
type: mesh
virtualNetworkSelector:
matchExpressions:
- key: vn
operator: In
values:
- db, middlware
---
apiVersion: v1
kind: Pod
metadata:
name: pod-vn-3
namespace: ns-single-mesh
annotations:
k8s.v1.cni.cncf.io/networks: vn-1
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: agent-mode
operator: NotIn
values:
- dpdk
containers:
- name: pod-vn-3
image: svl-artifactory.juniper.net/atom-docker/cn2/bazel-build/dev/google-containers/toolbox
command: ["bash","-c","while true; do sleep 60s; done"]
securityContext:
privileged: true
imagePullPolicy: IfNotPresent
restartPolicy: OnFailure
---
apiVersion: v1
kind: Pod
metadata:
name: pod-vn-4
namespace: ns-single-mesh
annotations:
k8s.v1.cni.cncf.io/networks: vn-2
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: agent-mode
operator: NotIn
values:
- dpdk
containers:
- name: pod-vn-4
image: svl-artifactory.juniper.net/atom-docker/cn2/bazel-build/dev/google-containers/toolbox
command: ["bash","-c","while true; do sleep 60s; done"]
securityContext:
privileged: true
imagePullPolicy: IfNotPresent
restartPolicy: OnFailure
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)
type VirtualNetworkRouterSpec struct {
// Common spec fields
CommonSpec `json:",inline" protobuf:"bytes,1,opt,name=commonSpec"`
// Type of VirtualNetworkRouter. valid types - mesh, spoke, hub
Type VirtualNetworkRouterType `json:"type,omitempty" protobuf:"bytes,2,opt,name=type"`
// Select VirtualNetworks to which this VNR's RT be shared
VirtualNetworkSelector *metav1.LabelSelector `json:"virtualNetworkSelector,omitempty" protobuf:"bytes,3,opt,name=virtualNetworkSelector"`
// Import Router targets from other virtualnetworkrouters
Import ImportVirtualNetworkRouter `json:"import,omitempty" protobuf:"bytes,4,opt,name=import"`
}
type ImportVirtualNetworkRouter struct {
VirtualNetworkRouters []VirtualNetworkRouterEntry `json:"virtualNetworkRouters,omitempty" protobuf:"bytes,1,opt,name=virtualNetworkRouters"`
}
type VirtualNetworkRouterEntry struct {
VirtualNetworkRouterSelector *metav1.LabelSelector `json:"virtualNetworkRouterSelector,omitempty" protobuf:"bytes,1,opt,name=virtualNetworkRouterSelector"`
NamespaceSelector *metav1.LabelSelector `json:"namespaceSelector,omitempty" protobuf:"bytes,2,opt,name=namespaceSelector"`
}
VNR maillage
apiVersion: core.contrail.juniper.net/v1alpha1
kind: VirtualNetworkRouter
metadata:
namespace: frontend
name: vnr-1
annotations:
core.juniper.net/display-name: vnr-1
labels:
vnr: web
ns: frontend
spec:
type: mesh
virtualNetworkSelector:
matchLabels:
vn: web
import:
virtualNetworkRouters:
- virtualNetworkRouterSelector:
matchLabels:
vnr: db
namespaceSelector:
matchLabels:
ns: backend
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
kind: VirtualNetworkRouter
metadata:
namespace: frontend
name: vnr-1
annotations:
core.juniper.net/display-name: vnr-1
labels:
vnrgroup: spokes
ns: frontend
spec:
type: spoke
virtualNetworkSelector:
matchLabels:
vngroup: spokes
import:
virtualNetworkRouters:
- virtualNetworkRouterSelector:
matchLabels:
vnrgroup: hubs
namespaceSelector:
matchLabels:
ns: backend
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
apiVersion: core.contrail.juniper.net/v1alpha1
kind: VirtualNetworkRouter
metadata:
namespace: backend
name: vnr-2
annotations:
core.juniper.net/display-name: vnr-2
labels:
vnrgroup: hubs
ns: backend
spec:
type: hub
virtualNetworkSelector:
matchLabels:
vngroup: hubs
import:
virtualNetworkRouters:
- virtualNetworkRouterSelector:
matchLabels:
vnrgroup: spokes
namespaceSelector:
matchLabels:
ns: frontend
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.