TungstenFabricでOpenStackとk8sをラクラク管理

© 2018 Juniper Networks
TUNGSTENFABRICで
OPENSTACKとK8Sをラクラ
ク管理
2019年7月
ジュニパーネットワークス株式会社
山下祐生

はじめに
このセッションでは下記のような人をターゲットに作っています。
• OpenStackや、k8sを導入しようとしているが、ネットワークの課題に直面している人
• OpenStackとk8sをそれぞれ使い分けて利用しようとしている人
• TungstenFabricに興味津々な人

自己紹介
山下祐生:
- 所属: Juniper Networks
- 好きなもの: ウイスキーとオンプレミス
}

自己紹介

このセッションの目標

ところで…

どちらにフォーカスしてますか？
• OpenStack
• K8s
• それとも…tungstenfabric?

k8sとOpenStackと私

K8SとOPENSTACKと私
k8sと私
• 初めてのkubernetesはGKE (この時はOpenStack on GKEを試していた)
• 残りは素kubernetesと、kubernetes with tungstenfabricを触れた程度
OpenStackと私
• 大学の研究室時代に初めてESSEXリリースを使い始める
• Sier時代に色んなOpenStackディストリビューションを経験
• MAAS/Juju, RHEL OSP, Mirantis Fuel, Kolla, OpenStack-Helm
• 今ではVMを立てる基盤としてサーバーが5台あればOpenStackでいいのでは？
と思っている

OpenStackとk8s
復習

OPENSTACKとは？
OpenStackはPrivate Cloudを誰でも始めることができるためのOSS
Cloud事業者に必要な機能といえば…

OPENSTACKとは？
OpenStackはPrivate Cloudを誰でも始めることができるためのOSS
Cloud事業者に必要な機能といえば…
• ユーザ毎にそれぞれのダッシュボードが表示される機能 - マルチテナンシー
• 好きなIP subnetが利用できる - ネットワークマルチテナンシー
• 物理計算ノードを意識しないでVMが利用できる - スケジューラ
• APIとバックエンドが分離している - Plugin architecture
• クラスタをスケールアウトしていくことが可能 - Micro architecture

K8Sとは？
アプリケーションを柔軟にリリースするためのコンテナオーケストレーター
柔軟にリリースするために必要な機能といえば…

K8Sとは？
アプリケーションを柔軟にリリースするためのコンテナオーケストレーター
柔軟にリリースするために必要な機能といえば…
• ユーザ毎にそれぞれのダッシュボードが表示される機能 - マルチテナンシー
• Release/Role backをすることができる - リリース管理
• Auto healingができる - Health check
• 物理計算ノードを意識しないでコンテナが利用できる - スケジューラ
• APIとバックエンドが分離している - Plugin architecture
• クラスタをスケールアウトしていくことが可能 - Micro architecture

OPENSTACKとK8Sの個人的な使い分け
VM:
• HostOSとの分離がOSレベルで可能
• 起動時間がコンテナに比べて遅い
• 使い分けとしてはVNFや、パフォーマンスが要求されるDBなど
コンテナ:
• Kernelを共有しているがNameSpaceを利用してストレージ,NWを分離
• 起動時間がVMに比べてとても高速
• 使い分けとしてはスケールアウトするアプリケーションや頻繁にリ
リースをする自社開発しているアプリケーション

GKEが私に教えてくれた
たった一つのこと

GKEが私に教えてくれたたった一つのこと
オンプレkubernetesは辛い

蛇足: GKEは便利
• GCRでContainer Registryが提供されている
• Type: LoadBalancerで外部接続が簡単にできる
• PODに割り当てるPersistent Volumeのサービスが提供されている
• クラスタも一瞬でDeployできる
• CI/CDも簡単に回せる
• スケールアウトも簡単にできる

なぜ辛いか？
• コンテナにPersistent volumeをアタッチするためのStorageを提供する
のが大変
• CSI をどうするか？
• コンテナに外からアクセスするために構成を考えなければならない
• CNIをどうするか？
• Container registoryや、CI/CDを回すための基盤を提供するリソース
• 周辺のサービスをどうやって整えるか？

＿人人人人人人人人人人人人＿
＞オンプレLove突然の死＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣

＿人人人人人人人人人人人人＿
＞オンプレLove突然の死＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣
ここでくじけるオンプレLoveじゃない！

GKEを参考にしてオンプレ
k8sの構成を考える

GKEを参考にしてオンプレK8Sの構成を考える~1~
まず以下の条件はクリアしたい
• Container Registryをk8sからアクセス可能なところに配置できる
• K8sシステムからのリーチャビリティの提供、基盤でCNIを提供する
• PODへの外部接続を提供する
• コンテナで動かすべきアプリと、VMで提供すべきアプリをそれぞ
れ用意して接続できるようにすべき
• K8sが具備しているCSIを基盤で提供する

• k8sのデプロイを簡単にできるようにする
• スケールアウトをするための機能を持っている基盤
• ハイパースケールのできる基盤
• オンプレ前提であればハイパースケールできないとオンプレのコス
トメリットがでない

GKEを参考にしてオンプレK8Sの構成を考える

