AUF DIESER SEITE
Mesh-VNR zur Verbindung von zwei oder mehr virtuellen Netzwerken im selben Namespace
Hinzufügen neuer virtueller Netzwerke innerhalb desselben Namespace zu einem vorhandenen Mesh-VNR
Standard-Anwendungsfall: Ein einziger VNR verbindet zwei virtuelle Netzwerke
Anwendungsfall update: Einzelne vNR verbindet zwei weitere virtuelle Netzwerke
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
VirtualNetworkskommunizieren miteinander. -
Hub-Spoke:
VirtualNetworksVerbinden Sie sich mit zwei verschiedenen VNR-Typen (Spoke, Hub).VirtualNetworksVerbunden mit Spoke-Typ-VNRs kommunizieren mitVirtualNetworksmit Hub-Typ-VNRs und umgekehrt.VirtualNetworksMit Spoke verbundene VNRs können nicht mit anderenVirtualNetworksan 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-Anwendungsfälle
Hub-Spoke-Anwendungsfälle
Mesh-VNR zur Verbindung von zwei oder mehr virtuellen Netzwerken im selben Namespace
- 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
VirtualNetworksCN2. - 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.
- Abbildung 3: Pods in VN1 verbinden sich mit Pods in VN2. Das Routenziel von VNR ist
importExportedfür beideVirtualNetworks.
Hinzufügen neuer virtueller Netzwerke innerhalb desselben Namespace zu einem vorhandenen Mesh-VNR
- Abbildung 1: Zwei
VirtualNetworks(VN1, VN2) mit VNR im Namespace-1. - Abbildung 2: Der Benutzer erstellt zwei neue
VirtualNetworks(VN3, VN4). - Abbildung 3: VN3 und VN4 verbinden sich mit VNR. Infolgedessen erhalten alle
VirtualNetworks, die mit dem VNR verbunden sind, Konnektivität.
Zwei Mesh-VNRs im selben Namespace
-
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.
-
Abbildung 1 und Abbildung 2: VNR-web und VNR-db kommunizieren miteinander.
- Abbildung 3: Alle
VirtualNetworksmit VNR-web und VNR-db verbundenen Verbindungen kommunizieren miteinander.
Zwei Mesh-VNRs mit unterschiedlichen Namespaces
-
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.
-
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.
-
Abbildung 3: Der Benutzer aktualisiert VNR-web, um VNR-db auszuwählen.
-
Abbildung 3: Der Benutzer aktualisiert VNR-db, um VNR-web auszuwählen.
-
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.
Hinweis:VNRs wählen VNs basierend auf
matchExpressionLabeln in einervirtualNetworkSelectorSpezifikation aus. In der obigen Abbildung wählt vNR-web im Namespace-1 beispielsweise VN1 und VN2 basierend auf dem Labelvn: webaus namespace-1 aus. AvirtualNetworkSelectorsucht nur nach übereinstimmenden Labeln im eigenen Namespace.
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.
Hub-and-Spoke-VNRs in verschiedenen Namespaces
-
Abbildung 1 bis Abbildung 3 ist identisch mit Hub-and-Spoke-VNRs im gleichen Namespace, mit der Ausnahme, dass VNR-Spoke und VNR-Hub in verschiedenen Namespaces arbeiten.
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.
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
apiVersion: v1
kind: Namespace
metadata:
name: ns-single-mesh
labels:
ns: ns-single-mesh
spec:
finalizers:
- kubernetes
---
apiVersion: core.contrail.juniper.net/v1
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/v1
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/v1
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/v1
kind: Subnet
namespace: ns-single-mesh
name: subnet-1
---
apiVersion: core.contrail.juniper.net/v1
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/v1
kind: Subnet
namespace: ns-single-mesh
name: subnet-2
---
apiVersion: core.contrail.juniper.net/v1
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: gcr.io/cos-cloud/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: gcr.io/cos-cloud/toolbox
command: ["bash","-c","while true; do sleep 60s; done"]
securityContext:
privileged: true
imagePullPolicy: IfNotPresent
restartPolicy: OnFailure
Dieser Anwendungsfall umfasst folgendes:
-
Zwei
VirtualNetworks(vn-1undvn-2) im Namespacens-single-mesh. Beide virtuellen Netzwerke verfügen über dielabelvn: web. JederVirtualNetworkenthält einen einzelnen Pod. DerVirtualNetworkvn-1enthältpod-vn-1. DerVirtualNetworkvn-2enthältpod-vn-2. -
Ein
type: meshVNR mit dem Namenvnr-1. Dieser VNR stellt die Konnektivität zwischen den beidenVirtualNetworksverwenden,matchExpressionsundvn: web. er VNR importiert die RI- und Routing-Tabelle vonvn-1undvn-2umgekehrt. Davnr-1es sich um einen Mesh-VNR handelt, kommunizieren alle miteinander verbundenenVirtualNetworksPods.
Anwendungsfall update: Einzelne vNR verbindet zwei weitere virtuelle Netzwerke
apiVersion: v1
kind: Namespace
metadata:
name: ns-single-mesh
labels:
ns: ns-single-mesh
spec:
finalizers:
- kubernetes
---
apiVersion: core.contrail.juniper.net/v1
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/v1
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/v1
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/v1
kind: Subnet
namespace: ns-single-mesh
name: subnet-3
---
apiVersion: core.contrail.juniper.net/v1
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/v1
kind: Subnet
namespace: ns-single-mesh
name: subnet-4
---
apiVersion: core.contrail.juniper.net/v1
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: gcr.io/cos-cloud/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: gcr.io/cos-cloud/toolbox
command: ["bash","-c","while true; do sleep 60s; done"]
securityContext:
privileged: true
imagePullPolicy: IfNotPresent
restartPolicy: OnFailure
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-2im Namespacens-single-meshmitmatchExpressions: db, middlware. -
Das
VirtualNetworkvn-3hat das Labelvn: dbundvn-4das Labelvn: 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)
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"`
}
Mesh-VNR
apiVersion: core.contrail.juniper.net/v1
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
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
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
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
apiVersion: core.contrail.juniper.net/v1
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
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.