SlideShare a Scribd company logo
©2018 VMware, Inc.
コンテナネットワーキング
(CNI) 最前線
Dec. 04, 2018
CTO, North Asia (Japan, Korea and Greater China)
Motonori Shindo
比べて分かる Flannel、Calico、Canal、NSX-T
2©2018 VMware, Inc.
Docker Network
container-01
ens160
vethXXXXX
eth0
container-02
vethYYYYY
eth0
veth-
pair
veth-
pair
docker0 (172.17.0.1/16)
• コンテナとホストの間に veth pair が作
られ、それぞれ別の namespace に置か
れる
• ホスト側に docker0 という bridge が作
られ、物理インターフェースと、veth
が接続される
• docker0 にはデフォルトで
172.17.0.1/16 が割り当てられる
• コンテナ側の eth0 には docker0 と同じ
サブネットから IP アドレスが振られて
いく
• コンテナの default gateway は docker0
を向く
• Docker0 に割り当てられたサブネット
からのパケットが外に出る場合は SNAT
(IP masquerade) されて出ていく
172.17.0.2/16 172.17.0.3/16
3©2018 VMware, Inc.
Docker Network の課題
172.17.0.2
docker0
172.17.0.1
node-01
container-
11
container-
12
172.17.0.3 172.17.0.2
docker0
172.17.0.1
container-
21
container-
22
172.17.0.3
node-02
• 同一ノード上のコンテナは素直に通信できる
• 複数ノードがある場合、各ノードには同じ IP アド
レスが振られる可能性がある(高い)
• ノードをまたがる通信には port-forward が必
要になる
• Port-forward の管理が大変(これをオーケス
トレーションする人がいない)
Port-forward
が必要
node-02% docker run container-21 –p 8001:80
node-02% docker run container-22 –p 8002:80
Docker により Container Network Model
(CNM) が提案されたが、Kubernetes は採
用せず(参考:Why Kubernetes doesn’t use
libnetwork)
4©2018 VMware, Inc.
CoreOS によって提唱、現在は CNCF に移管されている
Linux コンテナが作成された際のネットワーク接続性の確保とコンテナが
削除された際のリソース解放を行う
• QoS やネットワーク・ポリシーは範疇外(現状)
コンテナランタイム
• Rkt, Kubernetes, OpenShift, Cloud Foundry, Apache Mesos, Amazon ECS
3rd Party プラグイン
• Project Calico, Weave, Contiv, Cilium, Nuage CNI, Silk, ovn-kubernetes,
Juniper Contrail/TungstenFabric, NSX-T Container Plugin (NCP), etc.
CNI (Container Network Interface)
5©2018 VMware, Inc.
1. 全てのコンテナは他コンテナと NAT なしで通信できること
2. 全てのノードは全てのコンテナと NAT なしで通信できること
3. コンテナから見える自分の IP アドレスと他から見た場合と同じであること
Kubernetes がネットワークに求める要件
6©2018 VMware, Inc.
Kubernetes のネットワークモデル(ノード内)
eth0 eth0
• IP アドレスは Pod に対して振られ、
Pod Network の中からアドレスが割り
当てられる
• 1 Pod 内に複数のコンテナがある場合で
も、それらは同じ namespace 内にあり
network interface は共有される
• Pod 内の複数コンテナは localhost を
使って通信可能
• Pod 内のポート番号の調停は必要
だが、Pod 間で調停をする必要は
ない
C1 C1 C2
Pod Network (192.168.0.0/16)
192.168.0.1/16 192.168.0.2/16
Pod 1 Pod 2
lo0
(localhost)
Node
7©2018 VMware, Inc.
機能
• ネットワーク接続性
特徴
• さまざまな back end をサポート
– Official: VXLAN, host-gw, UDP
– Experimental: AliVPC, Alloc, AWS VPCs, GCE, IPIP, IPsec
Flannel
8©2018 VMware, Inc.
9©2018 VMware, Inc.
10©2018 VMware, Inc.
Flannel のアーキテクチャ
flanneld
FIB
etcd
Orchestrator
Plugin
userland
kernel
Node
11©2018 VMware, Inc.
Flannel によるネットワーク
kubuadm init --pod-network-cidr=10.244.0.0/16
10.156.0.0/16
• Pod Network CIDR (/16) は各ノード毎に /24 に分割され、各ノードに割り当て
られる
• flannel.1 という VXLAN (VTEP) interface が作成され、.0/32 のアドレスが振ら
れる
• cni0 という bridge interface が作成され、.1/24 のアドレスが振られる
• Pod には eth0 が作られ、それとペアとなる veth interface が作られ、cni0 ブ
リッジに接続され、default gw は cni0 のアドレスを向く
• 各ノードの Pod Network の next-hop は、そのノードの flannel.1 interface のア
ドレスの ”onlink” で作られる
• 他ホストの flannel.1 interface の MAC アドレスが静的に ARP テーブルに書かれ
る
• ググると L2 / L3 MISS を拾う、という記述が散見されるが、2017年2月の commit
5d3d66425 で大幅に書き換えられており、現在は L2/L3 MISS をフックす
るような動作はしなくなっている
node-01% ip route | grep 10.244
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink
cni0
(10.244.1.1/24)
pod-01
vethXXXXX
eth0
flannel.1
(10.244.1.0)
ens160
pod-02
eth0
vethYYYYY
node-01
pod-01% ip route
default via 10.244.1.1 dev eth0
10.244.0.0/16 via 10.244.1.1 dev eth0
10.244.1.0/24 dev eth0 scope link src 10.244.1.10
node-01% arp -an | grep 10.244
? (10.244.2.0) at 1a:39:5c:fa:9a:f1 [ether] PERM on flannel.1
? (10.244.1.9) at 0a:58:0a:f4:01:09 [ether] on cni0
? (10.244.0.0) at 22:b3:69:58:45:f1 [ether] PERM on flannel.1
14©2018 VMware, Inc.
機能
• ネットワーク接続性
• ネットワークポリシー
特徴
• 複数のオーケストレーションに対応(OpenStack, Kubernetes, etc.)
• Encapsulation が必要ない(IP-in-IP を使うことはできる)
• BGP(BIRD, gobgp)で経路を広告
• ポリシーは iptables で実現
• ポリシー部分だけ使うことも可能(e.g. Canal)
• IPv6 対応
Project Calico
15©2018 VMware, Inc.
16©2018 VMware, Inc.
17©2018 VMware, Inc.
18©2018 VMware, Inc.
Calico アーキテクチャ(コンポーネント)
Felix
BGP Client
(BIRD)
BGP RR (optional)
(BIRD)
ACL FIB
etcd
Orchestrator
Plugin
confd
userland
kernel
Node
19©2018 VMware, Inc.
Calico によるネットワーク(ノード間)
master node-01 node-02
kubuadm init --pod-network-cidr=192.168.0.0/16
10.156.0.0/16
0.84 0.78 0.86
• Pod Network CIDR (/16) は各 node 毎に /26 に分割して
BGP で広告
• ググるとホストルート(/32)が広告される、という
記述がたくさん見つかるが、少なくとも現在はそう
なっていない
• ノードに deploy された Pod 毎に caliXXXXXXX という
veth interface が作成される
• 他ノードへの経路は IP-in-IP を使う場合は dev tunl0 に、
そうでない場合は通常の ethernet i/f (e.g. dev ens160) を
向く
BIRD BIRDBIRD
node-01% ip route | grep 192.168
blackhole 192.168.0.128/26 proto bird
192.168.0.144 dev caliae434558fa1 scope link
192.168.0.145 dev cali436b19e8d7e scope link
192.168.0.146 dev calid93c954af3f scope link
192.168.221.192/26 via 10.156.250.84 dev ens160 proto bird
192.168.238.0/26 via 10.156.250.86 dev ens160 proto bird
BGP
BGPBGP
20©2018 VMware, Inc.
Calico によるネットワーク(ノード内)
pod-01
ens160
caliXXXXX
eth0
pod-02
caliYYYYY
eth0
veth-pair veth-pair
pod-01-container% ip route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
• どの Pod も default route が link local
である 169.254.1.1 を向く
• しかし、誰も 169.254.1.1 というアドレ
スを持った interface はどこにもない
• なぜ動くか?
• Host 側の interface (caliXXXXX) に
proxy ARP の設定がされている!
pod-02-container% ip route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
node-01 % cat 
/proc/sys/net/ipv4/conf/caliYYYYY/proxy_arp
1
ARP Req ?
169.254.1.1
ARP Rep
169.254.1.1 is at
ee:ee:ee:ee:ee:ee
21©2018 VMware, Inc.
いわゆる ACL(Access Control List)機能
• 方向: ingress / egress
• 対象: IP Block、Pod (label-based)
Pod 単位にかけられるので、Pod の IP アドレスが変
わっても追従することができる(いわゆる Micro
Segmentation)
iptablesで実装するケースが多い
Kubernetes ネットワークポリシー
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: access-nginx
namespace: policy-demo
spec:
podSelector:
matchLabels:
run: nginx
ingress:
- from:
- podSelector:
matchLabels:
run: access
22©2018 VMware, Inc.
Calico の Kubernetes ネットワーク
mshindo@kube-node01:~$sudo iptables -L
ChainINPUT(policy ACCEPT)
target prot opt source destination
cali-INPUT all -- anywhere anywhere /*cali:Cz_u1IQiXIMmKD4c*/
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW/*kubernetesexternally-visible service portals */
KUBE-FIREWALL all -- anywhere anywhere
(snipped)
Chaincali-FORWARD (1references)
target prot opt source destination
MARK all -- anywhere anywhere /* cali:vjrMJCRpqwy5oRoX*/ MARK and 0xfff1ffff
cali-from-hep-forward all -- anywhere anywhere /*cali:A_sPAO0mcxbT9mOV*/ markmatch 0x0/0x10000
cali-from-wl-dispatch all -- anywhere anywhere /*cali:8ZoYfO5HKXWbB3pk*/
cali-to-wl-dispatch all -- anywhere anywhere /*cali:jdEuaPBe14V2hutn*/
cali-to-hep-forward all -- anywhere anywhere /*cali:12bc6HljsMKsmfr-*/
ACCEPT all -- anywhere anywhere /*cali:MH9kMp5aNICL-Olv*/ /*Policy explicitly accepted packet. */ markmatch 0x10000/0x10000
Chaincali-INPUT(1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere /*cali:msRIDfJRWnYwzW4g*/ markmatch 0x10000/0x10000
ACCEPT ipencap-- anywhere anywhere /* cali:1IRlRis1-pHsGnX5*/ /*Allow IPIP packets from Calico hosts */ match-setcali40all-hosts-net srcADDRTYPEmatchdst-type LOCAL
DROP ipencap-- anywhere anywhere /*cali:jX63A0VGotRJWnUL */ /*Drop IPIPpackets from non-Calicohosts*/
cali-wl-to-host all -- anywhere anywhere [goto] /*cali:Dit8xicL3zTIYYlp */
MARK all -- anywhere anywhere /* cali:LCGWUV2ju3tJmfW0*/ MARK and0xfff0ffff
cali-from-host-endpoint all -- anywhere anywhere /*cali:x-gEznubq2huN2Fo*/
ACCEPT all -- anywhere anywhere /*cali:m27NaAhoKHLs1plD*/ /*Hostendpointpolicy accepted packet. */ markmatch 0x10000/0x10000
Chaincali-OUTPUT (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere /*cali:Mq1_rAdXXH3YkrzW*/ markmatch 0x10000/0x10000
RETURN all -- anywhere anywhere /*cali:69FkRTJDvD5Vu6Vl*/
ACCEPT ipencap-- anywhere anywhere /* cali:AnEsmO6bDZbQntWW*/ /*Allow IPIP packets to other Calico hosts */ match-setcali40all-hosts-net dst ADDRTYPEmatchsrc-type LOCAL
MARK all -- anywhere anywhere /* cali:9e9Uf3GU5tX--Lxy */ MARK and 0xfff0ffff
cali-to-host-endpoint all -- anywhere anywhere /*cali:OB2pzPrvQn6PC89t*/
ACCEPT all -- anywhere anywhere /*cali:tvSSMDBWrme3CUqM*/ /*Hostendpointpolicy accepted packet. */ markmatch 0x10000/0x10000
Chaincali-failsafe-in (0references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere /*cali:wWFQM43tJU7wwnFZ*/ multiport dports ssh
ACCEPT udp -- anywhere anywhere /*cali:LwNV--R8MjeUYacw*/ multiport dports bootpc
ACCEPT tcp -- anywhere anywhere /*cali:QOO5NUOqOSS1_Iw0*/ multiport dports bgp
ACCEPT tcp -- anywhere anywhere /*cali:cwZWoBSwVeIAZmVN*/ multiport dports 2379
ACCEPT tcp -- anywhere anywhere /*cali:7FbNXT91kugE_upR*/ multiport dports 2380
ACCEPT tcp -- anywhere anywhere /*cali:ywE9WYUBEpve70WT */ multiport dports 6666
23©2018 VMware, Inc.
Canal
Calico の ポリシー機能と Flannel の接続性機能を組み合わせた「利用パ
ターン」
• Calico / Flannel には特に何も手を入れず、そのまま利用
VMware Cloud PKS は現状 Canal を使っている(OVN に移行する可能
性あり)
% kubectl get pod -n vke-system
NAME READY STATUS RESTARTS AGE
canal-node-1-10-2-62-87l9w 3/3 Running 0 1h
canal-node-1-10-2-62-fkbjs 3/3 Running 0 1h
cluster-autoscaler-1-10-2-62-b77d598d-7l7cx 1/1 Running 0 1h
kube-dns-1-10-2-62-6b898964fc-l6pbf 3/3 Running 0 1h
kubernetes-dashboard-1-10-2-62-5b46d8b9d6-7lhw9 2/2 Running 0 1h
nginx-ingress-deployment-1-10-2-62-7cf5897767-pdr6l 1/1 Running 0 1h
node-monitor-ds-1-10-2-62-glv2r 1/1 Running 0 1h
update-controller-ds-1-10-2-62-52flf 1/1 Running 0 1h
24©2018 VMware, Inc.
25©2018 VMware, Inc.
Canal によるネットワーク
kubuadm init --pod-network-cidr=10.244.0.0/16
10.156.0.0/16
• Pod の eth0 と veth (caliXXXXX) interface のアーキテクチャは Calico のま
ま
• デフォルトが 169.254.1.1 を向き、proxy ARP
• cni0 bridge interface は作られるが caliXXXXX interface は繋ぎ込まれない
• 他ノードへの経路のルーティングアーキテクチャは flannel のまま
• 他ノードへの onlink な経路と静的 ARP 設定
• 「Calico の オーバーレイネットワーク部分を flannel で置き換えたアーキ
テクチャ」と考えたほうが正しいかも
node-01% ip route | grep 10.244
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 linkdown
10.244.1.2 dev calia2a0356c6f4 scope link
10.244.1.3 dev cali4f3e8bf5e26 scope link
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink
node-01% arp -an | grep 10.244
? (10.244.2.0) at 1a:39:5c:fa:9a:f1 [ether] PERM on flannel.1
? (10.244.0.0) at 22:b3:69:58:45:f1 [ether] PERM on flannel.1
? (10.244.1.9) at 0a:58:0a:f4:01:09 [ether] on cni0
cni0
(10.244.1.1/24)
pod-01
caliXXXXX
eth0
flannel.1
(10.244.1.0)
ens160
pod-02
eth0
caliYYYYY
node-01
pod-01% default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
node-01 % cat 
/proc/sys/net/ipv4/conf/caliYYYYY/proxy_arp
1
26©2018 VMware, Inc.
機能
• ネットワーク接続性
• ネットワークポリシー
• その他
特徴
• ネームスペースとの連動
• 可視化&トラブルシュート機能(カウンタ、ミラーリング、Traceflow、等)
• VM ワークロードとの共存
• Load Balancer を提供
NSX-T Container Plugin (NCP)
27©2018 VMware, Inc.
28©2018 VMware, Inc.
NSX-T NCP によるネットワーク(namespace との連動)
pod-11
• NCP は K8S の namespace を監視
1. namespace が作成される
2. NSX-T が持つ IP block からサブ
ネットが割り振られる
3. 論理スイッチが作成される
4. T1 ルータが作成され T0 ルータ
と接続される
5. T1 にルータポートが作成され、
論理スイッチに接続され、IP ア
ドレスがサブネットから振られ
る
6. NAT するなら、T0 ルータに
SNAT のルールを設定する
pod-12
namespace: foo
Hypervisor (ESXi or KVM)
namespace: bar
29©2018 VMware, Inc.
NSX-T NCP によるネットワーク(wiring)
pod-11
• Node 外に仮想ネットワーク機能 (NSX-
T) があるので、Node でオーバーレイを
終端する必要がない
• Node VM の中で動作している OVS に
VLAN Trunking してやるだけ
• OVS は Standalone モードで動作
し、NCP によりプログラムされる
• Cif (Container I/F) に対して DFW を適
用できるので、Pod 単位に Micro-
Segmenation できる
pod-12
Node-01 (VM)
VLAN10
VLAN11OVS
eth2
cifcif
pod-21 pod-22
Node-02 (VM)
VLAN10
VLAN11
OVS
eth2
cifcif
Hypervisor (ESXi or KVM)
NSX-T
30©2018 VMware, Inc.
OVS vs iptables パフォーマンス比較
出典:http://www.openvswitch.org/support/ovscon2014/17/1030-conntrack_nat.pdf
31©2018 VMware, Inc.
iptables による Service Routing のパフォーマンス(1)
出典: https://www.slideshare.net/LCChina/scale-kubernetes-to-support-50000-services
32©2018 VMware, Inc.
iptables による Service Routing のパフォーマンス(2)
出典: https://www.slideshare.net/LCChina/scale-kubernetes-to-support-50000-services
36©2018 VMware, Inc.
Flannel Calico Project Canal NSX-T Container
Plugin (NCP)
Datastore K8S API (recommended),
etcd
etcd、K8S API (beta) K8S API (recommended),
etcd
NSX Manager
Overlay Production: VXLAN, none
(host-gw)、Experimental:
IP-in-IP, IPsec
None, IP-in-IP VXLAN, IP-in-IP, VCP
routing (not
recommended)
Geneve (outside of
worker node)
Network Policy Mechanism - Iptables / Istio Iptables / Istio OVS / (n)vDS
K8S Policy - Yes Yes Yes
App Policy - HTTP method/path
(requires Istio)
HTTP method/path
(requires Istio)
No
Load Balancer N-S - - - NSX LB
E-W iptables iptables iptables OVS datapath
VM Support No No No Yes
Visibility Tools External External (prometheus) External (prometheus) Built-in (Traceflow,
Mirroing, etc.)
Commercial Support No Yes No? Yes
比較表
37©2018 VMware, Inc.
コンテナ・ネットワーキング、闇多し 
動きが早いので、Web の情報を信用してはいけない
スケーラビリティには注意しよう!
Key Takeaways
38©2018 VMware, Inc.
Ubuntu: 18.04 (bionic)
Kubernetes: v1.11.2
Docker: 18.06.1-ce
Flannel: v0.10.0
Calico: 3.2.1
Canal: Calico 2.6.2 + Flannel v0.9.1
NSX-T: 2.1.0.0.7395503
今回テストに使ったバージョン
©2018 VMware, Inc.
ご静聴ありがとうござ
いました

More Related Content

What's hot

NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くしたNginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
toshi_pp
 

What's hot (20)

BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
 
ゼロから作るKubernetesによるJupyter as a Service ー Kubernetes Meetup Tokyo #43
ゼロから作るKubernetesによるJupyter as a Service ー Kubernetes Meetup Tokyo #43ゼロから作るKubernetesによるJupyter as a Service ー Kubernetes Meetup Tokyo #43
ゼロから作るKubernetesによるJupyter as a Service ー Kubernetes Meetup Tokyo #43
 
OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)
OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)
OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)
 