K8S ON OPENSTACK
•NovaAPI
•Glance
•Keystone
•Neutrone/kuryr
•Cinder
•Heat
OVS/Bridge OVS/Bridge
nginx nginx
OVS/BR OVS/BR
OVS/Bridge
・APIServer
・Controller
・Scheduler
・APIServer
・Controller
・Scheduler
•Novacompute
•Neutronagent
OVS/Bridge
•NeutronGW
•Novacompute
•Neutronagent
•Novacompute
•Neutronagent
Jenkins
registory
mysql
rails rails

• Container Registryをk8sからアクセス可能なところに配置できる
• K8sシステムからRegistryへのリーチャビリティの提供
-> VMでregistryを構築、kuryrによりk8sからのアクセスを実現
• PODへの外部接続を提供する
• コンテナで動かすべきアプリと、VMで提供すべきアプリをそれぞ
れ用意して接続できるようにすべき
-> type: LoadBalancerでneutronを利用して実現
• K8sが具備しているCSIを基盤で提供する
-> k8sが提供しているCSIでCinderを利用し実現

• k8sのデプロイを簡単にできるようにする
-> openstack-heat kubernetesで実現
• スケールアウトをするための機能を持っている基盤
-> openstack-heat kubernetesで実現
• ハイパースケールのできる基盤
• オンプレ前提であればハイパースケールできないとオンプレのコス
トメリットがでない
-> OpenStackでのハイパースケールにはナレッジが必要(特に
Neutron)

K8S ON OPENSTACK
•NovaAPI
•Glance
•Keystone
•Neutrone/kuryr
•Cinder
•Heat
OVS/Bridge OVS/Bridge
nginx nginx
OVS/BR OVS/BR
OVS/Bridge
・APIServer
・Controller
・Scheduler
・APIServer
・Controller
・Scheduler
•Novacompute
•Neutronagent
OVS/Bridge
•NeutronGW
•Novacompute
•Neutronagent
•Novacompute
•Neutronagent
Jenkins
registory
mysql
rails rails
Kuryr
ボトルネックだが、
DVRはしたくない
…

K8S ON OPENSTACKまとめ
• どれも課題になりそうなものはOpenStack側で提供されているので機
能としてはすでにReadyに思える
• GKEやAKSもVMとして提供されているのでカリッカリのパフォーマン
スをとるよりかはスケールアウトができることや、構築が簡単な柔軟
性を取った方が良さそう
• オンプレミスはまだ負けていない！

OpenStack & k8s
ネットワーク
復習

• FLAT
– 非常にシンプルな構成、FLATなのでVirtualRouterも必要が無い
– マルチテナンシーがなく、ネットワークの数だけNICが必要になる
• VLAN
– 一番実績のある構成、セグメント数がVlan数の上限を超える場合は利用できないので中規模環境向け
• VXLAN
– VXLANのMTUサイズが1500を超えるのでMTUサイズを要変更(1550byte)
– また、オフロードNICがない場合は大抵ロングパケットでも4Gbpsで頭打ちする
– VXLANを選択するときはMellanox やEmulex、Qlogic、Intelなどが必須
– 内部Vlanの上限があるため、4096以上のテナントネットワークが必要な場合はネットワークノードのス
ケールが必要となる
– VXLANの利点であるVLAN4096突破には2台以上のネットワークノードが必要、冗長性考えるなら3台以
上になる
• 考慮点
– 冗長構成の場合L3-HAを使用することになり、L3HAをした時にVRRPの通信用テナントネットワークをテ
ナントごとに1つ作るので、内部VLANをいくつ利用するかは要検討
OpenStackネットワークタイプの選択

• OpenvSwitch
– OpenStack環境では実績が多く、一般的に利用されている
– ハイトラフィック環境ではLinuxBridgeよりも多くCPUを使う
– 高速化技術のDPDKが利用可能
– SecurityGroup(iptables)の機能がOVSのポートに対しては適用できないため、
SecurityGroup使う場合は、LinuxBridgeを排除することはできない
• SecuritieGroupをOFFにすることで、LinuxBridgeの排除が可能、NFVをなどで用いられる
• LinuxBridge
– レガシーな技術ではあるが、シビアなところでパフォーマンスを求めるお客様
が使われることが多い
– Bridgeの段数が減るのでOVSより僅かにパフォーマンスが良い
– OVSではサポートしていないQinQがLinuxBridgeでは利用可能なため、インス
タンスがTag付きパケットを出したいという要件がある場合に有効
仮想スイッチの選択

