Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Illustrated Guide To Kubernetes Networking
Tim Hockin
September 21, 2016
Technology
93
50k
Illustrated Guide To Kubernetes Networking
A short walk through of some ideas around container networking.
Tim Hockin
September 21, 2016
Tweet
Share
More Decks by Tim Hockin
See All by Tim Hockin
Kubernetes Pod Probes
thockin
5
2.2k
Go Workspaces for Kubernetes
thockin
1
670
Code Review in Kubernetes
thockin
1
1.1k
Multi-cluster: past, present, future
thockin
0
200
Kubernetes Controllers - are they loops or events?
thockin
11
2.7k
Kubernetes Network Models (why is this so dang hard?)
thockin
9
1.4k
KubeCon EU 2020: SIG-Network Intro and Deep-Dive
thockin
8
1k
A Non-Technical Kubernetes Talk (KubeCon EU 2020)
thockin
3
490
Bringing Traffic Into Your Kubernetes Cluster
thockin
44
11k
Other Decks in Technology
See All in Technology
PCI DSS に準拠したシステム開発
yutadayo
0
180
グローバルチームことはじめ / Bootstrapping a global team
tasshi
1
530
Pentesting Password Reset Functionality
anugrahsr
0
180
Virtual Thread - 導入の背景と、効果的な使い方 -
skrb
3
230
lt53
98_justdoit
0
110
AKIBA.SaaS資料
yasumuusan
0
150
EMになって最初の失敗談 - コミュニケーション編 -
fukuiretu
1
320
Airdrop for Open Source Projects
epicsdao
0
210
Janus
bkuhlmann
0
120
1つのアプリを開発する複数の職能横断チームの運用と今後 ~ タクシーアプリ「GO」の現状と未来 ~
takahia1988
1
3.3k
Astroで始める爆速個人サイト開発
takanorip
12
8.2k
UNIX は知らない。でも AWS は知ってる。 そんな僕が『 UNIX という考え方』を 読んでみた件
kentosuzuki
1
270
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
213
7.8k
Learning to Love Humans: Emotional Interface Design
aarron
263
38k
Clear Off the Table
cherdarchuk
79
290k
Teambox: Starting and Learning
jrom
124
7.9k
GitHub's CSS Performance
jonrohan
1020
430k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
22
1.7k
How to Ace a Technical Interview
jacobian
270
21k
How STYLIGHT went responsive
nonsquared
89
4.2k
The Invisible Side of Design
smashingmag
292
48k
Support Driven Design
roundedbygravity
88
8.9k
The Invisible Customer
myddelton
113
12k
Reflections from 52 weeks, 52 projects
jeffersonlam
338
18k
Transcript
Google Cloud Platform An Illustrated Guide to Kubernetes Networking Tim
Hockin <
[email protected]
> Senior Staff Software Engineer @thockin
Google Cloud Platform Layer 2: ethernet
Google Cloud Platform node-a node-c node-b node-d 192.168.1.1/16 11:22:33:44:55:01 192.168.1.2/16
01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04 L2 switch
Google Cloud Platform node-a node-c node-b node-d L2 to: 192.168.1.3
from: 192.168.1.1 GET / 192.168.1.1/16 11:22:33:44:55:01 192.168.1.2/16 01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04
Google Cloud Platform node-d node-b node-a node-c L2 to: <broadcast>
from: 11:22:33:44:55:01 who has 192.168.1.3? to: 192.168.1.3 from: 192.168.1.1 GET / 192.168.1.1/16 11:22:33:44:55:01 192.168.1.2/16 01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04 “ARP request”
Google Cloud Platform node-a node-c node-b node-d L2 to: 192.168.1.3
from: 192.168.1.1 GET / 192.168.1.1/16 11:22:33:44:55:01 192.168.1.2/16 01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04 to: 11:22:33:44:55:01 from: 11:22:33:44:55:03 I have 192.168.1.3 “ARP response”
Google Cloud Platform node-a node-c node-b node-d L2 to: 192.168.1.3
via: 11:22:33:44:55:03 from: 192.168.1.1 GET / 192.168.1.1/16 11:22:33:44:55:01 192.168.1.2/16 01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04
Google Cloud Platform node-a root netns eth0: 192.168.1.1/16 11:22:33:44:55:01 L2
with containers cbr0: 10.0.1.1/24 ctr-1 eth0: 10.0.1.2/24 ctr-2 eth0: 10.0.1.3/24 ctr-3 eth0: 10.0.1.4/24
Google Cloud Platform node-a 192.168.1.1/16 11:22:33:44:55:01 node-c node-b node-d 192.168.1.2/16
01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04 L2 ctr-1 10.0.1.2 aa:bb:cc:dd:e1:01 ctr-2 10.0.3.2 aa:bb:cc:dd:e3:02
Google Cloud Platform node-a 192.168.1.1/16 11:22:33:44:55:01 node-c node-b node-d 192.168.1.2/16
01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04 L2 ctr-1 10.0.1.2 aa:bb:cc:dd:e1:01 ctr-2 10.0.3.2 aa:bb:cc:dd:e3:02 to: 10.0.3.2 from: 10.0.1.2 GET /
Google Cloud Platform node-a 192.168.1.1/16 11:22:33:44:55:01 node-c node-b node-d 192.168.1.2/16
01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04 L2 ctr-1 10.0.1.2 aa:bb:cc:dd:e1:01 ctr-2 10.0.3.2 aa:bb:cc:dd:e3:02 to: 10.0.3.2 from: 10.0.1.2 GET / to: <broadcast> from: aa:bb:cc:dd:e1:01 who has 10.0.3.2? “ARP request”
Google Cloud Platform node-a 192.168.1.1/16 11:22:33:44:55:01 node-c node-b node-d 192.168.1.2/16
01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04 L2 ctr-1 10.0.1.2 aa:bb:cc:dd:e1:01 ctr-2 10.0.3.2 aa:bb:cc:dd:e3:02 to: 10.0.3.2 from: 10.0.1.2 GET / to: aa:bb:cc:dd:e1:01 from: 11:22:33:44:55:03 I have 10.0.3.2 “proxy ARP response”
Google Cloud Platform node-a 192.168.1.1/16 11:22:33:44:55:01 node-c node-b node-d 192.168.1.2/16
01:23:45:67:89:02 192.168.1.3/16 11:22:33:44:55:03 192.168.1.4/16 01:23:45:67:89:04 L2 ctr-1 10.0.1.2 aa:bb:cc:dd:e1:01 ctr-2 10.0.3.2 aa:bb:cc:dd:e3:02 to: 10.0.3.2 via: 11:22:33:44:55:03 from: 10.0.1.2 GET /
Google Cloud Platform Layer 3 - IP
Google Cloud Platform node-a node-c node-b node-d 192.168.1.1/32 192.168.1.2/32 192.168.1.3/32
192.168.1.4/32 L3 gateway
Google Cloud Platform node-a node-c node-b node-d 192.168.1.1/32 192.168.1.2/32 192.168.1.3/32
192.168.1.4/32 L3 to: 192.168.1.3 from: 192.168.1.1 GET /
Google Cloud Platform node-a node-c node-b node-d 192.168.1.1/32 192.168.1.2/32 192.168.1.3/32
192.168.1.4/32 L3 to: 192.168.1.3 from: 192.168.1.1 GET /
Google Cloud Platform node-a node-c node-b node-d 192.168.1.1/32 192.168.1.2/32 192.168.1.3/32
192.168.1.4/32 L3 to: 192.168.1.3 from: 192.168.1.1 GET / routing decision, static or learned (e.g. BGP)
Google Cloud Platform node-a 192.168.1.1/32 node-c node-b node-d 192.168.1.2/32 192.168.1.3/32
192.168.1.4/32 L3 ctr-1 10.0.1.2 ctr-2 10.0.3.2
Google Cloud Platform node-a 192.168.1.1/32 node-c node-b node-d 192.168.1.2/32 192.168.1.3/32
192.168.1.4/32 L3 ctr-1 10.0.1.2 ctr-2 10.0.3.2 to: 10.0.3.2 from: 10.0.1.2 GET /
Google Cloud Platform node-a 192.168.1.1/32 node-c node-b node-d 192.168.1.2/32 192.168.1.3/32
192.168.1.4/32 L3 ctr-1 10.0.1.2 ctr-2 10.0.3.2 to: 10.0.3.2 from: 10.0.1.2 GET /
Google Cloud Platform node-a 192.168.1.1/32 node-c node-b node-d 192.168.1.2/32 192.168.1.3/32
192.168.1.4/32 L3 ctr-1 10.0.1.2 ctr-2 10.0.3.2 to: 10.0.3.2 from: 10.0.1.2 GET / routing decision, static or learned (e.g. BGP)
Google Cloud Platform node-a 192.168.1.1/32 node-c node-b node-d 192.168.1.2/32 192.168.1.3/32
192.168.1.4/32 L3 ctr-1 10.0.1.2 ctr-2 10.0.3.2 to: 10.0.3.2 from: 10.0.1.2 GET /
Google Cloud Platform Overlays Q: When should I use an
overlay? A: When nothing else works, or when you have specific reasons to want it (e.g. the added value of management)
Google Cloud Platform node-a root netns eth0: 192.168.1.1/16 Overlay (e.g.
flannel, weave) cbr0: 10.0.1.1/24 ctr-1 eth0: 10.0.1.2/24 ctr-2 eth0: 10.0.1.3/24 ctr-3 eth0: 10.0.1.4/24 flannel0: 10.0.1.254/16
Google Cloud Platform node-a root netns eth0: 192.168.1.1/16 cbr0: 10.0.1.1/24
ctr-1 eth0: 10.0.1.2/24 ctr-2 eth0: 10.0.1.3/24 ctr-3 eth0: 10.0.1.4/24 flannel0: 10.0.1.254/16 to: 10.0.3.2 from: 10.0.1.2 GET / Overlay (e.g. flannel, weave)
Google Cloud Platform node-a root netns eth0: 192.168.1.1/16 cbr0: 10.0.1.1/24
ctr-1 eth0: 10.0.1.2/24 ctr-2 eth0: 10.0.1.3/24 ctr-3 eth0: 10.0.1.4/24 flannel0: 10.0.1.254/16 to: 10.0.3.2 from: 10.0.1.2 GET / Overlay (e.g. flannel, weave)
Google Cloud Platform node-a root netns eth0: 192.168.1.1/16 cbr0: 10.0.1.1/24
ctr-1 eth0: 10.0.1.2/24 ctr-2 eth0: 10.0.1.3/24 ctr-3 eth0: 10.0.1.4/24 flannel0: 10.0.1.254/16 to: 10.0.3.2 from: 10.0.1.2 GET / Overlay (e.g. flannel, weave)
Google Cloud Platform node-a root netns eth0: 192.168.1.1/16 cbr0: 10.0.1.1/24
ctr-1 eth0: 10.0.1.2/24 ctr-2 eth0: 10.0.1.3/24 ctr-3 eth0: 10.0.1.4/24 flannel0: 10.0.1.254/16 to: 192.168.1.3 from: 192.168.1.1 encap: to: 10.0.3.2 from: 10.0.1.2 GET / Overlay (e.g. flannel, weave)
Google Cloud Platform node-a 192.168.1.1/16 node-c node-b node-d 192.168.1.2/16 192.168.1.3/16
192.168.1.4/16 ctr-1 10.0.1.2 ctr-2 10.0.3.2 Overlay (e.g. flannel, weave)
Google Cloud Platform node-c root netns eth0: 192.168.1.3/16 cbr0: 10.0.3.1/24
ctr-4 eth0: 10.0.3.2/24 ctr-5 eth0: 10.0.3.3/24 ctr-6 eth0: 10.0.3.4/24 flannel0: 10.0.3.254/16 to: 192.168.1.3 from: 192.168.1.1 encap: to: 10.0.3.2 from: 10.0.1.2 GET / Overlay (e.g. flannel, weave)
Google Cloud Platform node-c root netns eth0: 192.168.1.3/16 cbr0: 10.0.3.1/24
ctr-4 eth0: 10.0.3.2/24 ctr-5 eth0: 10.0.3.3/24 ctr-6 eth0: 10.0.3.4/24 flannel0: 10.0.3.254/16 to: 10.0.3.2 from: 10.0.1.2 GET / Overlay (e.g. flannel, weave)
Google Cloud Platform node-c root netns eth0: 192.168.1.3/16 cbr0: 10.0.3.1/24
ctr-4 eth0: 10.0.3.2/24 ctr-5 eth0: 10.0.3.3/24 ctr-6 eth0: 10.0.3.4/24 flannel0: 10.0.3.254/16 to: 10.0.3.2 from: 10.0.1.2 GET / Overlay (e.g. flannel, weave)
Google Cloud Platform Overlays - the hard part
Google Cloud Platform node-a 192.168.1.1/16 node-c non-node node-d 192.168.1.2/16 192.168.1.3/16
192.168.1.4/16 ctr-1 10.0.1.2 ctr-2 10.0.3.2 Overlay (e.g. flannel, weave)
Google Cloud Platform node-a 192.168.1.1/16 node-c non-node node-d 192.168.1.2/16 192.168.1.3/16
192.168.1.4/16 ctr-1 10.0.1.2 ctr-2 10.0.3.2 to: 10.0.3.2 from: 192.168.1.2 GET / Overlay (e.g. flannel, weave)
Google Cloud Platform node-a 192.168.1.1/16 node-c non-node node-d 192.168.1.2/16 192.168.1.3/16
192.168.1.4/16 ctr-1 10.0.1.2 ctr-2 10.0.3.2 to: 10.0.3.2 from: 192.168.1.2 GET / Overlay (e.g. flannel, weave)
Google Cloud Platform node-a 192.168.1.1/16 node-c non-node node-d 192.168.1.2/16 192.168.1.3/16
192.168.1.4/16 ctr-1 10.0.1.2 ctr-2 10.0.3.2 to: 10.0.3.2 from: 192.168.1.2 GET / ?!?! Overlay (e.g. flannel, weave)
Google Cloud Platform We need a bridge between the physical
and overlay networks...
Google Cloud Platform We need a bridge between the physical
and overlay networks... • could: route to nodes • could: route to 1 or more bridge machines • could: run flannel on client machines
Google Cloud Platform We need a bridge between the physical
and overlay networks... • could: route to nodes • could: route to 1 or more bridge machines • could: run flannel on client machines • see “When should I use an overlay?”