►
Description
Service Mesh Hub is a Kubernetes-native management plane that enables configuration and operational management of multiple heterogeneous service meshes across multiple clusters through a unified API.
Service Mesh Hub simplifies discovery, trust domain unification, access policy, and L7 traffic routing among other things.
In this demo, we look at a multi-cluster, virtual-mesh API for controlling multi cluster L7 traffic.
A
Once
again
appreciate
you
sticking
with
us
coming
to
our
YouTube
channel,
checking
out
these
videos,
there's
a
lot
to
cover
and
we're
pretty
excited
about
this.
My
name
is
Christian,
where
I'm
from
so
Lodi,
oh
and
covering
the
surface
mesh
hub
capabilities
in
the
previous
videos,
we
looked
at
capabilities
like
mesh
discovery,
workload,
discovery.
We
looked
at
things
like
mesh
Federation
in
terms
of
identity
and
and
route
Trust
domain.
A
In
the
previous
immediately
previous
video,
we
looked
at
treating
an
entire
virtual
mesh
as
a
single
logical
mess,
even
though
it
might
be
made
up
of
multiple
different
clusters
of
mesh
and
then
looking
at
an
API
like
on
the
access
control
policy
to
manage
access
control
between
the
services
that
might
be
running
in
this
virtual
match
and
in
this
demo
we'll
take
a
look
at
managing
the
traffic
between
the
the
different
clusters
ultimately,
but
treating
this
as
a
single
unified
mesh.
Let's
jump
right
in
from
the
previous
video.
A
We
have
our
port
forwarding
open
to
the
to
the
book
info
page.
So
that
should
be
all
good.
You
seem
a
low
balance
between
B,
1
and
B
2
reviews.
The
review
service
v3
is
running
in
cluster
number
2.
So
let's
take
a
look
at
that,
so
in
the
previous
demos
we
did
Fedder
8
the
mesh.
We
can
see
that
it
was
set
to
permissive
mode,
which
means
that
service
discovery
will
be
available
between
all
of
the
services
between
all
of
the
different
clusters.
A
So
what
that
means
is
under
the
covers
is
that
sto
will
well.
The
management
plane
will
drive
the
issue
of
control
planes
to
create
the
service
entries.
These
service
entries
are
how
services
from
if
in
a
particular
mesh,
can
see
services
running
in
outside
of
the
mesh,
in
this
case,
in
a
different
cluster.
If
we
take
a
look
at
one
of
these
particular
also,
these
are
the
service
entries
on
cluster
2.
You
can
see
the
services
running
a
cluster
one
from
close
to
two.
A
If
we
take
a
look
at
a
particular
service
entry,
what
we
can
see
is,
let's
close
this
for
one
second,
we'll
bring
it
back
when
we
need
it.
What
we
can
see
is
the
host
for
services
running
in
cluster.
Two
is
pointing
to
a
particular
address
now
this
particular
address
maps
to
the
sto
ingress
gateway
on
cluster
two.
So
that
means,
if
in
cluster,
one
I
want
to
talk
to
reviews
and
some
of
the
traffic
needs
to
go
to
cluster
two.
A
It
will
go
from
from
the
the
workload
in
cluster
one
to
the
Gateway
on
cluster
two
and
then
the
Gateway
will
know
how
to
do
the
proper
sni
routing
to
get
that
traffic
to
the
correct
service
on
cluster
two
without
breaking
mutual
TLS.
So
we'll
have
end-to-end
encryption
here,
and
this
is
how
these
services
know
how
to
how
to
route
to
each
other.
A
So
now,
let's
control
the
traffic
on
cluster
one.
Let's
use
the
traffic
policy
just
like
access
control
policy
which
treats
these
policies
in
terms
of
a
larger
virtual
mesh.
We
do
the
same
thing
with
traffic
policy
and
in
this
case
we're
all
we're
saying
is
when
we
talk
to
reviews
route
all
of
the
traffic
to
version
one.
So
let's
go
ahead
and
apply
that
oh.
A
I
guess
I
didn't
fix
that
part
of
my
demo.
Let's
go
is
running
on
GK.
You
can't
apply
resources,
reviews
pd-1
yeah.
That
way
you
only
and
then
it's
also
do
the
port
forwarding.
So
we
can
come
back
so
we
did
apply
it
now.
We
should
see
all
of
the
traffic
only
going
to
reviews
v1,
which
we
see
and
we
did
let's
introduce
the
way,
let's
introduce
traffic
routing
between
v1
and
v2,
using
our
traffic
policy.
A
So
let's
apply
that
and
so
far
this
isn't
doing
anything
all
that
unique
other
than
it
is
managing
this
from
a
virtual
mesh
level
instead
of
a
particular
single,
singular
control
plane.
So
if
we
report
forward
that
now
and
refresh,
we
should
see
version
2
of
reviews
every
there
we
go
now
we
have
version
2
now.
The
last
thing
that
I
want
to
show
is
how
we
can
route
the
traffic
now
between
multiple
clusters
using
this
same
unified
API.
A
And
we
should
see
the
traffic
routing
mostly
to
version
three
which
lives
in
a
cluster,
and
if
we
refresh
everyone
somewhat,
we
should
see
some
of
the
traffic
from
cluster
one.
So
now
we
used
this
unified
traffic
policy
to
drive
the
traffic
between
them.
You
know
within
a
single
virtual
match.
It
just
happens
to
be
across
multiple
clusters,
but
let's
look
under
the
covers:
what
did
it
actually
do?
It
did
create
SCO
resources.
In
this
case
it
created
a
virtual
service
named
reviews.
A
So
if
we
take
a
look
at
that
under
the
covers
that
really
just
created
a
virtual
virtual
service
with
routing
to
the
remote
service
as
well
as
as
the
local
ones,
now
it
is
possible
that
we
end
up
with
different
routing
rules
and,
like
we
saw
in
the
access
policy
you
with
the
traffic
policy
rule.
Let's
take
a
look
at
that.
Actually.
A
There
we
go.
What
we
can
see
is
that
in
traffic
policy
just
like
at
in
that
and
the
access
control
policy
that
we
saw,
we
have
the
ability
to
select
sources
and
destinations
and
specify
groups
of
sources
and
groups
of
destinations.
Now,
by
doing
this,
it
simplifies
the
the
number
of
config
resources
that
you
need
to
keep
track
of,
but
on
the
other
hand,
it
does
make
it
possible
for
you
to
kind
of
turn
your
head
and
say
alright.
A
What
exactly
is
the
policies
and
the
rules
that
are
applying
to
a
particular
service
for
the
traffic's
coming
into
that
service
or
out
of
it?
What
use
mash
CTL,
which
is
part
of
service
Michelle,
described
to
see
exactly
what
those
rules
are?
So,
let's
look
at
what
the
service
reviews
has?
We
can
see
that
at
the
moment
it
has
traffic.
A
A
Have
that
part
filled
in,
but
you
can
see
we're
building
tooling,
to
give
you
both
the
power
and
the
simplicity
of
running
a
virtual
match
or
a
grouped
set
of
meshes
along
with
the
the
tools
to
be
able
to
inspect
it
and
describe
it
and
and
understand
exactly
what's
going
on.
So
you
can
be
successful
with
your
mesh
now
in
the
next.
Video
is.
A
What
we're
going
to
do
is
take
a
little
bit
deeper
dive
into
this
API
there's
a
lot
of
good
stuff
in
here,
and
we
think
it's
really
powerful
and
we
look
we're
looking
forward
for
feedback
but
I'd
like
to
introduce
you
to
it.
Until
then,
I
recommend
that
you
take
a
look
at
the
service
mesh
hub
documentation.
A
Look
at
on
github
solo,
io,
/
service
mesh
hub,
go
to
slack
dot,
solo
dot,
IO
to
join
the
conversation
with
us
and
look
forward
to
hearing
any
input
or
thoughts
that
you
have
about
service
mash
up
and
managing
multi
cluster
SCO
or
really
multi
cluster
any
service
mesh.
So
in
the
enterprise
version,
we'll
we'll
be
exploring
these
different
capabilities
until
then,
thanks
and
swing
by
the
the
YouTube
channel
against
receive
the
deep
dive
into
the
different
APs
Thanks.