►
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
Deep Dive: API Machinery SIG - Stefan Schimanski, Red Hat & Daniel Smith, Google
This Deep Dives will cover the recent developments of Sig API Machinery. This includes: - CustomResourceDefinition versioning, conversion, pruning and defaulting and the road towards GA - server-side apply and the implications for controller developers Both topics are essential for everybody building extension APIs on-top of Kubernetes. The first is about evolving CRD based APIs from v1alpha1 to v1beta1 to stable v1. The second is about multiple actors changing API objects with apply-like semantics. We will have the chance to dive into the topics and to answer technical questions around them.
To learn more: https://sched.co/Grf5
A
So
welcome
everybody,
so
we
have
it
late
because
we
have
machinery
future
taught
by
Daniel
was
Justin's
other
building,
so
we
were
running
and
but
yeah
so
deep
dive.
We
have
two
topics
mainly
I
have
some
slides
about
CID
conversion,
which
we
didn't
show
in
the
last
talk
bye-bye
medium
Eddie
I
will
go
over
them.
First
then,
you
has
something
about
apply,
so
I
said
apply
also
a
big
thing
for
2019
and
then
we
just
have
Q
day.
So
if
you
have
questions
about
those
topics,
but
anything
I
guess
just
feel
free
to
ask
so.
A
They
have
focus,
I
might
be
able
deep
dive.
So
I
think
most
of
you
have
seen
that
we
have
see
ad
conversion
since
113
is
either
via
web
hooks
and
I
just
want
to
yeah.
Give
some
slides
add
some
questions
which
came
up
afterwards.
So
there
was
a
question
about
ordering.
Wednesday
is
conversion
actually
and
houses
place
with
admission
and
those
things
and
I
will
try
to
answer
them
quickly.
So
this
is
a
pipeline
of
the
API
server
and
see,
at
least
in
this
case.
They
come
in.
A
Here,
goes
who
authentication
authorization
and
so
on
and
end
up
in
the
handlers
and
see
at
least
our
Jason
on
the
wire.
So
the
decoded
and
admission
is
executed
on
them
as
for
any
other
resource,
maybe
there
are
books
called
attends
as
usual,
test
logic
being
applied,
which
might
include
at
see
the
XS
and
any
other
more
complicated
things,
and
then
something
is
encoded
again
and
sent
back
to
the
client
and
yeah
conversion.
A
So
this
is
our
old
slight
general
slide
and
there
are
some
words
conversion
somewhere
in
there
and
I
highlighted
some
so
there's
three
places,
basically
where
we
have
conversion
and
they
play
a
role
of
obviously
also
for
CDs,
but
not
really
so.
Those
places
would
be
candidates
for
conversion
where,
because
the
conversion
stick
now
adays,
but
luckily
we
we
did
something.
A
We
don't
have
internal
types.
So
if
you
know
api
service
for
native
types
and
go
we
Nate
if
internal
taps
as
well-
and
we
have
to
convert
a
lot
for
CDs-
we
didn't
do
that
for
CDs.
We
have
requests
version
everywhere
in
the
pipeline.
So
you
see
this
blue
v1
everywhere
it's
v1
in
LCD.
It
might
be
v2,
so
this
dog
version
might
be
different
and
yeah,
as
you
can
imagine,
a
lot
of
source,
yellow
bubbles
just
go
away.
You
don't
have
conversions
there,
so
CID
conversion
is
not
called
as
much
as
for
native
resources.
A
Luckily,
because,
obviously
it's
a
it's
a
failure
or
a
point
where,
where
an
error
can
occur
or
it's
performance
issues,
latency
and
so
on,
so
basically
you
have
those
two
two
points
there
in
the
stack
on
an
update.
We
have
to
get
something
from
Exedy
and
we
apply
something,
so
they
have
some
conversion
back
and
forth.
So
maybe
two
or
three
something
like
that
at
the
end
here,
there's
nothing
because
we
are
Whitney's
right,
we're
on
the
netbook
cords.
It's
the
same.
A
Patches
are
a
bit
more
complicated,
so
patches
heavier
each
wire
mechanism
internally,
which
means
there
might
be
an
additional
conversions
because
each
each
time
on
each
each,
why
you
have
to
read
from
Exedy
again
on
convert
so
patches
bit
more
heavy,
but
still
it's
very
contained
at
those
two
positions
we
have
watches,
watches
are
also
burdened.
There
might
be
yeah
one
more
per
version,
which
is
not
the
storage
version,
so
this
is
yeah
roughly
is
a
idea
or
a
number
which
you
can
expect
from
from
the
Red
Hook
for
CID
conversion.
A
Yeah
I
talked
about
internal
versions.
This
is
a
picture
here.
This
is
for
native
resources
and
they
see
everywhere
inside
of
this
pipeline.
Here
you
have
internal
objects
and
everywhere
on
the
site
on
the
edge
you
have
to
convert.
So
this
is
where
we
were
heavy
and
conversion
is
so
important
for
internal
conversion.
There's
actually
a
discussion,
maybe
to
change
that.
Do
we
really
need
those
internal
types
anymore?
Maybe
we
want
something
called
a
hub
type,
which
would
also
make
this
easier.
Maybe.
A
The
second
topic
about
CID
is
haunt
ability,
so
I
show
the
slides.
We
do
how
to
test
for
native
resources
everywhere,
very
heavily.
So
on
each
change
in
the
API
we
weren't
thousands
of
randomized
conversion
tests,
so
we
we
just
fill
object
with
random
values,
convert
to
another
version
via
the
internal
version
and
back
and
see
it.
Nothing
was
lost
on
the
way,
so
hound
tripping
is
very
important
and
we
highlight
a
set
like
10
times
in
the
last
talk.
I
just
wanted
to
show
before
you
start
doing
that
we
have
patterns
for
that.
A
A
So
this
is
fast,
no
custom,
so
no
custom
coils
here,
but
often
you
have
to
fix
certain
things
like
you
have
to
apply
defaults
can
imagine
if
you
don't
have
default
and
you
convert
to
another
version
and
back
and
there
might
come
and
come
in
default
value,
suddenly
so
better
default
before
you
will
notice
that
very
early
on
when
you,
when
you
have
those
cases
with
defaults
where
on
table
testing,
fails,
but
it
shouldn't.
So
it's
pretty
obvious
that
defaulting
is
missing
and
also
other
type
invariants.
A
Sometimes
you
only
support
certain
string
formats
like
some
syntax
in
strings,
but
the
father
of
course
puts
Wenham
date
has,
and
this
is
not
supported
by
the
conversions
and
you
need
to
to
enforce
certain
type
invariants.
And
by
that
you,
you
create
a
list
of
those
fuzzer
functions
and
we
put
them
into
a
funk
slice
usually,
and
then
we
have
a
machinery
and
API
machinery.
So
some
some
package
called
round
trip
where
we
have
our
own
trip
test
for
API
group.
A
You
give
it
so
testing
T
and
the
insert
function
for
the
scheme,
those
functions
and
it
just
wanted
a
thousand
times
or
something
like
that
in
all
directions,
with
all
versions
between
all
those
ones.
You
have
or
conversions
you
have
to
find,
and
that's
basically
it.
So
that's
how
all
to
ability
testing
looks
like
in
our
code
and
jeez.
You
can
just
use
the
same
mechanism,
yeah
outlook,
I
just
repeated,
and
we
showed
it
in
the
last
talk
already.
A
A
big
topic
is
see
a
yeast
should
pga
next
year
and
there's
a
big
issue
just
look
to
it
with
20
or
something
ish
sub-issues,
which
we
have
there
and
those
are
the
ones
which
are
critical
so
which
we
declared
as
being
critical
before
we
go
to
j.
There's
a
discussion
in
this
issue.
If
you
have
a
different
opinion,
go
there
and
comment,
that's
more
or
less
consensus
at
the
moment,
but
yeah!
It's
it's
out!
A
It's
one
of
the
big
topics
next
year
to
work
on
those
the
first
one
is
nearly
done
so
I
guess
in
the
next
release
we
will
have
set
it's
nearly
what
it
missed
1:13.
Just
by
a
few
days,
I
guess
quota.
We
have
ideas,
we
had
some
implementation
by
Nikita.
She
is
here
and
we
want
another
implementation
where
we
have
everything
necessary,
I,
guess
now
generic
inform
us
it's
a
topic
there
default
and
prunings
as
a
kept
open.
A
B
B
Yeah
yeah,
yeah,
yeah
I
think
Phil
definitely
has
some
plans
there,
so
yeah
anyway,
I
just
I
just
thought.
It
was
important
to
mention
that
we're
aware
that,
like
this
is
this
is
hard
and
we'd
like
to
give
you
help
doing
it
so
I
put
together
this
server
side
apply
slide.
I,
put
everything
on
one
slide:
how
much
detail
do
people
want
for
server-side
apply?
Do
you
want
like
a
lot
of
detail
here
or
just
a
little
detail?
Okay,
I
see
some
yeah,
okay,
okay,
lots
of
detail.
Okay,
all
right
cool!
B
We've
been
working
on
this
since
I,
don't
know
into
like
I
put
together
the
original
design
like
q1
this
year,
and
then
we've
been
working
on
it
since
then,
and
we
did
a
lot
of
useful
generically
useful
plumbing
refactoring
in
in
API
server
like
we
refactored
the
patch
Handler
and
and
actually
as
a
result
of
that
were
able
to
like
I,
spend
all
this
time,
refactoring
it
and
then
then,
like
Jordan
deleted
like
a
huge
chunk
of
it,
because
it
wasn't
actually
useful.
So
that
was
great,
and
this
this
makes
our
job
easier.
B
So,
but
but
what
are
we
doing
now?
Well,
I,
don't
know
about
maybe
a
quarter
or
so
ago.
Maybe
four
months
ago
the
the
folks
really
working
on
it,
which
are
Antwon
police,
Jenny,
Buckley
and
myself
locked
ourselves
in
the
room
and
really
tried
to
make
sure
that
we
had
a
that.
We
had
a
shared
vision
for
the
design.
I
should
say
before
that,
like
like
Antwon
and
Jennie
implemented
dry
run,
because
we
knew
that
was
going
to
be
very
useful
for
this,
and
I
was
I
was
I
had
to
be
out
of
the
office.
B
Paternity
leave,
I
had
to
be
out
of
the
office,
so
they
went
and
implemented
dry
run,
and
that
is
beta
and
113.
So
that's
pretty
awesome,
but
then
then
I
came
back
and
we're
like.
Okay,
we've
got
a
we've
got
to
get
everybody
on
the
same
page.
We
really
got
to
knock
this
out
of
the
park
now,
so
we
hashed
out
the
design.
Antwon
read
all
like
50
pages
of
my
original
design
carefully,
and
so
then
we
we
sat
down
and
we
really
argued
about
how
to
like.
B
Is
that
really
the
best
way
to
do
it
like
there's?
So
the
original
design
like
like
the
so
the
current
design,
has
this
last
applied
annotation,
which
is
like
a
JSON
encoding
of
the
entire
object,
stuffed
annotation.
So
it's
like
everything
is
escaped
quoted
and
if
you're
in
a
secret-
and
you
had
some
secret
value-
well,
that's
on
the
annotation,
so
it
makes
it
hard
to
give
people
read-only
or
metadata
only
access
to
your
secrets
when
your
entire
value
is
in
the
metadata.
B
So
that's
not
good
and,
and
then
the
the
next
design
was
like
a
formalization
of
that
really
explicitly
defining
the
the
concept
of
what
is
a
schema.
What
is
it?
What
is
a
type?
What
does
it
mean
to
diff
them?
What
does
it
mean
to
add
them
together?
So
I
like
rigorously
rigorously
defined
this
three-way
merge
operation,
so
III
mean
I,
think
that
would
have
worked
what
we
came
up
with
a
slightly
better
design,
functionally
behaviorally.
B
This
is
almost
100%
the
same
like
like
we
won't
be
changing
the
test
cases
that
we
would
have
written,
but
the
new
design,
instead
of
storing
the
exact,
struct
or
exact,
object,
all
the
values
intact.
We're
now
we've
developed
this
data
structure,
which
is
a
set
of
field
owners
in
the
the
soso
and
we've
written
this
nice
library
that
gives
like,
given
a
schema.
B
But
the
upshot
of
this
is
that
we
can
store
these
in
the
we
can
store
these
in
the
metadata
and
since
these
are
just
sets
of
fields,
they
don't
include
the
values
so
that
lets
us
be
both
more
compact
and
in
space,
and
we
don't
publish
your
secret
details
anymore
in
metadata.
So
the
way
this
sort
of
works
is
well
suppose,
and
so
there's
there's
like
two
entry
points
into
the
apply.
The
apply,
I'll
call
it
the
system.
Alright,
there
is
the
apply
entry
point
where
you're,
a
user
and
you've
explicitly
said
apply
this
manifest.
B
So
so,
basically,
I'll
go
through
the
apply
path.
First,
so
you
do
not
apply.
The
server
takes.
Your
texture
object
that
you
sent
basically
takes
all
the
fields
you
set
strips
off
the
values
and
puts
this
into
the
data
structure,
which
is
like
a
try
just
for
efficiency,
but
you
could
logically
imagine
it's
just
a
flat
list
of,
like
you
know,
spec
spec,
dot,
replica
aspect
that
the
template
that
containers
0
named
foo.
You
know
so
all
these
things
in
in
this
set,
and
it
stores
this
in
the
metadata
saying
you
own
those
fields.
B
Now
we
allow
multiple,
it's
not
just
a
owner
set
in
a
metadata.
It's
also
who
is
the
owner
of
that
set,
so
we
can
look
at
what's
currently
in
the
metadata
and
see.
Does
somebody
else
think
they
own
one
of
the
fields
that
you're
trying
to
set
and
if
somebody
else
does
own
that
we
tell
you,
you
actually
need
to
force
this
operation.
B
You
need
to
say
explicitly
say:
I
know
some
other
component
or
some
other
actor
in
the
system
thinks
that
they're
managing
this
field,
but
now
I'm
managing
it-
and
this
is
a
this-
is
a
this-
is
to
force
the
user
to
be
cognizant
that
they're
fighting
with
some
other
actor
in
the
system.
Ok,
so
so
that's
essentially
what
happens
when
the
user
and,
of
course,
if
the
user
does
force,
then
we
take
that
field
away
from
the
other
actor,
add
it
to
the
user
to
the
user
set.
B
Like
always
force,
because
if
you're
writing
a
controller,
you're,
probably
not
prepared
to
begin
receiving
a
new
class
of
error
message
right,
like
a
hey
you're,
trying
to
take
over
a
field
that
the
user
thinks
they're
setting,
that's
not
a
useful
thing
to
give
to
a
controller.
It's
just
going
to
be
like.
Oh,
there
was
an
error,
I
guess:
I'll,
try
again
in
a
second
or
millisecond,
and
that's
that's
not
a
that's,
not
a
useful
thing.
B
So
so
we
just
always
let
the
controllers
win
and
then
the
next
time
the
user
goes
in,
the
user
will
get
the
warning
and
the
user
will
understand.
Oh
I'm,
fighting
with
the
horizontal
pot
autoscaler
over
the
value
of
spectra,
Pacha's
I,
should
probably
go
turn
that
off
for
this
thing
or
maybe
I
should
remove
it
from
my
from
my
specification
document
right
because
because
probably
you
actually
want
the
controller
to
keep
on
doing
you
don't
want
to
fight
with
it,
and
so
so
that's
a
those.
B
B
So
we
wrote
a
bunch
of
code
there.
It
constructs
these
fieldset
objects.
Does
all
the
necessary
set
operations
is
pretty
nifty.
It
implements
the
logic
behind
apply,
so
that's
that's
done
and
then
we
started
to
glue
it
all
together.
We
realize
that
we
missed
a
couple
pieces
like
like
in
the
glue.
So
it's
actually
calling
into
the
system
is
actually
easy.
It
is
phrasing
this
new
structure
in
the
metadata
that
is,
that
is
the
thing
Antoine
and
Jenny
are
working
on
at
the
moment,
so
our
our
first
draft
was
actually
incredibly
verbose.
B
So
we
came
up
with
a
new
format
and
Jenny
just
showed
me.
The
proof-of-concept
last
night
looks
great:
it's
going
to
be
very
concise
and
yeah
it'll
be
it'll,
be
great,
so,
hopefully
that'll
go
in
soon
when
I
come
back
from
maternity
leave,
end
of
January
it'll
be
it'll,
be
it'll,
be
all
in
so
I
should
say
one
more
thing
about
this.
B
One
of
the
hard
things
about
kubernetes
objects
is
we
tend
to
do
this
thing
with
lists
where
it's
not
actually
useful
to
index
the
list
by
by
number
right
like
it's,
not
that
you
want
the
first
container
in
the
list.
It's
that
you
want
to
own
a
field
for
the
container,
which
has
the
name
my
sidecar
right.
So
the
the
schema
format
and
the
way
in
which
you
name
things.
B
When
you
specify
a
list
item,
it
actually
understands
that
the
name
or
some
some
some
lists
have
them,
have
multiple
things
like
the
the
port.
The
port
list
has
both
the
port
number
and
protocol,
like
that.
Those
two
things
identify
that
entry.
So
it
understands
that
and-
and
it
puts
that
as
the
indexing
function,
so
that
you
own
it-
you
continue
to
own
it
even
in
the
face
of
reorderings
or
other
things,
so
that
is,
that
is
actually
one
of
the
main
reasons
why
we
have
to
do
something
special
here.
B
Why
built-in
tools
like
JSON
hatch,
JSON,
merge
patch,
are
really
insufficient
for
for
this
for
this
operation,
so
we're
working
on
the
API
I
think
we'll
have
something
that
we're
happy
with
very
soon
so
I
I
really
don't
see
any
problem
with
merging
this
back
and
actually
I
know.
We
made
this
feature
branch
and
it
looks
like
the
amount
of
actual
changes
that
are
going
into
the
future
branch
will
be
fairly
small
for
the
for
the
future
branch.
But
it's
good.
It's
a
good
to
either
commit
a
completely
working
thing
or
leave
it
not
committed.
B
Mathon
1.14
and
like
alpha,
then
beta,
then
eventually,
ga,
hopefully
soon
I
think
for
for
beta
will
want
to
make
sure
that
this
works
for
CR
DS,
just
as
well
as
other
optics.
We've
got
some
ideas
for
how.
How
can
we
make
reasonable
assumptions
about
the
schema?
If
you
are
CRD
author
and
you
didn't
actually
add
a
schema,
so
I'd
like
to
I'd
like
to
continue
to
support
like
some
some
rudimentary
amount
of
apply,
you
know
gracefully
degrade.
If
you
want
the
full
semantics,
so
you
can
always
provide
schema
so
next
steps.
B
What
are
we
gonna
do
in
the
future?
Well,
I
think
it's
really
nifty
that
we've
got
that
that
were
in
as
soon
as
this
merges
we're
gonna
have
this
great
entry
point
into
a
into
a
subsystem
that
understands
the
object,
schema
and
the
the
what
the
users
trying
to
do
to
it
so
I
think
an
example
of
a
really
useful
thing.
We
could
do
that
do
here,
that
we
really
didn't
have
the
ability
to
do
before,
or
at
least
not
in
a
clean
way,
as
we
could
add
something
like
discriminated
unions.
B
Brian
grant
has
frequently
talked
about
this
idea
that
that
are
one
of
it
would
be
great
if
we
had
like
a
field,
a
discriminator
field
that
told
you
which
of
the
other
fields
was
the
one
you
intended
to
use
like
in
the
the
volume
object
is
a
is
a
great
example
when
there's
like
this
many
different
volume
sources.
So
if
we
had
a
discriminator
that
said
what
what
volume
you
intended
to
use
like
the
subsystem
could
know
to
like,
if
you
send
it
with
this
new
thing
set,
we
know
that
hey.
B
We
should
clear
the
others,
because
you
didn't
intend
to
set
the
others
right.
So
if
you
have
like
like,
for
example,
a
client
that
didn't
understand
the
others,
because
it's
an
old
client
and
some
of
then
you
set
new
and-
and
so
you
couldn't
have
cleared
it
because
your
client
didn't
understand
that
field.
So
that's
that's!
That's
just
an
example
of
the
sort
of
thing
that
I
think
we
can
add
here
another
another.
B
Api
objects
is
enormous,
like
we've
got
to
narrow,
that
down
and
and
and
and
only
permit
a
certain
subset
of
that
to
enable
interoperability
and
all
the
all
the
things
you
get
with
the
kubernetes
api,
so
yeah.
That
was
a
lot
of
talking.
Should
we
do
Q&A
yeah
here
all
I'll
walk
around
with
a
microphone
and
Stefan
can
set
up
here
and
answer
all
the
questions.
C
Right
from
the
discriminated
unions,
but
we
specifically
don't
allow
one
of
in
the
validation
object.
Currently,
so
what's
the
justification
there
I
think
was
a
CPU
intensive
operation
to
do
the
validation
check
with
the
discriminated
Union
you're
saying
that
we
would
have
a
field
that
would
tell
us
what
to
check
for
to
see
if
it's
set
you're.
B
A
There's
one
office
performance
reasons,
so
you
can
easily
construct
something
which
is
exponentially
or
something
in
invalidation,
because
it's
open,
API,
strange
behaviour,
strange
property,
it
embeds
logic,
propositional
logic
completely.
So
that's
why
we're
that
it's
not
healthy
for
validation.
Yes,.
D
B
B
Unfortunately,
the
conversion
functions
the
built-in
ones
all
make
certain
assumptions
about.
The
object
like
the
defaults
are
set
which
are
actually
not
applicable
to
things
that
you
run
through
apply
because
apply
is
actually
a
subset
of
the
object
is,
is
not
the
entire
object.
It's
just
the
fields
that
you
want
to
manage.
So
we
realized
that
that
was
going
to
be
difficult
and
David
pointed
this
out.
B
I
had
I
had
an
approach,
but
after
thinking
about
it
carefully
and
I
wrote
up
a
design
that
actually
solved
the
problem
without
doing
any
conversions
by
doing
a
fancy
like
doing
extra
operations
on
both
sides,
which
I
won't
be
able
to
reproduce
off
the
top
of
my
head.
So
I
got
to
go
back
up
my
document,
but
the
fun
thing
about
the
the
fun
thing
about
the
design
is
that
it
worked
on
the
fieldset
approach
too.
So
kind
of
it's
not
that
we
went
down
the
wrong
direction.
B
A
B
F
In
one
of
the
keynotes
yesterday,
someone
declared
that
kubernetes
is
boring
and
all
of
this
stuff
looks
distinctly
not
boring
and
like
the
playing
field,
is
moving
at.
What
point
do
you
imagine
that
some
of
this
will
start
to
get
boring
and
stable
to
the
point
where
people,
rather
than
looking
at
wrapping,
cube
control
to
do
their
management?
Say
you
know?
Oh,
hey,
I
can
build
a
client.
You
know,
use
client
go
and
get
most
of
the
same
functionality.
F
B
That's
a
yeah
I
think
our
particular
corner
of
the
world
is
not
going
to
get
boring
for
a
little
while,
yet
I've
got
a
long
list
of
things
to
do
and
I
think
we're
a
little
bottleneck
both
and
like
spelling
out
the
things
we
want
to
do
and
and
people
taking
those
things
up
and
doing
them
and
and
and
reviewing
the
changes,
because,
because
there's
there's
actually
not
that
many
high-level
reviewers
for
API
machinery,
so
we're
a
little
we've
got.
We've
got
a
number
of
bottlenecks,
yeah,
so
yeah
it
would
be.
B
B
C
Sorry
Ida
spoken
with
Stefan
about
this
before,
but
validating
and
mutating
my
books
are
commonly
also
registered
with
CR
DS,
and
now
we
have
the
storage
conversion.
It
is
actually
configured
on
the
C
or
D.
Is
there
any
possibility
of
being
able
to
configure
yourself
as
a
validating
and
mutating
web
book
on
the
CR
D
and
then
a
follow
up
would
be?
Can
we
do
a
health
check
to
see
that
the
web
book
is
available
and
provide
that
in
the
status
of
the
C
or
D.
B
B
Actually,
so,
in
my
role
at
Google,
we
operate
many
clusters,
and
so
I
have
this
sort
of
side
a
project
or
idea
is
the
control
plane
needs
to
be
compartmental.
I
really
need
some
areas
of
it
to
be
able
to
fail
without
bringing
down
the
whole
thing.
So
in
particular,
these
web
hooks
are
a
source
of
concern,
but
importantly,
to
the
extent
possible,
I
want
the
conversion
or.
B
Admission
control
web
hooks
I
want
them
to
be
able
to
fail
without
bringing
down
the
whole
cluster.
It
may
not
be
possible
if
you
register
something
that
does
cover
the
whole
cluster,
but
at
the
very
least,
I
want
the
cluster
administrator
to
be
able
to
look
at
it
edit
at
a
dashboard
and
be
like
these.
These.
These
are
all
the
web
hooks
that
we're
calling
this
is
like
I,
don't
know
the
last
hours
worth
of
calls
or
something.
This
is
the
successes
of
failures.
B
The
like
failure
to
reach
it
basically
I
think
the
cluster
administrator
needs
to
be
able
to
quickly
route,
see
that
hey
something
is
broken.
I
go
to
the
Status
page.
This
is
the
thing
that's
broken
at
the
very
least,
so
a
health
check
could
help
that
in
a
busy
cluster,
it's
gonna
be
called
a
lot
which
is
sort
of
the
same
thing,
I
guess
but
yeah
and
the
other
question
was
all
those
all
those
webhooks.
That's
a
lot
of
work
folks.
B
Have
this
component
I
wanted
to
handle
all
aspects
of
this
I
think
that's
like
an
API
design
and
upgradability
thing,
and
also
a
security
security
thing,
because
the
ability
to
put
a
admission
webhook
on
all
resources
of
the
system
is
has
security
implications,
but
it
makes
sense
to
me
that
a
C
or
D
author
should
be
able
to
register
the
things
just
for
their
C
or
D,
and
whether
that
means
like
an
external
component
like
then,
goes
and
makes
the
necessary
entries
on
their
behalf.
That's
that's
the
most
obvious
way
to
do
it.
B
Yeah
yeah
I
think
actually
the
the
admission
control
webhooks
the
design,
the
the
objects
there
may
need
a
some
tweaks
in
their
design,
because
right
now
you
register
for
particular
versions
of
resources,
which
means
that
like,
if
you
actually
wanted
to
to
run
on
a
deployment,
no
matter
how
the
user
sent
the
deployment
to
the
system,
you
have
to
be
careful
to
do
that
correctly
today.
So
I
think
that
we
can
do
better.
We
just
haven't
had
the
like.
B
That
is
a
great
question.
I
think
it
is
actually
going
to
be
a
priority
for
us
and
q1
yeah.
My
team,
specifically
I
I,
was
actually
wandering
around
to
various
other
places
earlier
in
the
conference
asking
folks
hey,
why
don't
you
come
and
help
us
submit
a
design?
There
is
a
there
is
somebody
has
a
cap
out.
I
know
I
asked
for
some
changes
on
that
I
haven't
come
back
and
seen
the
responses
yet
and
I.
Think
David
and
I
are
mostly
on
the
same
page
with
what
we
need.
This
basically
like.
B
We
want
some
sort
of
bucketing
system
like
like
that's
very
cheap,
to
take
a
incoming
request
figure
out.
What
buckets
it
bucket
is
is
in
and
then
some
sort
of
quota
system
for
the
for
the
individual
buckets
and
there's.
But
there's
it's
not
clear
like.
If
you
have
multiple
API
server
replicas,
we
don't
want
to
yeah
it's
it's
a
little
like.
We
need
to
be
careful
to
make
sure
that
that
works
right.
G
B
Maybe
I
should
say
the
a
little
bit
more
like
I
think
we
actually
need
at
least
two
tiers
in
the
system.
Tier
one
is
like
guaranteed,
and
the
purpose
of
this
is
to
make
sure
that
your
cubelet,
your
scheduler,
your
controllers,
always
can
get
the
the
QPS
that
they
need
and
then
unused
like
the
API
server
needs
to
have
some
sort
of
understanding
of
how
many
requests
it
can
handle
and
so
anything
not
consumed
by
Tier.