►
Description
Topic Summary
Modern apps are built around microservices, linked by a complex mesh of connections. Cloud native orchestrators like Kubernetes enable developers to describe the connectivity requirements of their pods using intent-based documents called network policy. Network policy enables zero trust and satisfies security models that microservices communications require. In this session, we will cover the Kubernetes networking stack, network policy with Project Calico and application service mesh. Also a demo will be shown to reinforce the concepts.
About Christopher Liljenstolpe
Christopher is the CTO and co-founder of Tigera, Inc, and the original architect of Project Calico. Before devoting his life to making cloud networking simple and secure, he gained plenty of practical experience in how it was not ever thus, designing and running several OpenStack clusters, and architecting some of the earliest SDN solutions at Big Switch Networks. He also ran architecture at two large carriers (Telstra - AS1221, and Cable & Wireless/iMCI - AS3561), spent time in Asia as the IP CTO for Alcatel, and run networks in Antarctica (hint, bend radius becomes REALLY important at -50C). In his spare time he was foolish enough to do two stints as a working group co-chair in the IETF. Occasionally you can have the (mis-)fortune of hearing him speak at conferences and the like.
A
Of
course,
we
have
to
wish
on
that
356
birthday
to
Fridtjof
Nansen,
and
if
you
know
enough
about
me,
you'll
know
why
I
specifically
call
off
free
just
Manson,
but
I've
done
work
in
the
in
the
polls
before
so
happy
birthday
to
mr.
Danson,
so
solutions
utopia,
you
know,
I,
think
the
issue.
What
I'm
gonna
talk
a
little
bit
about
is.
A
What's
the
advantage
of
policy,
why
might
you
want
to
deploy
policy
or
application
connectivity
controls
within
a
kubernetes
or
cloud
native
environment?
You
know
you've,
you
developed
your
applications,
you've
deployed
them
as
containers
and
Victor
Burnett
ease,
pods
and
those
pods
are
up
and
running
and
everything
works.
So
that's
you
know
it's
a
great
environment
for
doing
that,
but
there
are
once
you
start
getting
into
production
in
a
large
enterprise
or
as
part
of
a
larger
organization.
There
are
other
components
in
your
organization
that
also
need
to
be
involved
in
this.
A
That
might
be
the
security
team,
the
ops
team
risk
assessment.
There
are
other
groups
that
need
to
have
to
do
their
jobs
need
to
have
visibility
and
the
ability
to
interact
with
their
new
cloud
native
application,
environment
and
the
way
that
was
done
often
before
always
very
waterfall
in
its
approach.
If
you
take
a
look
at
earlier
models,
you
deploy
an
application
and
then
you'd
ask
the
firewall
team
to
approve
firewall
changes
or
you'd.
Ask
the
the
ops
team
to
take
over
that
application
program,
the
network
program,
the
physical
infrastructure,
etc.
A
That
really
doesn't
fit
in
a
cloud
native
model
where
applications
can
mutate
very
quickly.
It's
a
constant
delivery,
see
ICD
kind
of
environment
on
the
orchestrator
itself,
like
kubernetes,
is
auto
scaling
and
auto
repairing
infrastructure,
classical
anchors
things
like
IP
addresses,
etc
now
become
fungible
on
all
of
those
things
have
even
larger
than
that.
It
is
the
dynamicism
of
these
environments
if
the
orchestrator
is
firing
off,
auto
scaling
groups,
etc
and
repair
and
red-blue
testing,
etc.
A
That
can
be
happening
in
almost
real-time.
If
you
have
to
be
updating,
infrastructure
policies,
etc,
those
can
take
hours
days
or
longer
if
you've
ever
raised
a
firewall
ticket
in
your
organization,
I'm
sure
everyone's
organization
has
you
know,
but
that's
not
a
problem
at
all,
but
I
can
assure
you
in
lots
of
other
organizations.
It
might
take
you
a
bit
of
time
to
get
a
firewall
change,
approved.
I'm
sure
that's
not
the
case
here,
but
it's
that's
what
happens
very
often
in
the
real
world.
A
So
those
time
scales
are
very
different,
so
you
sort
of
lose
the
advantage
of
the
cloud
native
environment.
So
how
do
you
do
all
these
groups
now
still
do
their
job?
It's
an
it's
a
necessary
job
in
this
cloud
native
environment.
So
let's
go
back
actually
a
little
bit
and
take
a
little
bit
of
a
retrospective
in
the
past
I'm
going
to
use
a
really
nasty
word
and
it's
so
it's
been
around
for
a
long
time.
We
always
talk
about
how
it's
loud
native
as
new
and
service
meshing
is
new.
It
actually
isn't.
A
You
know
so
service-oriented
architectures
have
been
around
for
a
long
time
and
the
idea
is
you
split
up
processes
into
individual
components
and
you
make
those
components
able
to
communicate
with
each
other
or
some
kind
of
infrastructure,
and
you
know
that
infrastructure
has
moved
obviously
over
over
the
years
from
being
RPC
calls
within
a
piece
of
code
in
to
being
over
the
network.
It's
that
way
these
processes
can
be
individually
scaled,
distributed,
etc.
A
This
is
this
is
the
Nirvana
that
we've
been
working
for
for
quite
some
times
and
give
you
my
idea
of
how
long
and
my
guess
is
not
all
of
you
on
this
call
have
been
in
this
industry.
This
long,
I
guess
I'm
going
to
date
myself
by
saying
I
have
been
so
we've
seen
this
story
before
and
you
know
we
started
off
with
this
thing
called
corba
and
again,
the
idea
was
you'd
have
objects,
but
those
objects
had
to
basically
be
completely
refactored.
A
In
order
to
collaborate
in
a
corbin
environment,
you
had
to
write
your
applications
from
ground
up
around
coral
and
so
surprisingly
enough
that
really
didn't
take
off,
because
it
serve
hard
to
tell
people
to
completely
refactor
their
applications
in
order
to
make
something
work
and
everything
within
the
infrastructure
has
to
support
core.
But
in
order
for
Corbin
to
be
and
to
have
been
successful,
so
of
course
that's
never
going
to
take
off.
So
we
tried
again
with
something
called
Enterprise
Service
bus
as
esps.
A
This
came
around
sort
of
the
Java
world
slightly
more
successful,
but
but
really
not
much
because
again,
I
have
to
write
my
applications
to
use
the
ESB
constructs
and
it's
very
difficult
to
bring
other
objects.
Other
code
legacy
code
into
that
kind
of
environment.
Everything
has
to
be
written
with
ESB
in
mind
in
order
for
ESB
to
be
successful.
So
again,
this
one
sort
of
failed.
So
what
what's
different
and
what's
different?
A
We
started
looking
at
in
in
2010
API
management,
API
gateways
and
we
basically
started
saying-
is
instead
of
building
the
whole
infrastructure,
let's
just
manage
access
to
the
api's,
and
this
got
somewhat
better,
but
it's
still
work
wired.
Writing
your
applications
now
to
integrate
with
that
API
gateway,
etc.
But
at
least
now
you
could
use
different
API
and
register
different
api's,
but
it
still
was.
You
know
it
requires
some
amount
of
refactoring
between
that
time,
and
now
things
have
changed
a
little
bit.
So
what's
changed
is.
A
One
of
the
advantages
of
having
middleboxes
in
the
Internet
load,
balancers,
HTTP,
load,
balancers,
firewalls,
etc-
is
that
those
applications
that
are
meant
to
be
used
on
the
public
Internet
have
had
to
deal
with
things
like
load,
balancers
and
firewalls
or
they're
a
necessary
part
of
the
infrastructure.
So
we've
started
writing
applications
to
utilize,
the
api's
that
work
across
those
devices,
namely
HTTP,
and
it
and
its
successors,
HTTP
1,
HT,
2,
G,
RPC,
etc.
A
A
We
already
have
the
building
blocks
to
build
this
kind
of
environment.
Applications
are
limited
in
scope.
We
don't
write
big
monolithic
applications
anymore.
We
write
containers
that
are
limited
in
scope,
you
don't
you
know,
or
even
if
it's
not
containerized,
you
basically
break
up
your
applications
and
into
small
constituent
components.
You
publish
those
api's
and
something
we
do
quite
regularly
already.
A
You
have
either
things
are
independently
deployable
and
there
are
components
that
can
exist
outside
of
the
process
itself.
So,
for
example,
we're
already
used
to
using
things
like
load
balancers
that
aren't
part
of
the
code,
the
output
load
balancing
code
in
our
applications
anymore.
We
rely
on
external
components.
Those
might
have
at
one
time
been
an
external
actual
load,
balancer
like
an
f5
or
an
a-10
or
nginx,
or
something
like
that.
A
B
A
So
what
is
so
of
today
and
I'm
using
so
specifically
because
I'm
just
trying
to
point
out
that
we
basically
delivered
finally
on
what
people
and
trying
to
do
for
the
last
20
plus
years,
and
we
are
using
micro
services
across
the
network
using
common
api's
and
using
capabilities
in
the
underlying
infrastructure
to
handle
a
lot
of
the
undifferentiated
heavy
lifting
as
people
call
it.
You
know,
HTML
or
balancer
is
an
HTTP
load
balancer.
It
doesn't
mean
to
be
specific
kind
of
specific
knowledge
to
your
application.
Necessarily.
A
So
how
do
we
deploy
these
applications
today?
Today,
you
can
deploy
these
applications
and
physical
boxes.
You
can
deploy
an
application
spill,
a
bunch
microservices
containers.
Whatever
on
on
a
physical
server,
you
can
do
the
same
deployment
across
virtual
machines
and
you
can
split
those
micro-services
up
into
individual
containers
and
deploy
them
in
a
in
a
container
environment
like
kubernetes.
A
So
that's
sort
of
a
sets
a
little
bit
of
a
context.
The
way
you
might
want
to
start
thinking
about
what
you're
really
offering
with
your
code
and
you're
really
offering
services,
and
you
really
need
an
architecture-
that's
going
to
support
services.
So
this
is
a
talk
about
networking.
So,
let's
talk
about
what
components
you
need
in
order
to
have
this
kind
of
service
based
architecture
within
from
from
a
networking
lens.
So
this
is
the
classical
OSI
network
layer
and
really
what
I'm
saying
here
is
at
the
very
low
levels.
A
So
we're
going
to
talk
a
little
bit
about
today
is
some
of
the
tools
you
can
use
to
deliver.
The
network
portion
of
this
services,
or
this
applicant
I,
will
now
start
using
the
term
application
connectivity
or
services
connectivity
in
a
modern
environment.
So
first
thing
we
need
to
do
is
get
packets,
get
those
API
calls
get
those
rest
calls
or
CRP
PPC
messages
between
services
and
pods,
delivering
those
services
and
between
pods
etc.
A
So
we
need
some
kind
of
connectivity
layer
and
that's
layer,
3
and
layer
4
in
the
infrastructure
and
there's
a
really
nice
tool
out
there.
At
least,
we
think
it's
very
nice
tool
called
project
calico
that
does
that
and
we'll
talk
a
little
bit
about
some
of
the
capabilities
there
and
then
we
also
need
to
start
talking
about
things
at
a
higher
level.
So
now
not
only
do
I
need
to
get
the
packets
from
A
to
B.
A
I
need
to
figure
out
where
those
packets
need
to
go
based
on
the
application
that
they're
that
they're
servicing
or
the
service
they're
servicing,
so
that
you
start
looking
at
things
like
load,
balancing
and
end
point
discard
or
service
discovery
and
and
possibly
policy
control
at
flair
5
through
7.
Are
you
allowed
to
make
that
kind
of
API
call?
So
that's
what
people
are
now
calling
service
mesh
and
there's
a
really
nice
tool
out?
A
So
you
know
the
agenda:
we're
going
to
talk
about
service
meshes
and
and
their
components
we're
going
to
do
a
demo
and
layer,
3
and
layer
and
demos
on
calico
I,
put
the
circle
in
on
place
and
then
we're
going
to
think
about
layer,
3
and
layer,
4,
endpoints
and
reach
ability
and
policy
control
of
those
connections.
So
not
only
how
do
we
get
traffic
between
different
pods
and
in
from
the
outside
and
and
out
to
the
outside,
but
should
that
traffic
be
allowed
at
layer,
3
and
layer
4?
A
So
well,
that's
what
we're
going
to
be
talking
about
here,
a
couple
of
examples
of
folks
who
have
all
deployed
some
or
both
of
these
components.
Google,
google
just
announced
that
project
calico
is
the
underlying
network
policy
infrastructure
for
gke
box
and
obviously
they're.
Very
big
supporters
of
this
do
as
well
box
is
using
calico
and
talked
about
using
calico
in
both
container
kind
of
environments,
as
well
as
bare
metal
environments.
We'll
talk
about
that
a
bit
and
why
they
we
can
talk
about
bare
metal
a
little
bit.
A
A
So,
let's
talk
about
layer,
3,
layer,
4,
first
project
calico,
the
idea
behind
project
calico
is
networking
should
be
simple
and
just
get
out
of
the
way
you
shouldn't
need
to
be
thinking
about
networking.
It's
you
know,
apologies
to
some
of
the
other
people
in
this
space,
but
very
often
the
networking
world
over
thinks
networking
and
we
like
to
put
lots
of
knobs
and
controls
and
give
you
lots
of
different
options.
A
Give
you
lots
of
different
types
of
packets.
You
can
transport,
so
we
built
overlays
and
meshes
of
overlays
and
you
know
I
think
of
it
as
Turtles.
All
the
way
down
you
end
up
with
overlays
on
overlays,
so
if
let's
say
use
an
overlay
based
infrastructure
for
your
kubernetes
networking
environment
on
top
of
a
VM
environment,
that's
also
using
overlays
pretty
soon
you've
got
two
or
more
layers
of
tunnels
in
each
other
sort
of
turtles
all
the
way
down,
or
sometimes
we
say
at
networking,
1,400
bytes
of
header
and
100
bytes
of
payload.
A
So
we
we
tend
to
make
networking
overly
complex
and
there's
historical
reasons
for
that.
But
in
today's
world
it's
all
IP.
It
should
all
be
pretty
simple,
so
with
project
calico,
we
start
with
back
to
first
principles
and
said
the
network.
L3
l4
needs
to
do
two
things.
These
get
packaged
from
A
to
B
and
needs
to
apply
policies
to
control
if
the
package
should
be
able
to
get
to
a
and
B.
So
we've
split
networking
in
calico
up
into
two
separate
problems
and
you
solve
them
differently.
When
is
reach
ability?
A
One
is
policy
enforcement,
so
reach
ability.
Let's
make
that
as
simple
as
possible,
it's
called
IP
routing.
We
know
it
works
at
scale.
There's
a
little
network
called
the
internet
that
whose
standard
IP
routing
works
really
well
at
scale.
It's
also
really
simple.
So
we
build
an
l-3,
simple
routed
fabric
that
uses
standard,
Linux
tools,
and
if
you
understand
IP
networking
in
Linux,
you
can
troubleshoot
a
calico
network.
It's
pretty
basic
infrastructure.
A
You
can
talk
about
it
in
more
detail,
but
basically
we
turn
every
node
into
a
router
and
we
just
route
traffic
from
A
to
B.
So
it's
it's
very
simple,
because
it's
simple
and
uses
standard
tools
that
have
been
built
to
handle
the
scale
of
the
public.
Internet
ie
IP
routing,
maybe
routing
protocols.
If
you
need
them
et
cetera,
you
know
you
can
scale
to
multi-thousand
node
production
clusters
from
a
couple
of
nodes
in
your
in
your
basement.
That's
your
your
playground,
same
technology.
A
Nothing
changes,
it's
all
exactly
the
same
thing,
so
it
scales
very
nicely
because
it
is
simple,
then
independent
of
that
we
layer
in
a
security
layer
called
and
we
use
policy
enforcement.
The
idea
being
very
often
people
in
again
in
the
networking
world,
try
and
do
some
isolation
with
firewalls
or
virtual
networks,
and
those
are
great
for
what
we'll
call
coarse,
grained,
isolation,
I'm
sure
they're,
not
great,
but
they
work.
You
know
you
can
say
this
is
dev.
This
is
prod.
This
is
test
Network.
But
what
do
you
do
if
things
need?
Let's
say?
A
Instead,
you
do.
This
is
project
a
and
this
is
project
B.
But
now
you
need
something
in
project
a
to
talk
to
something
in
project
B
hold.
There
aren't
separate
networks.
So
now
you
have
to
stick
those
two
together
and
then
you
need
to
stick
a
firewall
in
between
them
to
say
only
these
things
in
a
can
talk
to
these
things
at
B
and
that's
a
little
hard
if
the
IP
address
is
the
number
of
A's
and
B's
and
the
IP
addresses
of
A's
and
B's
I
change
become
sort
of
difficult.
A
So
you
know
I
now
have
a
firewall
construct
to
handle
finer
grain
policy.
That's
not
really
cloud
native
and
I
have
these
big
chunky
groups
of
A's
and
B's
and
C's
in
a
large-scale
system.
You
should
find
one
way
of
a
cheat
of
solving
a
problem,
and
you
should
use
that
for
all
instances
of
that
problem,
you
shouldn't
make
people
at
3
o'clock
good
morning
figure
out.
Was
it
the
first
great
isolation,
the
failure
to
find
great
isolation
to
fail,
so
in
calico?
A
What
we
do
is
we
implement
a
policy
that
basically
says
things
labeled
X
can
or
cannot
talk
to
things,
labeled,
Y
and
things.
Labeled
X
could
be
dev
prod
tests
or
things
could
be
labeled
about
clients
and
and
Y
could
be
LDAP
servers
or
it
could
be
application,
a
authentication
clients
to
application
a
authentication
server.
They
can
be
as
fine-grained
or
as
coarse-grained
as
you
want.
The
mechanism
is
exactly
the
same,
so
we
have
this.
A
This
very
rich
policy
based
micro
segmentation,
which
surprisingly
looks
a
lot
like
a
superset
of
kubernetes
network
policy,
because
it
is
a
superset
of
kubernetes
second
policy.
So
that's
one
takeaway
about
project
calico.
Instead
of
trying
to
solve
no
connectivity
for
reach
ability
and
security.
At
the
same
time,
we
treat
them
as
separate
problems.
We
use
the
right
technology
to
solve
both
of
those
at
scale
and
at
real-time
from
a
cloud
native
perspective,
and
that
allows
us
to
use
the
right
tools
for
the
right
job.
A
A
A
So
you
can
have
in
this
case
two
endpoints
on
one
server
you
can
have
now.
If
I'm
looking
at
virtualization
I
could
have
potentially
three
logical
servers
in
one
physical
server
and
some
of
those
have
one
endpoint.
Some
have
two
endpoints
and
all
of
those
endpoints
are
exposed
over
a
couple
of
physical
minutes.
A
So
what
we
do
in
calico
in
order
to
make
this
work,
is
we
actually
turn
the
linux
server
into
a
router,
and
each
container
has
its
own
interface,
in
this
case,
a
cally
interface,
which
is
a
virtual
Ethernet,
and
so
each
container
is
its
own,
unique
endpoint
in
the
infrastructure
and
it
hosts
its
own
applications,
because
each
container
is
its
own
endpoint.
Each
application
can
listen
to
the
same
ports,
because
they're
gonna
have
separate
IP
addresses
they're,
not
all
going
to
share
the
same
physical
servers.
A
Ip
address
so
now
as
an
application
developer,
you
if
you've
got
multiple
containers
that
both
need
to
listen
to
port
80
in
a
non
Calico
kind
of
environment.
It's
very
likely
that
if
two
containers
each
trying
to
listen
to
port
80
show
up
on
the
same
server,
you've
got
a
problem.
One
of
them
is
a
man
that
will
listen
to
a
different
address.
In
this
case.
That's
no
longer
the
case.
We
treat
each
container
as
its
own
IP
server
on
the
network,
so
you
don't
need
to
be
aware
of
port
conflicts
or
anything
else.
A
This
is
the
kubernetes
native
way
of
doing
things.
Sweet
Coomer
has
looked
at
this,
so
how
does
this
work?
You
have
two
hosts
they're
connected
to
a
network
they're
running
kubernetes.
They
have
multiple
containers.
Each
@cd
is
aware
of
those
containers
and
those
hosts,
and
it's
aware
of
those
because
it's
listening
to
the
orchestrator,
the
Orcas,
the
fcd,
is
being
listened
to
by
felix,
which
is
the
Calico
agent
on
each
server
and
felix
takes
information
in
at
CD.
A
What
this
actually
looks
like
is
the
routing
daemon
talks
to
the
forwarding
information
base.
The
links
kernel
is
the
reach
ability.
You
know
who
can
talk
to
who
or
not
who
can
talk
to
who
you
know.
Where
are
things
in
the
network?
That's
also
programmed
by
Felix,
based
on
information
from
the
orchestrator
Felix,
also
programs,
the
ACL
tables,
which
is
where
we
do,
the
policy
enforcement,
where
we
say
can
I
talk
to
D
or
can
a
talked
to
be
it
one
thing
it's
important
to
notice
here
is
policy
has
always
done
exactly
the
same
way.
A
If
we
go
back
in
here,
for
example,
the
same
rule
that
would
allow
container
a
to
talk
to
container
D
would
be
used
to
decide
if
container
a
could
talk
to
container
be.
There
is
no
difference
if
the
container
is
on
the
same
hosts
on
different
hosts
or
even
in
different
data
centers.
The
policy
enforcement
is
exactly
the
same.
A
A
You
have
a
policy
that
basically
says
policy,
name,
etc,
and
then
it
has
a
selector
and
a
selector
says
if
something
is
assigned
a
key
value
pair
a
label
in
kubernetes
role
is
database.
Then
this
policy
is
applied
to
it
and
the
policy
might
be
it's
an
ingress
filter.
So
it's
filtering
traffic
coming
in
it's
going
to
allow
traffic
from
things
labeled
rule
front
end
on
to
port
63
79,
let's
basically
I
say
any
workload.
A
A
A
Now
we
start
having
adding
things
like
storage
and
certificates
and
routing
and
and
security
to
these
workers,
and
we
also
start
adding
things
like
control
author
of
the
authentication
etc
and
in
kubernetes
and
we'll
talk
about
some
of
these
in
a
minute,
so
kubernetes
networking
concepts
you
have
CNI
networking
plugins.
Those
are
things
that
listen
to
coop,
to
kubernetes.
Listen
to
the
cube,
the
cube,
'let
and
program
the
network
locally
on
the
host,
and
that's
something
that
calico
listens
to.
He
gets
data.
We
have
network
policy
which
we
just
talked
about.
A
You
have
a
concept
of
services.
Services
are
now
things
you
deployed
Cooper,
state
and
kubernetes,
that
this
is
a
database
service
and
it
might
have
one
or
more
pods
offering
that
service.
So
a
service
is
a
virtual
construct
that
allows
you
to
have
a
single
anchor
point
or
a
single
entity
to
represent
one
or
more
actual
endpoints
that
offer
that
service.
So
this
is
when
you
start
defining
services
and
kubernetes.
You
have
ingress
controllers.
Ingress
controllers
allow
traffic
from
the
outside
of
the
of
the
cluster
to
reach
pods
and,
more
specifically
or
more
importantly,
services.
A
A
So
let's
talk
about
now
some
of
the
things
we
can
start
doing
at
this
services
layer,
that's
sto!
What
does
this
do
used
for?
It's
used
for
traffic
management,
so
somebody's
asking
to
reach
a
specific
service.
Where
do
we
send
that
traffic?
How
do
we
load
balance
it
to
the
individual?
Pods
are
the
pods
alive?
Are
they
working
correctly?
That's
one
thing
that
this
deal
can
do.
We
also
give
you
a
building
to
observe
traffic
on
those
pods
on
the
traffic
between
the
pods
etc.
A
So
what
would
you
use
traffic
management
for
traffic
and
management
you
might
use
for
canary
deployments
or
Bluegreen
deployments?
You
might
say,
I
want
10%
of
my
traffic
to
go
to
the
new
green
version
of
this
application,
90%
to
go
to
the
blue.
Someone
to
test
the
Newbery
I
might
do
load
balancing
this
way.
Obviously,
I
do
to
avoid
bouncing
this
way.
I've
got
20
blue
pods,
offering
the
service
I
need
to
spread
load
among
them.
A
I
need
to
support
multi-tenancy
I
need
to
support
retries
I,
don't
necessarily
want
the
application
to
have
to
do
the
retries
I
want
my
underlying
player.
To
do
that,
so
you
make
a
request
in
to
sto,
or
through,
is
do
for
a
API,
make
an
API
request
that
API
request
times
out
this
deal
can
resubmit
that,
on
your
behalf,
rather
than
you
building
retry
logic
into
your
application,
you
might
have
circuit
breakers.
You
know
this
pod
is
pounding
on
this
service
so
often
that
it's
causing
a
frankly
denial
service
attack.
A
So
you
can
set
a
circuit,
break
and
rule
would
say.
Pods
can
only
make
this
many
calls
per
second
to
this
API
and
you'll
build
you'll
disconnect
them
if
they
don't
timeouts.
We
sort
of
talked
about
retries,
outlier
detection.
You
have
one
blue
pod,
that's
much
slower
than
all
the
others.
So
maybe
you
take
that
out
of
circulation
because
it's
obviously
not
well
a
new
rate
limiting
sort
of
seeing
a
circuit
limit
somebody's
to
how
much
traffic
they
sent
over
a
given
API
called.
A
Tracing
you
can
trace
your
API
calls
see
where
they're
going,
what
pods
they're
there
they're
talking
to
et
cetera.
You
can
literally
follow
a
layer,
seven
or
layer
five
flow
through
the
network.
You
can
get
all
sorts
of
custom
telemetry,
you
can
meter
and
you
know
some
of
the
same
things
in
the
same
data.
That's
used
for
outlier
detection
and
rate
limiting
separate
is
made
available
to
you
through
right
now,
primarily
Prometheus
interface.
So
you
go
look
at
how
your
infrastructure
is
performing
at
layer,
five
through
seven
layer,
you
know
performance,
etc.
A
And
st
also
provides
security
capabilities,
you
can
have
identity
and
authorization.
I
know
what
pod
you
are
based
on
your
labels.
Are
you
authorized
to
make
that
that
API
call
you're
trying
to
make
based
on
your
identity?
I
can
encrypt
your
traffic
using
mutual
TLS,
almost
be
driven
by
by
a
policy.
So
that's
there's
a
lot
of
identity,
authorization
and
crypto
capabilities
within
mestia.
A
If
we
look
at
the
components
really
quickly
of
Sto
they're,
the
three
main
components
or
pilot
mixer
and
auth,
and
then
your
proxy
and
today
the
front
the
default
proxy
is
envoy,
so
pilot
provides
configuration
data.
So
you
write
a
policy
that
says
things:
labeled
X
can
send
this
API
call
the
things
labeled
Y,
or
this
type
of
API
call
to
think
to
things.
Labeled
Y
should
be
rate
limited
to
100
calls
a
second
that
kind
of
configuration
gets
handled
by
pilot
that
gets
pushed
into
the
proxies
on,
although
in
all
the
pods.
A
A
So,
let's
say
you've
got
a
rule
that
says
this
service
can
only
make
so
much
traffic,
so
many
calls
per
second
mixer
can
tell
envoy
well
how
many
times
has
that
service
made
that
that
call
in
in
the
last
second,
so
I'm
going
to
make
a
decision
if
you're
still
in
compliance
or
not?
It's
also
where
all
the
telemetry
comes
out
and
gets
sent
through
the
last
fit
of
this
is
envoy.
It's
a
very
light
weight
fast
and
modular
HTTP
G,
RPC
proxy.
A
It
has
control
point
integration
with
this.
Do
it
does
service
discovery
can
do
health
checks?
It
can
do
hot
restarts
role,
but
you
know
a
role
rolling
updates
the
nice
thing
about
it.
It
fits
very
nicely
with
kubernetes.
This
actually
resides
within
each
pod
rather
than
in
the
host.
So
all
of
the
application
behaviors
are
wrapped
within
the
pod
or
all
the
service
or
micro
services
functions
are
wrapped
within
the
pod,
even
though
they're
not
in
the
same
container,
it's
not
a
shared
environment.
A
A
Those
are
wrapped
into
the
pod,
so
they're
not
shared
globally
so
and
it's
also
been
hardened
at
scale.
The
entire
lift
infrastructure
runs
on
envoy
they're,
the
original
authors
of
envoy
and
the
CNCs
project
and
we'll
go
through
this.
We've
already
talked
about
this,
so
at
this
point,
I'm
going
to
go.
Do
this
demo
video
so
before
I?
Do
that,
though,
are
there
any
questions
before
I
go
and
do
the
demo
video.
A
And
again,
as
I
said,
this
is
what
we
did
for
OpenShift,
but
if
you
just
replace
any
of
the
OC
commands
with
cube
cuddle
commands,
it
has
exactly
the
same
effect.
There's
no
open
shift
specific
logic
here.
Just
this
is
the
video
I
could
find
on
short
notice.
So
we've
got
a
number
of
pods
running
and
we're
looking
all
the
namespaces
you'll
see,
we've
got
the
standard
cube,
kubernetes
pods
we've
got
some
calico
pods,
and
this
is
this
your
basic
environment.
A
So
now
now
you
pass
the
OC
version.
Yeah
yeah!
That's
now!
If
you
take
a
look
at
the
way
we
define
host
again,
this
is
probably
not
sufficient.
This
is
just
telling
you
how
to
stand
up
Calico
and
an
OC
in
a
openshift
environment.
That's
not
all
that!
That's
interesting
here!
So
now
we're
gonna
watch
pods
as
we
create
them.
So
we're
going
to
start
a
demo
and
there's
a
couple
policies
in
here
which
we'll
talk
about.
A
So
in
this
case
this
is
a
policy
and
what
you
this
sorry.
This
is
a
replication
controller
for
a
service
I'm.
Sorry,
it's
a
replication
controller
for
a
service
called
the
Stars
demo
service
and
there
are
back-end
and
front-end
services
and
clients
the
clients
going
to
be
the
UI,
and
so
we're
going
to
now
create
those
pods,
the
backend
and
the
front-end
and
the
user
interface
and
the
user
interfaces
that
management
UI.
And
now,
if
you
take
a
look
at
this,
we
have
three
pods
talking
together.
A
A
A
You
get
told
you
need
to
deploy
a
PCI
application
as
well,
so
we're
creating
a
PCI
application
that
also
needs
to
be
connected
to
the
client
and
it's
it's
handling
the
PCI
data
in
your
application
in
your
service.
So
we
have
now
two
back.
We
have
a
new
back-end
and
a
new
front
end
and
those
are
PCI
compliant
and
we've
laid
them
as
PCI
compliant
and
that's
this
compliance.
So
they
have
two
labels
on
the
mount.
A
roll
front
end
two
and
a
roll
compliance
PCI.
A
And
now
the
UI
shows
that
everything
can
talk
to
everything.
So
this
is
great.
Your
applications
running
PCI
is
the
PCI
application.
We
talk
to
you
by
the
container
by
the
client,
so
can
the
non
PCI.
This
is
great.
However,
your
security
person
comes
by
and
says
you
know.
What's
this,
you
know
your
friend,
your
client
can
talk
directly
to
your
backends.
A
That's
not
right!
Your
your
clients
only
be
able
to
talk
to
the
front
ends.
We
had
it.
We
talked
about
this.
We
said
you
can
only
have
your
client
talked
to
the
fun
end.
So
now
we're
going
to
tell
kubernetes
we're
going
to
have
kubernetes
install
a
policy
that
says
default
deny
and
we're
going
to
apply
it
see
this
match.
Labels
to
all
pods
basically
will
match
any
pod,
because
there's
not
a
more
specific
saying
match
role,
front-end
or
whatever.
So
it
just
says,
match
everything.
A
So
when
you
do
that,
though,
even
the
you
I
won't
be
able
to
talk
to
anything
in
the
network,
which
means
we
wouldn't
be
able
visualize
anything.
So
we
now
have
to
do
is
add
a
policy
that
says
we're
going
to
allow
the
UI
the
visualizer
to
reach
all
of
the
pots.
So
that's
what
we
just
did
there
and
what
it
shows
here
is
we're
going
to
allow
things
from
management,
UI
role,
we're
going
to
allow
we're
gonna,
say
we're
allowed
to
talk
to
any
any
service
or
any
endpoint
on
the
UI
port.
A
So
now
the
management
UI
can
see
these
pods,
so
these
pods
exist,
but
they're
not
talking
to
anything
everything's
down
hard
nothing's
working
in
your
application.
Well
that
didn't
work.
So
now
what
we're
going
to
do
is
we're
going
to
create
a
front-end
where
I
have
a
front-end
policy
that
basically
says
traffic
ingress
from
the
front-end
or
from
the
client
is
allowed
to
talk
to
on
for
82
things.
Labeled.
A
Marilla
traffic
in
from
the
client
on
to
from
things
labeled
front-end.
So
now
the
client,
as
you
just
saw
that
there
was
the
client,
was
able
to
talk
to
the
two
front
ends.
We
knew
the
same
thing
except
now
we
say
the
backends
are
allowed
to
talk.
I'll
receive
traffic
from
the
front
ends,
so
these
are
all
the
straight-up
EML
files.
It
doesn't
matter.
If
there's
one
back-end
or
a
thousand
backends,
this
will
all
be
dynamically
applied.
So
now
the
client
can
talk
to
the
front
ends.
A
The
front
ends
can
talk
to
the
backends,
but
we
still
have
your
so
now
now
we've
met
the
security
team.
You
know,
standard
front
ends
talked
to
backends.
Client
talked
to
front
ends.
The
compliance
guys
see
this
say:
whoa
wait
a
second.
Why
can
the
non
PCI
front
end
talk
to
the
PCI
back-end
or
vice-versa?
A
We
don't
want
that
compliance
says
those
have
to
be
separate.
So
now
we
apply
a
policy,
that's
going
to
allow
us
to
filter
traffic
so
that
the
front
ends
and
the
back
ends
will
be
limited.
So
only
the
PCI
front
end
can
talk
to
the
PCI
back
end
and
only
the
non
PCI
front
end
can
talk
to
the
non
PCI
back
end
and
we're
going
to
do
that.
I'm
going
to
speed
this
up
just
a
bit
because
we're
all
short
on
time.
A
Now,
what
you
see
is
the
front
end.
The
normal
front
end
can
talk
to
the
Niroula
back
end.
The
PCI
front
end
to
talk
to
the
PCI
back
end.
Both
front
ends
can
talk
to
the
client.
None
of
the
other
connections
are
available.
So
now
we've
met
compliances
requirements,
the
security
teams
requirements
and
the
application
is
working,
and
now
it's
independent
of
how
many
of
these
get
stood
up.
You
stand
up
a
new
version
of
the
pod.
As
long
as
the
labels
stay
the
same,
the
policies
will
still
apply.
There's
no
firewall
rules.
A
You
had
to
update
anywhere,
there's
no
networking,
you
know
which
VPN
or
which
the
X
LAN
this
gets
installed
in.
You
don't
have
to
have
any
of
those
thoughts.
It's
just
you
deploy
your
workloads,
you
label
them
appropriately.
You
have
simple
policy
statements
that
are
human,
readable
that
tell
you
what's
allowed
to
talk
to
what
and
you
get
the
behavior.
You
want
your
infrastructure
and
on
that
I
will
end
this
slightly
over
long
presentation.
I
think
we
still
have
a
couple
of
minutes
for
questions.
I
apologize
for
any
a
little
bit
long.
So
anyway,.
C
A
So
I
see
one
here
from
guru
when
I
showed
the
demo
I
showed
was
just
using
calico.
We
have
an
integrated
integrating
sto
into
that
would
have
been
even
longer,
and
but
we
will
be
doing
that
I
think
both
technologies
can
exist
on
their
own
SD.
You
can
just
deploy
a
steel
or
you
can
just
deploy
calico
I
think
in
the
long
run,
both
of
them
together
are
greater
than
the
sum
of
the
parts,
so
we'll
be
very
often
seen
as
people.
A
The
first
problem
people
have
is
just
connecting
their
pods
together
their
containers
together
and
connecting
them
to
the
rest
of
the
infrastructure
so
that
things
outside
can
talk
to
your
pods
and
your
services.
So
people
deployed
calico
to
get
the
network
running,
you
know
a
simple
scale,
etc,
and
then
they
start
using
calico
policy
and
they
might
just
be
using
standard
cube
proxy
and
other
things
for
the
service
mesh.
A
Then,
as
the
developers
start
going
to
get
more
feature-rich
capabilities
than
what
say,
cue
proxy
may
be
able
to
deploy,
deliver,
they
then
start
looking
at
sto
or
the
security
folks
really
want
to
control
TLS
encryption.
You
start
looking
at
is
do
so
there
you
go
the
other
way,
but
usually
what
we've
seen
in
practice
is
people
start
with
calico
and
then
they're
starting
down
to
layer
sto
on
top
of
that,
to
get
that
that
layer
5
through
7
functionality,
we
can
make
those
slides
available.
Yes,
guru
did
that
answer
your
question.
A
We
also
want
to
make
sure
that
the
pods
would
show
up
differently
labeled
in
the
in
the
graph,
but
those
have
all
been
labeled
as
front-end
and
back-end
and
then
had
the
PCI
compliance
label
attached
to
it
as
well,
and
you
have
had
the
same
effect
and
just
the
graph
would
have
I've
been
a
little
confusing.
So
that's
why
we
had
two
different
definitions.
There.
A
So
Roy
regarding
the
network
policies,
are
there
Kubb
neti
or
are
they
kubernetes
native
or
do
they
rely
on
things
in
calico?
Most
of
the
policies
you
saw
there
could
be
kubernetes
native
calico
has
some
additional
capabilities,
for
example,
kubernetes
until
very
recently
did
not
support
egress
filters.
That's
a
beta
feature
in
1.8
we've
squared
egress
filters
for
a
while.
A
There
are
a
few
other
things
we
can
do
in
calico
policy
that
you
can't
do
in
kubernetes,
although
that's
slowly
catching
up,
so
I
think
everything
you
saw
in
that
demo
would
work
once
you
had
egress
policy
filters
in
in
1.8,
so
it's
it's
possible
to
do
it
with
a
straight-up
kubernetes.
You
get
some
additional
bells
and
whistles
with
with
calicoes
superset.
A
Potentially,
from
a
networking
perspective
and
looked
at
contents
policy
lately,
but
last
time,
I
looked,
it
wasn't
quite
as
cheerful
as
what
we
have
in
calico.
The
bigger
one
is
is
overlays
the
reliance
on
overlays
and
we
think
that's
just
a
complication.
You
don't
necessarily
mean
calico
can
run
on
an
overlay
Network
but
does
not
require
overlays
I'm,
not
adding
extra
technology
to
meet
corner
cases.
So
I
think
from
a
simplicity
standpoint,
there's
just
less
moving
parts
in
calico
prepared
to
count
it.
A
A
A
A
The
case
manifests
used
in
the
demo
like
I,
said:
there's
a
little
bit
of
OpenShift
ich
nests
in
those
manifests.
No
the
Meccan
and
mechanics
we're
using
more
open
ship,
but
there's
some
there
we
will
get
a
set
of
kubernetes
manifests
out
fairly
soon.
One
thing
we
want
to
do
is
fix
the
stars
demo.
The
stars
demo
is
very
fragile
right
now,
so
we're
probably
going
to
anse
the
stars.
Back-End
is
written
in
ruby
and
this
is
a
rust
and
is
pretty
fragile.
A
So
we'll
probably
do
a
bit
of
a
rewrite
there
so
make
the
manifest
available,
but
there'll
be
a
more
solid
version
of
this
demo.
Once
we
fix
the
visualization
and
and
rust
automation
that
underpins
that
demo,
calico
versus
open
contrail
again
I'd
say
the
same
thing.
Our
policy
is
much
more
kubernetes
centric
and
less
Network
centric
much
more
pod
and
service
eccentric.
We
rely
a
lot
on
labels.
A
We
don't
rely
on
networking
artifacts,
like
virtual
networks
and
linking
them
between
with
intermediate
filters
firewalls,
except
where
we
do
this
all
the
filtering,
all
the
enforcement
that
happens
right
at
the
pod
boundary
outside
of
the
pod
boundary.
So
it's
trustworthy,
but
but
right
there
and
again
we're
not
relying
on
overlays
we're,
not
building
a
lot
of
complexity.
Overhead
into
this,
so
I
think
it's
again.
A
C
A
One
more
point:
if
that's:
okay,
I'm
sorry,
whenever
you're
done
I've
got
one
more
point:
if
I'm
allowed
a
lot
of
this
material,
we
covered
very
quickly
what
I
forgot
to
mention-
and
it's
the
only
plug
for
tie
gara
I'll
do
is
Tiger-
is
now
starting
to
offer
training
sessions
around
sto
and
networking
in
policy
etc.
So,
if
anyone
is
interested
in
those,
you
can
go
to
our
website
and
look
in
the
training
heading
and
we
have
classes
and
those
are
offered
remotely.