►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Kubernetes-style APIs of the Future - Daniel Smith, Google (Any Skill Level)
Over the past 4 years, the Kubernetes project has a built an extensive API platform centered around the needs of the Kubernetes cluster management system, because nothing else was suitable. What are those needs, and are they really unique to the domain of cluster management? They are not, and therefore there is a Kubernetes-style API in your future--come learn what it will look like.
About Daniel
Currently TL of Kubernetes’ API Machinery sub-team, Daniel has been working on Kubernetes since before it was open sourced, and contributed enough in the early days that he’s still one of the top contributors overall. Before that, Daniel worked on Google’s borg and AppEngine. He lives in Mountain View, CA with his wife and two children.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
A
A
We
ended
up
building
an
API
platform
and
whenever
I
say
that
I
feel
like
I,
should
follow
up
with
the
word
oops.
But
is
it
really
a
mistake?
I
think
the
reasons
that
we
did.
This
were
good
ones.
We
didn't
make
a
mistake.
We
needed
different
things
from
our
api's
than
we're
an
offer
from
the
various
API
systems
out
there.
A
So
let's
talk
a
little
bit
about
api's
I,
don't
know
if
you've
ever
made
a
hobby
website
or
anything
like
that.
I
have
and
you
sort
of
you're
writing
a
back-end.
You're.
Writing
a
front-end.
You
add
an
API
because
you
need
you
need
to
do
this
little
thing
and
you
had
another
one
whose
need
to
do
a
little
thing
here.
A
I've
got
a
user
adding
a
bunch
of
RAM
to
their
shopping,
cart
and
then
attempting
to
charge
their
card
for
it,
and
I've
done
this
sort
of
thing
before
it
doesn't
scale,
because
you've
got
some
handcrafted
artisanal
server-side
code
that
is
lovingly
putting
together
a
json
response,
object
and-
and
that's
great
until,
like
a
new
person,
looks
at
your
code
and
they're
like
I,
have
to
go.
Read
your
server
code
to
know
what
what
sort
of
client
to
write
so
this
this
is.
This
is
sort
of
the
first
thing.
B
A
A
So
then
you
come
up
with
something
like
what,
like
rest
so
for
for
my
purposes
here.
Rest
is
this
idea
that
your
operation
should
match
up
with
the
HTTP
verb
that
you're,
using
and
crud
is
the
idea
that
you
support,
create,
read,
update
and
delete
operations
yeah
so
that
that
gets
us
that
gets
us
a
little
bit
of
the
way
towards
an
understandable
API
system.
This
is
sort
of
like
the
API
version
of
a
object-oriented
programming,
but
it
doesn't
quite
go
far
enough.
A
A
For
example,
here
I've
got
you've
got
a
message
that
describes
the
resource
and
then
you
have
to
make
a
separate
message
for
the
create
request
and
the
create
response,
and
you
have
to
do
this
for
every
verb
that
you
want
to
support
and
when
you're
done,
you
have
a
bunch
of
code,
and
maybe
your
programmers
are
going
to
do
it
consistently.
Maybe
they're
not
and
you
can
generate
documentation,
but
that
sort
of
works
for
humans.
Although
humans
have
to
go
read
it,
it
doesn't
work
for
machines.
A
A
Let's
talk
a
little
bit
more
about
what
API
systems
do
they're,
basically,
opinions
very
strong
pinions
about
how
you
get
stuff
between
clients
and
servers.
So
I
have
a
little
diagram
here
of
how
you
know
if
the
rough
flow
you
start
with
some
in-memory
stuff,
you
do
some
manipulation
to.
It
ended
up
with
something
you
can
send
over
a
network.
The
server
does
some
computation,
hopefully
there's
no
side-effects,
or
maybe
you
want
the
side-effects,
and
then
it
sends
back
a
response.
A
So
you
can
summarize
this
as
an
API
call,
has
some
amount
of
data,
some
action
and
there's
some
transmission
layer
and
I've
drawn
the
data
in
the
action
in
the
same
layer
here,
because
they're
actually
fungible
right,
you
can
have
one
API
request
with
the
bajillion
options
or
a
ton
of
different
API
quests,
with
like
no
options
at
all.
So
is
really
you
can
you
can
stuff
the
you
can
shuffle
the
stuff
into
one
bucket
or
the
other.
It
accomplishes
the
same
thing.
A
So
an
API
system
is
like
some
sort
of
specification
telling
you
how
to
do
how
to
do
each
of
these
things
and
the
kubernetes
resource
model
is.
Is
it
goes
beyond
just
that
specification?
It's
a
specific
sort
of
a
specific
way
for
you
to
do
each
of
those
each
of
those
items
all
right.
So
the
under
the
kubernetes
api
system.
A
We
require
a
standardized
data
structure,
standardized
methods,
and
you
end
up
with
with
a
standard
resource
and
again
this
is
important
because
we
want
not
just
humans
but
machines
to
use
your
resources
yeah,
so
we
go
beyond
object-oriented,
we
are
requiring
various
it's
like
being
like
object-oriented
programming
is
like
here's,
your
your
phrase,
your
problem
in
terms
of
objects
to
which
you
can
perform
actions
right.
Well,
we
say
you
can
have
as
many
objects
as
you
want,
but
they
must
be
structured.
A
So
why
is
it
more
restrictive?
I
want
to
argue
that
a
lot
of,
if
not
all,
of
modern
software
engineering
practices
are
actually
about
complexity,
management
and
so,
for
example,
you
take
your
source
control
system.
That's
about
managing
the
complexity
of
having
lots
of
lines
of
code.
Object-Oriented
programming
is
about
managing
the
complexity
of
having
lots
of
code,
there's
just
just
about
everything
like
functional
programming,
immutable
objects.
This
is
about
managing
the
complexity
of
your
code
as
it's
in
motion.
A
A
If
we
document
each
of
these
separately,
we
have
a
bunch
of
users
that
have
to
go,
read
them
right.
If
you're
a
user
using
our
system,
you
want
to
figure
out
what
a
what
a
various
I've
got
a
pod
here
and
I
want
to
read
it.
Do
you
go
read
the
documentation
for
for
this
pod
I
mean
that's
great,
but
if
you
repeat
it
for
every
verb
for
every
object,
that's
a
lot
of
a
lot
of
reading
right.
A
A
So
so,
how
does
the?
How
does
the
kubernetes
resource
model
address
this
problem?
We
address
it
by
enforce
it
by
restricting
the
the
possibilities
we
document
a
standard
metadata
you're
not
allowed
to
have
a
non-standard
metadata.
You
won't
be
compatible
with
the
ecosystem.
We
document
standard
verbs,
you
must
you,
your
verbs
on
your
resource
must
work
the
same
as
the
verbs
on
any
other
resource.
You're
not
allowed
to
have
a,
for
example,
an
update
method
that
is
just
a
random
grab
bag
of
fields
that
you
can
update.
A
It
is
the
same
object
structure
as
the
thing
that
you
send
to
the
post
method,
so
you
do
this
and
now
a
user
that
understands
how
to
post
a
pod
also
understands
how
to
post
a
deployment.
The
only
thing
they
have
to
learn
is
the
contents
of
the
deployment
object
or,
if
I
know
how
to
post
a
replica
set.
I
also
know
how
to
put
a
replica
set,
because
the
the
the
difference
is
just
a
different
HTTP
verb.
A
The
the
body
of
this
request
is
the
same
and
if
I
learn
how
to
put
one
thing,
I've
learned
how
to
put
another
thing,
because
optimistic
concurrency
works
the
same
across
all
of
our
objects
and
methods.
So
hopefully
this
leads
to
a
bunch
of
happy
users.
I
can
say
this.
I
can
say
this
another
way.
We've
got
all
the
stuff
in
her
system.
Pods
node
services
are
back
rules,
I've
got
my
custom
resource,
which
is
essential
to
the
operation
of
your
cluster,
your
custom
resource,
which
is
pretty
nice
to
have
and
their
cluster.
A
There
are
custom
resources.
Well
we're
just
running
it
because
management
wants
us
to.
But
you
look
at
that.
That's
a
lot
of
stuff.
You
have
to
learn.
We
have
six
verbs
all
right,
I've
got
I've
drawn
six
verbs
there,
but
that
six
is
really
a
stand-in
for
the
average
number
of
operations
per
resource
type.
So
you
think
of
this
as
M
times
n.
This
is
a
polynomial
complexity
and
that's
not
good.
When
you
want
a
human
to
understand
your
system.
A
A
So
if
you've
got
one
pot
in
one
node
and
they
can
each
be
happy
or
sad,
you've
got
four
states
right
and,
and
four
states
doesn't
seem
so
bad.
But
if
you
think
about
it,
if
you've
got
a
node
and
it
can
be
in
one
of
five
states
and
you've
got
another
node
which
can
be
in
one
of
five
state.
You've
got
n
of
these
things
that
comes
out
to
five
to
the
N,
which
is
an
awful
lot
of
states
to
think
about
and
the
way
the
kubernetes
api
system.
The
the
resource
model
addresses.
A
This
problem
is
by
splitting
it
into
small
pieces
and
we
have
the
controller
mechanism,
so
we
write
a
controller.
The
controller
understands
only
one
thing
and
it
doesn't
have
to
understand
the
rest
of
the
system.
It
just
treats
the
rest
of
the
system
as
as
a
black
box,
and
it
just
tries
to
drive
this
one
thing
into
the
correct
state.
A
A
Why
is
it?
Why
is
it
difficult
in
other
API
systems
is
maybe
a
better
question.
We
have
this.
We
have
this
concept
in
the
kubernetes
api
system
that
you
manage
your
resources
declaratively.
So
we
have
this
this.
This
command
Q
control
apply
right
now
it
lets
you
decide
which
parts
of
your
resource
you
want
to
manage,
and
you
just
don't
mention
the
rest
of
them
and
there
are
free
for
the
controllers
in
the
system
to
manage
them
for
you.
A
A
We
can't
have
it
such
that
when
you
change
the
image
you
accidentally
blow
away
the
replicas
field,
that's
no
good,
so
so
it
has
to
work
for
both
controllers
and
humans.
So
there's
a
nice
side
effect.
If
you
remember
this,
this
slide,
which
is
if
you're
human
apply,
is
sort
of
a
basically
a
do
what
I
mean
command
and
if
you're,
just
tweaking
things
in
the
system,
you
basically
only
have
to
learn
one
operation,
which
is
even
nicer,
so
yeah,
here's,
my
here's,
my
here's,
my
diagram,
q
control,
apply.
A
So
why
will
you
see
api's
following
the
kubernetes
resource
model
in
the
future?
I
think
it's
because
a
lot
of
real
word
systems
are
a
good
fit
for
the
goober
90s
resource
model.
I
can
imagine
many
virtual
resources,
like
you
know,
of
course,
the
objects
in
the
kubernetes
system,
which
is
the
reason
why
the
API
system
exists.
In
the
first
place,
virtual
machines
load,
balancers
database,
endpoints
service
meshes
yeah,
anything
you
can
imagine
kubernetes
clusters
I
can
imagine
managing
physical
resources.
This
way
network
switches
routers.
A
A
It's
just
not
humanly
possible.
I
mean
if
you've
got
if
you're,
if
you're,
if
your
state
chart
has
like
500
spots
in
it,
and
you
add
a
new
state
to
the
system-
that's
500
places
you
have
to
go
audit
for
for
bugs,
because
you've
you've
changed
the
the
meaning
of
the
system,
which
is
what
I
just
said.
So
the
kubernetes
resource
model
allows
you
to
effectively
manage
the
complexity
of
your
API
ecosystem.
I
think.
That
is
why
you
will
encounter
these
api's
in
the
future.
A
B
Actually,
I
fully
agree
with
you:
I,
like
the
Kabbalists
model,
so
I'm
wondering
the
same
other
Google
products
open
source
products
coming
up
that
actually
follow
your
advice,
or
is
it
more
like
you
would
ask
to
follow
your
advice
so
that
we
can
then
explain
it
Google
that
others
are
doing
it
already.
I.
A
A
So
I
hope
to
I
have
to
say
it's
a
little
hard
to
use
our
system
right.
Now,
it's
a
little
hard
to
to
write
new
api's,
so
I
really
hope
in
the
coming
months
to
work
on
that
I'm
working
on
making
apply
general
and
usable
for
everybody
right
now,
and
the
next
step
for
me
after
that
is
to
make
the
control
plane
really
a
standalone
product.
A
D
I'd
like
to
follow
up
on
that
I'm
actually
doing
this
I'm
building
a
control
plane
for
a
traditional
ILS
system
using
this
kind
of
technology
using
aggregated
API
servers
with
you
know,
types
built
in
I
think
it's
working
pretty
well.
There
was
a
project
mentioned
at
the
previous
coop
con
about
a
generator
for
API
servers.
I
haven't
heard
anything
about
that
since
then.
What's
the
status
on
that.
A
I've
been
heads
down
on
apply,
so
I
haven't,
dug
into
it
too
much
yet,
but
yeah
I
really
planned
to
make
like
just
even
if
we
were
doing
it
just
for
ourselves.
We
would
have
to
do
this
work,
but
I
really
plan
to
make
the
the
the
whole
lifecycle
building
an
API
convenient
for
a
developer.
You
know
like
right
now
we
have
these
types
go
files.
A
You
declare
your
API
types
with
specially
crafted
go
structs,
so
yeah
I
want
to
make
this
into
a
real,
a
real
language
and
and
we're
starting
that
as
part
of
the
apply
changes
but
yeah
I
expect
a
I
have
grand
visions
of
like
a
pathway
that
you
you
write
this
you
get
a
CR
D.
If
you
want
to
use
a
C
or
D
or
you
get
the
generators
and
stuff.
If
you
want
to
make
a
aggregated
API
server,
yeah.
A
Hey
thanks
for
the
talk
I.
Do
you
want
to
talk
about
sub
resources?
I
didn't
hear
that
at
all
yeah
sure,
so
in
the
kubernetes
style,
there's
there's
sort
of
two
uses
for
sub
resources
and
if
you've
seen
our
HTTP
paths,
you've
got
like
a
namespace
and
a
resource
and
like
the
name
of
the
resource,
and
then
sometimes
after
that,
you'll
see
another
word,
which
is
a
sub
resource
and
so
there's
two
reasons
for
a
sub
resource
to
exist.
A
The
the
the
first.
What
reason
the
good
reason
for
our
sub
resource
to
exists
is
that
it
enables
polymorphism.
So
we
have
this
concept
of
a
scale
resource,
so
we
could
teach
the
horizontal
pot
Alice
autoscaler
to
apply
to
everything
that
or
patch
everything
that
has
a
scale
which
we
great,
but
some
people
don't
call
the
relevant
field
replicas.
So
instead,
we've
we've
made
this
polymorphic
resource
that
sort
of
converts
the
relevant
field,
which
is
like
a
replica
count
and
a
selector
I
think
into
a
standardized
format.
A
So
HPA
can
now
work
against
anything
that
has
a
scale
sub
resource
so
that
that's
like
the
first.
That's
like
the
first
and
good
reason
for
sub
resource
to
exist.
The
second
and
less
good
reason
for
a
sub
resource
to
exist
is
that
it's
a
way
to
break
the
glass.
So
you
can.
You
can
use
this
like,
like
our
pods
support,
the
exec
option,
like
there's.
B
A
Good
there's
no
good
way
to
phrase
that
in
a
in
a
declarative
format,
so
we
have
a
sub
resource.
You
can
do
whatever
you
want
with
it.
It's
a
it's
a
break,
the
glass
in
case
of
emergency.
So
we
have
a
few
things
like
that,
but
the
those
things
are
you
can't
really
reuse
them
with
machines
like,
like
you,
gotta
understand
each
one
independently.
There's
no
generic
way
to
make
that
to
make
that
work.
I.
E
Was
wondering
if
you
could
say
something
about
like
imperative
operations
in
the
kubernetes
resource
model,
because,
like
sometimes
you
want
to
do
something?
That's
like
really
boils
down
to
a
command
like
you
wanted.
You
have
a
sed
operator,
for
example,
and
you
want
to
say,
take
a
backup,
and
so
I
was
wondering
like
what
people
are
doing
today
to
express
in
operations
that
are
kind
of
fundamentally
imperative,
using
the
declarative,
modeling
kubernetes
uses.
A
Yeah,
that's
a
great
question,
so
there's
there's
multiple
ways
that
you
can
approach
this
and
some
of
them
are
good
and
some
of
them
are
not
so
good
you
you
can.
You
can
have
like
and
I've
seen.
People
do
this
and
it's
not
really
pretty.
You
can
have
like
a
you've
got
a
declarative
operation
like
open,
open
the
doors
and
you
phrase
that
in
a
declarative,
operate
a
declarative
object
as
like
open
the
doors
equals
false
or
true.
That's
not
really
a
good
way
to
do
it.
A
That's
actually
doing
the
backups
to
do
the
back
of
it
and
an
increment,
its
corresponding
count
in
the
status,
so
that
that's
that's,
maybe
one
way,
that's
a
little
bit
better
and
in
the
worst
case,
I
honestly
probably
would
prefer
to
see
a
sub
resource
over
a
like
shoehorning,
a
fundamentally
imperative
operation
into
a
declarative
data
format.
If
that
makes
sense,
Thanks
use
the
mic.
D
Taking
a
backup
is
a
relatively
easy
one
right,
because
you
can
say
make
me
a
backup
that
is
a
backup
of
that.
It's
more
like
this
exact
thing
is
I
think
are
a
little
harder
on
the
ration
they
make
it
look.
Just
like
you
can
say,
make
me
a
new
pod.
You
can
say,
make
me
a
new
backup
and
by
the
way
the
spec
of
this
backup
says
it's
a
backup
of
that
yeah.
A
That's
that's
a
great
point.
That's
another
way
to
to
solve.
The
problem
just
is
to
like
model
the
operation
itself
as
an
entire
object,
and
then
you
get
you
get
the
whole
lifecycle
there.
You
create
a
backup
object,
and
you
know
this
is
the
thing
and
then
you
wait
for
the
status
operation
to
get
filled
in
that's
this.
That's
that's
another
way
to
model
it.
C
A
That
is
actually
like.
There's
a
there's
technical
reasons
like
we
wanted
to
reduce
the
contention
on
a
resource.
If
you're
a
controller
writing
status,
you
don't
want
to
be
you
don't
want
to
have
a
bunch
of
optimistic
concurrency,
locking
a
conflicts,
because
somebody
else
is
updating
the
spec
and
actually,
actually
the
problem
happens.
More
often,
the
other
way
like
you're
trying
to
update
the
spec
and
you
keep
getting
beaten
by
a
controller
which
is
updating
status
like
continuously,
so
we
split
them
into
into
separate
resources.