►
From YouTube: Networking the Service Mesh Proxy: Where We Are, Where We’re Going - Tim Swanson & John Joyce, Cisco
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Networking the Service Mesh Proxy: Where We Are, Where We’re Going - Tim Swanson & John Joyce, Cisco
Redirecting application traffic to/from a proxy and lifecycle management of proxy instances are common requirements for service mesh implementations. The traffic and lifecycle problems are, to a large extent, tied. Many ideas for flexibility and optimization are emerging from multiple communities. This talk will discuss the current approaches for networking application service instances with sidecar proxies including lifecycle management. It will cover those implemented by Istio & Linkerd (including the Istio CNI plugin) as well as other open projects solving the same or similar patterns.
https://sched.co/MPes
A
A
We
do
have
an
agenda,
it's
pretty
long,
but
we
really
are
just
going
to
or
the
main
point
is
we're
gonna
focus
on
we're
not
going
to
go
through
Sto.
Okay.
So
if
you're
expecting
an
overview
of
this
do-
and
this
deal
features
you're
not
going
to
get
it
here,
we're
going
to
focus
on
us
some
specific
problems
and
networking
the
service
mesh
proxy
and
various
approaches
in
different
communities.
A
So
when
we
talk
about
when
you
see
pictures
of
service
mesh,
you
know,
basically,
you
see
an
application
and
a
proxy
that's
hosted
very
near
it
connected
to
another
proxy
back
to
the
app
another
application
instance
and
when
I
first
saw
that
picture
the
the
thing
that
struck
me
was
how
the
hell
do
they
do
that
little
arrow
right
there.
So
between
the
hello
wait,
how
does
all
the
traffic
get
to
the
proxy?
So
there
there's
a
lot
of
techniques
for
that
and
it's
it's
really
related
to
the
the
way
that
that
proxy
is
injected.
A
So
in
the
environment
that
the
proxy
and
the
application
instance
are
running
in
kind
of
drives
how
that
works
as
well.
So
there's
multiple
layers
here
for
this
problem,
we're
going
to
kind
of
go
through
some
of
those
and
then
the
the
actual
solutions
and
the
advantages
and
disadvantages
of
solution
mostly
fall
in
the
category
of
what
works
in
the
most
places.
Maybe
some
performance
improvements
and
big,
a
big
one
is
how
does
it
integrate
with
existing
application
and
proxy
orchestra
Solutions.
A
So
for
the
trip
we
call
it
traffic
redirect
the
the
how
the
traffic
ends
up
in
the
proxy
and
how
the
proxy
ends
up
pushing
all
the
traffic
back.
So
the
the
most
common
solution
in
you'll
see
is
IP
tables
and
we've
there's
support
for
IP,
six
tables
added
and
some
solutions.
This
do
being
one
and
then
evolving
is
our
EBE
BPF
solution.
So
the
cilium
project
has
has
a
solution
that
works
with
t
proxy
so
at
basically
they
put
the
they
use.
A
Ip
tables
T
proxy
target
to
put
the
proxy
right
in
the
raw
in
the
raw
IP
table
and
they
so
they
so
the
proxy
there's,
no
TCP
connection
tracking
and
stuff
like
that
in
the
Linux
stack.
So
that's
a
good
good,
stuff,
good
stuff
and
then
they're
going
further
in
the
cilium
project
with
socket
redirect
so,
basically
just
connecting
the
application
socket
with
the
the
proxy
socket
and
then
another
approach
more
in
line
with
some
proxy
orchestration
techniques
is
using
a
host
to
be
switched.
A
A
solution
like
similar
to
like
a
service
function
chaining
and
then
for
orchestrating
the
the
configuration
of
these
different
approaches.
There's
actual
options,
multiple
options
there,
so
the
main
one
that
like
sto
and
linker
D
I
guess
a
steal,
supported
supports-
is
having
a
NIC
container
that
has
net
admin
from
permissions
and
that
does
the
IP
tables
set
up.
A
So
those
are
the
basic
solutions.
The
for
the
proxy
lifecycle,
there's
also
multiple
solutions
for
that
and
where
these
are
in
various
stages
of
development
or
proof-of-concept.
Here
the
main
one
that
everybody
seems
to
use
right
now
is
the
admission
controller
approach
with
a
mutating
web
hook,
and
it
injects
a
sidecar
and
kubernetes
manages
you
know,
bringing
up
the
container
for
the
proxy
and
in
all
that
stuff,
the
disadvantage
of
that
is.
A
The
init
container
is
not
networked
through
the
proxy.
So
none
of
your
security
stuff
that
you've
done
for
that
pod
is
going
to
work
on
your
own.
It
container
in
the
sea,
the
maybe
the
solution
for
that
is
to
start
the
proxy
in
the
cni.
So
the
sea
and
I
would
baby
basically
start
up
a
proxy
process
and
the
advantage
there
is
that
before,
before
anything
runs
in
the
pod,
the
whole
proxy
network
is
set
up.
A
An
alternative
is
the
network
service
mesh
solution
which
could
be
used
to
cause
a
proxy
to
proxy
pod
to
actually
show
up
on
on
the
same
node
as
the
application
instance,
and
then
why
are
those
together?
That's
still
just
theory
nobody's
done
that
yet
and
then
the
node
agent
thing
I
was
talking
about
that,
couldn't
be
used
to
also
just
bring
up
a
proxy,
so
we're
gonna
quickly.
A
A
A
You
know
who
can
do
what
so
we
we,
the
the
current
project,
is
really
tightly
coupled
with
this
do
so
it's
driven
by
sto
features
and
reviewers
and
and
and
contributors.
It
takes
advantage
of
the
CNI
chaining
that
I
just
talked
about
to
plug
a
C&I
plug-in
into
a
existing
CNI
configuration.
So
it
doesn't
actually
do
any
full
networking
itself.
It's
just
responsible
for
doing
that.
Redirect
I
showed
in
that
picture,
so
it
and
it
installs
by
a
demon
set
like
I,
told
you
the
best
practices
work.
So
we
the
the
way
it
works.
A
So
this
is
the
visualization
of
the
CNI
plug-in
chain
we
have
each
node
has
a
demon
set
and
that
demon
set
sets
up
an
sto
C&I
config
in
the
existing
configuration
on
that
note
for
the
cni,
so
the
couplet
when
it
runs
when
it
when
a
pot
is
coming
up.
It
runs
each
one
of
these
in
the
chain,
each
plug-in,
that's
in
the
config
chain
and
the
ISTE
OC-
and
I
is
doing
this
right.
So
it's
setting
up
IP
tables
to
make
that
traffic
redirect
happen.
So
how
does
the
IP
tables
work?
A
A
If
this
app
is
a
server
so
he's
gonna
have
some
ports
open
and
the
excuse
me,
the
mat
free
routing
chain
is
gonna:
have
those
ports
configured
in
rules
and
assuming
it's
OSU
in
link
Rd
mostly
operate
on
TCP
traffic,
so
that
that's
going
to
be
or
only
offer
in
TCP
socket.
So
that's
going
to
end
up
falling
in
this
check
and
it's
going
to
get
redirected
to
the
proxy.
So
there's
a
in
IP
tables.
There's
a
redirect
target
in
that
redirect
target
it's
kind
of
like
a
NAT
function,
but
it
doesn't
modify
the
packet.
A
So
it's
it,
the
the
proxy
sees
the
actual
desta
address
and
port
and
stuff.
So
this
redirect
is
just
to
approximate.
This
prophecy
is
listening
on,
so
all
the
traffic
ends
up
in
the
same
port
in
this
proxy.
Similarly,
on
the
outbound,
the
in
that
output
chain
is
going
to
when
the
proxy
send
is
going
to
send
to
this
app.
It's
the
the
output
chain,
it's
going
to
notice
hey
this!
Is
the
proxy
kid
sending
this
so
we're
not
going
to
we're
not
going
to
do
the
redirect
back
to
this
guy.
A
So
it's
going
to
end
up
in
the
route
target
and
end
up
in
back
the
app
and
when
the
apps
and
sends
its
traffic.
It's
it's
the
same
chain.
It's
just
a
different
representation
of
this
chain
of
this
picture.
So
it's
the
net
output
chain
again,
the
owner
is
not
the
proxy
and
it's
going
to
end
up
getting
redirected
to
this
to
the
proxy
and
then
the
proxy
is
going
to
do
its
thing
and
then
set
out
send
out
through
the
the
same
that
output
chain.
A
A
So
it's
do
C
and
I
features
there.
Really
we
do
support
parity
with
in
it
the
NIC
container.
So
it
does
include
T
proxy
support
for
working
with
psyllium.
It's
it's.
It's
a
compliant
fully
to
the
cni
spec
and
it
has
in
the
way
sto
gives
it
parameters
as
via
annotations
on
pods.
So
when
that
when,
when
there's
an
injection
of
a
sidecar,
this
c-
and
I
will
notice
it
and
do
the
action
on
that
pod
and
it
won't
do
it
to
the
other
pods
that
don't
have
that
those
annotations.
A
So
if
in
the
future
work,
I
talked
about
doing
the
lifecycle
of
the
prophecy
in
the
cni
and
that's
there's
a
engineer
named
marco
luke
so
from
Red
Hat
he's,
but
he's
got
a
proposal
for
that
actual
code.
So
we're
we're
looking
to
get
that
in
soon,
but
it
needs
some
shaking
out.
But
the
gist
is
that
when
the
the
CNI
runs,
it's
going
to
start
a
envoy
or
a
proxy
instance
in
the
the
same
network
name
space
as
the
pod
and
it's
going
to
and
then
set
up
the
IP
tables
for
that
and
that'll.
A
Avoid
that
an
it
container
problem
that
I
talked
about
where
the
so
the
NIC
container
will
be
networked
exactly
the
same
as
the
application,
so
your
sto
rules
that
you
put
on
the
app
pod
will
apply
to
the
init
container
as
well.
The
the
cons
for
that
are
obviously
that
this
is
not
going
to
be
in
the
pod
spec,
so
the
Envoy
process
is
invisible
to
kubernetes,
so
something
if
you're
gonna
is
you
have
to
account
for
it
in
your
resource.
B
B
Ask
if
gear
is
quite
a
bit
here
and
talk
a
little
bit
more
about
how
the
COC
and
I
relates
to
other
projects
or
how
we
want
it
might
want
to
make
some
of
the
functions
that
we
did
with
the
Tim
was
described
in
C
and
I
does
how
we
might
want
to
do
them
differently
than
he
just
described
so
the
first,
the
most
obvious
one
is:
how
does
this
relate
to
linker
D?
So
we've
had
some
interaction
with
the
linker
D
guys
and
as
I
believe
they
mostly
borrowed
our
code.
B
Almost
you
know
verbatim
for
how
we
did
it
and
they've
adopted
that,
and
they
have
that
as
a
feature
that
I
think
is
in
a
beta
stage
for
them.
So
we
have
talked
to
them
about
actually
trying
to
make
this
a
common
repo
in
some
way
or
have
made
the
code
entirely
common.
So
it's
shared
we're
not
quite
there
yet,
but
that's
something
that
may
happen
so
the
other
one
that
you've
probably
heard
a
lot
about
this
week,
there's
been
some
keynotes.
A
number
of
other
sessions
is
the
network
service
mesh.
B
They
it's
an
incubation
project.
There
are
some
possibilities
that
you
we
could
integrate
with
the
network
service
mesh
and
could
have
the
network
service
mesh.
Do
some
of
the
functions
here
or
have
some
of
what
the
network
service
mesh
does
have
sto
or
service
like
an
app
service
mesh
plugged
by
the
network
service
mesh
itself.
B
So
we'll
talk
about
that
a
little
bit,
the
other
one
that
Tim
referenced
quite
a
bit
is
how
does
this
integrate
with
cilium
and
eb
PF
in
the
case
of
cilia
mini
BPF,
a
lot
of
it's
more
about
performance,
and
you
know
how
you
can
change
sort
of
the
data
plane,
the
actual
data
plane.
That's
used
to
move
the
packets
around
versus
the
actual
process
and
orchestration,
but
we'll
talk
about
that
a
little
bit
too.
B
So,
first
a
little
bit
of
a
summary
on
NSM.
So
probably
most
people
have
heard
about
this
already.
This
is
a
week,
so
I'll
try
to
go
a
little
bit
quick
here,
but
network
service
mesh
is
very
different
than
what
we
sometimes
refer
to
as
just
service
mesh
or
app
service
mesh
like
SDO
or
link
or
D
network
service
mesh
concentrates
more
on
the
network,
a
level
and
how
to
provide
basic
network
connectivity
and
network
services
between
along
the
lines
of
a
connection
or
between
endpoints
of
the
connection.
B
So
it's
less
about
how
the
app
might
want
to
do
its
whole,
all
its
work
and
more
about
how
that
the
network
is
constructed
between
two.
You
know
a
source
and
a
destination.
So
the
way
it
does.
This,
though,
is
it's,
tries
to
be
fairly
integrated
with
kubernetes
and
tries
to
determine
the
requirements
of
the
connection
and
the
constraints
of
the
connection
via
annotations
and
other
kubernetes
types
of
resources
or
definition
so
that
it
tries
to
be
integrated
tightly
with
kubernetes
and
in
the
case
of
NSM,
there
is
no
tight
binding
to
a
data
plane.
B
B
So
this
is
just
a
quick
sort
of
topology
view
borrowed
from
the
network
service
documentation
itself.
There
is
a
there's,
a
client
that's
run
or
closely,
coupled
with
the
application
itself
to
actually
create
a
connection
and
and
tell
the
network
service
manager
what
kind
of
connection
it
wants.
The
network
service
manager
itself
is
a
daemon
set
that
will
actually
set
up
the
connection.
I
show
a
network
service
endpoint
here,
that's
that
could
be
a
function
like
a
VPN
or
a
firewall
that
represents
some
kind
of
in
in
NSM
lingo.
B
B
So
this
is
just
a
quick
example
of
what
kind
of
what
might
happen
again
using
some
of
the
network
service
mesh
language.
But
the
idea
is
that
a
user
called
Sarah
might
need
a
connection
to
the
corporate
Internet
and
she
doesn't
want
to
be
too
bothered
with
what
kind
of
constraints
or
requirements
that
connection
has.
But
she
has
you
know
a
network
admin
and
a
security,
admin
and
other
constraints
that
will
be
imposed
on
her
and
those
constraints
can
be
imposed
through
configuration
and
annotations
in
kubernetes.
So
she
doesn't
have
to
be
aware
of
them.
B
So
how
does
this
relate
to
the
cni?
So
at
the
current
time?
There's
there's
no
actual,
integrations
or
proof
of
concepts
to
to
do
this
work,
but
it
sort
of
falls
out.
Naturally,
if
you
think
about
it
that
if
the
network
service
mesh
is
actually
orchestrating,
what
kind
of
network
elements
and
services
need
to
be
in
the
path
of
a
connection,
it
could
easily
are
quite
easily.
You
could
envision
like
what
we
talked
about
with
the
cni
falling
into
that
same
pattern,
where
it's
hey.
B
This
particular
application
wants
to
be
part
of
a
service
of
the
mesh.
Let
me
network
in
a
proxy.
Let
me
can
have
that
proxy
I
get
its
configuration
from
a
control
playing
like
SDO
or
link
or
D
or
whatever,
and
that
represents
a
you
can
think
of
that
proxy
is
just
a
sort
of
another
Network
function
that
the
network
service
match
is
aware
of
the
needs
to
be
inserted
for
that
particular
service,
and
it
could
maybe
maybe,
if
the
app
or
that
particular
pod
is
doing
different
types
of
services.
B
Maybe
that
proxy
is
only
inserted
for
some
types
of
traffic
and
not
others.
So
one
again,
this
is
all
sort
of
a
speculative,
but
you
know
with
the
one
thing
that
we're
going
to
explore
a
little
bit
with
the
network
service
mesh
guys
is
whether
there's
anything
that
should
be
pursued
here
and
whether
this
should
be
more
formalized.
B
So
quickly
on
cilium
we've
actually
talked
about
this
a
little
bit
too,
with
the
case
of
psyllium,
as
I
said
that
the
biggest
play
here
is
that
this
would
be
could
be
a
much
more
performant
way
to
connect
the
proxy
and
the
app
together
you
can
iptables
is
not
very
performant.
It's
quite
quite
well
known,
it's
quite
easy
to
deal
with,
but
it's
not
very
performant.
So
the
first
obvious
thing
is,
and
the
cilium
guys
have
it's.
Unlike
the
NSM
stuff,
a
lot
of
this
does
exist.
The
cilium
guys
do
work
with
this.
B
Do
they
do
are
able
to
plug
in
proxies.
They
have
a
couple
solutions
available
for
that.
So
the
one
thing
that
the
ISTE
o
team
is
interested
in
with
the
case
of
psyllium
is
actually
having
a
tighter
integration
with
with
ebps
and
I
shouldn't,
say:
psyllium,
specifically
more
tighter
integration
with
EBP
F,
so
EBP
F
is
an
option
to
plug
in
the
proxy
to
get
better
performance.
So
that's
something
that
the
sto
community
has
been
actively
talking
about
and
very
likely
to
pursue
more
actively
in
one
of
the
upcoming
releases.
B
So,
as
Tim
was
referring
to
this
sort
of
two
ways
that
they
approach
this,
they
can
do
a
transparent,
proxy
or
socket
level.
Redirect
and
I
show
the
three.
The
three
variants
here
on
the
left
here
is
the
traditional
IP
tables.
You
see
we
passed
through
iptables
twice
through
the
TCP
stack
a
few
times,
then,
when
you
do
the
transparent
proxy,
you
get
one
level
of
performance
boost
in
that
you're,
not
actually
passing
through
IP
tables
and
you've
reduced
the
amount
of
the
stack
that
you
have
to
go
through
and
then
on.
B
The
right
is
an
even
greater
opportunity
for
performance
boosts,
so
I
guess.
In
summary,
between
these
three
maps,
it's
that
I
talked
about
the
linker
D
method.
That's
already
in
the
works.
They
have
something
almost
identical
to
us,
but
it's
not
those
two
projects
are
still
separable
and
the
code
base
is
separable.
So
there's
an
opportunity
perhaps
to
combine
that
and
SM
is
all
exploratory.
B
But
it's
something
that
we
could
look
at
to
see
how
that
meshes
with
the
NSM,
sorry,
the
pun
and
then
the
cilium
stuff
is-
has
been
actively
talked
about
and
likely
to
actually
see
some
more
specific
developments
available
over
the
next
couple
months.
So
again,
this
is
just
a
sort
of
summary
back
to.
We
showed
this
slide
earlier,
just
showing
a
summary
of
where
we
are
with
the
different
approaches,
some
of
the
pros
and
cons
of
the
different
options
and
and
and
what
we're
doing
and
where
we're
at
with
them.
A
I
just
wanted
to
add
I
mean
the
this,
the
work
of
like
where
the
proc
who
instantiates
the
proxy-
that's
probably
the
biggest
you
like
discussion
point
on.
What's
going
on
what
should
be
the
future?
There
is
a
lot
of
momentum
behind
having
like
the
CNI.
Do
it
and
actually
psyllium
has
really
integrated
envoy
and
they
there
could
be
put
some
their
their
model
when
they
do
their
l7
protocol
proto
policy,
it's
a
little
bit
different
than
the
proud
of
her
sidecar
model,
but
it
could
be
probably
adapted
to
that.
A
So
there's
there's
some
definite
or
you
know.
Maybe
this
TOC
and
I
just
becomes
the
thing
that
starts
the
proxy.
So
there's
that's!
That's
probably
if
you're
wondering
what's
going
on
in
the
community,
that's
probably
the
biggest
we
you
know
change
that
would
impact
most
of
us
steel
users
out
there.
A
B
The
final
slide
is
really
just
our
references
from
the
thing
again.
A
lot
of
these
references
are
from
open
source
groups,
also
where
the
cni
project
is
where
we
more
than
love
anybody
to
help
contribute
it's
a
fairly
small
team.
There's
not
a
huge
amount
of
work
either.
So
it's
very
easy
to
get
right
in
there
and
do
some
PRS
and
do
some
contributions
and
be
one
of
the
leads
yeah.
A
One
of
the
ipv6
main
contributor
here
is
here
and
we're
possibly
going
to
move
to
NF
tables
from
IP
tables.
So
there's
there's
things
that
could
be
done.
We
might
there's
the
way
that
the
IP
tables
are
played
out
is
using
the
IP
tables
client,
not
not,
there's
sort
of
executable
rather
than
like
a
go
library.
So
there's
potential
for
changes
there.
So
there's
a
there's,
a
lot
of
cut
your
teeth,
kind
of
things
that
could
be
done
pretty
quickly
and
but
it's
a
great
place
to
learn.