►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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 Gateway Project Update - Daneyon Hansen, Tetrate & Alice Wasko, Ambassador Labs
If you're interested in using Envoy as an API gateway or Kubernetes ingress, this is your session. Envoy Gateway is a new project within the Envoy ecosystem that was announced at KubeCon EU 2022. The goal of the project is to attract more users to Envoy by lowering barriers to adoption through expressive, extensible, role-oriented APIs that support a multitude of traffic routing use cases. Agenda 1. Envoy Gateway Introduction & Demo 2. v0.2.0 Release Highlights 3. Roadmap 4. Q&A
A
A
A
But
before
we
get
into
what
the
Project's
been
up
to
I
wanted
to
just
take
a
moment
and
and
give
a
quick
history
which
I've
mentioned
a
few
pieces
of
it.
But,
as
most
of
you
know,
Envoy
started
back
in
the
fall
of
2016.
and
it
even
though
an
Envoy
became
synonymous
with
service
mesh.
It
actually
started
as
an
edge
proxy
within
lift
and,
as
I
mentioned
in
the
spring,
Envoy
Gateway
was
born
with
the
focus
around
these
two
areas.
A
How
do
we
bring
Envoy
to
the
masses
right
envoys
become
very
popular,
both
again
as
a
as
a
sidecar
proxy
for
service
mesh,
as
well
as
an
edge
proxy,
but
we
wanted
to
take
Envoy
to
the
masses.
Take
it
even
further,
and
one
of
those
areas
that
we
needed
to
address
is
how
do
we
make
the
user
experience
simple?
How
do
you
make
it
simple
to
consume
and
start
getting
value
out
of
envoy
proxy.
A
And
that's
what
gives
us
this
multiple
user
Persona
support
right,
and
so
what
you're
going
to
see
is
there
are
certain
resources
that
would
be
used
by
an
infrastructure
team
for
creating
the
envoy
proxy
infrastructure
and
then
a
separate
set
of
resources
that
would
be
used
by
your
app
Dev
team
right
and
and
the
primary
resource
would
be
the
routing
resources,
for
example,
HTTP
route
for
routing
traffic,
to
your
backend
application,
and
it's
extensible
again
not
only
through
Gateway
API.
But
we
have
some
native
extension
points
within
Envoy
Gateway.
A
But
it
is
extensible
in
the
sense
that
we
Define
through
apis
a
basic
common
level
of
configuration
and
management.
And
these
extension
points
allow
Envoy
gateway
to
run,
let's
say
in
different
providers
or
to
support
different
types
of
functionality
like
authen
and
auth,
z
and
again.
Those
extension
points
are
both
native
as
well
as
through
Gateway
API,
and
one
of
the
focus
areas
moving
forward
with
the
project
is
focusing
on
these
extension
points.
A
So
what
the
project
has
been
focused
on
for
the
v02
release,
which
just
released
a
couple
days
ago,
is
that
we
developed
a
solid
foundation
of
the
project
and,
as
we
now
transition
from
establishing
that
that
solid
foundation
and
now
focusing
on
Advanced
use
cases.
This
is
where
we're
going
to
be
spending
a
lot
of
time
here
in
the
near
Futures
is
with
these
extension
points
and
I
say
it's
built
with
Community
horsepower
right.
So
you
know,
creating
an
open
source
project
is
pretty
easy
to
do.
A
Creating
a
community
around
an
open
source
project
is,
is
more
challenging
and
I'm
really
proud
of.
Where
we're
at
with
the
project,
we
have
a
ton
of
different
contributors
which
you'll
see
here
in
a
future
slide
that
span
a
bunch
of
different
affiliations.
So
this
is
not
a
project
that
is
run
by
a
particular
company
or
affiliation.
We
we've
got
quite
the
diversity
already
in
in
the
project
and
we're
excited
to
see
that
grow.
A
Right
and
so
if
we
look
at
Envoy
Gateway,
pretty
straightforward
right
it
it
runs,
it
consumes
configuration
both
static
and
dynamic
configuration.
A
static
configuration
is
used
to
start
up,
Envoy
Gateway
and
then
the
dynamic
configurations
used
to
configure
its
runtime
and
that
Dynamic
configuration
is
expressed
again
through
Gateway
API
resources,
and
then
it
manages
a
fleet
of
proxies
Envoy
proxies.
A
And
let's
dive
into
Envoy
Gateway
a
little
bit
deeper
right.
So
just
like
the
picture
we
saw
back
here
now
we're
zooming
into
Envoy
Gateway,
and
we
see
a
few
things
that
envelope
Gateway
is
comprised
of
the
first
point
is
we
have
a
provider
right
and
so
currently
the
only
provider
that
Envoy
Gateway
supports
is
the
kubernetes
provider
and
Alice
is
going
to
show
you
a
demonstration
of
envoy
Gateway
using
the
kubernetes
provider
and
a
provider
is
responsible
for
certain
tasks
for
watching
the
resources.
The
dynamic
configuration
right.
A
How
are
those
resources
expressed
through
Gateway
API
resources,
but
those
Gateway
API
resources
in
a
kubernetes
provider?
Those
would
reside
in
a
Kube
API
server
right.
So
a
user
creates
those
resources
and
when
you
start
Envoy
Gateway
and
you
say-
use
a
cube
provider.
It
uses
a
kubernetes
client,
specifically
the
controller
runtime
client
to
to
communicate
with
the
Kube
API
server
to
watch
those
resources
right,
as
well
as
to
watch
any
of
the
dependent
resources
for
managing
the
envoy
proxy
infrastructure
right.
A
A
It
then
publishes
that
right,
so
all
of
these
different
system
components
communicate
over
a
a
message:
bus
via
Pub
sub,
and
what
we
the
way
we
Implement
that
message
bus
is
through.
What's
called
a
watchable
library
and
all
these
details,
we,
if
you
go
to
the
project
documentation
at
at
gateway.omboy
proxy.io.
A
If
you
go
to
the
project
documentation,
we
have
all
of
the
system
design
documented.
So
it's
a
really
good
place
to
start
where
we've
had
contributors
come
in,
have
given
us
really
positive
feedback
of
looking
at
the
system,
design,
documentation.
But
this
diagram
and
and
all
the
information
I'm
going
to
cover,
is
in
the
system,
design,
documentation.
A
But
again,
all
the
the
all
the
different
components
communicate
over
this
message.
Bus
and
it's
a
simple
kind
of
translation
pipeline
of
translating
the
Gateway
API
resources
into
our
internal
representation.
Our
internal
data
model.
What
we
call
our
ir
and
you
see
the
IRS-
actually
split
between
an
infra
ir
and
an
XDS
IR
right,
and
so
that
resource
translator
will
go
ahead
and
take
those
Gateway.
A
Api
resources
translate
them
into
our
into
our
internal
data
model
and
one
of
the
things
not
depicted
on
this
diagram
is:
it
should
actually
have
an
arrow
going
out
of
the
system
as
well,
and
that
arrow
is
for
updating
status
of
the
resources
as
they
reside
in
wherever
those
resources
are
persisted.
So
again,
with
the
kubernetes
provider,
those
resources
are
persistent
at
CD,
and
so
the
resource
translator
not
only
translates
the
rest
sources
inbound
from
Gateway
API
resources
to
our
internal
representation,
but
outbound
it's
responsible
for
updating
status
right.
A
Those
two
Services
subscribe
to
the
resource
translators,
whatever
the
resource
translator
publishes
right
and
the
infra
manager
right
now,
the
only
implemented
infra
manager
again
is
a
kubernetes
in
for
manager
and
that
info
manager
is
responsible
for
taking
the
infra
IR
as
input
and
then
as
output,
creating
the
necessary
kubernetes
resources
to
manage
an
Envoy
proxy
Fleet.
So
it
is
managing
the
deployment
resource.
That's
used
for
deploying
Envoy
proxy.
It's
responsible
for
managing
the
service
that
front
ends
the
fleet
of
Envoy
proxies
and
also
a
service
account.
B
B
So
as
of
the
0.2.0
release,
which
is
our
first
functional
release,
we
have
full
core
support
for
all
of
the
Gateway
API
fields
in
Gateway
classes,
gateways,
HTTP
roots
and
TLS
routes.
It's
really
quick
to
go
over
the
first
one
Gateway
class,
which
is
how
you're
going
to
get
started.
You
have
the
main
thing.
B
So
the
next
thing,
you're
going
to
create
would
be
your
gateway,
and
this
one
is
going
to
again
reference
that
Gateway
class
and
you'll
set
up
your
listeners
here
for
how
you
want
onboard
gateway
to
listen
for
requests.
You
can
add
multiple
listeners
on
your
gateway
and
then
once
you
create
this
in
your
kubernetes
cluster,
it's
going
to
trigger
Envoy
gateway
to
create
some
resources
for
you.
B
And
for
these
you
can
again
refer
to
the
parent
Gateway,
which
is
going
to
trigger
Envoy
gateway
to
configure
that
specific
gateway
to
route
traffic
to
this
back-end
service
that
we
need
to
find
in
here
on
the
provided
Port,
you
can
limit
it
to
certain
host
names,
which
is
not
required,
but
is
optional.
You
can
again
have
it
do
all
host
names
by
just
leaving
that
field
out.
There's
also
support
for
filters,
redirects
things
like
that
right
now
and
the
main
benefit
of
kind
of
again
why
we
chose
Gateway
API
resources
for
configuring.
B
Envoy
Gateway
is
one.
It's
established
and
two
it's
well
known,
so
we
want
people
to
get
that
benefit
of
not
having
to
jump
between
a
bunch
of
different
apis,
certain
different
projects,
creating
all
their
new
crds.
Then
you
have
to
memorize
like
okay.
What
is
the
crd
is
that
specific
to
this
project
is
that
a
more
broader
kubernetes
resource
that
I
can
used
in
different
things.
So
this
takes
a
little
bit
of
that
cognitive
load
off
and
then
Additionally
you
benefit
from.
B
A
While
Alice
gets
that
set
up
too
I
just
want
to
emphasize
you
in
that
last
slide,
you
saw
three
different
resources:
Gateway
class
Gateway
HTTP
route,
and
if
you
look
at
the
Gateway
API
documentation,
there's
other
resources
as
well.
There's
you
know,
there's
resources
for
being
able
to
share
secrets
across
different
name
spaces.
This
is
called
a
reference.
Grant,
there's
TLS
route,
UDP
route,
TCP
right
all.
B
And
again,
that's
not
going
to
say
that
those
are
the
only
resources
we're
ever
going
to
support
or
that
we're
only
going
to
support
core
Fields.
Those
are
just
what
we
have
available
ready
for
you
to
try
today
in
the
0.2.0
release
and
we're
going
to
be
adding
support
for
more
features,
more
different
fields
in
the
extended
support
for
Gateway,
API
and
future
releases.
B
C
B
All
right
so
first
thing
you'd
probably
want
to
do
when
getting
started,
is
hop
over
to
this
quick
start.
Like
Damien
said
you
can
get
started
with
just
two
quick
commands
and
a
cluster,
and
you
can
do
this
in
a
real
kubernetes
cluster
that
has
load
balance
to
support
or
you
can
try
it
in
a
local
cluster.
So
I'm
just
going
to
copy
the
First
Command
up
here,
which
is
installing
the
Gateway
API
resources.
A
Yeah,
so,
in
addition
to
this
is
essentially,
this
is
installing
Envoy
Gateway
right
and
so
in
addition
to
installing
Envoy
Gateway
and
installs,
the
Gateway
API
crds,
it's
going
to
install
our
back,
that's
used
by
Envoy
Gateway,
it's
going
to
install
a
cert,
gen
job
and
this
job.
What
it's
responsible
for
is
creating
the
TLs
assets
that
are
used
to
secure
the
communication
between
Envoy
Gateway,
which
is
the
control
plane
and
the
manage
data
plane.
The
envoy
proxies
that
it
manages
so
we
have
mutual
TLS.
A
The
the
screen's
not
showing
up
on
Alice's
on
her
desktop.
She
can't
see
anything
going
on
give
her
one
second
here,
but
as
I
was
mentioning
the
First
Command
here
is
installing
Envoy
Gateway
and
then,
by
by
the
end
of
that
installation,
obligateway
should
be
up
and
running.
You
could
tail
the
logs.
You
can
look
at
the
deployment
and
see
that
it's
running.
A
A
A
A
Envoy
Gateway
there
it
is
in
the
envoy,
Gateway
system
namespace,
and
it
is
ready
and
it
is
available.
So
it
is.
It's
ready
now
to
have
users,
declare
their
desired
state
of
the
proxy
infrastructure
and
then
start
routing
traffic
through
that
proxy
infrastructure
and
that's
what
the
next
step
is
going
to
be
to
create
those
resources.
A
And
then
one
last
piece
that
it
deploys
as
well
in
this
next
part
of
the
installation
is
a
sample
backend
application
as
well.
What
we
use
is
Echo
server,
that's
part
of
the
Ingress
conformance
kubernetes,
Ingress,
conformance
testing
and
what's
cool
with
that,
is
that
it
just
allows
when
we're
testing
and
through
curl
commands.
You
can
actually
see
some
of
the
details
of
the
Pod
that
responds
to
those
requests
to
see
what
name
space
and
the
Pod
name
and
so
forth.
A
B
A
And
the
status
is
really
key
here
right
because
you
know
the
infrastructure
admins.
Let
me
go
ahead
and
just
deploy
their
Gateway
class
and
gateways
and
just
be
able
to
see
that,
okay,
that
it's
ready
to
go
same
with
the
your
Dev
admins
or
your
your
developers.
They
just
go
and
and
list
gateways
and
say:
oh
look,
here's
the
Gateway
that
I
can
attach
to.
B
For
sure,
so
when
on
book
it
reads
all
these
resources
and
it
processes
them
if
there
are
any
errors
with
them
any
issues,
it
will
report
that
back
to
the
status
of
each
resource,
you
can
just
tell
not
only
if
there's
a
problem,
you
don't
have
to
necessarily
dig
into
the
logs
to
determine
what
that
is.
The
status
has
a
lot
of
useful
info
about.
Maybe
there
are
certain
fields
that
aren't
supported
at
the
moment,
certain
things
that
you
might
have
misconfigured
or
any
other
issues
that
to
detect.
B
So
this
is
our
HTTP
route
really
quick
here,
and
you
can
see
that
this
one
is
only
supporting
traffic
on
hostname
example.com,
so
any
other
requests
that
are
not
from
example.com
will
not
work,
but
we're
going
to
use
a
curl
command,
really
quick
to
test
traffic
to
this.
So
I'm,
just
going
to
scroll
down
here
to
section
four
pulling
up
requests
for
an
in
cluster.
A
C
C
C
C
A
C
B
So
when
we
make
that
request,
we're
going
to
make
the
request
to
port
8080,
but
you
can
of
course
change
that
to
80
or
443
if
you're
doing
TLS
traffic,
and
so
this
is
just
a
request
to
the
echo
service,
which
is
just
going
to
print
back
the
request,
headers
and
information
about
the
request.
But
it's
also
going
to
be
able
to
tell
us
which
pod
served
the
request
and
a
little
bit
more
info.
A
Really
quick
Alice
because
I
see
that
we're
getting
the
one
minute
signal,
so
the
other
part
of
the
demo
we're
gonna
do
is
just
patch
the
Gateway
and
add
a
add,
an
https
termination
on
that
Gateway.
It's
one
command,
and,
and
basically
what
that
Gateway
can
now
do
is
terminate
TLS
traffic
and
it
uses.
You
know
a
secret
that
a
user
would
create
to
that.
Typically,
your
infrastructure
admin
would
create
that
secret.
B
Yeah,
so
we
had
a
little
bit
of
friction
with
the
demo,
but
really
quick
before
we
finish
off.
I
just
want
to
go
over
some
of
our
contributors
that
we've
got
from
Envoy
Gateway.
So
far,
we've
already
got
a
lot
of
contributions
from
many
different
people.
We've
got
a
lot
of
expertise
on
this
project.
People
coming
from
various
different
projects,
I
work
on
Emissary
Ingress
we've
got
people
working
on
other
projects
as
well
like
Contour
people
from
got
experience
on
istio
and
as
well
as
people
that
are
working
on
Envoy
itself.
B
So
we've
got
a
lot
of
people
working
on
making
this
as
probably
the
best
solution
for
an
API
Gateway
and
bringing
in
a
lunch
of
experience
from
people
who
have
learned
lessons
building
out
these
API
gateways
with
Emissary.
When
we
got
started
on
that
there
were
a
lot
of
issues
and
design
decisions
that
weren't
great,
because
we
didn't
really
know
what
we
were
doing.
Big
goal
with
Envoy
Gateway
is
just
to
combine
all
that
experience
and
build
something
from
the
lessons
we've
learned
from
the
ground
up.
B
B
Yeah
so
like
Daniel
mentioned,
there
are
going
to
be
multiple
extension
points,
we're
looking
at
in
the
future,
specifically
for
auth
and
stuff,
but
we're
also
going
to
be
looking
at
adding
like
a
XDS
like
patching
mode.
So
you
can
have
sort
of
more
direct
access
to
the
config.
That's
underlying
there
for
people
where
you
kind
of
outgrow
the
needs
of
Gateway
API.
If
you
are
not
familiar
with
the
API
I,
encourage
you
to
go.
B
Look
at
the
docs
for
that
and
check
out
all
the
different
things
you
can
do
with
it,
because
its
config
actually
Maps
surprisingly
well
to
XDS
config.
So
you
can
actually
accomplish
a
lot
with
the
crds,
but
we
definitely
know
that'll
be
a
limiting
factor
for
some
people,
so
we're
already
planning
out
ways
to
extend
the
functionality
yeah.
A
We
have
an
issue
defined
for
kind
of
this
native
XDS
mode,
where
we're
not
going
to
try
to
just
you
know,
duplicate
everything
that
XDS
does
already,
and
so
we're
focused
more
on
kind
of
that
initial
to
kind
of
intermediate
use
case,
and
when
you
get
to
a
point
where
it's
like,
okay,
you've
got
a
lot
of
advanced
functionality
going
on
here.
Let's
use
the
escape
hatch
that
XDS
mode,
so
that
we're
not
again
duplicating
everything
that
XDS
has
to
offer
all
right.
Well,
thank
you.
I
appreciate
it.