►
From YouTube: Get Started With Gateway API
Description
Come and join Nick Young, the tech lead of Contour and Gateway API, to learn about Kubernetes Gateway API and all the related resources - GatewayClass, Gateway, HTTPRoute, TCPRoute, Service, etc!!
A
B
B
If
I
ramble
too
much
the
because
yeah,
I
have
a
lot
that
I
could
say
about
this
stuff
so,
but
I
want
to
keep
it
so
that
you're
learning
interesting
things
please,
please
hit
us
with
comments
and
stuff
like
that.
The
it's
yeah
there's,
definitely
a
lot
that,
like
I've,
been
working
on
this
for
like
three
four
years
now
so
I
know
I
have
a
lot
of
background
and
so
yeah.
If
you
have
any
questions
about
it
almost
certainly,
I
can
probably
give
you
a
reasonable
answer.
B
B
Usually
you
come
with
a
load
balancer
service
that
creates
an
external
load
balancer
for
you
when
you're
running
in
a
in
a
public
cloud,
and
then
then
you
use
your
ingress
resources
to
in
in
the
api
server.
Contour
reads
those
creates
config
enabled
for
you
and
exposes
the
service
that
your
that
your
ingress
refers
to.
B
So
this
is
how
this
is:
how
ingress
sort
of
works.
It's
important
to
remember
this
stuff,
because
gateway
api
is
essentially
the
bits
that
we're
going
to
talk
about
today
are
gateway.
Api
is
essentially
like
you
gave
api
actually
started
as
being
ingress
v2,
but
what
we
found
was
once
we
started
working
on,
that.
We
realized
that
there
was
a
lot
of
other
stuff
that
we
needed
to
include
in
there
and
that's
why
the
name,
the
sort
of
the
scope
expanded
out
and
the
name
changed.
B
Cool
cool,
awesome,
okay!
So
well,
let's,
let's
start
this
discussion
by
saying:
okay,
so
the
gateway
api
is
a
new
upstream
api.
Let's,
let
me
pull
up
the
this
is
the
okay.
This
is
the
game.
Api
website
gateway,
dash
api
dot,
sigs
dot,
kate's
dot
io
this.
This
is
the
the
introduction
page
I'll
walk
through
this
in
a
minute,
but
yeah.
B
They
need
to
express
all
the
stuff
that
you
need
in
order
to
do
all
the
stuff
you
want
to
do
with
your
ingress
traffic
through
fields
in
the
spec,
not
through
annotations,
like
you
like,
like
you
needed
to
do
on
ingress,
they
need
to
be
extensible
in
that
you
need
to
be
able
to
add
things
in
a
way
that
you
don't
need
to
again.
You
don't
need
to
use
annotations.
Basically,
a
large
part
of
this
is
we
want
to
avoid
having
lots
of
annotations
and
role.
B
Oriented
is
about
what
this
diagram
that
you
can
see
on.
The
screen
is
about
as
those
of
us
who
were
doing
ingress
stuff
spent
more
time
doing
it.
What
we
found
was
that
it's
pretty
common,
that
different
people
who
are
using
the
cluster
had
different
reasons
why
they
needed
ingress
and
different
things
they
wanted
out
of
ingress,
so
the
so
when
we
started
designing
the
go
api,
we
settled
on
some
personas,
so
the
one
that's
probably
most
familiar
is
application
developer
right.
B
This
is
the
person
who
owns
the
developer,
who
owns
an
app
and
they
want
to
be
able
to
own
some
config
that
they
keep
with
their
app
that
explo,
that
tells
that
tells
magic
stuff
in
the
cluster,
how
to
make
sure
that
their
app
is
visible
on
the
internet.
And
so
that's
what
that's?
What
this?
That's?
Why
that's
one
of
the
sort
of
key
personas
right,
like
that's
at
the
end
of
the
day?
That's
that's!
B
Sometimes
it's
the
same
person
as
the
application
developer
right
if
you're
running
a
kind,
cluster
or
you're
running
a
small
cluster,
you
know
you're,
probably
the
one
person
doing
everything
but
in
bigger
clusters,
this
distinction
between
the
application
developer
and
the
person
who
actually
owns
the
cluster
infrastructure
is
really
really
really
important
and
then
the
last
persona
we've
got.
Is
this
infrastructure
provider?
One
sorry
I'll
make
this
a
bit
bigger
this
infrastructure
provider
one?
And
so
this
this
is
basically
the
the
so
actually
I've
kind
of
messed.
This
up
a
little
bit.
B
The
cluster
operator
is
the
person
who
owns
like
the
the
individual
config
of
the
gateway,
they're,
the
one
who
say
in
a
really
big
organization
say
you
have
like
you
know,
www.company.com
and
that's
your
that's
your
company's
website
and
your
company's
website.
You
want
to
break
it
up
into
like
different
by
different
teams.
This
is
one
of
the
things
that
we
built
contours
http
proxy.
To
do
you
wanna
be
able
to
break
up
that
config
and
have
multiple
teams
access
that
same
website
or
expose
things
on
that
same
website.
B
You
probably
don't
want
those
individual
teams
to
have
access
to
really
important
stuff,
like
the
tls
key
pairs
for
for
that
for
that
domain
name
right,
those
are
probably
going
to
be.
You
know
you
know
those
are
going
to
be.
Those
are
secret.
You
need
to
keep
those
properly
secret,
and
so
this
cluster
operator
is
the
person
who
controls
that
level
of
stuff
the
gateway.
The
infrastructure
provider
is
the
person
who
actually
installs
the
controllers.
Sorry,
it's
been
a
little
while,
since
I
gave
this
talk,
I've
messed
that
up,
but
the
best.
A
So
the
instructor
provider
is
responsible
for
like
having
everything
you
need
to
run
the
giveaway
api
in
the
cluster.
Yes,
and
the
cloud
cluster
operator
is
responsible
for
like
maintain
some
kind
of
like
secret
or
like
security
settings
of
the
whole
cluster,
that
you
don't
want,
the
application
developers
developers
know
and
the
application
developers
kind
of
like
control
how
they
want
to
route
different
traffic
to
their
service.
B
Exactly
yeah
so
yeah,
I
think
the
cluster
operator
is
the
way
I
would
put
it.
Is
they
it's
not
just
the
secret
stuff?
It's
also
they
sort
of
control
the
so
lots
of
application
developers
might
want
to
expose
their
apps
and
the
cluster
operator
is
the
person
who
makes
sure
that
everybody
can
can
do
what
they
want
without
without
breaking
someone
else.
B
A
B
Yeah
exactly
so
typically
when
you
do
have
actually
like
a
large
enough
cluster
and
a
large
enough
company
that
you
need
this
sort
of
split.
The
cluster
operator
is
usually
like
an
sre
team
or
something
like
that
who
are
sort
of
making
sure
that
every
they're,
the
ones
who
are
responsible
for
making
sure
everything
keeps
running
and
doesn't
break.
And
you
know
all
that
sort
of
stuff
and
the
infrastructure
provider
are
usually
your
sysadmin
team
or
the
people
who
are
actually
configuring
and
setting
up
the
clusters
and
stuff
like
that.
B
It
doesn't
have
to
be,
but
that's
like
a
that's
a
very
common
way
that
this
that
this
breakdown
happens
now.
This
is
really
important,
because
we
we've
broken
up
the
the
config
that
you
used
to
be
able
to
put
on
ingress
into
three
parts
so
that
each
one
of
those
parts
is
accessible
to
a
to
a
to
a
to
one
of
those
personas.
B
Yes,
it's
actually
it's
actually
very
similar.
We
took
a
lot
of
design
cues
from
the
way
that
that
the
storage
storage
has
designed
has
fallen
out
so
yeah,
so
the
key
resource
of
the
gate
over
the
gateway
api
is
the
gateway.
That's
this
one.
You
know,
that's
why
it's
called
the
gateway
apis,
because
this
is
the
key
resource.
B
A
I
yeah
I
I
actually
I
have
a
question
here,
so
it's
there.
I
I
know
that
you
know
giveaway
class.
We
can
configure
that
which
giveaway,
okay,
which
con
which
controller
we
want
to
use
to
like
handle.
This
request,
handle
the
gateway
of
this
handle
this
giveaway
resources,
but
is
there
like
anything
else
that
we
can
config
in
this
giveaway
clause
other
than
the
controller
name.
B
Yes,
so
there
is,
let
me,
let
me
find
the
no.
This
is
the
wrong
hang
on.
I
gotta
make
my
window
a
little
bit
bigger,
so
we
get
the
there.
It
is
so
in
the
reference
section,
so
the
giveaway
class,
the
the
basic
spec
here,
has
a
controller
name
which
basically
sets
which
controller
is
going
to
be,
reconciling
that.
But
then
you
can
also
have
a
parameters
reference
now
this
parameters.
B
Reference
is
a
standard
kubernetes,
like
group
version
kind
and
name
reference
to
some
to
some
cid,
that
the
controller,
the
person
who
owns
the
controller
controls
so
for
contour
we've
got
like
a
contour
config
thing
that
you
can
put
into
the
parameters
ref
that
controls
how
contour
manages
the
gateway
class,
and
so
that's
the
way
that
you
can
sort
of
configure
extra
things
on.
There
is,
basically,
you
can
have
a
parameters
ref
that
points
out
to
some
other
resource.
B
A
B
Yes,
so
I
definitely
want
that
to
be.
I
certainly
would
like
to
see
some
built.
I
built
some
conversion
tools
in
the
past
they're.
You
know
they're,
actually
pretty
good
sort
of
first
project,
for
if
you
don't
understand,
like
it's
a
really
good
way
to
make
sure
you
understand
to
build
a
conversion
tool.
B
I
think
that
I'd
like
to
sort
of
see
us
build,
provide
a
framework
for
you
like
a
tool
that
has
like
a
plug-in
system.
That
means
it
can
read
ingress
or
it
can
read
hd
proxy
or
it
can
read
your
you
know
some
other
type
of
ingress
cid
and
turn
it
into
gateway
api.
That's
sort
of,
in
my
mind
the
ideal
end
state
here,
so
I
guess
the
correct
answer
is:
will
there
be
one
I
certainly
would
like
to
see
it?
Has
anyone
committed
to
doing
it?
Yet?
No
so.
A
B
Anyone
out
there
really
wants
to
learn,
like
all
the
all
the
detailed
ins
and
outs
of
the
gateway
api.
This
would
be
a
fantastic
first
project
for
somebody
like
everybody's
gonna
need
this
I
think,
there's
a
pretty
there's
a
pretty
strong
need
for
it,
and
I
think
that
it
would
be
pretty
likely
that
something
like
this
would
get
pulled
into
upstream,
very
quickly.
If
someone
built
it.
B
A
B
Okay,
so
I
think
we've
always
talked
about
gateway
class.
Let's
go
back
to,
let's
go
back
to
talking
about
gateway
right,
so
so
you
have
a
gateway
class.
That's
basically,
and
you
have
a
controller
to
reconcile
it.
Now,
how
do
you?
How
do
you
actually
get
some
config
and
the
way
you
do
that
is
with
the
gateway,
so
the
gateway
defines
like
a
few
things.
They
go
with
class
name
first,
so
you
have
to
have.
This
is
not
optional.
B
You
need
to
have
a
gateway
class
name
defined
in
your
gateway
and
and
then
you
need
to
have
listeners
and
addresses.
So
you
know
listeners
is
like
host
namesports
protocol
like
do
you
terminate
tls.
Are
there
any
tls
settings
all
that
sort
of
stuff
and
then
addresses
are
what
addresses
has
the
has
the
gateway
requested?
Now
again
we're
talking
about
spec
here
and
the
gateway
api
preserves.
The
usual
thing
that
kubernetes
resources
have
is
that
spec
is
the
request?
It's
the
it.
B
It
is
what
you're
asking
for,
and
then
status
is
what
you
got
right
and
so
a
behavior
that
I
don't
know
if
we
did
a
good
enough
job
of
making
clear.
Is
that
if
you
don't
request
any
specific
address,
it's
up
to
the
controller,
how
what
address
you
get,
but
in
the
status
you'll
be
able
to
see
whatever
address
your
your
gateway
is
reachable
on
in
the
status
the
same
way
as
you
can
with
ingress.
So
if
we
yeah
you
normally,
when
you
create
an
ingress,
there
is
a.
B
B
So,
as
you
can
see
here,
there's
addresses
and
it
tells
you
the
listeners,
the
status
of
the
listeners
and
then
the
status
of,
and
then
has
general
conditions
about
the
gateway.
If
you
haven't
seen
this
conditions
pattern
before,
you
should
have
it's
in
pods,
it's
in
nodes,
it's
in
lots
of
things.
This
is
like
the
new
sort
of
standard
way
of
telling
you
what
is
happening
with
your
kubernetes
resources
and
so
we've
leaned
hard
into
using
this
standard.
B
Okay,
so
let's,
let's
I'll
dive
a
little
bit
into
into
listeners-
and
this
is
the
api
specification-
this
is
the
actual.
This
is
the
reference.
So
let's
go,
I'm
using
the
v1
beta
1
versions.
We
have
literally
just
released
these.
For
now,
the
for
gateway
gateway,
class
and
http
route
are
all
available
in
beta.
The
spec
is
is
almost
identical
for
the
for
the
beta
and
the
v1
alpha
2
versions.
We
at
some
point
we
will
retire.
B
Then
we
went
out
for
two
versions
of
these
resources,
but
we're
going
to
give
everyone
a
little
while
to
get
around
to
it.
So
in
the
gateway
spec,
you
can
see
that
you've
got
a
gateway
class
name,
that's
just
a
standard,
kubernetes
object,
name,
you've
got
the
listeners
and
you've
got
the
addresses.
B
B
B
So
usually,
what
you
would
do
here
is,
if
you
want
to
expose
a
example.com,
you
have
a
hostname
that
says
example.com
and
okay
tls
config,
that
has
the
tls
details
that
has
a
secret
reference
that
will
have
the
details
of
the
certificate
for
you
yeah.
So
maybe
I
don't.
Let
me
just
give
me,
give
me
a
sec
and
I
might
just
see
if
I
can
pull
up
some
example,
some
example
ones,
because
I
think
it
might
be
handy
for
everybody
to
be
able
to
see
actual
actual
things.
B
B
A
B
A
B
Okay,
great
so
this
is
this
is
a.
This
is
one
of
the
examples
from
the
api
repo.
This
is
just
a
very
basic
http
setup,
so
we've
got
a
gateway
class.
Here,
that's
done
that's
handled
by
the
acme
gateway
controller.
There's
some
there's
a
parameters
left
there.
Then
there
is
a
gateway
that
has
a
single
listener.
B
That's
yeah
called
http
has
the
http
protocol
port
80,
and
then
we
have
the
other
reference
that
you
need
a
http
route,
and
so
this
this
one
this
route.
If
we
go,
I
don't
want
to
flip
back
back
and
forwards
all
the
time.
The
if
you
remember
in
the
diagram,
http
routes
attached
to
a
gateway
and
then
the
gateway
is
part
of
the
gateway
class
and
so
the
way
that
a
http
route
attaches
to
a
gateway
is
via
this
parent
ref
stanza.
B
So
this
is
a
lot
of
different
conditions.
You
can
already
see
and
it
even
even
specifies
the
hdp
method
as
well.
So
this
is
all
of
the
possible
matches
that
you
could
actually
have
in
one
rule,
probably
most
of
the
time
you're
not
going
to
use
this
many
matches
right,
but
yeah
you
can
see
compared
to
ingress.
We,
it
was
very.
The
matching
was
much
more
basic.
You
can
match
on
a
lot
of
different
things
you
can
match
on
the
path
you
can
match
on
query
parameters.
B
So
if
you're
posting
a
form
or
something
you
can
say
hey
if
this
form
has,
if
this
form
field,
has
this
value
then
route
to
a
different
service,
and
you
can
do
it
via
headers
as
well,
notably,
this
lets
you
do
stuff
like
say
is
the
is
the?
Is
there
a
cookie
set,
or
is
there
a
an
author
set
or
something
like
that
and
then
yeah
you
can
match
on
the
method,
so
you
can
say
hey
if
it's
a
get
request,
send
it
here.
If
it's
a
post
request,
send
it
here.
A
B
What
does
it
do?
It
has
a
listener,
but
without
some
http
routes
it
doesn't
do
anything
yeah.
So
so
it
depends
on
the
implementation,
some
implementations
when
you
create
the
gateway.
That
is
a
signal
for
the
for
the
implementation
to
actually
go
and
create
like
the
actual
data
path.
So
in
contour's
case
contour
works
by
having
contour
is
sort
of
the
the
control
plane
and
then
envoy
is
the
data
plane.
B
And
so,
if
you
are
using
contour
with
the
gateway
api,
the
the
when
you
create
a
you
sort
of
install
contour,
you
create
a
gateway
class.
Contour
doesn't
do
anything
when
you
create
a
gateway
control,
says:
aha,
you've
created
a
gateway,
I'm
going
to
go
and
create
an
envoy
dimmer
set,
and
that
daemon
set
will
is
then
ready
to
serve
the
config
that
you
that
you
add
using
http
route,
so
contour
will
go
off
and
for
you
it
will
create
envoys.
It
will
expose
them.
B
Virus
service,
type
load,
balancer,
it'll
hook
up
everything,
it
needs
it.
You
need
it
to
hook
up
and
then
once
that's
done,
then
you're
ready
to
attach
start
attaching
http
routes
to
it.
But
that
is
a
that's
a
implementation,
specific
thing
some
implementations
will
work
like
that
and
other
ones
won't
it's
again,
I'm
being
a
bit
vague,
but
that's
because
the
the
api
is
designed
so
that
you
there's
not
sort
of
one
way
to
do
things.
B
Sure
sure
I
guess
we
might
as
well
do
that
now
so
envoy
gateway
is
a
new
project
under
the
envoy
proxy
organization.
So
it's
part
of
envoy.
It
is
intended
to
be
the
the
sort
of
the
canonical
envoy
implementation
of
the
gateway
api,
so
contour
currently
implements
the
gateway
api
using
envoy,
onward
gateway
is
intended
to
sort
of
make
it
so
that
there's
an
envoy
sponsored
branded.
B
You
know
designed
built
and
owned
equivalent
to
contour
that
that
supports
the
gateway
api
and
only
the
gateway
api,
and
so
the
the
idea
here
is
that
onward
gateway
is
is
sort
of
intended
to
you
know,
there's
so
initially
in
the
project.
There's
the
contour
team,
the
ambassador
team
and
some
effects
on
tetrad
and
some
folks
from.
B
B
B
Okay,
so
yeah.
If
we
go
back
to
top
of
this
and
we
go
to
the
overview,
there's
an
implementations
page,
you
can
see
here
that
there's
a
whole
bunch
of
implementations,
we've
got
yeah,
we've
got
contour
here,
we've
got
emissary,
ingress,
we've
got
glue,
we've
got
gke
provides
their
own
implementation.
B
Proxy
has
started
working
on
things,
console
actually
cops:
istio
kong,
kumar,
nginx
apache.
So
there's
a
lot
of
there's
a
lot
of
people
working
on
different
implementations
of
this
api.
That's
one
of
the
reasons
why
I'm
a
little
vague
when
I
talk
about
it
is
that
different
people
have
been
doing
things
in
slightly
different
ways,
but
in
terms
of
gateway,
you
know
it's
definitely
intended
that
you
know
contour,
that
emissary
ingress
and
hopefully
in
the
future.
B
Some
other
folks,
as
well,
who
are
using
envoy
for
this
reverse
proxy
use
case,
as
opposed
to
the
service
mesh
use
case,
are,
are
all
coming
together
to
work
to
build
something.
I
hope
I
hope
that
hit
ricardo's
question
good
question,
though
so
yeah.
So
where
did
we
get
up
to?
We
got
up
to
talking
about.
B
B
So
you
can
see
here
that
on
the
list
we've
got
two
listeners
here:
we've
got
a
https
listener
that
listens
to
food.example.com,
and
so
it
has
a
cert
for
food.example.com,
and
then
you
have
a
https
listener
that
listens
to
bar.example.com
and
has
a
search
for
that,
notably
these
both
share
report.
That's
100,
okay,
as
long
as
other
details
are
different.
Like
the
hostname
you're
gonna
share
report,
you
need
a
different
hostname.
B
Another
way
to
do
this
is
to
have
a
single
listener,
with
a
port,
443
node
and
and
like
a
wildcard,
tls
and
then
say
hostnamestar.example.com
and
then
then
your
http
routes
can
have
foo
and
bar.example.com
in
them,
and
everything
will
work
and
the
as
long
as
the
the
http
router
hostnames
match
the
the
hostname.
That's
in
the
listener.
Everything
is
fine.
B
B
B
B
B
A
B
Yes,
so
that's
what
filters
are
for
so
right
now:
we've
we've
only
got
a
few,
a
couple
for
like
header,
modifiers
and
some
other
stuff,
and
you
can
do
path
rewrite
as
well.
I'm
not
sure
if
we've
got
an
example
of
that
here,
but
yeah.
So
that's
one
of
the
things
that
you
can
do.
It's
pretty
like
slightly
more
advanced
features,
so
some
of
the
other
things
you
can
do
are
so.
If
we
look
at
this
one
we've
got.
B
This
is
like
the
general
sort
of
http
routing
one
where
you've
got
a
gateway
here
with
a
http
listener,
and
then
we've
got
a
example.com
hostname
and
then
here
we've
also
got
separate
http
routes
that
have
food.example.com
login
and
bar.example.com.
These
all
connect
to
that
example,
lock
gateway.
That
example
gateway.
That
was
in
this
one.
B
So,
basically,
here
you've
got
three
different
http
routes
all
being
exposed
by
the
same
gateway,
and
this
is
again
one
of
the
reasons
that
we
built.
This
is
that
in
the
in
the
old
ingress
world,
if
you
wanted
to
do
this,
everybody
would
have
their
own
ingress
objects
and
if
there
was
if
there
happened
to
be
a
collision
on
a
hostname
or
something
like
that,
what
happened
was
actually
undefined
by
the
spec
ingress
engine
x,
as
as
it
did
in
so
many
other
ways,
because
it
was
because
it's
the
default
standard
set.
B
The
expected
behavior
for
people
is
that,
if
you
have
things
that
ingresses
the
match
exactly
there'll
be
load
balance
between
them,
but
it
actually
was
technically
undefined
by
the
spec.
So
one
of
the
things
we're
trying
to
do
is
to
make
sure
that
we
don't
have
big
behavior
chunks
like
that,
that
are
not
defined
by
the
spec.
That
people
end
up
just
picking
something
so.
B
Yes,
yes,
exa!
Definitely,
so
that's
why
you
can
see
this
parent
refs
is
is
a
list,
so
you
have
definitely
can
have
the
same
http
route
attached
to
multiple
gateways
and
in
fact,
that's
one
of
the
ways
that
we
anticipate
people
to
use.
This
is
to
to
make
it
so
that,
if
you
say
trying
out
a
new
gateway,
implementation
or
you're
migrating
to
a
new
gateway
implementation,
the
people
who
own
the
http
routes
can
do
this
by
just
adding
in
you
know
like
they
can
just
go
like
this.
B
Once
you
save
that
and
apply
it
to
the
cluster,
then
this
http
route
will
be
exposed
via
both
gateways
and
then,
when
you're
ready
to
migrate
across
you
remove
the
example
gateway
and
boom
you're
only
exposed
to
using
the
the
shiny
new
one,
and
so
that
that
that
puts
the
the
purpose
of
this
is
to
put
this
stuff
back
into
the
hands
of
the
application
developer.
So
as
an
application
developer,
you
can
have
like
multiple
gateways
available
in
your
cluster
and
it's
up
to
you,
which
one
you
pick
to
expose
your
route
on.
B
Okay,
so
let
me
close
out
a
couple
of
these
windows,
so
it's
not
to
be
too
confusing.
Another
thing
that
we
probably
should
address.
That's
that
is
kind
of
technically
present
in
ingress,
but
a
bit
tricky
to
do
is
traffic
splitting.
So
you
know
this
is
like
you
might.
This
is
weighted
back-ends,
essentially
so
in
a
http
route,
you
have
your
rules
that
sets
the
things
that
you
match.
B
If
you
look
in
some
of
these
other
in
this
basic
one,
your
rules
lets
you
have
matches,
and
then
it
has
back
end
refs
and
yeah.
Note
that
this
back
end
ref
is
a
list
as
well,
and
so,
if
we
go
into
a
simple
this
simple
traffic
split
this
this
one
is
a
http
route
that
matches
any
traffic.
That's
sent
to
it.
B
There's
no
host
name,
there's
no
path
match,
but
it
says
that
for
any
traffic
that
ends
up
at
this
http
route,
you've
got
two
back
ends
for
v1
and
3v2
and
that
90
of
the
traffic
should
go
to
for
v1
and
10
should
go
to
pv2.
So
this
lets
you
do
canary
deployments,
blue
green
rollouts,
all
the
stuff
that
requires,
like
a
traffic
awaited
traffic,
split.
B
A
B
B
B
You
can
use
the
production
infrastructure
for
your
testing
and
it's
up
to
you
to
then
set
a
header
in
your
requests
and
if
you
do
then
you'll
end
up
at
the
test
at
the
new
version
rather
than
the
old
version.
This
is
another
way
that
you
can
do
some.
You
know
sort
of
canary
slash,
sort
of
dark
roll
out
kind
of
patterns.
A
B
So
there
so
they
need
to
be
distinct.
The
rules
that
you
have
here
need
to
be
distinct.
They
need
to
match
a
different
set
of
things
so
right.
So
in
this
case,
you
can
see
that
this
one
doesn't
have
any
match
criteria.
So
it's
kind
of
the
default
criteria,
and
then
the
the
general
rule
here
is
the
more
specific
matches
should
beat
less
specific
ones.
So
it
doesn't
matter
if
you've
got
this
one,
but
like
after
this,
this,
like
this
second
one
with
the
header
match
after
the
one
or
before
these
are
not
ordered.
B
B
I
think
one
of
the
things
that's
important
for
to
understand
about
the
gateway
about
how
the
gateway
stuff
works.
Is
that
there's
when
the
gateway
when
gateway
when
http
routes
attach
to
the
gateway?
You
know
that
we've
covered
already
that
that
has
like
a
parent
refs
thing,
so
you
say
I
want
to
attach
to
this
gateway.
One
thing
that
is
really
important
to
remember
is
the
gateway
owners,
the
cluster
operator.
B
B
So
if,
if
you
have,
if
you
have
a
a
namespace
that
has
the
expose
apps
labeled
true,
you
can
create
a
http
route
to
expose
your
your
app
and
attach
it
to
this
gateway
and
the
the
implementation
will
look
at
that
and
say:
okay,
your
namespace
has
a
label
that
says
that
you
know
has
a
label
that
matches
so
your
http
route
will
successfully
attach.
If
I
have
a
namespace
that
doesn't
have
that,
and
I
try
to
attach
to
this
gateway,
my
http
right
will
be
rejected
and
it
will
not
attach.
B
So.
The
purpose
here
is
to
make
it
so
that
the
people
who
own
the
gateway,
like
the
the
sort
of
use
cases
that
we're
thinking
about
here,
are
you
I'm
a
cluster
operator.
I
have
a
gateway
that
is
for,
like
you
know,
ultra
ultra
secret
services
only
and
only
a
very
limited
set
of
services
should
be
exposed
by
this
gateway,
and
so
I
want
to
limit
the
people
who
can
actually
attach
their
routes
to
this
gateway.
B
What
a
great,
what
a
great
segue?
Thank
you!
So
yes,
so
if
we
there
are
other,
I
mean
I've
talked
a
lot
about
http
route.
This
is
http.
Router
is
currently
the
resource
that
we
probably
put
the
most
effort
in
development-wise,
but
if
we
go
back
to
the,
if
we
go
back
to
the
main
website,
that's
this
one!
B
Http
route
is
obviously
for
exposing
apps
via
http,
and
it's
explicitly
designed
to
be
a
thing
where
the
gateway
is
a
proxy
and
the
gateway
will
terminate
tls
or
do
it
in
the
clear
and
the
gateway
has
access
to
all
of
the
http
information
right.
So
you
know
the
gateway
reads.
The
whole
http
stream
has
access
to
the
headers.
Has
access
to
the
query
parameters.
B
All
that
sort
of
stuff
tls
route
is
intended
to
be
used
on
a
gateway
where
you
want
to
take
the
tls
connection
and
instead
of
stopping
it
at
the
gateway,
you
take
the
tls
connection
and
just
pass
it
all
the
way
down
to
the
service.
And
so
then
the
kubernetes
service
needs
to
handle
its
own
tls.
So
it
needs
to
have
a
certificate
and
a
key
pair
and
it
needs
to
be
able
to
serve
tls
itself,
but
the
the
reason
you
do.
B
B
Let's
disappear
out
just
saying:
if
we've
got
a
good
example
here
so
yeah,
so
when
you're
doing
a
pass-through
of
your
gateway,
you
have
a
tls,
you
have
tls
route,
and
so
what
that?
What
that
means
is
that
you,
you
know
you
pick
up
the
the
gateway
doesn't
terminate
the
tls,
it
looks
at
it
and
a
tls
connection
has,
I
think,
there's
a
field
called
a
server
name
indicator
the
s.
B
We
can
share
those
on
the
same
port
because
when
the
tls
connection
is
initiated,
part
of
the
tls
handshake
is
the
sni
and
even
without
terminating
the
tls.
Your
the
proxy
can
pick
up
the
tls
and
know
that
you,
the
ones
for
service
a
dogfood.com,
go
to
cinch's,
name,
place
namespace
and
the
ones
for
service
b,
dot
food.com
go
to
next
namespace
or
nix
http
routes.
B
A
B
Yes,
so
yeah,
so
the
tcp
route
is
intended
that
you,
if
you're
using
tls
with
a
tcp
route,
a
tcp
route,
only
lets
you
match
on
source
and
destination
address
and
port.
So
you
know
those
are.
Those
are
the
there's
only
six
pieces
of
information
that
you
can
match
when
you're
doing
a
tcp
ford
you
know
like
so
if
you're
proxying
tcp,
you
know
the
way
generally
the
proxy
works
is
you
know
you
have
to
stop
the
tcp
connection
and
then
start
a
new
one.
B
There
are
a
few
other
things
that
you
can
do
that
you
can
forward
tcp
streams
on,
but
if
you're
doing
a
tls
termination,
you
have
to
stop
the
stream
there.
Do
the
tls
and
shake
out
to
the
client
and
then
start
a
new
tcp
stream
yeah.
So
I
guess
I'm
getting
a
little
in-depth
too
in
depth
there,
but
the
the
idea
here
is
that,
because
we
have
because
we
have
the
different,
the
different
types
of
route
available,
let
me
so:
we've
got
tcp
route,
t
ls
route
and
udp
route.
B
Those
are
intended
to
just
give
you
give
the
api
space
to
describe
those
things.
So
I'm
kind
of
hopeful
that
in
yeah
some
period
of
time
a
year
or
two
that
are
clusters
that
you
run
on
on
a
cloud
provider
instead
of
having
to
use
a
service
of
type
load
balancer
to
expose
your
layer,
4
service,
you'll,
actually
be
able
to
have
you'll,
actually
have
a
gateway.
That
says,
you
know
that
you
can
attach
tcp
routes.
B
To
that
will
say:
hey,
please
expose
my
layer,
4
service
here
you
know
and
that
that's
the
same
thing
as
a
service
type
load.
Balancer
works
today
like
if
you
create
a
service
type
load
balancer.
It
sets
up
a
layer,
4
folding
path
for
tcp
service.
It
might
be
proxied
or
load
balanced
somewhere
upstream.
You
don't
really
care.
All
you
know
is
that
traffic
will
arrive
at
your
at
your
pods
that
are
part
of
that
service,
and
we
want
there
to
be
a
way
that
you
can
do
that
with
the
gateway
api
as
well.
A
B
B
I
don't
really
see
any
reason
why
we
would
so
there
will
be
still
support,
for
you
know
those
things
forever.
I
would
imagine
so
that
we
don't
have
to
worry
about
people
still
wanting
to
use
them.
The
idea
here
is
that
we
can
that
we
make
the
gateway
api
more
attractive
by
giving
you
greater
control
when
you're
talking
about
service
type
load.
B
Balancer,
there's
a
lot
of
magic
in
that
today
you
know,
and
if
you,
if
you
want
to
use
the
same
servicer
type
load,
balancer
on
aws
or
gke
or
azure,
there's
a
whole
series
of
annotations.
You've
got
to
put
on
your
servers
that
sort
of
direct
the
cloud
load
balancer
to
do
certain
things
or
entry
as
well.
B
The
downside
of
that,
of
course,
is
because
there's
less
magic,
it's
more
wordy
it's
more
verbose,
there's
more
stuff.
You've
got
to
do
to
make
it
set
up,
but
the
thing
that's
going
to
let
people
do
is
that
if
you
want
to
just
do
basic
stuff
like
you're
doing
today,
then
service
the
type
load
balancer
will
be
there
and
it'll
be
able
to
just
you
know.
I
just
want
to
expose
my
service.
I
don't
want
to
worry
about
how
it
works.
B
You
can
still
create
one
you'll
always
be
able
to
do
that,
but
when
you
run
into
things
like
oh
I'm
running
in
aws,
and
I
don't
wanna
like
application
load
balancer,
I
want
a
network
load
balancer
right
like
then
you
can
create
a
gateway
that
describes
how
your
network
load
balancer
works
more
closely.
You
know,
I
went
network
load
balancer
and
I
wanted
to
you
know,
and
I
want
to
be
able
to
set
my
cluster
networking
to
cluster.
B
B
So
yeah,
I
think
we're
running
close
to
time,
but
so
I
don't
want
to
dive
too
deep
into
this
stuff,
but
I
did
want
to
just
make
sure
I
hit
that
the
game
api
is
100,
not
just
layer
7..
We
probably
spent
a
lot
of
time
doing
layer
7,
because
that's
what
like
most
use
cases
in
kubernetes
are,
you
know
exposing
http
things,
so
it's
really
easy
to
get
people
to
check
that
there
is
definitely
a
lot
of
interest
in
people
doing
tcp
route,
tls
route
and
and
udp
route.
B
B
B
You
know,
and
so
you
know
that
that
sort
of
strays
into
the
sort
of
tail
scale
kind
of
territory
but
like
that's,
the
like
I've,
we've
tried
to
make
sure
that
the
that
the
concepts
we
have
for
gateway.
Don't
stop
you
from
doing
that
right,
and
so
we
we
have
the
option
of
exploring
that
space
later.
Would
we
do
that
anytime
soon?
No
hell!
No,
the
yeah,
the
there's
too
much
work
already
in
what
we've
got.
We've
got
so
much
work
left
to
do
as
always.
B
We're
definitely
looking
for
you
know,
as
like,
every
open
source
project
always
looking
for
more
people
to
help
with
the
go
api.
I
think
the
most
in
terms
of
sorry
in
terms
of
news
about
the
gateway
api,
the
biggest
news
is
yeah,
hey.
We
just.
We
just
recently
released
a
version
that
contains
the
v1
beta,
1
versions
for
gateway,
getaway
class
and
http
we're
building
out
a
series
of
conformance
tests
that
test
that
can
test
implementations
to
ensure
that
they
conform
it
to
the
spec.
B
We
think
that
this
is
like
absolutely
critical
for
making
sure
that
the
spec
is
actually
viable,
that
you
can
move
your
config
from
one
implementation
to
another
and,
lastly,
yesterday,
actually
the
there's
a
new
sort
of
sub
sub
project,
the
gateway
api
is
a
sub
project
of
sig
networking.
We
now
have
our
own
sub
project,
which
is
the
gamma
initiative
which
is
which
is
about
taking
gateway,
api
resources
and
using
them
to
describe
service
mesh
things.
So
there's
a
lot
of
activity
starting
up
there
as
well
yeah.
That
is
extremely
early
days.
B
We
literally
have
had
one
meeting
about
it,
and
so
you
know
we're
in
a
lot
of
sort
of
very
early
days
stuff
there.
But
the
idea
here
is
that
everybody
wants
to
spin
around
using
this
api
to
describe
all
sorts
of
networking
stuff.
Not
just
you
know,
the
north-south
path
of
ingress
traffic
is
the
first
thing,
but
we
also
want
to
hit
the
be
able
to
use
the
api
to
describe
east-west
traffic
service,
measure-style
traffic.
A
B
A
little
early,
but
I
think
yeah
I
kind
of
any.
If
I
started
to
discuss
too
much
more
about
details
of
anything
like
it's
going
to
take
a
lot
more
than
the
time
we
have
available
so
yeah.
I
kind
of
want
to
keep
this
as
like
an
introduction
for
folks.
The
are
probably
the
other
things
that
are
relevant.
Actually,
I
will
just
share
my
screen
one
more
time
so
that
I
can
sorry
I
keep
flipping
backwards.
B
I
should
point
out
the
contributing
page,
the
community
page
on
the
website
that
has
like
you
know
where
to
go.
We
have
see
so
on
the
kubernetes
slack.
We
have
sig
network
api
is
the
channel
to
come
to
to
talk
about.
We
have
two
meetings
a
week
now
the
the
main
gateway
api
meeting
and
the
gamma
initiative
meeting.
B
B
It's
also
because
it
sounds
like
a
cool
name
that
could
be
in
a
marvel
movie
or
something
the
yeah.
So
I
just
wanted
to
make
sure
that
I
sort
of
pointed
out
that
yeah
this
is
this
is
the
place
to
go
to
sort
of
find
out
more
about
how
to
contribute.
If
you
are
interested
in
contributing
like
I
said,
we
have
far
far
far
more
more
work
than
the
people
who
are
involved
can
currently
do
yeah.
B
A
A
B
We
definitely
have
some
requests
in
the
go
api
for
this
functionality.
You
know
everybody
lots
of
people
want
something
like
this
doing
it
in
the
right.
One
of
the
things
that
we
run
to
a
lot
with
this
api
is
that
we
want
to
make
sure
that
we
do
it
in
a
way,
that's
extensible
and
like
able
to
be
supported
by
lots
of
implementations,
and
so
sometimes
it
can
take
us
a
little
while
to
define
the
constructs
in
such
a
way
that
they
make
sense
they
fit
in
the
api,
and
everyone
agrees.
B
So
we
definitely
have
some
requests
for
this.
It
is
definitely
a
feature
that
we
want,
but
it
is
not
done
yet.
So
yes,
I
hundred
percent
agree.
It
is
really
important
that
that
there
should
be
allow
lists
and
block
list
functionality
available
in
the
api
somewhere,
but
we've
had
a
couple
of
people
have
stabs
that
have
stabs
at
it
and
it
hasn't
felt
like
the
right
thing.
B
B
So
there
is
a
so
there
is
a
so
one
of
the
other
things
that's
relevant
is
that
we
do
is
that
in
the
gateway
api
we
do
we
do
to
caps.
We
do
gateway
enhancement
proposals,
so
this
is
a
gap.
This
is
an
issue
that
describes
a
gap,
one
one
four
one
for
adding,
allow
less
and
block
this
functionality
to
the
gateway
api.
So
you
can
see
there's
a
few
people,
a
few
people
there.