►
From YouTube: Tutorial: Communication Is Key - Understanding Kubernetes Networking - Jeff Poole, Vivint Smart Home
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Tutorial: Communication Is Key -- Understanding Kubernetes Networking - Jeff Poole, Vivint Smart Home
Networking in Kubernetes has several aspects, including DNS, iptables, routing, software bridges, IP assignment, network policies, etc. While the practices for understanding the network were fairly easy to translate from physical servers to virtual machines, the level of complexity increases greatly when moving to containers in Kubernetes. This tutorial will explain several of the networking concepts used in Kubernetes with accompanying lab exercises in a virtualized environment so that participants will become comfortable looking under the hood at how a Kubernetes cluster is working (or not working, as the case may be). The material will be designed for people comfortable with SSH, bash, kubectl, and basic networking concepts, and will fill in the more advanced networking knowledge as the tutorial progresses. Please have Vagrant + VirtualBox installed to run the labs locally.
https://sched.co/Zej8
A
A
Kubernetes
is
a
distributed
system,
so
it
relies
heavily
on
networking
like
all
distributed
systems,
but
kubernetes
is
also
very
plugable.
You
can
change
all
sorts
of
things
about
it,
including
the
networking
plugins.
You
can
change
whether
it
uses
ip
tables
or
ebpf,
there's
all
sorts
of
knobs
that
you
can
tune
in
kubernetes
in
terms
of
the
networking
stack,
which
makes
it
even
more
complicated
than
a
normal
distributed
system
that
has
fairly
fixed
networking
protocols
and
standards.
A
So
this
makes
it
challenging
to
understand.
The
goal
of
this
tutorial
is
to
demonstrate
how
things
are
supposed
to
work,
to
also
gain
show
you
how
to
gain
visibility
into
how
it
is
working
and
learn
how
to
debug
networking
issues
in
kubernetes
as
a
result
and
application
issues
that
could
have
a
networking
aspect
to
them.
A
A
A
Footloose
is
a
tool
from
weaveworks
that
lets.
You
spin
up
a
bunch
of
docker
images
that
look
like
virtual
machines,
and
so
this
is
the
lightest
weight
way
to
get
a
kubernetes
cluster
up
and
running
on
your
machine.
One
of
the
problems
I
ran
into
when
I
was
trying
out
different
environments
for
this
is
that
the
amount
of
resources
it
can
take
to
run
several
virtual
machines.
At
the
same
time
it
can
be
intense
and
I
can't
make
any
assumptions
about
what
kind
of
hardware
people
are
running
with.
A
So
I
can't
be
like
oh
well,
everyone
out
there's
got
32
gigs
of
ram,
so
you
know
no
problem.
If
we
give
four
gigs
to
each
vm,
that's
probably
not
a
viable
option.
So
this
is
the
lightweight
lightest
weight
way
to
do
it.
The
biggest
downsides
of
this
other
than
having
to
have
footloose
running
is
that
there
are
some
weird
interactions
between
the
containers
and
the
kernel
of
the
host,
for
example
iptables.
A
If
the
kernel
the
host
doesn't
match
the
version
that
iptables
and
the
container
expects
sometimes
you'll
see
some
weird
results,
so
that
can't
happen
now
if
you've
got
a
working,
vagrant
and
virtualbox
setup,
I
also
have
a
vagrant
file
that
should
work.
That
said,
it
has
been
tested
to
the
bare
minimum.
A
A
You
probably
can
do
all
these
demonstrations
on
other
kubernetes
clusters,
but
if
you
want
to
do
the
exact
same
stuff,
I'm
doing
in
the
same
environment,
I'm
doing
it
then
this
is.
This
is
the
best
way
to
go.
Obviously,
you're
probably
not
going
to
get
your
production
kubernetes
cluster
and
swap
out
the
networking
layer.
A
So
there
are
some
things
that
would
be
hard
to
do
in
environments
that
people
are
depending
on,
but
certainly
if
you
wanted
to
spin
up
sets
of
vms
in
different
environments,
you
could
probably
replicate
these
without
using
my
tools
at
all,
I'm
using
k3s.
As
my
kubernetes
layer,
it's
a
little
bit
different
from
vanilla
kubernetes.
However,
it's
lighter
weight
and
very
fast
to
start
up
and
for
a
networking
perspective,
it
looks
very
close,
there's
also
a
project
k3d,
which
is
designed
to
run
like
k3s,
except
in
docker.
A
A
A
A
If
you're
in
an
environment
where
that
won't
work
or
you
need
to
have
a
pristine
outer
environment,
there's
a
few
cases
where
this
will
matter.
For
example,
if
you
look
at
ip
tables
in
a
docker-based
virtual
machine
running
footloose
and
your
kernel
doesn't
match,
what's
in
your
host
machine,
you
sometimes
get
some
weird
results.
A
A
A
A
A
So
let's
say
we
want
to
send
a
packet
via
arbitrarily
say:
udp
could
be
tcp
just
as
easily,
but
we
start
with
some
data
and
then
we
wrap
that
in
a
udp
packet,
so
there's
a
udp
header
and
then
a
payload
of
data
and
then
the
udp
or
tcp
portion
has
the
source
destination
ports.
That's
part
of
the
udp
or
tcp
level,
which
is
layer
four.
A
A
A
If
it's
just
an
intermediate
hop
it'll
look
at
the
ip
packet
figure
out.
What
the
next
hop
should
be
to
get
to
that
destination,
which
may
or
may
not
be
the
final
destination.
But
it's
the
next
hop
that
is
reachable
on
the
local
network
and
it
will
put
a
new
ethernet
header
on
there
with
its
address
as
a
source
address
and
that
next
top
as
the
destination
address.
A
This
means
that
they
don't
have
access
to
the
host
network
adapters
by
default
and
network
name
spaces.
Allow
you
to
isolate
networking
functionality,
the
there's
a
default
network
name,
space
often
referred
to
as
the
root
network
namespace,
and
that's
where
everything
is
by
default.
Unless
you
put
it
in
a
different
network
namespace.
A
When
docker
comes
up,
it
creates
a
bridge
device
generally
called
docker
zero
and
it
allocates
a
block
of
ips
to
containers
the
defaults
172.17
16..
So
that
means
the
last
two
octets
are
available
for
containers
in
this
bridge
device.
It
operates
like
an
ethernet
switch
running
in
software,
so
that
bridge
gets
attached
to
the
host
network
interface
and
docker
will
create
a
new
network
namespace
for
each
container.
It's
trying
to
create
I'm
putting
two
here
just
to
demonstrate
a
little
bit
better
now.
Docker
will
then
create
a
virtual
ethernet
pair.
A
A
It
then
gets
assigned
an
ip
from
the
range
of
ip
addresses
that
that
are
associated
with
that
bridge,
and
then
this
means
that
the
different
containers
have
interfaces
within
the
same
subnet,
but
with
different
ips.
So
they
can
talk
to
each
other
across
that
bridge.
Just
like
two
devices
on
the
same
subnet
with
different
ips
can
talk
to
each
other
across
an
ethernet
switch.
A
Traditionally
docker
doesn't
really
expose
those
container
ips
anything
off
the
host
containers
or
raw
there's.
There's
all
sorts
of
solutions
for
this
and
docker
swarm
obviously
has
some
solutions.
You
can
do
port
forwarding,
but
it's
not
really
part
of
the
base.
Docker
functionality,
so
getting
traffic
to
and
from
containers
on
on
other
machines
is
one
of
the
problems
that
kubernetes
needs
to
solve
to
make
this
useful
across
a
cluster
of
machines.
A
A
A
A
A
A
A
A
A
Another
thing
you
can
look
at
if
I
was
to
look
it
inside
that
other
container
you
can
see
its
ip
address
is
172.17.0.2
in
this
container.
I
can
go
ahead
and
ping
that,
and
what
happens
is
it
can
reach
that
other
host
through
the
bridge
they're
on
the
same
subnet?
So
they
because
they're
on
the
same
segment
there's
actually
an
arp
request
that
goes
through.
If
I
do
a.
A
If
I
show
my
ip
neighbor
table,
you
can
see
that
I
see
that
172.17.0.2
ip
address
and
I've
got
a
mac
address
for
it.
That
is
what
we
see.
In
fact,
if
I
look
in
the
other
container,
that
is
the
mac
address,
it
showed
there,
so
you
can
see
that
just
like
two
devices
plugged
into
a
switch
on
a
normal
network,
these
two
containers
can
see
each
other
across
the
bridge.
A
For
node
addresses
it's
pretty
simple:
every
every
node
every
machine
needs
an
ip
address.
This
is
used
for
nodes
to
talk
to
each
other
and
the
outside
world,
and
it
exists
before
kubernetes
is
set
up.
It's
really
outside
the
scope
of
kubernetes,
and
it's
designed
by
some
outside
process.
You
know,
dhcp
is
an
option
can
be
manual,
a
cloud
provider
might
just
magically
assign
it
somehow,
and
you
just
know
it
has
an
ip
when
it
boots
up,
doesn't
really
matter.
A
So
pod
addresses
to
review
how
kubernetes
works
in
kubernetes.
A
pod
consists
of
one
or
more
containers
sharing
the
same
network
name
space,
so
they
have
that
same
virtual
ethernet
device
as
their
e0
in
the
kubernetes
network
model.
Every
pod
receives
its
own
ip
address,
and
the
idea
is
that
all
these
ip
addresses
are
globally
routable
within
the
cluster.
So
any
pod
can
talk
to
any
other
pod,
no
matter
what
machine
it's
on.
A
These
addresses
are
going
to
be
allocated
through
the
ipm
functionality.
Ip
address
management
of
the
cni
container
network
interface,
plugins
you're,
using
the
most
basic
method,
is
assigning
a
subnet
to
each
node
and
then
allowing
that
node
to
just
hand
out
ips
from
that
subnet
because
it
knows
which
ones
are
in
use
on
on
itself,
and
so
it
requires
very
little
coordination
other
than
assigning
a
unique
subnet
when
the
node
gets
set
up
in
the
first
place.
A
The
cube
api
server
process
has
a
cluster
sider
flag,
which
tells
kubernetes
what
the
range
of
expected
pod
ips
are
across
the
cluster
okay,
now
services,
the
kubernetes
service
is
an
abstraction
over
a
set
of
pods.
It's
something
that
you
can
talk
to
and
get
a
pod
behind
it
without
having
to
know
how
many
pods
are
there.
If
there's
even
more
than
one,
if
it's
on
your
host
or
different
host
doesn't
matter,
all
non-headless
services
will
have
a
cluster
ip
assigned
to
them.
A
A
A
A
A
A
I
use
footloose
ssh
to
shell
into
node
0
and
I
run
the
k3s
installer
so
that
that
could
set
up
as
a
master
we're
using
k3s
because
it's
a
lighter
weight,
distribution
of
kubernetes
and
while
it's
got
a
few
quirks
such
as
it
doesn't
use
scd
by
default,
it's
a
compliant
kubernetes
distribution
and
its
network.
Behavior
is
very
similar
to
what
you
would
expect
from
a
normal
kubernetes
distribution.
So
it's
a
pretty
good
tool
for
this
purpose.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
But
if
the
traffic
was
from
outside
the
kubernetes
cluster
or
you're,
not
a
pod,
then
we
probably
need
to
force
it
to
go
through
the
current
node,
just
to
make
sure
that
it's
handling
both
directions
of
traffic.
So
it
can
reverse
the
nat,
and
if
it's
coming
from
the
destination
pod
itself,
we
need
to
sort
of
force
it
to
go
through
the
node.
So
it
doesn't
try
to
take
a
shortcut
and
skip
that
that
natting
phase.
A
So
that's
how
services
work
with
iptables?
Okay,
let's
talk
about
flannel
a
little
bit
so
flannel's,
one
of
the
earliest
networking
plugins
and
it's
a
decent
choice
for
small
clusters.
There
are
some
issues
when
you
get
too
large
in
terms
of
having
to
make
sure
your
table.
Size
is
large
enough,
and
it's
really
the
same
reasons
why
you
don't
make
one
ethernet
subnet
or
you
know,
ethernet
lan
too
big,
but
for
small
to
medium-sized
clusters.
Just
fine.
A
It's
also
the
default
for
k3s,
which
makes
it
a
great
place
for
us
to
start,
because
we
don't
have
to
do
anything
special
to
configure
it.
Flannel
runs
on
layer,
2,
ethernet
and
the
networking
stack.
So
all
the
pods
can
talk
via
ethernet
as
opposed
to
only
ip.
So
you
don't
have
to
necessarily
use
an
ip-based
protocol
to
talk
between
pods.
A
Flannel
uses
a
pod
subnet,
that's
statically
assigned
each
kubernetes
node
when
it
comes
to
ip
address
management,
so
pod
ip
allocation
decisions
are
local
to
the
node
super
simple.
The
default
encapsulation
for
flannel
is
vxlan,
which
involves
wrapping
a
layer,
2
ethernet
packet
inside
a
udp
packet.
So
you
have
your
ip
packet,
typically
wrapped
in
ethernet,
which
then
gets
wrapped
in
udp,
which
gets
wrapped
in
ip,
which
gets
wrapped
in
ethernet.
A
A
A
A
A
A
A
A
A
A
A
A
A
So
you
may
wonder:
I'm
looking
at
port
8472,
oh
you'll,
see
in
a
moment,
okay,
so
our
pods
are
running.
So
let's
do
a
cube,
control
exec,
let's
go
into
the
pod
locally,
because
we
want
to
see
stuff
on
this
node.
So
I
want
to
make
sure
I
don't
totally
involve
unrelated
pods
and
then,
let's
just
do
a
curl.
A
A
A
This
node
sent
one
sent
another
received,
one
send
one
okay,
so
you
look
at
this
and
you
think
what
in
the
world's
going
on
here,
this
isn't
very
useful
and
that's
true.
So
what
we're
seeing
here
is
the
vxlan
traffic
by
default.
Flannel
is
going
to
use
port
8472
for
its
vxlan
traffic,
but,
as
you
can
see
here,
all
we
can
tell
is
two
nodes:
are
exchanging
udp
packets.
A
A
We
got
a
syn
ack
back,
which
is
the
next
part
in
the
handshake.
An
act
gets
sent
and
then
because
t-shark
and
wireshark
have
advanced
packet
dissectors,
they
can
dig
in
there
and
go
hey.
This
was
actually
an
http
request,
getting
slash,
and
then
you
can
see
that
we
got
a
response
of
a
200
okay
and
then
the
connection
got
torn
down
so
by
actually
telling
it
to
get
these
udp
packets
interpret
them
as
vxlan.
We
can
see
what's
inside
them
and
for
an
extra
level
of
detail.
A
A
A
Hey
look
it
interpreted
that
as
virtual
extensible,
local
area,
network
or
vxlan,
and
so
you
can
read
the
details
of
vxlan
packet,
there's
not
a
whole
lot
of
data
there.
The
main
thing
that
you
might
care
about,
if
you
run
multiple
vxlan
networks,
is
that
the
vxlan
network
id
vni
is
right
here,
so
the
vni
of
one
that's
a
default.
A
You
can
change
it
if
you
have
multiple
vxl
networks,
but
that
that
helps
you
separate
traffic.
If
you
need
to
inside
the
vxlan
packet
is
an
ethernet
packet.
Remember
vxlan
encapsulates
layer,
two
packets,
so
it
encapsulates
the
entire
ethernet
packet.
This
is
interesting
because
there's
some
protocols,
you
can't
run
over
ip
alone,
so
things
that
rely
on
like
multicast
or
you
know
like
dhcp.
You
can't
run
over
ip.
It
runs
over
over
ethernet,
so
we
have
an
ethernet
pack
inside
our
vxlan
packet.
A
A
So
we
had
ip
packets
between
the
nodes
that
had
udp
payloads
that
were
interpreted
as
vxlan,
that
had
ethernet
packets
that
had
ip
packets
between
the
pods,
and
you
can
see
also
that
inside
this
ip
packet
is
tcp
because
http
requests
are
tcp,
so
vxlan
uses
udp
on
the
outside.
But
when
you
dig
all
the
way
in
you're
actually
seeing
tcp
packets
in
the
middle.
A
And
then
t-sharp
can
give
you
all
sorts
of
information,
and
then
here
we
have
the
next
frame,
which
is
another
ethernet
packet
with
another
ip
packet
in
it,
this
one
from
our
destination.
Node
back
to
the
node,
we
sent
the
request
from
inside.
That's
a
udp
packet,
going
to
port
8472
note
for
vxlan.
It's
always
the
destination
port
is
8472,
the
source
port
is
random
or
at
least
consistently
defined
it.
The
source
port
can
be
anything.
A
Here's
our
vxlan
information
that
we
found
inside
the
udp
packet
inside
that
another
ethernet
frame,
another
ipv4
ipv4
packet,
with
the
source
being
the
pod
that
was
running
the
http
server
and
the
destination
being
where
our
client
was
running
inside.
That's
a
tcp
packet
now,
in
this
case
the
source,
ports
8080,
because
we
we
made
a
request
to
8080
and
is
sending
a
response
back,
and
you
can
see
that
this
one
is
a
connection
established,
acknowledge,
send
plus
ack
packet.
A
But
if
you
really
want
to
know
everything
that's
going
on,
you
can
actually
dissect
the
whole
packets,
and
you
can
also
do
this
by
saving
a
pcap
file
and
loading
in
wireshark.
If
you
don't
want
all
this
information
spewing
to
your
console-
and
you
can
use
that
to
see
everything
that
happened
inside,
so
you
can
see
the
outside
packet,
the
vxlan
information
and
the
inside
packet-
and
you
know
you
can
also
use
this
to
display
the
payload
if
you
need
to,
and
that
should
cover
the
basics
of
flannel
and
vxlan
now
onto
calico.
A
So
calico
is
easily
the
most
common
networking
plug-in
with
tigera,
which
is
the
company
behind
it,
claiming
that
you
can
use
to
some
degree
at
least
implied
for
network
policies.
In
most
cloud
provider,
kubernetes
environments
runs
at
layer,
3
ipm,
the
networking
stack,
so
only
ip
traffic
can
be
encapsulated
and
everything
is
routed.
There's
no
way
to
broadcast
ethernet
packets
across
your
calico,
your
calico
layer
for
ipm
calico.
A
Actually,
each
node
goes
and
asks
either
the
kubernetes
api
server
or
its
own
lcd
cluster
for
a
block
of
ip
addresses
that
can
allocate
out,
but
it
can
keep
going
back
for
more
blocks
of
ip
addresses
as
needed.
So
it
is
nice
because
it
lets
you
dynamically
adjust
how
many
ip
addresses
are
allocated
to
each
node
and
then,
as
far
as
encapsulation,
the
default
encapsulation
for
calco
is
ip
and
ip,
which
involves
wrapping
a
layer
3
ip
packet
inside
an
extra
ip
header.
So
it's
very
low
overhead.
A
A
A
The
k8s
net
labs
get
repo,
there's
a
calico
folder.
This
one
has
a
simple
bootstrap
calico,
so
just
like
bringing
up
the
footloose
one
or
the
just
like
bringing
up
the
flannel
one.
It's
does
everything,
for
you
creates
a
docker
network.
It
makes
sure
the
image
is
pulled,
it
creates
the
cluster
and
it
does
all
the
stuff
required
to
get
k3s
to
properly
initialize
on
the
master
and
have
the
other
nodes
connect
to
that
master.
A
A
A
A
A
A
A
A
A
Okay
and
now
we
actually
have
some
pods
starting
up,
and
in
particular
you
can
see.
We've
got
pod
initializing
on
calico
node,
zero,
one
and
two,
so
we'll
have
to
wait
a
moment
for
for
this
doll
startup,
because,
obviously,
until
calico
comes
up,
we're
not
going
to
have
a
whole
lot
of
luck,
getting
the
rest
of
our
pods
to
come
up.
A
A
A
A
A
The
calico
nodes
can
grab
as
much
ips
as
they
need
and
in
fact,
if
you
look
here,
you'll
see
that
we've
got
a
route
for
192.168.63.128
26.,
so
we're
with
flannel.
We
gave
a
simple
slash:
24,
which
means
the
the
whole
last
octet
is
usable
by
the
node.
Depending
on
how
you
want
to
count
it.
You
know:
254
ish,
usable
ips.
There
calico
actually
grabbed
two
fewer
bits
of
address
space,
so
this
one's
only
more
like
64-ish,
but
it
can
grab
as
many
of
those
reservations
as
it
needs.
A
A
A
A
A
Spits
out
to
be
clear,
calico
node
one
has
dot
three
for
things.
That
knows
that
are
in
node
one.
It
knows
what
the
ip
range
is
or
all
the
ipa
ranges
that
node
one
has
reserved,
so
it
sticks
around
and
that
says,
hey
for
anything
going
to
this
pod
range,
we're
gonna,
send
it
via
node
1,
dev
tunnel
0..
A
A
A
A
A
A
A
A
A
But
you
know
all
your
network
devices
are
going
to
be
routing
the
ip
packet.
So
unless
you've
got
some
sort
of
stateful
firewall,
that's
looking
for
the
type
of
protocol
or
digging
inside
the
ip
packet.
It's
going
to
go
it's
an
ip
packet.
I
know
how
to
send
that
to
the
next
hop
so
inside
the
outer
ip
packet
is
the
inner
ip
packet.
This
one
has
the
pod
ips
in
it
and
then
you'll
see
the
protocol
inside
that's
tcp,
because
it's
http
runs
over
tcp.
A
So
you've
got
there's
your
tcp
packet
destination
port
8080,
which
is
what
the
web
server
is
running
on
inside
these
pods,
and
then
you
can
dig
all
the
way
down
see
it.
Does
a
http
get
on
the
other
side,
the
same
thing
anytime
packet
with
an
ip
packet
going
between
the
nodes
and
then
inside.
That
is
another
ip
packet
going
between
the
pods
protocol
and
the
other
one
was
ipip
protocol
and
the
inner
one
is
tcp
and
then
tcp
packet.
This
is
the
response
coming
back
from
port
8080
and
it
has
a
response
in
it.
A
A
The
tcp
flags
there's
no
sin,
because
the
connection's
already
established
the
connection
got
established
and
then
it
started
sending
enough
stuff
that
t-shirt
could
say.
Oh
that's
http,
so
it
ignored
the
early
packets.
But
this
is
this
way
you
can
see
what
happens?
You
have
an
outer
ip
packet
with
an
inner
ip
packet
immediately
inside
of
it
with
whatever
your
actual.
You
know,
payload
tcp
udp,
whatever
isn't
inside
that,
but
you
can
only
encapsulate
things
that
go
over
ip,
because
the
thing
you
encapsulate
has
to
be
an
ip
packet.
A
You
can't
encapsulate
you
know
ipx
or
apple
talk
or
any
of
those
things
that
that
didn't
use
an
ip
as
an
outer.
You
know
that
don't
have
an
outer
ip
layer
to
them.
Similarly,
you
can't
do
anything.
That's
that's
raw
ethernet
packets,
where
you
actually
have
to
get
the
ethernet
headers
to
the
other
side.
A
So
for
anyone
who
doesn't
know,
bgp
is
a
routing
protocol
and
it's
the
most
common
one
across
the
internet,
in
terms
of
when
different
networks
need
to
talk
to
each
other,
bgp
is
typically
what
they
use.
You
might
use
a
different
protocol
within
your
network,
but
if
you
want
to
exchange
routes
of
comcast
or
at
t
or
whoever
you're
going
to
use
bgp,
that's
the
standard
protocol
for
for
exchanging
routes.
A
A
A
A
Now
you
see
there,
we
got
a
bgp,
keep
a
live
message,
so
this
is
how
you
can
see
that
the
different
nodes
all
talk
to
each
other
over
bgp,
oh
great,
so
there
we
go.
That's
what
we
needed.
So
you
can
see.
We
have
a
keep
alive
message
that
went
between
dot,
four
and
dot
two
and
then
the
other
way,
and
then
between
dot,
three
and
dot
two
and
then
the
other
way.
So
this
is
showing
you
that
node
zero
is
talking
to
both
of
the
other
nodes.
A
A
A
A
A
There
we
go
that's
what
I
was
looking
for,
so
172.20
is
node
0.,
and
it
now
has
too
many
for
type
block.
So
you
can
see
it
now
got
allocated
another
ip
block,
dot
64,
which
gives
another
60
well
depending
on
how
it
used
it
could
use
up
to
64
of
those
ips.
But
sometimes
you
don't
use
the
first
and
last
so
it
could
be
62..
A
A
A
Okay,
so
that's
calico
uses
bgp
to
exchange
routes.
Each
node
gets
reservations
of
blocks
of
ips
from
either
the
kubernetes
api
servers
at
cd
or
its
own
fcd,
and
it
uses
routes
both
to
get
to
local
pods
and
to
get
to
other
nodes
and
the
standard
installs
encapsulating
via
ip
over
ip
now.
Calico
also
supports
network
policies.
A
It
also
supports
different
encapsulation
as
well.
You
know
you
can
actually
get
flannel
to
run
an
ip
over
ip
and
you
can
get
calicodes
vxlan,
it's
just
not
their
standard
standard
configuration,
and
so
it
made
more
sense
to
show
you
the
standard
configurations
of
the
two
and
get
to
see
both
flannel
and
calico
in
action,
as
well
as
both
vxlan
and
ipo
ip
in
action.
A
Okay.
So
that
brings
us
to
the
end.
This
has
been
a
quick
tour
through
container
networking,
service,
routing
and
flannel
and
calico
in
particular.
Kubernetes
networking
is
a
huge
topic,
so
any
talk
can
only
cover
a
small
slice.
There's
a
lot
of
things
I
would
love
to
go
into.
You
know,
for
example,
psyllium
is
fascinating,
there's
a
bunch
of
other.
I
mean
the
list
of
networking.
Plugins
is
tremendous.
A
We
could
have
used
several
other
encapsulations,
there's
all
sorts
of
new
technologies
out
there.
We
could
have
dug
deep
into
network
policies,
but
there's
only
so
much.
We
can
do
in
a
limited
amount
of
time,
but
hopefully
this
covered
the
tools
that
would
make
sense
for
looking
into
any
of
these
things
and
at
least
would
get
you
started
on
further
exploration.
If
you
did
want
to
go
into
these
other
topics,
this
has
been
pre-recorded,
so
I
can't
sit
here
and
answer.