►
From YouTube: Evolving the Kubernetes Ingress APIs to GA and Beyond - Christopher M Luciano, IBM & Bowei Du
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Evolving the Kubernetes Ingress APIs to GA and Beyond - Christopher M Luciano, IBM & Bowei Du, Google
The Ingress API has existed as beta type since early 2016 release in Kubernetes 1.2. Since its inception, it has been fairly lightweight and additions remained infrequent in attempts to maintain portability within the Kubernetes ecosystem. In response, Ingress API implementations commonly leverage a different internal API or extend the Ingress API by heavily decorating the resource with annotations. In this session, we will present the Ingress enhancements for the GA/v1 Ingress API and what factors went into these decisions. Furthermore, we'll explore several possible directions for what a v2 API could entail and walk through several examples including existing non-Kubernetes implementations.
https://sched.co/UaYG
A
A
What
the
current
state
is
and
what
changes
we
are
making
towards
bringing
it
to
beta
and
then
the
second
part
of
the
talk
is
how
we're
evolving
into
the
next
set
of
api's,
and
this
is
still
an
ongoing
process,
so
we're
gonna
talk
generally
about
the
goals
and
then
kind
of
some
interesting
aspects
of
API
design.
Actually,
that
would
be
relevant
for
other
resources
that
we
are
seeing
as
part
of
designing
this
API.
So
Chris
thanks.
B
So
currently
ingress
exists
as
like
a
big
bundle
of
kubernetes
service
back
in
mappings
and
rules
and
then
related
TOS
config,
and
this
has
been
pretty
good
for
the
short
term.
You
know
it
ensures
a
lot
of
flexibility
for
people
and
the
majority
of
people.
According
to
the
survey
that
we
did
last
year,
a
lot
of
people
are
using
it
successfully
with
the
myriad
of
controllers.
B
It's
been
there
for
release
after
release
and
it's
always
remained
in
beta.
In
fact,
until
a
few
releases
ago,
it
was
still
in
the
extensions
API.
So
one
of
the
first
things
we
did
was
remove
that
out
of
there
into
its
own
API,
and
now
we
want
to
add
in
what
we
think
will
complete
it
to
bring
it
to
GA.
Before
we
talk
about
a
lot
of
the
big
things
that
we
want
to
do,
evolution
and
v2
stuff.
B
The
first
thing
we're
gonna
do
is
just
a
simple
rename
from
back-end
to
default
back
end.
It
was
unfortunately
named
backends,
but
in
the
comments
it
really
imply
to
us
that
you
fought
back
in
nobody
read
the
comments
bottom
wonder
of
if
I
set
my
ingress
such
that
nginx
should
be
handling
this
one
and
I
wanted
neither
worked
what
would
happen
to
it.
B
So
in
this
example,
this
is
a
rename
we'll
make
that
a
lot
more
clear
where
that's
going
to
go
so
I
already
had
this
open
PR
for
it,
but
we're
going
to
be
combining
a
lot
of
like
the
whole
API
into
one.
So
you
can
take
a
look
at
it,
but
this
is
kind
of
like
the
smallest
change
of
making
the
next
big
one
comes
from
path
based
prefixes,
especially
what
we've
done
is.
B
It
was
just
like
a
string
that
was
placed
in
your
path
thing
affected
from
the
comments
that
this
would
be
a
regular
expression
following
standard
posted
above.
In
reality,
none
of
the
ingress
providers
actually
took
that
and
ran
with
it.
They
either
had
an
implementation
that
expected
things
in
re2
format
from
Google
or
other
different
POSIX
standards.
We
could
take
a
look
at
that
ingress,
nginx,
wife,
a
five
issue
or
out
of
a
comparison
of
all
of
the
different
things,
how
people
treated
them.
B
B
B
So
to
accomplish
this,
we're
we're
moving
forward
with
a
path
type
gonna,
be
three
different
path
types.
The
defaults
gonna
be
implement
implementation
specific,
which
is
the
way
it
is
today.
So,
however,
your
current
ingress
controller
is
treating
this
string
and
that
I
concede
you
to
happen
and
the
other
options
that
we're
adding
in
is
one
of
an
exact
type
and
then
a
prefix
match
type.
That's
gonna
go
in
this
path.
Type
field
here,
I
have
a
couple
of
examples.
To
make
this
a
little
more
clear,
so
exact
is
exactly
exact.
C
B
All
right
can
everybody
hear
me:
okay,
let's
work,
okay,
great,
excellent,
okay,
so
exact
is
exactly
exact,
so
ABC
matches,
ABC
ABC
does
not
match
CBA,
pretty
obvious,
where
we
have
a
little
bit
more
flexibility
in
the
trailing.
Slash
is
when
it
comes
to
the
prefix
matching.
So
in
here
you
know
we're
allowing
a
path
in
your
ingress
to
be
the
forward,
slash
and
then
whatever
path
is
requested.
After
that
by
our
user
is
going
to
match
same
thing
happens
with
ignoring
the
trailing
slash.
B
Abc
is
still
going
to
match,
request
path
that
you
have
been
there
for
ABC
v4,
slash
where
it
doesn't
work
is
going
to
be
the
final
example
there,
where
a
four
slash
is
not
separating
that
BB
and
ZZ,
but
we
do
include
the
sub
path
matching,
so
a
BB
one
specified
and
requested
of
the
finals.
You
see
that's
going
to
match.
B
The
next
big
thing
that's
come
up
and
you'll
find
in
almost
any
of
the
annotations
is
the
host
name
while
parting.
This
isn't
going
to
be
a
similar
matching
schema
as
before,
and
what
we're
looking
at
here
is
wildcards
on
the
first
dns
label
there,
so
anything
separated
by
the
dot
there.
So
just
a
couple
examples
on
this
one,
the
first
part
we're
matching
foo
and
bar
in
this
case
the
wildcard
matches
that
first
set
of
labels
we're
good.
Second
one
does
not,
because
we
have
before
our
foo
in
this
match.
We
have
a
label.
B
B
The
next
one
is
another
thing
that
is
existed
in
imitation
for
a
while,
it's
the
ingress
class.
This
is
basically
allowing
you
to
plumb
through
special
options.
For
your
ingress
controller,
one
example
that
comes
up
is
having
different
tiers.
If
you're
a
cloud
provider
like
having
your
bronze
level
or
your
silver
level
and
passing
different
options,
maybe
even
you
deploy
the
nginx
ingress
control
over
your
bronze
or
the
cloud
provider
specific
wand.
That's
got
you
know
global
load,
balancing
options
for
your
your
higher
tier.
B
B
A
lot
is
how
do
we
open
that
up-
and
this
has
come
up
in
some
of
the
discussions
you
see
in
maybe
around
v2
people
want
to
be
sure
that
if
I
don't
have
something,
that's
represented
one
to
one
with
a
kubernetes
type,
that
we
don't
break
that,
but
we
still
want
to
allow
just
a
bit
more
flexibility,
though
with
validation.
So
this
is
what
the
API
is
going
to
look
like.
Well,
this
is
the
sketch
of
it.
B
For
now,
as
you
see,
we
preserve
the
service
type
up
here
in
the
top
under
service
and
that's
going
to
be
a
regular
kubernetes
service,
and
this
is
a
must
case.
So
implementers
must
support
kubernetes
services
if
they
want
to
provide
anything
after
that.
That's
where
this
resource
example
comes
in
here,
and
one
of
the
big
things
that
comes
up
quite
a
lot
is:
how
do
I
express
something
like
direct
this
to
a
storage
bucket?
B
So
for
I
think
example,
this
is
the
second
example
here,
and
the
custom
resource
is
not
like
a
working
example,
but
we
envision
you
being
able
to
plug
this
in
through
a
sort
of
CRD
like
interface,
so
in
the
second
custom
resource
implement
right.
There
reason
the
API
group,
reflecting
your
CRD
version,
the
kind
for
according
to
your
CRD
standards
and
a
name
for
it,
something
really
simple,
but
still
preserving
that
thing
that
you
used
to
on
the
left-
and
this
is
the
default,
will
you
be
able
to
combine
these
both
together?
B
As
far
as
the
timeline
for
these
things,
we
were
trying
to
be
pretty
aggressive
about
this
in
the
beginning,
just
to
really
get
the
things
out
there.
Unfortunately,
we
didn't
want
to
kind
of
half-baked
things
like
put
in
back
in
types
and
the
rename
to
go
into
1:17
and
then
the
rest
to
go
into
1:18.
Would
that
feature
gated
or
something,
and
it
kind
of
makes
a
scope
creep
a
little
more
difficult?
B
Well,
we
have
done
so
far
is
in
114.
We
moved
everything
out
from
under
the
extensions
repository
into
the
networking
kto.
So
when
you
create
ingress
now
you
should
be
using
that
new
API,
it's
the
same
API
that
we
have
like
Network
policy
is
under
for
a
while
now,
and
we
made
that
mailing
list
announcement.
That
extensions
is
going
to
be
deprecated
1:15.
We
work
to
get
all
of
the
documentation,
examples
and
code
for
ingress
controllers
that
are
currently
under
the
kubernetes
org,
which
includes
ingress,
nginx
and
ingress
GCE.
B
The
GCE
release
for
that
controller
that
incorporates
the
use
of
this
new
API
or
right
there.
One
bus,
700,
ingress
nginx,
was
utilizing
these
new
things
and
v025.
There
one
thing
to
know
is
that
alejandro
was
very
specific,
that
we're
not
disallowing
you
from
using
the
extensions
for
a
few
releases.
So
if
you're
using
something
that
wasn't
114
when
he
released
this,
you
can
still
use
the
extensions
things
before
that.
B
Then
we
have
a
big
jump
to
a
release
that
hasn't
even
started
yet
because
you
said
we're
working
through
the
details
on
how
quickly
we
want
to
start
merging
the
stuff
in
so
we're
expecting
that
giant.
Pr
from
my
personal
repository
will
be
upstream
early.
Next
release
wrap
scott
from
google
bowie
and
myself
have
been
working
on
those
fact
changes
so
expected
those
are
going
to
1:18.
B
Then
a
similar
process
to
the
beta
api's
will
update
all
of
the
implementations
doing
this
in
our
kubernetes,
like
laying
119
and
then
shut
off
writing
to
the
extensions
thing
which,
as
we
mentioned,
was
deprecated
in
1:14
such
as
that
you
can't
like
write
to
it,
then
just
because
we
want
to
leave
it
open.
As
far
as
how
quickly
will
deprecated
ingress
from
the
beta
api's,
I
put
on
one
layer
1.2
to
be
specified
now
to
talk
about
the
future.
B
A
Thing
about
the
path
since
we
have
a
large
user
base
here
is
that
it's
definitely
the
case
that
you
will
need
to
get
off
of
the
extensions
API.
So
that's
the
API
group,
extensions,
/b,
1,
beta
1
and
transition
to
networking
and
then,
when
the
GA
API
comes
out,
we're
going
to
also
have
to
do
that
transition
so
that
that
thing
you
will
have
to
rewrite
in
your
external
configuration.
So
just
be
aware
of
that,
although
there
will
be
many
releases
where
they
will
interoperate.
A
So
in
terms
of
the
designing
a
new
API
for
the
l4
l7
space,
there
are
a
couple
of
considerations
and
we
kind
of
have
to
look
at
the
evolving
landscape
of
how
all
of
these
proxy
and
load
balancing
providers
that's
been
going
on
in
the
past
few
years.
So
here
I
have
diagrammatically
sort
of
like
a
classification,
a
rough
classification
of
various
providers.
There's
the
cloud
elby's,
which
is
you
know,
google
amazon
as
your
and
so
forth.
A
There's
the
middle
proxy
providers,
which
are
these
are
off-the-shelf
software,
such
as
ninja,
Nexon,
voyage,
a
proxy
and
then
finally,
on
the
top
we
have
transparent
proxies.
So
this
is
some
sidecar
based,
proxying
or
maybe
even
q,
proxy
and
in
terms
of,
if
you
look
at
how
the
early
kubernetes
cluster
and
the
sort
of
the
user
population
that
it
was
targeting,
these
early
resource
designs
were
self
sort
of
self
service
oriented.
A
So
you
had
an
empowered
developer
who
could
self-service
the
clusters
were
a
few
tenants,
and
you
know
the
Empowered
dev
would
own
the
whole
deployment.
They
would
define
the
application,
they
would
define
the
service
they
would
expose
on
the
internet.
Now,
when
we
look
at
the
use,
cases
of
kubernetes
has
become
much
more
diverse
and
in
fact
the
clusters
have
become
a
lot
bigger.
We
have
multiple
teams
roles
in
interactions
and
potentially
multiple
coexisting
implementations,
so
the
goals
for
the
evolution.
A
As
we
see
it
are
these
three
things
so
better
model,
the
personas
and
roles
involved
with
services
and
load-balancing
capture.
Some
of
the
complexity
that
we're
seeing
in
these
multi
tenant
clusters
support
modern
load,
balancing
features
while
maintaining
portability.
So
this
was
like
when
we
set
out
the
ingress
survey
in
2018,
we
got
back
to
contradictory
sort
of
responses.
One
of
them
was
that
we
wanted
to
be
portable.
The
other
one
was
that
I.
Don't
hide
me
from
my
features:
I
really
want
to
use
these
features
so
portability
or
maybe
in
the
brackets
predictability.
A
Can
the
user
predictably
use
something
and
know
when
it's
portable
and
when
it's
not
and
then?
Finally,
as
this
is
like
a
pretty
mature
space
and
in
terms
of
some
of
the
technologies,
have
standard
mechanisms
for
extension,
because
we
know
that
the
initial
API
that
we're
going
to
be
putting
into
kubernetes
probably
won't
be
addressing
all
of
the
different
use
cases.
How
do
you
grow
the
API
or
baby,
maybe
even
extended,
because
kubernetes
will
never
go
in
some
direction,
but
still
give
the
user
some
way
of
using
that
feature
so
the
status?
A
A
So
the
proposal
is
in
the
API
is
in
a
proposal
stage,
so
many
things
can
change
and
for
this
presentation,
I'm
going
to
describe
how
the
goals
map
to
API
design
and
then
give
a
sense
of
the
overall
object
model
on
how
it
works,
at
least
how
we
see
it
right
now
and
highlight
some
interesting
problems
and
approaches,
and
there
of
course,
are
many
open
questions.
So
here
are
the
goals
for
evolution
from
before,
and
then
here's
how
we
see
it
map
to
concrete
sort
of
aspects
of
kubernetes,
API
design.
A
So
when
we
were
talking
about
modeling,
personas
and
roles,
what
that
really
boils
down
to
is
how
do
you
split
up
the
resource
model
and
then,
in
terms
of
roles?
How
does
this
map
to
kubernetes
are
back?
The
second
piece
is
to
support
portability
and
predictability.
Now
we
are
talking
about
perhaps
defining
levels
of
support,
specification
and
conformance
for
the
various
implementers
out
there
and
then.
Finally,
the
last
one
is
again
a
resource,
modeling
issue
and
then
sort
of.
A
Maybe
we
can
use
something
like
polymorphism
to
sort
of
get
the
flexibility
we
want
so
going
into
a
little
bit
more
about
personas
and
roles.
So,
as
I
said
before
before
we
had
just
the
empowered
developer,
who
is
self-serving
everything,
but
what
we're
finding
in
a
lot
of
use
cases
is
actually
there's
quite
a
split
into
teams.
Potentially
right,
not
every
use
case
may
be
like
this,
but
a
split
into
these
three
general
roles.
A
The
first
is
the
infrastructure
provider,
so
this
is
essentially,
for
example,
the
cloud
provider
provides
the
infrastructure
for
cluster
creation
eg
the
cloud
provider
may
be
your
the
internal
PA's
team.
The
second
one
is
the
cluster
operator
so
or
net
ops
or
sre,
and
the
key
idea
behind
this
role
is
that
they
manage
the
cluster.
Overall,
they
manage
policies
across
the
cluster
or,
for
example,
for
net
ops.
They
manage
a
policy
across
the
whole
network,
they're
responsible
for
overall
policies.
A
One
of
the
canonical
examples
is
which
services
are
allowed
to
be
exposed
to
the
Internet.
Finally,
we
have
the
empowered
developer,
who
builds
the
services,
defines
the
applications
really
wants
to
define,
for
example,
traffic
routing
and
how
their
services
are
routed.
So
in
terms
of
modeling,
we
can
look
at
sort
of
the
initial
ingress
resource
model.
So
how
is
this
model
the
ingress?
So
ingress
is
a
self
service
model.
Now
we're
adding
ingress
class.
An
ingress
class
is
basically
something
that
we
expect
to
be
controlled
by
the
infrastructure
provider
right.
A
The
infrastructure
provider
will
provide
various
kinds
of
LBS
that
then
can
be
instantiated
by
the
application
developer.
Now
the
application
developer
actually
controls
both
the
thing
that
defines
the
service,
the
service
routing
and
then
how
the
surface
is
exposed
in
terms
of
evolution.
How
does
this
map?
How
do
we
make
a
resource
model
that
kind
of
breaks
up
these
roles,
so
you
can
have
different
permissions,
so
we
see
and
again
these
names
are
early,
but
these
have
some
resonance
at
least
give
them
talking
to
some
people.
A
What
we
have
is
basically
a
way
for
you
to
give
different
are
bat
permissions
to
the
creation
of
a
gateway
versus
the
rest
of
the
application,
which
is
the
routing
and
the
services,
so
we
have
gateway
class
gateway
routes
and
service.
They
kind
of
go
into
this
and
reiterate
in
this
more
detail.
It's
sort
of
like
a
semi
UML,
dot,
diagram
of
the
different
resources
and,
for
example,
gateway
class
will
be
used
by
the
infrastructure
provider
to
say,
okay
in
your
cluster,
you
can
provide
these
kinds
of
load
balancers.
A
In
this
example,
on
a
PTO
cloud,
you
have
an
Internet
elbe
which
allows
people
to
expose
things
through
the
internet,
and
you
have
a
private
elbe,
which
you
just
just
expose
to
your
local
VPC.
Now
next,
you
have
from
the
gateway
class.
You
go
to
the
Gateway
which
is
sort
of
the
instantiation
of
the
elbe,
and
then
this
is
tied
to
than
the
actual
application
routing
and
the
application,
which
is
the
surface.
So
let's
look
at
how
this
MA
maps
into
the
team
role
separation.
A
So
in
the
maximally
separated
regime
you
have
infrastructure
provider
is
going
to
provide
a
gateway
class.
Maybe
the
net
ops
controls.
What
kind
of
gateways
are
instantiated
and
then
the
application
developer
defines
their
application
and
must
coordinate
with
the
net
ops
to
kind
of
expose
their
application.
You
could
have
a
self-service
gateway,
for
example,
you
imagine
that
for
some
situations
a
private
elbe
could
be
fine
like
you
could
let
the
developer
create
these
things.
A
So
then
you
will
let
the
developer
provision
gateways
themselves,
so
they
could
actually
provision
this
whole
chain
and
then,
finally,
if
it's
fully
self-service,
you
may
even
say
the
application
developer
can
create
any
in
cluster
infrastructure,
so
they
can
have
a
gateway
class
of
nginx
and
then
also
create
the
gateway
at
HP
route
and
so
forth.
So
this
is
sort
of
lets
you
control
and
size.
The
kind
of
self-service
and
team
roles
that
you
could
possibly
expect
now
in
terms
of
designing
these
resources.
There
is
various
design
challenges.
A
For
example,
we
know
that
among
the
Endres
controllers
there
are
very
deployment
patterns
and
then
we
talked
about
a
little
bit
about
how
the
roles
and
cooperating
resources
work
and
then,
of
course,
portability,
extensibility
and
status.
So
in
terms
of
Gateway
deployment
model.
What's
interesting
to
understand
about
this
whole
schema
is
that
if
you
have
all
these
three
pieces
gateway,
class,
HP
route
and
service,
this
in
of
themselves
doesn't
do
anything,
they're,
sort
of
defining
configuration
and
it's
really
the
gateway,
that's
kind
of
wires.
A
Everything
up,
and
when
you
wire
everything
up
with
the
Gateway,
then
the
controller
then
could
configure
a
cloud.
Lb
or
Gateway
could
instantiate
a
proxy
instance
in
the
cluster
gateway
or
could
actually
merge
gateways
together
into
a
configuration,
and
all
of
these
are
valid
implementations
of
this
model.
But
the
key
thing
is
that
the
Gateway
will
be.
The
life
cycle
will
manage
the
light
we
want
to
one
with
the
life
cycle
of
the
load
balancer,
for
example,
you
could
merge
all
of
them
together
and
reload
the
configuration
now.
A
Another
interesting
thing
is:
how
do
you
handle
the
relationship
between
a
gateway
and
a
route?
So
we've
talked
to
a
wide
range
of
users
and
implementers,
and
actually
we've
found
that,
depending
on
your
situation,
you
either
want
to
have
a
self-service
gateway,
or
maybe
you
want
to
have
a
self-service
route
and
sort
of
the
relationship
is
actually
in
both
directions.
You
want
control
in
some
cases
in
one
direction
versus
the
other.
How
do
you
design
that
into
a
kubernetes
api?
Well,
first,
let's
take
a
look
at
what
our
back
gives
you.
A
So
our
back
stands
for
role
based
authentication
control.
You
guys
know
better
than
me,
but
it
really.
It
revolves
around
four
concepts:
there's
a
user,
a
role,
a
resource
and
a
verb,
and
how
this
sort
of
to
understand
it
is
really
reading
this
sentence
that
says:
Alice
can
act
as
a
cluster
operator
with
the
permission
to
update
the
configuration
of
a
gateway.
A
So
Alice
is
a
role
user
who
can
act
as
a
role
cluster
operator
and
they
have
a
permission
to
execute
a
verb
which
is
in
this
case
update,
and
then
they
have
a
resource
that
they're
operating
on
and
in
all
kubernetes.
This
is
the
model
right.
You
have
resources,
you
have
verbs
which
is
sort
of
the
rest
of
stuff
read-modify-write
we
update,
create,
and
then
you
have
the
roles
and
users.
A
However,
if
you
want
a
handshake,
actually,
you
need
to
put
the
link
on
both
sides
of
the
resource,
so
the
most
natural
modeling
is
to
actually
have
explicit
double-sided
links
from
a
gateway
to
a
route
and
then
from
a
route
to
a
gateway.
So
if
you
look
at
the
API
sketch
you'll
see
that
actually
there's
this
explicit
link
in
either
direction
and
that's
because
there
are
use
cases
for
control
from
either
side.
So,
for
example,
you
can
protect,
who
can
use
a
given
gateway?
A
You
can
have
self-service
attachment
and
then
some
users
want
to
control
who
can
export
a
route
and
so
forth.
Now,
in
terms
of
portability,
this
has
historically
not
been
a
thing
in
kubernetes,
but
we
kind
of
envisioned
a
sort
of
nested
circle
of
how
portable
something
is
so
at
the
core
is
going
to
be
a
hundred
percent
portable.
So
any
feature
in
this
segment
must
be
a
hundred
percent
supported.
Next,
we
know
if
you
remember,
that
diagram
of
the
cloud
load,
balancers
and
the
off-the-shelf
and
so
forth.
A
We
know
that
everyone's
features
are
slowly
converging,
like
the
the
functionality
is
slowly
getting
better
for
everyone,
but
it's
not
there.
Yet.
How
do
we
model
this
in
the
API?
So
the
is
is
to
have
this
extended
layer
which
is
on
a
feature
if
I
feature
basis,
it
may
be
supported,
but
if
you
support
it
as
part
of
your
controller,
it
must
work
the
same
across
all
controllers
and
it
must
be
part
of
the
API
schema
and
then
finally,
we
know
for
extensibility.
A
We
want
this
custom
there
so
that
for
anything
else
in
there
that
we
don't
have
any
guarantee
of
portability
and
there
will
be
no
official
schema
for
it,
and
hopefully
this
creates
a
gravity
that
takes
things
from
custom.
They
mature
they
become
extended,
they
mature
even
more
and
then
become
core.
So
how
do
you
enforce
this
like?
How
do
you
actualize
this
thing?
Well,
you
have
to
do
it
through
conformance
tests
and
I
think
to
do
it
properly.
A
You'll
have
to
basically
be
able
to
statically
check
the
existence
of
an
extended
feature,
so
here
just
the
example
of
what
we
see
immediately
in
terms
of
what
will
be
corn
extended,
for
example,
ingress
will
be
in
the
core
API
now
in
terms
of
extensibility
mechanisms.
I
know
this
is
like
a
pretty
a
lot
of
people
talk
about
how
to
do
these,
but
you
know
we
have
the
annotations
map,
string,
string
and
then
custom
resource
in
draw
objects,
and
currently
our
thinking
is
that
custom
resources
are
really
and
with
a
polymorphic
object.
A
Reference
is
a
really
interesting
way
to
kind
of
get
extensibility
while
still
staying
in
the
schema,
and
that's
if
you
see
the
example
of
the
backends
and
then
in
this
case,
the
routes,
the
routes
actually
point
to
potentially
different
types
right.
You
can
go
to
different
types
from
a
given
resource
and
that,
let's
we
lets
us
get
some
of
the
flexibility
and
extensibility.
Finally,
a
long-neglected
aspect
of
load.
Balancer
api's
is
the
status,
and
this
is
something
that
we're
going
to
invest
heavily
in
because,
as
you
get,
these
object,
graphs
versus
a
single
self-consistent
object.
A
It
becomes
very
hard
to
understand
how
it's
all
stitched
together.
So
really
this
is
a
call
to
action
how
to
get
involved.
So
we
have
an
API
sketch
and
then
we're
starting
a
working
group.
The
info
will
go
out
soon.
We're
going
to
have
bi-weekly
meetings,
we're
going
to
use
the
Signet
work,
mailing
lists
to
kind
of
communicate,
have
a
slot
channel
and
have
a
repository
and
really
we
want
help
and
feedback
and
ideas
and
use
case,
especially
from
the
users.
A
D
E
A
A
E
Everything
you've
talked
about
so
far
hinted
ed.
You
know
it's
kind
of
starting
off
with
layer,
seven
HTTP
style
routing.
Is
there
a
plan
in
the
roadmap
to
support?
You
know,
TCP
services,
you
know,
layer
for
routing
I
mean
I,
see
you're
kind
of
like
abstracting
things
out
like
gateways
and
stuff.
So
it
seems
like
it's.
There.
I
just
want
to
see
what
your.
A
That's
actually
in
our
sketch
and
part
of
the
scope
is
to
figure
out
how
this
would
be
affable
the
wall
for
because
essentially
it
boils
down
to
service
as
a
grouping
mechanism,
and
then
you
have
some
sort
of
application
routing,
and
then
you
have
some
description
of
the
exposure.
That's
kind
of
the
very
high
level
like
concept
space
that
we're
trying
to
map,
so
that
is
part
of
the
sketch
I
didn't
cover
it
explicitly
here,
but
that
is
part
of
this
code.
F
A
Gonna
start
off
with
CRS,
because
yours
are
supposed
to
be
the
same
in
terms
of
functionality
and
I.
Think
that
is
actually
the
trend
of
the
project
is
to
try
to
do
every
new
thing.
As
a
CR
there's
many
advantages.
One
of
them
is,
you
can
take
them
to
versions
in
the
previous,
as
opposed
to
rubbing
them
in
Coober
nice
itself,
which
has
been
pretty
painful
for
especially
new
stuff.
G
A
Then
you
that
lets
you
easily
pick
and
choose
which
kinds
of
things
your
you
want
to
do
with
your
service
and
we've
actually
had
sort
of
people
raise
this
issue
like
well
I
wanted
a
cluster
IP
service
or
I
wanted
a
low
balance
service.
I
didn't
really
want
the
node
for
it,
but
I
have
no
way
to
express
that
right
now.
So
this
somewhat
decouples
those
things.
Oh.
A
H
H
A
Like
a
lot
of
people
do
it,
but
that
is
sort
of
on
the
implementation
side
right
that
the
user
themselves,
probably
unless
they
are
actually
using
the
API
to
wire
that
up.
That's
more
like
the
infrastructure
provider
gave
you
an
implementation
of
a
load
balancer
on
the
Internet
and
the
way
it
was
implemented
is
to
kind
of
cascade
these
things.
We
do
have
some
sketches
and
I.
Think.
A
A
lot
of
priority,
for
example
in
contour,
is
to
how
to
compose
configurations
together
and
that's
a
different
kind
of
cascading,
where
you
have
different
user
teams,
and
perhaps
you
give
different,
are
back
to
different
resources,
and
then
you
merge
them
together.
So
like
a
slightly
different
way
to
compose
things.
Okay,.
H
Another
question
is
like
what
is
the
timeline
for
all
of
this
I
mean
it
seems
like
there's
going
to
be
new
India
as
we
want,
and
this
gateway
seems
like
a
completely
different
thing.
Is
this
in
Greece
v1
will
be
rolled
into
this,
so
it's
going
to
be
separately,
Inga's,
v2
or
like
how
this
all
works.
The.
A
Way
we
see
it
is
that
there
ingress
is
actually,
quite
surprisingly
popular
in
terms
of
implementations,
right,
lots
of
implementations
and
actually
quite
a
few
users
and
for
a
big
set
of
users.
It's
actually
a
completely
fine.
So
in
terms
of
Signet
work,
the
way
we
look
at
it
is
it's
going
to
be
supportive,
like
ingress,
is
going
to
be
GA
and
it's
going
to
be
a
thing
and
it's
going
to
remain
useful
for
those
people
and
then
Gateway
is
sort
of
how
we
are
seeing
an
evolution.