VirtualRouterやDHCPの利用は各テナント毎に設定が可能であるが、前述の通り用途を絞ってOpenStack
環境を構成した方が使い方に特化したカスタマイズが可能なので共存させない方が良い
• VR、DHCP利用
– VR、DHCPがいることで、インスタンスは起動とともにネットワークの疎通が可能になる
– 外に対しての通信もVRがNATすることで可能、外からのアクセスもFlotingIPの設定をすることで可能
– ネットワーク構成もOpenStackとして一般的な形になる
• DHCPのみ利用
– VRがいないので上位SWがGWになる必要がある
– HWのSWに直接つなぐ構成になるのでネットワークパフォーマンスが大幅に良くなる
– neutronコマンドを使ってVLANタグ(もしくはVXLAN)を指定した形でのネットワーク作成を行わなければならない
– テナントネットワークを作成する度に、上位SW側でVLANタグ(VXLAN)を受けるためのケアをしなければならない
– テナント間でのIP被り、VLAN被りが許容されなくなるので、意識して設計する必要がある
• VR,DHCPを利用しない
– NFVなどの特殊要件向け
– Metadataサーバとの接続ができなくなるため、Cloud-initを使ったconfigurationが行えない
– 基本は利用しない、本当にシビアなネットワーク要件が求められた時のみ使用
OpenStackネットワーク構成の選択

Linux Bridge + Flat
VM VM VM VM
brqxxx
ethx
Tap Tap Tap Tap
Vlan Dev
Linux Bridge
Tap Dev
Instance
OVS
Veth pair
凡例
コンピュートノード

Linux Bridge + vlan
Tap Tap Tap Tap
外部Tag付与
40Ethx.50ethx.40
ethx
50
VM VM VM VM
40 50Vlan Dev
Linux Bridge
Tap Dev
Instance
OVS
Veth pair
凡例
brqxxxbrqxxx

OVS + flat
ethx
Tap Tap Tap Tap
qbr qbr qbrqbr
VM VM VM VM
br-int
br-ethx
qvo qvo qvo qvo
qvb qvb qvb qvb
phy-br-ethx
int-br-ethx
Vlan Dev
Linux Bridge
Tap Dev
Instance
OVS
Veth pair
凡例

OVS + vlan
ethx
Tap Tap Tap Tap
qbr qbr qbrqbr
VM VM VM VM
phy-br-ethx
br-int
br-ethx
qvo qvo qvo qvo
外部Tag付与
40 50
int-br-ethx
qvb qvb qvb qvb
Vlan Dev
Linux Bridge
Tap Dev
Instance
OVS
Veth pair
凡例
40 50
Networknode
1 2
内部Tag付与
br-int

OVS + Vlan全体像
https://getpocket.com/a/read/958149305より引用

OVS + VXLAN全体像
http://www.cnblogs.com/starof/p/4223979.htmlより引用

ネットワークタイプ、仮想スイッチ、ネットワーク構成を決定するにあたっては用途によって決定す
ることが出来る
• IAAS基盤
– ネットワークのパフォーマンスよりも、SecurityGroup、マルチテナンシー、収容数が優先される
– ネットワークタイプ+仮想スイッチ：OVS+VXLAN or OVS+VLAN
– ネットワーク構成：VR、DHCP、L3-HA or DVR(オプションでLbaasとFWaaS)
– チューニング：特になし
• 大容量WEBコンテンツ配信
– ロングパケットでのスループットが求められる場合は、構成を決め打ちし、最低限スケールアウト出来る用に組む
– ネットワークタイプ+仮想スイッチ：OVS+VLAN or LinuxBridge+VLAN
– ネットワーク構成：DHCP
– チューニング：SecurityGroupをOFFにすることでLinuxBridgeを排除する工夫が可能
• NFV基盤
– ネットワークパフォーマンスが極限まで求められるので、機能を削っても速度の出る構成を組むべきである
– ネットワークタイプ+仮想スイッチ：OVS+VLAN OVS+FLAT
– ネットワーク構成：何も利用しない
– チューニング：インスタンス及び、NetworkNodeにDPDK及び、SR-IOVの適用
ネットワークタイプのユースケース

今回のユースケースでのk8s networking

K8S ON OPENSTACKまとめ -再掲-
• どれも課題になりそうなものはOpenStack側で提供されているので機
能としてはすでにReadyに思える
• GKEやAKSもVMとして提供されているのでカリッカリのパフォーマン
スをとるよりかはスケールアウトができることや、構築が簡単な柔軟
性を取った方が良さそう
• オンプレミスはまだ負けていない！

本音:
理論上はできるけどNW複雑すぎやろ…
構築できるけど、運用したくない典型

k8s on OpenStackのネットワークで抱える課題
• Kuryrのデバッグが大変そう
• 外部接続に為にLBAASも必要
• Neutron GWのボトルネック
• DVRは嫌なので、ボトルネックを解消しようと思うならNeutron
GWを立てないか、Neutron GWのDPDK化？
• Neutron GWを利用しないとSWのconfigurationが必要になる
• スケールアウト問題
• ハイパースケールを目指すならNeutron GWとVXLANを使うべき
か

tungstenfabricならその悩みは必要ない！！

TungstenFabric Networking

TUNGSTEN FABRIC
• tungsten fabric はLinux Foundation配下にあるSDNのプロジェクト
• 大元はContrail Systemsが開発していたOpenSourceのOpenContrailプロジェクト
• MPLSとBGPを利用している唯一のSDNプロダクト

tungstenfabricで実現できる
こと

