►
From YouTube: Emissary-ingress: Intro and Deep Dive - Flynn, Luke Shumaker & Alice Wasko, Ambassador Labs
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.
Emissary-ingress: Intro and Deep Dive - Flynn, Luke Shumaker & Alice Wasko, Ambassador Labs
Emissary-ingress, a CNCF Incubating project, is a self-service Kubernetes-native open-source API gateway and ingress controller built on the Envoy proxy -- but really, what does that mean? In this session, we'll give attendees an overview of why ingress controllers are necessary, how self-service developer workflows work for developers and for operations, and how Emissary-ingress can make all of this easier. We'll also look at current best practices around designing, managing, and evolving self-service APIs. We'll continue with a deeper dive into Emissary-ingress' evolution and future, notably including a discussion around plans for the upcoming getambassador.io/v3 API version, and - perhaps most importantly - how to get involved as a contributor or as a user who wants to offer feedback. This is a great opportunity to interact directly with the Emissary-ingress maintainers and make sure your voice is heard -- we're looking forward to your help as Emissary-ingress continues to grow and evolve!
A
A
All
of
us
of
work
are
working
at
emissary
ingress.
I've
actually
been
involved
with
the
project
since
the
beginning,
back
in
2017,
luke
has
been
elbows
deep
in
a
lot
of
the
low-level
stuff.
For
I
don't
know
a
few
years
now,
I
guess
now
about
three
years
alice
actually
came
over
and
worked
on
the
support
side
of
the
world
at
ambassador
labs
for
a
while
got
a
good
sense
for
what
the
customers
need,
what
the
users
need
and
then
decided
to
join
us
at
engineering.
We
have
successfully
dragged
her
over
to
the
dark
side.
A
A
A
A
A
B
B
C
A
A
A
A
Okay?
It
is
an
api
gateway.
One
of
the
core
roles
of
an
api
gateway
is
routing
traffic.
So,
if
you
have
a
user
jane
who
wants
to
request
a
quote
from
some
service,
then
she
can
do
that.
A
user
mark
can
request
a
quote.
They
might
not
talk
to
the
same
service.
That
might
just
be
something
where
they're
getting
started
off
for
load
balancing.
It
might
be
something
where
there
are
more
deliberate
things
going
on,
maybe
they're
users
in
different
tenants,
but
this
is
a
core
function
of
an
api
gateway.
A
A
A
D
Thanks
so
emissary
ingress
supports
self-service
configuration.
What
does
that
really
mean
for
the
end
developers?
If
you
take
a
look?
Here's
an
example
of
some
of
the
get
ambassador
io
resources
used
to
configure
emissary
ingress,
in
particular
note
how
we've
separated
them
out
based
on
distinct
function.
So
each
resource
is
generally
focusing
on
what
you're
going
to
be
wanted
doing
at
any
given
time
so
that
you
can
focus
on
exactly
what
you
need
to
do
at
any.
D
Note,
particularly
that
the
ingress
resource
you
have
to
specify
the
hostname.
You
want
to
use
you're,
providing
your
secret
name
if
you're
doing
tls
termination
and
you're
specifying
the
rules
for
what
traffic
you
want
to
send
into
what
upstream
service.
Whereas
with
the
get
ambassador,
I
o
things
you
can
configure
things
on
an
individual
level
that
you
might
not
need
to
configure
more
than
once
or
twice
so.
D
We've
put
a
lot
of
time
and
effort
into
the
design
of
the
get
embassador
resources.
That's
why
I
really
think
this
is
the
best
way
to
be
configuring.
It
we've
taken
a
look
at
some
of
the
challenges
that
result
from
configuring
things
at
a
scale
with
existing
resources
such
as
the
ingress
and
we're
constantly
revisiting
it.
To
look
at
what
is
working
for
people
at
a
scale,
what
are
points
of
conflict
and
friction
and
ways
that
we
can
upgrade
things
and
make
them
better
in
the
future?
D
Now
the
whole
self-service
point
means
that
any
one
developer
can
do
this
as
they
need
it
and
focus
on
pieces
bit
by
bit.
When
auth
is
particularly
relevant
to
you,
you
can
start
creating
auth
service
resources
to
focus
on
that.
You
can
do
hosts
and
listening
to
configure
how
the
traffic
is
getting
into
the
cluster
and
then,
when
you're
ready
to
get
it
sent
to
your
upstream
services.
You
can
just
focus
on
the
mappings.
D
As
for
the
best
practices
with
configuration,
obviously
you
get
the
most
out
of
it
when
you're,
using
that
separate,
distinct
role
approach,
so
that
you
can
trust
that
your
operators
are
just
going
to
focus
on
making
sure
things
are
set
up
for
you.
Your
developers
aren't
overburdened
worrying
about
how
to
configure
all
these
different
things
when
they
just
want
to
deploy
service,
and
then
each
person
can
focus
on
their
individual
tasks,
trusting
that
the
other
person
is
going
to
be
taking
care
of
that
side
of
the
world.
For
them.
D
This
really
empowers
teams
to
do
independent
releases
without
having
to
necessarily
worry
about
what
operations
is
doing
or
what
other
teams
are
necessarily
doing.
They
can
just
think
about
the
services
they're
developing
and
how
they
want
to
get
traffic
to
those.
It
also
means
that
you
don't
have
to
wait
for
ops
to
expose
the
services
you're
developing.
You
can
figure
out
exactly
how
you
want
to
expose
them,
and
do
it
really
quickly
with
a
small
amount
of
config.
D
Now
the
trust
between
teams
doesn't
necessarily
have
to
be
blind,
and
you
don't
have
to
give
everyone
just
total
access
to
your
cluster.
You
can
use.
Kubernetes
are
back
to
set
up
permissions
for
who
is
allowed
to
use
what
resources
apply,
resources,
configure
and
create
things
in
particular
we're
a
big
fan
of
this
tool
called
cube,
ctl
sudo,
that
can
let
you
set
up
permissions,
for
who
particularly
is
allowed
to
use
elevated
permissions
when
working
in
the
cluster
and
who
might
necessarily
just
have
only
read
configurations.
E
We'd
have
both
options,
and
so
now
we're
getting
rid
of
some
of
those
older
things.
So
we
used
to
have
this
used
websockets,
which
we
replaced
with
allow
upgrade,
which
is
more
capable,
more
flexible,
but
we've
been
supporting
both
and
so
in
v3
we're
removing
used
web
sockets
similar
deal
with
hosts
in
configuring,
which
host
names
a
map
end
matches.
There
used
to
be
this
kind
of
clunky
mechanism
with
host
and
host
regex
we've
we're
consolidating.
D
E
Things
to
make
them
easier
to
work
with,
and
also
adding
support
for,
dns,
globs
and
so
being
able
to
make
a
lot
of
these
cleanup
changes
is
what's
been
going
on
in
v3
and
a
a
bigger.
You
know.
Those
are
all
pretty
small
changes.
A
bigger
one
is
that
off
service
log
service
rate,
limit
service,
tracing
service
and
mappings
all
create
what
we
call
an
envoy
cluster
and
that's
essentially
a
thing
that
envoy
can
dial
out
to.
E
Alpha
one
right
now
or
v3
alpha
one
right
now
we're
going
to
be
working
toward
v3
as
we're
making
more
of
those
changes,
and
so
v3
beta1
should
be
happening
soon.
With
most
of
those
now
point
out
that
emissary
3.0
is
also
coming
soon
and
flynn's
going
to
talk
about
that
in
a
bit
those
the
progression
of
the
input
language
and
the
adversary
version
number
they
aren't
tied
together.
3.0
is
probably
happening
before
input
language,
v3
1,
you
can
happens.
E
So
we've
got
this
cool
conversion
layer
and
about
how
it
works.
Is
that
there's
one
version
that
you're
allowed
to
store
into
xcd
in
the
api
server?
And
so
when
you
create
a
v3
alpha
1
resource
today,
it
actually
converts
it
down
to
v2
to
get
stored
and
then
converts
it
back
up
to
v3
alpha
one
for
emissary
to
consume
it,
and
so
because
of
that
v1
is
very
central
to
how
things
are
actually
running.
E
And
so
you
can
be
sure
that
you
know
v2
support's
not
going
to
break
and
that
you
don't
have
to
worry
about
that
ever
breaking
and
that's
going
to
keep
being
the
storage
version
until
at
least
until
v3,
final
and-
and
there
are
several
reasons
for
that-
a
big
one
is
to
have
a
smooth
upgrade
path
from
emissary
1.0,
because
if
some
bugs
were
there
but
you're,
it's
going
to
keep
doing
conversions.
You
can
still.
You
don't
have
to
worry
about
any
of
these
changes
breaking
you.
E
You
can
still
keep
using
v2
or
v3
alpha
one
and
then
often
to
the
newer,
cleaner
stuff,
as
we
come
out
with
it.
So
we're
not
gonna
break
anyone,
and
you
know
we
are
trying
to
make
this
cleaner
and
easier
to
use,
and
so
feedback
would
be
very
welcome
about.
You
know
what
are
some
of
the
friction
points
that
we
could
improve
now
related
to
going
forward
with
new
api
with
new
input
languages.
E
So
there
are,
we
are
one
of
the
two
cncf
gateway
projects,
there's
another
one
called
contour
and
in
a
lot
of
ways,
emissary
and
contour
are
very
similar,
both
functionally
and
like
architecturally,
and
so
we're
do.
We've
been
duplicating
a
ton
of
effort
between
these
two
projects
and
so
envoy
gateway
is
less
coming
together
and
saying:
let's
you
know
collaborate
instead
of
duplicating
the
effort
and
it's
not
just
emmissary
and
contour
folks
coming
together.
E
We're
going
to
keep
is
we're
not
going
to
stop
working
on
I'm
sorry,
you
know
tomorrow
and
start
working
on
a
boy
gateway,
we're
going
to
be
working
on
both
in
parallel
for
a
while,
and
but
you
know
what
about
after
that,
what's
the
long-term
outlook
on
emissary?
Well
we're
going
to
be
transitioning.
The
long-term
plan
is
to
transition
emissaries
to
be
built
on
top
of
android
gateway.
E
They're
in
you
know,
I'm
involved
with
both
projects,
and
so
I'm
going
to
be
making
sure
that's
one
of
my
roles
in
envoy
gateway
to
be
making
sure
that
it's
capable
of
hosting
emissary-
and
there
are
some
and
emissaries
long-term
perspective-
is
that
there
are
a
lot
of
things
that
it
does.
That
envoy
gateway
is
just
not
interested
in
doing,
and
so
envoy
gateway
is
supporting
gateway.
Api,
0.5
and
later
0.5
is
not
out
yet,
but
you
should
turn
into
tomorrow's
gateway.
E
Api
talk
to
learn
more
about
hear
more
about
that.
Hopefully,
but
so
emissary
can
take
that
get
ambassador
io
language
that
alice
was
talking
about
earlier.
It
can
take
the
k
native
language,
it
can
take
the
old
ingress
api
language.
It
can
take
the
old,
older
versions
of
the
gateway
api
language.
That
angle
gateway
is
just
not
interested
in,
and
so
this
allows
you
to
have
compatibility
between
some
different
systems
and
that's
you
have
migration
paths,
and
so
misteri
is
still
delivering
value
there.
E
It
will
continue
to
deliver
that
value
and
also
envoy
gateway
itself
is
in
cons,
isn't
interested
in
watching
resources
other
than
from
kubernetes.
If
emissary
lets
you
do
this
read
config
from
other
places,
namely
console,
and
that
will
never
be
part
of
onboard
gateway,
that's
not
on
its
roadmap
and
so
emissary
you
can
think
of
it.
You
know
it's
going
to
keep
doing
these
things
and
hopefully
have
a
even
a
better
base
as
we
get.
We
join
forces
on
engineering
for
that
base.
A
A
The
self-service
thing
really
does
turn
out
to
work
very
well,
especially
that
separation
of
concerns,
where
you
can
have
developers
worrying
about
applications.
While
other
people
are
worrying
about
infrastructure,
they
can
support
each
other,
but
they
don't
have
to
get
tied
up
with
each
other.
It
does
take
a
certain
amount
of
trust.
It
can
take
some
time
to
establish
that
trust,
but
in
our
experience
it's
been
worth
it
to
do
so
and
to
continue
forward.
A
Luke
talked
some
about
the
input
language
changes.
I'd
like
to
reiterate
that
we
really
do
believe
that
the
version
three
stuff
is
the
way
to
go.
We're
actively.
Looking
for
feedback
on
that,
one
v2
will
still
be
supported.
We
think
that's
important
there.
There
have
been
a
lot
of
burn
fingers
getting
us
to
b3
and
the
lessons
that
we
learned
that
learned
doing
that
and
getting
burns
doing.
That
are
things
that
we'd,
like
you
all,
to
benefit
from
luke
also
was
talking
about
the
envoy
gateway
short
takeaway
from
that
is
really.
A
A
A
This
includes
the
transport
protocols
that
emissary
uses
to
talk
to
external
auth
and
rate
limit
services.
So
emissary
2
already
supports
the
envoy
v3
it.
Yes,
it
is
annoying
that
there
are
so
many
twos
and
threes
here.
I'm
really
sorry
about
that.
Emissary
2
already
supports
the
newer
transport
protocols.
There
is
nothing
preventing
anybody
from
going
ahead
and
switching
to
envoy
v3
right
now
before
3.0
comes
out
once
3.0
comes
out
once
emissary
3.0
comes
out,
the
old
v2
transport
protocols
will
not
be
supported.
That's
important!
There
are
going
to
be
new
features
in
3.0.
A
Can't
really
talk
about
those
yet
sorry,
but
the
biggest
driver
for
calling
it
3.0
is
that
breaking
change
under
the
hood.
So
I'd
like
everybody
to
be
prepared
for
that
one
kind
of
restate
the
obvious
here:
there's
no
possible
way.
We
would
have
gotten
this
far
without
the
community.
So,
thank
you
very
much
for
that
again.
A
If
you're
interested
in
getting
involved,
please
be
interested
in
getting
involved
a
great
way
to
do.
That
is
to
just
join
our
slack
channel.
All
three
of
us
are
easily
reachable
there.
I'm
also
not
gonna
lie.
I
have
to
acknowledge.
2021
was
kind
of
rough
in
terms
of
contributor
fiction
and
we
are
actively
working
on
making
that
better
right
now.
A
B
A
B
E
A
Is
actually
yeah,
I
was
gonna
to
extend
that
a
little
bit
x,
dot
z,
works
by
every
request
that
comes
into
envoy
envoy,
turns
around
and
asks
the
external
authentication
service.
Hey.
Is
this
okay
and
the
auth
service
gets
to
use
really
whatever
resources
it
wants
to
decide
whether
it's
okay
and
then
come
back
and
either
tell
envoy.
This
is
good
to
go
or
come
back
and
say:
no,
it's
not!
Okay!
You
should
respond
to
the
user.
A
C
E
C
E
With
the
you
want
the
communications
with
the
regular
service
to
be
pretty
lightweight,
because
that's
what
you're
counting
on
to
stop
you
from
overloading
all
of
the
other
stuff?
And
so
if
you
want,
you
know
to
say,
hey
envoy,
I
want
you
to
buffer
the
whole
body
to
pass
it
to
my
rate
limit
service.
E
That's
going
to
be
adding
a
bunch
of
overhead
that
you
probably
don't
want
in
your
rate
limit
system,
and
so
you
can
get
several
pieces
of
metadata
and
hopefully
it's
enough,
and
so
you
know,
even
if
you
did
want
to
say,
okay
rate
limit
service
for
kind
of
tier
one
filtering
and
then
more
advanced
stuff
using
the
body
with
a
an
auth
service.
That's
acting
like
a
limit
service.
You
could
do
that.
That
probably
wouldn't
be
bad,
but
you
probably
don't
want
that
level
of
everything.
In
the
first
level
rate,
limiting.
B
A
F
A
A
E
E
You
know
we
we're
not
reinventing
the
wheel,
there's
a
bunch
of
code
from
emissary
and
from
contour
that
we're
going
to
be
borrowing
and
I'm
going
away,
but
it's
going
to
be
a
while
before
it's
useful
and
then
even
once
it
is
you
know,
emissary
is
going
to
still
exist
still
be
built
on.
It
still
have
some
added
value
that
you
wouldn't
get
from
ongoing
gateway.
Okay,
thank.
F
A
E
E
But
we
do
have
the
extension
points
for
it
to
integrate.
I
I
there
are
laughs.
I
know
of
that
use
the
xdoth
integration
point
to
be
able
to
see
the
request
coming
in
and
then
also
use
the
law,
the
access
log
service
to
have
the
view
of
request
to
be
able
to
notice
suspicious
patterns,
and
that's
actually
specifically,
why
we
added
the
log
service
in
order
to
facilitate
that
waff
extension
point
use
case.