►
From YouTube: Envoy Q&A - Matt Klein, Lyft & Harvey Tuch, Google
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Envoy Q&A - Matt Klein, Lyft & Harvey Tuch, Google
Come meet the Envoy maintainers for a small intro to Envoy as well as an open Q&A!
A
B
Sure
I'm
harvey
took
I
work
at
google
on
on
my
platform,
so
I'm
interested
in
taking
onward
and
making
you
do
that
in
our
organization
and
also
supporting
envoys
and
open
source
projects.
I'm
a
senior
maintainer
I've
been
heavily
involved
in
envoy
in
a
number
of
areas,
mostly
around
apis,
the
xds
protocol,
as
well
as
security
and
some
amounts
of
just
basic
infrastructure,
and
so
on.
A
B
A
A
A
B
Better
off
taking
that
one
I
mean,
I
think
the
answer
is
yes.
Yes,
I
think
yeah
we
are
more
to
the
exact
status
of
where
we
are
because
we
had
a
question
a
previous
maintainer
separate
around
the
documentation
and
stability
and
examples,
and
I
think
that's
what
the
community
is
really
looking
to
actually
understand
right
now,.
A
Sure
so,
obviously
quick
in
http
3,
at
least
the
ietf
version
is
still
in
the
process
of
being
ratified.
I
think
it's
very
close,
quick,
obviously
came
out
of
google,
so
google
has
been
using
quicken
production
for
quite
some
time,
we're
very
fortunate
with
envoy,
where
the
team
that
shipped
quick
at
google
also
works
on
envoy
and
historically,
the
way
that
the
code
worked
is.
A
It
was
part
of
the
chromium
codebase,
so
it
was
already
open
source,
but
in
the
interest
of
making
it
easier
to
consume
in
chrome
as
well
as
envoy,
as
well
as
other
projects,
it's
been
moved
out
to
a
different
library,
called
quiche,
there's
a
team
of
people
that
have
been
working
on
integrating
that
into
envoy
for
actually
quite
some
time.
I
think
they've
been
working
on
it
for
six
or
nine
months
and
I
believe
it's
very
close
to
an
mvp.
A
I
think
there
are
people
that
are
that
are
actually
standing
it
up
now
and
I
think
one
of
the
maintainers
greg
is
actually
working
on
it
now,
not
at
google.
So
I
think
there
are
people
that
are
pretty
actively
working
on
it.
We
don't
have
documentation
yet,
but
the
the
support
is
planned.
It'll
support
the
old
google,
quick
it'll
support
the
support,
the
ietf,
quick
oops.
Sorry,
my
phone
is
beeping,
but
it
will.
You
know.
A
B
B
It's
sitting
it
it's
most
of
the
tests
are
actually
passing,
there's
still
a
backlog
of
tests
which
need
to
pass
there's
quite
a
bit
of
work
being
done
on
tooling
and
ci
to
make
sure
it's
possible
to
actually
make
maintainable
significant
investment
from
vmware,
and
I
don't
know
if
anyone's
actually
using
it
in
production.
Yet
that
have
you.
A
It
doesn't
perform
very
well,
so
I
I
think
it
is
functionally
complete,
meaning
it
has
all
the
features,
but
it
does
not
perform
well
and
that's
just
related
to
how
how
event
triggering
works
within
windows
and
the
team
is
working
on
that
currently.
So
I
think
their
goal
is
by
the
end
of
the
year
to
have
something
that
performs
well
for
a
beta
version.
A
B
Oh,
I
mean
what's
the
pitch
in
the
website:
omboy
is
a
cloud
native
service
mesh
proxy
or
something
like
that,
but
basically
what
I
think
of
envoys
is
actually
is
in
a
number
of
different
respects.
It
provides
some
l4,
l7
load,
balancing
and
proxying
a
data
plane
for
this.
It's
a
central
component
of
many
service
meshes
so
you'll
see
it
as
part
of
things
like
istio
and
also
it's
using
a
number
of
just
like
very
bespoke
applications
like,
for
example,
building
edge
load,
balancers
for
very
large
organizations
or
cloud
native
companies.
B
B
It
has
both
an
extensible
data
plane
with
various
extension
points
and
also
a
control
plane
built
around
open
apis,
and
these
are
the
xbs
protocol
apis
and
protocol
that
you
may
hear
about
in
association
with
envoy
and
things
like
istio,
and
this
is
where
a
lot
of
the
power
of
envoy
comes
about,
in
that
it
enables
entire
ecosystems
of
extensions
and
other
components
such
as
control,
planes
and
management
servers
to
interoperate
with
it.
So
yeah,
I
don't
know,
I'm
sure.
As
the
founder
you
you
have
a
particular
take
as
well
right.
A
A
That's
that's
the
most
similar
thing
that
you
would
compare
it
to
and
envoy
has
become
very
popular
because
of
a
bunch
of
the
features
around
how
it
does
configuration
and
extensibility
and
the
community
that
we've
built,
but
at
the
end
of
the
day
it's
a
software
load
balancer
all
right.
Let's
see
next
question,
I
have
a
file
access
log
question.
I
am
currently
using
the
file
access
log
in
my
filter
for
a
grpc
service
and
it's
creating
thousands
of
access
logs
per
minute.
Is
there
a
way
to
limit
that?
A
Yes,
there
are
various
ways
of
limiting
it.
I
would
take
a
look
at
what
envoy
calls
runtime
support,
which
basically
allows
you
to
do
stable
sampling,
so
you
can
sample
access
logs,
I
think
to
one
in
a
million
or
one
in
ten
thousand
and
there's
various
filters
that
you
can
use
to
limit
the
log
output
mark
that
one
answered.
A
Let's
see,
we'll
answer
answered,
live
okay
and
let's
see
next
one,
what
let's
see,
what
are
your
favorite
or
the
most
interesting
uses
of
xds
relay
I'll
I'll
talk
briefly
and
then
I'll?
Let
harvey
talk
also
so
xds
relay
for
those
that
don't
know
it's
a
it's
basically
an
xds
caching
proxy,
so
you
could
think
of
it
as
like
varnish
for
xts,
and
you
know
a
bunch
of
the
problems
that
people
have
when
they're
trying
to
run
envoy
or
other
xds
compliant
proxies.
Is
it
can
be
difficult
to
write,
control
planes?
A
It's
just
it's
not
it's
not
it's
not
super
simple.
So
our
goal
with
that
project
is
to
make
it
easier
for
people
to
write
scalable
control
planes
similar
to
how
people
frequently
run
cdns
in
front
of
their
http
origin
servers.
We
believe
that
there's
an
opportunity
to
have
a
a
common
caching
layer
that
can
offer
you
know
distributed
systems
best
practices
around
things
like
back
pressure
and
rate,
limiting
and
all
of
those
things
and
then
also
more
advanced
functionality
around
things
like
subsetting
or
implementing
incremental
xds,
and
things
like
that.
A
B
Yeah,
I
I
would
definitely
say
one
of
the
compelling
use
cases.
That's,
I
think,
is
a
pretty
high
priority
in
xds
relay
roadmap.
Is
this
idea
of
bridging
state
of
the
world
updates,
which
you
know
very
relatively
simple
configuration
pipelines
and
control
planes
can
speak
and
dealing
with
the
nuances
around
delta
and
even
on
demand
or
xds
updates?
I
don't
think
that's
like
their
immediate
goal.
B
I
think
the
xcs
protocol
itself
is
actually
starting
to
build
in
more
capabilities
and
first
class
support
for
cachability
as
we
go
for
scalability,
and
you
can
see
this
in
things
like
very
recently.
A
ttl
was
introduced,
which
is
is,
is
pretty
important
from
that
perspective,
but
also
we
we're
having
a
new
sort
of
url
based
naming
scheme
inside
xds,
which
will
be
capable
of
really
modeling
xds
resource
names
as
cache
keys
and
make
things
like
xds
relay
that
much,
I
guess
easier
to
use
and
more
effective.
B
So
when
things
like
onboard
mobile
adopts
xcs,
which
it
doesn't
today,
but
as
it
does,
this
kind
of
application
of
xcs
relay
as
well
as
other
more
traditional
cdn
kind
of
right
method
of
distributing
caching,
the
cachable
resources
will
be,
I
think,
pretty
important
yeah
I
mean
I,
I
think
it's
kind
of
like
a
swiss
army
knife
essentially
of
control,
plane
capabilities
which
you
know
can
be
used
for
this
than
our
capability.
That's
the
way
I
see
it,
yeah.
A
All
right
next
question:
is
there
a
plan
to
incorporate
latency
based
load,
balancing
like
linker
d's,
ew
ma?
I
don't
know
of
anyone
that
has
been
interested
in
implementing
this.
So
far,
all
of
envoy's
load
balancing
systems
are
actually
plugable,
so
it
wouldn't
be
terribly
hard
for
someone
to
implement
this.
We
just
need
someone
to
come
forward
and
do
so.
A
I
I
think
my
experience
with
the
latency
based
little
balancing
systems
is
that
you
know
I
mean
they
add
a
bunch
of
complexity
and
it's
not
clear
that
they
add
enough
value
to
warrant
the
complexity,
but
we
would
certainly
be
open
to
having
those
be
implemented
if
there's
people
that
would
want
to
implement
them,
let's
see
next
time
any
tips.
If
I
want
or
need
to
write
a
control
plane
for
envoy
from
scratch
I'll.
Let
harvey
take
that
one.
A
No,
I
I
think
I
would
just
echo
the
same
thing,
which
is.
I
would
really
not
recommend
writing
a
control
plane
from
scratch.
At
this
point,
I
think,
between
the
api
gateway
solutions
and
the
service
mesh
solutions
that
are
out
there,
I
would
really
recommend
starting
from
from
something
open
source,
even
if
it
requires
it
to
be
customized.
So
next
question:
where
do
you
stand
on
the
spire
integration?
A
A
You
know
that
can
interoperate
with
different
certificate
providers
and
different
ways
of
specifying
principles
and
our
back
rules
and
all
of
those
things,
so
I
think
we're
very
open
to
obviously
integrating
with
different
different
authentication
authorization
providers
and
it's
a
pretty
pretty
plugable
system,
so
I
think
we're
open
to
it.
I
don't
know,
did
you
have
anything
to
add
there
harvey.
B
No,
I
don't
think
so.
I
mean
other
than
to
point
out
that
yeah,
as
you
point
out
like
as
a
man
also
mentioned
before,
you
know,
part
of
envoy's
extensibility
extends
to
things
like
certificate
providers,
and
we
have
a
recently
added
mechanism
to
sort
of
very
flexibly.
Add
in
additional
sources
of
certificate
providers.
A
Right
next
question:
are
there
interesting
public
overlaps
using
open,
api
and
envoy?
I
can
answer
this,
I'm
not
sure
if
there's
something
that
you
know
about
harvey.
If
you
want
to
answer
this
at
all
or
do
you
want
me
to
take
this,
so
I
I
think
from
an
open
api
perspective,
I'm
not
an
expert.
I
don't
think
there
are
any
explicit
overlaps
right
now.
A
What
I
will
say
is
that
envoy
does,
I
would
say,
quite
a
lot
already
with
api
transcoding,
so
particularly
around
grpc
to
json
and
and
things
like
that,
and
I
think
there's
an
entire
ecosystem
brewing,
particularly
around
protobuf
and
grpc.
Apis
of
how
annotations
you
know
can
be
added
to
apis
to
allow
them
to
be
shared
across
different
ecosystems,
so,
whether
that
be
something
like
swagger
or
open
api
or
grpc,
and
automatic
conversion
between
grpc
and
json
and
yaml.
A
So
I
I
don't
know
that
envoy
at
least
initially
would
be
involved
in
this,
but
I
do
think
that
over
time
we're
going
to
see
more
convergence
in
how
people
define
apis.
I
think
there'll
be
an
increased
movement
towards
idl
and
then
I
think,
as
people
move
towards
idl,
I
believe
that
we
can
one
of
the
complaints
against
idl-based
apis
is.
A
A
So
there's
no
one
else
using
it
so
far
that
I
know
of-
and
you
know
to
be
clear
with
onboard
mobile,
we
open
sourced
it
really
at
the
very
beginning
before
there
wasn't.
There
wasn't
really
anything
so
it
was
developed
in
the
open.
So
we
are
finishing
our
production
rollout
by
by
the
end
of
the
year,
so
if
you're,
using
lyft,
most
rides
and
functionality
now
are
already
going
over
on
by
mobile,
we've
had
a
lot
of
quite
a
bit
of
interest
from
other
large
companies.
A
I
I
can't
speak
to
any
of
them
now,
but
I'm
expecting
broader
adoption
in
2021,
but
we'll
have
to
see
how
it
goes,
I'm
still
very
bullish
on
the
technology.
I
think
the
goal
of
the
project
which
is
to
share
the
networking
stack
everywhere,
tends
to
resonate
with
people,
and
this
comes
back
to
actually
what
we
were
talking
about
before
about
the
open
api
aspect,
which
is,
I
think,
when
you
look
at
defining
apis
and
look
at
them
end
to
end
from
the
client
to
the
server.
A
A
B
Yeah,
so
I
think
I
mean
we've
seen
over
time.
Unofficially
there
there
has
been
other
attempts
to
build
things
like
go
filters,
and-
and
this
kind
of
thing
I
think,
web
assembly
is
probably
one
of
the
key
places
that
most
the
community
is
going
to
head
towards,
because
it
provides
a
very
stable
interface
and
api
for
building
these
kinds
of
integrations
and
it's
kind
of
you
know
highly
aligned
with
the
idea
of
multi-language
support.
B
We
have
opened
a
tracking
issue
around
rust
use
in
envoy,
and
this
is
a
place
where
I
think,
if
anyone's
interested
in
contributing,
we
would
definitely
be
interested
in
trying
to
see
what's
possible.
It's
unclear
whether
we
would
be
able
to
offer,
for
example,
the
same
level
of
of
integration
as
existing
cps
plus
extensions
to
russcode.
Largely
because
of
this
problem
of
you
know.
Essentially,
foreign
function
interface.
B
You
know,
russ
is
a
more
like
c
like
abstraction
level,
and
it's
it's
kind
of
hard
to
make
it
work
well
with
c,
plus,
plus
and
there's
just
generally
an
open
issue
in
the
rust
community
around
that.
But
we're
definitely
interested
in
you
know
potential
normal
uses
of
rust.
I
mean.
One
thing
I
would
point
out
is
that
we
actually
have
a
pretty
large
array
of
extensibility
options
in
envoy
now
and
that
folks,
approaching
you
know,
building
an
extension
for
envoy
can
choose
between.
You
know
things
like
the
traditional
c
plus
native
filters.
B
A
Yep,
I
I
think
in
general,
just
just
to
summarize,
I
don't
think
we're
opposed
to
having
other
languages
right,
it's
like
if
someone
actually
wanted
to
figure
out
how
to
upstream
go
filters
or
whatever
else
I
we're
not
opposed
to
it,
but
it's
pretty
hard
to
actually
make
this
work.
It's
a
substantial
amount
of
effort
and
it's
unclear
that
someone's
going
to
be
willing
to
do
that.
A
So
I
think
it
really
depends
on
on
the
overall
community
ecosystem,
and
my
experience
has
been
that
for
the
vast
majority
of
use
cases
when
rubber
meets
the
road
c
plus
plus
works,
lua
works,
and
I
think
web
assembly
will
end
up
working
for
for
most
people,
so
I'm
just
skeptical
that
people
will
actually
put
up
put
up
the
work
other
other
than
rust,
because
I
think
rust
is
the
future.
So
yeah,
okay,
let's
see
there's
another
question
here.
A
Sorry,
if
this
is
a
vague
question,
we
manually
set
up
envoy
for
two
services,
envoy,
egress
envoy
ingress.
We
have
seen
upstream
connect
error
or
disconnect
before
headers
when
under
load.
We
are
seeing
the
error
occurrence
decrease
when
we
increase
the
cluster
connect.
Timeout,
is
it
a
good
idea
to
keep
the
connect
timeout
to
be
the
same
for
all
services,
any
idea
or
guideline
about
what
is
happening?
A
To
be
honest,
it's
really
hard
to
you
know,
comment
or
debug
this
type
of
thing
remotely
over
over
conference
video.
So
I
I
would
encourage
you
to
either
file
file
an
issue
or
hop
into
envoy
slack.
I
would
say
in
in
general,
I
mean
from
what
you're
saying
is
that
it's
not
surprising
to
me
that
under
load,
you
know
things
take
longer
to
connect
and
you
might
have
to
raise
the
timeouts.
A
So
at
the
end
of
the
day,
with
a
lot
of
the
timeouts,
you
know
that
you
can
set
in
envoy
you're
trying
to
balance
performance
with
overall
availability
and
the
only
way
to
really
tune.
That
is
going
to
be
to
look
at
your
particular
use
case
and
do
load,
testing
and
figure
out
what
type
of
error
budget
you
are
comfortable
with,
depending
on
the
load
that
you're
taking.
A
A
A
B
A
What
what
am
I
most
excited
for?
I
think
I'm
excited
for
webassembly.
I
really
do
think
that
is
the
future
of
extensibility,
so
I
am
very
excited
for
that.
One
and
I'm
excited
for
quicken
http
3
excited
for,
I
think,
a
bunch
of
the
work
that
we're
gonna
do
in
the
envoy
mobile
space.
I'm
excited
for
our
gender.
You
know
general
continued
focus
on
security,
so
I
think
that's
something
where
we've
you
know:
we've
made
great
strides
and
there's
always
always
more
to
do
it's
a
very
messy
space.
A
B
Yeah
I
mean
I,
I
would
definitely
agree
with
you
on
that
space
I
mean
just
generally
extensibility
in
general.
I
think
you
know
we're
going
to
see
a
continuum
of
growth
in
terms
of
extensibility
in
many
different
levels,
whether
it's
you
know
it's
how
people
are
building
ombre
extensions,
it's
how
we're
constructing
the
api-
and
you
know
making
that
built
around
the
concept
of
extensibility
and
less
fewer
sort
of
baked
in
concepts.
B
I
think
and
generally
sort
of
a
bit
gumbo
about
their
work
that
I'm
currently
involved
in
around
trying
to
improve
things
like
scalability
cachability
federation
support
this
kind
of
stuff
in
xds
sort
of
trying
to
open
it
up
to
a
a
wider
audience,
and
I
think
it'll
be
very
interesting
to
see
other
the
xcs
ecosystem
grow
as
a
whole.
As
we
see,
additional
proxies
and
data
plane
components
jump
on
board
and
I
think
that's
we
definitely
will
see
here.
In
the
previous
year
we
saw
grpc
join.
B
I
think
we're
going
to
see
quite
a
few
more
folks
come
on
board
in
2021,
so
yeah.
Those
are
things
that
I'm
definitely
very
excited
about
and
I
think
like
on
the
security
front,
I'm
very
interested
to
see
more
what
will
be
exciting
to
see
more
folks
and
companies
sort
of
getting
involved
and
contributing
there,
because
I
think
we're
starting
to
see
this
happening
and
it's
actually
really
great
to
see
security
becoming
a
sort
of
common
responsibility
and
something
which
many
companies
are
sort
of
giving
back
to
the
ombud
community.
B
A
Yep,
let's
see
what
efficiency
gains
has
lyft
made
by
implementing
envoy.
You
know
that's
a
tough
one
to
answer
right,
because
I'm
not
sure
what
efficiency
this
person
is
talking
about.
Are
we
talking
about
like
compute
efficiency
or
person,
efficiency
and,
to
be
honest,
it's
really
hard
to
answer
that,
because
envoy
was
developed
relatively
early
on
in.
I
live
to
solve
a
bunch
of
problems
around
them
around
the
microservice
rollout
and
it
certainly
satisfied
those
goals.
A
But
at
this
point,
envoy
is
so
intertwined
with
everything
that
lift
does
its
hard.
You
know
it's
hard
to
go
back
five
years
and
and
understand
what
it
would
mean
to
unwind
that
I
mean
it's
not
it's
it.
It's
not
really
possible.
So
I
think
that,
at
least
from
the
initial
goals
we
started
the
project
five
and
a
half
years
ago.
It
was
honestly
mostly
around
developer
productivity.
A
It
wasn't
really
around
like
machine
performance
and
I
think
the
goal
was
to
make
it
easier
to
do
the
microservice
rollout
and
I
think,
from
that
perspective,
the
microservice
rollout
went
from
being
stalled
to
being
successful.
So
I
I
think
I
would
I
would.
I
would
measure
it
more
on
the
developer
productivity
side
of
things.
A
B
There's
a
lot
from
even
folks
at
google
host
of
ramping
up
an
envoy,
because
the
two
are
sometimes
sort
of
treated
synonymously,
and
so
the
way
I
would
describe
this
is
istio
is
a
complete
service.
Mesh
offering
and
envoy
is
the
data
plane
component
there.
It's
the
sidecar
proxy
and
also
using
you
know,
things
like
the
you
know:
edge
sort
of
egressing
rest
proxy,
that
that
form
that
is
used
as
a
building
block
as
part
of
the
istio.
B
So
it
still
includes
many
other
things
beyond
just
envoy
in
terms
of
things
like
you
know,
a
ca,
a
policy
engine,
a
configuration
control
management
system.
So
all
these
things
are
sort
of
what
constitutes
istio,
so
you
can
think
of
like
envoys
being
a
single
proxy
which
you
would
have
like
is
in
a
single
node
or
a
single
electric
pod
in
like
istio
and
istio
is
really
the
the
whole
network.
The
comprehensive
service
mesh
offering
there
yeah
anything
to
that
matter.
A
A
No
upstream
go
filter
support.
There
have
been
a
couple
of
projects
that
have
done
it.
I
know
that
psyllium
has
done
it,
but
it's
not
upstream.
I
think,
there's
a
couple
other
companies
that
have
done
it,
but
nothing
is
upstream.
I
know
that
they're
working
on
a
tiny
go
webassembly
runtime,
so
you
know
that
might
be
an
option,
but
other
than
that,
I
don't
think
there's
anything
really
out
there.
A
I
think
we're
almost
out
of
time.
So,
let's
see
we
can
take
another
couple.
Is
there
any
integration
between
envoy
and
ebpf
not
directly?
But
if
you
look
at
psyllium
again
they're
doing
a
lot
of
stuff
with
ebf
and
envoy,
so
I
would.
I
would
look
at
them
and
trying
to
look
through
anything.
We
can
do
quick.
I
don't
know
what
is
the?
B
A
Yeah,
I
think
I
would
say
the
same
thing:
it's
just
it's
everywhere
right,
and
so
it's
like
it's
used
in
telecom
and
internet
and
like
finance,
and
it's
just
all
over
the
place.
So
I
think
the
most
surprising
thing
for
me
is
is
just
how
widely
it's
been
deployed
and
it's
deployed
all
over
the
place
from
surface
mesh
to
internal
load,
balancer
to
api
gateway.
So
from
a
project
perspective,
it's
really
fantastic
to
to
see
all
that
growth.
So
I
think
we're
about
at
time.