CONTRAIL KEY TERMINOLOGY
VN
VN
VN
Virtual Machines/Container
ネットワークマルチテナンシーをVM/Containerに対して提供する
Service ChainでFWを経由してVirtual Network同士をつなげることもできる
Virtual Networks
Virtual NetworkをそれぞれVRFとして提供し、VM/Containerを接続する
NeutronのVirtual Router機能をVRF間でルートリークすることで異なる
Virtual Network間を接続することも可能
Gateway Devices
Virtual Networkとphysical networkをGateway Deviceを利用してつなぐこ
とが可能
VM C

CONTRAIL KEY TERMINOLOGY
Virtual Network Policies
ポリシーに応じてVirtual Network間を接続することも可能
VM VM VM
Green
Virtual Network
VM VM VM
Red
Virtual Network
Policy
only HTTP
NAT

INTEGRATION WITH VM,CONTAINER AND BMS
Green Virtual
Network
(RT = G)
VM
1
VM
2
Blue Virtual
Network
(RT = B)
LOGICALPHYSICAL
Bare Metal Server Integration (using
vRouter) achieved through:
 L2 / L3 Gateway
 Containers Docker / LXC
 Smart NIC
VN Green
(RT = G)
VM
1
VM
2
… VLAN
VN Blue
(RT = B)
VM
3
VM
3
VRF
(RT=B
)
IP Fabric
C1
C
2
C
1
C
2
C
3
Containers
C
3

Gateway Router
… N
GROW SCALABILITY WITH SIMPLE WAY
Leaf IP Switches
Spine IP Switches
… N
… M
Easy to manage
Backplane bandwidth
Add ToR switch to
expand ports
ECMP load
balancing
Easy to expand GW
bandwidth
Internet / L3VPN / EVPN

GROW SCALABILITY WITH SIMPLE WAY

