►
From YouTube: Deep Dive: Cluster Lifecycle SIG (Cluster API) - Robert Bailey, Google & David E. Watson, Samsung
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: Cluster Lifecycle SIG (Cluster API) - Robert Bailey, Google & David E. Watson, Samsung
The Cluster Lifecycle SIG is the Special Interest Group that is responsible for building the user experience for deploying and upgrading Kubernetes clusters. Our mission is examining how we should change Kubernetes to make it easier to operate. In this deep dive, we will examine how the Cluster API simplifies the cluster management experience for cluster operators by enabling consistent machine management across environments, and bringing declarative upgrades to Kubernetes clusters.
To learn more: https://sched.co/Greh
A
All
right
welcome,
it's
2:35
I
think
we
should
go
ahead
and
get
started.
We
are
here
today
to
do
a
deep
dive
for
sig
cluster
life
cycle
into
the
cluster
API
sub
project.
Hopefully
everybody
in
the
audience
is
in
the
right
room.
If
not,
we
won't
feel
offended
if
you
don't
get
up
and
and
take
off
at
this
point,
make
sure
you
at
the
right
talk
to
introduce
ourselves.
I
am
Robert
Bailey
I
work
at
Google,
I've
worked
on
state
cluster
lifecycle,
for
maybe
three
or
four
years
now
before
it
was
actually
a
sig.
A
B
B
Okay,
so
the
agenda
for
today
is
first
we're
gonna
set
up
the
motivation
for
why
we're
doing
the
cluster
API
project.
Next,
we're
gonna
go
over
some
logistical
challenges
in
terms
of
how
do
you
set
up
your
first
cluster
with
cluster
API?
If
you
don't
have
a
cluster?
Finally,
we're
going
to
dig
into
the
API
definition
again.
This
is
a
deep
dive,
so
we're
targeting
this
towards
developers.
We
want
to
make
sure
that
when
you
leave,
you
understand
what
we're
doing
and
how
you
can
jump
in
and
get
involved
if
you're
interested.
A
So
last
year,
at
cube
con
in
Austin
Kristin,
when
I
got
up
and
sort
of
introduced
a
cluster,
a
pet
project,
and
we
spent
a
good
amount
of
time
for
that
presentation,
sort
of
setting
the
stage
and
giving
them
motivation,
but
for
people
that
weren't
there
haven't
watched
a
recording
or
knew
they're
here
to
find
out
what
we're
doing.
We
don't
want
to
sort
of
allied
over
that
and
just
jump
jump
right
into
the
details.
So
we
do
want
to
talk
a
little
bit
about
why
we're
here
and
what
we're
doing
so.
A
The
first
point
is
that
cluster
management
and
kubernetes
is
difficult.
This
is
sort
of
been
knock
on
communities
since
the
early
days.
It's
gotten
a
lot
easier,
since
there
are
the
days
I,
don't
know
if
how
many
you've
been
working
on
career
days
for
more
than
like
two
or
three
years,
but
it
used
to
be
really
really
hard
to
get
your
cluster
up
and
running,
and
people
still
did
it
right.
People
fought
through
the
difficulty
because
the
promise
of
once
it
was
up
and
running
what
it
delivered
to
you
was
so
valuable.
A
So
cluster
life
cycles,
part
of
their
Charter,
is
to
make
that
process
really
easy.
Make
it
really
easy
to
get
up
and
running.
I
know.
A
number
of
you
guys
were
in
the
previous
talk
in
this
room
about
cube
a
DM
cube.
A
DM
is
part
of
what
our
sig
has
been
working
on.
Some
get
easy
up
and
running
a
cube
ad
I'm
only
solves
a
part
of
the
problem,
and
that's
actually
intentional.
A
Our
sig
is
really
focused
on
building
tools
that
solve
pieces
of
the
problem
and
not
trying
to
build
a
one
solution
fits
all
tool
because
we
don't
believe
that
that
will
actually
have
traction
in
the
community,
because
everybody's
needs
are
so
different,
but
cluster
management
is
really
difficult
right.
So
one
of
the
pieces,
that's
difficult
is
clustering,
so
we
have
cube
ATM
for
that
piece
and
another
piece:
that's
really
difficult
is
managing
infrastructure
all
right.
A
B
Currently,
the
tooling
and
ecosystem
is
fragmented.
I
was
looking
this
weekend
at
the
kubernetes
documentation
and
there
are
over
75
ways
linked
from
the
official
documentation
to
deploy
kubernetes
I've
seen
lists
in
the
wild
of
over
a
hundred
different
deployment
tools.
So,
to
put
that
in
perspective,
I'd
say:
there's
roughly
a
hundred
people
here,
maybe
a
little
more.
That
means
one
of
two
things:
either
someone
here
has
never
written
deployment
tool,
or
one
of
you
has
written
at
least
two
of
them.
A
And
and
finally,
another
piece
of
our
motivation
is
we
really
want
to
be
able
to
start
enabling
the
community
to
build
higher-level
tooling
on
top
of
their
clusters?
One
problem
with
fragmentation:
is
you
can't
take
a
tool,
that's
meant
to
manage
clusters
and
use
it
anywhere
outside
of
your
same
small
ecosystem
right.
So,
if
you
are
a
user
of
cops,
you
might
write
a
tool
that
works
with
cops
to
manage
your
cops
clusters.
But
then
what
happens?
A
If
cops
doesn't
support
environment
you
want
to
use
and
now
you're,
using
cube
spray
and
I
need
to
use
queue
straight,
manage
clusters.
How
do
you
make
a
tool,
as
can
over
with
both
a
great
example?
This
is
the
cluster
autoscaler.
The
cluster
autoscaler
has
sort
of
a
cloud
plugin
interface,
so
they
can
work
with
different
underlying
infrastructures.
A
One
of
the
goals
of
the
machines
API
that
we'll
get
to
later
is
to
make
it
so
the
cluster
autoscaler
can
target
a
single
API
and
let
us
abstract
away
the
underlying
infrastructure
in
a
way
that
adding
support
to
the
cluster
API
for
new
environments
sort
of
gives
you
an
auto
scaler
for
free.
We
believe
if
there
are
other
tools
like
the
autoscaler,
that
will
benefit
from
having
some
consistent
api's
on
which
to
deal
with
how
we
manage
clusters.
A
Another
use
case
is
hybrid
cloud,
so
I
mentioned
with
the
cops
and
cubes,
for
example,
earlier
where
you
know
maybe
cops
as
it
support
new
environments,
but
even
if
it
does
support
new
environment,
we
want
to
have
consistent
ways
to
manage
your
clusters
across.
You
know
if
your
company
is
around
Amazon
and
Google
and
Microsoft,
how
do
you
interact
with
your
clusters?
A
There
are
definitely
a
lot
of
companies
that
are
trying
to
help
solve
this
problem,
but
we
think
that
managing
your
cluster
itself
managing
the
infrastructure
is
something
that
the
community
should
step
in
and
provide
some
guidance
to
the
users
of
kubernetes
on
how
best
to
do
that.
And
finally,
we
want
to
sort
of
help
manage
the
control
plane
of
a
cluster
right
and
so
cube.
A
Atm
is
really
great
at
doing
this
sort
of
on
a
single
machine
and
helping
orchestrate
the
process
of
managing
and
control
plane
and
manage
those
upgrades
across
multiple
machines
and
across
multiple
clusters
is
some
value.
We
think
the
cluster
API
can
bring.
So
what
is
the
cluster
API?
So
that's
probably
a
good
question.
A
If
you
guys
are
here-
and
you
aren't
involved
in
the
project,
you
might
want
to
know
like
what
it
is,
and
so
we've
been
sort
of
beating
around
the
bush
with
the
motivations
and
how
are
we
solving
this
problem
so,
first
and
foremost,
is
the
cluster.
Api
is
a
declarative
API
prior
to
the
cluster
API,
the
kubernetes
ecosystem
didn't
really
have
a
way
to
represent
the
cluster
or
machines
inside
of
kubernetes
itself.
There
was
some
early
attempts,
I
know
just
in
Santa
Barbara
and
pull
requests,
trying
to
add
machine
definition
to
core
kubernetes.
A
A
couple
of
years
ago,
I
was
rejected
as
being
out
of
scope.
So
what
we've
done
is
we
sort
of
stepped
outside
of
quorum,
readies
and
said
even
if
it's
not
part
of
core
kubernetes
we'd,
like
the
ecosystem,
to
have
a
consistent
way
using
kubernetes
native
primitives
to
be
able
to
represent
clusters,
control
planes,
configuration
and
machines
that
all
sort
of
come
together
and
make
up
your
cluster?
On
top
of
that,
there's
a
lot
of
common
logic
that
we
can
apply
across
different
environments
right.
A
We
really
think
it's
important
to
have
a
pluggable
architecture.
So
while
we
do
want
to
provide
common
logic
to
solve
these,
these
use
cases
for
people,
it's
it's
not
gonna,
be
a
one-size-fits-all
problem,
so
one
place,
it's
really
important.
To
have
a
pluggable
architecture.
Is
that
the
the
level
where
we
interact
with
the
infrastructure?
A
So
we
have
a
provider
abstraction
where
you
can
plug
in
support
for
new
cloud
providers
relatively
easily,
but
on
top
of
that,
each
of
the
API
is
has
controllers
that
implement
those
API
s
and
you
can
replace
those
controllers
if
you
need
to
if
the
default
controllers
don't
actually
satisfy
your
these
cases.
And
finally,
as
I
mentioned
previously,
we
really
want
to
be
able
to
enable
common
tooling
across
many
different
environments.
A
So
if
this
intrigues
you
and
you
want
to
sort
of
get
started,
we're
gonna
do
sort
of
a
quick
walkthrough
but
like
what
it
means
to
sort
of
get
up
and
running,
and
this
is
sort
of
walking
through
the
bootstrapping
workflow
using
the
cluster
cuddle
command,
which
is
part
of
the
open
source
repository.
So
what
the
command
does
is
a
user
runs,
runs
a
CLI
tool
and
says
create
a
cluster,
so
great
we're
gonna
pretty
cluster.
A
The
first
thing
that
we
need
to
create
a
cluster
is
a
cluster
right,
so
we
have
this
problem
where
we
need
a
cluster
to
create
a
cluster.
Luckily,
we
have
something
called
mini
cube
which
runs
great
on
your
laptop
and
provides
a
local
cluster
environment
without
needing
to
do
a
lot
of
work.
Configuring
it
so
by
default,
we'll
create
a
mini,
cube,
+,
ER
and
that
cluster
will
come
with
a
control
Blaine.
On
top
of
that
control
plane,
we
will
launch
a
couple
of
controllers,
will
launch
a
machine
controller
and
a
cluster
controller.
A
We
then
install
some
custom
resource
definitions
to
define
what
machines
you
want
to
create
and
what
your
cluster
should
look
like.
The
two
controllers
will
then
take
those
definitions
and
create
the
target
cluster
for
you.
So
this
is
where
we're
actually
gonna
reach
out.
You
know
to
the
environment
of
your
choice,
whether
that's
Google
or
Amazon
or
vSphere,
and
we're
gonna
go
and
actually
instantiate
resources
in
that
provider,
and
then
at
this
point
we
have
a
decision
to
make
to
pivot
or
not
to
pivot
right.
A
So
we
have
sort
of
two
modes
of
operation
for
our
bootstrapping,
the
first
mode
that
we've
built
is
pivoting
which
I'm
going
to
walk
through
and
if
we
decide
not
to
pivot,
that
last
slide,
I
showed
is
actually
where
we
stop.
We
leave
you
with
the
bootstrapping
cluster
in
place
and
the
target
Buster,
and
that
works
great.
If
you
have
an
existing
bootstrap
cluster
that
you're
using
to
create
new
clusters,
if
you're
using
sort
of
the
mini
cube
example,
you
probably
want
to
pivot,
because
you're
gonna
close
your
laptop
you're
gonna,
walk
away.
A
You're
gonna
lose
your
network
connection
and
the
cluster
is
no
longer
going
to
be
sort
of
actively
maintained.
Let's
say
that
we
do
want
to
pivot.
What
does
that
look
like?
Well,
the
first
thing
we
do
is
we
copy
the
custom
resource
definitions
from
the
bootstrapping
cluster
into
the
target
cluster,
and
the
next
thing
we
do
is
we
start
running
controllers
in
the
tart
cluster.
So,
if
you're,
if
you're
looking
at
this
sort
of
keenly,
you
might
notice
that
at
this
point
we
are
running
controllers
both
in
the
bootstrapping
cluster
and
the
target
cluster.
A
At
the
same
time,
which
doesn't
really
seem
like
a
great
idea
and
actually
when
we're
putting
these
slides
till
yesterday,
I
thought
we
killed
the
bootstrapping
cluster
bootstrapping
controllers
first
and
looking
at
the
code,
we
don't
so
that's
something.
We
hope
we
will
fix
and
make
this
a
little
bit
better.
The
time
frame
when
twenties
overlap
is
relatively
small,
so
we
don't
anticipate
there
being
too
many
problems
to
them
fighting.
A
But
at
this
point
we
do
have
two
different
places:
that's
a
source
of
truth
and
two
different
rollers
acting
on
those
two
different
places,
so
you
could
end
up
with
the
controllers
fighting
for
a
little
while,
but
pretty
quickly.
We
go
ahead
and
we
destroy
the
bootstrap
cluster
by
deleting
mini
cube
and
that
will
delete
the
controllers
and
delete
the
custom
resource
definitions
and
you're
left
with
your
target
cluster,
which,
at
this
point,
is
running
on
your
target
environment
and
it's
sort
of
self
managing.
B
B
B
There
is
an
in
the
status.
We
have
something
we
have
the
API
endpoint
field,
so
one
of
the
things
that
we've
been
working
on
as
we
work
towards
a
beta
is
initially
we
wanted
to
be
extremely
inclusive
so
that,
as
many
different
providers
could
use
an
experiment
with
this
framework,
as
we
move
towards
beta
I
would
think
it's
important
to
start
solidifying
and
codifying
the
semantics
of
these
different
fields.
B
B
So
on
this
slide,
it
also
says
that
providers
could
hook
in
where
specifically
needed.
So
one
thing
to
understand
about
how
the
code
is
structured
is
that
there
is
a
shared
controller
for
each
one
of
these
see
RDS
and
some
of
the
controllers
have
provider.
Specific
actuators,
which
can
be
plugged
in
the
shared
controller,
helps
provide
that
uniform
semantics
interface,
but
the
provider
specific
actuators
allow
it
to
be
customized
for
different
environments.
So
moving
along,
we
have
the
Machine
CRD
machines.
Our
D
has
configuration,
which
is
specific
to
a
given
machine.
B
That
includes
Cooper
days
version
information
and
providers
are
responsible
for
defining
how
that
machine
is
created.
What
it
looks
like
what
is
the
CPU
memory
and
disk
resources
that
it
is
created
with?
Next?
We
have
a
machine
set,
so
a
machine
set
is
a
homogeneous
configuration
of
machines
right,
you
have
a
template
or
the
machine
CRD,
and
the
idea
is
that
a
machine
set
it's
a
generic
controller.
B
B
So
one
of
the
going
back
to
the
motivations
we
we
feel
that
the
currents
the
ecosystem
is
complicated
and
fragmented.
One
of
the
things
that
makes
a
system
easier
to
use
is
familiarity.
So
we
just
want
to
point
out
the
analogy
that
exists
between
machines,
machine
sets
and
machine
employments.
They
are
directly
related
to
the
relationship
between
pods
replicas
sets
and
deployments.
B
So
earlier,
I
talked
about
the
distinction
between
the
actuator
provider-specific
code
and
the
generic
code,
the
common
code.
So
the
writer
specific
code
has
access
to
provider
specific
data,
the
provider.
Spec
is
the
specification
for
the
provider.
The
providers
are
expected
to
maintain
their
own
version,
II
of
the
spec
and
it's
opaque.
In
the
perspective
of
the
common
code.
B
One
of
the
difficulties
that
you
notice,
when
you
configure
each
machine
is
that
it
becomes
tedious
and
redundant.
You
don't
generally
want
every
machine
to
be
different.
In
fact,
it's
usually
the
case
that
you'd
like
them
to
be
relatively
homogeneous.
So
we've
created
a
mechanism
that
allows
you
to
share
provider
specs,
and
so
so
here's
the
provider
spec
embedded
in
machine,
and
this
is
a
machine
class.
So
a
machine
can
point
to
provider
spec
or
it
can
point
to
a
rider
spec
source,
one
of
which
is
a
machine
class.
B
B
They
could
be
hosted
solutions,
they
could
be
non
hosted
solutions,
so
the
general
broad
category
of
all
of
the
infrastructure
that
runs
kubernetes
now
within
a
given
environment
or
yeah
we're
gonna
give
an
environment.
We
have
put
the
potential
for
one
or
more
variants.
So,
for
instance,
we
have
a
repository
named
cluster
API
provider
AWS,
and
that
is
the
six
sponsored
repo
for
AWS
implementations
right
now.
It
has
an
implementation
which
is
targeted
towards
ec2
and
in
the
future
we
believe
it
will
have
an
implementation
for
eks.
B
So
again
we're
using
CR
DS.
This
makes
it
extremely
easy
to
create
a
new
provider
you
can
see
in
the
right-hand
column.
These
are
the
commands
that
you
can
run
in
order
to
generate
a
new
compress.
The
types
that
you're
defining
are
the
spec
and
the
status
or
the
cluster
object,
and
then
again,
the
spec
and
the
status
for
the
machine
object
once
you've
defined
the
various
types
you
need
to
register
their
schemes.
B
B
We
also
currently
have
two
additional
functions
which
we
intend
to
get
rid
of
at
some
point,
so
API
again
cuckoo
big.
Are
there
as
a
convenience
right
now,
but
eventually
will
be
deprecated
once
you've
defined
or
actuators
that
you
need
to
register
the
controllers.
Remember
we
built
this
using
coop
builder.
Coo
builder
knows
nothing
about
cluster
API,
so
all
of
the
core
common
customer
cluster
API
types
must
be
registered
with
the
controller
and
then
the
controller.
B
So
this
is
this
here
is
a
small
change
to
the
make
file
generated
by
goo
builder,
and
all
that
attempts
to
do
is
put
all
of
the
CR
DS
and
other
manifest
in
a
single
file,
so
that
deploying
the
cluster
API
with
the
provider.
Specific
components
can
be
as
simple
as
well.
First,
we
build
the
images,
but
it
can
be
as
simple
as
cou
I
mean
it
keeps
tart
baked
deploy
and
at
the
end,
you
should
have
a
cluster
with
cluster
API
running.
C
A
A
So
right
now
we
mentioned
it
we're
still
in
alpha
we're
still
making
braking
API
changes.
So
one
of
the
nice
things
about
being
an
alpha
is:
we
can
do
a
rapid
iteration
of
both
the
API
and
the
code
without
having
to
worry
about
supporting
innings
users.
So
that's
pretty
liberating,
but
at
some
point
we
actually
do
need
to
start
delivering
some
some
value
and
be
able
to
run
things
in
production
and
sort
of
prove
out
the
system
so
we're
targeting
beta
later
this
year,
so
that
we
can
actually
start
doing
that.
A
So
existing
systems
like
OpenShift
and
cops
are
looking
to
start
adopting
parts
of
the
API
and
I
think
they
would
really
prefer
if
those
parts
of
the
API
were
stable,
so
we're
shooting
for
that.
As
soon
as
we
can,
another
thing
we've
started
working
on
is
multi-master,
so
we
had
a
lovely
conversation
yesterday
that
the
Jason
set
up
for
us
to
talk
about
highly
available
deployments
for
with
the
cluster
API,
which
is
often
conflated
with
multi-master,
but
really
what
people
want
is
they
want
to
be
able
to
run
multiple?
A
B
So
some
other
areas
that
we're
focused
on
include
bare
metal
bare
metal
is
one
of
the
final
frontiers
of
kubernetes
deployment.
It's
very
difficult
because
of
how
varied
the
infrastructure
tends
to
be.
One
of
the
things
we'd
like
to
do
is
look
into
creating
a
generic
controller
that
uses
web
hooks
to
allocate
infrastructure.
This
might
be
a
way
to
help
people
target
different,
bare
metal
environments
without
having
to
have
a
proliferation
of
perhaps
dozens
or
more
different,
bare
metal
providers.
B
Another
thing,
that's
extremely
important,
is
documentation
right
now
we
have
a
fair
amount
of
documentation
for
developers.
It
still
needs
a
lot
of
work,
so
we
welcome
feedback
and
contributions
in
that
area,
but
eventually
I
would
like
the
documentation
to
target
not
just
developers
but
end
users
and
then
infrastructure
engineers.
So
there's
a
range
of
people
for
whom
closed
API
is
targeted
and
we
would
like
the
best
documentation.
We
can
have.
B
Finally
we're
going
to
be
looking
at
there's
a
seda
TM
project,
which
we
don't
know,
I,
don't
know
a
lot
about
it's
a
new
project,
but
it
aims
to
simplify
at
CD
Management.
In
the
same
way,
the
cuvette
TM
supplies
kubernetes
configuration
and
it
has
the
potential
to
simplify
the
deployment
of
clusters,
so
we're
looking
at
incorporating
that
into
some
of
the
provisioning
tools,
we're
looking
at
Adams
add-ons
as
operators.
So
there's
some
basic
infrastructure
like
DNS.
A
Great,
so
one
of
the
things
that
we
mentioned
is
hopefully
some
or
many
of
you
are
here,
because
you're
interested
getting
involved
in
the
project
and
I
want
to
make
sure
people
understand
that
getting
involved
doesn't
mean
writing
code
right,
there's
a
lot
of
ways
that
you
can
help
contribute
to
the
community.
They're
really
impactful,
with
that
how
to
write
code
now,
don't
get
me
wrong
if
you
are
able
to
write
code
and
want
to
send
s
code,
we
would
love
that
as
well.
A
We
have
multiple
audiences
that
we
want
this
documentation
to
reach
many
of
you
probably
fit
into
one
of
those
audiences,
and
so
even
if
you're
reviewing
the
documentation
filing
issues
against
the
documentation,
standing
small
changes,
the
documentation,
those
are
huge
contributions
to
the
project,
helping
us
sort
of
improve
the
documentation
for
the
next
round
of
people
that
show
up
similarly,
I
think
across
the
curators
community.
We
sort
of
have
a
lack
of
people
that
are
focused
on
helping
with
project
management.
A
Things
like
helping
with
issue
backlog,
triage,
helping
running
meetings,
helping
organize
people,
you
know
helping
keeping
people
on
track,
setting
goals,
setting
milestones
and
helping
sort
of
projects
move
forward
in
a
consistent
fashion
in
the
humans
ecosystem.
This
is
really
difficult
because
a
lot
of
the
players
come
from
many
different
companies
and
have
lots
of
other
priorities
other
than
just
helping
the
open
source
project
advance.
Other
things
like
helping
cut
releases,
building,
release
infrastructure
we
mentioned
during
a
cig,
call
recently
that
we
want
to
set
up
some
more
project.
A
A
Good
first
issues
are
ones
that
are
sort
of
much
smaller
issues
that
are
targeted
people
that
maybe
don't
have
the
depth
of
expertise.
Sometimes
the
things
that
are
labeled
it
Help
Wanted,
are
huge
sweeping
changes
to
the
system
that
are
hard
to
come
in
on
on
day,
one
and
start
changing,
but
good
first
issues
are
really
supposed
to
be
targeted
at
small
changes.
You
don't
need
to
have
a
lot
of
domain
expertise
to
make.
And,
lastly,
you
know
we
have
a
number
of
providers
that
have
been
built
so
far.
A
You
know:
we've
got
providers
for
most
of
the
major
clouds.
I
was
really
excited
to
see
that
right
around
the
time
that
Keep
Calm
China
was
happening.
Two
of
the
the
large
cloud
providers
in
China
submitted
their
implementations
for
about
ten
seven
Baidu.
So
if
there
is
an
environment
that
you're
particularly
excited
about
that,
maybe
you
use
on
your
day
to
day
for
work.
You
know
join
that
that
sort
of
sub
project
of
the
sub
project-
and
you
know,
help
make
that
environment
better.
A
If
there's
an
environment
that
doesn't
exist
yet
that
you
need
we're
also,
you
know
looking
for
people
to
contribute
support
for
new
environments
as
well,
I
think
over
time,
the
number
of
new
environments
we
want
to
support.
We
expect
to
shrink,
as
we
start
to
cover
a
lot
of
the
large
ones.
I
think
the
big
gap,
as
mentioned
earlier
was
was
bare
metal
because
the
environments
are
just
so
different
and
if
you're
looking
for
sort
of
more
particulars
on
how
to
get
a
hold
of
us,
this
top
link
is
linked
to
our
github
repo.
A
We've
got
to
read
me
there.
It
has
a
lot
of
the
restless'
information,
but
it's
you
know
what
mailing
lists
Ron.
We
use
the
mammoth
somewhat
sparsely
mentioned
during
our
cig
intro
a
couple
days
ago
that
there
are
over
550
people
on
this
mailing
list,
and
you
know,
cyclical
life
cycles
are
really
large,
say
with
a
lot
of
different
interests,
and
so
we
try
not
to
but
too
many
things
specific
to
sub-projects
on
to
the
mailing
list,
but
it's
a
great
way
to
find
out
about
cross-cutting
and
things
that
are
happening.
A
So
we
mentioned
during
the
previous
slide
things
like
the
add-ons
as
operators
and
at
CD
admin.
These
are
projects
that
are
starting
in
a
cig
that
we'd
like
to
adopt
across
the
saiga
sort
of
horizontal
efforts,
and
so
this
mailing.
This
is
where
you'd
start
to
hear
about
things
like
that.
There's
a
biweekly
meeting
for
the
overall
State
cluster
life
cycle,
but
there's
also
a
weekly
meeting.
A
That's
a
breakout
for
this
project
specifically,
and
we
come
together
for
about
an
hour
every
week
and
we
talk
usually
and
sort
of
pretty
great
technical
depth
about
different
design
decisions,
I'm
hoping
over
the
next
couple
of
months.
We
can
really
use
those
meetings,
sort
of
in
sort
of
a
project
management
style
to
really
drive
us
towards
these
alpha
and
beta
releases
that
we've
been
targeting.
A
There
are
actually
two
other
meetings
that
we
had
every
week:
one
that's
in
a
European
friendly
time
and
one
that's
in
a
sort
of
u.s.
West
Coast
friendly
time
where
people
can
get
together
and
sort
of
talk
shop,
come
across
from
different
provider
implementations
and
talk
about
problems.
They're
facing
you
know
things
that
David
brought
up
about
how
we
use
different
fields
in
the
API
making
sure
those
are
consistent
across
providers.
A
These
are
just
other
times
that
people
can
get
together
and
sort
of
know
that
somebody
else
will
be
there
to
talk
to
to
ask
questions
to
and
to
work
together
with
yeah
we've
got
a
link
to
our
meeting
notes,
all
of
the
meetings
get
recorded
and
uploaded
to
our
YouTube
playlist.
So
if
you
can't
make
meetings,
you
know
I
think
that
many
times
I
might
be
difficult
for
people.
You
know
in
China
you
can
always
go
back
and
watch
the
meetings.
A
A
Great,
and
so
we
tried
to
keep
this
pretty
short
because
we
anticipated
you
guys
having
some
questions
and
this
being
sort
of
a
deep
dive,
a
part
of
the
maintainer
strap.
We
really
wanted
to
make
sure
there
was
sufficient
time
for
audience
participation,
so
I'm
going
to
cut
my
mic
enter
on
this
one
and
wander
around
the
room,
and
let
people
ask
questions.
D
A
Yeah,
so
that's
what
David
was
mentioning
earlier
about
machine
classes
are
sort
of
intended
to
fill
that
role,
so
the
machine
class
is
a
way
to
extract
the
provider
spec
from
a
machine
or
a
machine
set
such
that
when
you
create
a
machine
you
say
I
want
a
machine.
I
want
to
look
like
this
and
you
can
point
to
a
machine
class
and
those
machine
classes.
Can
you
don't
have
to
create
necessarily
like
they
can
be
pre-installed
by
the
set
up
infrastructure
based
on
your
environment?
A
So
I
could
imagine
like
if
I
want
to
create
a
cluster
on
Google
I
might
create
a
cluster,
and
a
controller
might
just
sort
of
inject
a
couple
of
machine
classes
with
your
sort
of
common
types
to
make.
It
really
easy
for
you
get
started,
creating
new
machines
and
then,
if
you
want
different
types,
you
can
create
your
own
machine
classes.
You
know,
use
custom,
VM
shapes
or
at
GPUs
or
any
sort
of
other
special
thing.
I,
don't
necessarily
see
us
having
a
single
one
of
those
CR
DS.
A
A
Who've
had
a
lot
of
experience,
trying
to
build
systems
like
that
in
the
past
and
pretty
much
all
of
them
have
failed,
and
so
we
didn't
wanna
go
down
that
where
we
want
to
still
expose
or
the
underlying
power
and
different
features
of
every
environment,
because
we
believe
that
each
of
them
does
have
something
unique
sort
of
to
offer.
And
we
don't
want
to
hide
that
from
you
to
the
point
where
it's
not
usable,
because
otherwise
people
won't
use
the
higher
level
abstraction.
C
Hey,
have
you
guys
considered
hardening
the
idea
of
a
master
machine
versus
a
worker
machine,
because
once
you
bring
in
that
concept,
I
feel
like
you
can
kind
of
communally
bring
in
some
of
the
management
of
say
the
control
plane,
like
AWS,
you
said,
was
managing
a
highly
available
control,
plane,
I.
Don't
there
was
any
thought,
that's
gone
that
or
maybe
it's
out
of
scope.
B
So
at
one
point
we
actually
did
specify
the
distinction
between
masters
and
worker
nodes.
We
removed
that
because
it's
actually
not
a
completely
generic
topic
or
a
neutral
topic.
For
instance,
you
have
hosted
providers
where
you
don't
get
to
specify
or
access
your
masters
and
then
you
have
no
listen
vironment
where
you
might
not
even
have
a
concept
of
a
node.
So
so
we
didn't
want
to
limit
the
applicability
of
the
cluster
API
by
doing
that,
yeah.
A
That
being
said,
I
think
that
most
providers,
these
days
do
have
a
machine
where
they
run
something
that
creates
a
master
and
their
machine.
That's
intended
to
be
a
worker
that
joints
that
master
right.
So,
if
you
look
at
the
the
AWS
provider,
the
the
script
that
initializes
machine
is
targeted
at
master
will
run
cube,
ATM
in
it,
create
and
configure
control
plane,
and
the
machines
that
run
knows
will
run
cube.
Atm,
join
and
join
that
to
create
your
cluster
right.
A
E
Noticed
when
you
were
talking
about
the
machine
classes
that
had
the
provider
config
in
it
and
I
had
a
lot
of
different
things
in
there,
like
a
number
of
like
number
of
CPUs
amount
of
RAM
and
all
that,
but
it
also
seemed
to
have
locations
like
I
needed
in
US.
Central
1/2
and
I
was
wondering
if
there
was
some
composability
to
be
had
there
to
prevent.
The
exponential
explosion
of
like
I
need
an
n1
standard
to
in
this
zone
versus
this
all
like
they're,
all
very
similar,
just
different
locations.
A
A
Things
in
a
storage
class
to
make
them
more
specialized,
we
haven't
quite
figured
out
the
right
way
to
do
that.
That
gives
a
good
user
experience.
I.
Think
right
now,
you're
gonna
end
up
with
an
explosion
of
machine
classes
to
cover
each
of
your
different
sort
of
zones
or
regions
or
machine
types
right.
But
you
know
the
my
initial
cut
out.
What
machine
classes
should
look
like
was
like
templatized
and
parameterised,
and
it
was.
G
So
this
is
the
machine
class.
Is
there
also
a
cluster
class
and,
like
I,
keep
drawing
the
parallel
to
storage
class?
There's
a
default
storage
class?
Could
you
then
have
a
default
clustered
class
and
then
just
generically
everybody's
Kubb
cluster,
whatever
their
back-end
default
cluster
classes
could
just
use
some
CRD
and
say
just
give
me
a
cluster,
never
mind
the
details.
A
That's
a
really
good
question:
we
haven't
really
explored
trying
to
pull
out
the
common
bits
of
cluster
into
a
class
yet,
but
maybe
that's
something
we'll
get
to
I.
Think
the
reason
that
it's
happened
for
machines
is
people
create
lots
of
machines
per
cluster,
and
so
you
start
to
see
the
pain
pretty
quickly.
A
A
A
A
Are
all
AWS
specific
concepts,
so
those
aren't
things
that
we
promoted
into
like
the
general
description
of
a
cluster,
but
they
would
be
if
you
looked
at
a
cluster
for
AWS,
be
in
the
cloud
provider,
specific
spec
for
an
AWS
cluster
and
then
the
cluster
specific
actuator,
that
we
showed
the
interface
for
there
when
you're.
Reconciling
that
cluster
would
be
responsible
for
creating
those
things
if
they're
needed
I.
H
B
So
for
things
they
make
sense,
I
think
that
would
be
a
good
idea.
I
do
agree
that
there
is
certain,
because
the
deployment
does
not
cover
the
cluster
object.
There
may
be
things
that
are
specified
at
the
cluster
level
in
the
provider
specific
way
it
may
not
be
immediately
or
we
don't
expose
at
the
deployment
level,
how
you
would
change
those
things,
but
the
provider
spec
is
available
for
both
so
for
providers
which
allow
those
cluster
fields
to
change
in
their
provider
specific
way,
they
could
account
for
it
in
their
actuator.
B
A
A
The
other
thing
that's
missing
right
now
from
the
cluster
spec,
is
sort
of
a
more
full-fledged
definition
of
what
the
control
plane
itself
looks
like.
So
what
comprises
your
control
plan,
like
obviously,
everybody's
gonna,
want
a
scheduler,
an
API
server
and
controller
manager.
But
do
you
want
a
cloud
controller
manager?
Do
you
want
an
ingress
controller?
A
So
we
see
a
lot
of
things
that
are
sort
of
coming
down
the
road,
in
our
sake
that
we
can
sort
of
pull
together
and
sort
of
like
piece
together
into
sort
of
a
single
system
that
we
think
will
will
look
a
little
a
little
bit
different,
probably
an
ear
from
that.
It
does
now
and
actually
sort
of
answer.
Some
of
these
questions
a
little
bit
better,
whether
those
will
be
separate,
C,
RDS
or
whether
they
sort
of
get
combined
I.
A
A
There's
an
argument
right
now
that
we're
having
about
you
know,
should
machines
be
usable
on
their
own
without
the
cluster
object
right,
which
I
think
is
a
use
case,
a
couple
people
have
come
up
with
and
if
they're
pieces
of
the
cluster
object
that
should
be
decomposed,
especially
if
they're
usable
on
their
own
or
they
should
be
used
with
machines
without
the
other
parts,
then
it
makes
sense
to
break
them.
Apart
saw
some
hands
on
this
side.
B
I
A
A
A
One
of
the
things
we
want
to
do
is
create
a
load
balancer
and
there's
already
code
to
create
a
load
balancer
that
implements
the
elf
for
a
service
controller
or
the
ingress
controller,
depending
what
type
of
load
balancer
you
want,
and
that
code
is
maintained
by
Signet,
working
and
I.
Don't
want
to
have
to
rewrite
and
maintain
my
own
code.
A
That
does
the
same
thing
right,
so
we
have
been
talking
with
with
the
folks
that
are
doing
that
extraction
and
figuring
out
if
we
can
sort
of
combine
forces
once
they're
ready,
but
so
far
they
haven't
quite
been
ready,
but
yeah
like
and
for
the
Google
specific
case.
I
know
that
the
the
networking
team
has
done
a
lot
of
work.
Writing
mocks
on
top
of
all
the
GCP
api's
and
we'd
love
to
not
have
to
redo
that.
B
So
we
we
have
an
open
ticket
right
now
to
look
at
how
to
integrate
the
cluster
API
with
the
cluster
registry
from
the
multi
cluster
project.
I
can
tell
you
that
multiple
companies
have
deployed
hybrid
stack
or
hybrid
cloud
environments
that
target
multiple
clouds
using
a
cluster
API
and
then
so.
The
final
piece
of
that
is
to
more
fully
integrate
into
the
multi
cluster
environment
by
using
things
like
cluster
registry
and
then
also
looking
at
schedulers,
that
can
schedule
across
clouds
based
on
lease
cost
or
other
performance,
reliability
requirements,
yeah.
A
That's
it's
not
as
useful,
because
they
can
say
here's
a
list
of
clusters,
but
I
have
no
idea
what
to
do
with
those.
And
if
you
list
clusters
that
you've
created
using
the
cluster
API,
it
also
lets
you
connect
to
them,
and
so
for
some
people,
that's
a
little
bit
more
useful.
But
we
also,
you
know,
want
to
make
sure
we've
sort
of
harmonized
across
the
ecosystem
with
the
other
SIG's
and
make
sure
we're
not
providing.
A
A
Not
quite
so,
the
biggest
problem
we
have
right
now
is
that
the
cluster
autoscaler
has
a
requirement
for
scaling
down
to
be
able
to
delete
a
specific
machine
so
the
way
they
implement
this
currently
is
they
talk
to
the
underlying
cloud
provider.
It's
like
on
Google,
they
say,
I
have
a
managed
instance
group.
They
tell
the
manager
to
this
group
scale
down
by
one
and
I.
A
Want
it
to
be
that
specific
one
which
is
supported
by
the
API
in
kubernetes
we've,
you
know,
sort
of
cloned
the
API
is
for
replica
set
and
deployments,
and
they
do
not
have
a
way
to
scale
down
by
specific
instances
right.
They
just
have
a
way
to
set
the
new
desired
size,
and
we've
talked
to
the
folks
from
cig
apps
about
whether
they
think
they
will
add
that
support
and
the
answer
so
far
has
been.
A
They
hope
they
will
not,
and
so
we're
trying
to
figure
out
how
we
want
to
add
that
support,
so
that
it
will
sort
of
feel.
As
a
native
to
kubernetes
as
possible,
there
been
a
number
of
different
sort
of
implementation
proposals
for
this
I
know
the
the
sa
P
folks
have
one
that
they've
got
working,
that
they've
offered
to
donate
and
we're
trying
to
figure
out
sort
of
what
the
the
right
user
experience
for
that
should
look
like
and
then
once
we
can
scale
down,
then
it
I
think
that's
one
of
the
biggest
hurdles.
A
E
A
We
don't
have
to
do
with
credentials,
we'll
assume
that
you
can
get
them
out
of
band
I
think
that
in
many
of
the
providers
today
sort
of
by
default,
you
can
find
those
credentials
if
you
are
listing
clusters-
and
you
have
access
to
do
so-
that
might
not
be
the
best
way
to
deploy
them
depending
upon
your
environment
and
your
and
your
security
requirements
and
I
think
that's
something
we
haven't
necessarily
tackled.
Yet
I,
don't
know
if
you
have
thoughts,
Jason.
K
So
for
the
AWS
provider,
specifically
right
now
we're
storing
the
CA
key
and
see
a
cert
for
the
cluster
in
the
cluster
provider.
Step
closer
to
provider
can
peg,
so
you
can
generate
a
kid
config
to
access
it
longer-term
we're
looking
at
potentially
storing
that
within
Amazon
AWS
secrets
manager
so
that
we
can
restrict
who
can
actually
access
that
and
then
we
would
just
reference
that
sequence.
E
K
Was
just
gonna
add
that,
in
order
to
be
able
to
do
additional
operations
on
the
cluster,
there
are
a
lot
of
things
that
you
have
to
do
to
be
able
to
interact
with
the
cluster.
So
we
need
access
to
the
credentials
somehow
within
the
controller,
to
do
operations
on
the
cluster,
and
you
know
so
it's
not
necessarily
about
providing
the
credentials
to
the
end
user
as
it
is
for
being
available
about.