containerdの概要と最近の機能
containerdの概要と最近の機能containerdの概要と最近の機能
containerdの概要と最近の機能
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
 
10分でわかる Cilium と XDP / BPF
10分でわかる Cilium と XDP / BPF10分でわかる Cilium と XDP / BPF
10分でわかる Cilium と XDP / BPF
 
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
 
ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
 
VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)
VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)
VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)
 
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
 
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くしたNginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
 

Similar to コンテナネットワーキング(CNI)最前線

「さくらのクラウド」におけるVyattaの活用事例
「さくらのクラウド」におけるVyattaの活用事例「さくらのクラウド」におけるVyattaの活用事例
「さくらのクラウド」におけるVyattaの活用事例
SAKURA Internet Inc.
 
Openvswitch vps 20120429資料
Openvswitch vps 20120429資料Openvswitch vps 20120429資料
Openvswitch vps 20120429資料
Daisuke Nakajima
 
Trema での Open vSwitch
Trema での Open vSwitchTrema での Open vSwitch
Trema での Open vSwitch
kazuyas
 
Interrupt Affinityについて
Interrupt AffinityについてInterrupt Affinityについて
Interrupt Affinityについて
Takuya ASADA
 

Similar to コンテナネットワーキング(CNI)最前線 (20)

FD.io VPP事始め
FD.io VPP事始めFD.io VPP事始め
FD.io VPP事始め
 
