►
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.
Gateway API: Beta to GA - Rob Scott, Google & Nick Young, VMware
In the past year, Gateway API has made some significant progress, becoming an official Kubernetes API and graduating to Beta. As part of that process, it gained some exciting new features, including custom policy attachment, advanced rewrite configuration, cross-namespace references, and a lot more. In this talk, we’ll provide an overview of all the new features in Gateway API, demonstrating many of them with different implementations of the API. We’ll then discuss our plans going forward, including new features we’re working on and our goals for a GA release. Most importantly, we’ll share how you can get involved with the project.
A
A
C
A
Mean
that's
good,
but
hopefully,
by
the
end
of
this
talk,
we'll
have
even
more
of
you
wanting
to
try
it
out.
So,
let's
work
on
that.
So
for
those
of
you
who
haven't
tried
it
out,
yet
you
may
be
wondering
what
is
this
thing?
Well,
I
look
at
it
as
the
next
generation
of
kubernetes
load,
balancing
and
routing
apis.
A
Why
would
we
build
a
new
api
right?
This
is
a
very
familiar
problem.
We
already
have
an
ingress
api.
We
already
have
a
service
api.
Why
start
with
a
new
one?
Well,
the
ingress
api
simply
wasn't
able
to
express
advanced
configurations
that
so
many
people
wanted
this.
The
failures
of
that
api
led
to
lots
of
custom,
annotations
and
other
things
which
worked.
A
They
were
the
best
option
available,
but
we
wanted
to
provide
a
better
api
in
kubernetes
that
didn't
require
all
those
annotations
and
for
those
of
you
familiar
with
the
service
api,
you've
seen
new
fields
just
get
stuffed
in
over
and
over
again,
and
the
combination
of
those
fields
may
not
make
sense,
and
it's
very
hard
to
diff,
to
test
to
work
with
to
implement
all
those
things.
So
a
new
api
hopefully
offers
a
solution
to
this.
We
can
unify
load,
balancing
configuration
across
l4,
which
was
the
service
api
and
l7
ingress.
A
A
Lots
lots
of
fun
ideas
coming
yeah
yeah.
So
with
that,
let's
talk
about
our
timeline
and
how
we
got
to
where
we
are.
The
last
kubecon
I
was
at
in
person
was
kubecon
san,
diego
and
you
see
some
of
us
there.
Many
of
us
ended
up
becoming
maintainers
danian's
an
audience,
I
think
maybe
some
others
as
well.
The
initial
work
really
began
at
kubecon
san
diego.
We
had
some
initial
brainstorming
sessions
and
then
it
took
us
a
year
and
we
got
v1
alpha
1
out
the
door.
A
We
had
so
many
different
prototypes
and
many
different
structures
of
the
api
that
we
experimented
with
a
few
more
minor
releases,
some
additions
and
then
kubecon
eu.
It
was
all
virtual,
but
kubecon
eu
we
presented
our
first
overview
of
gateway
pi
at
a
kubecon.
Again
it
was
all
virtual,
but
that
was
around
a
year
ago
and
this
talk
is
really
going
to
focus
on
everything.
That's
changed
since
that
point.
So
in
the
past
year,
in
the
past
year,
v1
alpha
2
was
released.
That
was
a
huge
change
for
us.
A
We
saw
it
as
really
the
the
beginning
of
our
stable
api.
I
know
it
still
said
alpha,
but
we
thought
this
was
the
api
we
could
take
to
beta
and
that
largely
ended
up
being
true.
Since
then,
we've
really
been
focusing
on
conformance
tests.
Some
new
experimental
features,
some
patch
releases
just
stabilizing
what
we
have
and
we're.
Finally,
at
a
point
where
we're
confident
to
go
to
beta,
so
we'll
be
talking
about
that,
but
let's
take
a
few
steps
back
and
describe
the
api
itself.
A
A
Second,
we
have
gateways
these
represent
some
kind
of
entry
point
to
your
system.
It
could
be
a
load
balancer,
it
could
be
some
kind
of
proxy
configuration,
but
they
represent
some
kind
of
entry
point
to
your
system,
but
really
the
huge
part
about
this
api,
even
though
it's
called
gateway
api.
The
most
important
important
part
is
the
routes
we
have
a
lot
of
different
routes
and
the
routes
are
where
the
vast
majority
of
the
functionality
comes
from.
So
in
this
case,
I'm
showing
http
route
because
that's
our
most
stable,
most
full-featured
route.
A
That
has
a
lot
of
advanced
configuration
in
it,
but
you
could
also
attach
a
tcp
route.
Tls
udp
grpc
is
coming
soon.
We've
got
a
lot
of
different
routes
for
different
protocols
and
they
define
different
routing
configuration
that
is
protocol
specific.
So
you
attach
http
to
your
l7
load
balancer.
You
might
have
an
l4
load
balancer
that
you
attach
tcp
routing
configuration
to
can
jump.
D
In
yeah,
so
one
thing
I
didn't
want
to
say
there
is
with
the
I
think,
the
distinction
between
them
is
http
routers
for
terminated,
http
traffic,
tls
routers
for
stuff,
where
you're
passing
through
a
tls
and
then
tcp
and
udp
are
for
like
proxying
tcp
and
udp
traffic,
not
routing
proxying.
The
distinction
is
important.
A
A
There's
a
lot
in
here:
I'm
not
going
to
cover
all
of
it,
but
suffice
it
to
say
many
of
these
things
have
not
been
seen
in
other
kubernetes
apis.
This
is
an
official
kubernetes
api
that
supports
all
of
this
and
more
so.
This
is
a
big
thing
for
kubernetes,
but
you
may
be
asking
you
look
at
that
slide.
You
see
all
these
things
and
you
say
how
on
earth
can
this
be
portable?
You
know
we're
we're
trying
to
build
a
portable
api.
This
is
a
kubernetes
api.
A
How
can
you
promise
all
those
features
and
then
say
it's
portable
well,
unlike
ingress,
unlike
previous
kubernetes,
apis
we've
built
in
this
concept
of
conformance
levels.
So
we
start
with
a
conformance
level,
that's
called
core
and
that's
something
that
we
expect
every
implementation
to
handle
in
a
consistent
way
and
support.
A
good
example
of
this
is
with
http
prefix
path.
Matching
just
about
everyone
can
support
that
basic
capability.
A
Now
we
also
have
an
extended
level
of
conformance,
and
that
is
something
that
we
expect
to
be
supported
consistently
when
it
can
be
supported,
but
we
recognize
not
everyone.
Not
every
implementation
can
support
something
like
a
header
modification.
A
lot
of
implementations
can
but
not
quite
everyone,
so
that's
an
example
of
an
extended
feature
and
finally,
we
have
something
called
custom.
This
is
not
that
common
in
the
api,
but
there
exists
a
thing
called
regex.
A
I
think
that
is
the
only
thing
this
exists
for,
but
if
you're
familiar
with
regular
expressions,
you're
familiar
that
there
are
lots
of
different
variations
of
regular
expression
implementations,
so
we
can't
write
conformance
tests
that
expect
this
specific
path,
the
specific
regex
we
match
the
same
way
when
the
underlying
implementation
may
support
a
different
flavor
of
regex.
So
we
say:
okay,
this
is
a
concept
that
is
widely
understood,
but
we
recognize
there
may
be
some
variation
in
implementation
here.
A
With
all
that
background,
let's
spend
a
little
bit
of
time
talking
about
what's
changed
in
the
past
year
and
there's
a
lot
first,
we
went
to
v1
alpha
2,
as
I
mentioned,
but
maybe
most
important.
We
went
to
gateway
networking
kate's.
I
o
api
group.
What
that
means
is
we're
an
official
kubernetes
api.
That's
a
big
distinction.
Previously
we
were
just
an
experimental
kubernetes
api.
This
status,
as
in
the
case
api
group,
means
that
not
only
are
we
gateway
api
maintainers,
reviewing
every
step
of
the
api
change,
so
our
upstream
api
reviewers.
A
That's
actually
the
state
we're
in
right
now
for
v0.5.0
we're
in
that
final
set
of
review.
Hopefully
we
can
get
a
release
out
soon.
I'm
really
proud
of
this.
We
have
more
than
70
people
that
have
already
contributed
to
this
api
and
that
number
keeps
on
going
up
and
again,
if
you're
interested,
we
are
always
looking
for
more
contributors
and
maintainers.
Yes,
right
now,
I
think
this
number
is
a
little
out
of
date,
but
we
have
around
15
implementations
you
may
have
heard
earlier
on.
A
A
Click
whoa
yeah,
cool,
okay;
there
they
are
yes,
anyways.
Many
implementations
are
fully
passing
conformance
tests.
Now
we're
really
excited
about
it.
The
fact
that
we
already
have
a
pretty
robust
conformance
suite
means
that
I
think
we're
going
to
have
a
pretty
consistent
experience
across
implementations.
A
Okay,
let's
talk
about
what's
changed,
we
did
a
thing
with
route
gateway
binding
that
we
hope
will
simplify
things
for
any
of
you.
That
may
have
looked
at
v1
alpha
1
before
the
idea
was
that
gateways
select
routes.
So
if
you've
used
kubernetes
you're
familiar
with
the
idea
of
a
label
selector,
so
you
say
I
want
to
select
routes.
I
want
to
select
routes
that
have
a
specific
label.
A
A
So
we
tried
to
simplify
that
a
little
bit
by
instead
saying
hey
the
routes
reference,
the
gateway,
so
the
routes
have
this
parent
refs
thing
and
that
points
up
to
the
gateway
and
the
gateway
just
says
here
are
the
name
spaces.
I
trust
routes
from
and
actually
that's
kind
of,
an
important
detail.
A
gateway
can
trust
routes
from
multiple
namespaces
if
you've
ever
wanted
to
have
your
load
balancing
infrastructure
in
one
namespace
and
your
routing
configuration
in
another
namespace,
that's
possible
with
this
api.
A
Yes,
thank
you.
So
we're
really
excited
about
that.
Another
neat
thing
about
that
parent
rest
field.
Right
now
that
that
is
used
to
refer
to
gateways.
There
are
some
other
interesting
use
cases
here,
there's
a
gap.
We
you
know
if
you've
heard
of
kubernetes
enhancement
proposals,
we
have
gateway
enhancement
proposals
and
we
have
one
right
now.
That's
talking
about
route
inclusion
where
that
parent
could
refer
to
another
parent
and
another
route,
we'll
just
see.
This
is
still
in
proposal
phase,
but
there's
a
lot
of
really
interesting
stuff
happening
here.
A
All
right.
Let's
move
on
to
reference
policy,
we're
talking
about
crossing
namespace
boundaries.
This
is
a
slightly
different
way
to
do
it.
This
is
for
some
very
specific
instances
if
you've
ever
had
this
idea
in
your
head,
that
I
have
my
routing
configuration
here
and
I
want
to
forward
to
a
back
end
in
some
other
namespace.
So
I
have
all
my
routing
configuration
in
a
routing
namespace,
but
I've
got
my
service.
I've
got
my
app
in
my
app
namespace.
A
This
is
what
that's
intended
for
or
if
you
have
your
tls
certificates
in
a
separate,
secure
namespace,
but
you
want
to
allow
them
to
be
referenced
from
somewhere
else.
This
allows
for
that.
So
reference
policy
at
its
core
is
a
resource
that
exists
in
a
namespace
that
I
own,
and
it
says
I
trust
references
from
this
other
namespace.
A
So
in
this
case
this
reference
policy
says
I
trust
references
from
http
routes
in
the
prod
namespace
to
services.
In
my
namespace,
this
this
pattern
is
something
we
ran
by
sig,
auth
c
arch,
sig,
api
machinery.
We
run
it
through.
I
think
it's
a
good
pattern,
but
we're
very
much
interested
in
feedback
here.
A
I
should
hold
out
this
little
note
here.
We've
called
this
reference
policy,
but
there's
a
decent
chance.
It's
going
to
get
renamed
because
we
have
this
whole
other
concept.
That's
a
little
bit
newer,
called
policy
and
policy's
such
a
generic
term,
we're
thinking
we
may
rename
it
to
something
like
reference
grant,
so
don't
get
tied
to
that
name.
This
concept,
I
think,
is
here
to
stay.
The
name
may
change
okay.
Moving
on.
Let's
talk
about
policy
attachment.
This
is
that
thing.
I
mentioned
the
policy,
that's
a
really
broad
scope.
A
A
One
of
the
things
we've
really
struggled
with
in
our
api
is
something
like
as
simple
as
timeouts.
You
would
not
believe
the
variation
timeout
configuration
whether
you're
talking
to
nginx
envoy
some
cloud.
They
all
have
different
versions
of
timeouts
that
they
support
and
trying
to
build
portable
configuration
for
that
was
very
challenging.
So,
instead,
what
we're
suggesting
for
these
kinds
of
things
is
that
implementations
or
groups
of
implementations
decide
on
a
common
policy
that
works
for
them.
A
D
D
So
this
is
very
early
yeah
but
like
the
idea
here
is
that
you
can
have
settings
that
can
be
overridden
or
or
defaulted
and
stuff
like
that
that
allow
you
to
make
settings
at
sort
of
a
higher
or
a
lower
level
and
yeah
there's
a
whole
document.
It's
a
very
long.
It
took
us
a
long
time
to
write.
I
encourage
you
to
read
it
if
you're
interested
in
this
at
all,
but
yeah,
it's
because
it's
quite
complicated
and
there's
some
serious
subtleties.
A
Yeah
I'll
just
give
a
concrete
example
for
gk
we're
building
an
lb
policy
that
includes
some
of
our
low
balancer
specific
policy
configuration
that
just
doesn't
fit
in
the
api
itself,
and
I
imagine
other
vendors
will
have
similar
things
all
right.
So,
let's
talk
about
graduating
beta,
that's
a
big
part
of
this
talk.
We
finally
are
making
it
to
beta,
but
only
part
of
it.
So
we
have
defined
a
graduation
criteria
that
involves
a
number
of
things.
A
A
A
But
one
key
thing
is
that
that
means
we
don't
have
feature
gates
if
you've
used
upstream
kubernetes
before
you
may
be
familiar
with
a
concept
called
feature
gates
where,
when
you
add
a
new
field,
it
starts
in
alpha,
you
can
opt
in
with
a
very
specific
feature
gate
and
then
it
gets
to
beta.
Then
it
gets
ga.
We
don't
have
that
concept.
We
have
crds
and
after
talking
it
through
with
a
few
different
sigs.
A
This
is
what
we
came
up
with
stable
channel
is
what
you'd
expect
it's
the
resources
that
have
graduated
beta
and
all
feed
all
fields
that
are
not
considered
experimental,
but
experimental
is
kind
of
that
playground
where
we
start
with
new
things.
We
have
alpha
resources.
We
have
new
fields
that
we're
adding
that
we
think
are
promising,
but
we're
not
quite
confident
enough
to
graduate
to
stable.
Quite
yet
so
everything
starts
and
experimental
some
stuff
graduates,
the
stable
and
some
stuff
disappears
from
experimental.
D
I
guess:
can
you
go
back
to
that
yeah
for
a
second,
so
there's
a
couple
of
things
I
wanted
to
add
to
that
that
I
just
thought
of
so,
notably,
you
probably
noticed
that
the
reference
policy
is
still
in
alpha.
As
of
the
the
next
version.
This
is
all
as
of
the
0.50
reference
policy
is
still
an
alpha,
which
means
that
you
won't
be
able
to
make
cross
namespace
back-end
references
or
refer
to
secrets
that
are
not
in
the
same
namespace
as
a
http
route.
Yeah.
D
Those
both
require
reference
policy
to
be
done
safely,
because
reference
policy
won't
be
alpha
if
you're
only
using
stable.
You
just
won't
be
able
to
do
it.
There's
no
mechanism
to
it
right
so
just
wanted
to
call
that
out.
It's
still
like
the
gateway
api
with
the
the
resources
that
we're
moving
to
beta
are
still
perfectly
functional,
is
just
that
it's
a
bit
less.
You
can't
do
some
more
complicated
stuff.
D
We
are
hoping
to
get
reference
policy
in
really
soon
but,
like
that's
going
to
be
another
round
of
api
review
and
we
didn't
want
to
block
that
on
having
to
figure
out
a
new
name
like
you
know,
I'm
sure
all
of
you
have
tried
to
name
something
before
it's
really
hard.
It's
even
more
hard
when
you're
implementing
an
open
spec
that
a
million
people
are
going
to
have
different
people
have
to
implement
the
bike.
Sharing
is
crazy,
so
yeah.
So
it's
really
important
that
we
get
that
right.
A
D
D
Yeah
and
so
yeah,
let's
swap
out
so
yeah
look
rob
mentioned.
You
know
we're
really
the
first
official
kubernetes
api
to
be
built
with
cids
we're
the
first
ones
to
be
doing
this
api
review
process.
You
know
we,
the
ceo
with
crds,
as
opposed
to,
as
opposed
to
you
know,
just
doing
it
in
the
in
the
core
and
having
doing
using
feature
gates.
D
That's
why
we've
got
all
of
the
sort
of
fancy
versioning
and
the
performance
levels
and
a
bunch
of
other
stuff
is
we're
trying
to
make
sure
that
this
feels
as
close
as
we
can
manage
to
the
experience
of
using
upstream
right,
but
it's
delivered
with
cd,
so
there's
just
stuff,
that's
got
to
be
different,
so
here's
some
of
the
so
some
of
the
things
that
are
good
right.
Let's
go
pros
and
cons.
D
First,
we're
not
tied
to
the
kubernetes
release
cycle
right.
We
can
cut
a
release
any
time
we
like.
We
don't
have
to
wait
for
the
next
round
of
you
know
of
everything
and
be,
and
also
more
importantly,
be
tying
up
upstream
resources
talking
about
these
apis
when
they're
not
with.
I
don't
need
to
be.
D
D
I
I
would
hope
you
should
all
be
pretty
familiar
with
how
you
go
about
installing
crds
and
using
them
and
all
that
sort
of
stuff,
and
we
are
making
sure
the
web
hook.
Validation
is
required
for
you
to
pass
conformance
well,
it
will
be
required
for
you
to
pass
components
the
currently
we
don't
have
the
conformance
test
yet,
but
we
will
be
adding
conformance
tests
that
will
test
that
the
bits
we
are
checking
for
in
the
web
hook
get
rejected.
D
You
know
and
because
there's
some
stuff
in
the
workbook
that
we're
using
the
workbook
to
protect
you
against
you
know
serious
safety
errors
and
some
security
problems
and
stuff
like
that.
So
it's
really
important
that
that
gets
implemented
and
but
yeah.
The
big
part
here
is
that
we're
part
of
the
kubernetes.
I
o
api
group.
That's
intended
to
signal
to
all
of
you
that
this
is
a
real
thing.
This
is
an
upstream
api.
This
is
safe
to
use
once
it's,
you
know
once
once
it
has
reached
your
desired
stability
level.
D
It's
it's
safe
to
use
like
it's
not
going
anywhere.
It's
not
some
company
doing
it.
This
is
an
upstream
thing.
However,
it's
had
some
it's
made.
Some
things
really
hard.
We're
the
first
person
we're
the
first
people
to
do
this,
so
no
there's,
no
prior
art.
No
one
else
has
done
this
before
we've
got
to
figure
out
all
of
this
stuff
and
hopefully
do
it
in
a
way
that
other
people
will
be
able
to
copy
you
know
and
and
make
the
life
easier
for
other
people.
D
We've
had
to
add
the
stuff
about
conformance
levels
on
a
per
field
basis
and
the
stable
and
experimental
tracks
in
order
to
be
able
to
slice
that
up
as
finely
as
we
need
to
and
yeah.
Lastly,
designing
an
api
to
cover
this
enormous
set
of
use
cases
is
really
really
hard,
and
so
it's
taking
us,
you
know
it's
taking
us
two
years
just
to
get
even
close
to
beta
for
some
resources
you
know
like,
and
so,
but
the
reason
we've
taken
so
long
is
we
really
want
to
make
sure
we're
getting
this
right.
D
You
know
like
we
only
get
one
shot
at
doing
this
again.
You
know
like
we
don't
want
to
end
up
with
a
situation
like
ingress
where,
where
it's
just
not
specific
enough
and
so
we're
erring
on
the
side
of
overspecifying
rather
than
underspecifying
okay,
so
I
want
to
run
through
a
few
quick
examples
here.
I
will
try
and
keep
this
super
quick,
so
we
have
some
type
of
questions.
D
Okay,
this
is
a
simple
http
route
right,
so
most
of
this
should
look
pretty
similar
to
you.
If
you've
done
ingress
before
you
know,
like
you've,
got
a
host
name,
you've
got
some
rules,
you've
got
some
matches,
you've
got
various
types
of
paths
and
stuff,
and
then
you've
got
back-ends
right.
So
this
is
basically
ingress
pretty
much
with
some
extra
stuff
some
extra
magic.
Maybe
it's
a
better
way
to
say
it,
okay,
so
that's
and
that
extra
magic
is
stuff
like
this,
where
it's
the
advanced.
D
This
is
just
the
rule
section
from
that
object,
but
you
can
see
so
you
can
do
header
matching
query,
matching
path,
matching
method
matching
and
these
are
added
together.
So
that
means
that
this,
my
service
2,
is
going
to
get
only
things
that
have
the
exact
header
set,
the
exact
query:
param
set
the
paths,
the
path
exactly
right
and
the
method
and
the
method
is
get
right,
so
that's
an
and
set.
D
So
that
means
that
you
can
get
hyper
specific
about
what
goes
to
where
a
lot
of
this
stuff
was
possible
with
ingress
via
via
different
implementations,
and
they
all
had
either
their
own
cid.
I
mean
that's
what
I
did
on
that's
what
we
did
on
contour
or
you
had
to
do
like
a
million
annotations
on
your
ingress
and
hope
that
you
know
they
were
they
were
relatively
portable.
D
D
Yeah
well
should,
but
that's
what
the
performance
tests
are
for.
Right,
like
the
whole
idea
is:
if
they
are
both
conformant
implementations,
then
they
will
pass
the
test
and
you
can
be
confident
that
everything
will
work
so
also
we've
got
filters,
so
some
of
these
so
request
mirror
is
actually
a
extended
http
filter
request.
Header
modifier
is
a.
I
think.
It's
extended,
two
that's
extended
too
yeah.
I
think
there
is
one
of
the
other
ones
is
call
redirect.
Yeah
redirect
is
cool.
That's
right,
yeah!
So
see
it.
D
This
one
is
a
pretty
simple
thing:
you
can.
You
know
you
can
modify
headers,
you
can
add,
set
or
remove
headers.
You
can
send
a
mirror
of
the
traffic
off
to
another
service
you
and
if
none
of
those
get
hit,
then
you
go
to
the
to
the
standard,
backend
okay.
So
this
is
again
what
rob
was
talking
about.
This
is
how
this
is
a
little
bit
more
detail
about
how
the
cross
namespace
thing.
D
D
So
we
wanted
to
be
super
click
careful
here
that
that
we're
being
very
careful
to
keep
these
name
spaces
isolated,
except
in
so
far
as
there
has
been
agreement
between
the
two
parties
that
it
should
be
allowed
and
that's
what
this
is
aimed
to
do.
The
person
who
owns
the
gateway
has
said
I
will
allow
routes
to
attach
from
this
selector
now
they
could
be
just
like.
D
I
don't
care
it's
going
to
be
all
you
know,
any
any
name,
space,
no
problems,
it's
all
fine,
but
they
have
the
option
of
doing
that
right
and
then
the
http
route
has,
the
you
know
specific
is
the
owner
of
the
http.
Router
is
the
one
who
selects
which
gateway
they
want
to
attach
to,
and
we
chose
not
to
do
a
label
selector
or
something
like
that
there.
So
that
is
a
definite
action
and
you
as
a
http
route
owner,
have
to
pick
which
one
it
is
a
list.
D
So
if
you
want
to
have
your
http
route
owned
by
two
gateways,
that's
fine!
So
if
you're
moving
your
hp
route
between
gateways,
say
you
want
to
try
out
like
fancy
new
gateway
implementation.
You
just
point
it
at
two
gateways
and
both
of
those
implementations
should
take
the
same
config
and
end
up
with
the
same
result
right
so,
but
the
important
part
here
is
it's
a
it's.
D
D
So,
in
the
case
that
you're
doing
like
the
back
end,
ref
thing
yo,
we
do
have
the
field
in
there
that
you
can
do
a
name
space
unless
you
have
a
reference
policy,
your
implementation
must
reject
across
namespace
reference
like
this,
and
that
is
because
the
otherwise
I
could
use
this
to
refer
to
super
secure
service
that
I
just
happened
to
know
about
in
some
other
name
space
and
bada
bing
bada
boom.
I
am
now
you
know,
representing
the
the
billing
system
out
online
on.
D
You
know
some
other
100
percent,
not
the
billing
system
owned
the
haitian
peer
right.
So
so
that's
that's.
The
idea
here
is
there's
a
two
again
there's
a
two-way
handshake.
We've
got
the
http
route
owner
has
said
yeah.
I
want
to
point
this
to
a
service,
but
then
the
service
owner
has
to
say
that
is
okay.
I
allow
that
by
saying,
services
are
allowed
to
be
pointed
to
by
http
routes
in
the
prod
name
space,
notably,
you
don't
have
to
specify
both
of
these.
D
You
can
only
specify
you
can
say
all
http
routes
in
any
namespace
or
only
or
any
object
in
particular
namespaces
right
or
you
can
say
all
all
routes
in
all
name
spaces
right
like
or
all
things.
So
what
I,
the
two
use
cases
we
talked
about
is
the
is,
as
it
says,
back
end
ref,
but
the
other
one
is
the
classic.
You
want
to
keep
your
key
pairs
in
name
space
that
only
the
people
who
own
the
key
pairs
to
www.mycompany.com
shouldn't.
D
D
Okay,
so
we
talked,
we
talked
a
little
bit
about
the
graduation
criteria.
This
is
what
they
are.
We've
got
the
conformance
test
coverage.
We
have
multiple
conformant
implementations.
That
is
multiple
implementations
that
are
passing
the
conformance
tests
and
there's
you
know
we
there's
multiple
implementations
of
actually
being
used.
Like
there's
no
point
us
saying:
hey,
you
pass
the
performance
test
if
no
one's
using
it
and
that
we
need
to
leave
it
for
at
least
six
months
as
a
beta
api.
D
D
We
need
to
add,
because
once
we
go
to
ga,
that
is
our
commitment
to
all
of
you
that
this
thing
is
never
going
to
change
ever
like
ga
is
forever
like,
and
so
you
know
the
we
really
want
to
make
sure
if
it's
going
to
be
forever,
it's
really
what
we
want
so
well.
This
is
all
the
stuff
we're
working
on
more
conformance
tests
improved
like
improved
ux
through
fixing
up
the
status
right
now.
You
know
the
status
is
a
little
tricky
to
understand.
D
It
can
be
a
bit
weird
because
there's
some
edge
cases
that
aren't
handled
very
well
and
so
we're
really
trying
to
just
make
that
really
consistent
and
really
straightforward.
For
you
all
to
understand
my
my
personal
goal
is
that
if
you
are
a
http
route
owner,
you
should
only
need
to
look
at
your
http
route
to
know.
If
some,
if
everything
is
working
like
you,
shouldn't,
need
to
go
and
find
out
what
gateway
you're
pointing
to
and
check
that
the
gateway
is
okay.
D
D
That's
the
idea
where
you
can
break
up
your
route
configuration
and
have
a
route
sort
of
allow
another
route
to
attach,
so
in
the
same
way
that
a
gateway
allows
routes
to
attach
your
route
can
include
instead
of
a
back
end
and
a
loud
route.
Sander
itself
is
the
sort
of
the
rough
design
for
now
something
like
that
and
the
idea
there
is
that
just
lets
you
break
apart
things
that
have
different
teams
own
different
parts
of
the
config,
in
the
same
way
that
a
different
team
could
own
the
route
to
the
gateway.
D
Exactly
the
same
way,
grpc
route
is
being
implemented,
the
gap
the
design
for
this
has
been.
You
know
we
approved
it
yeah
we're
in
the
process
of
implementing
it
yeah.
We
really
want
to
do
more
layer,
4
stuff,
so
those
of
you
who
are
doing
tcp,
stuff
and
udp
stuff
I'd
really
yeah.
We
really
really
need
use
cases
and
to
talk
about
it.
D
Most
implementations
that
we're
talking
to
at
the
moment
are
proxies
not
like
load
balancers
like
not
true,
load
balancers,
so
they're,
actually
terminating
sessions
and
restarting
them,
and
that
has
big
implications
for
like
tcp
route
and
udpr
and
how
viable
they
are.
I
would
really
like
to
talk
to
people
who
are
okay
with
that
and
people
who
are
not
okay,
that
and
what
they
want
to
see.
D
So
we
really
desperately
need
use
cases
for
those
layer.
Four
things.
That's
one
of
the
reasons
they're
still
in
alpha.
We
just
don't
have
enough
information
about,
what's
really
needed
there
yeah
and
we're
looking
at
some
more
wild
use.
Cases
like
having
a
mesh
so
having
a
mesh
object
instead
of
a
gateway
object.
D
So,
instead
of
just
in
that
case,
your
routes
are
kind
of
describing
what
happens
east-west
instead
of
what
happens
north-south
right
so
and
so
the
mesh
object,
then,
would
describe
like
how
everything
fits
together,
not
how
you
get
in
and
out
of
the
cluster
egress
use
cases.
We've
started
talking
about
this.
We
know
people
need
it,
but
I'm
worried
that
the
constructs
we
have
at
the
moment
don't
fit
well
for
egress.
So
I
really
want
to
spend
some
time
with
people
who
need
this
to
talk
about
the
use
cases
again.
A
D
Lastly,
yeah
please
get
involved.
Just
like
I've
been
saying.
The
weekly
community
meetings
are
on
monday's
pacific
time.
That's
u.s,
pacific
time
I
am
in
australia,
so
it's
my
tuesday
morning
so
yeah.
I
can't
I
can't
do
the
time
zone
math
in
my
head,
I'm
sorry
to
tell
you
what
time
it
would
be
in
central
ukraine
time,
but
the
yeah
that
we
do
one
one
meeting
a
week
at
the
moment.
D
If
you
need,
if
you
all
need
it,
we
can
talk
about
like
standing
up
alternating
meetings
and
stuff
like
that
right
now.
We
just
don't
have
enough
people
to
to
need
it,
and
yet
contributors
from
all
backgrounds
welcome,
like
I
said
we
desperately
need
use
cases.
So
if
you
are
interested
in
contributing
to
an
upstream
thing
that
you're
probably
going
to
end
up
using,
please
please
come
and
tell
us
about
what
you're
trying
to
do.
D
If
you
are
an
implementer
implementing
this
api,
please
come
and
tell
us
what
your
experience
about
was
like
implementing
it
like.
We
need
to
know
like
what
have
we
missed
what's
hard
to
implement
like
what
was
easy,
like
the
the
plus
ones?
Are
nice
too
yeah?
This
is
our
website
gateway,
api,
dot,
six
dot
case
dot
io.
We
are
at
a
sig
network
gateway
api
in
kubernetes
slack
and
on
github
right
there.
E
F
Hey
hi,
I
don't
am
understand
this
is,
will
be
a
part
of
kubernetes.
If
I
have
kubernetes
cluster
in
the
latest
version
does
http
route
include
and
if
yes
does
it
come
to
replace
ingress?
Does
the
future
plane
is
that
english
will
be
deprecated
and
there
is
no
resource
name,
english
and
kubernetes?
Thank.
A
You
that's
that's.
A
great
question.
Ingress
is
around
to
stay.
Ingress
is
the
simple
api.
It
works
for
a
large
portion
of
the
community.
This
is
the
advanced
api.
Ingress
will
be
around
indefinitely.
It
is
a
ga
api.
What
nick
said
earlier,
ga
is
forever
gateway.
Api
is
a
new
api.
It,
as
as
nick
mentioned.
This
is
something
that
is
a
crd.
It's
not
dependent
on
the
latest
version
of
kubernetes.
You
could
take
these
crds
and
install
them
in
a
1.16
cluster.
D
F
D
F
D
D
You
know,
and
so
I
mean
we're
hoping
that
that
we
can
make
the
api
so
good
that
you
don't
want
to
use
ingress
right
like
that,
it's
simple
enough
to
use
and
easy
enough
to
use
that
you
can
just
you
know
that
you
can
that
you
want
to
use
the
gateway
api
instead.
Yep.
Thank
you,
yeah.
All
right.
Thanks.
E
B
Hi,
thank
you
for
the
conference.
So
question
is
about.
I
have
two
questions
about
egress.
I
find
it
a
very
interesting
use
case,
but
also
very
challenging
to
attract
the
traffic
from
the
cni,
because
it's
also
cni
dependent.
That's
one
question
and
the
second
question
is:
could
you
elaborate
on
what
you
meant
with
cluster
ip
please?
So
I
didn't
hear
the
second
part
yeah.
I
I
didn't
get
what
you
meant
with
cluster
ip.
What
what?
What
is
the
use.
A
Yeah,
I
I
can
cover
that
one,
this
this
is
way
pi
in
the
sky
theoretical
we
haven't,
we
don't
know
what
it
would
look
like.
It's
just
hey
could.
Could
we
use
these
api
constructs
to
represent
the
cluster
ip
routing
we
have
today
with
service,
and
maybe
service
becomes
something
a
little
simpler.
I
I
don't
know
this
is
like
years
in
the
future
theoretical.
D
G
Hello,
so
yeah
you're,
the
first
project
to
use
crds
are
you,
like,
obviously,
you've
had
like
the
teething
problems
and
like
the
first
project
problems.
Do
you
see
this
as
going
to
become
like
a
more
common
thing?
I
quite
like
the
idea
of
the
sort
of
module
yeah,
it's
more
a
more
modular
element
of
implementing
things
in
kubernetes
yeah
like
getting
involved
in
it.
So.
A
Sorry,
the
the
admin
network
policy
api
is
one
that
is
following
in
our
footsteps,
so
another
project
under
sig
network
that
is
working
towards
a
crd
based
api.
That's
that's
a
great
question
there.
There
are
definitely
it's
not
all
perfect
yet,
but
we
are
trying
to
blaze
a
path
that
makes
it
easier
for
others
to
come.
We
are
trying
to
pull
things
out
of
core
and
make
them
more
modular.
Exactly.
D
Like
what
you're
saying
so
yeah,
I
mean
there's
an
ongoing
effort
to
pull
things
out
of
the
tree
for
the
main
kubernetes
and
to
make
it
so
you
know.
Ideally,
everything
in
kubernetes
should
end
like
main
kubernetes
should
be
ga
and
not
changing
very
often
that
will
make
all
of
our
lives
easier
when
it
comes
time
to
upgrade
right
like
the
more
we
can
pull
out
of
the
tree,
the
better
off
we'll
all
be.
D
C
D
D
So
envoy
itself
doesn't
need
to
be
changed
because
envoy
is
configured
with
the
xds,
the
xcs
apis,
and
so
anything
that
you
can
write
so
envoy
gateway
is
all
about.
Taking
writing
a
separate
thing
that
doesn't
need
istio
that
can
take
kubernetes
gateway
apis
and
turn
them
into
envoy
config
and
configure
your
own
other
people.
You
know
other
implementations,
ingress
controllers,
use
nginx,
you
know.
Other
load
balancers,
like
I
think,
hey
proxy
and
middle
of
b,
have
talked
about
supporting
the
gateway
api.
D
The
idea
is
that
anybody
can
use
these
constructs
to
sort
of
describe
any
sort,
any
level
of
that
functionality
and
it
will
work.
And
then,
if
you
move
to
someone
else
who
supports
the
similar
level
of
functionality,
then
you
can
just
switch
your
config
over
and
it
should
just
work.
Do
you
know
that?
C
E
A
Do
not
have
a
reference
implementation,
we
don't
have
any
plans
to
have
a
a
single
standard
implementation.
There
are
you
know
there
may
be.
You
know
like
nginx
ingress.
There
may
be
one
that
is
widely
supported
in
the
community
in
the
future
that
that
kind
of
becomes
the
de
facto
one
that
we
reference,
but
that
does
not
exist
today.
Yeah
and
we
do
not.
D
We
do
not
ever
plan
to
anoint
like
the
one
true
gateway
api
implementation.
The
the
idea
is,
the
conformance
tests
are
the
source
of
truth.
If
you
pass
the
conformance
tests,
you're
a
conforming
api
implementation,
no
matter
who
you
are
yeah
and
we
are
planning
to
have
like
a
bit
of
a
feedback
loop
where
you
will
be
able
to
like
take
your
implementation,
do
something
with
the
run.
D
The
conformance
test
pass
them
back
to
us
and
we
will
be
able
to
have
a
canonical
list
of
these
implementations
past
the
performance
test
on
this
date
at
this
level
and
blah
blah
blah
the
same
as
you
do
for
upstream
performance.
You
know
you
get
like
a
sticker.
That
says
you
are
a
conformer
kubernetes,
distro
right
same
idea,.