Implemente VirtualNetworkRouter en Contrail Networking nativa de la nube
RESUMEN Cloud-Native Contrail® Networking™ admite la VirtualNetworkRouter construcción (VNR). Esta construcción proporciona conectividad entre VirtualNetworks.
Descripción general de VirtualNetworkRouter
Normalmente, VirtualNetwork el tráfico (VN) se aísla para mantener la separación del inquilino. En Cloud-Native Contrail Networking (CN2), VirtualNetworkRouter (VNR) realiza fugas de ruta. La fuga de ruta establece la conectividad entre VirtualNetworks la importación de instancias de enrutamiento (RI) y las tablas de enrutamiento asociadas con estas instancias. Como resultado, los dispositivos de una tabla de enrutamiento pueden acceder a los recursos de los dispositivos de otra tabla de enrutamiento.
El VNR proporciona conectividad para los siguientes dos modelos de red comunes:
-
Malla: Los podes de todos los conectados
VirtualNetworksse comunican entre sí. -
Radio concentrador:
VirtualNetworksse conecta a dos tipos de VNR diferentes (radial, concentrador).VirtualNetworksconectados a VNR de tipo radio se comunican conVirtualNetworksVNR conectados a VNR tipo hub y viceversa.VirtualNetworksconectados a VNR radiales no pueden comunicarse con otrosVirtualNetworksVNR conectados a los VNR radiales.
VNR es una construcción de Kubernetes desplegada en CN2.
Casos de uso de VirtualNetworkRouter
Los siguientes ejemplos son casos de uso comunes que demuestran la funcionalidad de VNR en CN2.
Casos de uso de malla
Casos de uso de hub-spoke
VNR de malla que conecta dos o más redes virtuales en el mismo espacio de nombres
- Figura 1: El usuario crea VN1 y VN2 en el espacio de nombres-1. Los pods en VN1 no pueden conectarse a pods en VN2. Este es el comportamiento predeterminado de
VirtualNetworksen CN2. - Figura 2: El usuario define un VNR de malla tipo que selecciona VN1 y VN2. Este VNR permite que los pods en VN1 se comuniquen con los pods en VN2 y viceversa.
- Figura 3: Los pods en VN1 se conectan a los pods en VN2. El objetivo de la ruta de VNR es
importExporteda ambosVirtualNetworks.
Agregue nuevas redes virtuales dentro del mismo espacio de nombres a un VNR de tipo de malla existente
- Figura 1: Dos
VirtualNetworks(VN1, VN2) se conectan a VNR en el espacio de nombres-1. - Figura 2: El usuario crea dos nuevos
VirtualNetworks(VN3, VN4). - Figura 3: VN3 y VN4 se conectan a VNR. Como resultado, todos los
VirtualNetworksconectados al VNR reciben conectividad.
Dos VNR de malla en el mismo espacio de nombres
-
Figura 1 y Figura 2: VNR-web y VNR-db de malla de tipo ya existen en el espacio de nombres-1. Solo los VNR conectados a los VNR respectivos se comunican entre sí.
-
Figura 1 y Figura 2: VNR-web y VNR-db se comunican entre sí.
- Figura 3: Todos los
VirtualNetworksconectados a VNR-web y VNR-db se comunican entre sí.
Dos VNR de malla con espacios de nombres diferentes
-
Figura 1: VNR-web selecciona VN1 y VN2. Los pods de VN1 y VN2 se comunican entre sí. VN1 y VN2 no pueden comunicarse con VN3 o VN4.
-
Figura 2: VNR-db selecciona VN3 y VN4. Los pods de VN3 y VN4 se comunican entre sí. VN3 y VN4 no pueden comunicarse con VN1 o VN2.
-
Figura 3: El usuario actualiza VNR-web para seleccionar VNR-db.
-
Figura 3: El usuario actualiza VNR-db para seleccionar VNR-web.
-
Figura 3: Dado que dos VNR se seleccionan entre sí, la RT (destino de ruta) de VNR-web se agrega a VN3 y VN4. El RT de VNR-db se agrega a VN1 y VN2. Los pods de VN1, VN2, VN3 y VN4 se comunican entre sí.
Nota:Los VNR seleccionan las VN según
matchExpressionlas etiquetas de unavirtualNetworkSelectorespecificación. Por ejemplo, en la ilustración anterior, VNR-web en el espacio de nombres-1 selecciona VN1 y VN2 según la etiquetavn: webdel espacio de nombres-1. AvirtualNetworkSelectorsolo busca etiquetas que coincidan dentro de su propio espacio de nombres.
VNR concentrador y radio en el espacio del mismo nombre
-
Figura 1: Los podes en VN1 no pueden comunicarse con los pods en VN2. VN1 y VN2 no pueden comunicarse con VN3.
-
Figura 2: El usuario crea un VNR de tipo "spoke" y "hub". VNR-spoke y VNR-hub importan los RT del otro.
-
Figura 3: Los RTs de radio VNR y hub de VNR se agregan a VN1, VN2 y VN3 porque importan los RT de los demás. Como resultado, los pods en VN1 y VN2 se comunican con VN3. Los pods de VN1 y VN2 no pueden comunicarse entre sí.
VNR concentrador y radial en diferentes espacios de nombres
-
Las figuras 1 a la figura 3 son iguales que los VNR concentradores y radios en el espacio de nombres del mismo nombre, con la excepción de que los radios VNR y los concentradores VNR operan en diferentes espacios de nombres.
Las mismas redes virtuales con varias VNR
-
Figura 1: Los podes de VN1 y VN2 no pueden comunicarse entre sí. También los recursos en VN3, VN4 pueden comunicarse entre sí.
-
Figura 2: Se crea un radio VNR seleccionando VN1 y VN2. Para crear un concentrador VNR, seleccione VN3 y VN4. Para crear una malla VNR, seleccione VN3 y VN4.
-
Figura 3: El radio VNR garantiza que VN1 y VN2 no puedan comunicarse entre sí, el hub de VNR permite que VN1 y VN2 alcancen VN3 y VN4, y la malla VNR permite la comunicación entre VN3 y VN4.
Explicación del caso de uso
Esta sección consta de los dos siguientes casos de uso de VNR junto con explicaciones de extremo a extremo de cada caso de uso:
Caso de uso estándar: una sola VNR que conecta dos redes virtuales
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: <image-repository>
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: <image-repository>
command: ["bash","-c","while true; do sleep 60s; done"]
securityContext:
privileged: true
imagePullPolicy: IfNotPresent
restartPolicy: OnFailure
Este caso de uso consta de lo siguiente:
-
Dos
VirtualNetworks(vn-1yvn-2) en el espacio de nombresns-single-mesh. Ambas redes virtuales tienen el .labelvn: webCadaVirtualNetworkuno contiene un único pod. ElVirtualNetworkvn-1.pod-vn-1ElVirtualNetworkvn-2.pod-vn-2 -
Un
type: meshVNR con el nombrevnr-1. Este VNR establece la conectividad entre los dosVirtualNetworksusomatchExpressionsyvn: web. he VNR importa la RI y la tabla de enrutamiento devn-1avn-2y viceversa. Dado quevnr-1es un VNR de tipo de malla, todos los pods conectadosVirtualNetworksse comunican entre sí.
Caso de uso de actualización: una sola VNR conecta dos redes virtuales adicionales
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: <image-repository>
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: <image-repository>
command: ["bash","-c","while true; do sleep 60s; done"]
securityContext:
privileged: true
imagePullPolicy: IfNotPresent
restartPolicy: OnFailure
Este caso de uso es similar al caso de uso estándar, con la excepción de que en este caso de uso el usuario actualiza el archivo YAML con un VNR adicional type: mesh para conectar dos nuevos VirtualNetworks (vn-3 y vn-4) en el espacio de nombres ns-single-mesh. Tenga en cuenta lo siguiente:
-
El VNR mostrado tiene el nombre
vnr-2en el espacio de nombresns-single-meshconmatchExpressions: db, middlware. -
El
VirtualNetworkvn-3tiene la etiquetavn: db, yvn-4tiene la etiquetavn: middleware.
Como resultado, vnr-2 importa el RI y la tabla de enrutamiento de vn-3 a vn-4 y viceversa.
Configuración de VirtualNetworkRouter
En la siguiente sección, se proporciona información de configuración de YAML para los siguientes recursos:
Tipo de API (esquema)
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 de malla
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
El archivo YAML anterior es un ejemplo de un VNR de malla con el nombre vnr-1 en el espacio de nombres frontend, con el labels vnr: web y ns: frontend. Este VNR importa su destino de ruta a cualquier VNR del espacio de nombres backend con matchLabel vnr: db.
VNR radial
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
El archivo YAML anterior es un ejemplo de un VNR radial con el nombre vnr-1 en el espacio de nombres frontend con el labels vnrgroup: spokes y ns: frontend. Este VNR importa sus destinos de ruta a cualquier VNR del espacio de nombres backend con matchLabel vnrgroup: hubs.
Concentrador 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
El archivo YAML anterior es un ejemplo de un concentrador VNR con el nombre vnr-2 en el espacio de nombres backend con labels vnrgroup: hubs y ns: backend. Este VNR importa sus destinos de ruta a cualquier VNR del espacio de nombres frontend con matchLabels vnrgroup: spokes.