VPP事始め
VPP事始めVPP事始め
VPP事始め
 
「さくらのクラウド」におけるVyattaの活用事例
「さくらのクラウド」におけるVyattaの活用事例「さくらのクラウド」におけるVyattaの活用事例
「さくらのクラウド」におけるVyattaの活用事例
 
Openvswitch vps 20120429資料
Openvswitch vps 20120429資料Openvswitch vps 20120429資料
Openvswitch vps 20120429資料
 
Lxc on cloud
Lxc on cloudLxc on cloud
Lxc on cloud
 
Container Networking Deep Dive
Container Networking Deep DiveContainer Networking Deep Dive
Container Networking Deep Dive
 
OpenContrailのソースコードを探検しよう!
OpenContrailのソースコードを探検しよう!OpenContrailのソースコードを探検しよう!
OpenContrailのソースコードを探検しよう!
 
Docker入門 OSC 2018 Tokyo/Spring
Docker入門 OSC 2018 Tokyo/SpringDocker入門 OSC 2018 Tokyo/Spring
Docker入門 OSC 2018 Tokyo/Spring
 
Using Kubernetes on Google Container Engine
Using Kubernetes on Google Container EngineUsing Kubernetes on Google Container Engine
Using Kubernetes on Google Container Engine
 
Backdoor!! vmware-tools と 統合サービスに見るハイパーバイザの呼び出し方
Backdoor!! vmware-tools と 統合サービスに見るハイパーバイザの呼び出し方Backdoor!! vmware-tools と 統合サービスに見るハイパーバイザの呼び出し方
Backdoor!! vmware-tools と 統合サービスに見るハイパーバイザの呼び出し方
 
