►
From YouTube: An Intro to Network Service Mesh (NSM) and Its Relationship to Service M... John Joyce & Tim Swanson
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
An Intro to Network Service Mesh (NSM) and Its Relationship to Service Mesh - John Joyce & Tim Swanson, Cisco
Open Source has many application service mesh related projects (Istio,Linkerd, SMI, etc.). Network Service Mesh (NSM), a relatively new addition to the Open Source landscape, aims to solve a slightly different problem. Used together they are immensely powerful. NSM aims to solve problems dealing with heterogeneous network configurations and multicloud scenarios, especially when exotic protocols like tunnelling are required. NSM can be used to solve microservice specific multicloud connectivity issues, but even with that connectivity, application service mesh integration with Istio doesn’t come for free. Application service mesh solutions are great in single cloud environments but become unwieldy or unusable across multiple environments. In this talk and demo we will show an NSM multicloud application connectivity solution with Istio integration to provide the control, security and observability applications require ACROSS multiple clouds. We will demo an NSM adapter for Istio which provides Istio a view of the NSM connected workloads. This will allow Istio to provide seamless control over microservices regardless of how they are connected.
A
Hello,
everybody,
my
name
is
John
Joyce.
My
co
contributor
here
at
Tim,
Swanson,
can
be
with
us,
he's
actually
doing
a
presentation
and
NSM
con,
which
is
just
on
the
other
side
over
here.
So
it's
just
me
a
little
bit
on
this
slide
template
the
slide.
Template
is
from
the
network
service
mesh
con
template.
So
what
you're
seeing
here
is
the
contributors
or
I'm?
Sorry,
the
the
sponsors
of
NSM
con.
So
that's
why
they're
listed
here
prominently
on
this
slide
deck?
A
A
So,
first,
what
is
network
service
mesh?
Well,
it's
a
CNC,
F
sandbox
project,
I.
Think
it's
been
a
sandwich
project
for
about
nine
months
now
approximately,
and
it's
really
trying
to
focus
a
little
bit
more
on
layer,
2
and
layer,
3
use
cases,
and
these
would
be
use
cases
that
are
sort
of
that
the
typical
C&I
would
not
solve.
So
it's
really
focusing
more
on
layer,
2
and
layer
3,
and
that's
that
that
layering
is
where
it's
contrasts
with
like
app
service
mesh
or
service
mesh,
as
you
guys
are
all
hearing
about
today.
A
So
it
tries
to
provide
these
kind
of
properties.
Allow
heterogeneous
network
connections.
Exotic
protocols
make
tunneling
as
a
first-class
citizen
for
those
cases
of
require
it.
It's
policy
driven,
and
it's
really
trying
to
bring
some
of
these
layer.
2
layer,
3
complex
networking
into
it
to
developers
in
a
cloud
native
way.
So
that's
it's
kind
of
main
goal.
A
Ok,
so
what
is
the
value
proposition?
Well,
it's
really
trying
to
allow
complex
networking
to
be
brought
to
a
developer.
Very
simply
so
they
don't
have
to.
They
can
specify
complex
networking
in
very,
very
simple
terms
and
I'll
get
to
this
in
a
little
bit
later.
How
exactly
they
do
that,
and
it
does
this
by
kind
of
trying
to
comp
encapsulate
the
complexity
of
the
networking
within
something
called
NSCs
or
network
service
endpoints.
A
So
these
are
constructs
within
the
network
service
mesh
framework
that
allows
you
to
put
all
that
networking
complexity
into
those
elements
and
kind
of
contain
it
and
keep
it
away
from
developers
and
other
people
that
want
a
very
simple
view
of
how
this
all
gets
put
together.
It's
also,
maybe
not
everybody's
use
cases,
but
there
are
many
use,
get
people
that
are
interested
in
cloud
container
network
functions
and
container
network
function,
virtualization
and
the
chaining
that
happens
with
those
types
of
functions.
A
So
the
biggest
contrast
is
the
the
one
of
highlighted
there
at
the
end
in
red,
which
is
that
network
service
mesh
really
tries
to
focus
more
that
layer,
2
and
layer
3.
And
while
you
know
the
service
meshes
that
you
guys
are
talking
about
today,
I
sometimes
like
to
call
app
service
mess,
because
I'm
working
in
both
worlds
is
focuses
more
on
the
layer.
7
experience,
ok,
so
how's
this
work
a
little
bit.
This
is
I
only
have
10
minutes
here,
so
I
won't
be
able
to
get
into
a
lot
of
detail.
A
Go
through
these
slides,
pretty
quick,
but
the
idea
is
that
it
takes
a
work
load
or
an
application,
and
it's
able
to
stitch
in
network
services
through
what
I
represent
here
as
a
network
service
endpoint,
this
particular
network
service,
endpoint
of
characterized
as
like
a
firewall.
So
it's
able
to
stitch
those
network
service
and
points
into
a
connection
between
workloads
and
these,
the
the
stitching
can
be
arbitrary,
I
mean
or
not.
Nsm
is
able
to
allow
an
arbitrary
stitching,
of
course,
the
stitching
that
you
want
will
be
defined
by
how
you
layer
and
hi
Ohio.
A
You
have
hierarchically
created
your
network
services,
so
in
this
particular
case,
there's
a
desire
to
have
like
a
firewall,
a
dpi
device
and
a
router
between
these
two
workload.
It's
kind
of
arbitrary,
where
those
workloads
may
say
it,
whether
they're
in
the
same
cluster
across
clusters
across
clouds,
so
all
that
it's
sort
of
immaterial
to
the
actual
way
this
is
put
together.
A
So
here's
a
bit
of
a
drill
down
into
the
components
that
are
involved
in
network
service
mesh
and
I'm
not
going
to
be
able
to
do
full
diligence
to
this.
You
know,
in
the
amount
of
time
I
have
to
try
to
explain
this,
but
the
idea
here
is
you:
have
you
have
network
service
clients
or
with
your
label?
Here?
Is
that
and
as
sees
they
go,
they
run
alongside
the
application
pod.
They
also
generally
are
inserted
as
a
sidecar
as
well
as
I
heard.
A
You
guys
were
talking
about
a
little
earlier
and
then
there's
the
network
service
endpoints
themselves.
So
it's
are
shown
in
green.
Those
are
the
things
that
provide
the
the
actual
complex
networking
capabilities.
The
network
service,
endpoint
implementation
and
details
are
not
defined
as
part
of
the
network
service
mesh
project
they
can
be
brought
in
by
any
company's
third
parties,
other
open
source
groups,
the
actual
implementation
of
those
is
not
defined
or
restrictive
by
the
network
service
master
project
itself
and
then
then,
there's
a
there's.
A
A
bit
of
a
control
plane
represent
here
by
the
network
service
registry
and
the
network
service
manager.
The
network
service
manager
is
the
the
component
responsible
for
doing
these
stitching
the
stitching
from
the
workloads
using
v
wires
over
to
the
network
service
endpoints
chaining
together,
potentially
network
service
endpoints
and
the
registry
is
the
the
the
component
that
sort
of
keeps
track
of
where
these
network
services
are
where
they
have
registered
themselves,
where
they're
available
to
be
stitched
in
and
then
there's
a
data
plane
and
the
data
plane
itself.
A
A
lot
of
the
NSM
data
plane
right
now
is
based
on
FDI,
oh,
but
that's
a
switchable
pluggable
module.
It
could
be
based
on
other
technologies
as
well.
So
here's
for
many
of
you.
This
is
probably
the
most
important
thing,
which
is
how
do
I?
Actually
the
network
service
so
from
a
workloads
perspective,
it's
really
really
simple.
All
they
need
to
do
is
provide
an
annotation
that
says:
hey
I
want
that
network
service
and
the
network
service
itself
can
be
hierarchical.
A
So
it
consists
of
you
know
a
number
of
sub
Network
services,
so
it
can
be
actually
a
very
complex
X
object
in
the
end,
but
the
pod
itself
just
says:
hey
I
want
that
network
service.
Then
you
have
in
this
particular
case,
it's
a
simple
network
service
firewall,
that's
saying:
hey
I,
implement
that
network
service
that
ends
up
getting
registered
via
NSM
and
allows
it
to
be
stitched
together.
A
So
this
is
I'm.
An
SEO
contributor
I
recently
started
contributing
to
NSM.
So
this
is
one
of
the
things
that
we
did
to
show
how
these
two
things
play
together.
Okay,
so
what
I
did
was
we
took
a
network
service,
topology
and
network
service
and
an
NSM
network
service
endpoints
we
put
together
a
topology
that
stitch
those
together
across.
A
You
know
arbitrary
clusters
across
arbitrary
clouds,
and
what
we
did
is
we
put
steel
on
top
of
that.
So
in
that
particular
model
we
have
NSM
providing
all
sorts
of
interesting
layer,
2
layer,
3
connectivity,
connectivity,
it's
not
just
via
CNI,
we
can
put
firewalls,
we
can
put
VPN
tunnels,
we
can
put
all
sorts
of
things
in
between
those
endpoints,
and
on
top
of
that
we
put
envoy-
and
we
then
give
all
that
information
to
envoy
do
control
give
this.