▪ IPv4, v6
▪ Container networking
▪ Default Cluster mode
▪ Network Isolation
▪ Custom Network Support (for
Ingress)
Routing &
Switching
▪ Floating IP
▪ Distributed SNAT
▪ Service isolation
through VRF
▪ DHCP/IPAM
Network
Services
▪ Customizable ECMP
▪ Ingress with HAproxy, with
UI
▪ Multi Ingress
▪ NodePort
▪ Integ. with F5, AVI, etc.
Load
Balancing
▪ Network Policy & Security
Groups
▪ XMPP Encryp., Data
Plane Encryption
Infra Security
& Policies
▪ Public Cloud connectivity
(through VPC APIs, *
▪ Gateway Less Support
Gateway
Services
▪ Alerts
▪ Multi-region analytics,
▪ Anomaly detection
Analytics &
Reporting
▪ Infra Failover, ISSU
▪ Provisioning using Ansible,
Single YAML
HA, Upgrades,
& Provisioning
▪ Multi-vendor Orch. – K8’s
,Openshift , Nested Mode
▪ Registry
APIs &
Orchestration
Contrail Networking Features

tungstenfabric Architecture

MPLS L3VPN / E-VPN tungstenfabric
P PPE PE
Route
Reflecto
r
Route
Reflecto
r
CECE
Underlay
Switch
vRouter
Control
Node
Control
Node
Underlay
Switch
VM
VM
VM
VM
vRouterVM VM
IBGP
IBGP
IBGP
XMPP
MPLS over
MPLS
MPLS over GRE or VXLAN
Network Management System (NMS)
DMI
Config
Node
Orchestrator
Analytics
Node
SDN
System
MPLS/L3VPNベースのアーキテクチャをそのまま持ち込んだモデル
draft-ietf-l3vpn-end-system
TUNGSTENFABRIV ARCHITECTURE

Physical IP Fabric
(no changes)
CONTRAIL
CONTROLLER
ORCHESTRATOR
Host O/SvRouter
Network / Storage
orchestration
Gateway
…
Internet /
WAN or
Legacy Env.
(Config, Control, Analytics, Svr Mgmt)
(Windows, Linux ….) on BMS
TOR
Compute
orchestration
Virtual
Network Blue
Virtual
Network Red
FW
Logical View
…
Centralized
PolicyDefinition
Distributed
PolicyEnforcement
BGP
BGP XMPPOVSDB
tungstenfabric Architecture

• マルチベンダのオーケストレータに対応
• Plugin形式でネットワークを制御、構築
– OpenStack Neutron Plugin
– VMware vCenter Plugin
– K8s CNI plugin
:
BASIC ARCHITECTURE

OPENSTACK & CONTRAILでのVMを作った時のフロー
Horizon UI
Contrail Web UI
Nova
(Compute Orchestration)
Neutron Plugin
Compute Node
Storage
Keystone
(Identity / Access
Mgmt)
Cinder
(Block Storage)
Swift
(Object Storage)
Nova Agent
Contrail Agent
Contrail Config
Contrail Control
vRouter
Operator
User Logs in, Create tenant
(projects), Create IPAM, Create
virtual network, Launch VMs
VM
Get VM Image to
spawn
API
Srvr
Scheduler …
Select Compute node
to spawn VM
Info to
spawn VM
Hypervisor
VM Spawned
Block Storage
Assignment
Xen
Bi-directional message bus
(XMPP interaction)
Launch VM
Network related interaction
Get virtual network info
DHCP
Plug (Tap interface, Instance ID, ..)
Glance
(Image Server)
Authentication, etc.

kubectl
(user
commands)
PODKubelet
vRouter
CNI
vRouter Agent
Kube-api
Contrail
Kube-Manager
Stream API
Update
Contrail
Controller
Build configurations
Launch POD
Retrieve configurations
Plug POD to VRouter
Master Slave
K8S & CONTRAILでのVMを作った時のフロー

今回紹介したい目玉機能

K8S ON OPENSTACK WITH CONTRAIL ARCHITECTURE
Kuberenetes Cluster on OpenStack
TF vRouter
K8s on OpenStackの構成の場合はVMにvRouterを配置し
ない、また同じようにSDNコントローラーもk8sクラス
ターには配置せず、Masterノードにkubemanager、
workerノードにCNIのみを配置する
kube-managerはOpenstack Neutron Pluginで動作する
TF Controllerをcallし、CNIはコンピュートノード上の
TF agentをcallする
このNested modeを使うことによってVM上で複数の
TF Controllerや TF agentが実行されるのを避けること
ができる
•Controller
•Analytics
•Analytics-DB
•NovaAPI
•Glance
•Keystone
•Neutron
Agent
・APIServer
kube-
manager
kubelet
CNI
bridge
pod
pod
vlan
vlan

Data Plane/Control Plane
アーキテクチャ

COMPUTE NODE – CONTRAIL VROUTER
Compute Node
Virtual
Machine
(Tenant B)
Virtual
Machine
(Tenant C)
Virtual
Machine
(Tenant C)
vRouter Forwarding Plane
Virtual
Machine
(Tenant A)
Routing
Instance
(Tenant A)
Routing
Instance
(Tenant B)
Routing
Instance
(Tenant C)
vRouter Agent
Flow Table
FIB
Flow Table
FIB
Flow Table
FIB
Overlay tunnels
MPLS over GRE or VXLAN
JUNOSV CONTRAIL CONTROLLER
CONTRAIL CONTROLLER
XMPP
Eth1Kernel
Tap Interfaces (vif)
pkt0
User
Eth0 EthN
Config
VRFs
Policy
Table
Top of Rack Switch
XMPP
• vRouterはハイパーバイザーカーネルの中の
Linux Bridge もしくは、OVSをリプレースする
役割を持つ
• vRouterはBridgingもしくはRouting(MPLS
base L3VPN)を提供する。
• vRouterはSecurity Policies, NAT, Multicast,
Mirroring, and Load Balancingのネットワーク
サービスを提供する
• Routing, Broadcast/Multicast, NATを提供する
為のService NodeやL2/L3GWがいらない
• ポリシーに基づいて、ルートは自動的にVRFに
リークされる

CONTROL PLANE – ROUTE DISTRIBUTION
10.1.1.1 10.1.1.2
70.10.10.1 151.10.10.1
10.1.1.2: NH = 151.10.10.1; LBL = 17 10.1.1.1: NH = 70.10.10.1; LBL = 39
10.1.1.110.1.1.2 PAYLOAD
VRF
PriSrcIPPriDstIP
10.1.1.110.1.1.2 PAYLOADLBL=17GRE70.10.10.1151.10.10.1
PubSrcIPPubDstIP
VM1
VRF
PriSrcIPPriDstIP
10.1.1.110.1.1.2 PAYLOAD
PriSrcIPPriDstIP
VM2
IP Network
Agent Agent
XMPP XMPP
Control Node
Configuration Node
REST/API
10.1.1.2:NH = 151.10.10.1; LBL = 17 10.1.1.1:NH = 70.10.10.1; LBL = 39
(Dynamic Tunnel Encapsulation) (Dynamic Tunnel Decapsulation)
Server 1 Server 2
Control Plane
*Outer MAC header was left out intentionally to reduce clutter
10.1.1.1:NH = 70.10.10.1; LBL = 39 10.1.1.2:NH = 151.10.10.1; LBL = 17
Control Plane
Cassandra

ルーティングの仕組み

CONTROL PLANE – ROUTE DISTRIBUTION
VM VM
Virtual
Network
Virtual Network
Tenant Virtual Machines
Dst Next Hop
G1 VIF – tap-
1
G2 S2  L6
VM
G1
Server S1
vRouter Agent
VRF GREEN VN : LABEL 2
vRouter
Forwarding Plane
VM
G2
Server S2
vRouter Agent
VRF GREEN VN : LABEL 6
vRouter
Forwarding Plane
Dst Next Hop
G1 S1  L2
G2 VIF
Orchestrator
Configuration
Control
1. コンピュートノードS1上にVM-G1を作成.XMPPプロトコルを経由してVM
のインターフェイスやルート情報を決定
2. BGPまたはXMPPを経由してコントロールノード上で受信したルート情報
はXMPPで各コンピュートノード上のvRouterへルート情報を送る
3. コンピュートノード上のvRouterはXMPPを受けとったのちVRFへ書き込
む
4. 同様の処理を各コンピュートノードで行う

VROUTERルーティングの仕組み
• 仮想ネットワーク間ルーティング
VNIごとにルーティングインスタンスを作成(domain_name:project_name:virtualnetwork_name)
VN Greenから VN Red の経路情報を追加した場合、Route Leakを使用
vRouter
1 2
VM
G1
VM
G2
VM
R1
VM
R2
VM
G1
VM
G2
VM
G3
Green
Virtual Network
VM
R1
VM
R2
VM
R3
Red
Virtual Network
RT:64512:800001
172.16.1.0/24
172.16.1.2 NH: Comp1 L:1
172.16.1.3 NH: Comp2 L:2
RT:64512:800002
172.16.2.2 NH: Comp1 L:3
172.16.2.3 NH: Comp2 L:4
RT:64512:800002
172.16.2.0/24
172.16.2.2 NH: Comp1 L:3
172.16.2.3 NH: Comp2 L:4
RT:64512:800001
172.16.1.2 NH: Comp1 L:1
172.16.1.3 NH: Comp2 L:2
Route Leak
172.16.1.0
172.16.2.0

ROUTE DISTRIBUTION - EXAMPLE
• On Contrail Web UI, VRF of virtual network "front-end".
• On Contrail Web UI, VRF of virtual network "back-end".

外部GW接続の仕組み

Contrail
Controller
VM
R1
VM
R2
BGP
L3VPN
Overlay Tunnel
MPLS/GRE
Route
Reflector
LSP (RSVP, LDP)
BGP
Gateway Router (PE Router)
OpenStack
GWはvirtual Networkとphysical networkを接続する役割を持っている
コントロールプレーンの上ではGatewayとController nodesの間でMP-BGPがはられて
いる
データプレーンのパケットははMPLS over GRE or MPLS over VXLAN, VXLANでエン
キャプスレーションされている
GWはvirtulal networkを他のデータセンターまで延伸する時や、Floating IPをサポート
する時、VMたちへのvirtual networkからphysical nertworkへのリーチャビリティを与え
るときに必要になる
tungstenfabricはMP-BGP,MPLS over GRE/VXLANなどのジェネラルなProtocolを
使っている為、Gateway RouterはMP-BGP/MPLS/GRE or VXLANをサポートしてい
る機器であればなんでも使うことができる
GATEWAY TO L3VPN

• ComputeノードS1(vRouter)はControl nodeに対してRouteを送信する
• ControlはGatewayも含む全てBGP peerに対してRouteをdistributeする
• ゲートウェイはルートを受信し、ルートターゲットによって正しいVRFを見つけ、動的GRE
トンネルを割り当てる
Physical
L3VPN
Red
Virtual Network
VM VM VM VM
Dst Next Hop
R1 VIF – tap-
1
R2 S2  L6
VM
R1
Server S1
vRouter Agent
VRF RED VN : LABEL 2
target:64512:10000
vRouter
Forwarding Plane
Control
Control
VRF RED VN :
target:64512:10000
Physical Gateway e.g. MX
Dst Next Hop
R1 gr-0/0/0.32110
R2 gr-0/0/0.32112
GATEWAY - CONTROL PLANE

• データパケットはゲートウェイのVRF RED VNに転送される
• パケットはカプセル化され、GREトンネルを通って、コンピュートS1に送信される
• コンピュートS1はパケットを受信し、デキャップ(GREトンネルとMPLSラベル)しVM-R1に
送信する
Physical
L3VPN
Red
Virtual Network
VM VM VM VM
Dst Next Hop
R1 VIF – tap-
1
R2 S2  L6
VM
R1
Server S1
vRouter Agent
VRF RED VN : LABEL 2
target:64512:10000
vRouter
Forwarding Plane
Control
Control
VRF RED VN :
target:64512:10000
Physical Gateway e.g. MX
Dst Next Hop
R1 gr-0/0/0.32110
R2 gr-0/0/0.32112
GATEWAY – DATA PLANE

Kubernetes Network
“Extention”

TUNGSTENFABRICのネットワーク WITH K8S
• 専用の POD Network
mysq
l
nginx nginxmysq
l
192.168.10.0/24
Tenant: A
apiVersion: v1
kind: Pod
metadata:
name: mysql
annotations: {
"opencontrail.org/network" : '{"domain":"default-domain",
"project": ”user1", "name":”pod-vn1"}'
}
labels:
name: db
spec:
containers:
- name: mysql-gA
image: mysql
TungstenfabricではAnnotationとしてtungstenfabric
の仮想ネットワークをPODに割り当てることが可
能
この仮想ネットワークはVNI/Route targetを持って
いる為、先ほど説明した外部GW接続の仕組み
を利用して、physical networkとの接続が可能

