►
From YouTube: Cloud-Native Building Blocks: An Interactive Envoy Proxy Workshop - Adam Sayah & Jim Barton, Solo.io
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Cloud-Native Building Blocks: An Interactive Envoy Proxy Workshop - Adam Sayah & Jim Barton, Solo.io
Envoy Proxy is a foundational layer for many of the innovations propelling the Kubernetes community, including service meshes and cloud-native API gateways. But many engineers understand it only as a black-box, hidden by simplifying levels of abstraction. The purpose of this workshop is to provide a hands-on workshop that will bridge those gaps in Envoy understanding. Participants will explore first principles regarding Envoy architecture, filter chains, and a day-in-the-life of a request. Users will then put those principles to work interactively. Every participant will have access to a computing environment via their web browsers to a Kubernetes K3s platform provisioned with Envoy and supporting tools. From there, users will explore the life of a request through a maze of transforms, custom processing with WebAssembly, and request routing. They will further learn to employ standard Envoy tools like metrics, access logging, and the Tap filter to solve real-world problems.
A
All
right,
good
morning,
everyone,
buenos
dias-
I
I
don't
know
about
you
but
adam,
and
I
talk
about
envoy
and
technologies
built
on
top
of
envoy
to
people
all
the
time
and
for
the
past
two
years.
Most
of
that
talking
has
been
to
you,
know:
two-dimensional
people
on
the
other
side
of
the
zoom
meeting,
and
so
to
see.
This
many
people
here
in
three-dimensional
form
is,
is
pretty
exciting
for
us.
A
We
are
going
to
be
talking
about
envoy
proxy
and
specifically
we're
going
to
be
talking
about
it
in
the
context
of
a
hands-on
workshop,
that's
going
to
give
you
the
opportunity
to
to
get
your
hands
dirty,
just
a
bit
to
get
a
taste
of
what
using
raw
envoy
proxy
is
is
like.
So,
if
you're
interested
in
following
along
with
the
hands-on
exercise,
you
know
get
your
laptop
out.
If
you
have,
if
you
have
chrome
installed
on
your
laptop
we've,
had
we've
had
great
results
from
chrome
with
this,
with
this
particular
workshop.
A
Occasionally
there
can
be
issues
with
with
other
browsers,
so
yeah,
so
absolutely
get
that
fired
up
and
we'll
give
you
we'll
give
you
some
instructions
for
for
for
getting
connected
to
that
in
just
in
just
a
bit
before
we
start
into
the
actual
hands-on
workshop
part.
What
we
want
to
do
is
is
just
lay
a
little
bit
of
groundwork
for
for
for
who
we
are
and
what
is
envoy
so
so
my
name
is
jim
barton.
I
am
a
field
engineer
with
solo.io.
B
A
Yep,
so
if
you,
if
you
have
questions
over
the
course
of
the
of
this
session,
what
we'd
encourage
you
to
do
given
the
size
of
the
audience
and
the
fact
that
a
large
percentage
of
it
is
remote?
What
we'd
like
to
do
is
encourage
you
to
get
onto
the
the
session
chat.
You
can
do
that
by
following
this
bitly
link
up
here.
Bit.Ly
slash
envoy
dash
chat,
and
we
have
one
of
our
solo
colleagues
here
somewhere
alex
over
here
stage
right
heading
in
the
corner,
yep
in
the
corner.
A
We
keep
him
back
there
in
the
corner
and
he
will
be.
He
will
be
happy
to
answer
your
questions
just
go
to
the
q
a
tab
and
I
think
that
can
work
as
kind
of
a
quasi-chat
mechanism.
If
you
have
issues
we,
we
hope
that
you
won't,
but
but
just
in
case
alex
will
be
there
to
answer
your
questions.
We
also
there's
a
lot
of
content
in
the
next
90
minutes,
and
so
we
hope
to
have
some
time
for
interactive
questions,
but
let's,
let's
save
those
for
the
end.
A
A
They
they
had
this
thing
called
envoy.
They
donated
it
to
the
cncf
in
2017.,
it
gained
popularity
very
rapidly
and
in
2018
it
graduated
from
from
as
a
cncf
project.
So
a
lot
of
success
very
quickly
and
since
that
time
its
adoption
has
really
exploded
across
the
the
enterprise
computing
universe.
So
you
know.
Why
is
that?
Why
is
it
that
envoy
has
become
so
popular
well
number
one?
It
was
built
to
be
extraordinarily
fast
and
scalable,
it's
implemented
in
c
plus
plus.
A
I
know
that
we
use
it.
We
talk
to
customers
every
day
who
have
who
are
managing
hundreds
of
millions
of
transactions
per
day
in
mission,
critical
applications,
all
on
top
of
fleets
of
envoy
proxies
and
so
very
fast,
very
scalable.
It's
also
very
comprehensive.
It
works
at
both
l4
and
l7
being
able
to
manage
and
route
requests
in
with
with
those
protocols.
A
It's
really
built
from
the
ground
up
to
work
in
a
dynamic
services
environment.
So
an
environment
like
kubernetes,
where
services
can
be
ephemeral,
they're
going
up
they're
going
down
new
things
are
being
added:
it's
not
a
single
static
environment
with
a
collection
of
you
know,
10
or
12
software
monoliths
behind
it.
It's
actually
designed
for
a
dynamic
environment,
it's
also
built
from
the
ground
up
to
be
dynamically
configurable.
A
So
one
of
the
things
that
adam
will
talk
about
a
bit
later,
as
we
get
deeper
into
the
workshop,
is
the
fact
that
you
can
use
a
it's.
Not
just
you
know,
traditional
api
gateway
technology.
Traditional
proxy
technology,
is
based
on
the
static
configuration
file
right.
So,
if
you
change
that
file,
you
want
to
change
a
route
or
something
like
that.
A
Often,
what
you
have
to
do
is
balance
balance
your
api
gateway
in
order
for
those
changes
to
take
effect
envoy
was
designed
from
day
one
to
be
unique
in
that
it
works
with
a
dynamic
control
plane.
So
in
other
words,
you
can
have
a
control
plane
that
serves
up
configuration
as
as
situations
change
on
the
ground,
as
new
policies
are
added,
as
new
services
come
in
or
go
away,
you
can
have
those
those
policies
served
up
dynamically
to
your
proxy
without
having
to
balance
anything.
A
So
it's
designed
to
be
that
way
from
from
day
one.
It's
also
designed
to
be
a
very
extensible
environment.
So
envoy
was
built
from
day
one
to
work
on
a
a
filter
chain
architecture.
So
if
you
go
to
the
envoy
proxy
dot,
io
website
you'll
see
an
entire
library
of
filters
that
you
can
use
to
apply
various
policies
and
routing
techniques.
To
your
to
your
request
and
we'll
be
looking
at
a
number
of
those
today
as
we
go
through
as
we
go
through
this
exercise
all
right,
it's
also
very,
very
observable.
A
So
out
of
the
box,
you
have
integrations
with
things
like
prometheus
and
grafana,
which
we'll
show
you
today
is
also
an
extensive
collection
of
metrics
that
are
published
from
from
envoy.
So
why
envoy
proxy
for
api
infrastructure?
There
are
clearly
a
number
of
alternatives
that
are
out
there
open
source
alternatives
like
envoy
that
have
been
out
there
for
years.
Why
envoy?
For
me,
it
really
boils
down
to
four
reasons.
A
Number
one,
and
I
think
the
most
important
one
from
my
standpoint
is
the
large
vibrant
community
that
that
that
supports
and
sponsors
of
envoy
proxy
right.
So
you
look
at
you
know
the
the
the
list
there
on
the
screen
comes
from
envoy
proxy.oh,
just
a
sample
of
the
companies
who
have
adopted
and
and
promote
envoy
proxy.
It's
also.
A
We've
already
talked
about
the
fact
that
it's
extensible
it's
dynamically
configurable,
but
also,
I
would
say,
most
importantly,
it
is
something
that's
battle
tested,
so
envoy's
been
chosen
as
the
foundation
for
a
lot
of
the
cloud
native
application.
Networking
technologies
that
are
growing
very
quickly
right
now,
so
technologies
like
istio
are
based
on
envoy
proxy
as
the
side
car
that
manages
traffic
going
in
and
out
of
your
of
your
service
pods.
A
Also,
multiple
api
gateway
technologies
like
like
blue
edge
from
solo
and
others
are
are
built
on,
are
built
on
envoy
proxy
as
well.
So
it
is,
it
is
at
this
point.
It
is
definitely
battle
tested.
It
is
something
that
you
can
that
you
can
put
into
production
environments
and
when
it's
properly
configured
it
will,
it
will
work
as
expected.
Okay,.
A
So
what
we're
going
to
do
today
is
a
hands-on
workshop
if
you'd
like
to
follow
along
that
would
be.
That
would
be
great.
I
think,
you'll
get
a
lot
out
of
that
out
of
that
process.
If
you
want
to
just
watch,
we'll
actually
be
we'll
actually
be
doing
everything.
That's
going
to
be
part
of
the
workshop
up
on
the
big
screen
here,
so
you
should
be
able
to
follow
along
in
that
fashion
as
well.
A
But
what
I'd
like
you
to
do
if
you
are
planning
to
follow
along,
go
ahead
and
navigate
to
that
bigly
link.
That's
up
there
in
red
on
the
screen
right
now
bit
dot.
L
y
slash
envoy
dash
workshop.
That's
going
to
take
you
to
the
instruct
platform.
I
don't
know
how
many
of
you
have
used
instruct
in
the
past.
It's
a
really
really
effective
platform
for
these
kinds
of
large-scale
interactive
sessions.
In
fact,
I
think
there's
some
instruct
people
in
the
audience
just
want
to
give
you
a
shout
out
there.
It's
very
solid
technology.
A
We
use
it
for
a
lot
of
our
workshops
and
big
events
like
this,
so
yeah
so
go
ahead
and
navigate
there.
Bit.Ly,
slash
envoy,
dash
workshop
there'll,
be
a
provision
compute
environment
for
you
there.
If
you
have
a
browser
and
an
internet
connection,
you
should
be
able
to
connect
to
it.
We're
going
to
go
through
five
exercises
today.
We're
going
to
start
off
with
just
some
envoy
basics.
A
Adam
is
going
to
cover
a
lot
of
the
core
principles
of
envoy
and
give
you
a
couple
of
exercises
to
to
sort
of
reinforce
those
we're
going
to
talk
about
http
connection
manager,
which
is
one
of
the
foundational
filters
in
envoy
that
manages
routing
of
traffic
to
to
services.
We're
going
to
talk
a
bit
about
security
and
then
we're
going
to
talk
about
observability,
which,
when
you're
talking
about
managing
collections
of
microservices
observability
becomes
a
critical
component.
A
Adam
is
going
to
discuss
that
and
as
well
we're
going
to
walk
you
through
a
a
live
debugging
exercise.
So
hopefully,
all
the
principles
you're
going
to
learn
in
the
next
in
the
next
few
minutes,
we're
going
to
be
able
to
take
those
and
then
solve
a
real
common
problem
that
you
see
when
you're
working
with
envoy,
proxy
and
adam
is
going
to
walk
us
through
that,
as
well.
A
Now
as
a
bonus
for
the
first
time
anywhere
in
the
world,
we
are
we're
going
to
be
offering
a
a
certification
based
on
the
results
of
this
workshop.
It's
an
envoy
foundation,
certification.
This
is
something
we've
done
quite
a
bit
with
other
open
source
technologies
like
istio
and
ebpf,
where
we
offer
certifications
at
different
levels.
This
is
the
first
one
of
these
we've
done
with
envoy,
so
we
have
a
foundational
certification.
A
A
Perhaps
you've
seen
a
screen
like
this.
At
this
point,
you
shouldn't
need
to
enter
an
email
address,
or
anything
like
that.
You
should
just
be
able
to
click
the
button
to
add
this,
to
your
study
room
once
you've
done
that
you
should
see
an
interface
that
looks
something
like
this.
So
click
through
the
my
exclusives
button
and
then
you'll
see
the
intro
to
envoy
proxy
instructrack
and
simply
click
on
the
on
the
view
track
button
there,
and
that
should
take
you
to
a
screen.
A
Something
like
this
one
and
at
this
point
we'll
actually
start
working
alongside
you.
So
I'm
going
to
go
ahead
and
start
this
track
up.
All
right
do
not
watch
the
video
that's
on
there.
That's
me
blabbering
on
for
about
20
minutes
about
what
is
envoy
proxy.
Instead,
you
can
listen
to
me.
Blabber
on
in
person,
so
you'll
see,
there's
a
there's,
a
there's,
a
spinning
green
circle
down
there.
This
basically
means
that
the
environment
is
being
provisioned,
so
definitely
go
ahead
and
get
that
process
started.
A
A
All
right,
so
as
I
as
I
said,
while
we're
waiting
for
everyone's
environment
to
spin
up,
we
do
have
a.
We
do,
have
an
exam
we'll
offer
at
the
end
of
this,
we've
been
doing
certifications
now
at
solo.io,
for
over
a
year
on
a
number
of
popular
open
source
technologies,
istio
and
ebpf
being
two
notable
examples.
A
A
It's
just
a
google
form
and
we
need
a
unique
email
address
to
sort
those,
and
if
you
pass
the
test,
the
badge
will
be
issued
within
a
few
weeks
by
our
very
efficient
marketing
department
and
it
is
suitable
for
framing
or
putting
on
your
linkedin
profile,
whichever
you
prefer
all
right.
Also,
if
you
are
as
passionate
about
application
networking
as
we
are
at
solo,
if
you're
interested
in
api
gateway
and
service
mesh
technology,
we
are
always
hiring
and
we
would
love
to
chat
with
you
again.
A
A
B
All
right,
the
guys
in
the
back,
you
get
you
guys
able
to
see
the
the
terminal
here
just
a
thumbs
up.
Oh
awesome,
awesome.
Thank
you
all
right,
all
right
all
right,
so
thanks
jim,
for
this
amazing
introduction
to
why.
Actually
we
need
envoy
during
this
first
lap
is
mainly
we're.
Gonna
cover
the
basics
of
like
just
envoy
components
and
just
technology
itself.
B
I
guess
envoy,
everyone
is,
if
you
guys
came
here,
there's
two
either
there's
two
possibilities:
either
you
are
new
to
android
technology
and
want
to
just
understand
the
basics
of
envoy
itself,
which
is
great
or
there's
also.
Maybe
you
are
using
an
envoy
technology,
that's
embedded
into,
for
example,
istio
or
blue
edge
or
any
other
technology.
B
So
this
workshop
is
based
on.
We
try
to
simplify
it
enough.
So
it's
going
to
be
just
like
a
a
docker
stack,
a
docker
compose
stack.
It's
it's
going
to
have
couple
components.
One
demo
application
one:
a
graffana
and
primitives
installed
already
we're
going
to
have
envoy
and
we're
going
to
have
like
an
xod
server.
I'm
going
to
use
later
during
this
workshop,
but
something
to
to
notice
here
is
that
we
are
using
static,
configuration
and
jim
mentioned
earlier
envoy.
B
I
think
we're
ready
to
start
here.
Awesome
just
also
way
to
communicate
between
every
single
lab,
we're
going
to
give
a
couple
of
minutes,
for
you
guys
to
be
ready.
So
I'll
ask
you
guys
just
do
a
a
thumbs
up
just
for
me
to
know
that
you
guys
are
ready
to
continue.
So,
if
you
guys
are
ready
to
start
just
please
a
thumbs
up,
awesome
awesome
audience
all
right.
B
Let's
get
rolling
here.
First
step
is
to
just
start
the
stack,
we're
not
going
to
talk
about
envoy
configuration
at
this
point.
It's
mainly
to
get
your
demo
stack
example
running
and
to
do
this,
what
we're
going
to
do
we're
going
to
do
here
is
we're
going
to
set
up
the
workshop,
so
just
go
in
the
right
directory
and
then
we're
going
to
again
we're
going
to
use
a
docker
compose
here.
B
So
if
you
guys
want
to
take
a
look
at
the
docker
compose
configuration
super
straightforward,
we'll
have
envoy
itself
and
it's
going
to
be
mounting
some
files
and
we
don't
get.
We
don't
have
to
get
into
details,
but
it's
basically
mounting
the
basic
configuration
we're
going
to
going
gonna
be
modifying
every
time
and
restarting
right.
B
Then
it
has
an
upstream
service
which
is
just
a
demo
service
for
us
just
to
test
the
connection.
All
the
way
to
your
back
end
and
then
we
have
an
off
server
that
one
gonna
be
used
for
authentication
later
in
another
lab,
and
we
have
the
primitives
plus
grafina
stack
for
monitoring
and
also
we're
gonna,
see
that
in
in
the
next
lab,
all
right.
So
first
step
here,
just
starting
the
stack,
that's
pretty
much
it
for
that.
B
We're
gonna
do
a
docker
compose
up,
and
it's
probably
gonna
take
a
couple
seconds
here
to
to
pull
all
the
the
images
and
start
your
or
your
your
stack
there's.
Sometimes
some.
Maybe
if
you
guys
have
trouble
with
internet,
I
mean
either
use
your
your
data
or
keep
refreshing.
If
you
refresh
the
page,
you
won't
lose
your
session.
It's
fine!
You
know!
If
you
see
something
stuck
refresh
the
page,
try
to
not
do
it
often,
but
if
you
really
see
that
refresh
would
be
helpful.
Please
do.
B
Okay,
so
now
creating
the
services.
We
see
that
everything
is
done
here.
So
we
have
our
services
running,
do
a
docker
ps
and
we
see
a
couple
components
here,
ready
for
us
to
to
demo.
So
one
thing
the
first
step
here.
What
we
did
is
that
we
created
a
couple
components
with
envoy
itself,
which
used
a
basic
configuration
having
only
the
admin
interface.
Now,
what's
the
admin
interface,
it's
one
of
it's
basically
the
way
to
interact
with
envoy
from
an
administrative
administrative
standpoint
where
you
can
see
the
configuration.
B
If
you
want
to
see
the
admin
interface
configuration
click
on
android
config
there
on
top,
if
you,
if
you
click
there,
you'll
see
if
you
click
on
the
file
here,
that
is
the
bootstrap
configuration
we
use
for
android
right
now
and
we
see
to
configure
the
admin
interface.
We
just
have
to
set
up
like
a
a
port
and
an
address,
and
that's
it
now.
The
admin
interface
is
one
of
the
really
important
component
for
you
to
understand.
B
If
you
want
to
debug
android
now,
the
admin
interface
itself
sometimes
is
masked
right,
like,
for
example,
istio
and
other
technologies.
We
don't
do
it
in
blue
edge,
but
there's
some
technologies
that
mask
the
the
the
ad
interface
from
a
user,
because
it's
risky
using
an
ad
interface,
you
can
drain
listeners,
you
can
fail
health
checks.
You
can
really
interact
with
envoy
itself
in
dynamic
manner.
B
That
can
be
hurtful
to
your
system,
so
I
I
would
really
advise
to
understand
how
the
admin
interface
work,
but
not
expose
it
externally,
something
internal
to
just
check,
what's
going
on
right.
So
for
that,
there's
a
couple
things
to
really
be
aware
in
the
admin
interface
and
we're
gonna
check
them
later,
but
one
that
I
like
looking
at
every
time.
I
start
the
admin
interface
on
on
envoy
is
the
config
dump
right.
B
The
config
dump
is
basically
the
state
or
the
state
of
envoy
at
this
time,
especially
if
using
dynamic
configuration
configuration
pushed
by
a
server.
You
want
to
be
able
to
just
go
to
envoy
and
see
what
android
is
seeing.
What's
the
configuration
envoy
is
having
right,
so
config
dump
is
one
of
the
most
important
things
you're
going
to
see
in
the
admin
interface.
B
Another
thing
that
I
would
advise
they
can
look
at
is
clusters
and
listeners,
but
we
are
not
there
yet,
since
we
haven't
created
any
listener
or
cluster
okay,
but
we're
going
to
see
that
in
a
second
all
right
so
again,
admin
interface
super
important
we're
going
to
be
using
a
couple
times
in
the
in
the
in
the
first
labs
and
then
we're
going
to
try
to
switch
to
more
like
a
primitives
and
graph.
The
stack
for
metrics
later.
B
That
reminds
me
that
also
the
link
to
stats
is
really
important
too
you're
gonna
see
that
here
either
stats
or
stats
per
meters
that
just
you
know,
formatted
for
primitives,
but
it
will
allow
you
to
give
you
an
idea
of
like
why
what's
going
on
like
why
request
is
failing
and
things
like
that,
we're
going
to
see
that
later,
all
right
so
admin
interface.
Is
there
installed
so
now
next
step?
B
What's
the
one
of
the
most
important
component
in
envoy,
I
would
say
a
listener
all
right,
a
listener
in
envoy,
I'm
gonna,
just
switch
to
this
a
listener
in
envoy
is
basically
a
way
for
us
to
open
the
port.
Simplify
it
easily
is
a
way
for
us
to
open
a
report
in
envoy
and
be
able
to
interact
like
send
requests
there.
Okay
and
envoy
intercept
the
request
there
and
do
something
with
it:
either
right,
reroute
it
or
terminate
it,
and
so
on.
B
So
a
non-void
listener
is
basically
a
network
address
open
on
your
envoy.
So
let's
create
one
listener
for
envoy
here.
To
do
this.
What
we're
going
to
do
is
just
use
git
check.
Checkout
already
have
all
the
configuration
it's
going
to
get
messy
if
we
have
to
do
it,
you
know
manually,
so
we
use
git
to
kind
of
switch
configuration
from
a
lab
to
another.
In
this
case,
if
you
go
to
the
admin
interface
at
the
android
configuration,
we
see
here
that
we
have
only
the
admin
interface
configuration
now.
B
B
B
A
filter
is
the
one
processing
that
connection
and
that
request
there's
two
types
of
filters:
there's
the
tcp
filters.
We
deal
with
l4
type
level
where
we
can
just
do
a
kind
of
pass-through,
tcp,
proxy
somewhere
or
there's
some
l7
type
filter
that
will
be
able
to
attach
to
the
http
connection
measure
we're
going
to
be
talking
about
later.
In
this
example,
we're
just
using
a
simple
filter
called
direct
response
operating
at
the
l4
level.
You
see
here
it's
a
tcp,
it's
an
network,
it's
a
network
filter
and
what
it
does
here.
B
B
If
you
again,
if
you
want
to
check
the
config
dump,
you
should
be
able
to
see
the
listener
added
to
the
envoy
configuration
itself
not
only
in
the
static
file,
and
if
you
do
just
a
curl
here
we
get
hello
er
back
right.
So
at
this
stage
we
have
only
a
listener
and
we
have
a
filter
he's
taking
communication
and
returning
hello
world
all
right
now
time
to
one
okay.
Okay,
so
I
want
to
talk
about
something
before
something
really
important
envoy
and
jim
mentioned
earlier-
is
be
able
to
observe.
B
B
Okay,
now
we
talked
about
listeners.
We
talked
about
filters.
A
third
really
important
concept
in
envoy
is
envoy
clusters.
A
cluster
is
a
grouping
of
addresses
to
point
to
a
certain
destination.
Okay,
so
you'll
think
about
the
cluster
as
a
representation
of
a
back
end,
a
backend
service,
for
example.
Either
it
can
be
your
local
community
service
or
it
can
be
pointing
to
an
external
service
somehow,
but
basically
just
a
collection
of
ips.
B
That
envoy
can
use
to
interact
with
the
back-end
system.
In
this
case
earlier,
we
just
terminated
the
request
right
there,
but
this
time
we're
gonna,
you
know
we're
gonna
route
traffic,
all
the
way
to
our
back
end.
To
do
this,
we
again,
I'm
gonna,
check
out
this
time
lab
one
two
one,
three,
sorry,
and
if
you
go
back
to
the
android
configuration
this
time,
something
is
added
here,
which
is
a
cluster
okay.
A
cluster
definition
is
pretty
straightforward
here,
we're
just
pointing
to
a
dns
address
upstream
8080..
Appstream
again
is
a
reminder.
B
Just
a
demo
application.
We
installed
with
our
docker
compose
stack
okay,
so
here
we
have
a
backend
service.
Now
that
we
have
this
name
and
this
cluster
called
app
stream
defined.
Let's
define
the
routing
to
that,
and
I
mentioned
earlier
using
tcp
filters.
You
can
do
a
tcp
proxy
routing
all
tcp
to
back
end,
in
this
case
we're
using
the
tcp
proxy
filter
instead
of
the
direct
response
filter.
B
We
had
previously
right
so
here
we're
doing
a
pass
through
all
the
way
back
to
the
back
end
and
if
you
see
we're
just
referencing
the
cluster
upstream,
that
we
defined,
which
is
our
demo
application.
So,
let's
now
that
we
had
the
we
have
the
configuration
again,
let's
restart
envoy,
to
pick
up
this
and
let's,
let's
make
a
call
here,
we
are
going
to
make
a
call
to
our
backend
system.
B
There
you
go
so
here
we're
getting
hell
back.
Hello
back
is
coming
from
our
backend
system,
raw
tcp,
going
through
envoy
to
our
backend
system
that
returned
hello
back
okay.
So
that's
really
an
important
concept
to
understand
here
the
concept
of
clusters,
because,
if
ultimately,
if
you're
dealing
with
istio
or
you're
dealing
with
any
other
technology
behind
the
scene,
the
control
plane
is
transforming
a
set
of
like
kubernetes
servers,
for
example,
to
a
set
of
apis
that
envoy
in
the
sense
right.
B
So
if
you
see
that
your
envoy
is
not
able
to
interact
with,
let's
say
an
end
like
a
side
car
and
for
side,
car
not
able
to
interact
with
a
certain
service
first
thing
to
do
is
to
verify
if,
if
the
cluster
is
defined,
there
does
envoy
know
about
that
specific
service
you're
trying
to
reach
so
something
to
keep
in
mind
all
right.
Just
I
want
to
show
you
certain
diagrams.
If
you
want
to
just
you
know,
look
at
it.
B
You
can
just
expand
this
on
the
side,
and
here
is
kind
of
the
example
that
what
we
did
during
the
lab
one,
what
we
did.
We
have
a
client
talking
to
a
listener
that
we
just
opened
on
the
port.
8000,
it's
going
to
talk
to
a
set
of
filters.
It
can
be
one
or
many
right,
it's
a
filter
chain,
so
you
can
chain
multiple
filters
to
do
multiple
things,
one
on
top
of
the
other
and
then
route
to
your
back-end
service,
all
right
so,
and
one
last
important
thing
here
again.
B
If
you
have
a
cluster
defined,
you
need,
you
can
check
the
ips
that
actually
the
endpoint
as
envoy
is
trying
to
use
if
you
go
back
to
yet
the
admin
interface
just
go
back
here
with
the
arrow
and
this
time
going
under
clusters,
so
we
can
find
it
here,
cluster
up
top.
Second
one:
oh
thank
you
all
right
clusters.
In
this
now
we
see
that
we
have
an
upstream
cluster
defined,
but
it's
really
important
here.
We
see
the
end
point.
Also
we
see
this
172
1805
defined.
B
This
is
our
ip
that
we're
trying
to
reach
right.
This
is
our
back
end
service,
something
really
too
important
to
to
notice
like
a
deep
active
again,
if,
even
even
if
you
have
the
cluster
defined,
try
to
check
the
cluster
path
in
the
admin
interface
or
the
metric
right.
Try
to
see
if
the
end
points
are
defined
right.
Okay,
I
have
the
upstream
cluster,
but
do
I
have
a
an
end
point?
Do
I
have
an
ip
defined
that
talks
to
this
service?
B
B
A
Very
good,
thank
you
adam,
so
that
was
a
great
introduction
to
to
the
basics
and
the
core
concepts
of
envoy
proxy.
If
you
haven't
already
go
ahead
and
hit
the
green
check
button
at
the
end
of
the
first
exercise,
that
will
hopefully
say
everything
is
correct
and
we'll
load
up
the
next
challenge,
which
is
we're
going
to
talk
about
http
connection
manager.
So
adam
worked
with
a
couple
of
examples
with
with
tcp,
and
he
also
in
some
of
his
examples
used.
You
know
direct
responses
straight
from
the
proxy.
A
There
was
not
even
a
back-end
service
that
was
that
was
handling
the
response.
That's
not
the
most
common
scenario
when
at
least
with
our
customers,
what
we
see
using
envoy
proxy,
very
commonly
what
we
see
is
people
who
are
using
http
connection
manager
to
be
able
to
process
requests
at
layer
seven
to
be
able
to
apply.
You
know,
let's
say
transformations,
to
apply
a
policies
based
on
headers
and
that
sort
of
thing,
and
so
you
need
the
l7
access
in
order
to
do
that.
A
So
envoy
has
a
l7
capability
and
the
core.
The
core
of
that
is
something
called
http
connection
manager,
and
so
that's
what
we're
going
to
explore
in
this
in
this
second
exercise.
So
what
we're
going
to?
What
we're
going
to
do
here?
Let's
go
ahead
and
move
into
the
correct
directory
and
check
out
check
out
lab
2-1,
and
so
I
just
want
to
show
you
first
graphically
what
we're
going
to
be
doing
this
time.
So
it's
a
little
different
right.
We
still
have
a
client.
A
We
still
have
a
listener
at
http
8000.
Now
we're
going
to
be
going
through
the
http
connection
manager
is
the
only
filter
in
our
filter
chain.
It's
going
to
route
to
our
upstream
service,
which
is
simply
going
to
give
us
back
a
a
hello
world
example
of
sorry
hello,
world
response.
So
let's
take
a
look
at.
A
So
here
is
here's
what
we've
added
here,
so
you
can
see
the
http
connection
manager
filters
specified
and
here
are
the
real,
the
real
key
bits
right
here
in
in
this
section,
you
can
see
we've
we
have.
We
have
identified
a
virtual
host
here
that
we're
calling
upstream
it
is
listening
on
domain
hello.envoyproxy.io.
A
So
if
it
sees
that
in
the
host
in
the
host
header,
that's
going
to
be
like
passing
the
first
gate
for
this
filter
to
to
fire,
you
can
see,
we
also
have
a.
We
have
a
route
defined,
okay,
so
we're
basically
saying
any
request
that
has
a
prefix.
The
path
prefix
begins
with
hello.
We
want
to
capture
that
we
want
to
capture
that
request
and
we
want
to
take
that
request,
and
then
we
want
to
route
it
to
this
cluster
called
upstream,
which
is
basically
the
little
hello
world
app.
A
That's
written
in
python.
That's
running
behind
the
scenes!
Okay!
So
that's
that's
pretty
much
all
we're
doing
for
this
for
this
first
example.
So,
let's
go
back.
Let's
go
back
here.
We've
already
applied,
we've
already
applied
that
config.
Now,
what
do
we
need
to
do
because
we're
not
using
a
dynamic
control
plane
we're
just
using
a
static
configuration
file
every
time
we
make
a
change
like
this?
A
We
have
to
restart
envoy
to
pick
up
the
new
config,
as
we
said
before,
adam's
going
to
talk
a
bit
about
control
planes
more
in
the
in
the
end
and
you'll
get
some
sense
of
the
value
that
they
can
add
here
so
you'll
notice.
Now
our
curl
command
is
we
don't
have
the
http
0.9
requirement
before,
because
this
is
not.
This
is
not
tcp.
This
is
an
http
connection.
You
can
see
it's
going
to
local
host
8000
with
with
a
path
of
hello.
A
You
can
also
see
we're
specifying
the
host
header
hello.envoyproxy.io
and
when
we
do
that
right,
we
get.
We
get
a
hello
world
back
just
as
expected.
Now
you
know
just
to
show
you
kind
of
a
a
counter
example.
Let's
say
we
didn't:
have
the
host
proxy
specified
properly?
What
do
you
expect
in
that
case
the
filter
is
not
going
to
match
and
you're
going
to
see
what
404
404
excellent.
Well,
you
didn't
actually
see
it,
but
if
we
do
this,
then
you'll
actually
see
there's
a
404.
A
If
we,
if
we
don't
specify
the
host
header
correctly.
Okay,
all
right
now,
as
we've
said
before,
really
a
core
bit
of
value
from
envoy
is
observability
and
metrics,
and
so
not
surprisingly,
you're
going
to
see
that,
with
with
this
example
as
well,
so
adam
showed
you
just
briefly
the
admin
interface,
and
so
you
can
go
in
here
and
hit.
You
know,
hit
the
stats
interface
and
you
can
actually
see
this
whole
raft
of
metrics
here.
A
Of
course,
you
can
also
we
can
just
access
this
via
curl
and
then
just
filter
out
the
the
bits
that
we
that
we
want
to
see,
and
so
in
this
case
you
can
see
here
here
is
a
metric
that
indicates,
you
know,
there's
been
one
request.
That's
been
completed
successfully
with
this
since
envoy
has
restarted.
If
we
go
off
and
let's
say
we
run
the,
we
run
it
again
right,
we
run
the
curl
command
again
the
correct
one,
and
we.
A
And
then
we
we
take
a
look
at
that
metric
again.
Not
surprisingly,
you
can
see
that
metric
has
been
updated
to
two
from
one,
so
so
the
definitely
as
you
as
you
get
deeper
into
envoy.
If
you
haven't
been
there
before,
we
definitely
encourage
you
to
spend
some
time
encouraging
understanding
this
vast,
metrics
library
that
envoy
publishes
okay,
there's
also
a
prometheus
instance,
as
adam
talked
about
that
is
that's
included
with
this
example.
A
We're
not
going
to
go
into
this
deeply
right
now
adam's
going
to
cover
that
in
lab
4
on
observability,
but
you
can
see
if
we
wanted
to.
We
could
go,
take
a
look
and
actually
see
this
same
metric.
You
know
graphed
out
using
using
our
little
prometheus
setup
that
we
have
in
this
example
as
well.
Okay.
A
So
let's,
let's
run
our
check
on
that
and
oh
wait.
Oh
I
said
let's
not
run
our
check
on
that,
because
we're
not
done
yet
all
right.
I
got
to
the
bottom
there.
I
thought
it
was
at
the
end
of
the
lab
all
right,
so
we're
going
to
go
through
one
other
example
with
http
connection
manager.
So
what
we
showed
you
first
was
just
a
very
simple:
you
know:
hey
here's,
the
request
route
it
to
this
back-end
server.
You
know
it
works
everyone's
happy
now
we're
going
to
deal
with
something.
A
That's
a
slightly
more
real-world
situation,
which
is
let's
say
our
back-end
service
is
unreliable
right.
In
fact,
let's
say
it's
really
unreliable
in
our
case,
we're
going
to
simulate
a
service
that
actually
fails
80
of
the
time.
Hopefully
you
don't
have
any
of
those.
But
if
you
do
you
can
you
can
appreciate
what
we're
going
to
do
here?
So
what
we're
going
to
do?
A
A
A
If
it
sees
the
header
unreliable
set
to
true,
then
it's
going
to
fail
80
of
the
time,
hopefully
your
you
know
app
developers
you
work
with
are
a
little
smarter
than
that,
but
so
let's
go
ahead
and
try
this
out,
and
so,
if
we
run
this
curl
here
with
unreliable
set
to
true
you'll,
see
that
80
percent
of
the
time
you're
going
to
get
back
a
500
internal
server
error.
Now
some
of
you
will
actually
see
that
request
succeed.
A
A
B
A
Somewhere
there,
it
is
yep
skips
right
over
that
all
right.
So
you
want
to
be
sure
before
you
do,
that
you
want
to
check
out
lab
2-2,
which
will
be
the
the
retry
part
of
this
lab
all
right.
So
once
you
switch
over
to
that
now,
you
go
back
to
the
envoy,
config
and
you'll,
see
you'll
see
there
is
a
change
and
the
change
is
right
here.
So,
within
the
context
of
this
http
connection
manager,
config,
we
have
added
this
retry
policy
right
here.
A
You're
noticing
we're
only
retrying
on
certain
conditions,
so
envoy
has
a
number
of
conditions
that
you
can
specify.
You
can
also.
You
can
also
aggregate
them
into
into
a
list,
but
there
are
only
certain
connections
that
we're
going
to
retry
on,
in
this
case,
we're
only
going
to
retry
on
500
class
internal
server
errors
and
then
we're
also
going
to
limit
the
number
of
retries.
So
we're
only
going
to
allow
10
retries.
If
we
see
more
failures
than
that,
then
then
we're
going
to
punt
there's
a
whole
host
of
other
things.
A
A
A
A
A
Yeah
yeah,
I
think
that's
a
good
idea.
So,
let's
yeah,
let's
put
some
space
in
here,
you
can
see
it
more
clearly.
If
we
run
this
again
all
right,
so
you
can
see
the
request
returned
true
and
actually
at
that
time,
of
course
it
worked
the
first
time
all
right.
Well,
you
know
one
out
of
every
five
times.
That's
going
to
happen.
So
let's
try
again.
A
A
A
So
if
we
take
a
look
at
that,
here's
a
here's,
a
set
of
metrics
that
give
us
a
lot
of
useful
information
about
what
we're
seeing
you
can
see.
First
of
all,
at
the
bottom
of
that
list,
we
see
that
there's
a
total
of
five
requests
that
have
been
issued
to
this
upstream
since
the
envoy.
Since
the
envoy
proxy
was
restarted.
You
can
also
see
that
of
those
of
those
five,
two
of
them,
two
of
them
succeeded
or
sorry,
three,
that's
right!
We
ran
it
right.
We
yeah
right.
A
A
You
can
also
see
that
there
were
a
number
of
retry
so
right
here
you
can
see
the
count
of
the
number
of
500
responses
that
we
got
and
the
number
of
retries.
So
each
one
of
these
elements,
this
this
http
connection
manager
filter,
is
emitting
metrics
that
are
associated
with
with
all
of
these
capabilities,
and
you
can
see
we're
seeing
those
we're
seeing
those
here
both
both
in
the
aggregate
as
well
as
as
well
as
broken
down
by
particular
error
codes
that
are
being
returned
all
right.
A
A
Thank
you
adam
all,
right,
cool,
great
great
and
so
we're
going
to
talk
a
little
bit
about
securing
traffic
using
envoy
and
we're
going
to
discuss
two
separate
topics
here.
One
is,
you
know,
really
really
basic
something
that
every
every
one
of
you,
no
doubt
has
probably
done,
which
is
you're
going
to
we're
going
to
set
up
tls
configuration
to
encrypt
the
communication
channel
between
the
downstream
client
and
the
proxy.
A
So
we're
going
to
take
a
look
at
that
and
then
we're
also
going
to
investigate
a
second
envoy
filter,
which
is
the
x
off
z,
filter.
So
we're
going
to
add
in
a
little
custom
authorization
service
into
the
mix
and
we're
going
to
configure
envoy
to
con
to
properly
authorize
our
request
before
we
actually
go
off
and
hit
the
upstream
service.
So
we'll
show
you
how
to
do
that
with
envoy
as
well.
A
A
So,
let's,
let's
go
to
the
correct
directory:
let's
check
out
the
the
configuration
for
this
exercise,
and
so
here
is
what
we're
going
to
do
in
graphic
form,
we're
again
going
to
have
a
downstream
client
we're
going
to
be
talking
to
a
different
listener.
This
time
we're
going
to
be
talking
to
an
https
listener,
that's
listening
on
a
different
port
8443!
A
This
communication
channel
is
going
to
be
encrypted
and
then
it's
going
to
delegate
similarly
to
what
we
did
before
in
this
first
example
through
http
connection
manager,
which
is
going
to
route
to
the
upstream
cluster
and
then
ultimately,
the
service
that
backs
that
okay.
So
the
way
we're
going
to
do
that
is
we're
going
to
configure
something
called
a
downstream
tls
context,
and
we
will
provide
some
certificate
information
in
context
to
that.
Let's
look
at
that
over
here,
so
you
can
see.
One
change
we
made
was
simply
changing
from
port
8000
to
8443.
A
We
didn't
have
to
do
that.
It's
simply
a
convention
based
on
you
know
the
traditional
values
for
http
versus
https
port
values,
and
then
you
can
see
we've
added
this
bit
of
configuration.
This
transport
socket
stanza
into
our
envoy
config.
Everything
else
is
the
same,
so
you
can
see
you
can
see
we're
using
this
downstream
tls
context.
A
It's
we're!
Actually
configuring
this
to
require
a
client
certificate
be
presented
and
then
we're
specifying
the
the
certificate
chain
that
that
we're
going
to
be
that
we're
going
to
be
using
and
that's
really
all
there
is
to
it
we're
using
self-signed
search
in
this.
You
know
in
this
lab
exercise
so
that
will
that
will
change
things
just
a
bit
from
what
you'd
see
in
the
in
the
real
world,
but
you'll
definitely
get
the
idea.
A
Okay,
so
because
we've
changed
configuration,
we
again
need
to
restart
envoy
and
now
what
we're
going
to
do?
Let's
just
let's
test
the
same,
let's
test
what
we
had
before
and
just
confirm
that
that
no
longer
works.
So
if
we
try
to
hit
http
the
http
listener
at
port
8000,
not
surprisingly,
that's
going
to
fail
because
that
listener
is
no
longer
active.
A
Let's
say
we
just
correct.
Let's
say
we
just
correct
the
port
number,
but
we
don't
correct
the
protocol
to
https
again,
you
can
see
that's
going
to
fail
right
because
the
listener
is
expecting
expecting
https
and
it's
not
it's
not
getting
that
and
then.
Finally,
let's,
let's
get
let's
get
everything
right.
Now
you
get
back
from
curl,
you
get
a
warning
hey.
This
is
a
self-signed
certificate.
Are
you
sure,
you're
sure
you're?
A
A
All
right
now,
let's
take
a
look
at
something,
that's
a
little
more
complex,
and
this
is
this
is
the
the
more
probably
the
most
complex
flow
we're
going
to
use
in
this
in
this
exercise,
and
what
we're
doing
is
we're
adding
another
element
to
our
filter
chain
here
and
the
the
element.
We're
going
to
add
is
the
xdot
z,
the
authorization
filter.
So
this
this
is
a
standard
envoy
filter
that
you
can.
You
know,
pick
up
open
source.
A
You
can
plug
it
into
your
envoy
into
your
envoy
instance,
and
what
that's
going
to
do
is
it's
going
to
give
you
the
ability
before
you
actually
process
the
request
you'll
be
able
to
delegate
first
to
an
off
cluster
and
the
auth
cluster
will
simply
take
your
request
and
based
on
whatever
criteria
you
specify
we'll
give
you
a
thumbs
up
or
a
thumbs
down.
This
request
is
acceptable,
or
this
request
isn't
acceptable
by
default.
You'll
get
back
a
403
if
it
is
unacceptable
and
if
it
is
acceptable.
A
B
A
A
We
were
actually
thinking
about
closed
sourcing,
this
code
and
you
know,
but
instead
we'll
just
we'll
put
it
out
there
for
you,
so
yeah
you
can
see.
This
is
our.
This
is
our
sophisticated
all
services,
it's
a
simple
python
server
that
looks
for
hey.
Is
there
a
header
called
called
authorization
in
the
request
and
does
it
have
the
value
of
workshop
if
it
does
thumbs
up
if
it
doesn't
thumbs
down?
Okay,
simple
stuff
and
our
our
upstream
service
is
equally
sophisticated,
as
as
this
all
right.
A
Okay,
so
let's
check
out
the
let's
check
out
the
new
configuration
here
and
what
you're
going
to
see
when
you
look
at
the
differences
notice?
What
we've
done
here
in
the
context
in
the
context
of
our
of
our
filters,
we
have
added
in
this
x,
auth,
z,
filter
and
you
can
see
what
it's
going
to
do
is
it
is
going
to
delegate
to
this
cluster
called
off
right.
A
We
weren't
very
creative,
with
our
naming
conventions
either
and-
and
you
can
see-
we've
also
added
now
an
auth
cluster
with
you
know
the
location
where,
where
it
can
be
reached
so
that
that
will
be
the
first
step
in
that
process
is
for
the
request
comes
in
the
xf
z
filter
is
going
to
pick
that
up
it's
going
to
send
it
off
to
the
auth
service.
All
service
is
going
to
give
a
thumbs
up
or
a
thumbs
down
if
it
gives
a
thumbs
down
we'll
return
a
403
forbidden
back
to
the
client.
A
A
A
A
Let's,
let's
try
something
slightly
different:
let's
let's
say
we
provide
a
bad
authentication
key.
Is
that
going
to
work
yep
just
like
expected?
It
gives
us
back
a
403
forbidden
code
and
then,
finally,
let's
do
the
let's
offer
the
correct
header
with
the
correct
value,
and
now
you
can
see
we
get
back
a
200
okay,
so
it's
working
just
as
expected,
all
right!
So
that's
that's
the
basics
of
how
to
use
the
the
the
out
of
the
box,
xdolf,
z,
filter
that
comes
with
that
comes
with
envoy
all
right.
A
Now,
you're
not
going
to
be
surprised
to
learn
that,
like
every
other
filter
that
comes
with
envoy,
the
x
dot,
z
filter
publishes
a
a
nice
collection
of
metrics
that
you
can
use
to
understand
what
it's
actually
doing.
So,
let's,
let's
take
a
look
at
that.
Take
a
look
at
some
of
the
take
a
look
at
some
of
the
metrics
and
then
let's
see
if
we
can
interpret
interpret
what's
going
on
there.
A
So
what
you'll
see
is
that
here
here
at
the
top
you'll
notice,
that
the
upstream
for
the
or
the
x
dot
z
that
delegates
to
upstream
there
was
one
request
that
was
that
was
okay
right.
That
was
the
last
one.
But
then
there
were
two
requests
here
that
were
that
were
denied
okay.
So
that's
all
good!
You
can
see
also,
similarly,
here
at
the
at
the
ingress
level.
We
also
so
we
got
metrics
that
were
published
at
the
individual
upstream
level.
We
also
get
metrics
that
are
published
at
the
ingress
level.
A
A
We
have
two
that
were
denied
from
the
from
the
ingress
point
and
one
that
was
okay.
You
can
also
see
at
the
bottom
at
the
listener
level,
you
can
also
see
a
breakdown
by
response
code,
so
you
can
see
right.
There
was
one
that
was
a
200,
200
class
response
and
two
that
were
that
were
403
class
responses
and
a
total
number
of
requests
that
were
completed
for
three.
A
So
you
can
see
how
this
produces
a
whole
lot
of
metrics
that
are
really
useful
for
you,
observing
what's
going
on
in
the
system,
adam
is
going
to
talk
about
that
in
just
a
minute
in
more
detail.
Okay,
so
at
this
point
we
are
done
with
lab
three
hope
that
was
helpful
in
understanding
some
of
the
envoy
security
mechanisms.
A
B
So,
if
you
go
back
to,
if
you
can
start
this
workshop
and
we
go
under
graffana
graffana
here,
you
can
just
you
know,
use
I
don't
know
if
you
guys
are
familiar
with
the
grafana.
Basically,
the
default
credentials,
admin
admin
so
use
admin,
admin
you're
going
to
be
able
to
log
in
here
just
skip
this.
You
don't
have
to
to
put
a
new
password
and
we're
going
to
take
a
look
at
what
we
have
here.
B
B
If
you
guys
familiar
with
you,
can
always
create
your
own
panels,
use
all
the
metrics
we
used
to
have
like
define
you
can,
you
know,
create
your
alerting
if
your
system
is
down
and
so
on,
so
something
super
important
is
if
something
is
going
down
check
your
metrics,
that's
the
first
thing
to
do
like
why
I
mean
what's
happening
there.
It's
gonna
get
you
like
some
some
key
data
there
and
then
after
that,
obviously
you're
going
to
check
something
else
which
is
locked
and
we're
going
to
talk
about
this
in
a
second.
B
So
here
we
have
just
a
collection
of
some
metrics
that
are
important.
That
can
be
used
as
a
framework
or
you
guys
can
do
your
own,
create
your
own
dashboards.
We
saw
that
we
have
of
the
night
because
we
added
the
odd
filter
in
the
third
lab.
We
saw
that
we
have
couple
of
the
night
there,
that's
because
of
that,
for
regarding
the
upstream,
the
the
cluster
upstream
cluster
membership,
we
see
that
everything
is
healthy.
Everything
has
been
good
for
the
couple
past
minutes,
15
seconds,
15
minutes.
B
Sorry,
we
see
the
success
rate
is
is
good.
The
only
time
when
something
didn't
happen.
Well
is
because
we
did
this
unreliable
header
and
so
on
so
connection
timeout.
We
see
there
was
no
connection
timeout,
which
is
which
is
awesome.
We
see
some
400s
mainly
because
of
our
403
xod
denied
there,
and
and
so
on,
so
really
valuable
to
understand
the
core
concept
of
like
dealing
with
metrics.
B
If
you
debug
your
environment,
if
you
set
up
envoy,
you
need
to
set
up
your
metrics
either
directly
with
envoy
or,
if
you're,
using
like
something
and
control
plane
and
so
on,
if
using
like,
like
an
istio
or
blue
edge,
so
on
to
always
have
some
sort
of
automatically
pushing
injecting
this
metric
collection
to
your
primitives.
Sometimes
it
even
comes
with
a
primitive
server
with
you
all
right,
so
that
was
super
quick
for
just
grafana
and
we're
going
to
go
back
to
this
like
in
couple
seconds
for
a
debug
exercise.
B
But
another
thing
that
is,
I
think,
even
more
important
is
logs
right.
Something
goes
down,
something
doesn't
work.
Okay,
metrics
will
alert
we're
going
to
receive
a
3
a.m.
Notification
that
everyone
loves,
then
we're
going
to
have
to
check
logs
right.
So,
let's
see
what
we
can
do
to
add
logs
to
envoy
to
do
this.
We're
gonna
use
something
called
access
logs.
So
access
logs
are
really
useful
piece
of
data
that
is
produced
by
envoy
on
each
request.
B
If
envoy,
interceptor
requests
and
something
happen,
either
good
or
bad
like
if
everything's
successful,
you're
gonna
have
a
log
saying
all
good
200,
no
problems
there.
Now,
if
something
goes
out,
what
do
you
have
to
do
check?
Also
the
x
logs
and
check
to
see
what
eric
which
error
code
was,
was
provided
and
so
on?
So
let's,
let's
just
set
up
the
x
logs
quick
here
to
do
this.
B
And,
oh
sorry,
I
have
to
go
in
the
envoy,
folder
check
out
lab4-2
and,
let's
take
a
look
at
the
envoy,
configuration
this
time
to
add
access
logs.
We
added
that
on
our
http
connection
manager,
it's
basically
just
one
line.
Okay,
if
you
add
the
one
line,
type
thing:
it's
just
using
default
format
that
I'm
providing
here
in
the
lab
that
you
guys
can
check
that.
One
here,
I
think,
is
better
for
me
to
squeeze
it
this
way,
but
you
can
configure
your
access
logs,
like
you
want.
B
You
can
add
specific
data
like
you
can
print
specific
headers
that
you
care
about
headers
coming
from
your
client
and
things
like
that
you
can
print.
What's
the
client
ip
address,
for
example,
things
that
are
really
important,
which
upstream,
where
the
traffic
should
be
going
and
what
kind
of
answer
you
guys
got
from
the
upstream.
So
all
this
is
super
valuable
to
have
on
in
your
x
logs
now.
One
key
thing
if
I
have
to
advise
for
only
one
thing
to
watch
in
your
access
logs
is
the
response.
B
Flags,
okay,
response
flags
and
invoice
and
are
super
super
important.
If
something
goes,
if
everything,
if
everything
works,
fine,
you
don't
have
any
response
flag,
gonna
be
a
dash
everything's
fine.
Now,
if
everything
is
not
working,
fine
you're
going
to
have
a
response
flag,
which
is
a
two
letter
or
more
code,
and
this
code
will
tell
you
why
at
least
give
you
a
good
hint
on
why
this
request
failed
you're,
going
to
grab
that
response
flag
go
on
google
go
on
the
end
void,
documentation
match
that
to
what's
the
core.
What's
why?
B
Actually,
what
the
explanation
around
that
specific
response
flag
and
from
there
it's
going
to
give
you
the
good
hint
to
continue
your
debugging
journey.
Okay,
so
again
response
flags.
So
let's
just
restart
the
configuration
here
to
pick
up
our
access
logs,
config
and
now,
let's
you
know,
make
a
couple
calls
and
see
how
things
are
printed.
B
Let's
do
this
alright,
so
I
just
made
five
requests
here
to
my
back
end
again,
but
this
time
I
have
x
logs
on
so,
if
I
go
to,
if
I
check
the
logs
of
envoy
this
time,
I
would
see
my
access
log,
and
this
is,
if
you
fi,
if
you
guys,
see
the
the
five
last
lines
here,
this
is
x
logs
that
can
be
collected
right.
You
guys
can
collect
that
using
your
blog
collection
metric.
You
know
we
have
fuel
and
d
and
so
on
aggregating
this
data,
sending
it
to
any
anywhere.
B
You
guys
persisting
your
logs
and
you
guys
can
query
on
it
so
on,
but
this
is
really
important
here,
where
you
see
that
we
using
the
basic
access
log
format,
we
see
that
we're
making
calls
hello,
we
got
the
200,
it
was
a
one
one
http
one
one
connection
we
see
basically
which
host
was
using,
we
use
and
which
app
stream
ip
we
try
to
target.
Something
important
here
is
that
the
response
flag
is
not
provided
it's
not
implemented.
We
should.
We
see
a
dash.
B
All
right,
let's
start
great,
so
I'm
gonna
go
back
to
the
folder
always
been
using
for
for
this
workshop,
and
now
that
just
makes
some
calls
right.
I
mean
expecting
everything
works.
Well,
no.
We
have
problems
connecting
to
envoy
and
voice
returning
something,
but
I
don't
know
what
it
is
he's
saying.
It
looks
bad
well,
it
looks
really
bad,
no
healthy,
abstract
and
well.
This
time,
appstream
doesn't
mean
that
our
cluster
upstream
just
mean
like
I
can,
can
do
anything
with
your
request.
B
Okay.
Well,
this
is
not
a
fun
time
to
you
know
with
our
with
our
system.
So
what
what
can
we
do?
First
thing
again,
as
I
mentioned
just
kind
of
an
extended
version
of
this
debug
exercise,
first
thing
to
do
if
something
doesn't
happen
now
I
now.
I
know
that
at
least
end
voice.
Returning
something
for
me
in
my
mind,
if
envoy
is
returning,
something
I
was
able
to
connect
to
envoy
so
a
listener.
Is
there
all
right,
I'm
removing
the
listener
possibility
from
my
equation
now?
B
If
I
have
the
listener
defined
and
staking
traffic
and
something
is
happening,
something
so
either
something
is
happening
within
envoy
or
something
is
happening
on
the
you
know,
backhand
side
of
it.
So
now,
let's
try
to
figure
out
if
it's
the
between
envoy
or
in
the
back
end,
what
you're
going
to
do
again
check
the
logs.
B
We
have
ax
logs
defined
already
so
this
time.
Oh
hey,
there's
a
code
there
yeah
we
have
a
bad
thing
going
on.
We
should
not
see
any
code
and
we
see
u
h
right.
So
if
you
see
that
I'm
sending
a
link
here
to
a
documentation,
so
hopefully
it
doesn't
mess
up
everything,
but
I
mean
it's
super
super
small
I'll
see
if
you
guys
go
on
the
envoy
documentation
now
that
we
have
you
edge
like
and
we
can
check
what
it
means.
B
Oh
sorry
up
there
you
go,
it
gives
us
a
bit
more
explanation.
At
least
you
know
this
is
super
basic
one
right.
Yes,
but
you
guys
can
also
see
the
more
complicated
ones
and
that's
the
one.
That's
really,
you
know
really
important
hint
for
us,
so
no
healthy,
upstream
hosts
in
upstream
cluster,
in
addition
to
a
503
response
code-
okay,
well,
no
healthy
upstream
hosts.
So
there
is
something
with
endpoints
like
there
is
something
going
on
that
I
can
connect
to
my
back
end.
So
what
you
do?
B
B
Oh,
this
is
super
maxed
out,
so
I
can
see
everything.
Oh
okay,
so
I'm
looking
at
the
upstream
one.
I
can
scroll
down
here,
I'm
looking
at
the
upstream
cluster
and
something
is
telling
me
that
the
cluster
membership
just
dipped
down
right.
The
number
of
healthy
members
just
crashed,
no
healthy
members.
B
We
can't
connect
to
the
back
end.
So
let's
also
take
a
look
at
the
admin
interface.
If
you
guys
remember
when
we
talked
about
clusters,
we
said
when
we
have
clusters.
We
have
clusters
definition
plus
endpoints
ips,
where
we
can
connect
to,
and
if
we
look
at
the
upstream
one,
nothing
is
there,
there's
no
ips.
B
So
basically
the
envoy
doesn't
know
about
your
backend.
You
know
it
knows,
by
definition,
that
I
need
to
talk
to
something
called
upstream,
but
I
don't
have
the
address
right.
I
just
have
the
name,
no
address
kind
of
switch
right,
so
everything
is
pointing
to
the
fact
that
envoy
doesn't
have
a
way
to
connect
to
my
back
end,
and
that
can
be
because
of
mainly
one
thing:
the
service
is
not
there
or
the
health
check
is
failing
and
health
cycle.
All
endpoints
are
failing.
B
In
this
case
we
have
only
one
ip
so
when
envoy
evicts
this
host
there's
no
way
to
connect
to
it
at
all.
So
let
me
just
quick
check
the
the
list
of
services
I
have
running.
Oh,
where
is
my
back-end
service
here
right
super
basic,
but
I
think
what's
important
to
note
here
during
this
quick
debugging
journey.
Is
that
envoy
will
give
you
some
hints
to
take
a
look
somewhere
else?
B
First,
going
to
tell
you
hey,
there's
no
healthy
hosts
like
I
have
I'm
having
a
trouble
they're
connecting
something
you're
going
to
go
check
your
response
flag.
It
tells
you
a
little
bit
more
hey.
Maybe
there
is
no
endpoint
and
then
you're
gonna
go
check
your
grafana.
Usually
I
mean
if
you
can
connect
to
the
admin
interface.
That's
fine!
If
not
you're
gonna
connect
to
grafana
check.
If
there
is
data
there,
if
there
is
endpoint,
there
is
no.
If
there
is
configuration
we
saw
in
graffana
there's
like
a
cluster
membership
dip.
B
So
we
saw
that
something
happened
which
is
bad
from
there.
You
can.
You
can
have
a
hint
on
what's
the
next
step.
In
our
scenario,
we
just
see
that
there
is
no
back-end
service.
Well,
that's
an
easy
fix,
at
least
for
us
today.
It's
just
to
start
back
our
upstream
and
that's
all.
If
we
make
a
call
again.
B
B
B
We
just
like
had
an
hcm
matching
on
a
host
directing
traffic
to
an
app
stream
to
my
backend
service
and
having
xot
and
tls
on
it.
That's
super
straightforward,
but
we
see
that
it's
super
complicated
configuration
and
honestly
maintaining
that
on
file
and
dealing
with
this.
It's
no
go.
You
guys
can
do
that.
It's
that's
one
service.
Imagine
about,
like
you,
know
200..
B
So
this
is
why
envoy-
and
we
mentioned
it
earlier
envoy-
has
a
mechanism
to
push
data
through
what
we
call
an
xds
server,
okay,
which
is
basically
your
control
plane
server.
It's
going
to
be
a
like
just
a
server
serving
android
configuration
and
voice
connects
to
fetch
the
configuration,
automatically
update
and
be
able
to
route
traffic
right.
So
it's
really
important
to
have
a
control
plane,
and
we
know
there
is
a
lot
of
advantages
to
have.
B
You
know
to
use
a
control
plane,
it's
pretty
straightforward.
If
you
want
to
use
envoy
for
a
simple
exposing
of
one
service,
it's
fine
to
use
a
file.
I
would
say
now,
if
you
are
doing
you,
know,
enterprise,
networking
and
application
exposure
and
stuff
like
that,
you
need
you
care
about
couple
things
and
I'll.
Just
you
know
just
a
summary
here
or
thing
that
you
really
care
about
is
mainly.
I
want
to
simplify
the
interaction
I
want
to
have
a
way
to
just
create.
I
mean
I'm
a
user.
B
What
matters
for
me
just
I
want
to.
I
want
to
tell
the
system
hey,
expose
this
service
called
upstream
through,
like
either
a
cloud
native
way
of
doing
it
using
you
know,
cr
crds,
in
in
communities,
I
create
my
cr
automatically.
A
control
plan
will
pick
up
the
configuration
and
modify
my
data
plane,
which
is
envoy
to
do
this.
B
B
Imagine
if
you
guys
had
to
write
this
with
the
ammo
and
mess
up
one
tab
right
and
restart
and
somehow
just
push
your
configuration.
That
would
be
a
mess,
bringing
all
your
infrastructure
down
for,
like
a
real,
real
silly
mistake.
So
having
configuration,
validation
is
a
key
component
that
control
planes
provide
you're
going
to
have
a
cr
pushed
this
cr
going
to
be
validated
by
either.
You
know
kubernetes
schemas
in
in
the
crs
or
you're
going
to
have
like
a
backend
type
validation
that
will
take
this
configuration
that
you
provided
compared
to
whatever
exists.
B
If
you
see
that
we're
defining
another
host
on
top
of
a
host,
that's
already
defined,
for
example,
this
is
a
problem.
I
don't
want
this.
I
don't
want
to
do
that.
So
I'm
going
to
return
this
configuration
to
the
client
saying
hey.
This
already
exists,
figure
out
your
problem
again.
Also,
you
know
canary
upgrades
and
so
on.
If
you
have
a
decoupling
between
your
multiple
version
of
envoy
with
a
control
plane,
you
can
always
you
know.
Let's
say
it's
rare.
B
We
didn't
void
to
change
stuff,
but
let's
say
tomorrow
they
migrated
to
the
new
version
of
envoy,
like
we
did
between
v2
and
v3.
If
you
guys
familiar
with
enjoy
a
bit,
it
was
a
change
of
app
of
api.
So
if
you
have
a
control
plane
that
understand
this
change
automatically
convert
an
old
configuration
to
a
new
version
of
an
envoy
api.
It
will
make
a
way
smarter
upgrade
to
your
system
instead
of
like
modifying
every
single
file,
you
know
thousand
times
so.
B
B
That's
is
a
simplified
control,
plane
of
on
top
of
envoy,
where
you
can
just
create
crs
on
communities
and
that
transform
your
cr
into
an
envoy
configuration.
Basically
all
we
did
today
that
can
be
do
done
through
through
crs
all
right,
so
I'm
gonna
give
back
the
mic
to
jim.
So
you
can
give
us
a
bit
more
probably
a
closing
statement.
A
Some
of
you
will
be
interested
in
this.
If
you
would
like
to
take
the
exam
to
get
your
envoy
foundations
badge,
there
are
some
additional
instructions
here
again,
you
need
80.
You
can
take
the
test
multiple
times,
but
you'll
need
a
different
email
address.
It's
just
a
google
form.
Most
of
the
questions
are
just
multiple
choice
and
they're,
going
to
be
drawn
directly
from
the
material
that
we've
presented
during
this
workshop.
So
if.
B
A
I
see
I
see
yep,
so
this
is
a.
This
is
a
program
that
that
we've
been
running
for
a
while
at
solo,
with
a
number
of
open
source
technologies,
istio
ebpf
being
the
most
notable
ones.
But
if
you
see
the
link
there
at
the
bottom
or
you
can
scan
the
qr
code,
the
link
to
get
to
the
google
form,
that
is
the
exam,
is
bitly.
Slash,
envoy,
dash
exam
again
bitly,
slash
envoy
dash
exam,
and
so
you
can.
You
can
do
that.
You'll
also
have
access.
A
If
you
want
to
continue
to
play
around
with
your
environments
and
maybe
explore
some
things
that
you
didn't
get
to
do
as
deeply
as
you
would
like
in
the
course
of
the
discussion
here,
you
can
actually
restart
the
track
if
you
would
like
to
and
you
have
access
to
it
for
probably
another
two
and
a
half
hours
or
so,
and
certainly,
if
you
you
know,
if
you
want
to
get
access
to
it
later,
just
contact
us
at
solo.
We
can.
We
can
set
you
up
to
be
able
to
to
do
it
on
your
own.
A
B
Yeah-
and
I
want
to
really
mention
something
that
was
like
a
one-on-one
basic
debugging,
yes,
foundation
and
envoy
has
a
lot
more
to
offer
at
different
levels
and
we're
planning
on
doing
something
more
intermediate
and
something
more
expert
in
the
future.
So
yeah,
please
just
check
out
our
website
or
reach
us
to
us.
I'll
tell
you
if
there
is
any
update
there,
but
yeah.
We
hope
to
see
each
one
of
you
in
our
next
workshop
envoy
envoy
workshop.
We.
B
A
B
So
once
you
see
them,
you
mean
like
like,
like,
I
just
understand
like
what
do
you
mean
by
seed
and
because
you
can
obviously
through
metrics,
you
can
always
see
multiple
filters
sometimes
expose
different,
different
metrics
right.
So
if
it's
a
filter
chain,
you
can
always
see
that
the
listener
got
the
connection,
and
then
you
can
go
to
every
single
filter
and
see
if
it
just
intercepted
the
connection.
B
Now,
if
you're
looking
into
like
a
specific
request
and
how
it's
flying
into
the
filter
chain,
definitely
logs
right,
well
access
logs,
it's
something
simple,
but
you
can
always
turn
on
debug
likes
on
the
debug
log.
Sorry,
on
on
android
itself,
envoy,
every
time
it
turns
out
to
request
it.
It
puts
like
a
request
id
right
so
using
the
request
id
that
you're
trying
to
track
you're
gonna
be
able
to
track
it
down
all
the
way
down
to
to.
Basically
your
your
backend,
so
I
would
say
logs
is,
is
the
way
to
do
it.