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

Motonori Shindo
©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.
ご静聴ありがとうござ
いました
1 of 34

Recommended

Dockerからcontainerdへの移行 by
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Kohei Tokunaga
16.6K views36 slides
Dockerからcontainerdへの移行 by
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Akihiro Suda
7.5K views36 slides
BuildKitによる高速でセキュアなイメージビルド by
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドAkihiro Suda
42.6K views27 slides
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~ by
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~NTT DATA OSS Professional Services
26K views43 slides
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料) by
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)NTT DATA Technology & Innovation
2.6K views53 slides
BuildKitの概要と最近の機能 by
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能Kohei Tokunaga
4.6K views34 slides

More Related Content

What's hot

コンテナ未経験新人が学ぶコンテナ技術入門 by
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門Kohei Tokunaga
140.3K views89 slides
Dockerfileを改善するためのBest Practice 2019年版 by
Dockerfileを改善するためのBest Practice 2019年版Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Masahito Zembutsu
63.7K views83 slides
OpenStackで始めるクラウド環境構築入門 by
OpenStackで始めるクラウド環境構築入門OpenStackで始めるクラウド環境構築入門
OpenStackで始めるクラウド環境構築入門VirtualTech Japan Inc.
34.5K views66 slides
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する by
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動するStargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動するKohei Tokunaga
1.5K views26 slides
10分でわかる Cilium と XDP / BPF by
10分でわかる Cilium と XDP / BPF10分でわかる Cilium と XDP / BPF
10分でわかる Cilium と XDP / BPFShuji Yamada
12K views20 slides
「おうちクラウド」が今熱い! by
「おうちクラウド」が今熱い!「おうちクラウド」が今熱い!
「おうちクラウド」が今熱い!Hirotaka Sato
1K views13 slides

What's hot(20)

