►
Description
See what’s new with Service Mesh Hub -- On April 8th, Solo.io announced the open sourcing of Service Mesh Hub with new enhancements for multi-cluster orchestration aka ‘virtual mesh’ and support for the new Istio version 1.5.
Service Mesh Hub is the industry’s first unified dashboard for installing, discovering, operating and extending a single service mesh or group of meshes. Launched last May at KubeCon EU, we have been working with end users and the community to understand their preferred deployment patterns for service mesh and the operational challenges they are looking to solve.
That feedback drove the latest set of enhancements including virtual mesh capabilities to group multiple clusters of meshes together, discovery of meshes and services, API simplification and CLI tooling to streamline management of multiple service mesh clusters.
Download the presentation https://speakerdeck.com/soloio/service-mesh-hub-get-multi-cluster-istio-management-with-virtual-mesh
Questions? Join the community at https://slack.solo.io
More Info:
Read the announcement https://www.solo.io/blog/delivering-on-the-vision-of-multi-mesh/
Technical blog https://www.solo.io/blog/open-source-service-mesh-hub-technical-overview/
Documentation https://docs.solo.io/service-mesh-hub/latest
GitHub https://github.com/solo-io/service-mesh-hub
A
Thank
you
all
for
joining
I'm
super
excited
to
be
talking
about
this.
This
is
something
we've
been
thinking
about:
planning
working
with
prospects
working
with
the
community
for
probably
a
year
and
a
half
now,
and
the
most
recent
announcement
that
we
made
around
service
bathtub,
like
Betty
said,
is
open
sourcing.
A
These
efforts,
we've
rebranded
some
of
the
efforts,
and
you
know
we're
focusing
on
real
use
cases
that
people
have
when
they
adopt
a
service
mesh
and
especially
when
they
adopt
a
service
mesh
in
multiple
clusters
and
local
clusters
are
multiple
deployment
targets
right,
so
you
might
not
just
run
on
on
kubernetes,
and
so
what
we
can
look
at
today
is
what
we're
doing
at
solo.
Why
we
care
about
this
and
why
this
is
important
and
then
we'll
spend
most
of
the
time
on
demos.
A
So
really
excited
talking
about
service
special
table
talking
about
multi
cluster
multi
cloud,
hybrid
deployment,
application
networking
in
a
highly
decentralized
implementation
that
works
well
with
with
cloud-based
environments
for
micro
services,
style,
architectures
and
all
you
know,
knowing
that
you
can't
just
wave
a
magic
wand
and
have
a
green
field
setting
knowing
that
you're
gonna
have
to
imagine
this
within
the
constraints
of
your
existing
investments
and
an
enterprise.
So
with
that,
let's
get
let's
get
going.
I
think
Betty
you're
on
you're
on
this
line.
A
I
had
the
great
pleasure
of
working
with
with
zappos.com
back
in
2012
and
back
then
we
were
doing
the
same
thing.
We're
modernized
we're
going
to
you
know.
The
parent
company
was
bamas
on
we're
going
to
AWS
for
modernizing
our
infrastructure
to
work
on
the
cloud
and
AWS
and
so
forth,
but
the
reality
was
not.
Everything
could
go
to
those
environments.
So
there's
still,
there
was
still
the
stuff
that
we
had
to
keep
in
the
data
center
on-premises
ourselves
and
what
we've
seen
since
then
the
last
eight
years
is.
A
You
know,
through
my
work
at
at
Red
Hat
with
customers
adopting
kubernetes,
and
you
know
large
enterprises,
banks
and
insurance
and
health
and
so
forth,
retail.
The
reality
is,
people
are
deploying
some
new
stuff
to
the
new
infrastructure,
they're,
bringing
some
of
the
old
stuff
to
the
new
infrastructure,
they're,
looking
at
even
newer
compute
platforms
like
functions
of
service
and
and
so
forth,
but
the
reality
is
the
the
platform.
The
deployment
targets
are
hybrid,
the
technology
that
they
adopt
are
of.
A
They
still
have
similar
concerns,
whether
you
know
going
to
the
cloud
or
deploying
on-premises
around
keeping
applications
highly
available,
limiting
blast
radius
and
identifying
fault
planes
and
keeping
those
as
tight
as
possible
being
able
to
create
options
in
terms
of
the
vendors
that
they
use
and
so
forth,
and
using
application
architectures
that
allow
them
to
select
the
right
technology
for
the
segment
of
the
problem
that
they're
trying
to
solve.
So
basically,
it's
a
mishmash,
the
utopian
you
know,
everything's
just
gonna,
be
one
and
highly
you
know.
If
isn't
does
it
doesn't
play
out
in
reality?
A
And
so
we
want
to
keep
this
in
mind
as
we
as
we
go
down
this
path.
So
what
we've
been
looking
at
is
as
folks
adopt
micro-services
as
folks
adopt
some
of
this
new
technology
and
they
start
seeing
new
ways
of
implementing
old
problems
and
solutions
right.
We
are
building
api's,
we're
exposing
them
to
our
users,
we're
exposing
them
to
our
business
partners
where
maybe,
in
some
cases,
monetizing
those
but
more
importantly,
what
I've
seen
is
we're
exposing
them
internally
and
we're
creating
a
marketplace
internally
to
build.
A
You
know
new
applications
quicker
and
so
forth,
and
some
of
the
old
ways
of
managing
api's
in
a
highly
highly
centralized
fashion
doesn't
play
very
well
in
this
new
cloud
and
and
modern
infrastructure,
highly
decentralized,
ephemeral,
auto-scaling
compute,
all
right,
so
things
like
a
service
match,
started
to
come
up
and
and
solve
this.
This
problem
a
little
nicer
and
what
we,
but
we
thought
at
solo
from
back
in
you
know,
fall
2018
is
that
this
looks
like
something
we've
seen
before.
This
looks
like
you
know,
middleware
and,
and
and
tooling,
that
is
going
to
be.
A
There's
gonna
be
extremely
fierce
competition.
There's
going
to
be
a
lot
of
different
incarnations
and
ways
of
thinking
about
solving
these
problems.
What
we
think
is
gonna
happen
over
the
next
few
years.
Is
the
you
know,
there's
gonna
be
a
proliferation
of
these
types
of
technologies
in
spirits
mesh,
but
what
we
want
to
do
is
help
people
adopt
it.
A
A
Well,
we
we've
thought
into
a
20-18
an
open
source
may
open
source
project
to
kind
of
accompany
this
vision
was:
can
we
look
at
federating
these
mismatches
and
treating
them
as
a
single,
logical
abstraction
of
the
network
so
that,
whether
you're
running
on
on-premises
or
in
a
public
cloud
well
they're
using
one
particular
mesh
or
another?
You
know
or
just
want
multiple
instances
of
a
single
one
you
know:
can
we
can
we
manage
that
in
a
unified
way?
A
And
so
that's
what
we
started
going
down
the
path
that
led
to
an
evolution
of
the
API
which
led
to
a
partnership
and
announcement
with
Microsoft
in
May
that
led
to
innovation
around
extending
the
mesh?
So
if
you
have
this
API
I
can
do
things
like
traffic
routing,
select,
telemetry,
you
know
access
control
and
so
forth.
A
This
is
this
is
some
of
the
data
that
we
saw
from
people
signing
up
for
this
webinar.
So
these
are
people
who
are
potentially
interested
in
service
management
might
be
looking
at.
It
might
be
running
it
and
the
different
ones
that
they're
looking
at
now.
This
you
know
upon
seeing
it
ourselves.
This
reflects
very
similarly
what
we're
seeing
in
them
in
the
market
with
our
customers,
with
our
prospects
in
general,
I
would
say
this.
This
is,
this
is
fairly
fairly
accurate
and
I
know
Betty
one
to
run
another
quick
poll.
You
ID'd
that
yeah.
A
B
Plan
to
run
your
message
meant
your
mesh's
cloud,
on-premise
all
right,
I'm,
going
to
end
the
poll
we've
got
like
pretty
much
over
80
percent
of
the
folks
will
share.
These
can
y'all
see
this,
hopefully
so.
But
what
we've
got
here
is
that
you
know
most
folks
are
looking
to
run
on
cloud
in
the
cloud
or
in
both
and
just
a
few
saying
that
fully
fully
just
on
Prem.
B
So
you
know
this
goes
back
to
the
point
of
hybrid
right,
whether
you
have
even
if
you're
planning
to
run
your
service
meshes
I,
don't
you
know
mostly
in
the
cloud
you're
gonna
have
a
lot
of
other
applications
that
are
still
running
on
pram.
What
have
you
and
so
effectively
everything
is
still
high
Burren
now,
and
then
we
have
one
more
quick
poll,
quick
question
about
your
application
architecture.
B
So
as
you're
looking
at
the
environments
of
your
new
environments
for
your
micro
services
or
kubernetes
apps,
and
things
that
you,
the
environments
in
which
you
plan
to
run
service
match
when
you
look
at
the
architecture,
are
you
looking
at
doing
many
small
clusters
so
or
are
you
looking
to
manage
them
as
mega
clusters
that
are
kind
of
subdivided?
You
know.
B
Alright,
thanks
for
the
responses,
so
let
me
share
the
results
interesting.
So
a
small
percent
have
not
yet
decided,
but
then
you
know
the
many
small
clusters
is
just
edging
out
with
with
the
sample
size
here
of
respondents.
Just
you
know,
just
a
few
percentage
points
more
than
I'm
having
a
few
big
mega
clusters.
So
what's
interesting
here
is
that
you
know
we're
gonna
see
this
may
even
actually
vary
within
your
organization,
depending
on
how
big
your
organization
is
and
how
many
teams
you
have
maybe
for
some
teams
it
might
be
one.
B
You
know
a
few
large
environments,
whereas
for
other
teams
they
may
do
many
small
clusters,
so
going
back
to
the
point
of
things
will
be
hybrid
within
your
organization,
and
so
how
do
we
go
about
managing
that
moving
forward?
Thanks
for
sharing
that,
thanks
for
sharing
your
thoughts
with
us
and
I'll
hand,
it
back
to
Christian
awesome.
A
Alright,
let's
get
going
let's,
let's
start
looking
a
little
bit
closer
at
the
at
the
the
technology
itself.
So
what
we're
doing
at
solar?
What
we're
very
interested
in
is
solving
the
problem
of
getting
applications
to
connect
to
each
other
and
do
that
reliably.
Do
that
in
a
way
that
we
can
observe
them
and
do
that
any
way
we
can
control
the
traffic
and
do
that
in
a
way
that's
secure.
So
what
we
see
the
approach
people
take
is
they're
starting
to
modernize
their
applications.
They
might
be
starting
to
use
containers
or
kubernetes.
A
It
might
be
starting
to
you,
use
micro
services
and
and
starting
to
adopt
patterns
like
the
stringer
pattern
and
so
forth,
and
so
for
that,
what
we've?
What
we
said
is
you
know,
if
you're
starting
to
go
down
this
path
and
you're
starting
to
reimagine
the
way
to
solve
API
problems.
Do
that
incrementally
and
do
that
with
the
technology?
That's
foundational
to
the
way
people
are
building
these
types
of
frameworks
going
forward,
and
that
is
with
ongoing
proxy
and
getting
ready
for
things
like
web
assembly,
and
so
we
built
a
open
source.
A
Api
gateway
called
glue
on
top
of
Envoy
proxy
to
help
solve
those
types
of
problems.
Those
those
initial
steps
into
this
into
this
new
world.
Now
you
get
there
and
you've
built
micro-services
you're
running
in
a
cloud
environment
like
a
kubernetes
are
in
a
public
cloud
and
you
start
to
adopt
things
like
service
mesh.
That's
that
stuff
can
get
pretty
complicated
pretty
quickly
and
managing
that
across
multiple
clusters.
Doing
things
like
routing
across
failover,
across
unifying
identity
domains
where
necessary
is
before
thee
and
keeping
all
that
running.
A
I
think
that's
the
most
important
part
getting
it
working.
The
first
time
isn't
the
goal
you
want
this
sustainable.
So
that's
where
we
build
service
mesh,
hub
and
sofas,
which
Christ
will
talk
about
today
and
as
I.
Keep
alluding
to.
None
of
these
things
are
built
with
the
assumptions
of
your
organization
in
mind,
so
you'll
need
some
way
of
integrating
it
with
the
rest
of
your
processes
and
your
workflows.
You'll
need
a
way
to
change
the
behavior
of
the
data
plane
at
runtime
to
handle
things
like
non-standard
security.
A
You
know
requirements
and
protocols,
and
you
need
logging
to
be
just
exactly
the
certain
way
that
you
have
it
in
your
environment
or
you
know
any
number
of
these
customizations,
and
so
that's
what
we're
focusing
our
efforts
on
webassembly.
That's
why
things
like
glue
in
a
non
production
way
right
now
at
least
supports
webassembly,
we're
seeing
you
know
we
helped
contribute
to
the
developer.
Experience
to
running
was
assembly
with
Sto
and
so
forth.
A
So
the
the
entire
spectrum
of
getting
envoy
based
technology
and
frameworks
working
in
your
environment,
regardless
of
what
your
environment
is,
is
our
core
competency
at
solo?
That's
what
we're
working
on
and
doing
that
in
a
decentralized
manner
right,
so
we're
starting.
We
want
to
go
faster.
That's
the
whole
point
of
doing
something
like
micro
services
and
adopting
self-service
cloud
platforms
is
to
be
able
to
go
faster.
So
we
need
to
a
way
to
decentralize
our
api's
and
decentralize.
The
way
we
implement.
You
know
the
things
that
we're
building.
A
So
you
start
looking
at
deploying
your
services
into
a
cluster
or
multiple
clusters.
You
need
some
way
for
the
traffic
to
get
in.
You
might
want
to
manage
the
evolution
from
monoliths
to
micro
service,
and
so
that's
a
glue.
Fitz
glue
fits
in
at
the
edge
of
your
application.
Boundaries
solves
things
like
security
things
like
oh,
I
DC
web
application
following
data
loss,
prevention,
TLS
termination
and,
and
and
and
so
for
those
those
types
of
security,
concerns
rate,
limiting
message,
transformation,
automatic
service
discovery
and
and
so
forth.
A
A
But,
like
I
said
this
is
in
this
hybrid
world
you
probably
likely
be
running
on
maybe
kubernetes,
maybe
VMware,
maybe
AWS
in
the
public
cloud
or
some
of
the
other
public
clouds,
and
you
need
a
decentralized
way
of
solving
these
edge
ingress
type
problems,
and
so
that's
where
glue
can
also
fit
right.
So
we
can.
We
have.
We
have
coverage
from
envoy
capability
at
the
edge,
regardless
of
the
platform
into
which
you
deploy
where
your
applications
live.
A
Now,
when
the
service
is
started
to
need
to
talk
with
each
other,
and
we
need
to
solve
for
this
east-west
traffic
direction,
that's
where
a
service
match
would
come
in
and
help
it.
This
gives
visibility
to
the
network
at
the
application
layer,
things
that
we've
always
wanted
in
the
past
that
we
might
have
put
es
B's
and
message
queues
and
so
forth
in
there
and
thinking
that
we
just
have
this
nice
centralized
hub
for
everything
flows
and
we
can
see
it
and
control
it
and
so
forth.
This
model
is
a
little
bit
different.
A
The
implementation
is
highly
decentralized.
Envoy
is
running
next
to
each
of
these
workloads,
whether
that's
in
containers
or
in
VMs
or
anywhere
physical
and
all
the
traffic
is
flowing
through
these
Envoy
proxies
that
have
been
deployed
next
to
our
applications
and
they
provide
things
like
timeouts
and
retries,
and
circuit
braking
and
telemetry
gathering
and
security
for
end-to-end,
mutual
TLS
and
so
forth,
because
the
transport
goes
through
these
proxies
and
then
the
service
mesh
gives
you
a
control
point
in
in
in
terms
of
the
data
plane,
as
well
as
the
control
plane.
A
So
the
service
mesh
gives
you
a
single
place
where
you
can
go
configure
the
mesh
and
the
problem
that
you
run
into
is
now.
How
do
you
start
to
do
that
and
federating
across
multiple
of
these
deployment
targets,
multiple
of
these
sort
of
special
control
planes,
and
that's
exactly
the
problem
that
service
mesh
hub
was
built
to
solve.
A
Now
we're
also
aware
that
you
know,
for
example,
maybe
it's
geo
today
might
be
you
know
more
highly
adopted
and
and
so
forth,
at
least
based
on
the
polls
that
we've
seen
the
anecdotal
data
we
have,
but
we
realized
that
when
people
go
to
a
public
cloud
like
AWS,
for
example,
AWS
has
a
service
mesh
and
it's
actually
getting
its
first
of
all.
It's
getting
really
it's
getting
good.
It
works
across
multiple
deployment
targets,
so
ECS,
ec2,
eks
and
and
I
think,
Fargate
and
so
forth.
A
A
Going
to
see
this
adoption
pattern
and
if
any
architect
is
you
know,
been
around
for
a
little
bit
and
seeing
the
evolution
of
the
enterprises,
you
know
that
you
don't
have
one
of
of
anything
right.
You
have
multiples
of
everything
and
it's
unfortunate.
It's
not
ideal,
but
sometimes
it's
miscommunication
in
within
an
organization.
Sometimes
it's
through
merger
and
acquisition.
But
you
end
up
with
multiple
incarnations
of
a
particular
technology
solution
and,
like
I,
said
a
shoe
shouldn't
be
something
that
you
strive
for,
but
in
the
event
that
does
happen,
we're
that's
all
we're
building
service.
A
With
that
in
mind,
with
the
reality,
sometimes
ugly
reality
of
the
enterprise.
You
know
the
collection
of
software
and
and
solutions
that
they
end
up
having
so
service
mesh
hub
is
a
multi
mesh
management
plane
for
multiple
clusters
or
multiple
deployments
of
a
service
mesh,
and
the
goal
of
it
is
to
unify
those
different
deployment
instances
so
that
you
as
operator
as
as
a
sre,
can
think
about
the
platform
as
a
whole
and
not
each
individual
meshes
api
differences
and
conflicts,
and
you
know
whether
one
mesh
can
talk
to
the
other.
A
Whether
the
identity
is
unified,
keeping
things
like
service
discovery,
up-to-date
and
and
so
forth,
and
doing
this
across
any
deployment
target
or
any
mesh,
and
so
that's
what
we're
targeting
and
that's
what
we're
building
with
with
service
mesh
hub.
So
that's
enough
talking.
Let's
actually
look
at
service
mesh
home
I
think
the
first
place.
A
If
you
go
to
Doc's
solar,
dot,
IO
and
slash
surface
mesh
hub,
you
can
you'll
get
to
the
docks
and
I
think
this
is
a
great
start.
The
getting
started
is
well-named
and
and-
and
so
this
this
will
get
you
on
your
way.
If
you
wants
you
look
at
github,
we
can
see
the
open
source
project
here,
it's
very
active.
A
We
do
frequent
releases,
we
just
updated
some
documentation
for
contributors
to
you,
know,
contribute
to
the
project
and
and
so
forth,
join
slack
if
you
have
questions
and
issues,
but
so
basically
what
what
service
mesh
table
looks
like
is.
Is
this
so
the
first
thing
that
we're
gonna
do
is
we
have
multiple
clusters
here?
Let
me
actually
come
over
here,
make
it
a
little
bit
clearer.
Alright,
we
have.
A
A
Each
other
and
we're
running
independent,
ISTE
O's
at
the
moment.
What
we're
going
to
do
in
the
demo
is
we're
going
to
install
service
web
on
one
of
the
clusters
and
register
those
sto
control
planes
with
service
mesh
hub
now.
This
is
purely
just
to
save
in
the
number
of
clusters
that
I
have
up
and
running,
but
we
could-
and
you
would
ideally
do
it
like
this-
where
you
have
a
separate
cluster
for
your
management
plane
and
you
would
be
managing
the
remote
clusters.
A
A
We
are
expecting
the
same
setup
from
the
remote
cluster,
our
second
cluster,
and
just
to
get
an
idea
of
how
we
installed
this
deal
here
maybe
come
to
the
docks
and
their
guides
and
installing
sto
multi
cluster
with
Services
Hub.
Actually
we
could
we
very
quickly
install
a
multi
cluster
ready
service
mesh,
all
right
sto,
which
which
controls,
which
which
components
ultimately
under
the
covers
it
does
set
up
at
the
operator
and
so
forth,
but
just
for
a
mesh
CTL
tool
from
service
mesh
tab.
We
can.
A
We
can
very
quickly
spin
up
a
steel
like
I
did
here.
So
in
the
first
cluster
we
can
see.
We
have
some
components
of
the
book
info
app,
so
there's
the
sample
from
ischium
running
version,
1
and
version
2
of
reviews
on
the
second
cluster.
We
have
some
of
the
components
from
the
book
info
app
running.
We
have
version
3
of
reviews,
and
so
the
first
thing
we're
gonna
do
is
install
service
much
hub
into
the
management
plain
context.
We
come
back
here
that
will
be
so
that
the
architecture
looks
like
looks
like
this.
A
What
we
have
service
better
hub
running
on
the
management
plane
looks
like
that's
been
installed.
We
could
very
quickly
take
a
look
at
what
components
make
up
service
mesh
and
right
here
we
can
see
that
we
have
the
discovery
and
the
networking
components
and
I
might
jump
back
and
forth
here.
If
you
click
on
operations
and
the
troubleshooting
guide,
we
do
give
information,
what
those
components
do,
debug
them
and
and
and
so.
A
So
we
have
the
components
running.
This
makes
up
the
management
plane.
What
we're
gonna
do
is
check
to
make
sure
that
everything
was
installed
and
everything
looks
correct,
and
that
does
look
good.
Okay.
Now,
let's
registers,
we
have
the
management
plane
installed.
Let's
register
our
clusters
with
the
management
plane,
and
so
what
this
is
going
to
do
is
tell
the
management
plane
service,
much
fun
about
cluster
one
cluster
two
and
then
what
service
mesh
top
is
going
to
do
is
go
discover
what
is
running
on
those
clusters
which
service
mesh
is
running.
A
There
is
one
as
a
sto
is
it'll,
be
established.
What
is
this?
What
workloads
are
running?
What
services
are
defined
for
those
meshes,
so
we'll
go,
get
basically
kind
of
build
a
a
map
of
the
or
the
lay
of
the
land
of
the
different
deployment
targets,
in
this
case
clusters
that
we
have
we
have
access
to,
and
we
should
see
that
the
clusters
were
correctly
registered
and
we
should
see
that
the
different
meshes
were
also
discovered.
So
we
have
is
still
running
on
cluster
1
and
cluster
2
here.
So
that's
that's
great.
A
Now
what
we
want
to
do
we
have
these
two
separate
in
these
two
separate
meshes
right
in
these
two
separate
meshes
service
finish
hub
is
running
on
one
of
the
clusters.
What
we
want
is
to
enable
some
service
discovery.
We
want
to
enable
a
root,
shared
trust
between
the
two
meshes
without
doing
unsafe
things
like
exchanging
private
keys
and
so
forth
over
the
network.
A
So
what
we,
what
we
want
to
do
is
establish
a
unifying
construct
across
these
two
meshes
in
this
case
two
clusters,
so
that
we
can
start
to
treat
the
met,
those
two
men
as
a
single
virtual
mesh,
the
single
logical
mesh
and
so
to
do
that,
let's
take
a
look
at
what
what
what
the
certificates,
what
the
identity
of
the
meshes
are
and
then
let's
unify
them
and
unify
their
their
their
capabilities
as
well.
So
what
we
did
here
in
this
command
is
in
the
first
mesh.
A
A
A
What
we're
going
to
do
is
we're
going
to
use
the
service
mesh
of
virtual
mesh
CRD
to
establish
a
shared
trust
domain
and
shared
group
CA
in
this
case,
we're
going
to
we're
gonna
automatically
build
a
create
the
route,
but
we
could
use
a
provided
one
and
that
provided
one
could
come
from
vault
or
some
secret
store
and
so
forth.
We're
going
to
we're
gonna
Feder,
a
10
with
the
service
discovery
capability
of
permissive.
A
This
is
just
means
that
we're
going
to
let
all
of
the
services
from
one
cluster
know
about
the
services
running
in
another
cluster.
So
these
things
can
be
configured
we're
gonna
start
with
access
control,
false,
so
we're
just
going
to
enable
all
the
traffic
and
then
we
basically
we're
just
going
to
group
these
two
meshes
that
we've
we've
discovered.
A
So,
let's
just
let's
do
that.
Let's
apply
it
to
the
management
plane
and
what
this
is
going
to
do
under
the
covers
is
start
to
orchestrate
unifying
their
trust,
domains,
orchestrate
their
service
discovery
and
give
you
the
opportunity
to
treat
these
different
clusters
as
a
single
unified
mesh.
Hopefully,.
A
A
The
next
thing
we're
gonna
do
is
actually
look
at
the
CR
itself
and
we
should
see
that
so,
first
of
all,
all
of
the
all
of
the
CRS
and
service
men
should
have
a
status
field,
so
you
can
very
quickly
using
your
own
automation.
Your
own
tooling
determine
the
state
of
these
resources,
and
we
can
see
that
the
certificate
unification
has
happened.
The
access
control
is
set
to
false,
it
has
happened,
and
so
is
the
service
discovery
for
Federation.
That
all
looks
looks
good.
So
now,
let's
take
a
look
at
what
we
did.
A
The
first
thing
we
did
was
we
created
a
root
private
key,
insert
pair
right
in
the
management
planes
from
virtual
match.
Ca
certs,
we
came
back.
Let's
come
back
to
our
diagram,
real
quick.
What
we
did
was
we
built
this
part
you
can
see
in
the
diagram.
Without
this
part
s,
certificate
ends
with
Q
s
and
an
equal
sign
we'll
try
to
remember
that
Q
s
and
an
equal
sign.
A
If
we
look
at
the
remote
cluster,
the
remote
cluster
has
something
called
a
virtual
mesh
certificate
signing
request
and
so
what
it,
what
it
did
in
there
in
the
virtual
cluster.
Is
it
spun
up
a
little
CSR
agent
that
CSR
agent
created
a
private
key
insert
pair
local
to
that
machine?
Nothing
was
transferred
over
the
network
and
then
the
CSR
agent
said:
hey
service
mesh
hug
I
have
a
certificate
signing
request.
A
I
want
you
to
sign
this
with
your
route
so
that
we
can
use
this
new
certificate
as
intermediate
CA
for
Sto
and
therefore
sto
can
that
any
of
these
entities
on
both
sides.
Both
clusters
can
use
this
intermediate
to
build
the
work
load
certificates
that
all
derived
from
the
same
root.
So
we
have
a
shared
root
CA.
A
A
Now,
let's
take
a
look
at
what
we've
done
on
the
remote
cluster
or
for
for
both
of
the
sto
service
mesh
control
plates
we've
created
that
intermediate
on
the
management
plane,
we've
done
the
same
thing
for
the
remote
clusters.
That
is
this
part.
We've
created
this
intermediate
is
signed
by
the
shared
route.
A
C
A
And
then
one
thing
notice
is
that
for
the
demo,
I
also
restarted
the
book
info
pods
just
so
that
they
would
pick
up
their
new
workload
certificate
faster
just
for
the
demo.
So
we're
not
sitting
here
for,
however
long
it
takes
for
that
to
happen,
and
then
now
what
we
should
expect
is
both
control
claims
now
we're
using
a
CA
to
come
at
the
shortest
same
route,
so
that
if
we
run
that
same
command
that
we
did
earlier
reviews
calling
ratings
and
exploring
their
certificates.
A
Their
root
CA,
the
root
certificate
is
Q
s,
equals
I,
believe
that's
what
it
what
we've
memorized,
but
if
we
look
at
the
second
cluster
and
make
that
same
call,
Q
s
equals
is
what
we're
looking
for.
We
should
see
the
same
root
and
the
same
ending
Q
s
equals.
So
we
can
see
now
that
the
roots
have
been
unified.
A
A
What
we're
going
to
do
is
we're
going
to
enable
our
access
policy
or
turn
access
policy
on
for
the
mesh.
So
we're
going
to
take
the
same
virtual
mesh
I'm
going
to
change
that
one
flag
to
true
and
it
was
false
which
a
need
to
choose,
let's
apply
it
now
and
what
that
is
going
to
do
is
enable
access
control
policy
which,
by
default
out
of
the
box,
has
a
deny
all
policy.
A
So
we
should
end
up
seeing
and
it
does
take
a
little
bit
for
it
for
this
to
trickle,
and
this
do
control
place.
What
we
should
see
is
some
point.
Things
started
to
come
unavailable
because
a
call
cannot
complete.
We
start
getting
errors
here,
because
the
product
page
can't
call
its
its
collaborators
and
those
services
can't
call
their
collaborators.
We
refresh
a
couple
times
we
see
now
everything
is
come
to
a
grinding
halt,
there's
no
traffic
flowing
because
there's
no
access
policies
right.
A
So,
let's
take
a
look
at
a
access
control
policy
from
servers
20-odd
that
gives
you
the
the
as
much
fine
grain
or
coarse
grained
control
over
this
policy
for
the
virtual
mesh.
Treating
this
as
these
two
pluses
is
one
single
mesh,
and
so
what
we're
going
to
say
here
is
for
product
page
and
cluster,
one
trying
to
talk
to
a
service
that
lives
in
a
namespace
of
default
on
any
of
the
clusters.
Allow
that
to
happen,
allow
product
page
to
talk
to
reviews
and
details
and
so
forth.
A
And
so
that
has
been
applied
now,
if
we
refresh
like
I,
said
it
takes
a
second
to
we
see
that
the
book
details
has
come
back,
we
see
book
reviews
has
come
back,
so
we
enable
the
traffic
from
product
so
that
it's
direct
collaborators
but
from
reviews
calling
ratings
that
is
not
enabled.
So,
let's
enable
that
that's
been
able
calling
him
from
on
the
review
service
to
call
into
into
ratings.
So.
A
A
Next,
let's,
though,
the
last
thing
that
we'll
look
at
is
that
a
same
idea
having
a
unified
configuration
API
for
controlling
access
policy,
let's
do
the
same
thing
with
traffic
control
and
traffic
routing.
So
right
now,
the
first
thing
that
we'll
look
at
is
the
Federation
model.
We
set
the
permissive
just
made
the
services
available
on
on
each
of
the
different
clusters,
so
on
cluster
one
I
can
see
I
have
access
to
the
services
running
on
cluster
two.
If
I
do
the
other
way
on
cluster,
two
I
should
see
the
ones
running
on
cluster
one.
A
So
these
are
the
service
entries
that
is
CEO
uses
to
be
able
to
route
traffic
outside
of
the
mesh.
If
we
take
a
look
at
one
of
these
service
entries
from
from
cluster
one,
let's
say
we
can
see
that
we've
defined
a
host
of
workload,
names
based
on
whatever
the
cluster
is
and
we're
pointing
it
to
an
external
address
somewhere.
Now
that
external
address
in
the
ischial
model
is
the
ISTE
of
ingress
gateway
for
cluster
two.
A
Let's
look
at
the
traffic
routing
API
so
again,
this
is
just
like
the
access
policy
API,
but
is
it
is
virtual
mesh
aware
and
what
we're
gonna
say
is,
in
this
case
traffic
or
control
the
traffic,
so
that
100%
of
it
goes
to
reviews
v1
on
cluster.
One
can
apply
that
at
this
point,
we're
still
just
dealing
with
it
happens
to
be
the
workloads
on
a
single
cluster.
A
A
C
A
Do
that
and
we
refresh,
we
should
see
most
of
the
time.
We
should
see
the
red
stars
because
that's
B
3
reviews
and
we
do
so
from
this
traffic
policy.
We
can
control
the
the
routing
of
the
traffic
in
our
system
without
having
to
know
exactly.
You
know,
go
to
each
one
of
the
clusters
and
manually
configure
them
right.
So
we
have
a
policy.
That's
aware
of
this
virtual
mesh
now
one
one
thing
that
can
happen
so
yeah.
Well,
okay,
though
it'll
take
a
look.
Quick
look
under
here.
A
Follow
the
skirt
what's
happening
under
the
covers.
Is
the
surface
mesh
table
is
orchestrating
SEO
and
SEO
is
creating
it's
known.
Api
under
the
covers
all
right,
so
we
can
take
a
look
at
the
virtual
service
and
it
knows
how
you
know
it
knows
the
sto
API
here
now.
One
thing
that
can
happen
when
you're
building
these
policies
across
different
clusters
is
for
a
particular
service.
You,
you
might
not
exactly
just
by
looking
at
the
configs.
What
are
the
rules
that
apply
to
that
service?
A
A
In
this
case
we
can
see
if
we
ask
about
the
review
service,
we
have
a
traffic
shift
policy
in
place,
but
you
could
also
have
various
header
matching
policies
or
fault
injections
or
retries
and
so
forth,
and
and
as
soon
as
you
start
to
come
up
with,
let's
say
a
hierarchy
of
rules,
something
that
you
might
say
is
is
default
for
all
of
the
services.
Maybe
I,
don't
retry
of
two
or
three
or
whatever.
A
A
We'll
leave
you
with
links
to
service
messed
up
in
the
community,
definitely
go
to
slack
if
you're
interested
in
this
and
interested
in
contributing
interested
in
kicking
the
tires
or
trying.
This
out,
please
go
to
to
get
hub.
Please
go
to
the
slack
signup
reach
out
to
me,
reach
out
to
anyone
in
the
slack
Graham
and
Harvey
and
H
on
you,
ballin
O's
folks,
the
engineers
on
soullow
we're
more
than
happy
to
help.
C
C
B
A
B
C
A
Yes,
so
with
glue,
we
can
the
backends
that
we're
out
to
first
of
all
out
of
the
box
glue
will
do
its
best
to
discover
the
services
that
it
can
wrap
to.
So,
for
example,
if
it's
running
in
kubernetes
it
will
query
the
kubernetes
api
if
you've
configured
it
with
console,
maybe
a
Bearnaise
bank
console.
We
can
discover
things
running
in
console.
A
You
can
also
point
it
to
AWS
and
it
can
automatically
discover
workloads
that
are
running
on
ec2
or
in
Landis,
and
the
the
foundational
piece
to
the
to
the
glue
control
plane
and
even
serve
as
much
hub
is
that
everything
is
built
on
plugins.
So
if
there's
a
registry-
or
you
want
to
do
some
automatic
registration
using
a
registry
that
we
don't
have
support
for
at
the
moment,
some
may
be
something
like
a
zookeeper
or
whatever.
That
can
easily
be
added
and
extended
into
into
the
control
plane.
C
A
That's
a
great
question,
so
the
identity
model
at
the
moment
that
is
being
used
to
federate
the
identity
between
the
meshes
as
we
saw
in
this
diagram,
is
based
on
the
underlying
meshes
implementation
of
identity.
So
in
this
case
it
is
sto
and
sou
this
15.
Now,
what
becomes
you
know
more
interesting
is
when
we
get
into
situations
like
like
this,
where
we
have,
maybe
it's
do
an
app
mesh
running
or
STL
and
maker,
D
or
constable
right.
B
A
Can
maybe
scroll
back
up
so
the
the
call
on
cluster
to
from
reviews
to
ratings
had
a
root
certificate
of
QA.
It
terminated
with
a
certificate
of
Q
s.
Equal
sign
the
certificate
on
cluster
1
when
we
called
reviews
and
ratings
also
had
a
root
terminate
with
Q
s,
equal
sign
so
they're,
both
part
of
the
same
root,
trust
domain
and
how
this
deal
was
configured
to
use
MPLS,
as
we
can
see
when
we
make
these
calls.
So
that's
not
like
when
I
called
ship
asked
to
show
the
sirs.
A
A
That's
a
great
question
in
this
particular
model
of
multi
cluster.
We
went
with
a
an
assumption
that
there
was
no
flat
network.
These
were
different
networks,
but
the
gateways
that
we
could
reach
the
gateways.
So
there
was
connectivity
to
the
gateways.
There
are
other
models
that
you
know
you
can
do
multi
cluster.
Maybe
this
would
be
a
good
webinars
just
to
do
multi
cluster
patterns
and
trade
offs,
but
where
we
can
go
in
a
little
bit
more
detail
about
the
different
architectures
and
the
pros
and
cons.
A
But
you
could
have
a
scenario
where,
in
your
network
you
do
have
a
flat
network
and
you
do
have
multiple
clusters
and
workloads
running
within
that
single
network
and
you
might
want
we're
close
to
be
able
to
directly
connect
to
each
other.
And
you
know
that's
that's
a
valid
approach
as
well
and
you
might
want
the
control
planes
in
that
case,
and
so
to
be
completely
separate.
Maybe
to
be.
A
You
know
deployed
enough
highly
available
scenario
where
you
have
only
one
active
and
so
there's
a
bunch
of
different
models
here,
but
in
the
demo
that
I
showed
there
was
no
assumption
for
flat
networking.
But
that's
not
the
only
approach
to
doing
multiple,
multiple
cluster
and
Federation
of
SEO
clusters.
Then.
B
Actually,
there's
a
quick
question
here:
I
think
you
bring
up
a
good
point.
We're
gonna
have
a
whole
another
session
just
on
the
multi
cluster
patterns,
but
question
here
has
other
than
traffic
routing.
Can
you
touch
on
what
are
some
of
the
other
use
cases
for
like
a
federated
mesh
or
economies?
Multi
cluster
patterns,
yeah.
A
Federate
them
is
to
simplify
the
operations
of
them
is
to
enable
things
like
failover,
enable
things
like
global
discovery.
Service
discovery
enable
things
like
Global
Mutual
TLS
like
we
saw
to
enable
like
a
unified,
single
pane
of
observability.
So
you
can,
you
know,
see,
what's
happening
across
the
different
clusters,
so
the
the
answer.
It
really
is
just
how
do
you?
How
do
you
do
that?
And
how
do
you
simplify
that
and
make
that
operational?
And
you
have
that
ready
for
day
two
type
operations,
because,
like
I
said
the
individual
meshes
look
at
this?
A
Do
you
can
go
follow
the
steps
for
for
doing
this
stuff,
but
then
making
it
operational,
making
it
repeatable,
making
it
part
of
your
CI
CD
platform
and
doing
it
in
a
way
that
kind
of
lowers
the
mental
acuity
that
you
have
to
have
to
understand
what
the
heck
is
going
on.
I
think:
that's!
That's
the
that's!
What
we're
doing
with
service
mashup!
Those
are
the
advantages
deploying
across
multiple
clusters
and.
A
What
do
you
think
the
the
hub
itself
would
need
to
be
so
at
the
moment
it
doesn't
we
don't
we
don't
the
hub
itself.
The
management
plate
is
NaN
is
not
highly
highly
available.
Now
you
could,
you
could
do
it,
you
could
do
it
pretty
easily,
but
it's
not
something
that
we've
we've
tried
to
simplify
or
make
it
possible
yet.
But
the
interesting
thing
about
that
is
and
I
get
the
pros
and
cons
about
it.
A
But
the
interesting
thing
is
it's:
a
management
plane
where
to
go
down
each
individual
service
mash
still
at
least
in
the
model
that
we
looked
at
today,
has
its
own
control
claim.
Alright,
so
those
are,
those
are
still
up
and
running.
You've
limited
the
blast
radius
of
a
failure
here
into
you,
know
each
of
the
different
zones
management
plane
zone
and
each
mesh
control
plane
zone
right.
So
everything
would
still
continue
to
run.
A
You
could
still
operate
it,
you
might,
you
might
have
to
go
to
each
one
of
the
meshes,
but
ideally
the
mesh
management
plane
would
be
deployed
in
a
highly
available
scenario.
Now
why
I
said
you
could
probably
do
it
today?
Is
you
know
the
the
way
you
might
run
kubernetes
today,
I
know
some
people
might
run
kubernetes
in
a
scenario
where
you
have
a
hot
cold
scenario
where
you
have
one
cluster
running,
and
then
you
have
a
one
standby
and
so
forth.
A
The
model
I
think
that
would
be
appropriate
that
we're
going
to
we're
going
to
probably
end
up
with
is
you
could
run
two
active
active,
but
only
one
is
the
leader
and
the
other
one's
the
follower.
So
there's
the
we're
still
ironing
out
exactly
how
we
want
to
solve
that.
But
I
would
say
right
now
from
because
it's
the
management
plane
driving
these
are
the
control
planes.
B
Cool,
so
that's
where
we
are
at
time
there's
a
few
other
questions
in
here,
but
what
we
can
do
is
we
can
answer
them
offline,
get
back
to
folks
and
we'll
post
that
with
the
recording
and
the
slides
as
well
and
also
recaps
with
these
questions
in
there
and
we
look
to
see
yeah
look
to
have
everybody
in
the
slack
Channel
Christian.
If
you
want
to
go
back
to
that
last
slide,
but.