►
From YouTube: Multicluster Service Mesh- Adam Sayah, Solo.io
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Multicluster Service Mesh- Adam Sayah, Solo.io
The digital transformation is pushing companies to adopt a cloud-native architecture, the microservice architecture is becoming a standard, resulting in a greater management complexity that a service mesh helps to alleviate, but how to solve the complexity when an organization has hundreds of clusters, or if multiple personas are involved.
- introduction to service mesh
- service mesh multi-cluster complexity
- introduction to management plane
A
A
A
So
the
agenda
today
we're
going
to
talk
about
first
talk
about
the
service
mesh,
the
origins
of
it
just
as
an
introduction
to
it,
then
we're
gonna
talk
about
take
an
example
of
a
service
mesh.
In
this
case.
We're
gonna
talk
about
this
joe
and
then
we're
gonna
talk
about
a
multi-cluster
deployment
and
what's
the
concerns
we
have
with
it,
and
then
we're
going
to
talk
about
how
to
solve
the
complexity
that
comes
with
multi-cluster
service
mesh
and
at
the
end,
we
are
going
to
end
with
demo.
A
A
The
microservice
editor
came
to
solve
a
lot
of
problems
that
we
used
to
have
with
the
monitor
the
monolith
architecture.
So
the
monolith
in
the
mod
architecture.
We
used
to
have
a
big
component
with
all
the
logic
in
it
so
to,
for
example,
to
change
only
a
part
of
the
logic
we
used
to
wait
for
a
long
release
cycles.
A
A
To
solve
these
issues,
we
moved
to
a
microservice
architecture
where
we
split
all
these
components
into
different
services
microservices
and
they
all
communicate
through
the
network
and
every
single
microservice
would
deal
with
only
a
part
of
the
logic,
so
we
would
have
only
so
yeah,
so
you
have
only
one
service
dealing
with,
for
example,
let's
say
a
banking
account,
you
have
like
a
user
microservice,
you
have
an
account
microservice
and
other
other
services
like
that.
So
in
this
scenario
you
can
scale
only
a
part
of
the
logic,
so
you
can
scale.
A
A
A
A
So
in
this
example
here
we
see
that
we
have,
for
example,
three
services
service,
one
service,
two
and
seven
three
talking
to
each
other.
We
have
a
side
car
with
every
single
service
and
that
deals
with
the
service
service
communication,
the
microsoft,
the
the
the
side
cars
will
deal
with,
for
example,
enforcing
the
the
telemetry,
the
mtls
between
the
component
having
a
unified
logging
and
all
these
things,
and
you
have
your
service
actually
dealing
with
only
the
logic
of
the
service.
A
So
the
service
won't
have
to
deal
with
all
the
cross-cutting
concern
and
doesn't
have
to
worry
about
network
failures
and
all
these
things,
all
that
is
dealt
with.
We
handle
it
with
the
sidecar.
The
developers
will
only
focus
on
developing
the
services
and
only
the
core
components
and
logic
of
the
of
the
microservice.
A
Now,
in
a
lot
of
service
measures,
we
use
envoy
as
a
sidecar,
and
this
is
why
we're
taking
the
example
fanfare
here
envoy
is
a
lightweight
gateway.
It's
http
2!
You
can
deploy
it
next
to
your
service
to
do
it
to
deal
with.
For
example,
we
talked
about
service
service,
mtls,
enforcing
policies
like
that
enforcing
like
having
a
way
to
get
telemetry
tracing
between
components,
all
the
things
that
we
needed
in
the
microservice
architecture
to
make
it
more
resilient.
A
Now,
for
your
data
planes
or
from
service
service,
you
need
actually
a
control
plane
that
controls
this
configuration,
push
it
to
your
side,
cars,
to
enforce
this
policy
and
manage,
and
basically
configure
the
traffic
from
service
to
service,
and
here
in
this
example,
we're
going
to
take
an
example
of
a
service
mesh
istio,
where
we
have
a
control
plane
that
control
your
data
plane
and
push
policies
on
your
side
cars.
Here
we
see
them
in
red.
A
A
The
sidecar
will
have
some
configuration
they've
been
pushed
through
the
control
plane,
the
control
control
plane,
also
configure
the
service
discovery
and
other
things,
so
we'd
have
a
way
to
know
where
to
call
the
other
service
and
how
to
call
it
right.
In
this
case,
we
have
mtls.
We
can
have
some
policy
enforcement
that
we
need.
You
know
to
give
access
to
the
service
user
from
the
service
account.
A
So
that's
the
role
of
a
control
plane-
and
this
is
an
example
of
like
how
istio
dales
is
actually
implementing
the
basically
the
service
mesh
right
now
to
configure
your
control
plane
to
configure
istio.
In
this
example,
you
will
need
multiple
configuration.
You'll
need
multiple
components,
multiple
configuration
here.
We
have
a
virtual
service,
for
example,
that
is
used
for
routing
traffic.
You'll,
have
this
destination
rules?
You
can
have
a
service
entry
every
that's
an
example
for
istio,
but
every
single
service
match
will
need
some
sort
of
configuration
for
routing
between
components.
A
And
we
will
talk
about
as
controlling
access
control
in
in
istio,
because
it's
needed
later,
I'm
going
to
talk
about
it
more.
In
this
example
here
in
istio,
we
use
spf
framework
where
spiff
spiffy
is
a
framework
that
allows
you
to
have
like
enforce
some
policies
like
on
trusting
communication
between
communication
between
workloads
in
here.
So,
for
example,
you'll
have
a
space
spf
id
in
istio
you'll
have
spfee
the
trust
domain.
Then
you
have
namespace,
then
the
service
account
and
that's.
If
you
go
back
to
go
back
to
the
example
of
isio.
A
Let's
say
if
we
have
account
the
service
account
that
wants
to
talk
to
the
service
user.
You'll
have
first
the
mtls
that
enforce
you
know
security
between
the
two
but
after
verifying
mtls.
You
also
verify
that
the
account
microservice
has
access
to
the
user
microservice
and
that's
through
saying
the
creating
like
a
policy,
a
security
policy
in
istio
that
configures
this
authorization
allowing
the
traffic
after
establishing
mtls
allowing
the
traffic
from
the
control
from
the
account
the
service
microsoft's
account
in
this
example
to
talk
to
the
service
user.
A
Now,
after
just
talking
giving
an
example
of
an
introduction
to
how
is
to
operate
and
what's
a
control
plane,
now
we're
going
to
talk
about
multi-cluster
service
mesh,
how
to
install
a
service
mesh
or
how
to
manage
multiple
service
meshes,
you
know
we
talked.
We
give
an
example
of
a
service
mesh
on
only
one
cluster,
where
you
have
like
your
control,
plane,
eco
configuring,
the
data
plane
and
side
cars
between
the
components.
It's
pretty
simple
to
to
look
at
it
into
only
one.
A
A
Now
how
we
do
that
in
istio,
there's
different
ways
of
deploying
of
handling
this
multi-cluster
deployment.
In
this
case
here
we
have
a
way
where
we
can
have
a
control
plane
only
one
cluster,
but
we
need
to
give
access
to
the
api
server.
So
the
control
plane
needs
to
know
need
to
have
access
to
the
api
server
on
different
cluster.
To
get
the
data
about
the
services
running
within
the
cluster
and
other
things,
so
imagine
also,
we
have
also
in
a
mode
where
you
have
the
con
multiple
control
planes.
A
Every
single
cluster
has
its
own
control
plane,
but
also
we
always
need
to
have
access
to
the
api
server
on
different
clusters.
Imagine
the
complexity
when
you
have
100
cluster
and
you
have
100
mesh
right,
how
can
you
it's
going
to
just
it's
going
to
be
n2,
so
every
single
microservice
need
to
know
about
every
single
sorry.
Every
single
cluster
will
need
to
know
about
every
single
other
cluster
to
be
able
to
establish.
A
You
know
this
multi-mesh
configuration
now
you
guys
see
that
when
we
have
multiple
cluster
instead
of
coming
with
different
problems
like
if
we
take
an
example
of
histo-
and
let's
say
we
want
to
configure
something
like
that
right,
where
we
have
two
clusters
cluster
one
and
cluster
two-
they
both
have
different
components
in
this
case.
I'm
using
the
example
of
the
istio
book
info
example.
A
A
Now
you
guys
see
that
we
have
this
on.
Let's
say
we
have
this
on
two
different
clusters
right
and
you
want
to
have
a
way
to
basically
say:
let's
say
you
have
a
new
version
of
the
review
microservice
and
you
just
want
to
try
something
else.
You
want
to
try
to
route
the
traffic
some
traffic
from
the
cluster
one
to
the
version
three
of
the
reviews
of
the
other
on
the
in
the
other
cluster
right.
A
That's
a
common
use
case
specifically
like,
especially
if
you
want
to
do
like
some
blue
green
deployments,
and
things
like
that
right
now.
If
you
want
to
do
that
using
istio
as
an
example
of
a
service
mesh,
you
will
have
to
create
a
lot
of
configuration
so
here
only
in
the
cluster
one
you'll
have
to
create
a
virtual
service
that
points
to
basically
the
review
microservice.
A
Then
you'd
have
to
create
a
destination
rule
a
service
entry.
That's
only
on
customer
one,
then,
on
cluster
two,
you
also
need
to
create
other
configuration
like
when
the
traffic
is
routed
to
cluster
two.
You
need
to
transform
it
to
a
local
local
call
to
your
review
microservice.
You
also
need
to
define
your
destination
rule
and
that's
basically
gonna
call
the
pod
version.
A
Three
you're
gonna
call
to
your
review
v3
on
the
cluster
too,
but
you
guys
see
that
this
is
a
pretty
standard
scenario,
but
it
gets
pretty
complex,
pretty
fast
to
create
something
like
that.
Imagine
you
have
hundreds
of
clusters
how
to
manage
all
this
configuration
right.
You
also
need
to
authorize
the
access
we
were
talking
about
spf
as
an
introduction
here,
where
we
use
it.
A
Basically,
in
this
we're
saying
that
we're
allowing
you
know
you
guys,
can
you
notice
here
the
spf
id
that
basically
is
used
to
allow
the
traffic
from
the
service
the
cluster
one
to
the
cluster
two
to
the
to
the
service
review?
Now
you
guys
see
that
this
is
a
pretty
simple
use
case
and
it
comes
with
a
lot
of
configuration
and
we
see
that
when
we
have
multiple
clusters,
it
comes
with
a
lot
of
concerns,
a
lot
of
a
lot
of
issues
that
you
can
have
like
while
scaling.
A
So
one
of
the
issues
can
be,
you
need
to
have
a
way
to
see
the
configuration
over
all
your
microservices.
All
your
service
measures.
You
want
to
know
every
single.
What's
the
status
of
every
single
service
mesh,
you
need
to
have
a
kind
of
a
service
discovery
over
every
single
over
all
your
service
meshes.
You
need
to
have
a
way
to
unify
the
identity.
You
need
to
have
a
way
to,
for
example,
say
if
you
have
mcls
between
one
cluster
and
you
have
mtls
in
the
other
cluster.
A
You
need
to
have
a
way
also
to
unify
the
identity,
to
have,
for
example,
the
same
rule
ca.
So
you
can
have
some
sort
of
mtls
between
cluster
one
to
a
service
in
cluster
two
right,
if
every
every,
if
every
single
cluster
has
its
own
identity,
that
won't
work
to
have
a
multi-cluster
communication
right.
You
can
also
have
you
need
a
way
to
have
a
configuration,
pretty
a
pretty
easy
configuration
deployed
to
only
like
some
management
cluster
and
that
configuration
needs
to
be
deployed
to
every
single
cluster
right
you
want
to
like
we.
A
We
took
an
example
of
and
pretty
standard
way
of,
doing,
like
some
kind
of
canary
routing
here
between
two
clusters,
and
you
guys
see
that
the
complexity
was
yet
pretty
complex
pretty
fast.
So
you
need
to
have
a
way
to
simplify
this.
You
also
need
another
way
of
enforcing
high-level
policies
like
if
you
have
different
personas
operating
your
service
meshes.
A
You
want
to
just
have
a
way
to
create
a
policy
that
says
hey
this
team
or
this
user
is
allowed
basically
to
route
traffic
from
his
service
mesh
to
only
this
service
mesh,
or
only
these
services,
regardless
of
the
implementation
of
how
we
do
it
behind
the
scene,
for
example,
in
the
control
or
like
in
istio,
the
apis
are
pretty
low
level,
so
you
know
for
doing
the
routing.
You
need
all
virtual
services
and
you
need
service
entries
and
distinction
rules.
So,
regardless
of
all
this,
what
is
more
important?
A
You
need
something
like
a
component
that
knows
about
all
the
service
meshes
knows
about
all
the
clusters
knows
about
all
the
control
planes
and
be
able
to
manage
them
all
right.
So
in
this
use
case,
I'm
taking
as
an
example
glue
mesh,
which
is
more
familiar
with,
which
is
a
management
plane
that
operates
on
multiple
clusters,
for
example.
Here
in
this
use
case,
you'll
have
your
management
plane
where
you
register
different
clusters.
A
So
let's
say
I
have
so.
I
have
my
management
plan
where
I
have
two
cluster
registered,
so
we
have
two
control
planes
right
in
this
case
contest
cluster
one
and
cluster
two.
They
both
have
issue
installed
and
if
I
can
look
at
the
cluster
one,
you
can
see
that
the
workloads
here
we
have
review
version
1
and
review
version
2
right
now.
If
I
go
back
to
the
other
cluster,
we
can
see
that
in
this
cluster
we
have
version
1
version
2
and
version
3..
A
You
see
that
the
other
cluster
has
only
it
has
the
three
versions
and
the
first
cluster
has
only
two
versions,
and
we
want
to
do
some
sort
of
canary
deployment
to
basically
route
only
part
of
the
traffic
to
this
cluster
right
now.
The
only
difference
between
all
these
services
in
in
the
review,
the
different
versions,
is
that
the
version
one
has
no
like.
When
we
look
at
this
ui
here
so
version,
one
has
no
color
version.
Two
has
like
a
black
stars
and
version
three
has
red
stars.
A
A
For
that
I
just
need
to
create
one
configuration
on
my
management
plane
saying
that
what
I
need
is
like
when
I
try
to
call
the
review
service
in
my
cluster
one
behind
like
when
calling
the
service
the
routing
they
need
to
operate,
is
that
I'm
gonna
route
75
of
the
traffic
to
the
version
three
in
the
cluster
two
and
I
want
to
route
15
to
the
version
one
same
cluster
and
ten
percent
of
the
to
the
version.
Two
on
the
same
cluster.
A
A
A
You
need
this
high
level
view
that
comes
with
a
management
plane,
so
you
guys
see
again
that
the
management
plane
is
really
important
when
scaling
and
when
having
multi-cluster
service
mesh.
With
that,
thank
you
for
listening
to
me.
I'm
I'll
be
happy
to
have
the
conversation
going
on
the
social
media.
Obviously
you
can
guys
reach
me
out.
I
have
you
know
I'll
be
happy
to
have
any
any
conversation.