►
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.
Exiting Ingress With the Gateway API - Rob Scott, Google & Shane Utt, Kong, Inc.
Speakers: Rob Scott, Shane Utt
Are you currently using Ingress but curious about what Gateway API is? Wondering if you should switch to Gateway API or how that would even work? This is the talk for you. The development of Gateway API has unlocked a wide set of new capabilities within Kubernetes, but it can also be overwhelming to understand the full scope of it. In this talk, Rob and Shane will answer some of the most common questions they get as Gateway API maintainers, including what you gain over using the Ingress API. They’ll walk through a step-by-step demo of what it takes to get started with Gateway API. This demo will show you how to migrate from Ingress to Gateway API and showcase some of the newest features in Gateway API, including traffic splitting between backends in different namespaces.
B
A
So
let's
do
an
overview
of
these
apis,
real,
quick.
Let's
take
a
look
at
what
we're
talking
about
so
the
Ingress
API,
which
everybody's
familiar
with
it's
pretty
simple.
You
can
do
host
and
path
matching.
You
can
forward
to
a
service.
You
can
do
TLS
configuration
it's
been
around
for
a
long
time
and
there
are
lots
of
implementations
like
22
plus
implementations.
A
There
are
some
limitations
of
the
Ingress
API,
there's
not
enough
features,
and
this
ended
up
leading
to
custom
extensions
everywhere,
so
extensions
that
were
they
were,
and
the
biggest
problem
was
extensions
that
weren't
portable,
like
the
traffic
splitting
header
matching
and
sticky
sessions,
were
some
notable
ones
became
this
annotation
Wild
West.
Also
it
had
an
insufficient
permission
model,
so
Gateway
API
intends
to
be
the
next
generation
of
kubernetes
routing
and
load
balancing
apis.
It's
designed
to
be
expressive
role
oriented.
We
have
15,
plus
implementations
right
now
and
we
graduated
to
Beta
in
July.
B
So
if
you
take
a
look
at
this
diagram
over
on
the
left,
you're
going
to
see
that
in
Gateway
API,
we
have
three
main
kinds
of
resources.
We
have
the
Gateway
class
if
you're
familiar
with
the
Ingress
class
resource
before
it
Gateway
class
is
nearly
identical.
Then
we
have
HD
HP
route
and
a
bunch
of
other
route
types
at
the
bottom,
we'll
focus
on
HTTP,
because
it's
the
most
similar
to
Ingress,
but
we'll
show
you
very
soon
that
HTTP
route
and
the
Ingress
resource
are
also
very
similar.
B
Gateway
is
kind
of
a
New
Concept
in
this
API
and
we'll
be
talking
about
that
just
a
little
bit
after
now,
Gateway
API
has
a
ton
of
features.
I
know
that
we've
got
lots
of
feature
requests
throughout
kubernetes
networking.
For
many
of
these
things,
whether
it's
request,
redirects
rewrites
header,
matching
method,
matching,
there's
a
lot
of
things
in
here
that
we've
had
feature
requests
for
a
long
time.
Gateway
API
finally
allows
you
to
do
many
of
these
things,
but
some
of
you
may
say
hold
on
you
know.
I
can
do
this
with
Ingress.
B
You
may
be
wondering
like
how
on
Earth.
Can
you
provide
all
these
new
features?
When
not
everyone
can
Implement
everything
to
accomplish
that?
We
introduce
the
concept
of
conformance
levels.
It's
a
very
important
concept
to
understand
in
Gateway,
API
every
feature.
Every
field
in
Gateway
API
is
assigned
one
of
these
conformance
levels
to
start
most
of
our
features
and
fields
are
our
core
conformance
level.
This
is
similar
to
Ingress.
B
Every
single
implementation
has
to
implement
that
field
or
feature,
and
do
it
in
a
conformed
way
that
passes
our
conformance
tests,
but
we
recognize
that
not
every
implementation
can
Implement
everything.
So
we
have
another
layer
and
that's
called
extended.
So
an
example
of
this
would
be
header
matching,
so
where
prefix
matching
might
be
core
header,
etching
is
just
not
quite
everyone
can
support
it.
B
So
we
have
conformance
test
coverage
for
this
and
if
your
implementation
can
support
it,
you
document
that
well,
but
otherwise
we
recognize
not
quite
every
implementation
of
the
API
is
going
to
be
able
to
cover
that
and
then
finally,
we
have
a
custom
category.
There
is
very
little
in
this,
but
if
anyone's
familiar
with
regular
Expressions
anyone
deal
with
regular
Expressions
out
here,
okay
yeah
so
they're
a
special
thing.
B
So
with
regular
Expressions
you
may
you
may
realize,
there's
some
variation
depending
on
the
underlying
implementation,
so,
whether
you're
talking
to
you
know
nginx
version
of
regular
expressions
or
Envoy
or
AJ
proxy
or
whatever
Cloud
you're,
using
the
variation
of
regex.
That
supporters
is
going
to
be
slightly
different,
so
custom
means
we
understand
this
concept,
but
it
may
not
be
completely
portable
across
your
implementation.
B
B
First,
off
we're
going
to
look
at
the
simplest,
Ingress
and
HP
route
resource
I
can
think
of
we're
going
to
walk
through
step
by
step,
step
and
see
the
parallels
between
them.
Now,
first
off
in
Ingress
we
have
a
concept
of
Ingress
class
name.
So
in
this
example,
our
Ingress
is
being
implemented
by
nginx
now
in
HP
route.
What
we
have
is
a
parent,
refs
concept,
and
this
says
Hey
attach
this
HP
route
to
the
gateway
called
nginx.
B
You
can
attach
HP
routes
to
more
than
just
gateways,
but
we're
focusing
on
gateways
now
and
I
know
many
of
you
don't
even
know
what
a
Gateway
is
yet
we'll
get
there
I
promise,
but
just
we
point
up
to
a
thing
called
the
nginx
gateway
next
step.
We
want
to
do
a
prefix
path
match
on
login
and
you
can
see
these
apis
look
nearly
identical
and
then
finally
they're
both
forwarding
to
the
auth
service
on
Port
8080..
B
So
starting
off,
you
can
see
there's
a
lot
of
similarities
here,
but
let's
extend
this
example
just
a
little
bit.
Let's
say
that
we
want
to
add
another
implementation
of
our
HTTP
route,
so
in
Gateway
API.
That
would
mean
I
want
not
just
the
nginx
gateway
to
implement
this
HTTP
route,
but
I
also
want
the
Contour
gateway
to
implement
this
HTTP
route,
and
in
this
case
you
just
attach
another
parent
ref,
so
you're
saying
not
only
do
I
want
the
nginx
Gateway
I
want
the
Contour
gateway
to
implement
this.
B
B
Now,
let's
say
you
wanted
to
add
another
path
match
so,
for
example,
let's
say
in
addition
to
matching
path,
paths
that
start
with
Slash
login.
Maybe
we
want
to
do
an
exact
match
on
slash
auth.
This
is
pretty
straightforward
in
HTTP
route,
just
a
couple
lines
you
can
do
the
same
thing
in
Ingress,
but
again
it's
just
a
little
bit
more
verbose.
B
So
you
may
see
a
pattern
here
that
the
same
things
are
possible,
but
maybe
just
a
little
bit
simpler
with
Gateway
API.
Now,
adding
a
host
match,
let's
say
I
only
want
to
match
requests
to
example.net
again.
This
starts
very
similar,
but
some
of
the
people
that
are
paying
extra
close
attention
may
be
able
to
see
where
I'm
going
with
this
one.
Let's
see
what
happens
when
we
try
and
add
another
host
match,
so
we
want
to
match
example.net
and.com
with
HP
route.
You
just
add
one
item
to
the
list
and
you're
done
with
Ingress.
B
A
So
Rob
alluded
to
gateways
via
parent
ref,
so
parent
refs
point
to
gateways
in
Gateway
API
Gateway
is
an
actual
resource,
so
in
Gateway
API
we
have
Gateway
class,
which
is
like
Ingress
class.
This
tells
you
like
your
controller.
What
routes
am
I
responsible
for
and
as
we
just
talked
about,
Ingress
and
HTTP
route
have
similarities,
but
we
now
have
Gateway
kubernetes
resource
this
lets.
You
represent
your
load,
balancer
your
proxy
as
a
kubernetes
resource.
A
There
are
a
couple
common
types
of
implementations
today:
I
represent
working
at
Kong
and
in
cluster
implementation,
so
we
deploy
a
Gateway
resource
and
then
that
ultimately
results
in
the
the
proxy
the
Gateway
being
deployed
in
a
pod
on
the
actual
cluster,
the
addresses
are
usually
provisioned
with
a
service
type
load
balancer,
and
this
behaves
the
same
way.
It's
portable.
It
goes
on
any
kubernetes
cluster
and.
B
I
work
at
Google
and
so
I
work
on
gke's
implementation
of
Gateway
API.
So
that's
representative
of
a
cloud
provider
implementation
of
this
API.
So
when
you
create
a
Gateway
with
a
gke
Gateway
class,
what's
going
to
happen,
is
we're
going
to
provision
a
cloud
load
balancer
behind
the
scenes
to
represent
that
Gateway?
So
in
in
case
of
GK,
we
have
an
ilb
Gateway
and
an
xlb
Gateway,
depending
on
what
you're
most
interested
in
I
an
advantage
of
a
cloud
provider.
B
A
So
talking
a
little
bit
more
about
route
attachment
routes
attached
to
gateways
of
parent
West
fields,
we
did
that
the
same
route
route
can
be
attached
to
multiple
gateways.
So
if
you
needed
to
migrate
between
implementations
or
if
you
needed
two
implementations
to
serve
the
same
route,
you
can
do
that.
So
in
this
case
we
have
nginx
and
Contour
both
serving
the
same
route.
Gateway
owners,
the
ones
who
make
the
Gateway
resources
can
specify
where
those
routes
can
come
from.
A
This
is
our
concept
of
allowed
routes,
so
developers
can
attach
their
routes
to
gateways
in
different
namespaces.
So
in
this
example,
we
can
set
trusted
name
spaces
for
attaching
routes
to
a
Gateway.
So
there's
two
listeners
here
both
of
them
are
just
doing.
Http
store.example.com
only
allows
attachments
of
routes
from
the
namespace
as
a
labeled
store
and
then
api.example.com
only
allows
those
attachments
from
namespaces
labeled
API.
This
is
optional
extension,
but
because
same
namespace
just
works,
but
it's
something
that
you
can
do
to
kind
of
make.
That
distinction.
B
So,
let's
walk
through
a
couple,
Advanced
examples
here,
as
I
said,
we
get
a
lot
of
feature
requests
and
I.
I
live
mostly
in
the
world.
I
used
to
be
an
end
user
of
kubernetes,
but
I
may
have
gotten
just
a
little
bit
detached
so
back
when
I
was
using
kubernetes
more
I
thought
that
something
called
Canary
routing
or
traffic
splitting
was
a
pretty
common
thing
that
I
wanted
to
do
a
lot.
Anyone
else
want
to
do
traffic
splitting
anyone,
okay,
good.
B
Okay,
we
put
a
lot
of
effort
into
this,
so
I'm
glad
that
it
actually
worked.
It's
something
that
people
will
appreciate
and
use
now
throughout
these
two
examples:
I'm
going
to
show
you
how
it
was
possible
with
Ingress
today,
thanks
to
some
very
creative
implementations
that
built
things
on
top
of
Ingress
API
and
then
how
we've
made
it
easier
with
Gateway
API
so
first
to
understand
what,
in
this
case,
Canary,
routing
or
traffic
splitting
is
doing.
B
The
idea
is
I
want
to
match
my
request
to
example.com
and
send
90
of
traffic
to
my
prod
service
and
then
10
of
traffic
to
my
canary
service,
and
you
can
think
of
many
different
examples
of
traffic.
Splitting
I
want
to
highlight
Ingress
nginx.
It
has
a
great
implementation
about
as
good
as
you
could
possibly
do
with
Ingress
API
and,
as
we
alluded
to
annotations,
were
the
way
you
extended
the
Ingress
API.
B
So
you
have
one
Ingress
resource
that
allows
you
to
send
your
traffic
to
production,
and
then
you
create
a
second
Ingress
resource
and
that
allows
you
to
send
10
of
your
traffic
to
your
Canary,
endpoint
and
you're
doing
that
with
those
annotations
there.
So
this
was
possible
with
some
creative
implementations
of
the
Ingress
API.
We
tried
to
make
this
easier
and
Native
and
portable
with
Gateway
API.
So
instead
you
have
a
single
HP
route
and
you
just
have
some
traffic
splitting.
B
B
B
Right,
I
I,
think
some
of
you
in
here
may
have
seen
this
inside
hold
on
a
second.
This
doesn't
look
quite
right.
This
doesn't
seem
safe
and
and
if
you
had
those
eyes
of
caution
like
hold
on
a
second
good
for
you,
I
I
understand
this
is
something
that
does
not
seem
good
on
the
surface,
because
you
know
just
being
able
to
reference
any
Secret
in
any
other
namespace
without
any
safety
mechanism
is
probably
not
the
best.
So
in
Gateway
API,
we
built
something
to
enable
this
safely.
B
A
handshake
mechanism,
I
created
a
reference,
a
resource
called
reference
Grant,
and
this
allows
you
to
complete
the
handshake.
So
you
have
one
resource,
that's
saying
in
this
case
a
Gateway
saying:
I
want
to
reference
this
Secret
in
another
namespace,
and
then
you
have
a
reference
Grant
in
that
namespace
that
says
I
own.
The
secret
and
I
trust
references
from
gateways
in
that
other
namespace.
B
A
So
you're
probably
wondering
should
I
switch,
maybe
not
so
if
Ingress
API
and
the
Eco,
if
the
Ingress
API
is
doing
it
for
you
like.
If
you
have
everything
that
you
need
there,
you
may
not
want
to
switch,
but
if
you
one
thing
that's
important
to
realize
is
that
Ingress
is
really
not
going
to
get
new
features.
It's
kind
of
complete,
so
the
Gateway
API
is
going
to
have
a
lot
of
new
features.
It's
more
expressive.
A
It's
extensible,
it's
portable,
but
in
addition
to
that,
we
also
just
are
going
broader
than
Ingress
we're
working
on
the
use
cases
for
mesh
L4
load,
balancing
we've,
so
we've
graduated
the
beta,
it's
ready
to
use
and
it
can
be
used.
It's
a
crd
based
API,
so
you
can
install
it
on
any
cluster
with
kubernetes,
116
or
greater.
If
you
are
using
something
less
than
116
we'd
like
to
kind
of
hear
from
you
afterwards,
we
just
kind
of
we're
just
just
genuinely
curious,
just
kind
of
like.
A
What's
going
on
so
to
get
started
like
I
said
it's
a
crd
implementation,
so
you
just
deploy
the
crds,
pick
an
implementation
and
then
follow
our
guides.
They
all
work
pretty
much
the
same,
so
you'll
just
deploy
a
Gateway
you'll
create
HTTP
routes,
attach
them
everything
we
just
showed
you
kind
of
previously.
A
There
are
several
here
are
several
great
implementations
that
we
have.
This,
isn't
an
exhaustive
list
that
you
can
get
from
the
from
our
website,
so
we
have
under
gateways
website
implementations.
You
can
just
kind
of
pick
the
one
that's
right
for
you
and
then
our
guides
should
kind
of
walk
you
through
the
rest.
B
So
yeah,
if
you
got
this
far,
if
you
may
have
read
our
talk
description
and
one
of
the
things
we
promised
is
that
we
were
going
to
show
you
from
start
to
finish
from
creating
a
cluster
all
the
way
to
using
it.
We
want
to
show
you
exactly
all
the
steps
involved.
There
aren't
many
to
use
this
API
so
in
this
case
I'm
going
to
use
gke
cluster,
but
of
course
any
kubernetes
cluster
will
work
on
gke.
B
We
offer
an
option
to
manage
these
crds
for
you,
but
again
you
can
just
install
them
in
any
kubernetes
cluster
same
thing
will
work
so
to
have
us
manage
crds
for
you,
you
just
add
a
Gateway
API
flag
when
you're
creating
a
cluster
or
updating
one
and
we'll
run
through
that
process.
Now,
I've
sped
this
up
a
little
bit
as
you
can
see.
B
B
Now
we
actually
want
to
get
our
Gateway
classes,
because
when
we
choose
GK
on
Gateway
API
to
be
enabled
on
GK,
we
also
bundle
a
couple
Gateway
classes
for
you
in
this
case
gxlb,
that's
our
Global
external
load,
balancer
and
Regional
internal
load.
Balancer
is
available
just
by
default
on
these
clusters.
B
Now
we
can
go
ahead
and
actually
apply
a
few
base
resources
we're
going
to
use
these
throughout
the
entire
rest
of
the
demo,
and
in
this
case
we
have
a
service
and
a
deployment
for
our
V1
version
of
this
application
and
then
the
same
thing
for
our
Canary
version
of
this
application.
Our
application
in
question
is
just
Echo
server.
B
So
with
all
that,
let's
actually
create
a
Gateway.
That's
a
really
simple
Gateway
GK
Gateway
we're
using
our
internal
load
balancer
in
this
case
and
just
listening
on
HTTP
on
Port
80.,
we'll
create
that
Gateway
and
in
just
a
little
bit
we'll
be
able
to
get
an
IP
that
we
can
make
requests
with
again.
I've
sped
this
up
because
it
takes
three
minutes
or
approximately
to
get
a
new
Gateway
up
and
running,
but
eventually
you'll
see.
B
We
have
some
IPS
that
we
can
make
a
request
to,
but
this
on
its
own
is
not
very
useful
because
we
just
have
a
Gateway
and
a
Gateway
doesn't
know
where
to
Route
things.
It's
really
just
the
entry
point
to
the
system.
So
let's
create
an
HP
route,
so
it
has
something
to
route
to.
In
this
case,
we've
got
an
HTTP
route,
that's
going
to
point
to
store
V1
on
port
8080,
and
you
see
that
parent
ref
there
it's
attaching
to
the
GK
Gateway
we
just
created
and
we're
going
to
be
reusing.
B
So
we'll
go
ahead
and
apply
that
HTTP
route.
Http
route
is
good
to
go
because
you
may
have
noticed
I
said
I
I'm
using
an
internal
load
balancer
for
this
demo,
I
actually
have
to
get
somewhere
into
the
network.
The
easiest
way
to
do
this
is
I'm
just
going
to
exec
into
a
pod
and
I'm,
going
to
run
a
few
curl
requests
and
you
can
see
we're
hitting
a
store
V1
pod.
Each
deployment
has
two
pods.
A
A
A
So
we'll
apply
the
Gateway
class,
it
doesn't
come
with
the
the
clusters,
of
course,
because
this
is
the
portable
implementation
and
once
the
operator
sees
it,
it'll
pick
it
up
and
the
market
is
accepted.
True,
I'm
ready
to
serve
I'm
ready
to
create
gateways.
So
in
the
Gateway.
This
is
almost
the
exact
same
thing
as
what
gke
had,
except
it's
a
Kong
Gateway
class
name.
A
Same
thing,
we
just
go
ahead
and
apply
that,
and
then
we
wait
for
the
gateway
to
be
ready
behind
the
scenes.
This
is,
of
course,
like
I
just
said,
going
and
actually
creating
the
pot
on
the
cluster
via
deployment.
Ultimately,
once
it's
ready,
you'll
have
a
load,
balancer
IP
address
that
you
can
go
and
make
a
requests
to
the
Gateway.
In
this
case
this
is
a
gateway
with
no
configuration
yet
so
that's
just
kind
of
the
default
response.
A
So
before
we
set
up
the
store,
V1,
pod
and
so
forth
that
we
were
routing
our
traffic
to
with
HTTP
route.
In
this
case,
we're
just
going
to
add
the
con
Gateway
same
routes
and
everything
that
we
already
have
we'll
just
update
the
HTTP
route
to
say:
I
also
want
that
route
to
be
served
by
column,
Gateway.
A
A
So
traffic
splitting
we
talked
about
that
a
little
bit
earlier,
we're
going
to
update
the
same
issue
route.
Both
implementations
are
serving
it
and
say
that
we
want
a
weight
of
50
50
between
the
two
pods
like
just
or
two
between
the
two
back
ends:
the
services
so
Story.
One
Canary
should
both
be
getting
50
of
the
traffic.
A
B
And
now
we'll
step
back
in
time
a
minute
and
we're
going
to
make
the
same
request
but
to
the
GK
Gateway
IP
here
and
you're,
going
to
see
we're
getting
the
same
responses
so
again,
two
different
implementations
of
the
API
connected
to
the
same
HTTP
route
and
everything
works.
We
just
demoed,
two
I
think
there's
15
or
more
implementations
of
this
API
they'd
work
the
same
way
again.
The
goal
here
is
to
have
a
portable
experience,
no
matter
what
underlying
implementation
you're
using.
B
If
you
read
our
talk
description
very
carefully,
you
may
have
said:
hey
we
PR.
We
promised
a
demo
of
cross
namespace
traffic
splitting
I'm
sorry
this
was
we
write
these
cfps
like
five
months
ago.
It's
a
long
time.
We
thought
we
would
have
this
Auto
experimental.
It's
like
two
weeks
away.
We
just
we
just
missed
the
timeline,
but
this
is
moving
from
our
experimental
channel,
the
APA
API
to
standard
in
a
couple
weeks,
and
so
we
know
what
this
does.
B
We
know
how
it
works,
but
the
idea
is
that
reference
Grant
idea
that
we
we
demoed
earlier.
You
can
use
the
same
concept
again
but
to
reference
a
back
end
in
another
namespace,
so
we
we've
been
traffic
splitting
within
the
same
name
space.
That's
the
default!
That's
the
easiest
thing
to
do,
but
there
are
some
legitimate
use
cases
where
you
want
to
traffic
split
to
another
namespace,
and
this
enables
you
to
do
that
so
again.
B
B
Now
I'm
sure
some
of
you
are
saying
hold
on
this
looks
like
a
ton
of
work,
yet
another
new
kubernetes
API
to
learn
I
I'm,
sorry,
but
we
are
trying
to
make
this
transition
just
a
little
bit
easier,
so
we've
created
a
tool
called
Ingress
to
Gateway.
So
if
you're
interested
Ingress
will
just
out
of
curiosity,
how
many
of
you
have
kubernetes
clusters
right
now
that
have
a
bunch
of
ingresses
running
in
them?
Okay,
great
I,
would
love
if
you
would
try
this
out.
B
A
Yes,
please!
So
what's
next
for
Gateway
API
service
mesh,
like
I,
talked
about
a
little
bit
earlier
is
kind
of
one
of
the
bigger
ones.
We
have
What's
called
the
gamma
initiative
and
we're
looking
at
taking
these
apis
like
HTTP
route
and
stuff
like
that
and
see
how
they
can
apply
to
the
service
mesh
use
case,
Gateway
class,
Gateway
and
HTTP
route.
All
just
recently
went
to
V1
beta
one,
but
we
are
trying
to
get
to
V1
very
soon
TCP
route,
UDP
route,
TLS
route.
A
They
need
more
feedback
implementations,
but
we
are
hoping
to
get
those
into
beta
very
quickly.
Grpc
route
just
released
as
an
alpha,
so
go
check
that
out
and
then
ultimately,
one
of
our
Big
Stretch
goals
that
we've
had
for
a
while
is
we
want
the
Gateway
gateways
to
be
an
alternative
to
surface
type
load?
Balancer?
A
If
you
want
to
get
involved,
we
actually
have
two
weekly
meetings,
so
the
one
on
every
Monday
is
kind
of
our
regular
Gateway
API
meeting
for
like
Ingress
and
so
forth,
and
then
our
Tuesday
meetings
are
gamma.
That's
the
mesh
related
meeting.
We
would
like
anybody
who
wants
to
come
to
come
all
backgrounds,
even
if
you
just
want
to
come
in
and
listen
but
we'd,
certainly
like
feedback
and
ideas
and
stuff
like
that
about
how
to
go
forward
with
these
things.
B
I,
just
before
before
we
get
into
questions
I,
just
one
last
call
out
I
forgot
to
put
this
in
the
slides,
but
Keith
is
here.
John
is
maybe
here
I'm,
not
sure,
but
if
you're
interested
in
the
mesh
side
of
this
there's
another
talk
at
11
A.M
tomorrow.
Is
that
right,
I
think
but
yeah
look
for
it
really
really
interesting
things
happening
with
this
API.
We
focused
on
the
Ingress
side,
but
it's
much
broader
than
that.
Without
any
any
questions.
B
Yes,
I
know
at
least
one
implementation
supports
that
so
in
GK
we
have
multi-cloud.
We
combine
this
with
multi-cluster
services,
so
one
of
the
things
you
can
forward
to
we
focused
on
forwarding
the
services,
but
you
could
forward
to
a
service
import
and
just
build
on
top
of
the
multi-cluster
service
API
for
multi-cluster
gateways.
B
D
D
D
C
B
Yeah,
it's
a
good
question.
I
know
I
know,
that's
been
discussed
a
lot,
but
I
think
you
know.
From
my
perspective,
the
goal
is
to
make
keep
kubernetes
the
project
from
growing
even
wider,
there's
already
so
much
in
the
core
kubernetes
repo
that
we're
trying
to
pull
things
out
like
most
people,
but
not
everyone
using
kubernetes
needs
something
like
Gateway
API.
You
know
this
is
not.
Everyone
needs
load
balancing
in
their
cluster,
so
this
is
something
that
you
can
bolt
on
as
basically
an
extension
of
your
cluster
and
that's
the
direction.
B
B
F
For
traffic
shifting,
it's
sort
of
like
a
idea
for
using
like
the
scaling
API
or
something
to
make
that
a
little
more,
you
know
easy
to
drive
from
Akita,
or
you
know
some
other
traffic
monitoring
tools.
So
you
can
have
traffic
shift
automatically
versus
like
setting
configurations
like
a
sub
resource.
B
C
A
A
A
Right,
I,
don't
yeah
I,
don't
think
we
have
anything
like
that
today
in
the
API
like
a
way
to
express
that
all
right.
There
may
be
something
that
have
come
up
in
the
past,
but
come
to
the
come
to
the
meetings
come
to
like
get
on
GitHub
with
us
and
like
tell
us
about
that,
because
we'd
love
to
try
and
see
if
we
can
fit
in
a
use
case
like
that
it
sounds
cool.
D
E
G
A
Yeah
I
think
I
think
today
we're
kind
of
leaving
that
up
to
the
operators
to
kind
of
figure
out
as
opposed
to
making
that
something
that
we
express
like
in
this
API
but
open
to
it
like
opens
if
it's
something
that
can
be
generally
applied
across
most
implementations,
I
mean
we
also
have
like
extended
and
other
feature
sets
basically
to
try
to
capture
things
that
can't
be
done
everywhere.
We'd
be
open
to
putting
something
like
that
in
yeah.
B
I'd
also
recommend
watching
that
kubecon
talk.
It
was
yesterday.
If
you
missed
it,
there
was
one
by
sanskar
who's
over
there
demoing
just
how
to
use
this
API
with
in
that
case
Flagger,
but
something
that
helps
automate
that
transition
process
for
you
I
think
really.
Those
kind
of
automated
transitions
are
going
to
require
something.
On
top
of
this,
like
Flagger
I.
Think
I
can't
remember
if
Argo
supports
this
API,
yet
I
thought
they
were
working
on
it,
but
I
I
can't
remember.