►
Description
Featuring Nina Polshakova and Aaron Birkland. Adopting or adapting to Istio Ambient mesh requires new kinds of decisions, engineering considerations, and procedures that might not be familiar to users of classic Istio with Sidecars. With Gloo Mesh, we aim to provide the same capabilities and APIs you are used to, while managing the practical differences between the Sidecar and Sidecarless worlds under the hood. We will explore how Gloo mesh achieves this goal, and explore a few additional knobs Gloo Mesh provides for fine-tuning ambient to optimize particular use cases.
A
A
So
before
we
start
how
many
of
you
either
use
or
are
familiar
with
glue
mesh
in
in
particular
right
now,
okay,
a
few.
How
many
are
you
know,
use
istio
directly
and
maybe
considering
blue
mesh?
Okay,
all
right.
So
this
is
the
this
is
to
kind
of
give
a
high
level
overview
of
how
glue
mesh
could
be
helpful
in
adapting
to
ambient
because,
as
you
peel
away,
the
layers
they're
actually
a
few
nuances
that
you
need
to
be
aware
of
when
adapting
to
ambient
mesh.
A
So
this
kind
of
gives
you
a
a
big
big
picture
of
what's
going
on
and
how
glue
mesh
can
be
helpful
and
I'll.
Try
to
be
quick
for
this
increasingly
inaccurately
named
10
o'clock.
Talk
about
about
glue
mesh,
okay,
so
I'm
gonna
go
through
this
rather
quickly,
but
it's
it's
good,
just
to
start
with
the
classic
sidecar
architecture.
We
talked
about
this
earlier.
You
all
probably
know
this,
but
suffice
to
say.
A
The
important
part
is
that
the
istio
API
so
by
API
I
mean
the
custom
resources,
the
istio
custom
resources,
the
virtual
Services,
the
destination
rules,
service
entries
Etc,
are
all
implemented
by
the
envoy
instances
that
are
injected
into
each
pod,
the
side,
cars
so
to
speak,
and
so
basically
you'd
Define,
the
topology
of
your
mesh
and
the
policies
in
terms
of
the
istio
API
and
istio,
then
translates
it
into
envoys
Primitives.
So
Envoy
is
kind
of
the
lower
level
implementation
here
and
istio.
A
You
know
the
mesh
is
specified
in
terms
of
in
terms
of
istio.
Now,
as
your
use
case
becomes
more
complex,
as
you
like,
for
example,
involve
multi-cluster
use
cases
or
service
isolation
or
your
mesh
grows
big.
Then
it
can
be
a
little
bit.
Defining
the
mesh
in
terms
of
istio
Primitives
can
become
a
little
bit
tricky
and
that's
where
glue
mesh
enters
the
picture.
Glue
mesh
is
a
higher
level
API
and
introduces
some
Concepts,
such
as
workspaces
and
such
as
virtual
destinations.
A
That
can
make
it
a
little
bit
easier
to
specify
your
mesh
in
you
know
complex
scenarios
But.
Ultimately,
what
glue
mesh
is
doing?
Is
it's
taking
this
high
level
glue
mesh
API,
translating
it
into
istio
resources,
which
could
be
fairly
complex
for
implementing
service
isolation
in
a
multi-cluster
environment
and
then
istio's
configuring,
the
envoy
instances,
so
so
far,
so
good,
nothing
radically
different!
A
Here
now
we
enter
in
the
ambient
architecture,
and
you
know,
as
alluded
to
earlier
today,
so
ambient
kind
of
it's
it's
big
thing
is
that
it
pulls
the
implementation
of
the
service
mesh
away
from
the
pods,
so
it
decouples
it
from
the
pods,
so
the
pods
can
have
their
own
operational
life
cycle.
It's
not
at
all,
coupled
to
the
life
cycle
of
istio
and
the
separation
of
those
two
offers
considerable
operational
complexity
benefits
because
it
reduces
the
operational
complexity.
A
So
if
you
actually
have
policy,
if
you
actually
need
to
know
what
an
HTTP
request
is,
what
a
header
is,
what
a
what
a
path
is
ETC,
then
you
need
to
go
into
the
L7
world,
and
then
that
means
you
need
Waypoint
proxies,
and
the
idea
is
that
the
Z
tunnels
can
forward
traffic
to
Waypoint
proxies
for
implementing
that
here's
where
things
start
to
get
a
little
bit
tricky
Also.
Earlier
today
you
learned
about
the
Gateway
API
and
that's
what
istio
uses
right
now
in
order
to
specify
that?
A
Yes,
in
fact,
we
need
these
Waypoint
proxies.
So
let's
take
a
look
at
this
real,
real,
quick
right,
so
here
we
have
a
Gateway
resource
that
we
created.
We
put
it
in
in
our
in
our
in
our
cluster
and
if
you
look
at
these
annotations,
you
see
this,
you
know
annotations
istio,
I
o
service
account
and
we've
named
the
We've
named
a
specific
service
account,
so
that
brings
forward
a
number
of
questions.
A
Okay,
so
out
of
the
box,
ambient
just
comes
with
these
Z
tunnels
right
and
we
need
to
opt
in
to
Waypoint
proxies,
and
so
one
of
the
points
of
ambient
mesh
is
for
reduction
of
cost
reduction
of
proxies
that
you
don't
need.
So
so
you
need
to
opt
into
these
things.
However,
the
consequence
is
that
out
of
the
box,
the
entire
istio
API
is,
you
know
it's
not
implemented
by
Z
tunnels.
It's
in
it's
implemented
kind
of
incrementally.
As
you
add,
these
Waypoint
proxies,
which
is
a
notable
nuance,
so
yeah.
A
So
this
this
kind
of
begs
a
number
of
questions
as
you
actually
get
to
use
it.
So
what
does
it
mean
to
have
a
waypoint
for
a
service
account
in
the
first
place,
and
so,
if
you're
responsible
for
specifying
when
to
use
these,
these
Waypoint
proxies?
How
do
you
know
when
it
is
necessary
to
create
them?
How
do
you
know
which
ones
you
need
and
then
there's
the
question
about
Affinity.
Like
note
Affinity
of
these,
these
these
Waypoint
proxies
scaling,
High
availability.
A
What
sort
of
API
is
is
is
available
for
these,
so
diving
in
a
little
bit
deeper
as
it
turns
out,
especially
if
you're
familiar
with
istio.
It
becomes
clear
that,
although
the
istio
API
has
not
changed
for
ambient,
there
is
a
fairly
different
mental
model
that
you
need
to
adjust
to
and
have
in
your
mind.
So
this
sort
of
this.
This
is
a
quick
scenario
that
kind
of
gets
at
the
the
meat
of
that
okay.
So
in
this
scenario,
we
have
a
reviews.
A
A
So
a
request,
the
the
request
comes
from
the
Pod
and
it
goes
to
the
Z
tunnel,
which
is
part
of
the
node,
which
is
on
the
Node
that
co-located
with
the
Pod
from
reviews,
that's
making
the
request,
and
then
the
Z
tunnel
knows
to
route
that
to
the
Waypoint
for
ratings
and
that
presumes
that
this
Waypoint
exists.
If
there
is
no
ratings
Waypoint,
it
simply
won't,
and
you
simply
will
not
get
this.
The
the
the
virtual
service
will
not
be
implemented.
A
Let's
say
that
it
has
some
some
weights,
and
so
it
directs
most
the
traffic
to
V1
and
maybe
a
small
percentage
to
V2
you're
doing
Canary
thing.
In
order
for
that
to
work,
you
need
that
ratings
Waypoint
and,
if
you're
familiar
with
with
with
the
functioning
of
istio,
you
might
be
taking
a
little
bit
taken
aback
by
this,
because
in
the
classic
sidecar
mode
virtual
Services,
they
they
Define
routing
rules
and
they
are
typically
implemented
on
the
client
side.
So
if
that
reviews
had
a
sidecar
right,
the
sidecar
would
intercept
the
request.
A
Do
the
routing
there
that
is
implied
by
the
virtual
service
and
the
client-side
car
will
send
it
where
it
needs
to
be
here.
It's
different
here.
Reviews
sends
a
request
to
a
server
side,
a
ratings
Waypoint
that
has
nothing
to
do
with
the
review
service
and
it's
routed
from
there.
So
if
you're
familiar
with
istio,
this
kind
of
flips,
the
you
know
where
virtual
services
are
implemented,
it's
it's
kind
of
backwards
from
sidecars.
A
Likewise,
if
we
consider
service
entries
right,
reviews
makes
a
request
to
let's
say:
HTTP
HTTP
bin
goes
to
the
Z
tunnel
and
it
goes
through
a
different
Waypoint
where
policy
is
enacted
and
then
goes
out
to
the
internet.
Well,
that
is
a
oh
wait,
a
minute.
That's
the
reviews,
Waypoint!
What's
up
with
that!
Well,
so
you
know
external
services
on
the
internet,
don't
really
have
their
own
waypoints
and
so
we're
actually
using
a
waypoint
deployed
for
the
surface,
encounter
reviews
in
a
client-side
manner
in
order
to
implement
that
service
entry.
A
So
you
can
really
dig
deep
into
you
know,
even
though
the
istio
API
hasn't
changed.
There
are
some
fundamental
differences
down
underneath
of
how
istio
is
implementing
its
own
API
and
what
happens
to
requests
so
yeah.
So,
in
order
to
really
you
know,
leverage
those
Gateway
resources
in
order
to
define
the
set
of
waypoints
that
you
want.
There
are
some
nuances
and
some
some
things
that
you
need
to
consider,
and
so
who
here
is
looking
for
more
nuances
in
the
service
mesh
I
have
a
few.
A
A
You
know
glue
mesh,
provides
a
high
level
API,
which
is
then
translated
into
istio
Primitives,
and
so
in
this
case
the
you
know,
istio
API
is
the
same,
but
then
we
have
these
these.
These
Waypoint
proxies,
which
you
know
who
knows
what
Waypoint
proxies
we
need
so
in
other
words
like
glue
mesh.
Basically
it
presents
to
you
the
same
abstractions,
the
same
glue,
mesh
API,
but
under
the
hood
glumash
is
doing
doing
things
a
little
bit
differently
for
ambient.
A
So
one
of
the
you
know
major
major
components
that
we
found
out
that
we
needed
in
order
to
implement
glue
mesh
for
ambient
is
a
waypoint
lifecycle
management.
So
the
glue
mesh
API
has
the
notion
of
workspaces
from
there.
We
know
which
Services
communicate
with
which
other
services
says.
We
know
what
glue
mesh
translates
you
know
into
in
terms
of
the
sdo
API,
and
so
we
can
infer
which
waypoints
are
actually
necessary
for
a
given
use
case.
So
glue
mesh
is
able
to
optimize
this
now.
A
You
could
always
run
ambient
istio
with,
like
you
know,
Waypoint
proxies
everywhere,
and
that
would
work,
but
that
wouldn't
really
give
you
you
know.
That's
not
really
an
optimal
scenario,
so
glue
mesh
can
kind
of
do
that
optimization
under
the
hood.
Likewise,
factors
like
like
scaling
like
how
many
of
these
Waypoint
proxies
do
you
need
Affinity
Etc,
there's
right
now
there
is
no.
There
is
no
solid
answer
for
that.
A
As
far
as
the
as
far
as
the
apis
available
in
ambient
istio,
that's
something
which
may
very
well
be
exposed
down
the
road,
but
it's
something
that
we
wanted
to
like
expose
control
of
now.
So
we
kind
of
interact
with
these
waypoint
proxies
at
a
lower
level,
where
we
can
influence
factors
like
that,
and
so
we
provide
an
opt-in
API
for
like
if
you're
interested
in
in
in
you
know
influencing
those
aspects.
It's
it's
a
knob,
that's
available.
A
A
You
know,
underneath
you
know
getting
getting
glue
mesh
to.
You
know,
work
with
Ambi
and
there's
some
slight
changes
there
and
lastly,
this
bullet
point
managing
risk.
So
istio
ambient
is
Alpha.
It
is
evolving.
It's
it's,
its
API
might
change
in
certain
respects.
You
know,
but
you
know
we
can't.
We
can't
necessarily
predict
how
it
will
evolve,
but
the
idea
is
that
glue
mesh
kind
of
acts
as
a
buffer
layer,
in
the
sense
that
you
know
we
try
to
keep
the
same
API
for
glue
mesh.
A
Just
translate
it
a
little
bit
differently
to
the
a
reality
of
the
istio
underneath
it
and
we
plan
to
keep
track
of
the
changes
to
istio
and
and
we'll
leverage
new
features,
and
otherwise
you
know
just
be
able
to
provide
a
solid,
stable
platform
where
you
can
experiment
with
with
ambient
and
and
be
a
bit
insulated
from
the
alphanus
of
the
underlying
istio.
So
that's
kind
of
it
in
a
quick
nutshell
in
this
this
this
short
presentation
time
and
so
Nina-
is
going
to
give
a
demo
of
this
in
action.
B
Can
you
hear
me:
okay,
okay,
awesome,
so
yeah
fingers
crossed
we're
still
connected
to
the
hot
spot,
but
yeah,
so
so.
First
of
all,
I'll
pull
up
the
glimesh
UI.
So
this
is
the
UI
that
Aaron
was
mentioning
and
in
my
example,
I
have
two
gke
clusters:
one
has
the
glue
mesh
management
server
installed
and
the
other
has
our
glumesh
agent
installed
and
ambient
istio.
So
then,
if
we
go
to
the
graph,
this
kind
of
shows
the
metrics
that
Aaron
mentioned
so
currently,
I
only
have
I,
don't
have
any
waypoints.
B
So
all
these
metrics
are
coming
from
the
Z
tunnel
and
I'm
going
to
use
the
book
Info
app
example
to
demonstrate
some
traffic
routing
and
Waypoint
creation.
So
if
you're
familiar
with
book
info,
you
have
the
product
page,
which
kind
of
looks
like
this.
Let's
see
if
the
refresh
is
still
connected.
Oh
look
at
that.
B
So,
based
on
the
reviews
you
hit
you'll
either
get
no
stars
for
reviews,
V1
or
blackstars
for
reviews,
V2
or
red
stars
for
reviews
V3,
and
that's
just
important
to
keep
in
mind
as
I
demonstrate
some
stuff.
So
let's
actually
take
a
look
at.
What's
in
our
in
our
cluster,
so
this
is
the
remote
cluster
that's
registered
with
the
agent
and
on
it.
I
have
three
different
nodes,
so
looking
at
the
first
node
there's
some
glue
mesh
resources
here
that
we
can
use
for
x-dof
and
rate
limiting.
B
Let's
go
back
so
on
the
second
node.
We
have
actually
our
book
info
like
a
subset
of
our
book
info
here.
So
we
have
product,
page
ratings
reviews,
V1
and
V2
and
then
again
also
z-tunnel
and
istiocni.
So
one
thing
you
might
notice
here
is
there
aren't
any
sidecars,
so
in
product
page
I
actually
have
a
curl
container
just
to
test
some
traffic
that
we're
going
to
be
sending.
B
Oh,
it
has
the
last
part
of
our
book
Info
app,
so
it
has
reviews
V3
and
the
details
here
and
again:
Z
tunnel
and
istio
cni
node
cool
okay.
Now
that
we
got
that
out
of
the
way
we
can
actually
route
some
traffic.
So
the
first
thing
I'm
going
to
do
is
apply
a
header
match
example
using
the
glue
mesh
API.
So
in
order
to
do
a
subset
routing
in
glumash,
let
me
make
this
full
screen
yeah
a
little
easier
to
see.
B
We
create
this
route
table
resource
and
in
this
example,
we're
going
to
either
route
to
reviews
V2
based
on
this
header.
Being
there,
the
user
is
your
custom
user
or
if
the
header
isn't
present,
we're
going
to
route
to
or
use
V1,
so
I'm
going
to
apply
that
and
let's
actually
send
some
traffic.
So,
like
I
mentioned,
we
have
in
the
product
page
a
nice
curl
container.
B
So
we're
going
to
go
from
the
product
page
to
reviews
and
just
send
a
little
bit
of
traffic
cool,
okay,
it's
very
slow
because
of
the
the
Wi-Fi
and
you
might
notice
that
there
aren't
any
Stars
associated
with
this.
So
it
seems
like
our
subset
match
worked
because
we
didn't
have
the
header
in
this
request.
B
So
again
with
the
header,
we
should
get
our
black
stars
back
cool
okay.
So
what
happened
behind
the
scenes?
So,
let's
look
at
what's
inside
of
book
info,
so
one
thing
I
didn't
mention
is
book
info
is
labeled
for
ambient.
So
this
is
why
traffic
is
routing
through
the
Z
tunnel
and
why
this
Waypoint
proxy
has
just
gone
created.
So
we
saw
glue.
Mesh
has
magically
created
a
waypoint
proxy
based
on
our
only
our
route
table
that
we
applied
so
because
this
route
table
has
the
header
match.
B
Here
we
create
this
Waypoint
proxy
to
manage
the
L7
policy
there.
So,
let's,
let's
look
at
the
logs
just
to
make
sure
that
we're
actually
going
through
the
Waypoint
and
yeah
cool.
So
we
got
some
connections
that
looks
good
and
they're
they're,
hitting
the
reviews.
Endpoint
there
cool
okay.
So
the
next
thing
we're
going
to
do
is
apply
so
that
was
just
simple
subset
routing:
let's
apply
an
actual
L7
policy,
so
in
glue
mesh.
B
If
you
want
to
apply
fault
injection,
you
can
apply
it
based
on
the
route
table
you
defined
earlier,
so
here
we're
using
the
the
route
table,
labels
that
we
defined
from
our
route
table
before
and
another
thing
to
note
like
this
route
tables,
specifically
for
East
West
traffic,
that's
where
we're
going
from
pot
to
pawn,
but
it's
matching
on
the
the
label
that
we
we
had
here:
cool
okay.
So
let's
let's
apply
that.
B
And
then,
let's
send
some
traffic
so
again
we're
going
to
go
from
product
page
and
hit
reviews
and
we're
expecting
to
hit
this
418
response
so
yeah.
So
we
get
our
filter
report
and
if
we
again
look
behind
the
scenes,
what
happened
in
book
info,
you
can
see
that
we're
still
using
the
same
Waypoint
proxy
that
was
created
before,
because
we
don't
need
a
new
one,
since
the
policy
is
being
applied
to
review
still.
B
B
So
now
we
have
two
Waypoint
proxies
running
and
one
thing
to
note
is
they're
running
in
the
same
node.
So
if
you
wanted
to
change
the
the
node
Affinity
or
the
where
the
Waypoint
proxy
gets
deployed,
you
can
add
a
plot
Affinity
value
to
make
sure
the
Waypoint
proxy
gets
deployed
at
where
a
specific
review
service
is
so
currently
it
used
to
be
in
the
node.
Where
reviews
V3
is
so
we're
going
to
select
V2
now
and
apply
that.
B
B
So
that
gives
you
both
the
ability
to
like
just
try
ambient
out
of
the
box
without
changing
any
of
your
underlying
apis
to
see
how
it
works,
but
it
also
lets
you
have
the
flexibility
to
configure
where
it
gets
deployed.
You
know
how
many
replicas
you
want
and
things
like
that
so
yeah,
that's!
That's
all
I
had
for
the
demo.