►
Description
Navigating the Container Jungle - Casey Davenport, Tigera
It's a jungle out there! Modern apps are built around microservices, linked by a complex mesh of connections like sprawling vines. And just like in the jungle there are predators out there waiting to pounce on any weakness, steal your data, hijack your apps, and compromise your users. It may seem like a trade-off: do you simplify networking connectivity OR enforce security? In this session, Casey Davenport reviews the latest developments from the Kubernetes community to enable developers to describe, simply and intuitively, the connectivity requirements of their pods, consistent with established Kubernetes concepts such as labels and selectors. With live demos and examples drawn from user case studies, Casey will navigate the audience through this complex jungle and bring them safely out the other side.
About Casey Davenport
Casey Davenport is a core developer at Tigera working on Project Calico and has worked on software defined networking solutions since 2012. He is an active technology evangelist for containers and simplified networking, and has spoken recently on related topics at multiple meetups. He holds a Bachelor of Science in Electrical Engineering from Northeastern University.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Welcome
my
name
is
Casey
Davenport
I
am
an
engineer
at
tae,
Guerra
and
I'm.
One
of
the
core
developers
on
Project
calico
I,
want
to
talk
today
about
navigating
the
container
networking
jungle.
I'm
gonna
walk
through
some
common
pitfalls
that
you
know.
We
at
tag
era
have
seen
and
tell
you
how
you
can
avoid
those
so
I
like
to
start
by
reminding
people
that
networking
is
important.
It
used
to
be
that
the
network
was
really
just
what
got
users
to
your
application,
but
our
applications
have
grown.
A
We've
started
using
containers
micro
service
based
architectures,
and
what
that
means
is
that
our
code
doesn't
fit
on
a
single
machine
anymore,
so
we're
Network
used
to
be
what
got
users
to
your
application.
It's
now
actually
a
critical
part
of
your
application
itself.
So
you
know
when
your
network
is
slow,
your
application
is
slow.
When
your
network
is
hard
to
debug,
it
means
your
application
is
hard
to
debug.
A
So
networking
is
important.
I
want
to
walk
you
through
a
brief
history
of
enterprise
networks.
So
so,
20
years
ago
there
was
the
enterprise
and
the
network
had
looked
like
this,
and
a
bunch
America
bare-metal
servers
they're
running
their
code
directly
on
these
servers.
Each
server
was
connected
to
their
physical
network.
A
A
A
So
you
end
up
with
overlay
networks,
they're
separated
now
not
by
a
physical
firewall,
but
by
a
virtual
firewall,
and
not
too
long
after
that
we
got
containers
and
when
we
switched
from
containers
from
virtual
machines,
we
did
the
same
thing
that
we
did
when
we
switched
from
bare
metal
to
virtual
machines.
We
went
another
layer
deep,
so
we
followed
the
same
pattern
and
we
ended
up
with
something
like
this.
So
you've
now
got
container
overlays
virtual
machine
overlays.
He
had
containerized
firewalls,
you
have
virtualized
firewalls.
A
This
is
all
running
over
some
physical
or
cloud
network
and
there's
some
real
problems
with
this
approach,
the
first
being
complexity
right.
It's
really
hard
to
look
at
this
and
know
what's
going
on
and
when
something
goes
wrong
with
your
application
or
in
the
network.
It's
hard
to
tell
where
exactly
the
problem.
Is
you
don't
know
if
it's
in
one
of
your
container
overlays
or
a
containerized
firewall?
A
So
we
added
all
this
complexity
to
the
network,
there's
all
in
the
name
of
increasing
security,
but
when
it
comes
down
to
it,
there
are
still
major
flaws
of
this.
This
approach
so
now,
the
first
being
that
you
know
overlays
are
inherently
dumb.
They
don't
know
what
the
needs
of
your
application
are.
They
just
know
that
these
workloads
need
to
talk
to
each
other,
so
the
kind
of
level
of
isolation
they
give
you
for
your
workloads
is
rather
coarse-grained.
A
If
an
attacker
gets
access
to,
you
know
one
container
on
one
overlay,
then
they
have
free
reign
over
all
the
other
containers
on
it.
Overlay
because
there's
nothing,
no,
managing
the
connections
between
those
this
workloads-
and
the
second
is
that
each
firewall
is
itself
a
single
point
of
failure.
So
if
somebody
can
get
through
one
of
your
firewalls,
there's
nothing
on
the
other
side,
stopping
them
from
getting
that
entire
overlay
on
the
other
side.
A
You
had
a
simplified
service
model,
simplified
way
of
thinking
about
your
workloads
and
with
that
was
a
simplified
networking
model.
So
in
kubernetes
every
pod
gets
its
own
IP
address.
Each
pod
can
talk
to
every
other
pod
in
the
network
and
crucially,
each
pod
sees
the
same
IP
address
for
itself
as
the
other
pod
seat
for
that
plot.
So
this
is
vastly
simplified
and
comes
with
a
lot
of
benefits
in
terms
of
reducing
that
complexity
in
terms
of
performance
and
debug
ability
of
your
network,
and
it
doesn't
make
any
claims
about
how
you
do
this.
A
You
can
do
it
with
a
single
pot
overlay
network
or
you
can
do
it
by
attaching
each
of
your
pods
to
physical
or
a
cloud
network.
So
this
is
great.
It
solves
the
complexity,
problems
and
performance
problems.
We
had
to
the
previous
approaches,
but
there's
still
an
issue
of
security.
So
in
this
model
every
pod
can
talk
to
every
other
pod.
So,
given
this
is
your
kubernetes
cluster.
A
You've
got
a
whole
lot
of
different
connections
that
are
possible
and
most
of
those
actually
aren't
useful
for
your
application,
and
what
that
means
is
that
if
a
bad
guy
gets
into
your
network,
then
they
have
free
rein
to
access
whatever
they
want.
So
so
what
we
really
want
to
do
is
eliminate
all
those
connection
paths
so
that
only
the
bare
minimum
set
of
connections
that
are
useful
for
our
application
remain,
and
this
makes
it
really
hard
for
attackers
to
infiltrate
your
network.
A
A
So
kubernetes
has
an
answer
to
that
and
it's
called
network
policy
and
for
those
of
you
who
aren't
familiar
with
it.
Network
policy
is
a
kubernetes
resource
and
it's
a
way
of
defining
at
a
very
high
level
and
a
declarative
way.
What
groups
of
pods
should
be
able
to
talk
to
which
other
groups
of
pods
and
how
so
what
kubernetes
network
policy
lets.
A
So
with
that
background,
they
want
to
walk
you
through
a
few
used
to
use
user
case
studies,
so
these
are
real
kubernetes
users
that
are
deploying
workloads
in
production
and
they
got
lost
in
the
container
networking
jungle.
So
I
want
to
tell
you
about
designs
that
came
up
with
and
then
the
resulting
architecture
once
they
started
using
kubernetes
network
policy
with
calico.
A
A
Instead,
the
second
problem
they
were
having
came
from
the
fact
that
they
were
separating
these
three
different
environments
into
three
different
kubernetes
clusters,
and
that
meant
they
were
statically
partitioning
their
servers
into
one
cluster
or
another.
So
this
led
the
poor
resource
utilization.
So,
for
example,
they
might
have
a
spike
in
production
traffic
that
you
know
maxed
out
their
production
cluster.
Well,
they
still
had
a
whole
bunch
of
free
CPU
cycles
in
a
dev
cluster
and
what
this
meant
is
they
had
the
over-provision
all
three
of
those
that
they
could
prepare
for
the
worst
case.
A
This
was,
you,
know,
inefficient
and
costing
the
money,
so
they
looked
for
something
else,
and
what
they
came
up
with
was
to
combine
those
three
clusters
into
one,
so
they
got
rid
of
the
overlay
networks
and
they
moved
dev
tests
and
production
into
a
single
cluster
with
each
one
and
a
separate
namespace,
once
they've
done,
that
they're
now
able
to
use
Network
policy
to
isolate
a
long,
namespace
boundaries
and
then
even
within
namespaces,
to
get
the
isolation
that
meets
the
requirements.
So
so,
after
doing
that,
you
get
something
that
looks
like
this
flat
layer.
A
A
So
the
second
case,
I
want
to
talk
to
you
about
a
large
financial
corporation
and
they're
trying
to
deploy
a
traditional
three-tier
application.
So
when
I
say
three
to
your
application,
I
mean
they've
got
a
set
of
workloads
that
are
their
front
end,
a
middle
tier
that
comprises
all
their
business
logic
and
does
the
secret
sauce
they've
got
a
third
tier
which
is
their
database.
A
This
is
the
way
that
people
have
deployed
web
applications
for
a
long
time
and
I
want
to
isolate
between
these
tiers
so
that
only
adjacent
adjacent
tiers
can
talk
to
each
other,
so
the
way
they
started
to
implement
this
was
to
use
overlay
networks
to
isolate
the
different
tiers
and
they
weren't
using
kubernetes
at
this
point,
how
they're
trying
to
spend
their
own
thing.
So
this
is
what
they
came
up
with.
A
They
have
two
different
overlay
networks
and
based
on
which
tier
container
ends
up
in
they
attach
it
to
a
different
overlay
network,
and
if
it
needs
to
communicate
with
both,
then
it
gets
attached
to
both
overlay
networks,
so
they
found
some
problems.
The
first
is
that
this
was
really
hard
to
configure,
so
it
was
pushing
the
haulage
of
their
network
into
their
pods.
They
were
having
to
change
their
application
code
to
be
aware
of
multiple
interfaces
in
their
container,
depending
on
which
tier
the
code
belongs
to.
A
A
A
So
again,
this
this
slide
looks
pretty
similar
because
it's
the
same
solution.
They
switched
to
a
flat
network.
Each
of
the
pods,
gets
connected
to
the
network
and
use
network
policy
to
determine
who
can
talk
to
them
and
again,
the
the
network
policy
required
to
do
this
in
kubernetes
is
dead
simple,
so
they
have
a
front
end
policy
that
applies
to
their
front
end
pods
middle
tier
policy
that
uses
a
label
selector
to
select
the
middle
tier
pods
and
the
database
poly.
That's
policy
that
selects
their
database.
A
So
they
were
looking
to
move
to
containers
because
they
were
starting
to
push
the
limits
of
what
the
cluster
do
and
they're
trying
to
come
up
with
a
design
to
move
to
containers.
So
what
they've
got
at
the
moment
is
a
bunch
of
bare
metal
servers,
no
containers
each
one
attached
to
a
physical
firewall
device.
They've
got
some
custom
automation,
scripts
that
are
watching
the
code,
that's
deployed
on
these
servers
and
updating
the
firewalls.
A
A
You
don't
have
a
whole
lot
of
churn
in
your
network
for
one
of
the
attributes,
and
one
of
the
benefits
of
things
like
kubernetes
and
containers
is
its
dynamic
nature
right.
You
can
dynamically
scale
and
schedule
different
workloads
all
across
your
cluster
and
keeping
up
with
this
churn
is
difficult
using
traditional
automation
methods,
so
it
was
really
hard
for
them
to
keep
these
firewalls
up-to-date.
A
The
second
is
that
they
were
moving
to
a
vastly
larger
number
of
workloads
and
trying
to
enter
all
of
those
firewall
rules
into
their
physical
firewall
devices
meant
they
were
running
out
of
room
in
the
devices
themselves.
So
you
know,
isolating
with
physical
firewalls
was
not
going
to
work
for
them,
so.
A
A
So
deja
vu
looks
exactly
the
same
flat
layer,
3
network,
each
containers
attached
to
the
network
and
the
user
network
policy
to
isolate
and
they've
removed
all
the
firewalls.
Now
you
probably
noticed
that
each
of
these
three
solutions
looked
exactly
the
same
and
I
think
that's
really
a
testament
to
the
power
of
this
model
right.
You
can
take
three
separate
problems
and
reduce
it
down
to
the
same
network
topology
and
a
very
flexible
network
policy
API
to
solve
those
three
different
problems
and.
A
It's
got
I
read
this
back
end
and
it
has
a
replicated
front-end
that
I
wrote
that
will
talk
to
Redis
when
it
receives
a
request
from
the
client
and
when
I
start
it
up
you'll
see
everything
can
talk
to
everybody
else.
This
is
a
security
problem,
so
I'm
going
to
put
things
in
the
correct
order,
make
it
so
that
only
the
front-end
can
talk
to
Redis
and
that
the
client
can
talk
to
the
front-end.
A
So
I've
got
a
local
cluster
running
here,
because
I
didn't
want
to
depend
on
internet
connectivity.
You
want
to
try
this
out
yourself,
there's
a
really
great
way
to
do
it.
You
can
go
to
a
stack
point:
do
high
and
select
Calico
and
you'll
get
a
kubernetes
cluster
with
Calico
installed
just
a
couple
minutes.
So
I've
got
this
demo
script,
and
this
is
something
I
stole
from
the
one
and
only
Tim
Hawke
in.
Let
me
oops.
A
A
A
A
And
you
can
see
I've
got
five
of
those
running
so
on
the
left
here.
This
is
gonna.
Do
it's
gonna
SS
eight
to
do
one
of
my
machines
and
it's
basically
gonna
repeatedly
hit
my
service
and
tell
me
the
results.
If
it
fails
to
hit
the
front
end,
it'll
print
out
fails
to
hit
the
front
end.
So
on
the
left.
You
can
see
it's
printing
out
the
hostname
of
each
one,
so
it's
getting
load
balanced
across
five
different
instances
and
I
am
making
some
sweet
cash.
A
But
there's
a
problem
here
so
I
can
SSH
in
from
the
simple
Redis
out
pine
container
and
I
can
set
my
money
or
and
back
down
to
zero.
Just
like
that.
So
that's
not
great
and
think
about
it.
A
bit
on
the
side.
I
want
to
fix
that
with
a
network
policy.
So
you
can
see
I've
got
no
policy
to
find
at
the
moment,
but
I'm
going
to
create
some.
A
So
the
first
thing
I'm
going
to
do
is
I'm
going
to
create
this
Redis
policy
and
what
this
does
is
it
uses
label
selectors
to
apply
this
policy
to
my
Redis
container,
so
it
selects
based
on
the
eat.
Demo
label,
sorry,
demo,
Redis
label,
and
it
allows
incoming
traffic
only
from
the
front
end
and
only
on
port
six,
three
seven,
nine
TCP
port
67
lat,
so
I'll
go
ahead
and
create
that
and
I'm
gonna
do
the
same
thing
for
my
front
end.
A
So
I'll
create
that
as
well.
The
last
thing
I
need
to
do
before
this
takes
effect
is
enable
isolation
on
my
namespace.
So
up
to
this
point,
I've
just
created
the
policies,
but
not
limit
akin
effect.
By
doing
this,
I'll
be
telling
my
namespace
that
I
want
you
to
only
allow
traffic
that
is
allowed
by
network
policies
in
this
namespace.
A
Cool,
so
traffic
keeps
flowing.
Nothing
looks
any
different,
however,
if
I
run
that
same
command
again,
just
using
the
Redis
open
container.
Try
to
set
my
money
back
to
zero,
nothing
happens
so
I
am
protected
and
and
just
to
show
you
a
little
bit
more
if
I
go
ahead
and
delete
the
rebus
policy,
that's
allowing
my
front-end
to
talk
to
Redis,
then
we'll
start
seeing
the
front-end
report
that
fails
to
talk
to
Redis
sitting
that
default
deny
policy.
A
Cool,
hopefully
that
was
enlightening
and
interesting.
If
you're
interested
in
trying
out
project
calico
like
I,
said
stack,
point
cloud
is
a
great
way
to
try
it
out.
It's
really
easy.
You
can
also
check
out
the
Calico
documentation.
We've
got
a
funky
new
duck
site,
I'm
Casey
from
tae
Guerra.
If
you're
interested
in
building
things
like
what
you
just
saw
Tiger
is
hiring
so
come
talk
to
me
and
I
check
out
our
github.
It's
all
open
source.
A
A
So
we,
the
question,
was:
do
you
support
overlapping
IPs
and
multi-tenancy?
Calico
today
doesn't
do
overlapping
IP
addresses.
We
have
a
plan,
a
technical
plan,
to
do
that,
but
we
haven't
heard
really
enough
user
demand
for
it.
The
way
someone
would
do
multi-tenancy
and
a
calico
deployment
would
be
through
this
network
isolation,
and
you
know
in
kubernetes,
you
can
use
services
to
abstract
IP
addresses
really
easily.
A
A
A
A
So
the
question
was:
does
calico
do
anything
north-south
respect
to
the
ingress
load?
Balancer,
you
can
apply
policy
on
traffic
that
is
coming
from
one
of
your
ingress,
little
balances
and
if
you're
running,
for
example,
a
ingress
controller,
you
can
apply
policy
on
traffic
from
that
the
kubernetes
spec
itself
doesn't
at
the
moment
talk
about
traffic
external
to
kubernetes
in
the
first
iteration,
but
there's
discussion,
discussion
in
the
cig
about
you
know
what?
How
do
we
get
to
that
point,
or
should
we
get
to
that
point
I
hand
in
the
back.
A
Yeah,
the
question
was:
do
you
think
the
network
policies
and
kubernetes
are
sufficient
to
express
all
kinds
of
network
policy
that
you
might
do
in
a
firewall
and
I?
Think
I
think
the
answer
there
is
close,
but
not
quite
there
are
still
things
you
can't
quite
Express
in
network
policies
just
because
of
where
the
spec
is
at
the
moment,
because
it
would
be
impossible
to,
for
example,
there's
no
way
to
specify
an
exact
IP
match
right.
It's
just
based
on
labels.
A
A
A
A
Well,
quite
a
bit
of
code,
so
the
policies
are
implemented
on
each
host
in
IP
tables.
So
Calico
has
a
way
of
you
know,
taking
the
centralized
kubernetes
policies
and
distributing
them
across
the
cluster
and
making
sure
that
each
toast
each
host
is
programmed
with
the
right
rules
for
the
workloads
that
are
on
it.
A
A
A
Should
policy
it's
a
good
question,
so
calico
two
supports
that,
but
the
kubernetes
spec
does
not
yet
have
a
concept
of
egress
policy.
So
that's
another
thing
where
we've
been
discussing
in
the
networking
sig
kind
of
what,
where
that
belongs,
does
that
belong
as
part
of
the
kubernetes
api,
or
is
that
something
that
belongs
outside
of
kubernetes?
But
you
can
expect
this
spec
to
evolve
and
if
you're
interested
in
that
definitely
get
involved
in
the
network.
Cig.