►
From YouTube: Istio Service Mesh Simplified Beyond a Single Cluster - Lin Sun, IBM & Sven Mawson, Google
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Istio Service Mesh Simplified Beyond a Single Cluster - Lin Sun, IBM & Sven Mawson, Google
We have made numerous improvements to the Istio project over the past year to simplify the experience for users and operators in a single cluster. This year we have been focusing on improving the experience beyond a single cluster, simplifying multicluster deployment by merging the replicated control plane and shared control plane patterns. Within this unified multicluster pattern, users can choose a control plane and network topology based on their business needs and requirements. We have also been simplifying Istio's usage beyond containers, making it easier for users to securely onboard VMs into the service mesh. In this talk, we will be demoing the new and improved experience for using Istio with multiple clusters and expanding the mesh to VMs.
A
B
A
A
So
first,
the
mixer
goes
away.
Well,
the
mixer
functionality
folded
into
the
cycle
proxy.
We
have
the
injection
system
again,
the
config
config
system
goes
away
and
that
function
folded
into
pilot.
We
have
the
cyca
injector
is
also
folded
into
pilot
and
the
last.
We
also
have
the
node
agent
folded
into
our
pilot
agent,
so
that
you
don't
need
a
set
of
parts
security
policies.
A
We
also
have
a
citadel
function.
Folded
into
pilot,
so
pilot
is
becoming
hcld
where
the
d
stands
for
daemon
and
it
really
helps
our
operators
who
runs
istio
control
plane
because
they
only
have
to
worry
about
one
single
components.
So
great
simplification
work
done
by
the
community
for
the
single
cluster.
A
Some
of
you
might
have
already
set
up
a
multi-cluster
with
istio
mesh,
and
I,
if
you
do,
I
guarantee
you
you're,
probably
very
confused
on.
Why
are
we
having
two
models?
We
have.
This
model
called
replicate
control
plane,
which
is
what's
on
the
left
side.
A
lot
of
users
are
actually
very
interested
in
their
model
because
they
have.
A
This
model
provides
high
availability
on
the
control
plane,
so
you
could
have
a
istio
control
plane
running
in
cluster
one
and
cluster
two,
and
you
could
selectively
expose
what
other
services
services
you
want
to
expose
to
the
other
cluster
instead
of
everything
together,
we
also
have
another
interesting
model
on
the
right
side.
Called
shell
control
plane
model,
which
means
two
of
the
cluster,
are
actually
using
one
istio
control
plane,
and
in
this
case
all
the
services
are
shared
among
the
clusters.
So
there's
a
lot
of
confusing
to
your
user.
A
A
So
a
lot
of
confusing
in
this,
the
good
news
is,
we
are
taking
a
lot
of
effort
in
the
community
to
unify
the
istio
multi-cluster
model.
So
with
this
new
model,
if
you
have
two
cluster
like
what's
the
diagram
shows,
you
would
be
thinking
about
based
on
your
requirement,
whether
you
are
going
to
need
to
run
sdod
on
just
one
cluster
or
whether
you
run
sdod
also
for
high
availability
of
your
control
plane
on
the
second
cluster.
So
it's
up
to
you
as
a
choice.
A
You
can
also
choose
to
run
whether
you're
on
ingress
gateway,
both
cluster
or
just
running
it
on
your
primary
cluster.
So
that's
also
a
choice
to
you,
based
on
your
control,
plane
model
and
also
based
on
your
network
model
topologies
and
then,
finally,
you
can
also
choose
for
the
services
on
your
data
plane.
You
can
choose
what
services
are
you
exposing
to
the
other
clusters
and
you
can
also
based
on
your
needs
to
create
the
mirror
for
the
services
as
needed?
B
This
so
lynn
talked
about
some
of
these
choices
already,
but
basically
we're
trying
to
have
a
unified
model
here,
where
you,
as
the
user
you
know,
are,
are
in
charge
of
of
what
control
planes
you
run
so
for
each
cluster.
Do
you
want
to
run
a
control
plane
in
it
for
availability
and
redundancy,
or
do
you
want
to
use?
B
B
We
also
talk
in
our
multi-cluster
model.
A
lot
about
tenancy
models
and
istio
really
supports
two
different
models.
Here.
One
is
kind
of
a
namespace
tenancy
model
where
you
don't
worry
as
much
about
clusters,
and
it's
really
just
the
namespace
name-
determines
sort
of
the
team
name
and
that's
kind
of
the
the
built-in
model
where
names
are
treated
the
same
if
they're
in
the
same
name
space,
but
you
can
also
use
clusters
as
your
tenancy
model,
where
maybe
one
team
owns
a
particular
cluster.
B
So
just
a
little
bit
more
detail
on
kind
of
the
the
first
two
things:
the
control
planes
and
the
networks
so
control
planes.
It's
really
your
choice.
Right.
Where
do
you
want
to
install
a
control
plane?
You
can
install,
you
know
a
control
plane
in
each
cluster
and
those
are
sort
of
known
as
primary
clusters.
B
B
B
There's
another
model
that
actually
recently
has
been
coming
out
of
the
studio
community,
which
is
this
notion
of
external
control
planes,
and
so,
when
you
have
that
remote
cluster,
it's
remote
to
some
control
plane
that
control
plane
doesn't
actually
need
to
run
in
one
of
your
clusters.
It
can
run
outside.
It
can
be
a
vendor
provided
control
plane.
It
can
be
one
that
a
platform
team
is
running
for
teams
within
your
organization.
B
The
network
side,
as
I
mentioned,
istio,
supports
kind
of
whatever
network
setup
you
have
and
the
way
we
do.
This
is
when
you're
within
the
same
network,
where
pods
can
just
talk
to
each
other
they'll
just
talk
to
each
other
and
they'll
call
directly
and
again,
you
can
run.
You
know
multiple
control
planes.
You
can
run
a
primary
remote.
B
However,
you
want
to
set
it
up,
but
we
also
support
multiple
networks
where
you
want
to
run
istio
on
a
different
network
in
a
cluster
on
a
different
network,
but
you
want
those
all
to
be
one
mesh
and
the
way
we
do
this
is
we
use
gateways.
So
you
have
gateways
that
can
talk
to
each
other
and
we
tunnel
the
traffic
through
those
gateways
so
to
the
applications.
B
A
A
Here
on
the
second
cluster,
you
want
to
make
sure
you
have
the
right
cluster
name
and
network
it's
the
same
and
the
main
thing
is
the
cluster
name
and
then
the
second
thing
is
create
the
remote
secret
so
that
it
can
do
endpoint
discovery
for
the
remote
cluster
and
the
way
you
do
it
is
using
create
remote
secret
command.
So
that
was
it
at
the
the
same
network
was
really
simple.
A
If
you
do
have
a
multiple
network
and
you
do
want
a
multiple
primary
for
high
availability
of
your
control
plane
in
this
case.
Similarly,
as
the
previous
you
do
is
still
install
istio,
when
you
do
remote
service
create
remote
secret,
you
want
to
do
it
on
both
of
the
clusters,
so
make
sure
the
endpoints
can
watch
the
other
clusters
api
server,
and
then
you
want
to
make
sure
you
are
setting
up
the
east
and
west
gateway
to
help
you
bridge
on
the
network.
A
So
that
the
traffic
can
download
through
the
gateway
and
reach
the
other
cluster,
the
last
step
is
you
want
to
also
expose
your
user
services
to
make
sure
you
know
service
a
can
be,
can
reach
out
to
talk
to
service
b,
so
we
we
provide
samples
to
allow
you
to
by
default.
I
think
it
exposes
all
the
services
out
on
the
gateway,
but
you
could
potentially
tune
that
to
based
on
your
business
needs.
A
A
The
last,
but
not
the
least
model
we
have
is
primary
remote,
mlt
networks.
In
this
case,
you
install
sdod
only
on
the
primary
cluster
same
as
the
previous
one,
and
same
as
previous
one.
You
create
this.
The
cluster
2
secret
on
cluster
1
for
endpoint
discoveries,
and
then
you
set
up
the
istio
and
west
gateway
same
as
the
the
previous
one.
A
The
fourth
one
step,
four
it
exposed
is
your
d
on
the
gateway
it's
also
same,
but
you
do
have
to
do
one
additional
step
on
step,
five
to
expose
your
user
services.
This
is
because
your
user
service,
a
and
service
bui,
is
not
going
to
be
able
to
talk
to
each
other
directly
because
you
have
multiple
networks,
so
it
has
to
go
through
the
gateway.
So
you
want
to
make
sure
your
services
are
exposed
on
the
gateway
for
the
other
for
services
from
the
other
cluster
to
consume.
A
So
what's
really
nice
about
these
models,
as
you
can
see,
is
they
are
like
building
blocks
right?
You
can
based
on
your
requirements
and
your
needs,
and
you
choose
the
building
blocks,
that's
needed
to
to
fix
your
requirements.
So
with
that
we
are
going
to
be
very
excited
to
talk
to
you
guys
about
our
demo.
Gosh
I've
never
set
up
something
across
different
clouds,
so
we
actually
have
four
clusters
on
the
left
side.
We
have
two
clusters,
cluster
y
with
and
cluster
2i,
on
ibm
cloud
in
this
setup.
A
On
the
left
side,
I
believe
they
are
primary,
multiple,
multiple
primary
and
they
are
also
multiple
networks,
because
we
don't
have
flat
networks
on
our
cloud.
So
this
is
one
of
the
model
we
talked
about
on
the
right
side.
Savann
has
set
up
two
clusters
on
google
cloud
and
in
this
case
I
noticed
we
only
have
sdod
running
on
cluster
one
and
there's
no
seod
on
cluster
two.
So
this
is
a
primary
remote
and
I
believe
this
is
the
same
network
in
his
environment.
A
So
you
can
see
where
experimental,
different
topologies
across
different
clouds
and
we're
setting
up
the
same
the
single
mesh
among
these
four
clusters.
From
our
application
point
of
view,
the
purpose
is
to
show
you
guys
the
multi-cluster
topology,
so
we
decided
to
use
really
simple
book
info
examples.
A
As
you
can
see,
we
have
product
page
and
review
version,
one
running
on
cluster
one
I
and
then
we
have
review
version
2
running
on
2i
and
review
version.
3
have
high
availability
running
on
google
cloud
with
cluster
1
and
2..
With
that,
I'm
going
to
go
ahead,
share
my
screen
and
and
show
you
guys
the.
A
A
A
Issue
on
this
cluster
now-
and
this
is
my
configuration
yamo-
you
can
see
I'm
installing
a
primary
cluster
in
this
environment,
with
my
network
and
my
cluster
name
and
on
to
the
next
cluster
to
ui
seminar
plan,
except
I'm
having
a
different
cluster
name
and
a
different
network
name.
So
let's
go
ahead
and
install
that
as
well.
A
A
A
A
A
So
now
we
got
remote
secret
generated
for
both
of
our
both
of
my
two
cluster.
Now
we're
applying
on
the
second
cluster,
we're
applying
the
first
cluster
secret,
which
enables
the
second
clusters
to
look
up
to
query
the
api
server
on
the
first
cluster.
To
do
endpoint
discovery
upon
the
upon
the
secrets
are
applied.
You
would
see
the
remote
is
your
remote
secret
with
the
cluster
name
as
part
of
your
secret
in
the
israel
system.
A
B
Great,
so
I'm
just
gonna
show
what
we
set
up
in
a
very
similar
way
over
on
gcp.
So
I
have
two
clusters
they're
each
running.
Well,
actually
one
of
them
is
running
primary
ones,
remote.
So
first,
let's
look
at
the
primary
one.
So
the
primary
cluster
has
that
same
thing
that
lin
just
set
up
on
ibm
cloud.
It
has
an
east
west
gateway,
an
ingress
gateway
and
this
dod
and
then
on
cluster
2.
We
just
have
the
ingress
gateway
in
s2d.
B
We
don't
have
an
east
west
case
gateway
because
we're
not
running
the
full
control
plane.
There
is
duty
in
that
cluster
is
actually
just
the
ca.
It's
not
running
the
the
xds
server,
so
it's
a
little
bit
confusing,
but
it's
actually
not
running
the
whole
control
plane
and
we're
actually
working
on
removing
that
out,
and
so
you
can
see
the
same
thing
on
the
service
level.
There's
this
is2d
dash
remote
service.
B
That
is
actually
what
the
remote
cluster
is
using
to
talk
to
the
server
and
the
installation
is
very
similar
to
what
lynn
showed
as
well.
We
just
have
these
issue
operator
files
that
have
cluster
one
and
cluster.
Two
on
cluster
two,
the
difference
is
this
is
actually
set
up
as
a
remote
cluster,
the
profile's
remote,
and
it
has
a
remote
pilot
address.
B
A
Okay,
great
and
now
steven
give
me
his
secrets,
so
I
apply
his
secrets
on
both
of
my
clusters,
so
I
can
do
endpoint
discoveries.
Now
you
can
see
all
the
secrets
are
applied,
so
I
have
on
each
of
my
cluster.
I
have
three
of
the
remote
clusters
so
now
we're
going
to
look
at
deploy
book
info.
We
talked
about
in
the
diagram
we're
deploying
book
info
with
version
2
version
1
of
the
review
on
the
first
cluster
in
ibm
cloud.
A
A
A
B
And
so
what
lane
was
just
showing?
We
have
the
product
page
working
with
just
v1
and
v2,
and
now
we're
actually
going
to
go
install
v3
over
in
google
cloud,
and
this
one
has
red
stars.
Instead,
it's
a
it's
a
big
upgrade
and
so
really
similar
to
what
lynn
just
showed.
We
have
reviews
deployment,
the
review
service
and
actually
the
rating
service,
because
reviews
actually
calls
back
to
ratings,
which
is
running
back
in
ibm
cloud
in
cluster
one.
B
So
the
path
is
actually
coming
into
ingress
on
the
ibm
cloud
side
going
to
reviews
over
in
google
and
then
going
back
to
ibm
for
ratings
and
then
back
out.
So
it's
actually
bouncing
back
and
forth
between
clouds,
but
as
the
app
owner.
I
don't
actually
care
about
any
of
that
I
just
deploy,
and
now
I
have
red
stars.
B
B
Yeah,
let
me
talk
a
little
bit
about
vms
now,
so
so
what
we
showed
is
how
you
can
have
you
know
a
bunch
of
different
kubernetes
clusters
all
connected,
but
we
know
our
users
have
a
lot
of
services
on
vms
and
they
want
all
those
same
benefits.
And
so
what
istio
has
this
model
that
we've
called
vm
expansion
or
mesh
expansion?
B
And
it's
really
it's
letting
you
attach
vms
kind
of
the
same
way
that
you
attach
clusters
and
that's
actually
how
we
kind
of
have
a
unified
model
here.
So
I
can
run
what
we
call
a
workload
group
which
is
really
just
a
group
of
vms,
similar
to
kind
of
like
a
deployment.
But
it's
you
know
loosely
defined
as
just
any
vms
that
you
want
to
have
as
a
group
and
they
can
use
that
same
east
west
gateway.
B
B
So
let's
look
at
some
of
the
improvements
that
we've
made
recently
to
this,
because
we've
actually
had
this
for
a
while,
but
it
hasn't
been
the
easiest
to
use.
The
big
improvements
coming
in
ist
1.8
are
around
improving
how
you
register
those
vms
and
how
you
create
them,
so
we're
actually
introducing
two
new
commands.
I
actually
realized.
I
left
out
the
x
for
experimental
on
these.
These
are
experimental
commands,
but
you
can
create
a
workload
group
really
easily.
B
B
Some
of
the
other
improvements
we
have
are.
We
have
dns
proxing,
which,
before
this
you
had
to
go
and
manually
change
your
dns
configuration
for
your
bm,
either
changing
it
to
point
at
one
of
the
kubernetes
clusters
dnsers
or
setting
up
your
own
local
proxy
that
forwards
things
for
the
mesh
to
the
cube
one
and
otherwise
keeps
them
in
whatever
you
have
for
your
vms.
B
B
We
also
have
changed
how
identity
bootstrapping
happens
in
previous
versions.
There
was
a
very
complicated
setup
with
certificates
and
I
believe
the
the
1.7
one
you
could
only
really
have
one
vm
attached
to
a
cluster
didn't
really
expand
very
well.
This
actually
uses
the
existing
kubernetes
token
infrastructure
to
bootstrap
them.
So
as
part
of
that
workload,
entry
configure
this
will
actually
automatically
be
generated
for
you.
B
We
generate
the
token
you
copy
that
to
the
vm
and
then
that
bootstraps
certificate
which,
from
then
on
uses
just
the
normal
istio
certificate
infrastructure
we've
also
added
auto
registration.
So
you
don't
have
to
worry
about
manually,
registering
each
vm
as
it
comes
up
which
doesn't
work
well,
if
you
have
auto
scaling-
and
we
also
have
health
checking
coming
in
too
so
these
all
make
vms
kind
of
as
easy
to
use,
hopefully
as
pods
once
they're
all
in
place
and
let.
A
B
B
Actually,
you
can
call
by
name
here,
I'm
actually
using
the
file,
but
if
it's
in
the
api
server
you
can
actually
just
refer
to
it
by
name,
you
call
workload,
entry
configure
with
that
name
and
namespace,
and
it
generates
into
the
configure
all
the
artifacts
that
you
need
to
run
the
vm
and
basically
that's
it.
You
copy
those
to
the
vm
and
you
run
istio
and
the
vms
will
then
connect
through
that
east-west
gateway
to
s2d.
B
They'll.
Be
practicing
dns
for
you
and
all
the
requests
between
the
entire
mesh
can
now
go
to
those
vm
end
points
and
vm
end
points
can
call
into
the
mesh.
So
all
the
networking
is
just
set
up
and
working.
That's
basically
it
so.
We've
walked
through
a
lot
of
different
parts
of
istio
in
this,
and
here
are
kind
of
the
the
key
takeaways.
B
B
B
Mtls
and
authorization
policies
and
all
that
good
stuff,
as
part
of
this,
you
can,
you
know,
choose
where
you
want
to
install
those
control
planes.
Obviously
it
works
across
multiple
networks
and
then
the
other
takeaway
is
that
this
is,
you
know,
works
great
for
kubernetes,
but
we're
also
making
it
really
simple
and
easy
for
vms
as
well,
so
those
will
also
be
able
to
join.
B
A
B
Try
that
can
you
hear
me
lynn,
bye,
tom,
okay,
so
the
observability
work?
We
haven't.
Okay,
great,
yes,
technical,
technical
issues
with
live,
not
cute
right
here,
observability
isn't
totally
multi-cluster
aware,
yet
we're
actually
working
on
that.
I
think,
hopefully,
in
the
1.9
release
of
this
video,
we'll
be
able
to
have
some
better
stuff
there,
it's
possible
to
set
up,
but
but
it's
not
easy
sort
of
to
the.
We
want
to
make
things
easy,
not
just
possible
theme
here.
It's
it's
not
yet
that
easy
right!
B
B
I
can
maybe
look
at
the
next
question,
so
there
was
a
question
about
about
federation,
support
and
inter
accounts
and
intro
accounts,
I'm
not
actually
quite
sure
what
that
is
meant
to
mean
federation
is
something
we
want
to
continue
also
making
easier.
That's
that's
also
not
quite
as
easy
as
we'd
like
it
yet,
but
we'll
get
there.
If
you
want
to
follow
up
on
exactly
what
you
mean
about
inter
accounts
versus
intro
accounts,
we
can
we
can
follow
up
on
the
question
there.