►
From YouTube: 2021-01-28 Istio Community Meeting
Description
On January 28, 2021 the community hosted a meetup featured a presentation called, "Multi-cluster Istio operations,” Istio control planes across multiple clusters including configuration, security, and Web Assembly (Wasm) presented by Christian Posta, Field CTO, Solo.io.
B
A
A
A
It's
events,
dot,
istio
dot,
io,
slash,
instacon
2021,
so
we
hope
to
see
many
of
you
there
to
learn
how
people
use
istio
in
production
and
learn
from
leadership.
Obviously,
as
well
as
the
the
roadmap
for
the
for
the
project,
I
believe
we
should
be
able
to
announce
the
program
pretty
soon.
So
that's
exciting!
A
B
All
right,
thank
you,
maria,
and
definitely
thank
you
for
giving
an
update
on
the
istio
con.
That
is
the
week
of
february
22nd.
I
believe
I
do.
I
want
to
say
something
about
that
too.
I'm
I'm
I'm
I'm
surprised,
pleasantly
surprised,
and
it
was
really
good
to
see
the
the
number
of
submissions
that
came
in
for
istio
khan.
B
B
It's
gonna
be
a
little
bit
of
a
different
format.
I
I'm
gonna
say
I'm
trying
something
new
here.
Let
me
share
my
screen
and,
and
if
you
can
see
from
my
screen,
I'm
gonna
I'm
gonna
go
off
a
little
bit
of
normal
normalcy
in
normal
script,
where
people
show
slides
and
demos
I'll
show
some
demos,
but
I
also
really
like
you
know.
I
can't
nobody's
traveling
right
now
right
and
as
part
of
my
work
as
a
as
an
architect
and
and
working
with
with
customers.
B
I
I
really
enjoyed
traveling
and
being
in
front
of
them,
and
you
know
talking
about
solutions
and
sketching
things
on
on
whiteboards
and
going
back
and
having
that
collaborative,
feel
and
that's
not
something
that
that
we've
been
able
to
to
do.
And
so
one
of
the
formats
that
I
wanted
to
try
for,
for
at
least
this.
This
meetup
is,
is
trying
to
go
back
to
that.
B
Right,
like,
like,
I
said
earlier,
the
best
part
was
being
with
people
and
and
exchanging
ideas
and
and
trying
to
draw
them
out.
You
know
I
would
prefer
this
to
be
two-way
street,
so
people
jump
in
and
ask
questions
or
clarifications
or
objections
and
pushback.
If,
if
you
know,
if
you
see
an
opportunity
for
that
so
with
that,
thank
you
for
joining
the
community
meeting
and
cross
your
fingers,
let's
hope
the
ipad
and
the
and
everything
cooperates
here
and
let's,
let's
get
going
okay.
B
B
But
we
can.
You
know
we're
on
the
cusp
of
of
being
able
to
use
webassembly
for
a
growing
set
of
use,
cases
to
extend
the
capability
of
the
mesh
and-
and
in
fact
at
least
here
at
so
we
are
working
with
some
large
customers
that
are
putting
weather
assembly
into
production
right
now,
which
a
month
or
two
ago
I
would
have
thought
that
be
scary.
But
it's
working
out.
It's
working
out
really
good.
B
B
There
is
the
the
model
where
everything
is
on
the
same
network
which,
if
you
have
and
can
enjoy
a
situation
like
that,
then
by
all
means,
go
for
it
and
what
that
means
is.
You
might
run
multiple
clusters
with
non-conflicting
networks
or
rather
routable
networks
between
each
of
the
pods,
so
that
the
the
you
know
a
pod
in
cluster.
One
talking
to
a
pod
in
cluster
two
doesn't
have
to
do
anything
special,
just
talk
to
the
aip
of
that
pod
or
that
kubernetes
service
and
everything
will
be
routed
and
everything
will
be
fine.
B
Now,
how
does
how
does
this
service
here
know
that,
when
it
talks
to
a
surface
b
that
service
b
actually
lives
over
on
a
different
cluster?
Well,
istio
has
something
called
the
service
entry
right
and
that's
we.
We
we
put
that
config
piece
of
config
here
and
we
give
it
a
name
of
b,
let's
say:
there's
a
service
b
and
then,
when
this
particular
proxy
wants
to
talk
to
a
service
b
under
the
covers.
B
So
now
this
this
model
will
happen
when
you're
on
different
networks,
and
you
need
to
hop
to
different
networks
now,
there's
another
variant
to
the
multi-cluster
model,
which
is
sharing
or
not
sharing
a
control
plane
in
this.
In
this
case
that
we
see
here,
we
have
two
different
clusters
with
two
different
istio
control
planes,
and
the
reason
that
I
I
we
we
typically
start
out
with
this
model
is
that
it
allows
for
various
types
of
failure
and
isolation.
B
So
if
this
cluster
goes
down,
we're
not
trying
to
share
a
control
plane
and
this
that
cluster
can
go
down
and
not
affect
the
the
other
cluster
okay.
So
then,
if
we
have
separate
control
planes,
then
we
need
some
way
of
telling
the
work
telling
the
the
control
plane
in
cluster.
One
we'll
call
this
one
cluster
one
and
this
one
cluster,
two
that
hey
this
is
service.
B
Basically,
it's
an
entry
into
istio
registry
of
service
discovery
registry
that
says
okay
well,
surface
b
is
over
here
also
in
1.8,
and
although
this
this
capability
had
existed
before,
but
it
was
officially
documented
in
the
in
1.8
the
model
that
the
docs
suggest
is
to
connect
connect
cluster
one
to
cluster
two
to
its
kubernetes
api
right.
So
we
have
the
kubernetes
api
here
and
we
also
have
a
you
know
the
kubernetes
api
in
cluster
one
and
what
what
the
doc
suggests
is
create
a
little
a
little
secret
here
on
cluster
one.
B
That
knows
how
to
authenticate
to
cluster
two.
Do
the
same
thing
on
cluster
two
back
to
cluster
one
and
have
them
pull
the
the
endpoints
for
all
the
different
services,
and
so
if
there
are
endpoints
for
service
b
over
on
on
cluster
two
and
on
cluster
one,
then
istio
will
know
about
that.
There's
a
surface
beyond
cluster,
too.
All
right
and
in
this
model
we
don't
have
to
create
all
of
the
different
service
entries
and
and
so
on.
B
Now,
one
of
the
one
of
the
challenges
or
unfortunate
side
effects
of
this,
as
as
we've
seen
with
some
of
the
folks
who
have
adopted
this
model,
is
that
the
more
clusters
you
have?
Let's,
let's
draw
a
couple
more
here,
the
more
and
and
you
want
to
federate
the
services
across
these
different
clusters.
The
more
you
have
to
create
these
security
tokens
to
talk
to
the
kubernetes
api
in
the
various
clusters
right.
So
every
cluster
ends
up
having
access
to
the
kubernetes
api
of
any
of
the
other
clusters
in
that
that
group
right.
B
And
so
if
we,
if
we
accept
that,
then
we
have
to
say
what
what
is
what
is
a
different
model?
How
how
can
we,
if,
if
we're
going
to
solve
the
problem
of
service
discovery
which
which
we
need
to
do-
and
we
don't
want
to
share
these
secrets
and
shuffle
them
around,
because
you
could
have
100
clusters
and
one
cluster
gets
compromised,
then
all
of
them
potentially
could
get
compromised?
B
It's
not
a
very
it's,
not
a
very
safe
model,
one
of
the
one
of
the
options
that
we've
been
working
with
with
customers
around
is:
let's
see
if
I
can
go
to.
Let's
just
go
to
this.
This
diagram
is
going
back
actually
to
the
the
model
of
placing
the
service
entries
where
they
should,
where
they
should
go,
and
this
has
a
couple
of
advantages
one.
B
Instead
of
giving
every
cluster
access
to
every
other
cluster,
you
could
have
something
else,
some,
let's.
Let's
call
this
a
config,
config,
automator
or
whatever,
and
this
this
config
automation
can
say
all
right:
cluster,
one
and
cluster
two
for
the
services
that
that
need
to
talk
with
each
other.
We
will
put
service
entries
onto
those
clusters
on
onto
those
clusters
and
for
the
ones
that
don't
need
to
talk.
We
won't,
we
won't
add
the
services.
So
we
won't
every.
B
All
right.
So
now
we
kind
of
go,
go
back
and
we're
going
to
we're
going
to
have
a
little
bit
more
control
over
what
gets
exposed
and
how
it
gets
exposed
and
we're
going
to
scope
down
to
security,
surface
or
potential
threat
surface
down
to,
let's
say
a
single
service
like
the
config
automator
orchestrator
piece.
B
C
Second,
hey
christian:
this
is
lynn,
I
think
it's
really
interesting.
You
are
describing
this
problem.
Certainly,
there
are
some
challenges.
I've
also
heard
that
there
are
concerns
to
allow
even
just
read
access
just
to
re,
allow
the
primary
cluster
to
allow
access
to
the
remote
cluster
just
on
the
read
access
for
the
api
server.
So
I've
also
heard
similar
concerns
on
that.
I
think
it's
interesting
how
you
guys
tackle
this
problem.
B
Definitely
yeah
so
so
far,
I'm
just
trying
to
talk
about
the
problem
generally
and
then
I'll
go
into
a
little
bit
of
of
how
we're
working
with
with
folks
to
to
solve
this
problem,
but
yeah.
I
just
just
just
first
wanted
to
kind
of
lay
the
groundwork
of
what
what's
available.
What
what
are
some
of
the
patterns?
What
what
are
some
of
the
drawbacks
and
and
talk
about
it
like
that?
But
then
yeah
I'd
love
to
go
into
some
of
the
stuff
that
we're
we're
specifically
doing.
B
D
They're,
following
along
this
makes
sense
yeah
they
sent
you
here
from
zendesk
technology.
It's
a
task
that
we
have
on
our
backlog
to
build.
We've
been
calling
this
internally
a
remote
service
reconciler,
which
was
your
previous
slide.
That
was
the
idea
we
had
in
mind
without
digging
further
but
yeah.
I
really
appreciate
you
sharing
your
thoughts
and
looks
like
we're.
Gonna
need
to
revisit
and
reconsider
that
architecture
that
we've
planned.
B
B
But
if
they're
not
you
know,
if
they're
different
clusters
like
they
are
heterogeneous
clusters,
then
then
the
config
slightly
change
right
and
the
direction
of
traffic
is
sort
of
implied
in
the
configuration
and
some
somehow
that
needs
to
be
accounted
for.
Now,
if
you
take
this
and
and
spread
it
out
to,
let's
say
a
whole,
a
whole
bunch
of
different
clusters,
now
we
have
to
shuffle
these
configs
make
sure
the
implicit
directionality
and
all
the
all
the
other
stuff
is,
is
taken
care
of.
B
That's,
even
if
you
had
all
of
this
put
into
your
get
ups
pipeline.
There's
there's
still
a
lot
of
moving
pieces
here
and
let
me
just
switch
back
to
this
one.
This
is
the
one
I
wanted
to
be
on
anyway.
There's
still
a
lot
of
moving
pieces
here
and
a
lot
of
ways
that
things
can
go
go
wrong.
So
what
we've
been
working
with
with
folks
on
is
how
can
we?
B
Maybe
you
have
like
maybe
a
bunch
of
different
clusters
running
your
application
workloads
and
you
have
a
separate
cluster
where
you
introduce
canary
releases
all
right
and
in
that
separate
cluster,
you
want
to
get
some
traffic,
that's
flowing
in
the
rest
of
the
system
over
to
this,
this
separate
cluster
there's
this
new
canary
cluster
right.
What
you
care
about
is
doing
the
release,
making
sure
the
canary
works.
B
B
I
want
to
make
sure
that
if
things
start
to
fail,
they
fail
gracefully
that
you
know
in
in
certain
cases
you
take
locality
into
into
account
and
so
on
that,
but
but
the
actual,
whether
there's
virtual
services
on
this
class
or
that
match
and
service
entries
and
so
on.
You
focus
on
the
the
part
that
matters
to
to
you
all
right
and
then
that
that
comes
back
to
this.
B
B
So
if
we
just
look
real
quick
at
the
demo,
we
have
two
different
clusters
in
this
case
running
on
gke
cluster,
one
cluster:
two,
they
run
some
parts
of
the
book
info
demo
from
istio.
You
can
see
product
page
and
details
and
reviews
you
want
to
b2
in
the
second
cluster.
We
see
reviews
v1,
v2
and
v3,
so
you
can
kind
of
think
of
cluster
two,
maybe
as
our
canary
cluster,
or
introduce
a
new
version
of
reviews,
and
we
want
to
from
from
the
rest
of
the
traffic
in
the
fleet.
B
B
So
the
first
thing
that
that
we
want
to
take
a
look
at
is
the
app
and
make
sure
that
it's
working
host
1980
remove
your
product
page
cross,
fingers
all
right,
so
the
normal
working
app
that
we
have
running
this
happens
to
be
in
cluster
one,
but
but
the
reviews,
v1
and
v2-
are
in
cluster
one
and
cluster
two.
We
refresh.
We
see
it
re
reviews,
v1
and
v2.
That's
that's
all
normal,
but
what
we
want
to
do
is
we
want
to.
B
You
know
fleet
of
clusters,
but
in
this
case
we
do
want
to
be
explicit
and
say
well
route
in
this
case,
I'm
going
to
choose
a
large
number,
so
we
don't
have
to
wait,
keep
refreshing,
but
I'm
going
to
rout
actually
75
for
the
10
of
the
traffic
to
any
of
the
traffic
coming
into
the
review
service
to
to
the
canary
that
would
be
running
in
cluster
two
and
this
traffic
policy
resource.
So
this
is
the
api
that
that
we
came
up
with
that
us
it
actually.
B
I
was
about
to
say
it
suits
most
people,
but
it
actually
doesn't
there's
no
one
api
that
suits
most
people
or
everyone
and
and
and
there's
there's
some
reasons
behind
this.
This
api
is
actually
customizable.
You
can
change
the
shape
of
this
api
depending
on
who
needs
to
use
it
I'll
talk
about
that
later.
But
so
anyway,
we
have.
We
have
this
traffic
policy
api.
That
is
a
little
bit
more
focused
on
who
are
this?
What
is
the
source
of
the
traffic?
B
So
let's
apply
this
to
our
config
automation
or
we
would
call
a
management
server
management
plane
and
then,
when
we
come
over
here
and
cross
our
fingers,
we
refresh,
we
should
see
some
traffic
go
to
the
red
stars,
which
would
be
reviews
v3.
So
it
is
going
across
from
from
cluster
one
to
cluster
two.
Because
of
this,
this
automation,
or
because
of
this
configuration
the
automation
under
the
covers.
So
if
I
take
a
look
at
our
policies,
we
see
our
our
policy
here.
We've
routed
75
of
the
traffic
to
a
different
cluster.
B
That's
all
good,
but
under
the
covers,
if
we
look
at
one
of
the
the
service
meshes,
we
see
the
correct
virtual
services,
the
correct
service
entries
destination
rules,
any
of
the
envoy
filters
that
we
need
to
need
to
use
here,
gateways
and
any
of
those
things
have
automatically
been
created
and
put
on
the
right
cluster
where
that
that
particular
mesh
lives.
So
if
we
happen
to
look
at
virtual
service
here,
this
is
a
istio
virtual
service.
B
B
But
if
you've
been
watching
istio
and
envoy
and
some
of
the
stuff
that's
been
happening
around
it
with
webassembly
you,
you
would
kind
of
understand
that
webassembly
can
be
used
to
customize
the
behavior
of
the
proxy,
and
you
can
pick
the
language
that
you
like
for
webassembly
and
and
write
the
write,
the
functionality
in
that
language.
For
you
know,
those
limitations
is
still
emerging,
but
you
know
that
that
is.
That
is
a
way
to
customize
the
the
proxy.
Now
the
question
is:
how
do
you
actually
deploy
that?
B
B
B
I'm
gonna
choose
assembly
script,
we'll
target
iso
1.8
and
that
will
basically
bootstrap
for
us
a
a
project
that
has
all
of
the
right
all
of
the
right
versions
for
the
right
excuse
for
the
sdk
that
you
might
want
to
use
for
for
writing.
Your
your
web
assembly
module
and
it
it
spits
out
a
sample
sample
source
code
that
you
can
go
in
and
start
start
editing
in
this
case
we're
going
to
edit
the
the
headers
on
a
response
and
we'll
change.
We'll
add
a
header,
hello
world.
That
part.
B
You
know
that
that
part
is
its
own
again
its
own
topic,
but
let's
try
to
build
it.
There's
a
chance.
Do
I
have
docker
running,
let's
find
out.
I
actually
didn't
run
through
this.
It's
a
bit
off
the
cuff,
but
what
we're
going
to
do
here
is
we're
going
to
build
our
webassembly
module
as
an
oci
image
and
then
from
there.
We
can
push
it
into
a
registry.
B
We'll
give
that
we'll
give
that
a
second
and
then
once
it's
pushed
into
a
registry,
then
we
can.
Then
the
question
comes
alright,
and
how
do
I
deploy
this
thing?
So
we
built
it
and
we
have
it
let's
go
over
here.
Let's
make
sure
that
let
me
just
make
sure
this
is
work,
gonna
work
and
then,
let's
pop
into
this
other,
let's
delete
that
pop
into
this
other
demo.
B
And
what
we're
going
to
see
is
if
we
make
a
call
between
a
pod
and
the
review
service,
we
get.
We
get
a
certain
behavior,
the
out-of-the-box
behavior.
We
get
the
response
that
looks
good,
but
what
we
want
to
do
is
install
a
webassembly
module
to
change
the
behavior,
in
this
case,
simple
demo,
of
the
the
response
headers
right.
B
What
we're
going
to
do
is
we're
going
to
define
using
using
some
configuration
where
to
apply
this
change,
where
this
extension
extensibility
was
where
this
extension
should
exist
and
what
module
we
want
to.
We
want
to
use
and
and
pull
it
from
a
particular
repo,
and
so
if
we
take
this
same,
this
declarative
model
here
and
say
all
right:
we're
going
to
apply
this
to
reviews,
v2
that
happens
to
run
on
cluster
one
and
apply
it
to
our
config
automation,
server
management
server.
B
Then
we
should
cross
our
fingers.
If
we
get
the
deployment
itself,
we
should
see
a
status,
all
right,
it's
been
deployed,
and
now,
if
we
try
to
call
reviews,
it
might
take
a
couple
of
tries
because
we
applied
it
to
reviews
v2
and
it's
going
to
load
balance
between
the
two.
So
let's
just
try
a
couple
more
times.
B
A
couple
more
times,
hopefully
it
doesn't
break
okay.
Then
we
see
we
do
get
the
the
extension.
We
do
get
this
this,
this
change
in
in
behavior
through
to
web
assembly,
and
so
we
can
do
that.
We
did
this.
We
specified
cluster
one,
but
we
could
have
specified
any
of
the
cluster
all
of
the
clusters
and
in
the
way
this
is
working.
Is
the
web
assembly
module,
so
it
wasn't
baked
into
the
image
or
anything
like
that?
B
We
dynamically
loaded
it
at
runtime
and
actually
streamed
the
module
over
a
secondary
xds
channel
that
was
then
able
to
dynamically
load
into
the
proxy,
and
obviously,
here
change
the
behavior
of
of
the
proxy,
and
I
guess,
if
we
look
back
at
the
ui,
you
can
see
that
there's.
This
is.
This
is
something
that
we
added
to
the
particular
workloads
and
that
it's
showing
showing
that
it
was
installed
nicely
all
right.
B
So
I
was,
I
was
hoping
to
come
on
and
see
whether
or
not
the
ipad
illustrations
would
work
and
share
a
couple
of
things
that
we've
been
working
with
our
users,
our
customers
here
at
solo
and
and
then
show
you
what
we're
doing
around
webassembly
and
how
that
integrates
with
with
istio
but
yeah.
I
won't
take
any
more
of
your
time
and
I'll
leave
it
open
for
questions.
A
Thank
you
very
much
christian.
I
know
that
we
got
a
start
and
we
got
on
a
late
start,
so
we
may
not
have
time
for
going
into
breakout
rooms,
but
maybe
we
can
have
a
conversation
about
this
demo
and
if
you
have
questions
or
comments,
please
feel
free
to
speak
up.
But
if
that's
not
an
option
for
you,
we
can
also
read
the
chat.
E
B
The
the
architecture
of
the
configuration
service
allows
that
we
haven't
gotten
to.
We
have
users
who
are
about
to
run
into
that
and
we
will
support
it,
but
so
far
everybody's
been
on
the
same
version
of
istio,
but
this
this
absolutely
is
intended
to
be
used
across
any
versions
of
istio
and
you
know,
and
potentially
even
other
meshes.
But
that's
that
is
the
intent
to
support
that
use
case.
E
B
B
And
so
the
the
approach
we
have
for
for
that
is
to
ahead
of
time
you
can
config.
You
can
configure
right
if
you
say
apply
this
apply
this
config
and
it
doesn't
apply
successfully
to
all
the
clusters.
Then
then
roll
it
back
or
you
can
configure
it
by
default
to
go
ahead
and
apply
it
and
then,
if
one
of
them
doesn't,
if
one
of
them
doesn't
work
out
the
way
you're
expecting
that
at
least
notify
the
user
and
then
give
enough
debugging
tools
to
go,
go
help
figure
out.
B
D
A
quick
one,
so
I've
seen
a
video
about.
It
was
like
a
two
three
minute:
video
about
easter
1.9,
and
there
was
a
very
vague
mention
about
a
global
registry
that
it
will
work
align
with
kubernetes
multi-cluster
support.
Are
you
familiar
with
those
changes
that
are
coming
down?
The
line
will
that
somehow
conflict
with
the
work
that
you're
doing
here.
B
E
F
Our
architecture
is
such
that
each
cluster
is
its
own
shard
and
they
run
the
same
copies
of
the
same
services,
but
we
don't
want
to
load
balance
across
so
would
it
be
able
to?
Would
you
be
able
to
like
address
remote
instances
of
service
services
deliberately
and
explicitly
without
having
to
you
know,
you
make
a
request
to
service
b
and
cluster
two
that
won't
go
to
cluster
three
or
four.
B
Yeah,
that's
a
great
question,
and
so,
with
with
the
model
at
least
we
have
within
glue
mesh.
The
services
in
different
clusters
will
be
uniquely
identified
as
being
in
those
clouds,
so
you
can
route
specifically
to
those
or
if
you
want
to
group
them.
If
there's
other
ways
that
you
want
to
group,
then
you
can.
B
You
can
specify
a
global
name
and
and
have
them
grouped
to
either
one
cluster
or
two
clusters
or
whatever,
but
you
can
so
if
they
would
be
sharded
across
and
they're,
not
heterogeneous,
they're,
just
you
know
they're
in
their
own
cluster,
then
you
would
be
able
to.
You
would
be
able
to
directly
and
address
them.
C
And
just
to
answer
your
question
in
istio,
there
is
also
something
called
locality
load
balancer.
So
this
is
something
enabled
by
default,
but
it's
only
enabled
when
you
also
configure
outlier
detection
inside
of
your
destination
rule.
So
if
you
have
destination
rule
with
outlier
detection
property
config,
you
could
just
configure
hey.
I
always
prefer
local
services
first
and
then,
if
the
local
services
are
failing
and
not
meeting
my
requirements,
it
would
fade
over
to
the
remote
cluster.
So
I
think
that
could
potentially
work
for
you
also.
F
F
C
B
A
Yeah
thank
you
for
for
presenting
this
very
original
demo.
As
a
reminder,
this
is
going
to
be
available
on
the
easy
youtube
channel
in
the
next
few
days.
I
just
wanted
to
let
you
all
know
that
a
jamie
has
just
added
the
the
tentative
schedule
for
instacon
on
the
istio
calendar,
the
community
calendar,
so
this
is
not
written
in
stone
yet
so
the
hours
might
vary
a
little
bit,
but
I
just
wanted
you
to
know
that
this
is
where
we're
going
to
be
updated,
updating
it
so
you're
up
to
date.