TUNGSTENFABRICのネットワーク WITH K8S
• IPOD Network間接続
mysq
l
nginx nginxmysq
l
192.168.10.0/24
異なるPODネットワーク間の通信を許可するには
tungstenfabricのFW Policyでの許可が必要
通常のkube-proxyではHTTP/HTTPSのみの制御にな
るが、tungstenfabricではその他のトラフィックも
制御可能
5 TupleでPOD間を制御できる為、既存ネットワー
ク設計のように管理することが可能
192.168.20.0/24

PODを外部ネットワークへダイレクト接続
• Connect POD from External Network
外部からPODに接続することは通常不可能だが、
tungstenfabricはPODのインターフェイスに対して、
Floatiing IPを割り当てることで特定のPODに対し
て直接外部からアクセスが可能
この機能は特定のPODで起きた障害のデバッグな
どを行うのに有効
ただし、この機能はk8s標準ではない為
tungstenfabric側での設定が必要
nginx nginx
pod-network
external-network
Web
LoadBalancer
service-network
public-network
D:203.0.113.1
10.0.10.1
10.0.10.1

WHAT CHALLENGES CAN TF RESOLVE?
• Connect POD from External Network
tungstenfabricは先ほど紹介した通り、物理ルータ
やHVTEPと連携ができるのでPODネットワークを
外部ネットワークとの連携が可能
外部DBなどを参照する場合にNATいらずで通信が
行える
これはtungstenfabricgs紐づいている為、特別な
ゲートウェイサーバが不要で、既存の物理ルータ
などと連携が可能
・APIServer
TF vRouter
pod
pod
•KubeManager
•Controller
•Analytics
•Analytics-DB
kubelet
CNI
Agent
TF vRouter
pod
pod
kubelet
CNI
Agent
SV VMSV VM
BGP L3VPN/EVPN

