このページの目次
クラウドネイティブのContrail NetworkingにVirtualNetworkRouterを導入する
概要 クラウドネイティブのContrail® Networking™ は、 VirtualNetworkRouter (VNR)構造をサポートします。このコンストラクトは、 VirtualNetworks間の接続を提供します。
仮想ネットワークルーターの概要
通常、 VirtualNetwork トラフィックは、テナントの分離を維持するために分離されます。クラウドネイティブのContrail Networkingでは、 VirtualNetworkRouter (VNR)がルート漏洩を実行します。ルート漏洩は、ルーティングインスタンス(RI)と、これらのインスタンスに関連付けられたルーティングテーブルをインポートすることによって、 VirtualNetworks 間の接続を確立します。その結果、あるルーティング・テーブル上のデバイスは、別のルーティング・テーブル上のデバイスからリソースにアクセスできることになります。
VNRは、次の2つの一般的なネットワークモデルに接続を提供します。
-
メッシュ: 接続されているすべてのポッド
VirtualNetworks相互に通信します。 -
ハブスポーク:
VirtualNetworks2つの異なるVNRタイプ(スポーク、ハブ)に接続します。 スポークタイプ VNR に接続されたVirtualNetworksハブタイプ VNR に接続されたVirtualNetworksと通信し、その逆も同様です。 スポーク VNR に接続されたVirtualNetworksは、スポーク VNR に接続された他のVirtualNetworksと通信できません。
VNRは、クラウドネイティブのContrail Networking内に導入されるKubernetesコンストラクトです。
仮想ネットワークルーターの使用例
次の例は、クラウドネイティブのContrail NetworkingにおけるVNRの機能を示す一般的な使用例です。
メッシュの使用例
同じ名前空間内の 2 つ以上の仮想ネットワークを接続するメッシュ VNR
- 図 1: ユーザーが名前空間 1 に VN1 と VN2 を作成する。VN1 のポッドは、VN2 のポッドに接続できません。これは、クラウドネイティブのContrail Networkingにおける
VirtualNetworksのデフォルトの動作です。 - 図 2: ユーザーは、VN1 と VN2 を選択するメッシュ タイプの VNR を定義します。この VNR により、VN1 内のポッドが VN2 内のポッドと通信したり、その逆を行ったりすることができます。
- 図 3: VN1 のポッドは VN2 のポッドに接続されています。VNRのルートターゲットは、両方の
VirtualNetworksにimportExportedされます。
同じ名前空間内の新しい仮想ネットワークを既存のメッシュタイプ VNR に追加する
- 図 1: 2 つの
VirtualNetworks(VN1、VN2) が名前空間 1 の VNR に接続します。 - 図 2: ユーザーが 2 つの新しい
VirtualNetworks(VN3、VN4) を作成します。 - 図-3:VN3とVN4はVNRに接続しています。その結果、VNRに接続
VirtualNetworksすべての人が接続を受信します。
同じ名前空間にある 2 つのメッシュ VNR
- 図 1: VNR-web と VNR-db 型が mesh-1 に既に存在します。それぞれのVNRに接続されたVNRのみが相互に通信します。
- 図-2: VNR-web と VNR-db は相互に通信します。
- 図-3:VNR-webとVNR-dbの両方に接続されているすべての
VirtualNetworks相互に通信します。
異なる名前空間を持つ 2 つのメッシュ VNR
- 図-1: VNR-webはVN1とVN2を選択します。VN1 と VN2 のポッドは相互に通信します。VN1 および VN2 は、VN3 および VN4 と通信できません。
- 図-2: VNR-db は VN3 と VN4 を選択します。VN3 と VN4 のポッドは相互に通信します。VN3 および VN4 は、VN1 および VN2 と通信できません。
- 図-3: ユーザーが VNR-web を更新して VNR-db を選択します。
- 図-3: ユーザーが VNR-db を更新して VNR-web を選択します。
- 図-3:2つのVNRが互いに選択し合うため、VNR-webのRT(ルートターゲット)がVN3とVN4に追加されます。VNR-dbのRTがVN1とVN2に追加されます。VN1、VN2、VN3、VN4 のポッドは相互に通信します。
同じ名前空間内のハブ アンド スポーク VNR
- 図 1: VN1 のポッドは VN2 のポッドと通信できません。VN1 および VN2 は VN3 と通信できません。
- 図-2: ユーザーは、「スポーク」および「ハブ」タイプのVNRを作成します。VNRスポークとVNRハブは互いのRTをインポートします。
- 図 3: VNR スポークと VNR-hub の RT は互いの RT をインポートするため、VN1、VN2、VN3 に追加されます。その結果、VN1 と VN2 のポッドは VN3 と通信します。VN1 と VN2 のポッドは通信できません。
複数のVNRの下にある同じ仮想ネットワーク
- 図 1: VN1 と VN2 のポッドは相互に通信できません。しかしVN3、VN4。また、VN3、VN4上のリソースは相互に通信できます
- 図 2: VN1、VN2、VN3、VN4、VN4を選択するVNRハブを選択するVNRスポークを作成する
- 図-3:VNRスポークはVN1、VN2が相互に通信できないようにし、VNRハブはVN1、VN2をVN3、VN4に到達させ、VNRメッシュはVN3、VN4間の通信を可能にする
ユースケースの説明
このセクションでは、次の 2 つの VNR ユース ケースと、各ユース ケースのエンドツーエンドの説明で構成されています。
標準的な使用例:2 つの仮想ネットワークを接続する単一の VNR
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
このユース ケースは、名前空間 ns-single-mesh の 2 つのVirtualNetworks (vn-1、vn-2) で構成されます。どちらの仮想ネットワークにもlabel vn: webがあります。各VirtualNetworkには 1 つのポッドが含まれています。VirtualNetwork vn-1にはpod-vn-1が含まれています。VirtualNetwork vn-2にはpod-vn-2が含まれています。vnr-1という名前のtype: mesh VNRは、matchExpressions vn: webを使用して2つのVirtualNetworks間の接続を確立します。VNR は、vn-1 の RI とルーティング テーブルをvn-2にインポートし、その逆も同様です。vnr-1メッシュ型VNRであるため、コネクテッドVirtualNetworks内のすべてのポッドが相互に通信します。
更新のユースケース:2 つの追加仮想ネットワークを接続する単一の VNR
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
このユース ケースは標準のユース ケースと似ていますが、このユース ケースでは、ユーザーが追加のtype: mesh VNR で YAML を更新して、名前空間 ns-single-mesh の 2 つの新しいVirtualNetworks (vn-3、vn-4) を接続する点が異なります。表示されている VNR の名前は、名前空間 ns-single-mesh に matchExpressions: db, middlware を付けてvnr-2。VirtualNetwork vn-3 には vn: db というラベルが付き、vn-4には vn: middleware というラベルが付いています。その結果、vnr-2 は RI とvn-3のルーティング テーブルをvn-4に、またその逆をインポートします。
API の種類 (スキーマ)
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
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
この YAML は、名前空間 frontend に名前が vnr-1、labels vnr: web と ns: frontend が付いたメッシュ VNR の例です。このVNRは、matchLabel vnr: dbでbackendネームスペース内の任意のVNRにルートターゲットをインポートします。
スポーク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
この YAML は、名前空間frontendに labels vnrgroup: spokes と ns: frontend vnr-1名前を持つスポーク VNR の例です。このVNRは、matchLabel vnrgroup: hubsの付いたネームスペースbackend任意のVNRにルートターゲットをインポートします。
ハブ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
この YAML は、名前空間にvnr-2名前を持つハブ VNR の例で、labels vnrgroup: hubsと ns: backend を含むbackendです。このVNRは、matchLabels vnrgroup: spokesの付いたネームスペースfrontend任意のVNRにルートターゲットをインポートします。