コンテナネットワーキング（CNI）最前線

©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

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）

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)

1. 全てのコンテナは他コンテナと NAT なしで通信できること
2. 全てのノードは全てのコンテナと NAT なしで通信できること
3. コンテナから見える自分の IP アドレスと他から見た場合と同じであること
Kubernetes がネットワークに求める要件

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

機能
• ネットワーク接続性
特徴
• さまざまな back end をサポート
– Official: VXLAN, host-gw, UDP
– Experimental: AliVPC, Alloc, AWS VPCs, GCE, IPIP, IPsec
Flannel

Flannel のアーキテクチャ
flanneld
FIB
etcd
Orchestrator
Plugin
userland
kernel
Node

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
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

機能
• ネットワークポリシー
特徴
• 複数のオーケストレーションに対応（OpenStack, Kubernetes, etc.）
• Encapsulation が必要ない（IP-in-IP を使うことはできる）
• BGP（BIRD, gobgp）で経路を広告
• ポリシーは iptables で実現
• ポリシー部分だけ使うことも可能（e.g. Canal）
• IPv6 対応
Project Calico

Calico アーキテクチャ（コンポーネント）
Felix
BGP Client
(BIRD)
BGP RR (optional)
(BIRD)
ACL FIB
etcd
Orchestrator
Plugin
confd
userland
kernel
Node

Calico によるネットワーク（ノード間）
master node-01 node-02
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
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

Calico によるネットワーク（ノード内）
pod-01
ens160
caliXXXXX
eth0
pod-02
caliYYYYY
eth0
veth-pair veth-pair
pod-01-container% ip route
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
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

いわゆる 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

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)
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)
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)
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)
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

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

Canal によるネットワーク
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 で置き換えたアーキ
テクチャ」と考えたほうが正しいかも
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
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
node-01 % cat
/proc/sys/net/ipv4/conf/caliYYYYY/proxy_arp
1

機能
• ネットワークポリシー
• その他
特徴
• ネームスペースとの連動
• 可視化＆トラブルシュート機能（カウンタ、ミラーリング、Traceflow、等）
• VM ワークロードとの共存
• Load Balancer を提供
NSX-T Container Plugin (NCP)

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

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

OVS vs iptables パフォーマンス比較
出典：http://www.openvswitch.org/support/ovscon2014/17/1030-conntrack_nat.pdf

iptables による Service Routing のパフォーマンス（１）
出典： https://www.slideshare.net/LCChina/scale-kubernetes-to-support-50000-services

iptables による Service Routing のパフォーマンス（２）
出典： https://www.slideshare.net/LCChina/scale-kubernetes-to-support-50000-services

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
比較表

コンテナ・ネットワーキング、闇多し 
動きが早いので、Web の情報を信用してはいけない
スケーラビリティには注意しよう！
Key Takeaways

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
今回テストに使ったバージョン

コンテナネットワーキング（CNI）最前線

Recommended

More Related Content

What's hot (20)

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

More from Motonori Shindo (19)

コンテナネットワーキング（CNI）最前線