WHAT CHALLENGES CAN TF RESOLVE?
• Connect LB from External Network
Tungstenfabricではservice type: Loadbalancerを利用
して、外部からのアクセスを提供することが可能
LoadbalanceはECMPによって各vRouterで行われる
為、高速で切り替わりも早く、またスケールアウ
トもする
・APIServer
TF vRouter
pod
pod
•KubeManager
•Controller
•Analytics
•Analytics-DB
kubelet
CNI
Agent
TF vRouter
pod
pod
kubelet
CNI
Agent
SV VMSV VM
BGP L3VPN/EVPN
LBLB
kind: Service
apiVersion: v1
metadata:
name: cirros-loadbalancer
spec:
selector:
app: cirros-deployment
ports:
- protocol: TCP
port: 80
type: LoadBalancer

K8S WITH TUNGSTENFABRICでのサービスチェイン
• VNF between Networks
インターネットや、別ネットワークに対して抜け
る場合に必ずFWやDPIなどを経由してから通信を
行うような制御が可能(上述したサービスチェイン)
サービスチェインするノードを増やしたり、多段
にすることも可能
TF vRouter
pod
pod
kubelet
CNI
Agent
TF vRouter
Agent
Internet

TUNGSTENGABRICが提供するソリューション
Consider K8S limitation from Typical Enterprise Network Design
Web Web
API API
DB DB
192.168.10.0/24
192.168.20.0/24
192.168.30.0/24
172.16.0.0/24
Syslo
g
Monitor
Service Network
Develop:A
Develop:B
Tungstengabricはkubernetesネットワークの
制限を緩和し、既存ネットワークの接続や、
PODネットワークを専用に割り当てられる
Tungsten Fabric Resolved:
• Dedicated POD network
• FW integration
• Existing Network connection
• Direct POD connection

KUBERNETES TO CONTRAIL OBJECT MAPPING
Single project OR Shared project
Virtual Machine
ECMP Loadbalancer
Haproxy Loadbalancer for URL
Contrail Security
Namespace
Pod
Service
Ingress
Network Policy

まとめ

ぼくのかんがえたさいきょうのPRIVATE CLOUD
•NovaAPI
•Glance
•Keystone
•Neutrone/kuryr
•Cinder
•Heat
TF vRouter
・APIServer
・Controller
・Scheduler
・APIServer
・Controller
・Scheduler
•Novacompute
Jenkins
registory
mysql
TF vRouter
Agent
kubelet
CNI
bridge
rails
nginx
vlan
vlan
TF vRouter
Agent
•Novacompute
Agent
Internet
BMS Other DC Public Cloud
•Novacompute

まとめ
• k8sが流行っているからといって、仮想化の全てがContainerで提供さ
れることにはならない
• VMとContainerの両方をうまく使い分ける必要がある
• k8s on OpenStackはオンプレk8sにおける解決案の一つ
• しかし抱えている課題はまだまだある
• k8s on OpenStack with tungstenfabricでnestead modeを利用すること
でOpenStackとk8sのNWを簡単に統合でき、特別なナレッジがなくて
もGKEと同じような感覚で利用することができる

Enjoy tungstenfabric !!!

付録

TUNGSTENFABRIC COMPONENTS
Config Node
• REST API Server
• contrail-api
• REST API Server that provides the north-bound interface to an Orchestration
System or other application. This interface is used to install configuration state
using the high-level data model. This process is responsible for storing/loading
permanent data to/from database.
• Schema Transformer
• contrail-schema
• Schema transformer that learns about changes in the high level data model
over the Redis message bus and transforms (or compiles) these changes in
the high level data model into corresponding changes in the low level data
model. Only one Schema Transformer is elected on Contrail cluster.
• Service Monitor
• contrail-svc-monitor
• SVC Monitor creates service instances on hypervisor which provide network
service such as NAT, Firewall, Load balancer. Only one Service Monitor is
elected on Contrail cluster.
• Message Bus
• rabbitmq-server
• Message Bus to facilitate communications amonginternal components. REST
API sends notification messages to other Config Nodes through Message bus.
Support service
Database NodeConfig Node
REST API
Server
Schema
Transformer
Orchestrator
REST
Cassandra
Control
Node
Control
Node
Message
Bus
Compute
Node
Analytics
Node
Zookeeper
Service Monitor
Device Manager