VTI の中身
VTI の中身VTI の中身
VTI の中身
 
OpenvswitchでVPS
OpenvswitchでVPSOpenvswitchでVPS
OpenvswitchでVPS
 
Lagopus + DockerのDPDK接続
Lagopus + DockerのDPDK接続Lagopus + DockerのDPDK接続
Lagopus + DockerのDPDK接続
 
Trema での Open vSwitch
Trema での Open vSwitchTrema での Open vSwitch
Trema での Open vSwitch
 
How to apt-get from the internal network: remote sshd with kneesocks
How to apt-get from the internal network: remote sshd with kneesocksHow to apt-get from the internal network: remote sshd with kneesocks
How to apt-get from the internal network: remote sshd with kneesocks
 
宣言的(Declarative)ネットワーキング
宣言的(Declarative)ネットワーキング宣言的(Declarative)ネットワーキング
宣言的(Declarative)ネットワーキング
 
Hadoop on LXC
Hadoop on LXCHadoop on LXC
Hadoop on LXC
 
近頃のDockerネットワーク
近頃のDockerネットワーク近頃のDockerネットワーク
近頃のDockerネットワーク
 
VlanManagerを使ってみた
VlanManagerを使ってみたVlanManagerを使ってみた
VlanManagerを使ってみた
 
