►
Description
Ingress is an interface for L7 load balancing in Kubernetes that has led to many successful ecosystem implementations over the years. Gateway is an open-source Kubernetes API that is designed to evolve the capabilities of Ingress. Gateway focuses on being more expressive, more extensible, and role oriented for Service owners, all while retaining the same portability that made Ingress successful in the first place. Bowei is one of the contributors to the OSS Gateway API and he'll summarize the areas where Gateway improves upon Ingress and provides a modern load balancing API for Kubernetes.
Presenters:
Kaslin Fields, Developer Advocate @Google
Bowei Du, Staff Software Engineer @Google
A
Okay,
let's
get
started
hello
everyone.
Thank
you
very
much
for
joining
us
to
today's
cncf
webinar,
the
evolution
of
ingress
through
the
gateway
api,
I'm
jerry,
fallon
and
I'll
be
moderating
today's
webinar.
We
would
like
to
welcome
our
presenters
today.
Castlin
fields,
developer
advocate
at
google
and
bowie.
Do
staffs
software
engineer
at
google
just
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee.
A
There
is
a
q,
a
box
at
the
bottom
of
your
screen,
so
please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
the
code
of
conduct.
Please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
B
Hello
and
welcome
everyone,
I
think,
as
you
mentioned,
this
is
the
evolution
of
ingress
through
the
gateway
api
and
there
we
go,
like
you
said,
I'm
caslin
fields
and
I'm
a
developer
advocate
at
google.
I
focus
on
devops,
kubernetes
containers
and
all
sorts
of
things
and
I'm
also
a
cloud
native
computing
foundation
ambassador
and
today
I
have
with
me.
C
Hi,
I'm
bowie,
I'm
one
of
the
leads
on
kubernetes
networking
at
gk
networking
at
google.
B
So,
let's
get
started
so
today
we're
going
to
be
talking
about
gateway
api,
and
I
wanted
to
tell
you
all
a
little
background
on
how
I
found
out
about
this,
which,
honestly
I
don't
really
know.
I
am
a
kubernetes
kind
of
person,
so
I'm
in
all
these
kubernetes
groups
and
things
and
gateway
api
was
one
of
those
things
that
I
heard
about
at
some
point
and
I
was
like
wow.
I
would
love
to
learn
more
about
that.
B
So
I
learned
about
boei
and
the
team
creating
gateway
api
and
I
started
learning
about
it.
So
what
I'm
going
to
share
with
you
all
today
is
what
I've
learned
so
far,
I'm
going
to
give
you
all
a
little
bit
of
a
demo
and
bowie's
going
to
jump
in
a
little
bit
deeper,
so
to
start
off
with
what
is
gateway,
api
and
kind
of.
Where
does
it
come
from
so
in
terms
of
kubernetes
ingress
and
the
ways
that
kind
of
networking
and
traffic
within
kubernetes
are
handled?
B
Traditionally,
these
types
of
roles
have
been
a
single
type
of
role,
and
it's
been
very
self-service
in
style,
but
over
time,
as
more
and
more
companies
are
are
adopting
kind
of
the
devops
methodology
for
dealing
with
kubernetes
and
adopting
cloud-native
technologies.
B
This
is
changing.
There
are
now
many
roles
that
kind
of
touch
this
space,
and
so
the
permissions
and
the
way
ways
that
people
interact
with
these
tools
are
changing,
as
these
roles
are
kind
of
diversifying.
B
So
traditionally
these
kind
of
categories
of
tools
have
been
more
separated,
but
as
devops
methodology
takes
hold,
as
these
roles
are,
transforming,
these
tools
are
also
transforming
and
the
intersections
between
them
are
getting
more
and
more.
There's
more
and
more
overlap
between
the
feature
sets.
So
the
the
kind
of
landscape
here
has
been
around
ingress
and
networking
has
been
evolving,
so
the
goals
of
the
gateway
api
project
are
to
better
model.
B
The
personas
and
the
roles
that
are
involved
with
services
and
load
balancing,
like
I
mentioned,
they've,
been
kind
of
changing
with
the
adoption
of
devops
and
we
want
to
support
modern
load
balancing
features
while
maintaining
portability
or
maybe
a
predictability.
We'll
talk
more
about
what
that
means
in
a
little
bit
and
we
want
to
have
standard
mechanisms
for
extending
apis
in
this
space
so
that,
as
the
api
grows
and
as
vendor-specific
behaviors
are
needed
and
implemented,
everything
is
kind
of
consistent
and
standard.
B
So
how
is
gateway
api
going
to
accomplish
these
things
for
dealing
with
personas
and
roles?
You
have
to
incorporate
that
into
the
resource
model
of
how
you
do
ingress,
how
you
create
load
balancers?
How
do
different
roles
use
those
resources,
so
part
of
that
is
the
resource
model.
Part
of
that
is
our
back
rule-based
access
control
and,
if
you're
familiar
with
kubernetes,
you
probably
or
lots
of
other
things.
B
Part
of
that
is
in
the
resource
model
and
there's
kind
of
a
polymorphism
like
strategy
that
the
team
has
adopted
here,
which
I'll
talk
more
about
again.
B
So
did
you
have
something
to
add:
polly,
nope,
okay,
sorry
so
modeling?
Let's,
first
talk
about
services,
kubernetes
services,
a
service
as
a
resource
kind
of
handles
a
lot
of
jobs.
If
you
are
just
getting
started
with
kubernetes,
the
first
kind
of
exposure
that
you
get
to
services
is
probably
as
a
method
of
exposure
for
your
applications
that
you're
running
in
kubernetes.
B
So
there
are
a
variety
of
methods
for
doing
that.
You
can
have
cluster
ip
type
services,
node,
port
and
load
balancer
type
services,
and
I
know
in
some
of
the
early
tutorials
I
did
with
kubernetes
you'd
actually
do
like
cube
ctl
expose
whatever
your
pod
was,
and
that
is
how
you
enable
sending
traffic
to
that
application.
How
you
connect
it
to
other
applications,
so
services
are
a
method
of
exposure.
B
Another
important
point
that
sometimes
people
forget
about
or
don't
think
about
enough
is
that
services
are
a
method
of
grouping
back
ends.
A
workload
is
often
not
just
a
single
pod.
It's
often
several
pods
altogether,
and
so
you
give
those
all
selectors
and
the
service
kind
of
connects
back
to
all
of
those
different
selected
pods.
So
it's
a
grouping
of
back
ends
and
it's
also
a
way
for
you
to
place
attributes
on
on
your
service.
B
For
example,
you
can
describe
how
to
handle
traffic
for
the
service
with
external
traffic
policy
and
then
there's
things
like
session
affinity,
so
services
kind
of
have
a
lot
of
jobs,
and
so,
as
such
they
can
be
kind
of
complex
to
handle.
So
there's
this
concept
of
ingress
that
kubernetes
introduced
and
we're
introducing
gateway
api
to
kind
of
separate
out
the
chunks
so
that
they
make
more
sense
with
the
different
roles
that
have
to
deal
with
services.
B
So
let's
go
over
those
roles
that
we
keep
talking
about.
The
three
roles
that
we're
going
to
kind
of
focus
on
here
are
the
infrastructure
provider,
and
this
is
going
to
be
whoever
is
providing
the
infrastructure
for
cluster
creation.
This
could
be
a
cloud
provider
or,
for
example,
an
internal
platforms
of
the
service
team,
there's
also
the
cluster
operator
or
cluster
administrator
network
operations
site
reliability.
Engineer
these
types
of
roles
do
cluster
management.
B
B
So
our
example
here
is
alice.
Our
user
can
act
as
a
cluster
operator,
which
is
our
role
with
permission
to
update
the
thing
that
alice
can
do
the
configuration
of
a
gateway,
the
resource
that
alice
can
do
this
action
to.
B
So.
The
important
thing
here
is
to
remember
that
there
are
many
different
types
of
roles:
different
personas,
that
need
to
be
able
to
do
different
things.
They
need
different
permissions,
so
this
is
a
way
to
kind
of
control
that
and
we
need
to
divide
up
the
resources
so
that
roles
can
be
given
different
types
of
access,
depending
on
what
they
need
to
do,
and
I
want
to
mention
that
the
kubernetes
api
implements
are
back,
so
apis
mostly
have
kind
of
the
same
set
of
verbs,
and
so
if
you're
familiar
with
kubernetes
are
back.
B
You'll
you'll
know
a
little
bit
of
this
already,
and
this
will
relate
back
to
the
way
that
gateway
api
is
implemented
which
you'll
see.
So
I
want
to
talk
for
a
second
about
ingress.
So
kubernetes
has
this
concept
of
an
ingress
class
and
an
ingress
resource,
and
the
ingress
resource
in
kubernetes
is
more
of
that
self-service
model.
I
mentioned
how
the
roles
have
been
changing
over
time,
so
this
is,
we
think,
not
as
representative
of
of
what
these
roles
are
doing
now,
that
kind
of
devops
has
started
to
become
the
way
of
things.
B
So
ingress
is
a
self-service
model.
The
ingress
class
is
the
part
that's
created
by
the
infrastructure
provider.
If
we're
talking
about
those
roles
and
then
the
application
developer
kind
of
manages
both
the
ingress
and
the
service
and
ingress
is
limited
to
kind
of
simple
l7
descriptions,
so
it
kind
of
ignores
the
cluster
administrator
all
together
here,
and
this
is
arranged
differently
in
the
gateway
api
model,
and
this
is
all
centered
around
those
roles
that
we
just
talked
about.
B
So
the
idea
here
is
to
decouple
along
the
role
concept,
so
the
first
one
we
talked
about
infrastructure
providers.
They
are
going
to
deal
with
the
gateway
class,
which
basically
sets
up
a
template
of
this
is
the
types
of
load
balancers,
basically,
that
you
can
have
in
kubernetes
for
your
various
services.
B
Then
the
cluster
administrator
will
take
those
templates
and
actually
implement
them
as
actual
resources
and
kubernetes,
which
are
called
gateways,
and
the
application
developer
cares
then
about
routes
and
services.
So
this
is
a
little
bit
closer
to
what
they
actually
care
about.
It's
all
about
the
types
of
traffic
that
are
coming
in
and
where
that
traffic
goes,
making
sure
that
it's
going
to
their
services
in
the
way
that
they
want
it
to
so
in
terms
of
concepts.
B
The
gateway
is
all
about
exposure
and
access,
it's
kind
of
a
load
balancer
it's
taking
in
traffic
and
then
the
routes
define
more
where
that
traffic
is
going
to
go.
It's
all
about
routing
protocol,
specific
attributes
and
then
the
services
are
like.
We
said
about
grouping
pods,
dealing
with
back
ends
and
allowing
for
that
type
of
selection.
B
So
here's
a
look
at
what
the
api
kind
of
looks
like
you'll
see
this
several
times.
It'll
make
a
lot
more
sense,
probably
in
the
demo.
If
you
want
to
check
that
out
so
there's
the
gateway
class,
which
I
mentioned,
is
kind
of
a
template
and
there's
the
gateway
itself,
and
then
we've
got
these
two
http
routes
that
are
defining
where
traffic
goes,
and
then
they
go
to
the
backend
services.
B
So
you
can
get
kind
of
an
idea
for
what
this
flow
looks
like
and
now
boy
are
always
going
to
go
into
more
detail
on
that
in
a
minute.
There's
one
more
thing
I
wanted
to
talk
about
here,
which
is
portability
and
predictability.
I
used
these
words
earlier.
What
does
that
really
mean
and
how
is
it
being
implemented
in
gateway
api?
B
B
The
challenge
is
that
sometimes
the
ways
that
these
are
implemented
are
very
standardized,
and
so
they
can
be
kind
of
challenging
to
deal
with
so
in
developing
the
gateway
api.
We
know
that
it's
going
to
grow
over
time
and
we
want
to
make
sure
that
extensions
to
that
api
make
sense.
They're
kind
of
predictable,
they're
really
easy
to
use.
B
B
B
If
it's
just
kind
of
a
one-off
type
of
thing,
so
core
must
be
supported.
Extended
is
kind
of
a
feature
by
feature
thing.
B
It
might
be
supported,
but
it
really
must
be
portable,
so
we
want
to
make
sure
that
it
conforms
to
our
specification
and
it's
part
of
the
api
schema
and
then
implementation
specific
is
no
guarantees
there.
It's
whatever
you
need
for
your
specific
use
case,
and
how
will
we
make
this
happen
with
conformance
tests?
B
So,
if
you're
doing
an
extended
feature
definition,
then
we're
going
to
require
that
you
do
self-contained
conformance
to
make
sure
that
that
conforms
to
the
specification
and
everything
kind
of
makes
sense
between
the
core
api
and
the
extended
api
and
all
extended
features
must
be
checkable
statically,
so
conformance
all
around
for
the
extended
portions
of
the
api.
Basically.
B
And
extensibility,
so
I
mentioned
earlier
that
this
is
kind
of
a
polymorphic
style
that
is
being
adopted
to
try
to
kind
of
make
this
really
extensible.
B
So
what
we
mean
here
is
gateways
can
refer
to
different
kinds
of
routes.
For
one
thing
you
can
have
http
tcp
or
even
custom
routes,
so
we've
got
this
concept
of
a
route
and
it
can
be
used
in
many
different
ways
and
you
can
also
route
to
back
ends
in
a
kind
of
a
polymorphic
way
and
if
you're
familiar
with
the
concept
of
custom,
resource
definitions
and
kubernetes,
like
I
mentioned
earlier,
this
is
using
custom
resource
definitions
to
make
this
work,
cool
and
now
boy
is
going
to
go
into
more
detail
on
all
this.
C
Yeah
thanks
caslin,
so
now
we're
just
going
to
go
into
sort
of
give
a
taste
of
the
api.
So
your
next
slide
so
we'll
go
through
a
user
story
where
we
have
the
different
roles.
So
imagine
we
have
alice
the
ias
provider,
we
have
bob
the
sre
and
we
have
carol
the
application
developer
next
slide.
C
So
first
we
start
with
alice
the
ias,
she's
the
person
who's,
providing,
let's
say
the
cloud
provider
or
in
many
cases
the
person
who
sets
up
the
overall
infrastructure
for
your
kubernetes
clusters
and
as
part
of
this,
she
has
basically
two
flavors
of
low
bouncers
that
she
wants
her
users
to
use.
She
has
one,
that's
external,
and
this
basically
creates
a
load
balancer,
that's
accessible
on
the
internet
and
one
that's
internal,
and
this
is
internal
to
the
vpc.
C
This
kind
of
comes
as
part
of
the
infrastructure
for
kubernetes
clusters
that
she
is
providing
the
way
she
will
sort
of
express
this
in
the
api
is
that
she
will
create
two
gateway
classes
that
come
basically
pre-installed
with
the
kubernetes
cluster.
She
will
create
a
gateway
class
called
external
and
then
because
you
know
it's
alice
cloud,
so
she
has
a
controller
called
alice.io,
that's
going
to
facilitate
all
the
gateway
apis.
C
In
addition,
she
has
another
gateway,
class
called
internal
and
similarly,
it's
controlled
by
the
same
controller.
What
this
gives
alice's
users
is
a
way
to
kind
of
talk
about
these
functionalities
without
actually
talking
directly
about
alice.io
gateway,
controller
or
kind
of
knowing
the
internal
implementation.
Details,
for
example,
alice
may
be
changing
her
controller
or
she
may
be
changing
attributes
about.
You
know
how
the
controller
works
and
it's
set
up
and
so
forth
and
kind
of
the
users
of
her
cluster.
Actually
don't
need
to
understand
that
they
just
need
to
understand
that.
C
C
So
now
that
alice
has
set
up
this
overall
infrastructure
next
comes
bob,
the
sre,
so
bob
is
in
charge
of
managing
actually
stuff.
That's
running
inside
the
cluster,
not
just
the
infrastructure
itself
and
he's
also
responsible
for
various
policies,
especially
around
load
balancers.
For
example.
It
would
be
bad
if
you
know
arbitrary
users
can
just
kind
of
expose
their
applications
on
the
internet.
They'll
probably
be
quite
unhappy,
so
bob
wants
a
couple
of
things,
so
bob
wants
that
only
certain
name
spaces
can
deploy
external
lbs.
C
So
imagine
that
he's
going
to
control
how
to
label
namespaces,
and
he
basically
says
if
I
label
your
namespace
with
internet
external,
you
can
create
an
external
lb.
Otherwise,
no
like
I
don't
want
you
to
be
able
to
go
on
the
internet
also.
The
second
thing
that
bob
wants
is
that
he
knows
that
developers
want
to
be
able
to.
You,
know,
experiment
and
just
kind
of
do
their
dev
work,
so
anyone
can
deploy
an
internal
lb
and
finally,
anyone
can
deploy
an
in-cluster
proxy
for
testing.
C
Bob
knows
that
alice.io
is
going
to
be
charging
for
these
lbs
and
then
maybe
he
has
some
custom
configurations.
So
he
wants
to
use
a
acme.io
proxy,
so
he
basically
deploys
that
as
well.
So
first
we
have
these
gateway
class
definitions
and
bob
actually
edits.
One
of
the
definitions
for
external
to
basically
say
that
only
those
with
internet
external
can,
on
their
labels
on
their
name.
Space,
can
create
gateways
of
this
class
internal
he's
going
to
allow
everyone.
C
That's
the
default
so
he's
going
to
allow
everyone
to
create
an
internal
class
and
then
actually
caslin.
Can
click
he's
going
to
actually
install
an
acme
io
proxy,
and
this
basically
adds
another
gateway
class
he's
going
to
call
me
a
test.
He
says:
hey
if
you
want
to
test
things
out,
use
gateways
of
this
class.
Okay
next
slide.
C
So
now
we
get
to
carol
carol's
the
dev
she's
going
to
be
developing
the
application
and
kind
of
writing
descriptions
about
how
her
application
is
routed
and
attributes
about
it.
So
she
has
two
applications.
One
is
store,
one
is
checkout,
the
first
one
store.
She
writes
a
route
for
store,
so
this
is
stored
on
acme,
rail
and
you
know
it
has
a
bunch
of
rules
about
matching.
Let's
say
route
goes
to
the
store
service
and
then
the
search
path
goes
to
the
search
service
and
her
other
application
is
a
different
host
name.
C
A
C
So
just
to
highlight
the
alpha.
Basically,
the
schema
looks
like
this,
but
we-
the
one
thing
I
want
to
note,
is
that
we
added
in
a
bunch
of
advanced,
slow,
well,
not
really
advanced,
but
basically
modern,
load,
balancing
features
that
you
can
express
with
hp
route
and
one
of
the
ones
that
I
think
has
been
commonly
asked.
Is
this
header
matching
so
a
lot
of
the
common
http
load
balancing
features
we've
added
into
the
new
api,
as
opposed
to
the
previous
ingress?
Okay,
next
slide.
C
So
to
continue
this
story
so
carol
the
dev.
She
wants
to
test
out
her
applications,
so
she
creates
a
gateway
of
class
tests
in
her
name
space,
and
you
see
that
this
is
a
gateway
definition,
and
so
she
calls
it
test
and
she
defines
a
bunch
of
listeners
that
refer
to
routes
and
actually
by
default,
you
can
take
up
pick
up.
Have
your
gateway
pick
up
all
the
routes
in
your
namespace?
It's
just
an
easy
way
to
use
it
and
you'll
notice
that
there's
a
dashed
box
around
all
the
resources.
C
These
are
all
created
in
carol's
namespace,
so
she
has
control
over
all
the
objects.
In
here
so
click
so
a
gateway
to
kind
of
get
into
more
detail
about
what
it
is
that
what
does
this
api
represent?
So
gateway
is
actually
a
request
for
an
lb
and
you'll
notice
here
that
it's
actually
quite
underspecified,
for
example,
I'm
requesting
a
listener
for
protocol
http,
but
I
didn't
spill
in
the
port
I
didn't
fill
in
the
address
I
wanted
and
it's
up
to
the
controller
to
kind
of
fill
in
the
blanks.
C
This
basically
makes
it
easy
for
the
application
developer
to
basically
specify
only
things
that
they
care
about,
for
example,
in
carroll's
case.
She
only
cares
about
exposing
her
applications
using
http
for
testing.
She
doesn't
necessarily,
you
know,
require
a
particular
ip
address,
or
you
know
hosting
it
on
a
different
port
than
port
80.,
and
the
controller
will
basically
look
at
this
and
say.
Oh,
I
can
satisfy
your
request
for
exposing
your
services
and
routes
in
this
way.
You
know
I
will
stamp
it
out
in
next
slide
yeah.
C
So
here
you
see
that
she
only
specifies
http,
it's
underspecified,
but
it's
okay.
The
controller
can
fill
in
the
blanks
next
slide,
all
right.
So
once
she
has
created
the
gateway,
this
is
where
the
controller
machinery
just
kicks
into
action,
so
the
gateway
is
somewhat
the
cornerstone
resource,
that's
going
to
tie
in
basically
gateway
classes,
routes
and
services,
all
together
to
actually
create
the
load
bouncer
and,
like
I
said
before,
she
picks
up
all
the
routes
in
her
local
name.
Space
next
slide,
yep
next
slide.
C
Okay,
so
now
it's
all
wired
up
and
actually
this
wires
up
the
gateway
with
the
acme
dot,
io
proxy
class.
That
bob
has
installed
previously
and
he's
given
kind
of
access
to
every
single
dev
on
the
cluster,
and
this
lets
carol
test
her
stuff.
So
next
slide
yep.
So
she
does
curl
you'll
notice
that
in
the
status,
it's
just
a
raw
ip
address,
because
probably
this
one
doesn't
integrate
with
dns
in
any
way
and
she
can
test
other
stuff.
C
The
next
slide.
Okay,
so
one
thing
to
note
is
that
carol
cannot
create
an
external
class
gateway
and
serve
production
traffic
she's
just
not
allowed
and
you'll
see
here.
Basically,
if
she
tried
to
reference
the
external
class,
it's
just
denied
by
the
controller
next
slide
now
bob
the
sre
manages
external
gateways
so
clearly
at
some
point
carol,
hopefully
after
she
checks
in
all
her
code
and
it
all
works
wants
to
put
into
production.
So
what
does
he
do
so?
Actually
he
can
explicitly
reference
her
route
and
it's
actually
in
a
different
namespace.
C
So
you'll
see
this
namespace
bob
seems
like
that's
not
great
practice,
to
name
your
name
spaces
after
yourself,
but
you
know
this
is
his
production
namespace
and
from
that
namespace
he
creates
a
gateway
of
class
external
he's
allowed
to
do
so
because
his
namespace
has
the
appropriate
labels
and
he
references
a
route
in
carol's
name
space,
so
he
actually
brings
carol's
routes
into
this
gateway
and
exposed
in
doing
so
exposes
it
into
the
internet.
C
C
You
know
in
random
namespaces
next
slide,
so
here
after
all,
this
is
wired
up
by
bob
carol
is
able
to
basically
deploy
her
application
to
store.acme.io
and
it
works
next
slide.
Okay,
so
a
recap
on
the
user
stories
right.
So
you
know
what
are
the
roles
of
all
these
api
objects,
so
gateway
class
basically
allows
you
to
as
the
iis
provider
or
even
the
sre
kind
of
support,
multiple
classes
of
load,
balancing
multiple
implementations
side
by
side,
and
it
reflects
the
capabilities
of
the
iis
or
underlying
deployed
infrastructure.
C
In
fact,
you
know
you
can
install
a
new
gateway.
Well,
assuming
you
have
permissions,
you
can
install
new
gateway
classes,
lets
you
mix
and
match
different
implementations
as
you
see
fit.
It
also
gives
a
layer
of
abstraction
from
the
underlying
platform.
For
example,
if
you're
managing
a
cluster
and
you're
kind
of
building
a
platform
for
your
users,
you
can
kind
of
hide
them
from
the
fact
that
oh,
this
is
going
to
be
a
specific
kind
of
load.
C
C
You
know
what
is
the
virtual
ip
import?
What
kind
of
proxy
is
going
to
be
used,
and
also
this
is
the
thing
that
ties
it
together
to
kind
of
kick
off
the
controller
action
to
expose
your
application.
Finally,
we
have
route
and
service,
so
route
defines
routing
for
your
application
for
a
given
protocol
and
then
services
you
know.
Basically,
I
think
what
service
does
really
well
is
define
how
your
back-ends
are
grouped,
and
this
is
the
decomposition
that
we're
hoping
we
can
move
towards.
C
As
mentioned
earlier,
it's
like
how
do
we
take
these
things
that
are
just
all
focused
on
service
or
all
combination
of
service
and
ingress
and
kind
of
decompose
them
into
their
different
roles,
and
then,
once
you
have
decomposed
them
into
different
resources,
you
can
assign
them
to
different
roles
next
slide,
so
also
going
into
like
what
we're
seeing
in
the
user
story.
So
we
can
deploy
multiple
classes
of
load,
balancing,
we
can
control
access
to
different
gateway
classes
and
we
can
also
control
access
to
different
gateways.
C
So
basically,
this
lets
you
do
cross
namespace,
sharing
in
a
safe
manner,
and
it's
kind
of,
if
you
think
about
it
as
a
access,
is
a
handshake
between
gateway
and
routes.
Next
slide.
C
So
if
you
are
astute
and
thinking
through,
you
know
what's
happening
here
clearly,
if
you
have
a
bunch
of
routes,
they
get
merged
into
a
gateway
and
gateway
and
routes
may
not
be
compatible.
So
when
you
kind
of
do
this
sort
of
merging,
when
you
have
split
up
the
object
across
like
what
used
to
be
a
single
object,
which
is
ingress,
you
kind
of
split
into
multiple
objects
now
with
gateway
routes
and
so
forth,
you
can
result
in
conflicts.
C
C
So
it
turns
out
the
details,
probably
are
tricky
and
you
should
read
the
comments
in
the
documentation,
but
we
have
three
main
principles
that
we
are
following
in
terms
of
how
to
handle
conflicts.
So
the
first
one
is:
do
no
harm.
So
when
you
have
a
conflict,
you
don't
want
to
break
things
that
are
working.
For
example,
if
you
have
a
load
bouncer
and
the
store
acne
store
is
all
wired
up.
You
want
to
drop
as
little
traffic
as
possible.
C
If
someone
absolutely
pushes
a
conflict
into
the
system,
you
want
to
be
consistent,
so
you
want
to
provide
consistent
behavior
when
conflicts
occur.
So
if
you
had
a
state,
you
know,
object
a
and
then
object
b
got
created.
It
should
probably
be
the
equivalent
to
having
b
and
a
because
in
kubernetes,
the
notion
of
time
is
quite
loose
and
you
can't
really
guarantee
like.
I
knew
that
a
happened
and
that
b
happened
and
then
b
and
a
unless
it's
like
stably
expressed
somehow
or
recorded
somehow
so
prefer
more
specific
matches
less
specific
matches.
C
I
think
this
is
just
expected
behavior
that
many
people
have
intuitively
and
then,
as
I
said
before,
you
should
decide
all
these
conflicts
using
stable
properties.
What
I
mean
by
stable
properties
is
basically
it's
written
in
the
database,
so
creation
timestamp
and
then
maybe
some
sort
of
canonical
order,
such
as
name
space,
common
name.
C
Finally,
the
thing
that's
really
confusing
of
conflicts
is
that's
very
hard
for
humans
to
understand.
So
we
should
basically
make
it
clear
which
con
configuration
has
been
chosen
and
then
all
the
conflicts
will
be
communicated
via
the
object
status
and
that's
something
that
we've
been
working
on
extensively
in
terms
of
defining
the
apis
to
really
make
it
clear
in
the
status.
So
next
slide
now,
let's
talk
about
extension
points.
So
right
now
in
the
alpha,
we
have
a
couple
of
extension
points
as
caslin
alluded
to
earlier.
C
They
use
basically
this
sort
of
polymorphic
like
reference,
so
we
have
a
bunch
of
extension,
ref
references
that
can
reference
arbitrary
crds,
and
this
is
where
you
can
plug
in
your
own
custom
crds
for
your,
for
example,
your
vendor
specific
properties,
as
well
as
just
allow
you
to
sort
of
reuse
the
api
without
having
to
kind
of
throw
all
of
the
different
fields
into
one
big
resource.
C
There's.
A
couple
of
existing
extension
points
that
we
have
in
the
alpha
gateway
class
has
the
extension
point
for
parameters
gateway
listeners
each
have
an
extension
ref
for
customizing
listener
properties
and
then
routes
have
this
notion
of
filters
which
allows
you
to
have
extensions
in
terms
of
how
the
processing
works
and
that
back
ends
can
be
referred
to
more
than
just
services.
Ingress
actually
has
this
in
the
ga
form
is
that
you
can
point
to
just
more
than
services
and
the
same
thing
gets
carried
over
to
the
gateway
apis.
C
C
So
one
thing
that
we're
very
excited
about
in
the
service,
apis
and
gateway
sort
of
group
that
we're
working
on
is
that
we're
actually
very
close
to
the
alpha,
so
it
should
be
cut
in
a
matter
of
weeks.
C
C
C
We
need
to
define
those
conformance
tests
that
we
talked
about
before
and
then
one
thing
that
we
punted
for
now,
that
was
in
previous
conversations
about
gateway,
is
how
to
do
delegation,
so
not
not
only
delegate
from
gateway
to
route
but
actually
from
route
to
other
routes.
Sort
of
can
you
carve
off,
say
sections
of
your
website
and
then
kind
of
delegate
it
to
a
different
team,
a
different
name
space.
C
B
C
Yeah,
this
is
a
there's,
a
landing
page
at
the
bottom.
It's
like
a
sub
project
of
sig
network
and
we
have
a
lot
of
participation
from
many
different
vendors
and
really
we're
looking
at
creating
a
portable
sort
of
standard,
and
a
lot
of
the
discussion
is
around
how
to
do
that
and
that's
where
the
difficulty
is.
B
Yeah
so
now,
like
I
mentioned,
I'm
pretty
new
to
this
stuff,
but
I
got
to
do
some
cool
hands-on,
trying
this
out,
if
you're
interested
and
want
to
do
that
as
well,
feel
free
to
join
us
at
this
bitly
link
or
find
the
thing
on
github.
When
I
move
over
to
that
in
a
minute,
sorry,
I
need
to
like
change
this
surprise.
There
was
a
terminal
under
there
all
along.
B
Okay,
so
what
I've
got
up
over
here
is
in
github.
I've
got
google
cloud
platform,
slash
gke
networking
recipes,
slash
gateway
in
here,
so
this
is
a
fun
little
tutorial.
If
you
want
to
try
this
stuff
out
for
yourself,
it's
pretty
easy
to
get
started
with.
I
didn't
really
have
too
much
trouble
with
it,
so
I
would
recommend
if
you
want
to
check
it
out
and
I'm
just
going
to
kind
of
run
through
this
a
little
bit.
B
So
if
you're
new
to
this,
like,
I
am-
which
I
assume
pretty
much
everyone
is,
this
is
a
good
way
to
get
hands-on.
What
you
need
is
a
kubernetes
cluster
you'll
install
the
api
custom
resource
definitions,
you'll
install
seo
and
you'll
need
to.
I
think
I've
already
got
this
stuff
here,
but
I'll
run
it
again
just
to
make
sure
so.
I'm
gonna
need
these
kind
of
parameters
set.
B
I'm
gonna
copy
this
and
paste
it
over
just
to
make
sure
that
I've
got
all
those
set
up
there.
We
go
cool
so
then
we
hop
into
the
tutorial.
So
we
talked
earlier
about
gateways
and
the
different
styles
kind
of
that
you
can
use
gateways
in
like
you
can
have
a
gateway
that
routes
to
a
single
service
you
can
have
multi-service
gateway.
B
B
Foo
and
bar
is
that
what
it
creates
namespace
deployment
yep,
we
can
see
it
creates
the
deployment
foo
and
it
creates
the
deployment
bar.
So
I
already
ran
this
command,
but
if
you're
following
along
at
home,
watching
the
recording
or
something
run,
cube,
ctl
apply
a
demo
and
you'll
want
to
be
in
basically
this
repo
that
we're
in
right
now
so
you'd
have
to
get
this
from
github
and
do
that.
B
B
This
is
what
a
definition
of
a
gateway
class
looks
like
we
talked
earlier
about
how
a
gateway
class
is
basically
defining
kind
of
a
template
for
gateway
resources
that
you'll
be
able
to
create
later.
Since
I
have
istio
installed,
just
it's
an
easy
way
to
try
this
out.
This
is
going
to
be
istio
style
gateways,
and
I
can
apply
that.
I
wonder
if
I
already
have
one:
let's
see,
cube
cpl.
B
Right
class,
I
don't
know
yeah,
so
I
already
did
this.
I've
got
my
gateway
class
up
and
running,
but
how
you
would
do
it
is
just
to
run
the
thing
from
this
repo,
so
I've
got
my
getaway
class
next
thing
is
to
create
some
gateways,
and
this
is
what
a
gateway
definition
looks
like
you
can
see.
We've
got
our
gateway.
Important
thing
here
to
know
about
is
the
listeners
for
your
gateway.
B
What
traffic
is
going
to
be
coming
into
this
gateway
that
it's
going
to
have
to
manage
so
we're
listening
on
port
80,
we're
listening
for
http
protocol
traffic
and
it's
going
to
connect
to
http
routes?
B
We
talked
about
our
gateway
routes
earlier,
so
this
is
going
to
be
able
to
connect
to
routes
of
the
http
kind
of
type,
and
you
can
see
a
cool
diagram
of
how
all
that
works
here,
and
so
here's
what
the
http
route
definition
looks
like
if
you
want
to
check
that
out,
it's
going
to
define
kind
of
where
stuff
goes,
the
name
of
the
service
that
your
incoming
traffic
is
going
to
go
to,
and
this
one
is
a
single
service
style.
I
think
so
we're
going
to
apply
that.
B
B
Let's
just
copy
paste,
that
in
here
cool
and
so
now
I
should
have
a
gateway
setup
and
a
route
set
up
yay.
How
do
I
know
that
that
does
anything
so
we're
just
going
to
run
a
curl
command
with
those
parameters
that
I
set
up
earlier,
so
you
can
see
here
that
it's
returning
some
information.
B
I
really
like
the
pod
name.
Emoji,
that's
a
lot
of
fun,
so
you
can
see
that
we
sent
some
traffic
to
our
gateway
to
the
porch
that
our
gateway
was
listening
on
and
then
had
that
routed
to
metadata.
Foo
is
telling
us
that
we're
hitting
the
correct
pod
on
the
back
end
cool.
So
let's
try
doing
it
with
multiple
services
on
the
back
end.
B
So
if
we
send
in
some
traffic
that
is
intended
to
be
destined
for
the
foo
service
back-end,
we
can
do
this.
Curl
command
we're
specifying
hostfu.com,
and
so
you
can
see
in
the
metadata
that
that
spits
out
that
it's
hitting
the
fu
backend
service
and
we
can
do
the
same
thing
with
bar
so
that
we
know
that
both
of
our
back
ends
are
available
and
we
can
hit
them
both
depending
on
what
we
put
in,
and
so
that's
hitting
the
bar
service.
B
B
B
I
mean
it
said
it
deployed
it,
so
I
don't
really
need
to
check,
but
there
you
go
there.
It
is
and
then
we're
going
to
create
another
new
http
route.
That's
going
to
route
some
of
our
traffic
to
baz.com
well
to
our
baz
service
on
the
back
end
from
baz.com
hostings.
B
B
B
Another
tab
here
and
I'm
gonna
have
to
run
back
up
to
the
top
of
this
and
grab
our
export
or
export
our
parameter
names
again
for
this
new
tab.
Otherwise
this
wouldn't
work,
because
that
would
be
silly,
not
that
I
did
that
the
first
time,
because
I
definitely
did
and
then
I'm
gonna
set
up
a
continuous
curl
command
so
that
you
can
see
as
we
flip
over.
B
So
all
of
our
traffic
is
going
to
our
v1
of
our
back
end
right
now
and
now
we
want
to
apply
the
new
traffic
splitting
route
where
it
actually
splits
it.
This
was
a
hundred
and
zero,
so
this
new
one
is
going
to
do
2080.,
so
20
of
the
traffic
is
going
to
start
going
to
v2.
So
you'll
start
seeing
v2
pop
up
here,
every
now
and
then,
but
mostly
it's
going
to
be
v1,
and
then
we
can
switch
our
traffic
completely
over
to
our
v2.
B
So
once
I
do
that,
you
should
start
seeing
see
these
are
just
all
v2
now,
whereas
before
it
was
only
sometimes
v2
and
that's
pretty
much
it
so
what
you
saw
here
was
a
single
service
gateway,
kind
of
using
the
gateway
resource
to
load,
balance
traffic,
to
a
single
service
on
the
back
end
and
then
creating
a
gateway
with
a
route
that
routes
traffic
to
multiple
services
and
then
creating
a
gateway
with
multiple
different
routes.
B
So
you
can
use
one
load
balancer
to
kind
of
route,
your
traffic
in
in
multiple
different
directions,
so
pretty
cool
stuff,
and
then
we
did
traffic
splitting
too.
So
if
you
want
to
try
this
stuff
out
for
yourself,
all
you
need
is
a
kubernetes
cluster.
I
use
gke
for
this
because
I
work
at
google.
So
that's
what
I
have,
but
if
you
wanted
to
run
it
on
like
a
mini
cube
or
something
like
that,
there's
also
the
export
for
node
port.
B
If
you
need
to
use
a
node
port
type
service,
so
yeah
check
this
stuff
out
and
that's
kind
of
what
I've
got
for
you.
C
Yeah,
thanks
guys,
that's
really
cool.
It's
always
good
to
have
bleeding
edge
software
not
completely
blow
up.
C
So
yeah,
so
you
know
we're
a
sig
network
subproject
we're
basically
trying
very
hard
to
get
the
alpha
out
right
now
and
then
we're
you
know
it's
it's
going
to
be
part
of
the
stream.
The
project
homepage
is
there
all
these
will
be
available
on
in
the
slides.
C
If
you
want
to
contribute,
that's
a
community
page,
we
have
meetings
basically
weekly,
which
is
kind
of
intense
two
days
a
week,
actually
for
the
try
to
get
this
alpha
out
and
it's
going
to
be
alternating
am
time
specific,
because
we
want
to
be
inclusive
of
both
the
apac
and
the
euro
time
zones
and
there's
a
meeting
code.
So
please
check
out
the
website
check
out
the
calendar.
C
The
demo
is,
link
is
also
available
in
the
slides
and
that's
freely
available
to
you
can
just
do
whatever
you
want
with
it
yeah.
So,
thanks
for
coming,
I
think
we
can
move
to
questions.
A
Okay,
well,
thank
you
both
for
a
wonderful
presentation.
We
have
about
a
little
less
than
10
minutes
left
for
questions,
so
please
feel
free
to
drop
them
into
the
q.
A
box
looks
like
we
have
a
couple
here.
A
C
Yeah,
that's
what
we're
we're
basically
for
the
alphas
along
with
is
a
bake
off
of
different
implementations.
So
clearly,
there'll
be
some
cloud
represented
like
I'm,
going
to
represent
google
cloud
and
we'll
have
an
implementation
there,
but
also
some
of
the
other
participants
are.
C
You
know,
for
example,
contour
support,
implementers,
there's
going
to
be
other
sort
of,
and
then
you
saw
one
the
demo
actually
uses
sort
of
istio
as
the
basis.
So
this
is
there's
we
expect
actually
many
different
implementations
and
then
it
also
it
supports
both
the
cloud-based
and
the
in-cluster
proxies.
C
So
in
terms
of
flexibility,
you
should
you
should
be
able
to
use
many
different
sort
of
ways
to
get
at
the
api
implement
the
api.
The
the
whole
goal
is
to
make
it
so
that
this
experience
is
portable
across
all
of
these
different
sort
of
ways
of
doing
it,
which
is
kind
of
down
in
that
very
first
slide
in
terms
of
the
trends.
C
C
Yeah,
that's
a
good
question,
one
of
the
it's
actually
an
issue
on
the
rio.
So
there's
plenty
of
discussion
there
there's
a
couple
of
things.
One
of
them
is
we
did
spec
out
what
it
means
to
add
just
configuration
knobs
for
mtls.
So
that's
one
way
to
do.
Authentication
the
other
one
is
that
if
you
have
a
very
specific
sort
of
requirement,
there's
two
extension
points
that
can
be
used.
One
of
them
is
in
the
listener,
so
you
can
say:
okay,
I'm
listening
to
http
and
you
know
I
want
to
apply
this
special
thing.
C
That's
inserted
there
there's
another
one
on
the
filter
of
the
route
itself,
so
you
could
say,
while
you're
sort
of
matching
requests
for
this
particular
service,
you
can
add
your
authentic
sort
of
configuration
there.
Really.
We
would
like
feedback
in
terms
of
like
how
to
make
that
generic,
because
I
think
a
lot
of
the
focus
will
be
like
okay.
How
do
we
make
this
work
for
an
nginx
implementation,
an
envoy
implementation,
a
contour
implementation,
a
cloud
implementation
and
that's
where
all
the
conformance
and
the
extended
versus
the
core
comes
in?