►
From YouTube: 003 Extending Istio and Gloo Mesh with Web Assembly
Description
WebAssembly filters allow users the power to extend and customize Istio to their liking. But how do organizations actually develop them? Tooling exists for traditional software development, but established methods and tooling are difficult to come by in the emerging WebAssembly ecosystem. In this talk we will attempt to answer the following, based on our experience working Istio + WebAssembly in customer environments for over one year.
A
A
A
Let's
talk
a
little
bit
about
it's
your
adoption
that
we
see
in
the
industry.
So
we
like
to
divide
it
to
this
first
step.
The
first
step
we
see
is
kind
of
a
crawl
step
where
people
need
support
for
abstract
medicine,
they're,
just
testing
it
out.
They
need
long-term
support,
they're,
beginning
to
learn
what
service
mesh
means
technically
and
operationally.
A
Then
the
next
step
is
people
add
on
more
features.
We
call
it
the
walk
phase,
they're
doing
maybe
a
developer
portal,
maybe
an
ingress
api
gateway,
start
to
use
mtls
for
zero
trust
security
start
to
use
the
observability
features
once
they
get
more
confidence,
they
usually
go
to
the
stage.
We
call
the
run
stage,
which
involves
more
delegating
responsibilities
to
different
teams
with
the
various
objects
that
allow
delegation
a
web
assembly
filters
to
enrich
the
data
plane
once
the
once
organizations
feel
comfortable
in
this
step.
A
B
So,
let's
do
a
quick
overview
of
istio's
architecture.
Istio
deploys
a
sidecar
proxy
to
each
microservice
running
in
your
service
mesh.
These
sidecars
are
each
instances
of
envoy
proxy,
which
we
collectively
refer
to
as
the
data
plane.
This
data
plane
of
onboard
proxies
is
controlled
by
what
we
call
the
control
plane
in
istio's
case.
This
is
this
cod
and
istiod
will
communicate
these
configuration
updates
from
the
control
plane
into
the
data
plane
once
our
customers
start
looking
at
istio.
One
of
the
first
questions
they
ask
us
is:
how
do
we
extend
it?
B
Now,
luckily,
envoy
is
incredibly
powerful
and
it
provides
us
with
a
really
really
powerful
extension
layer
inside
of
its
filter
chain.
So
the
filter
chain
out
of
the
box
will
give
us
some
really
helpful
filters
like
external
off
and
rate
limiting,
but
it
also
gives
us
the
ability
to
build
our
own
custom
native
envoy
filter.
Now
this
does
have
some
drawbacks.
B
Luckily,
this
is
where
webassembly
comes
to
the
rescue.
So
what
is
webassembly
webassembly
is
a
binary
format
that
was
originally
meant
to
run
on
the
web.
It
was
meant
to
run
non-javascript
languages
inside
of
a
browser
context,
because
it
was
designed
to
run
inside
of
a
browser
context,
it's
built
with
simplicity,
security
and
performance
in
mind,
but
these
attributes
are
also
incredibly
desirable
when
running
in
other
contexts.
The
context
we're
especially
interested
in
here
is
running
inside
of
the
envoy
data
plane
or
more
specifically,
inside
of
the
filter
chain.
B
So
what
does
that
look
like,
rather
than
having
a
native
custom
envoy
filter?
Now
we're
running
envoy's
built-in,
wasn't,
filter
and
passing
it
our
wasm
filter
as
code.
This
means
that
it
has
all
of
the
advantages
of
the
other
envoy
configuration
such
that.
If
you
want
to
add
or
remove
a
wasn't,
filter
or
update
its
configuration,
you
don't
need
to
restart
the
proxy
there's
zero
downtime.
It's
also
secure
and
reliable
wasm's
gonna
run
inside
of
an
isolated
vm.
B
A
A
We
like
to
separate
the
technology
from
the
the
user
experience
right
with
docker
the
technology.
Wasn't
new
linux
containers
were
already
there.
Docker
made
it
really
easy
to
build
and
distribute
those
containers.
Same
goes
with.
Webassembly
webassembly
exists
today
in
envoy,
but
to
use
it
today
there's
a
lot
of
stuff.
You
need
to
do
on
your
own
and
with
the
glue
mesh
web
assembly
hub.
We
aim
to
simplify
that.
A
A
A
We
have
pre-packaged
filters
in
several
languages
and
we
allow
you
to
quickly
and
easily
get
started
with
mesh
ctl
glue,
mesh
command
line
tool,
we've
added
the
wasm
sub
command
that
allows
you
to
easily
initialize
a
filter
with
this
mercedes
wasn't
in
it.
It
creates
a
base
filter.
So
you
can
start
writing
code.
A
A
A
This
allows
us
to
configure
onward
to
grab
additional
extensions
like
web
assembly
filters
from
a
separate
control
plane
separating
the
lifecycle
of
regular
mesh
configuration
and
your
webassembly
filter.
In
this
example,
we
use
we
use
mesh
ctl
wasam,
deploy
to
create
a
filter
deployment
crd
that
glue
mesh
will
then
use
to
create
an
android
filter.
Ico
crd
to
inject
this
ecds
extension
onto
onboard
anway
subsequently
will
contact
bluemesh
and
get
the
wasan
binary
and
will
load
it
and
activate
it
on
the
request
path.
A
All
right,
let's
see
a
quick
demo
for
the
wasam
developer,
experience
with
glue
mesh.
So,
first
of
all
on
the
left
side
of
the
screen,
you
can
see
the
glue
mesh
console.
It
gives
you
a
nice
overview
of
your
deployment
status.
If
we
drill
down
to
the
meshes
tab,
you
can
see
that
we
have
two
cluster
management
cluster
in
the
remote
cluster
and
they're
connected
with
a
single
virtual
mesh,
and
you
can
see
the
various
traffic
target,
workloads
and
policy
kind
of
a
high
level
overview
of.
What's
going
on.
A
You
can
also
drill
down
to
the
policy
tab
to
see
specific
policies.
Now
we
have
added
a
wasim
plugin
to
the
mesh
ctl
command
line.
Mesh
ctl
is
the
command
line
that
comes
along
with
glue
mesh
we've
added
what
the
capabilities
of
wasmi
to
mesh
ctl
using
the
wasam
plugin
and
let's
see
how
the
developer
workflow
for
deploying
a
wasm
extension
to
the
mesh
works.
A
This
extracts
a
template
for
an
easy,
getting
started
experience.
So
let's
open
up
the
code
and
see
what
we're
working
with
as
you
can
see.
In
this
example,
we
implement
http
response
header,
so
this
method
will
be
called
every
time
an
http
requested
made.
The
response
is
returned
and,
as
the
response
headers
are
returned,
this
function
here
will
be
called,
and
in
this
case,
what
we
can
see.
A
We
have
a
few
lines
just
to
make
it
a
bit
more
interesting
and
it
sets
a
response-
header,
hello
and
with
the
default
value
world,
plus
this
number,
which
comes
out
to
be
one
all
right.
So
now
that
we
have
the
code
we
want
to.
The
next
step
would
be
to
build
this
filter
into
a
wasa
binary.
We
have
a
command
for
that
as
well,
so
messy
dl
build.
We
tell
it
the
language,
so
it
can
select
the
right
tool
chain
to
build
with.
A
A
Now
this
is
very
similar
to
how
docker
images
work
and,
lastly,
we
give
it
the
folder
that
contains
the
filter,
so
building
pulls
in
a
container
with
build
tools.
In
this
case
it
has
a
bazel
and
it's
running
and
building
the
filter.
It's
happening
live
so
it'll.
Take
a
minute
I'll.
In
the
meantime,
I'll
mention
that
after
the
filter
is
built,
the
resulting
wasam
file
will
get
packaged
in
an
oci
image
that
will
be
stored
on
your
local
machine
and
then
in
the
next
step.
A
What
we'll
do
is
actually
push
it
to
webassembly
hub
all
right
everything
built
successfully
image
was
tagged,
everything
looking
good.
So,
let's
move
on
to
the
next
step,
mesh
cdl
push
and
what
this
does
is
very
similar
to
how
docker
push
works.
It
will
push
this
image
from
the
local
cache
into
webassembly
habio,
so
it's
available
wherever
it's
needed.
A
Next,
all
right
so
far,
so
good
the
image
is
pushed.
So,
let's
move
on
to
the
next
step,
and
the
next
step
is
to
deploy
the
image
right
so
so
far
we
have
the
limit
the
image
in
our
local
machine.
We
have
it
in
webassembly
hub.
We
need
to
get
it
to
the
service
mesh
right
and
in
this
case,
we'll
use
the
message.
Dl
wason
deploy
command,
so
you
can
see
here
messaging
wasn't
deployed
to
ico
to
our
current
management
cluster,
the
deployment
that
we
want
to
create.
That's
the
filter
deployment.
A
It's
going
to
be
the
add
header.
This
is
the
name
of
the
crd
that
will
be
created
to
express
the
extension
right,
so
everything
is
managed
with
crds
and
the
result
of
this
command
will
be
a
crd
that
glue
mesh
will
process
and
inject
the
filter,
the
wasam
extension
into
the
workload.
So
this
is
the
name
of
the
filter
deployment.
Crd
that
is
about
to
be
created.
We
give
it
obviously
the
namespace
and
the
image.
This
is
the
image
we
just
pushed
to
webassembly
hub.
A
A
So
with
with
the
ui.
It
would
really
try
to
give
you
a
full
360
view
of
what's
happening
in
your
service
mesh,
all
right
next
step,
we're
going
to
test
that
it's
actually
working
here
is
the
step
where
I
cross
my
fingers.
So
what
we're
doing
here
is
essentially
x
again
to
the
product
page
pod
and
from
the
product
page
pod,
we're
gonna
curl
the
ratings
pod
right
and
if
everything
works
well,
we
will
see
exactly
the
hello
world.
A
I
would
like
to
give
a
brief
look
into
the
future,
and
this
is
not
something
we
have
just
yet.
This
is
more
of
an
illustration
of
our
plans
ahead
and
that's
debugging,
and
one
of
the
challenges
with
web
assembly
is
source
level
debugging.
It's
not
something
that's
easy
to
do
today,
especially
not
in
envoy.
A
So
for
this
demo
we
prepared
on
an
example
on
how
we
think
this
is
going
to
look
like
and
the
way
it's
going
to
work,
we're
going
to
add
an
stl
debug
wasn't,
which
will
actually
attach
lldb
to
the
envoy
and
using
a
special
time,
can
also
source
level
debug
the
wasan
filter
itself.
So,
if
we'll
go
here
to
my
history
of
commands,
we
can
break
on
http
response.
A
A
A
A
A
B
B
And
with
that,
this
is
a
good
time
to
start
with
a
demo.
So
this
is
what
our
demo
environment
looks
like.
We've
got
two
clusters:
they
both
have
an
istio
mesh
installed
on
them,
and
each
of
them
has
about
half
of
the
istio
book
info
example
installed.
So
the
cluster
on
the
left
that
which
we're
calling
the
management
cluster
has
reviews
v1
and
v2
the
cluster
on
the
right
has
reviews
v3.
For
example.
B
Both
clusters
are
managed
by
glue
mesh
in
what
we
call
a
virtual
mesh,
so
it
acts
as
one
logical
mesh
which
just
makes
it
a
little
easier
to
to
manage.
So,
let's
jump
right
into
the
terminal
here,
just
to
kind
of
see
what
this
looks
like
I'm
running
canines
here
and
you
can
see
on
the
left.
We've
got
our
management
cluster
and
on
the
right,
we've
got
our
remote
cluster
note
that
we've
got
some
things
running
just
in
one
cluster
like
product
page
and
some
things
running
on
the
second
cluster.
B
Like
the
details,
one
thing
I'd
like
to
call
attention
to
before
we
jump
into
our
code.
Editor
is
that
we've
got
a
wasm
deployment
here
for
our
ratings
service,
where
we're
exposing
some
metrics,
I'm
just
taking
a
quick
look
at
what
this
looks
like
you
can
see
that
we've
defined
our
webassembly
filter,
I've
actually
built
and
deployed
and
uploaded
this
to
webassembly
hub
ahead
of
time.
Just
so,
we
can
save
a
little
bit
of
time
on
the
demo
and
you've
already
seen
how
all
that
works
in
our
previous
demo,
and
then
you
can
see
here.
B
B
Okay,
so
jumping
into
the
actual
code
here
a
bit
now
we
can
see
that.
Well,
I
guess.
First,
let's
start:
what
does
this
filter
do?
So
this
is
a
webassembly
filter,
written
in
rust
and
it's
it's
pretty
basic.
We're
kind
of
using
this
as
an
example
to
show
the
different
ways
you
can
debug
things,
but
essentially
it
will.
B
So
we're
going
to
be
discussing
three
different
ways:
we
can
kind
of
debug
here.
Some
of
them
are
suitable
for
production.
Some
of
them
are
more
suitable
for
a
development
environment.
First,
let's
talk
about
debug
logs,
and
this
is
one
of
those
things
that's
a
little
bit
more
appropriate
to
use
in
a
development
environment.
B
B
So
what
does
this
actually
look
like?
Let's
jump
back
to
our
terminal
here?
Okay,
so
we
can.
We
can
clear
out
the
remote
cluster
get
a
little
bit
more
space,
because
we're
kind
of
focusing
on
the
cluster
that
has
the
glue
mesh
management
plane
installed
on
it,
just
be
aware
that
this
is
a
multi-cluster
environment.
B
B
And
just
to
kind
of
show
you
how
that
works,
if
you're
not
familiar
with
the
envoy
logging
api,
we're
just
doing
a
simple
post
to
slash
logging
and
we're
specifically
cranking
up
the
component,
wasn't
to
debug
level.
So
you
can
see
here
everything
else.
All
of
the
other
components
are
still
left
at
warning
and
then
here
at
the
bottom,
you
can
see.
Wasm
is
up
to
debug.
B
Now
that
wasm
is
at
the
debug
level,
we
can
make
a
few
requests.
So
how
this
is
going
to
work
is
we're
going
to
exec
execute
a
curl
request
from
the
product
page
going
into
the
ratings
page
or
the
rating
service?
I
should
say
so.
This
rating
service
is
going
to
be
the
one
that
has
our
filter
installed
or
it
already
has
our
filter
installed.
B
You
can
see
on
http
response
body,
which
is
what
we
saw
previously
in
our
code,
and
then
you
can
see
the
body
gets
printed
out
here.
This
is
the
body
of
the
response,
and
finally
you
can
see
the
review
which
we've
calculated
as
part
of
our
filter,
just
jumping
back
to
our
filter,
real
quick
kind
of
tighten
that
together,
you
can
see
on
http
response
body
which
we
just
saw
in
our
logs.
B
You
can
see
the
word
bodies
printed
out
the
actual
body
itself
and
then
finally
down
here,
you
can
see
the
log
level,
so
that's
the
first
way
in
order.
We,
in
order
for
us
to
debug
things
in
a
complex
environment.
Again,
like
I
said,
debugging
is
definitely
something
that
you
want
to
do
in
a
local
or
dev
environment.
It's
not
really
well
suited
to
use
in
production.
B
There
is
a
performance
impact,
so
if
you
want
to
do
more
logging
at
the
production
level
at
high
scale,
without
impacting
your
performance,
how
we
do
that
is
something
called
access
logging,
so
for
access
logging.
How
it
works
in
envoy.
Is
it's
a
little
interesting?
So
we
we
set
a
property
in
our
case
we're
calling
it
average
reviews
and
the
average
reviews
property
is
a
filter
state
object
that
we're
setting
for
envoy
by
itself.
B
So
what
does
this
access?
Log
yaml
look
like?
How
do
we
configure
exactly
what
gets
logged
and
what
we
want
to
look
at.
So
what
we're
going
to
do
is
take
a
quick
look
back
in
our
terminal.
We're
going
to
look
at
this
access
log
record,
and
this
is
the
customer
resource
I
was
talking
about
earlier.
You
can
see
here
we're
only
applying
it
to
requests
on
the
path,
slash
rating,
slash
one.
We
are
applying
it
to
both
clusters
and
you
know
you
could
scale
this
up
to.
B
B
That's
because
our
enterprise
networking
pod
exposes
a
glue
mesh
api
for
monitoring
this
for
observability
purposes.
We're
then
going
to
call
that
api,
which
is
the
slash
observability
logs
and
we're
going
to
watch
it.
So
this
is
a
live
stream
that
we're
going
to
keep
open
and
then
finally,
we're
just
going
to
make
a
few
more
requests
again
same
request.
B
B
Maybe
I
shouldn't
have
said
so
many
requests,
but
here
we
go
filter
state
objects.
So
one
thing
to
note
is
it
is
of
bytes
value
here
and
that's
because
our
wasm
filter
didn't
actually
know
the
data
type
when
it
was
saving
it.
We
just
saved
it
as
bytes,
but
it's
worth
noting
you
can
see
here
that
it's
nc41
is
the
value
and
that's
just
the
byte
value.
B
So
if
I
get
out
of
this
and
then
I
do
nc41
and
just
pipe
it
to
base64,
decode
and
echo
that
result
back
out
again,
you
can
see
that's
4.5,
which
is
the
4.5
stars
average
review
that
we
calculated
in
our
service.
So
this
is
something
that
we've
piped
through
from
our
filter,
that
gets
executed
on
the
request
path,
but
it's
handled
by
this
access
lock
access,
logging
architecture,
which
is
you
know,
architected,
so
that
it
can
be
run
on
the
data
path
in
production
at
scale
without
crippling
your
performance.
So
this
is.
B
This
is
really
handy,
and
this
is
something
you
can
leave
on
in
a
real
production
environment,
which
is
great
so.
Lastly,
the
last
thing
we're
going
to
talk
about
is
metrics,
so
I'm
going
to
jump
back
to
the
code
for
a
sec
and
we
already
talked
about
our
logging
and
we
already
talked
about
our
access
logging.
B
But
the
other
thing
that
we've
done
in
this
filter
is
we've
defined
some
custom
metrics.
You
can
see
up
here
in
line
17
and
18.,
so
we've
got
a
metric
for
when
the
json
that
we're
parsing
in
the
filter
is
parsed,
okay,
which
we're
calling
okay
and
then
we've
got
one
for
when
the
parsing
fails
and
they're
defined
up
here
at
the
top,
and
then
you
can
see
down
here
where
we're
executing
them.
B
If
it's
a
success,
we're
doing
record
metric
metric,
okay
and
then
right
here
at
the
bottom,
when
it's
a
failure,
we're
going
to
record
a
failure
and
the
great
thing
about
these
metrics
is
that
they're
exposed
as
your
standard
envoy
metrics.
So
if
we
jump
back
to
our
terminal
here,
let's
just
exit
some
of
these
guys
and
get
more
space.
B
Okay,
so
we
should
be
able
to
curl
localhost,
fifteen
thousand,
slash
stats
and
then
we're
just
gonna
grab
for
debug
filter,
which
is
part
of
our
stats.
So
you
can
see
here:
we've
got
two
error,
requests
recorded
and
ten
okay
requests,
and
these
are
the
two
metrics
that
we
define
in
our
filter.
If,
for
example,
I
make
a
good
request
to
ratings
v1.
B
And
then
I
look
at
the
stats
again,
you
can
see
it's
gone
from
10
to
11..
Similarly,
if
I
make
a
request
to
a
bad
url,
that's
not
the
accepted
ratings
one,
and
then
we
look
at
the
stats
again,
you
can
see
it's
gone
from
two
to
three
and
the
great
thing
about
these
metrics
is
that
they're
first-class
citizens
in
envoy
stats.
So
you
can
export
these
to
prometheus.
You
can
get
them
in
a
graffana
dashboard
where
you
can
set
up
alerting
on
them
depending
on
how
important
they
are.
B
You
know
this
is
just
a
really
powerful
tool,
especially
for
something
in
production
that
you
want
to
just
keep
an
eye
on
and
set
alerting
to.
This
is
this
is
great,
so
in
summary,
we've
looked
at
how
you
can
attach
a
debugger
to
do
dev
level.
Debugging
we've
looked
at
how
you
can
look
at
debugger
logs
inside
of
your
filters.
We've
also
looked
at
more
production,
appropriate
use
cases
like
access,
logging
and
metrics,
which
you
can
use
in
your
clusters
at
scale.
B
We've
looked
at
the
entire
life
cycle
of
a
wasm
filter
of
how
you
can
go
about
building
it.
How
you
can
publish
it
to
a
registry,
how
you
can
discover
filters
that
other
people
have
written
and
published
up
to
the
registry
and
how
you
can
deploy
it
across
your
cluster.
We've
highlighted
the
ease
of
use
of
all
of
this
throughout
the
ecosystem,
as
well
as
the
various
languages
you
can
use
to
write
these
filters
in,
and
we've
shown
you
that
we've
given
you
the
tools
of
how
to
do
this
in
a
multi-cluster,
multi-mesh,
environment.