Interrupt Affinityについて
Interrupt AffinityについてInterrupt Affinityについて
Interrupt Affinityについて
 

More from Motonori Shindo

L2 over l3 ecnaspsulations (english)
L2 over l3 ecnaspsulations (english)L2 over l3 ecnaspsulations (english)
L2 over l3 ecnaspsulations (english)
Motonori Shindo
 

More from Motonori Shindo (20)

おうち Lab で GitDNSOps / GitDNS Ops in My Home Lab
おうち Lab で GitDNSOps / GitDNS Ops in My Home Labおうち Lab で GitDNSOps / GitDNS Ops in My Home Lab
おうち Lab で GitDNSOps / GitDNS Ops in My Home Lab
 
Tanzu Mission Control における Open Policy Agent (OPA) の利用
Tanzu Mission Control における Open Policy Agent (OPA) の利用Tanzu Mission Control における Open Policy Agent (OPA) の利用
Tanzu Mission Control における Open Policy Agent (OPA) の利用
 
Open Policy Agent (OPA) と Kubernetes Policy
Open Policy Agent (OPA) と Kubernetes PolicyOpen Policy Agent (OPA) と Kubernetes Policy
Open Policy Agent (OPA) と Kubernetes Policy
 
Open Policy Agent (OPA) 入門
Open Policy Agent (OPA) 入門Open Policy Agent (OPA) 入門
Open Policy Agent (OPA) 入門
 
急速に進化を続けるCNIプラグイン Antrea
急速に進化を続けるCNIプラグイン Antrea 急速に進化を続けるCNIプラグイン Antrea
急速に進化を続けるCNIプラグイン Antrea
 
Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用
Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用
Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用
 
Service Mesh for Enterprises / Cloud Native Days Tokyo 2019
Service Mesh for Enterprises / Cloud Native Days Tokyo 2019Service Mesh for Enterprises / Cloud Native Days Tokyo 2019
Service Mesh for Enterprises / Cloud Native Days Tokyo 2019
 
Idea Hackathon at vFORUM 2019 Tokyo
Idea Hackathon at vFORUM 2019 TokyoIdea Hackathon at vFORUM 2019 Tokyo
Idea Hackathon at vFORUM 2019 Tokyo
 
Containers and Virtual Machines: Friends or Enemies?
Containers and Virtual Machines: Friends or Enemies?Containers and Virtual Machines: Friends or Enemies?
Containers and Virtual Machines: Friends or Enemies?
 
Open Source Projects by VMware
Open Source Projects by VMwareOpen Source Projects by VMware
Open Source Projects by VMware
 
Serverless Framework "Disptach" の紹介
Serverless Framework "Disptach" の紹介Serverless Framework "Disptach" の紹介
Serverless Framework "Disptach" の紹介
 
フロー技術によるネットワーク管理
フロー技術によるネットワーク管理フロー技術によるネットワーク管理
フロー技術によるネットワーク管理
 
Viptela 顧客事例
Viptela 顧客事例Viptela 顧客事例
Viptela 顧客事例
 
ViptelaのSD-WANとクラウド最適化ネットワーク
ViptelaのSD-WANとクラウド最適化ネットワークViptelaのSD-WANとクラウド最適化ネットワーク
ViptelaのSD-WANとクラウド最適化ネットワーク
 
OpenStack Congress and Datalog (English)
OpenStack Congress and Datalog (English)OpenStack Congress and Datalog (English)
OpenStack Congress and Datalog (English)
 
OpenStack Congress and Datalog (Japanese)
OpenStack Congress and Datalog (Japanese)OpenStack Congress and Datalog (Japanese)
OpenStack Congress and Datalog (Japanese)
 
L2 over l3 ecnaspsulations (english)
L2 over l3 ecnaspsulations (english)L2 over l3 ecnaspsulations (english)
L2 over l3 ecnaspsulations (english)
 
L2 over L3 ecnaspsulations
L2 over L3 ecnaspsulationsL2 over L3 ecnaspsulations
L2 over L3 ecnaspsulations
 
VMware NSXがサポートするトンネル方式について
VMware NSXがサポートするトンネル方式についてVMware NSXがサポートするトンネル方式について
VMware NSXがサポートするトンネル方式について
 
CloudStack 4.1 + NVP Integration
CloudStack 4.1 + NVP IntegrationCloudStack 4.1 + NVP Integration
CloudStack 4.1 + NVP Integration
 

