►
From YouTube: One API To Rule Them All? What the Gateway API Means For Service Meshes - Keith Mattix & John Howard
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
One API To Rule Them All? What the Gateway API Means For Service Meshes - Keith Mattix II, Microsoft & John Howard, Google
Speakers: John Howard, Keith Mattix
The explosion of the service mesh ecosystem over the past 5 years is well-documented; cloud-native users are consistently reaching for common mesh features like advanced traffic routing and policy enforcement(authn/z, timeouts, retries, etc). Unfortunately, the innovation of various service mesh implementations has led to a sprawl in APIs and features that can make life difficult for end-users and tooling providers. In this session, you’ll learn about historical efforts to unify the service mesh space and how the new Kubernetes Gateway API may hold the key to achieving that vision.
A
We're
gonna
go
ahead
and
get
started.
Thank
you
all
for
coming
on
a
Friday
I
really
appreciate
everyone
coming
out
for
our
talk.
Our
the
title
of
our
talk
is
one
API
to
rule
them
all.
I'm
Keith,
Maddox
I'm,
a
senior
engineering
lead
for
the
open
service
math
project
at
Microsoft,
I'm.
Also
a
co-lead
of
the
gamma
initiative,
which
we'll
talk
about
soon.
B
I'm
John
Howard
I'm,
a
software
engineer
at
Google
working
on
the
Easter
project,
I'm
also
a
co-leader
on
the
gamer
project,
which
we'll
learn
about.
Excuse
me
oop
wrong
way,
all
right
before
we
get
into
it.
I
just
want
to
give
a
very,
very
brief.
I
promise
history
of
like
where
we're
coming
from,
to
give
some
more
context
on
where
we're
going.
B
So
in
the
beginning
you
know,
kubernetes
was
launched.
It
gave
us
a
conference
to
go
to
and
talk
about
things
it
had
some
service
mesh
features
that
you
know
it
has
like
Service
as
a
resource
gives
you
some
amount
of
functionality
there,
but
not
all
the
rich
functionality
that
we
want
out
of
a
service
mesh
today.
So
pretty
shortly
after
new
service
mesh
products
were
starting
to
pop
up
Linker
D2
and
East
Joe
were
some
of
the
first
ones,
bringing
things
like
HTTP
and
grbc
load,
balancing
and
routing
mtls,
Telemetry
and
tracing
it.
B
B
Do
I
want
to
do
with
a
virtual
service,
a
traffic
Route,
a
service
router,
a
service
profile,
a
virtual
router
or
many
many
other
ones
right.
So
these
are
all
real
apis
to
configure
the
same
thing
from
different
service
mesh
offerings,
and
so,
while
they
all
do
the
same
thing
or
roughly
the
same
thing,
they
all
have
different
communities.
A
Yeah
and
so
this
landscape
I'll
go
back
a
slide
just
to
really
hone
in
on
this.
This
landscape
is
a
bit
is
a
lot
to
work
with
right
when
you
are
somebody
who's
trying
to
build
software
on
top
of
service
mesh
when
you
are
trying
to
provide
tool
to
the
ecosystem.
Trying
to
make
your
way
through
this
proliferation
of
resources
is,
is
difficult
and
honestly
it
prevented
real
innovation
in
the
space
and
so
Circa
2018
or
so
the
SMI
spec
was
launched.
A
Smi
stands
for
service
mesh
interface
and
it
was
a.
The
goal
of
the
project
was
to
create
a
single
set
of
resources
of
apis
that
are
supported
by
all
service
mesh
offerings,
and
so
we
saw
a
bit
of
success
with
SMI
projects
like
Flagger
and
Argo.
Rollout
supported
the
service
mesh
interface
as
a
common
specification
for
service
mesh
implementations
to
use,
and
they
would
add
functionality
like
Canary
Canary
deployments
and
Progressive
rollouts.
A
A
b
testing
experiments
things
of
that
nature,
and
you
know
the
standard
looks
something
like
this:
these
are
both
SMI
resources.
You've
got
your
HTTP
route
group
that
has
matches
a
http
header
for
some.
You
know
a
user
agent
containing
Firefox
somewhere
and
then
you've
got
that
HTTP
route
referenced
in
a
traffic
split
resource
and
in
this
example,
specifically
there's
no
traffic
going
to
a
website.
A
V1
all
the
traffic
goes
to
website
V2,
but,
as
you
can
see,
that's
configurable
and
it
matches
the
route
group
that
we
refer
to
earlier
and
so
SMI
provided
this
a
single
interface
for
this
kind
of
functionality
across
meshes,
and
we
saw
it
take
off.
There
are
at
Linker
DM
and
implements
a
couple
of
SMI
resources.
Open
service
mesh.
The
mesh
I
work
on
implements
a
lot
of
the
SMI
spec
and
things
were
pretty
good,
but
over
time
we
started
to
see
some
some
cracks
in
the
foundation
SMI
because
of
where
it
started.
A
It
made
some
design
decisions
and
its
specifications
that
were
incongruent
with
where
the
community
decided
to
go.
Overall.
When
it
comes
to
routing
resources,
we
The
Binding
authorization
policy
was
very
route
and
service
account
focused.
There
was
no
space
to
insert
like
workload
selectors
or
things
of
that
nature.
There
was
no
concept
of
a
workload
in
General
within
the
SMI
spec.
A
The
open,
Telemetry
love
the
work
that
that
project's
doing
they've
got
a
lot
of
exciting
news
that
we
learned
about
here
during
this
conference.
But
you
know
the
we
already
had
one
direction.
We
were
going
up,
it's
Elementary
went
a
different
direction,
and
so
there
was
some
friction
in
the
community.
A
At
that
point,
we've
got
some
key
maintainers
move
on
to
some
other
projects
and
we
struggled
to
kind
of
gain
more
widespread
adoption
and
usage
and
patterns
to
move
resources
from
alpha
to
Beta
and
kind
of
fast
forwarding
now
doing
a
bit
of
a
Time
skip
to
present
day
we're
kind
of
evaluating
the
future
of
the
SMI
specs.
So
if
you
use
SMI,
if
you've
got
opinions,
come
talk
to
me.
Let
me
know
I
love
to
get
some
feedback
from
the
community.
There.
B
So
if
you
know,
we've
talked
all
about
service
mesh
here,
but
if
you
look
over
into
the
Ingress
world
of
kubernetes,
we
kind
of
saw
the
same
thing
happening
so
from
the
beginning.
Kubernetes
had
this
Ingress
resource
to
describe
how
to
get
traffic
into
your
cluster
right
and
they
started
out
with
one
unified
API
that
would
be
implemented
by
a
lot
of
different
vendors
and
there
are
tons
of
vendors
that
implement
this
API.
B
But
the
problem
was
that
it
was
so
simple
that
it
really
had
this
lowest
common
denominator,
feel
to
it,
and
there
wasn't
really
points
to
extend
the
API
for
adding
vendor
specific
things.
So
what
started
to
happen
was
implementations
would
add.
All
sorts
of
annotations,
I
think
I
saw.
Nginx
is
like
over
100
different
annotations.
B
You
can
add
to
customize
things,
or
they
would
just
make
their
own
completely
different,
apis
like
in
istio,
that
is
the
Gateway,
which
is
confusing
the
overlapping,
a
name
but
there's
many
other
ones
as
well,
and
so
we
saw
kind
of
you
know.
Over
and
over
again
we
saw
the
same
pattern
like
there's,
not
extensions,
it's
not
portable.
We
have
all
this
kind
of
mess
in
the
ecosystem,
so
that's
where
the
Gateway
API
comes
in
right.
This
is
kind
of
a
new
ish
I
guess
it's
actually
been
around
kind
of
a
while.
B
B
That's
learned
from
the
stakes
of
both
the
Ingress
API,
as
well
as
all
the
other
vendor
apis
that
have
been
around
for
the
past
few
years
and
kind
of
learned
how
users
want
to
configure
things.
You
know
what
the
right
way
to
arrange
resources
is
how
to
correctly
like
give
those
to
different
roles.
All
sorts
of
things
like
that
and
one
of
the
key
parts
of
it
as
well,
is
that
it's
extensible.
B
So
while
a
common
core
will
be
there
in
the
API,
there's
always
going
to
be
some
obscure
vendor
thing
that
they
want
to
add
to
these
apis
right.
So
extensibility
is
built
into
the
core
to
try
and
ensure
that
we
don't
get
that
same.
You
know:
proliferation
of
annotations
people
forking
off
new
resources.
That
sort
of
thing,
so
this
API
has
been
really
successful.
It
recently
graduated
beta
there's
over
15
implementations.
B
So,
just
a
brief
overview,
there's
actually
some
deep
dives
from
other
talks
that
you
can
go
through
this
week.
If
you
want
to
learn
more
and
I
have
a
bunch
of
links
at
the
end,
but
just
an
overview
of
the
Gateway
API
rather
than
a
single
resource
like
Ingress,
it's
been
split
up
into
many
different
resources
to
give
kind
of
a
role-oriented
resource
model
so
that
different
roles
can
configure
different
resources
and
they
can
be
segmented
with
our
back
Etc
right.
B
So
the
core
resource
really
is
Gateway,
which
is
like
the
entry
point
to
your
cluster.
That
typically
would
actually
go
provision,
a
real
load,
balancer
or
a
real
pod
that
actually
implements
you
know
the
the
proxying
and
then
application
developers
can
add
HTTP
routes
and
there's
also
TCP
routes,
TLS
routes,
UDP
routes
and
even
now,
grpc
routes
to
kind
of
go,
add
routes
to
this
load,
balancer
right
and
you
can
see.
In
this
example,
we
have
two
different
application
developers
living
in
two
different
name:
spaces
that
are
both
configuring:
the
shared
Gateway
resource.
A
These
two
initiatives-
you
know
between
Gateway,
API
and
SMI
kind
of
happened
around
the
same
time
and
it
was
a
bunch
of
you
know
a
bunch
of
people
coming
together
and
trying
to
solve
the
same
problems,
and
you
know,
as
an
SMI
maintainer
I
became
aware
of
what
was
happening
over
in
Gateway
API
award
for
Ingress,
and
you
know
a
thought
occurred
to
me.
You
know
why
need
the?
Why
does
you
know
service
Mesh
networking
need
to
be.
A
You
know,
standardized
in
a
separate
workflow
from
Ingress
networking,
and
so
I
said
this
is
a
excerpt
from
an
email
I
sent
to
a
lot
of
my
very
talented
colleagues
in
the
service
mesh
Community
and
I'll.
Read
it
here.
The
features
present
in
the
spec,
referring
to
Gateway
API,
are
by
no
means
specific
to
Ingress
traffic.
In
fact,
just
about
every
project
represented
here
in
the
email
thread
exposes
near
identical
functionality
to
their
users.
A
Around
I
want
to
say
yeah
around
early
to
mid-july.
These
two
blog
posts
were
author
simultaneously
one
from
the
SMI
Blog,
the
other
from
the
istio
blog
announcing
a
new
collaboration
between
members
of
the
SMI
community
and
istio,
as
well
as
other
service
meshes
throughout
the
ecosystem,
to
form
something
called
the
gamma
initiative.
Yes,
it
does
sound
like
an
Avengers
team,
I'm,
a
big
Marvel
nerd,
if
you
can't
tell
already-
and
so
the
naming
was
somewhat
accidental,
wink
wink.
B
Yeah,
so
the
gamma
initiative,
which
is
a
long
acronym
that
was
forced
in
to
for
a
Gateway
API
for
mesh
management
and
Administration
very
fancy,
was,
like
we
said,
was
a
you
know,
kind
of
initiative
to
bring
all
the
benefits
that
Gateway
API
has
started
to
succeed
at
in
the
Ingress
space,
but
to
service
mesh
right.
So
it's
actually
a
very
fancy
name
and
everything
for
quite
a
simple
concept
like
how
do
we
apply
these
same
lessons?
We've
learned
in
apis,
but
for
the
mesh
World.
B
So
this
is
not
you
know
a
new
project
or
product
or
anything.
This
is
more
like
just
a
group
of
people
that
have
meeting
every
week
and
talk
about
mesh
and
Gateway.
So
yeah,
like
I,
said.
Our
goal
is
to
have
this
unified
API,
not
just
across
the
vendors
of
meshes,
but
also
between
Ingress
and
mesh
right.
So
if
you
want
to
do
a
canary
rollout,
for
example,
you
might
want
to
apply
that
for
external
traffic
and
also
the
same
for
internal
traffic
without
a
unified
API
between
those
two.
B
You
need
to
go,
learn
two
different
apis
to
solve
the
exact
same
problem.
It
doesn't
sound
great
to
me,
so
you
know
we've
been
meeting
ever
since
July.
We
have
weekly
meetings
if
you
want
to
get
involved,
I
have
a
bunch
of
resources
at
the
end,
and
you
know,
since
we
started
we've
gotten,
a
huge
number
of
different
service
meshes
on
board.
These
are
all
the
people
I
saw.
You
know
coming
into
the
meetings
sharing
these
ideas
interested
in
implementing
this.
B
So
you
know,
if
you
look
at
this,
this
is
not
a
group
of
people.
You
typically
see
all
agreeing
on
one
thing:
I
was
a
bit
surprised
myself,
but
it's
true
it's
happening
so
you
know
really.
The
full
ecosystem
is
starting
to
collapse
around
the
Gateway
API,
both
in
the
service
mesh
and
in
the
Ingress
ecosystem.
So
this
is
really
powerful
right.
B
This
15
seconds
ago
was
now
probably
15
minutes
ago,
but
we
have
just
recently
emerged
kind
of
the
first
big
milestone
for
the
project,
which
is,
if
you
recall,
I,
showed
an
HTTP
route
example,
which
is
like
matching
and
routing
HTTP
traffic.
We
just
added
support
for
really
defining
how
that
works
in
a
service
mesh
right.
B
That's
kind
of
the
base
foundation
for
the
project
so
that
we
now
have
a
common
language.
That's
used
across
all
the
implementations
and
I'll
get
more
into
what
is
coming
next.
So
here's
just
an
example
of
what
this
may
look
like
for
a
very
simple
traffic
split
between
two
different
Services.
So,
as
you
can
see
before
we
were
attaching,
we
had
this
parent
ref
resource
attaching
to
a
gateway
for
a
mesh.
B
C
B
Actually,
let
me
keep
going
so
one
thing,
I
want
to
say:
we've
talked
a
lot
about
okay
uniformity
between
the
vendors
and
something
I
get
asked
a
lot.
Is
you
know,
IU
service,
mesh,
X,
I,
don't
care
about
service
mesh?
Why
right?
Why
do
I
care
that
they
have
the
same
API
I'm,
not
going
to
run
them
both
at
once
right
and
I
get
it?
That's
actually,
you
know
fairly
valid
point,
but
one
thing
that
I
think
has
missed
a
lot
is
the
value
of
having
one
ecosystem
right.
B
So,
even
if
you
only
use
one
mesh,
it's
still
valuable
that
the
other
meshes
are
doing.
The
same
thing
right
I
saw
a
talk
earlier
on
Flagger,
which
automates
Canary
rollouts
right
and
I
looked
at
their
docs.
They
had
a
page
of
like
the
15
different
vendors.
They
Implement.
They
had
15
different
apis,
15
different
code
bases
for
this,
like
it's
a
huge
mess
for
them
to
maintain
right
with
something
like
the
Gateway
API
that
can
be
dropped
down
to
just
one
API
that
they
Implement
right.
B
There's
one
ecosystem:
there's
one
set
of
documentations
for
how
Gateway
API
Works,
rather
than
15
different
meshes,
trying
to
make
their
own
documentation.
There's
one
set
of
tests.
You
know
people
will
post
tutorials
what
not
on
YouTube
those
will
all
be
Gateway
API
and
it's
much
of
the
same
reason
why
kubernetes
itself
has
been
so
successful
right
as
this
common
set
of
apis
across
Cloud
vendors
Etc.
B
A
Good
yeah-
and
you
know
hopping
on
top
of
that
I
I-
think
it's
important
to
call
out
that
this
was
done
in
you
know.
Our
first
meeting
was
in
July.
It's
now
October.
If
you
do
some
quick
math,
you
know
that's
about
three
months
and
you
know
we've
been
meeting
weekly.
These
may
not
look
like
a
lot
for
three
months,
but
there
if
you've
got
links
on
the
end
linking
to
our
to
our
minutes
from
our
agenda,
and
there
has
been
a
lot
of
conversation.
A
That's
driving
these
changes
a
lot
of
consideration
of
different
methods.
We
went
through
like
eight
or
nine
different
approaches.
By
the
time
we
got
to
the
end
of
everything,
to
figure
out,
what's
going
to
be
best
for,
for
you
what's
gonna
be
best
for
the
user
users
in
the
ecosystem
for
mesh
implementers
for
end
users,
what
can
be
the
most
natural
set
of
apis,
and
so
a
lot
of
back
and
forth
is
done
both
on
a
technical
Merit
perspective,
as
well
as
a
user
experience.
A
A
A
Right
now,
if
you
want
to,
there
are
some
proposals
that
we
are
going
to
be
adding
to
that
to
clarify
some
language
in
some
edge
cases,
but
what's
next
on
the
frontier,
for
you
know
for
the
gamma
initiative,
one
of
the
big
things
that
we're
talking
about
right
now
is
authorization
policy
right
now
again
similar
to
routing
just
about
every
single
service.
Mesh
has
its
own
off
Z
mechanism
with
HT.
You've
got
authorization
policy.
Osm
you've
got
a
traffic
Target
blanking
on
some
of
the
other
meshes
yeah.
What
console
has
intentions
there?
A
A
When
you
talk
about
getting
traffic
in
and
out
of
a
cluster
traffic
going
between
different
Services,
how
do
I
limit
the
number
of,
not
just
a
number
of
but
the
specific
destinations,
that
a
service
or
a
Gateway
is
allowed
to
to
send
traffic
to
we've
kind
of
deferred
that
in
our
initial
set
of
Standards?
But
it's
getting
to
a
point
where
we're
starting
to
really
re-examine
at
what
stage
we
need
to.
We
need
to
tackle
this
policy.
Attachment
has
been
a
huge.
A
You
know,
conversation
for
us
as
well,
for
those
of
you
who
might
not
know
the
Gateway
API
actually
has
a
first
like
a
first
class
idea
of
attaching
policy
to
a
route
to
any
number
I
think
it's
like
seven
different
layers
of
abstraction
throughout
the
API
and
it's
kind
of
a
bit
of
Uncharted
Territory.
There
haven't
been
a
ton
of
examples
of
it
in
the
wild.
If
I
had
to
explain
it
briefly,
the
idea
of
Gateway
API
policy
attachment
is
it's
got
a
set
of
you
know
any
crd.
A
A
It
plays
really
well
with
this
model,
with
Gateway
API
with
one
of
the
big
Ideas
behind
Gateway
API
is
Persona
based
development,
and
so
your
application
developers
don't
need
your
cluster
operator
permissions
policy
attachment.
Does
that
same
thing,
if
I,
as
a
application
developer,
want
to
set
a
timeout
policy
for
my
service,
I
should
be
able
to
do
that
without
having
to
use
cluster
operator
permissions
and
put
that
right
in
my
namespace
that
I
own,
and
so
that
contract
exists
already
for
Gateway
API.
How
do
you
bring
that
into
mesh?
A
How
do
you
bring
that
same
Persona
based
development
into
the
mesh
world
and
we're
having
conversations
about
that
different
kinds
of
policies
you
can?
You
can
think
about
us
adding
here,
I
mentioned
authorization
policy
is
one.
It's
kind
of
weird,
so
it's
a
little
bit
different
from
some
of
the
other
ones
you
might
think
of.
A
So
that
might
be
it's
a
special
case,
but
rate
limiting
circuit
breaking
all
these
service
mesh
features
that
you've
come
to
know
and
to
love
and
to
rely
on
if
you're,
a
business,
critical
applications,
we
want
to
bring
those
and
standardize
them
and
make
them
simpler.
Maybe
that's
through
a
set
of
generic
patterns,
maybe
that's
through
a
collection
of
resources.
At
some
point
we
don't
know
yet.
You
know
we
take
a
very
iterative
approach
to
this
to
our
development
cycles
and
one
of
the
other
really
awesome
things
about
Gateway
API.
A
A
We
got
our
resources,
this
resource
out
here
in
three
months,
we're
able
to
do
that
with
a
relatively
High
degree
of
confidence,
because
we
know
we
can
Market
as
experimental
and
so
we're
going
to
continue
to
kind
of
move
in
a
relatively
quick
Pace
to
try
to
get
these
things
out
there,
and
we
want
you
anybody
who's,
implementing
a
mesh
anybody
who's
using
a
mesh
to
get
your
eyes
on
these
things
and
use
them
and
to
give
us
feedback.
So
we
can
create
a
better,
a
better
spec.
A
A
A
Like
we
mentioned
before,
we
have
weekly
meetings
and
we
actually
do
something
a
little
interesting
with
our
meetings.
We
alternate
them
on
WE,
alternate
time
slots,
so
I
think
the
meeting
that
was
supposed
to
be
this
week
that
we
canceled
for
kubecon.
It
was
going
to
be
at
8
A.M
Pacific
time.
But
then
next
week's
meeting
will
be
at
3
P.M
Pacific
time,
and
this
is
just
to
try
to
be
as
inclusive
of
other
times
as
possible.
A
D
So,
on
your
slide
that
showed
all
the
mesh
people
that
were
participating,
you,
you
said
you
pulled
a
Marvel
move,
I
believe
Avengers
move
or
whatever.
What
actually
is
the
backstory
because
I'm
just
did
it
really
just
happen
that
easily,
or
was
there
a
little
more
back
and
forth
to
get
people
engaged.
B
B
It
was
really
the
only
one
interested
in
that,
and
so
I
really
wanted
to
go
start
doing
this
right
off
the
bat,
but
I
was
worried
about
having
only
one
vendor
behind
it
and
that
we
would
just
accidentally
make
it
a
new
Easter
API
that
no
one
else
adopted
right.
So
we
really
were
trying
to
get
people
actually.
Last
year,
I
was
just
going
around
to
everyone's
like
how
do
you
feel
about
Gateway
for
mesh?
How
do
you
feel
about
Gateway
for
mesh
right
and
trying
to
get
people
on
board?
B
So
it
was
a
long
process.
You
know,
eventually
different
vendors
have
different
reasons
for
why
they're
adopting
it
right,
some
of
them
may
just
see
like.
Oh
everyone
else
is
doing.
Let's
go
for
it.
Linker
D
had
a
great
blog
post
about
why
that's
not
what
they
care
about.
They
don't
care
that
everyone
else
is
doing
it,
they
just
really
like
the
API
and
it
solve
the
real
problems
for
them
right.
A
B
C
A
All
those
have
different
data
planes,
and
you
know
one
of
the
criteria
for
introducing
apis
is
like
we
try
as
hard
as
we
can
to
to
make
it
work
for
both
of
them.
If
it
can't
there
is
a
custom
conformance
level
that
exists
in
Gateway
API
for
cloud
for
data
plane,
specific
implementations
to
host
their
policies
host
their
implementation.
Things
like
that,
so
we
hope
that
we
don't
have
to
make
that
decision.
We
hope
we
create.
A
E
Hi
because
I
think
maybe
just
related
to
the
previous
question.
Yeah,
do
you
see
the
Gateway
API?
As
you
know,
if
I'm,
if
my
application
is
going
to
use
service
mesh,
that
I
am
going
to
be
deploying
my
application
solely
with
Gateway
crds,
or
do
you
envision
it
as
well?
Probably
80
percent
will
be
these
Gateway
core,
crds
and
20
will
still
be
vendor
specific
configuration.
C
B
So
that's
a
great
question,
so
you
know
a
core:
API
cannot
possibly
have
all
the
functionality
that
all
these
different
service
meshes
offers
right.
That
just
doesn't
work
so
like
I
said,
extensibility
is
really
the
name
of
the
game,
we're
hoping
that
most
of
the
core
use
cases
can
be
defined
in
the
core
apis
and
the
more
specific
use
cases
are
kind
of
in
the
extensions
right.
So
if
you're
just
getting
started,
it's
probably
good
enough
to
just
use
the
core
apis.
B
Once
you
start
getting
to
more
and
more
bespoke
requirements,
you
may
start
needing
to
leverage
those
vendor
extensions
over
time.
Some
more
may
move
into
course.
That
may
become
less
and
less
right.
Now,
there's
not
a
whole
lot
in
there
right,
there's
just
routing.
So
if,
as
soon
as
you
want
to
do
some
like
authorization
policy,
you'll
need
to
reach
to
a
vendor
extension
in
the
future.
We
hope
that
gets
less
and
less.
F
A
Yes,
so
that's
kind
of
the
whole
reason
we
started
investigating
this
work
stream
Gateway,
you
know
initially
was
focused
towards
Ingress,
but
from
the
earliest
days
talking
to
Rob
and
Shane
and
Nick,
and
some
of
those
early
maintainers.
It
was
always
kind
of
designed,
so
that
mesh
could
work.
If
somebody
was
willing
to
investigate
it.
A
Their
naming
is
very
hard
as
I'm
sure
many
of
us
in
the
room
know,
and
the
Gateway
API
actually
had
a
previous
name
before
that.
That
was
more
generic,
but
that
caused
some
confusion.
And
so
you
know,
despite
the
name
Gateway,
we
really
do
see
the
specification
itself
as
being
useful
and
applicable
to
both
north
south
and
East-West
traffic
yeah.
F
The
reason
mainly
here
is
like
it's:
it's
between
complexity
and
making
it
simple
the
difference
between
having
everything
you
know
being
handled
by.
Let's
say:
Envoy
right,
you
know
East
West
or
not
South,
Ingress,
egress
and
internally,
but
then
you
want
to
simplify
that
and
make
it
into
a
core
kubernetes
API.
You
know
we.
We
are
trying
to
sort
that
out.
F
A
Okay,
so
Vision
yeah,
so
for
me,
I
think
somewhere
else.
I
heard
another
question
to
him
heard
of
this,
but
for
I
personally
believe
that
ServiceMaster
will
always
be.
The
implementation
will
always
be
separate
from
kubernetes.
Our
vision
is,
at
least
for
me,
a
set
of
apis
and
kubernetes
to
describe
traffic.
A
Those
you
know
Gateway
API
is
it
exists
as
a
crd,
but
it's
within
the
kubernetes
organization,
which
actually
helps
a
lot
with
acceleration,
velocity
and
productivity.
You
don't
have
to
go
through
the
lengthy
kept
process,
but
you
know
if
there
is
a
single
set
of
apis
in
kubernetes
for
routing
traffic
period.
Why
shouldn't
your
service,
mesh
implementation,
understand
that
and
and
that's
the
vision
for
us
for
a
new
person
who
wants
to
use
kubernetes,
they
can
use.
You
know,
10
years
in
the
future.
A
Gateway
API
will
be
the
de
facto
thing
that
they're
seeing
on
tutorials
that
they're
learning
and
then,
when
it
comes
time
for
their
organization,
to
adopt
a
mesh
for
regulation
for
ntls
or
for
more
powerful
extensions
for
Canary
and
things
of
that
nature.
They
can
use
those
same
apis
that
they
essentially
grew
up
with.
In
kubernetes
and
use
that
for
their
service
mesh,
no
new
overhead
to
go
and
learn
a
whole
new
set
of
apis
just
for
the
base
level
of
functionality.