►
From YouTube: Gateway API: A New Set of Kubernetes APIs for Advanced Traffic Routing - Harry Bagdi & Rob Scott
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Gateway API: A New Set of Kubernetes APIs for Advanced Traffic Routing - Harry Bagdi, Kong Inc. & Rob Scott, Google
Existing networking APIs like Ingress and Service were designed in the very early days of Kubernetes. They got many things right, but it was quite difficult or even impossible to use those APIs for more advanced use cases. This resulted in a proliferation of implementation-specific annotations and custom resources that fragmented the user experience and have proven to be difficult to evolve. The Kubernetes networking SIG has been developing a new set of APIs that aim to solve these problems. The Gateway APIs project defines Kubernetes APIs to configure advanced concepts like traffic splitting, header matching, and load balancing configuration. In this talk, Harry and Rob will provide an overview of these APIs and some insight into the design decisions that have been made along the way. They will demo some of the advanced capabilities of these APIs, showcasing the portability of the APIs across implementations. Finally, they will provide a roadmap for the future of this project.
A
Hello,
everyone
welcome
to
this
talk
on
gateway
api,
a
new
set
of
kubernetes
apis
for
advanced
routing,
I'm
harry
bachty.
I'm
a
software
engineer
at
kong
and
with
me
today.
I
have
rob
scott,
who
is
a
software
engineer
at
google.
We've
been
working
on
this
new
api
for
a
while
and
want
to
take
some
time
today
to
introduce
you
to
the
api
and
demonstrate
some
use
cases
that
it
enables
for
the
problems
that
you
might
be
facing
before
we
get
started.
A
A
Users
have
expressed
the
need
for
more
complicated
and
advanced
use
cases,
and
this
has
resulted
in
a
wide
variety
of
annotations
to
extend
the
ingress
resource.
Now,
all
these
annotations
do
get
the
job
done.
They
result
in
a
very
poor
user
experience.
As
you
know,
annotations
are
free
for
form
strings,
so
users
have
no
validation.
A
There
is
no
consistency
between
features
of
different
implementations
and
so
on.
At
the
same
time,
we
have
the
service
resource,
which
is
seeing
almost
the
similar
problems
as
ingress
resource.
It,
too,
is
getting
a
lot
of
custom
annotations
and
it
is
now
becoming
bloated
with
features
which
concern
different
areas
of
kubernetes.
A
One
such
area
is
load.
Balancing
and
it's
been
getting
a
lot
of
load
balancing
features,
the
resource
has
become
complicated
enough
that
it's
now
proving
to
be
a
little
difficult
to
manage
and
evolve
as
we
go
on,
so
these
problems
have
existed
for
a
while
and
then
at
cube
consent,
san
diego
in
2019,
we
came
together
and
an
idea
started
floating
around
on
how
a
new
api
could
be
used
to
solve
these
problems.
A
A
A
That
means
bob
is
responsible
for
administration
of
the
entire
cluster,
which
includes
day
two
operations
like
network
access
management,
ensuring
that
applications
have
the
right
permissions
and
application
developers
also
have
the
right
permissions
to
deploy
their
applications
under
the
cluster
carol
is
finally,
our
application
developer.
Who
is
going
to
use
the
cluster
that's
been
set
up
by
alice
and
bob
to
deploy
her
application,
which
means
she
is
responsible
for
application,
as
well
as
routing
configuration.
A
So
first,
when
alice
creates
new
kubernetes
clusters,
she
ensures
that
each
cluster
gets
provisioned
with
two
gateway
classes,
an
external
lb
and
an
internal
lb.
Now,
what
is
the
gateway
class?
Really
a
gateway
class
is
a
way
to
abstract
away
a
type
of
load,
balancing
infrastructure
that
is
available
within
the
cluster,
so
external
lb
and
internal
llb
here
represent
a
kind
of
load,
balancing
infrastructure
and
these
two
gateway
classes
are
being
controlled
by
a
controller
called
acme
dot,
io,
slash
gateway
controller.
A
What
this
results
in
is
behind
the
scenes
when
a
gateway
resource
is
created,
an
external
load
balancer
is
provisioned
for
the
cluster,
and
the
load
balancer
here
is
listening
on
port
80
for
http
requests
and
as
requests
come
in.
Those
requests
are
made,
matched
based
on
http
route
resources
notice,
how
we
have
a
selector
label
here
with
the
key
of
gateway
and
the
value
of
acme
external.
A
This
would
feel
a
little
similar
to
how
service
resource
has
a
label
selected
for
pods,
so
once
bob
has
the
gateway
resource
created,
carol
can
finally
deploy
her
application,
so
carol
goes
ahead
and
creates
an
http
route
resource
with
the
same
label.
As
you
can
see
here
now.
This
resource
would
feel
very
familiar
to
a
lot
of
you,
as
it
relates
very
closely
with
the
ingress
resource
that
we
already
have
in
kubernetes
here.
A
So
this
gives
a
an
overview
of
how
bob
alice
and
carol
work
together
to
deploy
this
e-commerce
store
application
to
their
kubernetes
cluster
using
gateway
api.
Now
you
might
ask
a
question:
this
was
already
possible
with
ingress.
Why
should
we
use
gateway
api,
which
seems
a
little
more
complicated
than
ingress
resource
and
the
answer?
There
is
gateway.
Api
really
shines
with
day
two
operations,
so,
let's
say,
for
example,
carol
wants
to
do
a
canary
rollout
of
a
new
version
of
her
application.
B
A
Now,
at
the
same
time,
imagine
that
bob
wants
to
test
out
a
new
load
balancer
that
their
provider
has
exposed
to
them.
So
here
bob
goes
ahead
and
creates
another
gateway
resource
with
the
new
gateway
class
and
notice
how
the
listener
sections
here
for
the
old
and
the
new
gateway
are
exactly
similar.
A
A
Now.
Next
imagine
that
alice
is
provisioning,
a
clusters
in
new
environments
and
for
some
reason
you
have
to
use
a
different
vendor
in
these
two
environments.
So
in
one
cluster,
the
implementation
from
vendor
a
is
being
used,
while
the
other
cluster
gateway
api
implementation
from
vendor
b
is
being
used.
Now,
even
though
there
are,
these
are
two
different
environments.
A
We
do
not
expect
users
to
deal
with
gateway
and
gateway
class
resource
on
a
day-to-day
basis.
Those
would
change
much
more
infrequently
now.
Why
is
this
hierarchical
model?
Important
and
it's
important,
because
we
are
dealing
with
a
shared
infrastructure
problem
here
with
shared
infra
users
want
maximum
flexibility
to
make
optimal
use
of
shared
resources,
but
at
the
same
time
they
want
a
centralized
control
over
that
shared
resources.
A
This
is
to
ensure
governance
and
proper
administration
and
make
sure
that
the
resources
are
utilized
fairly
and
correctly,
and
to
do
that,
roles
are
mapped
to
each
resource
type,
as
we
have
seen
in
our
example,
the
infrastructure
infrastructure
provider
takes
care
of
the
gateway
class.
The
cluster
operator
takes
care
of
the
gateway
resources
and
then
application
developers
create
route
resources.
B
B
B
We
don't
want
people
to
have
to
rely
on
all
kinds
of
custom
annotations
or
whatever
to
stack
onto
this
api.
We've
built
very
intentional
extension
points
throughout
this
api
to
ensure
that
not
only
can
it
support
lots
of
core
use
cases,
but
also
your
custom
implementation,
specific
use
case
if
desired.
B
So
how
can
we
really
make
this
portable?
How
can
we
really
achieve
this
goal?
We
have
you
know
pretty
big
goal
here
of
covering
a
broad
surface
area
and
still
making
it
portable.
So
how
can
we
do
that?
Well,
first,
we
do
want
that
wide
set
of
functionality
in
the
core
api,
but
we
also
want
to
ensure
that
whatever
doesn't
fit
in
the
core
api
is
easy
to
add
in
either
through
custom
route
types
or
really
ways
to
extend
existing
types
that
we
already
have.
We
have
custom
filters.
B
We
have
really
extension
points
throughout
different
resources
that
feel
very
natural
and
also
patterns
to
extend
the
api
by
attaching
policy
or
other
types
of
resources.
And
finally,
we
want
to
establish
three
unique
conformance
levels.
So
what
we've
decided
here
is
we'll
have
core
extended
and
custom
support
levels,
so,
instead
of
an
all
or
nothing
approach
where
you're,
either
conformant
with
the
api
or
you're
not,
we
have
core
features
that
we
expect
every
implementation
to
be
fully
conformed
with.
But
then
we
also
have
extended
features
which
we
recognize.
B
Not
everyone
is
going
to
be
able
to
support,
but
of
the
implementations
that
support
it.
We
expect
them
to
follow
a
specific
set
of
patterns
that
are
lined
up
out
in
the
stack
and
finally,
we
make
room
for
custom
conformance,
which
is
really
just
that
last
tier
of
implementation,
specific
features
and
implementations
of
concepts.
B
So
a
key
concept
in
this
api
is
that
of
routes
and
most
of
our
demos,
and
most
of
the
talk
so
far
has
focused
on
http
route.
But
I
want
to
take
some
time
to
mention
that
we
have
other
route
tags.
We
have
tcp
route,
udp
route,
tls
route
and,
of
course,
we've
left
room
open
to
add
additional
route
types.
We
envision
that
there
will
probably
be
more
route
types
added
to
the
core
api,
but
in
addition
to
that,
implementations
may
want
to
add
their
own
custom
route.
B
B
Now,
when
we
talk
about
routes,
we
really
have
to
talk
about
how
they're
connected
to
gateways-
and
the
key
thing
to
remember
is
it's
a
two-way
handshake
between
gateways
and
routes,
so
really
routes
and
gateways
both
have
to
agree
that
they
can
be
bound
to
each
other.
That
may
sound
a
little
complicated,
but
keep
in
mind
that
within
the
same
namespace
we
have
some
pretty
same
defaults.
B
This
is
a
really
powerful
concept
that
I
think
can
be
used
really
well.
But
when
that
happens,
we
really
want
to
make
sure
that
both
the
gateways
and
routes
are
on
board
and
that's
why
we
have
this
kind
of
two-way
handshake
where
both
the
gateway
and
route
have
to
agree
with
it,
and
you
can
read
more
on
our
docs.
We
don't
have
enough
time
to
cover
it
in
proper
detail
here,
but
that's
a
core
concept
of
this
api.
B
And
finally,
we
can't
talk
about
this
without
talking
about
ingress,
because
ingress
is
really
a
lot
of
inspiration
for
this
api
and
you
may
be
wondering
well,
okay,
what's
happening
to
the
ingress
api
and
I'll
say
that
I
know
of
no
plans
to
deprecate
or
remove
this
api
anytime
in
the
near
future.
I
think
it's
going
to
be
around
for
a
very
long
time,
where
possible
we're
trying
to
port
concepts
back
to
ingress.
B
So
as
an
example,
there
are
tiny
little
tweaks.
We've
made
to
the
ingress
api
to
help,
keep
it
consistent
and
up
to
date
with
the
gateway
api,
but
I
should
say
that
a
lot
of
the
new
functionality
we're
adding,
although
it
fits
very
naturally
inside
the
gateway
api,
it
doesn't
really
fit
well
inside
the
ingress
api.
B
In
this
case,
we've
got
a
acme,
contour
gateway
and
a
acme
store.
Hdb
route
that
we're
going
to
use
to
publish
the
acme
store,
so
this
will
look
familiar,
but
we
have
a
very
basic
gateway.
It's
listening
on
port
80
and
it
supports
http
routes
and
it
will
match
or
bind
to
any
route
that
has
the
label
gateway,
acme
external.
B
B
We
can
use
that
to
make
some
simple
curl
requests,
but
first
we
want
to
get
a
quick
overview
of
the
service,
acme
store
and
the
pods
that
we'll
actually
be
routing
to
now,
when
we
do
a
simple
curl
request
against
that
ip
address,
you
can
see.
The
pod
name
is
one
of
those
acme
store
pods.
So
it's
getting
routed
correctly.
The
reason
we
know
this
is
all
the
containers,
through
all
our
demos
are
going
to
be
using
a
where
my
image
that
prints
out
all
this
useful
information
for
us.
B
B
Our
second
demo
is
really
just
an
extension
of
the
first
one
and
in
this
case
we're
going
to
add
a
gateway
with
istio.
Now
this
is,
admittedly,
a
really
simple
demo.
We
take
the
existing
configuration
we
already
had
in
the
first
demo
and
we
just
had
an
a
new
istio
gateway,
and
you
may
look
at
this
and
say
well
yeah.
This
is
really
simple
and
that's
by
design
you
can
imagine.
B
This
has
really
cool
implications
when
you're
starting
to
talk
about
day,
two
operations
you've
had
gateways
running
for
a
long
time,
and
you
want
to
test
an
update.
You
want
to
test
new
configuration
or
a
new
implementation
or
just
a
different
vendor
altogether.
Whatever
it
happens
to
be,
you
can
just
spin
up
a
new
gateway,
send
traffic
to
it
and
see
what
happens
alongside
your
existing
gateway.
That's
continuing
to
serve
all
your
production
traffic
without
issue.
Now
you
can
reuse
all
your
routes,
you
don't
need
to
reconfigure
anything
below
the
stack.
It
just
works.
B
You
can
just
add
a
new
gateway,
so
you
can
imagine
if
you're
trying
to
do
seamless
replacement
for
gateways
smooth
upgrades
whatever
it
happens
to
be.
This
is
a
really
powerful
concept,
but
also,
I
think
this
shows
just
how
powerful
the
portability
component
of
this
api
is,
so
we're
going
to
take
a
new
gateway,
and
this
is
going
to
be
really
identical
to
the
gateway
we
showed
for
contour,
but
instead
we're
going
to
use
the
istio
gateway
class.
B
B
So
this
example
may
look
familiar
to
you
we're
going
to
do
canary
traffic
splitting,
but
instead
of
before,
where
we
did
percentage
based
traffic
splitting
we're
going
to
do
something
a
little
bit
differently.
We're
going
to
say
any
request
that
has
a
specific
header
should
go
to
our
canary
service
and
everything
else
should
go
to
our
stable
service.
B
B
A
B
This
is
still
traffic
splitting,
but
the
difference
is
that
we
have
three
different
clusters
involved
here,
so
we
have
a
cluster
one,
which
is
includes
store
c1
as
a
service.
We
have
cluster
two,
which
includes
store
c2
as
a
service,
and
then
we
have
a
config
cluster
which
has
a
gateway
and
a
route
that's
targeting
both
of
these
services.
B
B
B
So
again,
let's
take
a
quick
look
at
our
gateway.
This
is
also
going
to
look
very
similar,
but
we're
using
a
gke
gateway
class
instead
and
one
detail.
I
want
to
point
out
in
this
specific
example
we're
using
an
internal
load
balancer
instead
of
an
external
one,
there
will
be
a
number
of
gka
gateway
classes
supported
by
this
api,
but
in
this
case
I
wanted
to
show
what
an
internal
load
balancer
looked
like
now.
B
B
So
let's
talk
about
our
roadmap.
One
of
your
first
questions
is
probably
how
can
I
use
this?
How
can
I
test
this
out
and
the
great
news
is
there's
already
some
awesome
implementations
in
progress.
We've
got
contour
gke,
istio,
kong,
solo
and
trafic,
and
in
many
cases
these
implementations
are
already
ready
for
you
to
test
out.
B
We're
working
on
conformance
tests
and
web
hook
validation,
we're
hoping
to
release
v1
beta
1
later
this
year
and
that
will
bring
much
more
api
stability.
But
until
we
get
to
that
point,
we
can
still
make
significant
changes.
So
your
feedback
in
the
next
few
months
is
critical.
If
you
have
ideas
for
how
we
can
improve
this
api,
how
we
can
change
this
api,
please
let
us
know
we
have
community
reading
meetings
every
wednesday
everyone's
welcome.
It's
an
open
agenda
feel
free
to
add
something
to
the
agenda,
create
a
github
issue,
whatever
it
is.
B
We'd
love
your
ideas
and,
of
course,
we're
on
slack,
find
our
slack
channel
we're
sig
network
gateway
api
and
ask
any
questions.
Join
the
discussion,
whatever
it
might
be,
and
finally,
if
you're
just
interested
in
more
information
about
the
api
check
out
our
website,
that's
gateway,
api.sigs.ks.io
thanks.
So
much
for
your
time
have
a
great
rest
of
your
coop
con.