コンテナネットワーキング(CNI)最前線

  • 1. ©2018 VMware, Inc. コンテナネットワーキング (CNI) 最前線 Dec. 04, 2018 CTO, North Asia (Japan, Korea and Greater China) Motonori Shindo 比べて分かる Flannel、Calico、Canal、NSX-T
  • 2. 2©2018 VMware, Inc. Docker Network container-01 ens160 vethXXXXX eth0 container-02 vethYYYYY eth0 veth- pair veth- pair docker0 (172.17.0.1/16) • コンテナとホストの間に veth pair が作 られ、それぞれ別の namespace に置か れる • ホスト側に docker0 という bridge が作 られ、物理インターフェースと、veth が接続される • docker0 にはデフォルトで 172.17.0.1/16 が割り当てられる • コンテナ側の eth0 には docker0 と同じ サブネットから IP アドレスが振られて いく • コンテナの default gateway は docker0 を向く • Docker0 に割り当てられたサブネット からのパケットが外に出る場合は SNAT (IP masquerade) されて出ていく 172.17.0.2/16 172.17.0.3/16
  • 3. 3©2018 VMware, Inc. Docker Network の課題 172.17.0.2 docker0 172.17.0.1 node-01 container- 11 container- 12 172.17.0.3 172.17.0.2 docker0 172.17.0.1 container- 21 container- 22 172.17.0.3 node-02 • 同一ノード上のコンテナは素直に通信できる • 複数ノードがある場合、各ノードには同じ IP アド レスが振られる可能性がある(高い) • ノードをまたがる通信には port-forward が必 要になる • Port-forward の管理が大変(これをオーケス トレーションする人がいない) Port-forward が必要 node-02% docker run container-21 –p 8001:80 node-02% docker run container-22 –p 8002:80 Docker により Container Network Model (CNM) が提案されたが、Kubernetes は採 用せず(参考:Why Kubernetes doesn’t use libnetwork)
  • 4. 4©2018 VMware, Inc. CoreOS によって提唱、現在は CNCF に移管されている Linux コンテナが作成された際のネットワーク接続性の確保とコンテナが 削除された際のリソース解放を行う • QoS やネットワーク・ポリシーは範疇外(現状) コンテナランタイム • Rkt, Kubernetes, OpenShift, Cloud Foundry, Apache Mesos, Amazon ECS 3rd Party プラグイン • Project Calico, Weave, Contiv, Cilium, Nuage CNI, Silk, ovn-kubernetes, Juniper Contrail/TungstenFabric, NSX-T Container Plugin (NCP), etc. CNI (Container Network Interface)
  • 5. 5©2018 VMware, Inc. 1. 全てのコンテナは他コンテナと NAT なしで通信できること 2. 全てのノードは全てのコンテナと NAT なしで通信できること 3. コンテナから見える自分の IP アドレスと他から見た場合と同じであること Kubernetes がネットワークに求める要件
  • 6. 6©2018 VMware, Inc. Kubernetes のネットワークモデル(ノード内) eth0 eth0 • IP アドレスは Pod に対して振られ、 Pod Network の中からアドレスが割り 当てられる • 1 Pod 内に複数のコンテナがある場合で も、それらは同じ namespace 内にあり network interface は共有される • Pod 内の複数コンテナは localhost を 使って通信可能 • Pod 内のポート番号の調停は必要 だが、Pod 間で調停をする必要は ない C1 C1 C2 Pod Network (192.168.0.0/16) 192.168.0.1/16 192.168.0.2/16 Pod 1 Pod 2 lo0 (localhost) Node
  • 7. 7©2018 VMware, Inc. 機能 • ネットワーク接続性 特徴 • さまざまな back end をサポート – Official: VXLAN, host-gw, UDP – Experimental: AliVPC, Alloc, AWS VPCs, GCE, IPIP, IPsec Flannel
  • 10. 10©2018 VMware, Inc. Flannel のアーキテクチャ flanneld FIB etcd Orchestrator Plugin userland kernel Node
  • 11. 11©2018 VMware, Inc. Flannel によるネットワーク kubuadm init --pod-network-cidr=10.244.0.0/16 10.156.0.0/16 • Pod Network CIDR (/16) は各ノード毎に /24 に分割され、各ノードに割り当て られる • flannel.1 という VXLAN (VTEP) interface が作成され、.0/32 のアドレスが振ら れる • cni0 という bridge interface が作成され、.1/24 のアドレスが振られる • Pod には eth0 が作られ、それとペアとなる veth interface が作られ、cni0 ブ リッジに接続され、default gw は cni0 のアドレスを向く • 各ノードの Pod Network の next-hop は、そのノードの flannel.1 interface のア ドレスの ”onlink” で作られる • 他ホストの flannel.1 interface の MAC アドレスが静的に ARP テーブルに書かれ る • ググると L2 / L3 MISS を拾う、という記述が散見されるが、2017年2月の commit 5d3d66425 で大幅に書き換えられており、現在は L2/L3 MISS をフックす るような動作はしなくなっている node-01% ip route | grep 10.244 10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink cni0 (10.244.1.1/24) pod-01 vethXXXXX eth0 flannel.1 (10.244.1.0) ens160 pod-02 eth0 vethYYYYY node-01 pod-01% ip route default via 10.244.1.1 dev eth0 10.244.0.0/16 via 10.244.1.1 dev eth0 10.244.1.0/24 dev eth0 scope link src 10.244.1.10 node-01% arp -an | grep 10.244 ? (10.244.2.0) at 1a:39:5c:fa:9a:f1 [ether] PERM on flannel.1 ? (10.244.1.9) at 0a:58:0a:f4:01:09 [ether] on cni0 ? (10.244.0.0) at 22:b3:69:58:45:f1 [ether] PERM on flannel.1
  • 12. 14©2018 VMware, Inc. 機能 • ネットワーク接続性 • ネットワークポリシー 特徴 • 複数のオーケストレーションに対応(OpenStack, Kubernetes, etc.) • Encapsulation が必要ない(IP-in-IP を使うことはできる) • BGP(BIRD, gobgp)で経路を広告 • ポリシーは iptables で実現 • ポリシー部分だけ使うことも可能(e.g. Canal) • IPv6 対応 Project Calico
  • 16. 18©2018 VMware, Inc. Calico アーキテクチャ(コンポーネント) Felix BGP Client (BIRD) BGP RR (optional) (BIRD) ACL FIB etcd Orchestrator Plugin confd userland kernel Node
  • 17. 19©2018 VMware, Inc. Calico によるネットワーク(ノード間) master node-01 node-02 kubuadm init --pod-network-cidr=192.168.0.0/16 10.156.0.0/16 0.84 0.78 0.86 • Pod Network CIDR (/16) は各 node 毎に /26 に分割して BGP で広告 • ググるとホストルート(/32)が広告される、という 記述がたくさん見つかるが、少なくとも現在はそう なっていない • ノードに deploy された Pod 毎に caliXXXXXXX という veth interface が作成される • 他ノードへの経路は IP-in-IP を使う場合は dev tunl0 に、 そうでない場合は通常の ethernet i/f (e.g. dev ens160) を 向く BIRD BIRDBIRD node-01% ip route | grep 192.168 blackhole 192.168.0.128/26 proto bird 192.168.0.144 dev caliae434558fa1 scope link 192.168.0.145 dev cali436b19e8d7e scope link 192.168.0.146 dev calid93c954af3f scope link 192.168.221.192/26 via 10.156.250.84 dev ens160 proto bird 192.168.238.0/26 via 10.156.250.86 dev ens160 proto bird BGP BGPBGP
  • 18. 20©2018 VMware, Inc. Calico によるネットワーク(ノード内) pod-01 ens160 caliXXXXX eth0 pod-02 caliYYYYY eth0 veth-pair veth-pair pod-01-container% ip route default via 169.254.1.1 dev eth0 169.254.1.1 dev eth0 scope link • どの Pod も default route が link local である 169.254.1.1 を向く • しかし、誰も 169.254.1.1 というアドレ スを持った interface はどこにもない • なぜ動くか? • Host 側の interface (caliXXXXX) に proxy ARP の設定がされている! pod-02-container% ip route default via 169.254.1.1 dev eth0 169.254.1.1 dev eth0 scope link node-01 % cat /proc/sys/net/ipv4/conf/caliYYYYY/proxy_arp 1 ARP Req ? 169.254.1.1 ARP Rep 169.254.1.1 is at ee:ee:ee:ee:ee:ee
  • 19. 21©2018 VMware, Inc. いわゆる ACL(Access Control List)機能 • 方向: ingress / egress • 対象: IP Block、Pod (label-based) Pod 単位にかけられるので、Pod の IP アドレスが変 わっても追従することができる(いわゆる Micro Segmentation) iptablesで実装するケースが多い Kubernetes ネットワークポリシー kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: access-nginx namespace: policy-demo spec: podSelector: matchLabels: run: nginx ingress: - from: - podSelector: matchLabels: run: access
  • 20. 22©2018 VMware, Inc. Calico の Kubernetes ネットワーク mshindo@kube-node01:~$sudo iptables -L ChainINPUT(policy ACCEPT) target prot opt source destination cali-INPUT all -- anywhere anywhere /*cali:Cz_u1IQiXIMmKD4c*/ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW/*kubernetesexternally-visible service portals */ KUBE-FIREWALL all -- anywhere anywhere (snipped) Chaincali-FORWARD (1references) target prot opt source destination MARK all -- anywhere anywhere /* cali:vjrMJCRpqwy5oRoX*/ MARK and 0xfff1ffff cali-from-hep-forward all -- anywhere anywhere /*cali:A_sPAO0mcxbT9mOV*/ markmatch 0x0/0x10000 cali-from-wl-dispatch all -- anywhere anywhere /*cali:8ZoYfO5HKXWbB3pk*/ cali-to-wl-dispatch all -- anywhere anywhere /*cali:jdEuaPBe14V2hutn*/ cali-to-hep-forward all -- anywhere anywhere /*cali:12bc6HljsMKsmfr-*/ ACCEPT all -- anywhere anywhere /*cali:MH9kMp5aNICL-Olv*/ /*Policy explicitly accepted packet. */ markmatch 0x10000/0x10000 Chaincali-INPUT(1 references) target prot opt source destination ACCEPT all -- anywhere anywhere /*cali:msRIDfJRWnYwzW4g*/ markmatch 0x10000/0x10000 ACCEPT ipencap-- anywhere anywhere /* cali:1IRlRis1-pHsGnX5*/ /*Allow IPIP packets from Calico hosts */ match-setcali40all-hosts-net srcADDRTYPEmatchdst-type LOCAL DROP ipencap-- anywhere anywhere /*cali:jX63A0VGotRJWnUL */ /*Drop IPIPpackets from non-Calicohosts*/ cali-wl-to-host all -- anywhere anywhere [goto] /*cali:Dit8xicL3zTIYYlp */ MARK all -- anywhere anywhere /* cali:LCGWUV2ju3tJmfW0*/ MARK and0xfff0ffff cali-from-host-endpoint all -- anywhere anywhere /*cali:x-gEznubq2huN2Fo*/ ACCEPT all -- anywhere anywhere /*cali:m27NaAhoKHLs1plD*/ /*Hostendpointpolicy accepted packet. */ markmatch 0x10000/0x10000 Chaincali-OUTPUT (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere /*cali:Mq1_rAdXXH3YkrzW*/ markmatch 0x10000/0x10000 RETURN all -- anywhere anywhere /*cali:69FkRTJDvD5Vu6Vl*/ ACCEPT ipencap-- anywhere anywhere /* cali:AnEsmO6bDZbQntWW*/ /*Allow IPIP packets to other Calico hosts */ match-setcali40all-hosts-net dst ADDRTYPEmatchsrc-type LOCAL MARK all -- anywhere anywhere /* cali:9e9Uf3GU5tX--Lxy */ MARK and 0xfff0ffff cali-to-host-endpoint all -- anywhere anywhere /*cali:OB2pzPrvQn6PC89t*/ ACCEPT all -- anywhere anywhere /*cali:tvSSMDBWrme3CUqM*/ /*Hostendpointpolicy accepted packet. */ markmatch 0x10000/0x10000 Chaincali-failsafe-in (0references) target prot opt source destination ACCEPT tcp -- anywhere anywhere /*cali:wWFQM43tJU7wwnFZ*/ multiport dports ssh ACCEPT udp -- anywhere anywhere /*cali:LwNV--R8MjeUYacw*/ multiport dports bootpc ACCEPT tcp -- anywhere anywhere /*cali:QOO5NUOqOSS1_Iw0*/ multiport dports bgp ACCEPT tcp -- anywhere anywhere /*cali:cwZWoBSwVeIAZmVN*/ multiport dports 2379 ACCEPT tcp -- anywhere anywhere /*cali:7FbNXT91kugE_upR*/ multiport dports 2380 ACCEPT tcp -- anywhere anywhere /*cali:ywE9WYUBEpve70WT */ multiport dports 6666
  • 21. 23©2018 VMware, Inc. Canal Calico の ポリシー機能と Flannel の接続性機能を組み合わせた「利用パ ターン」 • Calico / Flannel には特に何も手を入れず、そのまま利用 VMware Cloud PKS は現状 Canal を使っている(OVN に移行する可能 性あり) % kubectl get pod -n vke-system NAME READY STATUS RESTARTS AGE canal-node-1-10-2-62-87l9w 3/3 Running 0 1h canal-node-1-10-2-62-fkbjs 3/3 Running 0 1h cluster-autoscaler-1-10-2-62-b77d598d-7l7cx 1/1 Running 0 1h kube-dns-1-10-2-62-6b898964fc-l6pbf 3/3 Running 0 1h kubernetes-dashboard-1-10-2-62-5b46d8b9d6-7lhw9 2/2 Running 0 1h nginx-ingress-deployment-1-10-2-62-7cf5897767-pdr6l 1/1 Running 0 1h node-monitor-ds-1-10-2-62-glv2r 1/1 Running 0 1h update-controller-ds-1-10-2-62-52flf 1/1 Running 0 1h
  • 23. 25©2018 VMware, Inc. Canal によるネットワーク kubuadm init --pod-network-cidr=10.244.0.0/16 10.156.0.0/16 • Pod の eth0 と veth (caliXXXXX) interface のアーキテクチャは Calico のま ま • デフォルトが 169.254.1.1 を向き、proxy ARP • cni0 bridge interface は作られるが caliXXXXX interface は繋ぎ込まれない • 他ノードへの経路のルーティングアーキテクチャは flannel のまま • 他ノードへの onlink な経路と静的 ARP 設定 • 「Calico の オーバーレイネットワーク部分を flannel で置き換えたアーキ テクチャ」と考えたほうが正しいかも node-01% ip route | grep 10.244 10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 linkdown 10.244.1.2 dev calia2a0356c6f4 scope link 10.244.1.3 dev cali4f3e8bf5e26 scope link 10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink node-01% arp -an | grep 10.244 ? (10.244.2.0) at 1a:39:5c:fa:9a:f1 [ether] PERM on flannel.1 ? (10.244.0.0) at 22:b3:69:58:45:f1 [ether] PERM on flannel.1 ? (10.244.1.9) at 0a:58:0a:f4:01:09 [ether] on cni0 cni0 (10.244.1.1/24) pod-01 caliXXXXX eth0 flannel.1 (10.244.1.0) ens160 pod-02 eth0 caliYYYYY node-01 pod-01% default via 169.254.1.1 dev eth0 169.254.1.1 dev eth0 scope link node-01 % cat /proc/sys/net/ipv4/conf/caliYYYYY/proxy_arp 1
  • 24. 26©2018 VMware, Inc. 機能 • ネットワーク接続性 • ネットワークポリシー • その他 特徴 • ネームスペースとの連動 • 可視化&トラブルシュート機能(カウンタ、ミラーリング、Traceflow、等) • VM ワークロードとの共存 • Load Balancer を提供 NSX-T Container Plugin (NCP)
  • 26. 28©2018 VMware, Inc. NSX-T NCP によるネットワーク(namespace との連動) pod-11 • NCP は K8S の namespace を監視 1. namespace が作成される 2. NSX-T が持つ IP block からサブ ネットが割り振られる 3. 論理スイッチが作成される 4. T1 ルータが作成され T0 ルータ と接続される 5. T1 にルータポートが作成され、 論理スイッチに接続され、IP ア ドレスがサブネットから振られ る 6. NAT するなら、T0 ルータに SNAT のルールを設定する pod-12 namespace: foo Hypervisor (ESXi or KVM) namespace: bar
  • 27. 29©2018 VMware, Inc. NSX-T NCP によるネットワーク(wiring) pod-11 • Node 外に仮想ネットワーク機能 (NSX- T) があるので、Node でオーバーレイを 終端する必要がない • Node VM の中で動作している OVS に VLAN Trunking してやるだけ • OVS は Standalone モードで動作 し、NCP によりプログラムされる • Cif (Container I/F) に対して DFW を適 用できるので、Pod 単位に Micro- Segmenation できる pod-12 Node-01 (VM) VLAN10 VLAN11OVS eth2 cifcif pod-21 pod-22 Node-02 (VM) VLAN10 VLAN11 OVS eth2 cifcif Hypervisor (ESXi or KVM) NSX-T
  • 28. 30©2018 VMware, Inc. OVS vs iptables パフォーマンス比較 出典:http://www.openvswitch.org/support/ovscon2014/17/1030-conntrack_nat.pdf
  • 29. 31©2018 VMware, Inc. iptables による Service Routing のパフォーマンス(1) 出典: https://www.slideshare.net/LCChina/scale-kubernetes-to-support-50000-services
  • 30. 32©2018 VMware, Inc. iptables による Service Routing のパフォーマンス(2) 出典: https://www.slideshare.net/LCChina/scale-kubernetes-to-support-50000-services
  • 31. 36©2018 VMware, Inc. Flannel Calico Project Canal NSX-T Container Plugin (NCP) Datastore K8S API (recommended), etcd etcd、K8S API (beta) K8S API (recommended), etcd NSX Manager Overlay Production: VXLAN, none (host-gw)、Experimental: IP-in-IP, IPsec None, IP-in-IP VXLAN, IP-in-IP, VCP routing (not recommended) Geneve (outside of worker node) Network Policy Mechanism - Iptables / Istio Iptables / Istio OVS / (n)vDS K8S Policy - Yes Yes Yes App Policy - HTTP method/path (requires Istio) HTTP method/path (requires Istio) No Load Balancer N-S - - - NSX LB E-W iptables iptables iptables OVS datapath VM Support No No No Yes Visibility Tools External External (prometheus) External (prometheus) Built-in (Traceflow, Mirroing, etc.) Commercial Support No Yes No? Yes 比較表
  • 32. 37©2018 VMware, Inc. コンテナ・ネットワーキング、闇多し  動きが早いので、Web の情報を信用してはいけない スケーラビリティには注意しよう! Key Takeaways
  • 33. 38©2018 VMware, Inc. Ubuntu: 18.04 (bionic) Kubernetes: v1.11.2 Docker: 18.06.1-ce Flannel: v0.10.0 Calico: 3.2.1 Canal: Calico 2.6.2 + Flannel v0.9.1 NSX-T: 2.1.0.0.7395503 今回テストに使ったバージョン