コンテナ未経験新人が学ぶコンテナ技術入門 by Kohei Tokunaga
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga140.3K views
Dockerfileを改善するためのBest Practice 2019年版 by Masahito Zembutsu
Dockerfileを改善するためのBest Practice 2019年版Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
Masahito Zembutsu63.7K views
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する by Kohei Tokunaga
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動するStargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する
Kohei Tokunaga1.5K views
10分でわかる Cilium と XDP / BPF by Shuji Yamada
10分でわかる Cilium と XDP / BPF10分でわかる Cilium と XDP / BPF
10分でわかる Cilium と XDP / BPF
Shuji Yamada12K views
「おうちクラウド」が今熱い! by Hirotaka Sato
「おうちクラウド」が今熱い!「おうちクラウド」が今熱い!
「おうちクラウド」が今熱い!
Hirotaka Sato1K views
Linux女子部 systemd徹底入門 by Etsuji Nakai
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
Etsuji Nakai137.9K views
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料) by NTT DATA Technology & Innovation
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理 by NTT DATA Technology & Innovation
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
DockerとPodmanの比較 by Akihiro Suda
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda47.9K views
単なるキャッシュじゃないよ!?infinispanの紹介 by AdvancedTechNight
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight16K views
Kubernetesのワーカーノードを自動修復するために必要だったこと by h-otter
Kubernetesのワーカーノードを自動修復するために必要だったことKubernetesのワーカーノードを自動修復するために必要だったこと
Kubernetesのワーカーノードを自動修復するために必要だったこと
h-otter715 views
急速に進化を続けるCNIプラグイン Antrea by Motonori Shindo
急速に進化を続けるCNIプラグイン Antrea 急速に進化を続けるCNIプラグイン Antrea
急速に進化を続けるCNIプラグイン Antrea
Motonori Shindo1.7K views
Dockerfile を書くためのベストプラクティス解説編 by Masahito Zembutsu
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu84.4K views
コンテナセキュリティにおける権限制御(OCHaCafe5 #3 Kubernetes のセキュリティ 発表資料) by NTT DATA Technology & Innovation
コンテナセキュリティにおける権限制御(OCHaCafe5 #3 Kubernetes のセキュリティ 発表資料)コンテナセキュリティにおける権限制御(OCHaCafe5 #3 Kubernetes のセキュリティ 発表資料)
コンテナセキュリティにおける権限制御(OCHaCafe5 #3 Kubernetes のセキュリティ 発表資料)
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】 by Masahito Zembutsu
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Masahito Zembutsu82.3K views
コンテナにおけるパフォーマンス調査でハマった話 by Yuta Shimada
コンテナにおけるパフォーマンス調査でハマった話コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
Yuta Shimada2.2K views
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料) by NTT DATA Technology & Innovation
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
本当は恐ろしい分散システムの話 by Kumazaki Hiroki
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki686.1K views

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

FD.io VPP事始め by
FD.io VPP事始めFD.io VPP事始め
FD.io VPP事始めtetsusat
2.3K views19 slides
VPP事始め by
VPP事始めVPP事始め
VPP事始めnpsg
11.1K views19 slides
「さくらのクラウド」におけるVyattaの活用事例 by
「さくらのクラウド」におけるVyattaの活用事例「さくらのクラウド」におけるVyattaの活用事例
「さくらのクラウド」におけるVyattaの活用事例SAKURA Internet Inc.
13.4K views26 slides
Openvswitch vps 20120429資料 by
Openvswitch vps 20120429資料Openvswitch vps 20120429資料
Openvswitch vps 20120429資料Daisuke Nakajima
3.3K views31 slides
Lxc on cloud by
Lxc on cloudLxc on cloud
Lxc on cloudYukihiko SAWANOBORI
1.5K views25 slides
Container Networking Deep Dive by
Container Networking Deep DiveContainer Networking Deep Dive
Container Networking Deep DiveHirofumi Ichihara
11.2K views25 slides

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

FD.io VPP事始め by tetsusat
FD.io VPP事始めFD.io VPP事始め
FD.io VPP事始め
tetsusat2.3K views
VPP事始め by npsg
VPP事始めVPP事始め
VPP事始め
npsg11.1K views
「さくらのクラウド」におけるVyattaの活用事例 by SAKURA Internet Inc.
「さくらのクラウド」におけるVyattaの活用事例「さくらのクラウド」におけるVyattaの活用事例
「さくらのクラウド」におけるVyattaの活用事例
SAKURA Internet Inc.13.4K views
OpenContrailのソースコードを探検しよう! by Takashi Sogabe
OpenContrailのソースコードを探検しよう!OpenContrailのソースコードを探検しよう!
OpenContrailのソースコードを探検しよう!
Takashi Sogabe4.9K views
Using Kubernetes on Google Container Engine by Etsuji Nakai
Using Kubernetes on Google Container EngineUsing Kubernetes on Google Container Engine
Using Kubernetes on Google Container Engine
Etsuji Nakai2.9K views
Backdoor!! vmware-tools と 統合サービスに見るハイパーバイザの呼び出し方 by tshiroyama
Backdoor!! vmware-tools と 統合サービスに見るハイパーバイザの呼び出し方Backdoor!! vmware-tools と 統合サービスに見るハイパーバイザの呼び出し方
Backdoor!! vmware-tools と 統合サービスに見るハイパーバイザの呼び出し方
tshiroyama2K views
Lagopus + DockerのDPDK接続 by Tomoya Hibi
Lagopus + DockerのDPDK接続Lagopus + DockerのDPDK接続
Lagopus + DockerのDPDK接続
Tomoya Hibi4K views
Trema での Open vSwitch by kazuyas
Trema での Open vSwitchTrema での Open vSwitch
Trema での Open vSwitch
kazuyas10.4K views
How to apt-get from the internal network: remote sshd with kneesocks by inaz2
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
inaz23.6K views
宣言的(Declarative)ネットワーキング by Motonori Shindo
宣言的(Declarative)ネットワーキング宣言的(Declarative)ネットワーキング
宣言的(Declarative)ネットワーキング
Motonori Shindo1.1K views
Hadoop on LXC by 俊夫 森
Hadoop on LXCHadoop on LXC
Hadoop on LXC
俊夫 森3.4K views
近頃のDockerネットワーク by Yuji Oshima
近頃のDockerネットワーク近頃のDockerネットワーク
近頃のDockerネットワーク
Yuji Oshima5.1K views
VlanManagerを使ってみた by Hiroki Ishikawa
VlanManagerを使ってみたVlanManagerを使ってみた
VlanManagerを使ってみた
Hiroki Ishikawa2.7K views
Interrupt Affinityについて by Takuya ASADA
Interrupt AffinityについてInterrupt Affinityについて
Interrupt Affinityについて
Takuya ASADA13.2K views

More from Motonori Shindo

おうち Lab で GitDNSOps / GitDNS Ops in My Home Lab by
おうち Lab で GitDNSOps / GitDNS Ops in My Home Labおうち Lab で GitDNSOps / GitDNS Ops in My Home Lab
おうち Lab で GitDNSOps / GitDNS Ops in My Home LabMotonori Shindo
928 views11 slides
Tanzu Mission Control における Open Policy Agent (OPA) の利用 by
Tanzu Mission Control における Open Policy Agent (OPA) の利用Tanzu Mission Control における Open Policy Agent (OPA) の利用
Tanzu Mission Control における Open Policy Agent (OPA) の利用Motonori Shindo
524 views11 slides
Open Policy Agent (OPA) と Kubernetes Policy by
Open Policy Agent (OPA) と Kubernetes PolicyOpen Policy Agent (OPA) と Kubernetes Policy
Open Policy Agent (OPA) と Kubernetes PolicyMotonori Shindo
573 views36 slides
Open Policy Agent (OPA) 入門 by
Open Policy Agent (OPA) 入門Open Policy Agent (OPA) 入門
Open Policy Agent (OPA) 入門Motonori Shindo
1.4K views36 slides
Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用 by
Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用
Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用Motonori Shindo
1K views32 slides
Service Mesh for Enterprises / Cloud Native Days Tokyo 2019 by
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 2019Motonori Shindo
2.9K views20 slides

More from Motonori Shindo(19)

おうち Lab で GitDNSOps / GitDNS Ops in My Home Lab by Motonori Shindo
おうち Lab で GitDNSOps / GitDNS Ops in My Home Labおうち Lab で GitDNSOps / GitDNS Ops in My Home Lab
おうち Lab で GitDNSOps / GitDNS Ops in My Home Lab
Motonori Shindo928 views
Tanzu Mission Control における Open Policy Agent (OPA) の利用 by Motonori Shindo
Tanzu Mission Control における Open Policy Agent (OPA) の利用Tanzu Mission Control における Open Policy Agent (OPA) の利用
Tanzu Mission Control における Open Policy Agent (OPA) の利用
Motonori Shindo524 views
Open Policy Agent (OPA) と Kubernetes Policy by Motonori Shindo
Open Policy Agent (OPA) と Kubernetes PolicyOpen Policy Agent (OPA) と Kubernetes Policy
Open Policy Agent (OPA) と Kubernetes Policy
Motonori Shindo573 views
Open Policy Agent (OPA) 入門 by Motonori Shindo
Open Policy Agent (OPA) 入門Open Policy Agent (OPA) 入門
Open Policy Agent (OPA) 入門
Motonori Shindo1.4K views
Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用 by Motonori Shindo
Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用
Cluster API によるKubernetes環境のライフサイクル管理とマルチクラウド環境での適用
Motonori Shindo1K views
Service Mesh for Enterprises / Cloud Native Days Tokyo 2019 by Motonori Shindo
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
Motonori Shindo2.9K views
Idea Hackathon at vFORUM 2019 Tokyo by Motonori Shindo
Idea Hackathon at vFORUM 2019 TokyoIdea Hackathon at vFORUM 2019 Tokyo
Idea Hackathon at vFORUM 2019 Tokyo
Motonori Shindo1.5K views
Containers and Virtual Machines: Friends or Enemies? by Motonori Shindo
Containers and Virtual Machines: Friends or Enemies?Containers and Virtual Machines: Friends or Enemies?
Containers and Virtual Machines: Friends or Enemies?
Motonori Shindo2.9K views
Serverless Framework "Disptach" の紹介 by Motonori Shindo
Serverless Framework "Disptach" の紹介Serverless Framework "Disptach" の紹介
Serverless Framework "Disptach" の紹介
Motonori Shindo1.4K views
フロー技術によるネットワーク管理 by Motonori Shindo
フロー技術によるネットワーク管理フロー技術によるネットワーク管理
フロー技術によるネットワーク管理
Motonori Shindo10.7K views
ViptelaのSD-WANとクラウド最適化ネットワーク by Motonori Shindo
ViptelaのSD-WANとクラウド最適化ネットワークViptelaのSD-WANとクラウド最適化ネットワーク
ViptelaのSD-WANとクラウド最適化ネットワーク
Motonori Shindo3.3K views
OpenStack Congress and Datalog (English) by Motonori Shindo
OpenStack Congress and Datalog (English)OpenStack Congress and Datalog (English)
OpenStack Congress and Datalog (English)
Motonori Shindo3.3K views
OpenStack Congress and Datalog (Japanese) by Motonori Shindo
OpenStack Congress and Datalog (Japanese)OpenStack Congress and Datalog (Japanese)
OpenStack Congress and Datalog (Japanese)
Motonori Shindo2.4K views
L2 over l3 ecnaspsulations (english) by Motonori Shindo
L2 over l3 ecnaspsulations (english)L2 over l3 ecnaspsulations (english)
L2 over l3 ecnaspsulations (english)
Motonori Shindo9.8K views
L2 over L3 ecnaspsulations by Motonori Shindo
L2 over L3 ecnaspsulationsL2 over L3 ecnaspsulations
L2 over L3 ecnaspsulations
Motonori Shindo38.9K views
VMware NSXがサポートするトンネル方式について by Motonori Shindo
VMware NSXがサポートするトンネル方式についてVMware NSXがサポートするトンネル方式について
VMware NSXがサポートするトンネル方式について
Motonori Shindo4.2K views
CloudStack 4.1 + NVP Integration by Motonori Shindo
CloudStack 4.1 + NVP IntegrationCloudStack 4.1 + NVP Integration
CloudStack 4.1 + NVP Integration
Motonori Shindo772 views

コンテナネットワーキング(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 今回テストに使ったバージョン