• Device Manager
• contrail-device-manager
• Device Manger creates XML data for Netconf. It manages
physical routers such as MX/vMX router.
• Message Bus
• rabbitmq-server
• Message Bus to facilitate communications amonginternal
components. REST API sends notification messages to other
Config Nodes through Message bus.
• Discovery Server
• contrail-discovery
• Discovery Server collects all contrail node information and send
sends appropriate Node IP addresses at client request.
Config Node
Support service
Database NodeConfig Node
REST API
Server
Schema
Transformer
Orchestrator
REST
Cassandra
Control
Node
Control
Node
Message
Bus
Compute
Node
Analytics
Node
Zookeeper
Service Monitor
Device Manager

Control Node
Control Node
Proxies
XMPP
Control
Node
Control
Node
Compute
Node
TSN
Config Node Config Node
IF-MAP
XMPP
IF-MAP
Client
Gateway
Routers
Service
Nodes
• IF-MAP Client / XMPP
• contrail-control
• Control nodes receive configuration state from the configuration
nodes using IF-MAP.
• Control nodes exchange routes with other control nodes using
IBGP to ensure that all control nodes have the same network
state.
• Control nodes exchange routes with the vRouter agents on the
compute nodes using XMPP. They also use XMPP to send
configuration state such as routing instances and forwarding
policy.
• Control nodes exchange routes with the gateway nodes
(routers and switches) using BGP. They also send
configuration state using Netconf.
• Proxies
• contrail-dns
• contrail-dns create DNS records for each tenants.
• contrail-named
• contrail-named provides the name to IP address mapping for
DNS and MDNS requests.
BGP
Netconf

Analytics Node
• REST API Server
• contrail-analytics-api
• REST API server that provides a northbound interface for querying
the analytics database and for retrieving operational state.
• Query engine
• contrail-query-engine
• Query engine for executing the queries received over the
northbound REST API. This engine provides the capability for
flexible access to potentially large amounts of analytics data.
• Sandesh Collector
• contrail-collector
• Collector that exchanges Sandesh messages with components in
control nodes and configuration nodes to collect analytics
information.
• Rules engine
• contrail-collector
• rules engine to automatically collect operational state when specific
events occur.
• Message Bus
• redis-server
• Message Bus to facilitate communications among internal
components.
Analytics Node
REST API
Server
Rules
Engine
Other
Analytics
Clients
Collector
All
Nodes
All
Nodes
Analytics Client
Generated API
UI, CLI
Application
Message Bus
Query
Engines
Sandesh
REST
Database Node
Cassandra
Zookeeper

Analytics Node
• SNMP Collector
• contrail-snmp-collector
• SNMP Collector receives SNMP, IPFIX, sFlow infofation from
Physical Routers and underlay Switches.
• Topology Builder
• contrail-topology
• Query engine for executing the queries received over the
northbound REST API. This engine provides the capability for
flexible access to potentially large amounts of analytics data.
Analytics Node
REST API
Server
Rules
Engine
Other
Analytics
Clients
Collector
All
Nodes
All
Nodes
Analytics Client
Generated API
UI, CLI
Application
Message Bus
Query
Engines
Sandesh
REST
Database Node
Cassandra
Zookeeper

TUNGSTENFABRIC FORWARDING PLANE
Compute Node
Compute Node
vRouter Agent
Overlay tunnels
MPLS over GRE/UDP or
VXLAN
Control Node
vhost0
Kernel
pkt0
User
Config
VRFs
Policy
Table vRouter Forwarding Plane
Virtual
Machine
(Tenant A)
Routing
Instance
Flow
Table
FIB
Tap Interfaces (vif)
Routing
Instance
Flow Table
FIB
Virtual
Machine
(Tenant B)
Virtual
Machine
(Tenant B)
• vRouter agent
• contrail-vrouter-agent
• Exchanging control state such as routes with the Control nodes
using XMPP.
• Receiving low-level configuration state such as routing
instances and forwarding policy from the Control nodes using
XMPP
• Reporting analytics state such as logs, statistics, and events to
the analytics nodes.
• Installing forwarding state into the forwarding plane.
• Discovering the existence and attributes of VMs in cooperation
with the Nova agent.
• Applying forwarding policy for the first packet of each new flow
and installing a flow entry in the flow table of the forwarding
plane.
• Proxying DHCP, ARP, DNS, and MDNS.
vhost0

TungstenFabricでOpenStackとk8sをラクラク管理

More Related Content

What's hot

Similar to TungstenFabricでOpenStackとk8sをラクラク管理

TungstenFabricでOpenStackとk8sをラクラク管理