前回、Kubernetes(以下k8s)のCNI(Container Network Interface)としてTungsten Fabric(OSS)/Contrail(Juniper社)をリモートラボのvLABsで触って見る方法をお伝えしました。
今回はそのつづきとして、Contrail/Tungsten Fabricでk8s Namespaceを使った場合の動作を記載します。加えて、仮想ネットワーク分割や仮想ネットワーク同士の相互接続方法についても記載しておきます。
##■k8s Namespaceとは？
k8sのNamespaceとは、同一の物理クラスター上で仮想クラスターをつくり複数のユーザーの間でクラスターリソースを分割する方法です。
同一クラスタ内で Pod や Service, Deployment, StatefulSet などを仮想的なクラスタとしてグルーピングして利用することができます。
なお、完全な分離ではないため、マルチテナント環境で、全く異なるポリシーで利用する場合は注意が必用です。マルチテナントは、CNCFのMultitenancy WGでも議論がされていますが、現在は、テナント毎にクラスタをわけてデプロイするという事もあるようです。
Namespaceの詳細は、これらを参照ください。
[kubernetes.io Namespaces]
(https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/namespaces/)
[Kubernetesベストプラクティス：Namespace]
(https://qiita.com/jackchuka/items/a1456d8cab03651ddbf8)
k8sは、初期状態で、以下3つのNamespaceが存在します。
- default：デフォルトでPODやServiceが利用するNamespace
- kube-system：Kubernetesクラスタのシステムコンポーネントやアドオン等で利用
- kube-public：全ユーザが共通して利用するConfigMapなどを配置
デフォルトでは、defaultというNamespaceを使ってPODがデプロイされることになります。
#■Contrail/TungstenFabricのNamespaceについて
Contrailでは、k8sのNamespaceをContrailのProjectとして扱います。
実現方法として、Non-Isolated NamespaceとIsolated Namespaceという2つの方法があります。
Isolated Namespaceを利用することで、異なるNamespaceでネットワークを分割し、互いに通信をさせないということができます。また、ネットワークの分割方法としては、Custom Isolated Modeとしてより詳細に各PODに異なる仮想ネットワークをアサインするということも可能です。
この3つ(Non-Isolated Namespace, Isolated Namespace, Custom Isolated Mode)の利用方法ついて記載します。また、異なる仮想ネットワーク間を通信させるためには、Contrail Network Policyを使い通信を行うことも可能なため、そちらも記載しておきます。
Contrailとk8sの動作概要としては、Contrailに関連するNamespaceやネットワークの設定はannotationで記載するのですが、contrail-kube-manager (KM) が、kube-apiserverからannotations objectを取得します。Contrail Controllerは、contrail-kube-managerはから取得した情報から各k8s NodesにデプロイされているvRouterを制御することでそれぞれのPODやServiceを制御することになります。
#■Default Mode, Non-Isolated NameSpace
デフォルトのNamespaceは、フラットなネットワークとして、NATを使わず、POD間の通信を行うことが可能となります。これを、Contrailでは、Non-Isolated Namespaceと呼びます。
Non-Isolated Namespaceで新たにNamespaceを作ってもネットワークは分割されず、どのNamespaceに属しているPODとも通信ができます。
デフォルトで用意されるPOD用のネットワーク(k8s-default-pod-network)と、Service用のネットワークがありますが、これは、default namespaceを利用することになります。
尚、ContrailのProjectの表記は、k8s cluster名とNamespace名が組み合わせて表示されることになります。k8s cluster名はデフォルトでk8sとなるため、Namespace をns-user-1とすると、 k8s-ns-user-1と表記されることになります。k8s cluster名はデプロイ時に指定することもできます。
Non-Isolated Namespaceの場合、
新たにNamespaceを作成しても、Namespaceが同一か否かに関わらず、
デフォルトの2つのネットワーク(k8s-default-pod-network, k8s-default-service-network)を利用して通信ができることになります。
後ほど記載するCustom Isolated Modeを利用し、新しい仮想ネットワークを作成する場合、Namespaceが同一か否かに関わらず、異なるネットワーク間は通信はさせず、同一仮想ネットワークのPODのみが通信をするということになります。
つまり、Non−Isolated−Namespaceの場合は、Namespaceが同一かどうかは通信の可否には関係がありません。
ちなみに、pod-networkとservice-networkは仮想ネットワークがわかれていますが、service-networkからpod-networkにあるPODに通信ができるのは、デフォルトで有効化されているContrailのNetwork Policyがお互いで通信ができるように設定されているためです。後半のContrail Network Policyにて内容記載します。
それでは、Non−Isolated−NSの作成方法と確認方法のサンプルです。
Namespace作成と確認
$ cat ns-non-isolated.yaml
kind: Namespace
apiVersion: v1
metadata:
name: ns-non-isolated
labels:
name: ns-non-isolated
$ kubectl apply -f ns-non-isolated.yaml
namespace/ns-non-isolated created
# kubectl get namespace
NAME STATUS AGE
contrail Active 254d
default Active 254d
kube-public Active 254d
kube-system Active 254d
ns-non-isolated Active 26s ←-----
POD起動用のyamlサンプル
[root@k8smaster]# cat deployment-ubuntu-pod-1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: ubuntu-pod-1
spec:
selector:
matchLabels:
app: ubuntuapp
replicas: 3
template:
metadata:
labels:
app: ubuntuapp
spec:
containers:
- name: ubuntuapp
image: ubuntu-upstart
defaultとns-non-isolatedのNamespaceでそれぞれPODを起動します。
(右スクロールで各PODのアドレスを確認
[root@k8smaster]# k apply -f deployment-ubuntu-pod-1.yaml
deployment.apps/ubuntu-pod-1 created
[root@k8smaster tsuka]# k apply -f deployment-ubuntu-pod-1.yaml -n ns-non-isolated
deployment.apps/ubuntu-pod-1 created
[root@k8smaster]# k get pods -o=wide --all-namespaces | grep ubuntu
default ubuntu-pod-1-5f46c84995-hvb87 1/1 Running 0 2m10s 10.47.255.248 k8snode2 <none>
default ubuntu-pod-1-5f46c84995-rbkdb 1/1 Running 0 2m10s 10.47.255.252 k8snode1 <none>
default ubuntu-pod-1-5f46c84995-wrwqs 1/1 Running 0 2m10s 10.47.255.249 k8snode2 <none>
ns-non-isolated ubuntu-pod-1-5f46c84995-8nwbt 1/1 Running 0 86s 10.47.255.246 k8snode2 <none> ←-----
ns-non-isolated ubuntu-pod-1-5f46c84995-gn22h 1/1 Running 0 86s 10.47.255.247 k8snode1 <none> ←-----
ns-non-isolated ubuntu-pod-1-5f46c84995-ppbwf 1/1 Running 0 86s 10.47.255.245 k8snode1 <none> ←-----
Namespaceがdefaultとns-non-isolatedとわかれていても、それぞれのPODで通信ができることを確認します。
[root@k8smaster]# k exec ubuntu-pod-1-5f46c84995-hvb87 ping 10.47.255.252
PING 10.47.255.252 (10.47.255.252) 56(84) bytes of data.
64 bytes from 10.47.255.252: icmp_seq=1 ttl=63 time=2.34 ms
[root@k8smaster]# k exec ubuntu-pod-1-5f46c84995-hvb87 ping 10.47.255.249
PING 10.47.255.249 (10.47.255.249) 56(84) bytes of data.
64 bytes from 10.47.255.249: icmp_seq=1 ttl=63 time=0.483 ms
[root@k8smaster]# k exec ubuntu-pod-1-5f46c84995-hvb87 ping 10.47.255.246
PING 10.47.255.246 (10.47.255.246) 56(84) bytes of data.
64 bytes from 10.47.255.246: icmp_seq=1 ttl=63 time=0.601 ms
[root@k8smaster]# k exec ubuntu-pod-1-5f46c84995-hvb87 ping 10.47.255.245
PING 10.47.255.245 (10.47.255.245) 56(84) bytes of data.
64 bytes from 10.47.255.245: icmp_seq=1 ttl=63 time=1.95 ms
以上のように、Non-isolatedモードの場合、Namespaceは分けてもPODやサービスネットワークは分割されていないことがわかります。
Contrail側で状態確認をすると、同一のk8s-default-pod-networkという仮想ネットワークに属しているのが確認できます。
一部Tengesten Fabric GUIのサンプルを提示
K8s-ns-nos-isolated projectのネットワークリソースには何も表示されていません。
#■Isonated Namespace
Non-Isolated Namespaceに対して、Isolated Namespacesの場合、Namespaceを分割することでネットワークも分割することができ、各Namespace毎にpod-network とservice-networkが作られます。
Isolated Namespaces で立ち上がったPODは、同じNamespaceのserviceとpodsだけ通信ができることになります。
Isolated NamespacesとしてNamespaceを作る場合は、yamlのanontationで"opencontrail.org/isolation" : "true" として定義します。
Isolated Namespaceの作成とのサンプルです。
[root@k8smaster tsuka]# cat ns-isolated.yaml
apiVersion: v1
kind: Namespace
metadata:
name: ns-isolated
annotations: {
"opencontrail.org/isolation" : "true"
}
labels:
name: ns-isolated
[root@k8smaster tsuka]# kubectl apply -f ns-isolated.yaml
namespace/ns-isolated created
[root@k8smaster tsuka]# kubectl get namespace
NAME STATUS AGE
contrail Active 254d
default Active 254d
kube-public Active 254d
kube-system Active 254d
ns-isolated Active 20s ←-----
ns-non-isolated Active 3h34m
ns-isolatedのNamespaceでPODの起動します。
(右スクロールで各PODのアドレス確認
[root@k8smaster tsuka]# kubectl apply -f deployment-ubuntu-pod-1.yaml -n ns-isolated
deployment.apps/ubuntu-pod-1 created
[root@k8smaster tsuka]# kubectl get pods -o=wide --all-namespaces | grep ubuntu
default ubuntu-pod-1-5f46c84995-hvb87 1/1 Running 0 139m 10.47.255.248 k8snode2 <none>
default ubuntu-pod-1-5f46c84995-rbkdb 1/1 Running 0 139m 10.47.255.252 k8snode1 <none>
default ubuntu-pod-1-5f46c84995-wrwqs 1/1 Running 0 139m 10.47.255.249 k8snode2 <none>
ns-isolated ubuntu-pod-1-5f46c84995-k59j4 1/1 Running 0 48s 10.47.255.244 k8snode2 <none> ←-----
ns-isolated ubuntu-pod-1-5f46c84995-mgckn 1/1 Running 0 48s 10.47.255.243 k8snode1 <none> ←-----
ns-isolated ubuntu-pod-1-5f46c84995-pqppc 1/1 Running 0 48s 10.47.255.242 k8snode2 <none> ←-----
ns-non-isolated ubuntu-pod-1-5f46c84995-8nwbt 1/1 Running 0 138m 10.47.255.246 k8snode2 <none>
ns-non-isolated ubuntu-pod-1-5f46c84995-gn22h 1/1 Running 0 138m 10.47.255.247 k8snode1 <none>
ns-non-isolated ubuntu-pod-1-5f46c84995-ppbwf 1/1 Running 0 138m 10.47.255.245 k8snode1 <none>
default namespaceのPODからpingして通信確認してみます。
同一namespaceはping可能だが、ns-isolated namespaceへのpingは不可能というのがわかります。
[root@k8smaster tsuka]# kubectl exec ubuntu-pod-1-5f46c84995-hvb87 ping 10.47.255.252
PING 10.47.255.252 (10.47.255.252) 56(84) bytes of data.
64 bytes from 10.47.255.252: icmp_seq=1 ttl=63 time=1.84 ms
[root@k8smaster tsuka]# kubectl exec ubuntu-pod-1-5f46c84995-hvb87 ping 10.47.255.244
^Z
[3]+ Stopped kubectl exec ubuntu-pod-1-5f46c84995-hvb87 ping 10.47.255.244
[root@k8smaster tsuka]# kubectl exec ubuntu-pod-1-5f46c84995-hvb87 ping 10.47.255.243
^Z
[4]+ Stopped kubectl exec ubuntu-pod-1-5f46c84995-hvb87 ping 10.47.255.243
[root@k8smaster tsuka]#
ns-isolated namespace内のPOD同士はpingはできます。
[root@k8smaster tsuka]# kubectl exec ubuntu-pod-1-5f46c84995-k59j4 ping 10.47.255.243 -n ns-isolated
PING 10.47.255.243 (10.47.255.243) 56(84) bytes of data.
64 bytes from 10.47.255.243: icmp_seq=1 ttl=63 time=2.32 ms
[root@k8smaster tsuka]# kubectl exec ubuntu-pod-1-5f46c84995-k59j4 ping 10.47.255.242 -n ns-isolated
PING 10.47.255.242 (10.47.255.242) 56(84) bytes of data.
64 bytes from 10.47.255.242: icmp_seq=1 ttl=63 time=0.434 ms
上記のようにIsolated Namespaceの場合は、Namespaceが異なるとネットワークも分割され、通信ができないということがわかりました。
Contrail側の状態確認をしてみると、新たにつくったks-ns-isolatedのNaespace/projectにもPODとServiceの2つの仮想ネットワークが作成され、k8s-ns-isolated-pod-networkにPODが属しているのが確認できます。
k8s-ns-isolated-pod-networkという仮想ネットワークにPODが属しているのが確認できます。
#■Custom Isolated Mode
Contrailの場合、Custom Isolated Modeとして、Namespaceのネットワーク分割よりもより詳細に各PODを仮想ネットワークをアサインすることもできます。
利用する仮想ネットワークは事前にContrail UIかAPIで事前に仮想ネットワークを作成しておく必要があります。
サンプルとして、REDネットワークとして100.0.0.0/24のサブネットを指定する場合のGUI設定です。
または、Multus ProjectのCustomResourceDefinition(CRD)であるNetworkAttachmentDefinitionを利用して、Kubectlで以下のように作成することでも作成することもできます。但し、name:blueで作成した場合は、Contrailでは”k8s-blue-pod-network”として作成されます。
k8s-blue-pod-networkとして2.0.0.0/24のサブネットをもつ仮想ネットワークをつくるサンプル。
[root@k8smaster tsuka]# cat vn-net2.yaml
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: blue
namespace: default
annotations:
"opencontrail.org/cidr" : "2.0.0.0/24"
"opencontrail.org/ip_fabric_snat" : "true"
"opencontrail.org/ip_fabric_forwarding" : "true"
spec:
config: '{
“cniVersion”: “0.3.0”,
"type": "contrail-k8s-cni"
}'
[root@k8smaster tsuka]# kubectl apply -f vn-blue.yaml
networkattachmentdefinition.k8s.cni.cncf.io/blue created
PODの定義ファイルのannotationで
"opencontrail.org/network: <fq_network_name>" として、
仮想ネットワークを指定することで、そのPODを特定の仮想ネットワークに属させることができます。
k8s-blue-pod-networkを利用するPODのサンプルです。
apiVersion: v1
kind: Pod
metadata:
name: ubuntuapp
labels:
app: ubuntuapp
annotations: {
"opencontrail.org/network" : '{"domain":"default-domain", "project": "k8s-defaultt", "name": "k8s-blue-pod-network"}'
}
spec:
containers:
- name: ubuntuapp
image: ubuntu-upstart
同じように"name": "RED"とした定義ファイルを用意し、それぞれでPODを起動した場合、各PODがRED(100.0.0.0/24)とk8s-blue-pod-network(2.0.0.0/24)でPODが起動しているのがわかります。
[root@k8smaster tsuka]# kubectl get pods -o=wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
ubuntuapp 1/1 Running 0 55m 2.0.0.252 k8snode2 <none>
ubuntuapp2 1/1 Running 0 4m 100.0.0.3 k8snode1 <none>
Custom Isolatedによる仮想ネットワークアサインは、Non-Isolated Namespace, Isolated-Namespaceのどちらでも利用可能となります。
Non-Isolated Namespaceを利用した場合、pod-networkとservice-networkはdefault NamespaceとNon-Isolated Namespaceで共有されることになりますが、異なる仮想ネットワークは分割され、通信ができないことになります。
k8s-vn-left-1-pod-networkを各Namespaceで作成した場合のイメージはこのようになります。
新たに追加した仮想ネットワークは各Namespaceで分割されますが、Non-Isolated-NamespaceのPODとService用のネットワークは共有化されます。
#■Contrail Network Policy
仮想ネットワークが異なるとそれぞれのネットワークは通信ができなくなりますが、Contrailの場合、Contrail Network Policyで制御することで、それぞれのネットワーク間通信を許可/拒否することができます。
最初の方で記載しましたが、各Namespaceで作成されるservice-networkからpod-networkのPODに通信ができるのは、互いで通信を可能にしているContrail network policyが有効化されているためです。
このContrail Network Policyによる各仮想ネットワークの通信の制御はk8s連携に限らずContrailの仮想ネットワークの通常オペレーションとなります。ベーシックなContrailオペレーションシナリオはこちらも参照ください。
ちなみに、同じ"Network Policy"という名称ですが、k8s Network Policiesとは別の意味です。k8s Network PoliciesとはPod間の通信や外部のエンドポイントへの通信を制御するためのリソースです。k8s network policyは、Contrailでは、Contrail Securityとして通信制御をすることが出来ます。Contrail Securityについてはまた別途記載します。
以下、REDネットワークとBlueネットワークで互いに通信をさせるための方法です。
Contrail Network Policyを何も設定してない場合、
ubuntuapp(100.0.0.3)からubuntuapp2(2.0.0.252)は通信不可ができません。
[root@k8smaster tsuka]# kubectl get pods -o=wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
ubuntuapp 1/1 Running 0 55m 100.0.0.3 k8snode2 <none>
ubuntuapp2 1/1 Running 0 4m 2.0.0.252 k8snode1 <none>
[root@k8smaster tsuka]# kubectl exec ubuntuapp ping 2.0.0.252
[11]+ Stopped kubectl exec ubuntuapp ping 2.0.0.252
そこで、双方向で通信が出来るようなContrail Network Policyを作成します。
このNetwork Policyを相互通信させたいREDとk8s-blue-pod-networkそれぞれに適用します。
仮想ネットワークが異なり、サブネットも異なりますが、通信が可能となることがわかります。
[root@k8smaster tsuka]# kubectl exec ubuntuapp ping 2.0.0.252
PING 2.0.0.252 (2.0.0.252) 56(84) bytes of data.
64 bytes from 2.0.0.252: icmp_seq=1 ttl=63 time=2.13 ms
^Z
Contrailでは各仮想ネットワーク毎にrouting-instance/VRFを持つことになりますが、REDのルーティングテーブルを見るとk8s-blue-pod-networkの経路も載ってきており、
双方のテーブルに両方の経路が確認できます。これはNetwork PolicyによりRoute Leakingをすることで通信が行えるようになったためです。
状態確認の詳細やデバッギングは、Introspectで確認することもでき、contrail-introspect-cliを使ってCLIで確認することも出来ます。
introspect-cliでREDのRouting-instanceを確認するサンプルです。
[jcluser@k8smaster contrail-introspect-cl]$ python ist.py --host 10.1.0.194 vr vrf
Introspect Host: 10.1.0.194
+--------------------------------------+---------+---------+---------+-----------+----------+--------------------------------------+
| name | ucindex | mcindex | brindex | evpnindex | vxlan_id | vn |
+--------------------------------------+---------+---------+---------+-----------+----------+--------------------------------------+
| default-domain:default-project:ip- | 0 | 0 | 0 | 0 | 0 | N/A |
| fabric:__default__ | | | | | | |
| default-domain:default-project:ip- | 1 | 1 | 1 | 1 | 2 | default-domain:default-project:ip- |
| fabric:ip-fabric | | | | | | fabric |
| default-domain:k8s-default:RED:RED | 5 | 5 | 5 | 5 | 15 | default-domain:k8s-default:RED |
| default-domain:k8s-default:k8s-blue- | 7 | 7 | 7 | 7 | 17 | default-domain:k8s-default:k8s-blue- |
| pod-network:k8s-blue-pod-network | | | | | | pod-network |
| default-domain:k8s-default:k8s- | 2 | 2 | 2 | 2 | 5 | default-domain:k8s-default:k8s- |
| default-pod-network:k8s-default-pod- | | | | | | default-pod-network |
| network | | | | | | |
| default-domain:k8s-default:k8s- | 3 | 3 | 3 | 3 | 6 | default-domain:k8s-default:k8s- |
| default-service-network:k8s-default- | | | | | | default-service-network |
| service-network | | | | | | |
| default-domain:k8s-default:k8s-net2 | 6 | 6 | 6 | 6 | 16 | default-domain:k8s-default:k8s-net2 |
| -pod-network:k8s-net2-pod-network | | | | | | -pod-network |
| default-domain:k8s-ns-isolated:k8s- | 4 | 4 | 4 | 4 | 8 | default-domain:k8s-ns-isolated:k8s- |
| ns-isolated-pod-network:k8s-ns- | | | | | | ns-isolated-pod-network |
| isolated-pod-network | | | | | | |
+--------------------------------------+---------+---------+---------+-----------+----------+--------------------------------------+
[root@k8smaster contrail-introspect-cl]# ist.py --host 10.1.0.194 vr route -v 5
Introspect Host: 10.1.0.194
2.0.0.252/32
[100.123.18.2] pref:200
to 0:50:56:a2:ca:2 via MPLSoUDP dip:10.1.0.66 sip:10.1.0.194 label:58, nh_index:24 , nh_type:tunnel, nh_policy:disabled, active_label:58, vxlan_id:0
10.96.0.1/32
[LinkLocal] pref:100
via vhost0, nh_index:11 , nh_type:receive, nh_policy:enabled, active_label:0, vxlan_id:0
100.0.0.0/24
[Local] pref:100
nh_index:1 , nh_type:discard, nh_policy:disabled, active_label:0, vxlan_id:0
100.0.0.1/32
[Local] pref:100
to 0:0:0:0:0:1 via pkt0, assigned_label:-1, nh_index:13 , nh_type:interface, nh_policy:enabled, active_label:0, vxlan_id:0
100.0.0.2/32
[Local] pref:100
to 0:0:0:0:0:1 via pkt0, assigned_label:-1, nh_index:13 , nh_type:interface, nh_policy:enabled, active_label:0, vxlan_id:0
100.0.0.3/32
[100.123.18.2] pref:200
to 2:2e:8c:1:4:cf via tapeth0-2e7ea3, assigned_label:61, nh_index:77 , nh_type:interface, nh_policy:enabled, active_label:61, vxlan_id:0
[LocalVmPort] pref:200
to 2:2e:8c:1:4:cf via tapeth0-2e7ea3, assigned_label:61, nh_index:77 , nh_type:interface, nh_policy:enabled, active_label:61, vxlan_id:0
[INET-EVPN] pref:100
nh_index:0 , nh_type:None, nh_policy:, active_label:0, vxlan_id:0
ネットワークポリシーを削除するとubuntuapp2(2.0.0.252)の経路情報はREDのrouting-tableからは削除されます。
[jcluser@k8smaster contrail-introspect-cl]$ python ist.py --host 10.1.0.194 vr route -v 5
Introspect Host: 10.1.0.194
10.96.0.1/32
[LinkLocal] pref:100
via vhost0, nh_index:11 , nh_type:receive, nh_policy:enabled, active_label:0, vxlan_id:0
100.0.0.0/24
[Local] pref:100
nh_index:1 , nh_type:discard, nh_policy:disabled, active_label:0, vxlan_id:0
100.0.0.1/32
[Local] pref:100
to 0:0:0:0:0:1 via pkt0, assigned_label:-1, nh_index:13 , nh_type:interface, nh_policy:enabled, active_label:0, vxlan_id:0
100.0.0.2/32
[Local] pref:100
to 0:0:0:0:0:1 via pkt0, assigned_label:-1, nh_index:13 , nh_type:interface, nh_policy:enabled, active_label:0, vxlan_id:0
100.0.0.3/32
[100.123.18.2] pref:200
to 2:2e:8c:1:4:cf via tapeth0-2e7ea3, assigned_label:61, nh_index:77 , nh_type:interface, nh_policy:enabled, active_label:61, vxlan_id:0
[LocalVmPort] pref:200
to 2:2e:8c:1:4:cf via tapeth0-2e7ea3, assigned_label:61, nh_index:77 , nh_type:interface, nh_policy:enabled, active_label:61, vxlan_id:0
[INET-EVPN] pref:100
nh_index:0 , nh_type:None, nh_policy:, active_label:0, vxlan_id:0
尚、仮想ネットワーク間の通信はLogical Routerという機能を使いRoute LeakingやL3 routingで各仮想ネットワークを相互接続させ通信させることもできます。
但し、Network Policyのほうが詳細な制御は可能となります。
このようにContrail NamespaceやCustom Isolationを使ってさまざまなネットワーク分轄ができるということがわかりました。
次回はContrail Security/k8s network policyかCNF Service-chainingについて記載しておこうと思います。
#■参考ドキュメント
[KB : [Contrail] Understanding namespace and isolation concepts]
(https://kb.juniper.net/InfoCenter/index?page=content&id=KB35121&cat=CONTRAIL&actp=LIST)
[Contrail Networking with Kubernetes]
(https://www.juniper.net/documentation/en_US/contrail19/topics/concept/kubernetes-cni-contrail.html)
[Contrail Namespaces and Isolation(day-one-book)]
(https://www.juniper.net/documentation/en_US/day-one-books/topics/topic-map/kubernetes-and-contrail-integration.html#id-contrail-namespaces-and-isolation)
[Contrail-controller kubernates]
(https://github.com/Juniper/contrail-controller/wiki/Kubernetes#31-default)