►
From YouTube: Kubernetes SIG Cluster Lifecycle 20171018 - Cluster API
Description
Meeting Notes: https://docs.google.com/document/d/16ils69KImmE94RlmzjWDrkmFZysgB2J4lGnYMRN89WM/edit#heading=h.w4xw7yvzdgs
Highlights:
- Reviewed the pitch deck for the cluster api (join the sig cluster lifecycle mailing list to get access)
- Process going forward
- Overlap with the cluster registry
- Reviewed an early version of the proposed node api
A
Hello,
everyone
and
welcome
to
the
inaugural
meeting
for
the
cluster
API
effort,
which
is
part
of
sync
cluster
lifecycle
today
is
Wednesday
October
18th
and
since
this
is
our
first
meeting,
I
think
we're
going
to
started
by
just
sort
of
talking
about
what
we
think
we're
doing
and
why
everyone's
here
and
I'm
sorry
that
my
camera
doesn't
work.
It
worked
at
the
meeting
two
hours
ago
this
morning
using
the
same
software
and
appears
to
have
broken
since
then.
A
So
I'll
go
first,
my
name's
Robert
Bailey
I'm
listed
as
cluster
ops
and
zoom,
so
I
can
record
the
meeting
work
at
Google
and
I'm
one
of
the
leads
of
the
cluster
lifecycle,
sync
and
working
on
the
coaster,
API
effort,
because
I
think
it's
important
for
us
to
standardize
not
just
at
the
sort
of
cube
admin
level,
but
also
at
the
level
of
specifying
what
clusters
look
like
to
meet
a
number
of
different
important
Hobbs
cases.
I'm
just
gonna
go
across
the
top
and
sort
of
call
on
people
Chris.
B
I
see
I
am
Chris
Ramsey
I'm
also
on
the
cluster
lifecycle
team
here
at
Google
and
I
am
mostly
interested
in
the
control
plane.
Definition
in
the
API
group
I'm
curious,
I'm
I
want
to
see
this
effort
become
a
standard
way
to
deploy
and
make
it
easy
to
automate
and
maintain
and
operate
clusters
and
I
think
getting
the
control
plane.
Definition
just
right
for
continuous
operation
is
one
of
the
most
critical
pieces
for
that
cool.
D
E
Hi
alex
moore,
I'm
also
at
Google
on
the
cluster
lifecycle
team,
manage
it
so
I
just
thought
I'd
take
along
and
see.
What's
going
on,
my
particular
interest
is
really
about
making
the
cluster
ops
experience
better
right
and
I
know
we're
focusing
on
deployment
and
Suns
initially,
but
that
longer-term
lifecycle
of
keeping
clusters
happy
and
running,
and
so.
F
A
F
I
am
involved
with
lost
your
life
cycle,
I,
copped
and
I
wrote,
keep
accord
and
now
a
lot
of
other
people
contribute
to
that
project.
Great
and
I
believe
that
the
fact
that
we
don't
have
an
infrastructure
API
is
hard
for
me
to
swallow.
So
I
really
want
to
see
this
thing.
Take
off
and
I
really
want
to
fight
for
it
and
then
get
into
devote
a
lot
of
work
time
and
a
lot
of
personal
time
and.
G
H
Young
Matt
I'm
from
a
UK
company,
called
just
like
we
focused
one
of
the
things
we've
been
doing
recently,
is
on
a
cloud
agnostic,
cubanelles
provisioner,
based
on
the
work
that
we've
previously
done
with
some
of
our
customers.
We
open
source
out
last
week
a
stomach
with
a
k
now
we're
docked
at
the
blast
or
API,
or
it's
the
very
early,
humble
beginnings
of
the
hunter
API
work
so
in
to
contribute.
Really.
A
A
I
J
A
Awesome
I
think
I
got
everyone.
Please
poke
me.
If
I
missed
you
and
you'd
like
to
introduce
yourself
I
kind
of
wanted
to
start
by
going
over
a
pitch
deck
that
one
of
our
PMS
helped
us
put
together
for
sort
of
why
we
wanted
to
start
working
on
a
cluster
API.
Hopefully
this
resonates
pretty
well
with
people
like
Matt,
who
sort
of
started
on
this.
Everything,
selves
and
Jacob
was
nice
enough
to
share
his
screen
some
time
doing
the
recording
and
we'll
just
sort
of
walk
through
this
really
quickly.
A
I
know
a
lot
of
people
have
probably
seen
something
like
this,
or
this
will
not
be
a
surprise,
but
I
want
to
set
a
stage
of
where
we
think
we're
headed.
So,
if
you're
the
next
slide,
the
current
state
of
the
world
for
cluster
management
and
cluster
office,
as
Alex
mentioned,
is
very
fragmented,
where
we
have
and
lots
of
different
tools
right.
You
know
you
know
Chris
mentioned
just
you
know.
A
We've
explicitly
even
said
that
that's
not
part
of
core
kubernetes,
just
in
Santa
Barbara
sent
a
pull
request
a
couple
of
years
ago
to
try
and
put
the
notion
of
node
pools
into
core
which
was
rejected
and,
as
a
result,
sort
of
everybody
has
as
reimplemented
things
like
node
pools.
People
are
employing
different
types
of
upgrade
strategies,
there's
not
any
consistency
in
terms
of
cluster
configuration
for
admission
controllers,
etc
across
different
clusters
and
result.
A
We
don't
have
a
foundation
to
build
higher-level
sort
of
cluster
management
or
cluster
ops
tools,
so
things
like
the
cluster
autoscaler
get
reimplemented
and
talking
with
the
cholesterol
scaling.
Team
they've
actually
started
themselves,
also
sort
of
implementing
something
akin
to
like
a
cloud
provider
interface,
which
is
what
we're
trying
to
get
rid
of
in
core
slash
like
a
cluster
API
definition
interface.
That
is
portable
across
clouds,
so
I
think
we're.
A
A
So
the
custom
API
is,
is
meant
to
be
a
declarative
way
to
create,
configure
and
manage
clusters
where
we
have
controllers
and
the
kubernetes
sense
of
controllers
will
reconcile
desired
versus
actual
state.
If
you
think
about
a
lot
of
the
existing
system,
this
is
this
is
sort
of
how
they're
built
you
know.
Cops
has
built
this
way.
A
Api
is
directly
next
slide,
so
sort
of
from
a
diagram
point
of
view.
What
this
looks
like
is:
you'd
have
user,
interacting
with
the
deployment
tool
the
deployment
tool
uses
a
cluster
API,
plus
this
sort
of
glue
layer
that
I
mentioned
to
actually
instantiate
a
cluster
on
top
of
it
and
a
different
cloud
environment.
A
You
then
have
cluster
automation.
That
can
be
pointed
at
the
same
cluster
API
so
that
the
cluster
automation
can
introspect
what
different
nodes
look
like
what
the
pools
of
nodes
look
like,
can
automatically
scale
or
add
nodes
to
the
cluster
or
remove
nodes.
You
can
build
things
like
cluster
repair
or
monitoring
that
also
targets
that
and
is
able
to
take
automated
actions
built
on
top
of
the
cluster.
A
The
next
couple
of
slides
are
just
sort
of
strawman
sort
of
rough
estimations
about
the
a
my
API
might
look
like
you
know.
All
of
these
are
just
sort
of
here
to
point
out
the
fact
that
we
started
thinking
about
what
this
would
look
like
in
terms
of
structures
and
then
the
resulting
sort
of
VM.
All
that
you'd
get
would
be
something
that
you,
what
is
gonna
look
pretty
familiar
if
you've
had
to
deal
with
Trinity
amo
files,
but
instead
of
describing
your
application,
would
just
drive
your
cluster.
A
And
so
you
use
your
version
control
as
the
source
of
truth,
and
you
can
do
the
same
thing
at
this
at
this
level
with
your
clusters
themselves
and
you
can
check
in
your
cluster
definitions
and
use
those
to
be
the
source
of
truth.
We've
actually
does
this
today
using
terraform.
They
check
in
terraform
configs
it
to
get
and
use
that
to
describe
what
their
cluster
should
look
like,
and
that
works
great
for
their
environments.
But
again
it's
not
portable
across
environments
and
a
class
across
companies
and
across
infrastructure,
and
so
with
the
cluster
api.
You'd.
A
So
some
risks
that
we
see
are
that
we,
the
API
design
here,
is
gonna,
be
pretty
tricky.
We
can't
make
the
API,
so
generic
that
you
can,
you
know,
use
the
same
y
ml
everywhere,
but
you
can
actually
expose
the
underlying
power
of
different
environments.
And,
conversely,
if
the
API
is
so
specific
that
it
works
great
in
one
one
environment,
but
but
not
others
or
you
can
actually
extract
the
general
pieces
out,
then
it's
gonna
become
really
difficult
to
make
things
that
are
truly
portable
and
a
good
example.
A
It's
been
a
long
time
since
people
are
sort
of
thinking
about
this
problem,
but
nobody's
really
pushed
hard
to
make
it
true
and
the
longer
we
wait,
the
harder
it's
going
to
be
to
drive
people
to
consensus
into
a
standard
and
in
the
last
slide,
is
talking
about.
So
what
what
we're
doing
from
the
Google
side.
So
you
guys
probably
meant
notice
that
there
a
lot
of
Google
people
on
the
call.
Today
we
have
a
number
of
people
that
were
spinning
up
on
this
effort
to
to
make
sure
that
it
makes
some
significant
forward
progress.
A
We've
started
working
on
a
spec.
We
once
you
share
that
spec
and
start
getting
feedback,
and
especially
for
people
who've
also
sort
of
tried
to
do
this
and
we're
starting
to
build
a
prototype
against
that
to
run
on
Google's
cloud.
We
hope
that
people
will
do
that
as
well
on
other
platforms,
we're
looking
to
figure
out
what
tools
that
we
can
port
to
to
sort
of
prove
out
the
cluster
API
in
the
near
term,
and
the
last
bullet
here
I
convinced
rpm,
to
resolve
that,
and
so
that's
no
longer
an
open
open
question.
A
It
was
when
we
wrote
the
slides,
but
the
the
codes
can
end
up
in
to
cube,
deploy
repository
I
just
merged
a
PR
hour
ago
to
create
a
directory
for
the
cluster
API,
and
we
can
start
putting
everything
there.
The
nice
thing
is
it's
in
the
communities
organization,
it's
got
the
CLA
bought
attached
to
it
and
so
forth,
so
that
we
know
that
contributions
will
be
covered
sort
of
legally
going
forward
in
the
same
way
as
the
rest
of
communities.
A
So
the
idea
is
to
put
it
there
for
now,
until
we
have
a
better
home
for
it.
So
the
problem
is
right.
Now,
the
with
the
sort
of
recent
election
of
the
steering
committee,
the
incubator
process,
has
been
put
on
hold
the
process
for
creating
new
repositories
in
communities
is
also
put
on
hold
I
talked
to
the
cluster
Federation
folks
last
week,
and
they
have
their
own
repositories
that
they
created
like
two
days
before
that
hold
was
put
in
place,
so
they
kind
of
squeaked
by
having
their
own
cluster
registry
repository.
A
But
at
this
point,
new
repositories
are
not
being
approved
and
and
nobody's
graduating
from
incubation
until
the
steering
committee
figures
out
sort
of
what
that
whole
first
process
and
procedure
should
look
like,
and
so
Brian
grants
had
recommended
that
we
sort
of
squat
in
an
existing
repository,
cube,
deploy
is,
is
almost
completely
unused
at
this
point
and
we
can
sort
of
use
that
as
a
reasonable
home
for
now,
but
the
intent
is
not
for
it
to
live
there
forever.
That's
just
a
intermediate
step.
A
I
Had
a
couple
questions
about
scope,
it
seems
like
there's,
potentially
a
massive
massive
massive
huge
scope
here,
especially
if
it
includes
things
like
doing
cluster
upgrades
across
Louds.
Considering
that's
a
problem
that
virtually
no
one
has
solved
even
for
like
single
clouds,
I'm
just
curious
what
the
explicit
goals
are.
Is
there
a
goal
to
homogenize
the
top-level
input?
It
seems
like?
That's,
that's
something
and
everyone
agrees
upon.
Is
there
a
goal
to
make
clustered
portable
between
tools
as
well,
when.
I
A
You
couldn't
necessarily
just
say,
because
it
has
a
cluster
API
I
can
now
use
cubic
corn
to
provision
and
add
new
notes
that
cluster,
because
when
you
tell
the
cluster
API,
you
want
a
new
node.
The
reconciler
that's
running
at
is
gonna.
You
know
be
using
ansible,
based
on
your
configuration,
leaving
some
it's
possible
that
you
could
replace
that
reconciler
with
a
new
one.
That
you
know
is
the
cuba,
corn,
reconciler
and
and
sort
of
switch
switch
midstream
that
way,
but
I
don't
think
that's
an
explicit
goal.
I
Or
maybe,
maybe
put
another
way.
The
goal
is
not
necessarily
portability
of
deployment
tools
as
much
as
it
is
add-ons
that
you
might
run
in
the
cluster
that
need
to
interact
with
the
cluster
and
know
about
the
cluster
and
have
a
concept
of
a
high-level
view
of
the
cluster.
Is
that
fair
to
say,
because
it
seems
like
we're
making
a
distinguishment
between
tools
that
actually
deploy
the
cluster
versus
tools
that
operate
on
the
cluster,
like
the
autoscaler?
Well,.
I
That's
that's
actually
exactly.
My
concern
is
that
the
autoscaler
is
probably
going
to
need
a
need
to
know
about
some
things
that
exist
beyond
the
the
API
as
well
like
the
autoscaler
for
adjure,
for
example,
you
know
the
depending
on
which
one
you're
looking
at
both
of
them
have
you
know
dependencies
that
aren't
obvious
from
the
API
level
on
how
the
how
the
plates
are
created
or
how
they're
managed
so.
E
A
So
maybe
this
would
help
so
if,
if
you
have
a
consistent
way
to
add
capacity
to
your
cluster
right,
so
the
autoscaler
is
is
automation
for
adding
an
asset
if
your
cluster,
but
even
if
I'm
doing
it
manually
and
I,
say
I
want
to
add
three
new
nodes
to
my
cluster.
If
there's
a
consistent
way
to
say
you
know,
create
you
know,
queue
petal
create
a
CRD
resource
that
describes
that
I
want
a
new
node
with
one
core
and
that's
it,
and
that
at
a
high
level
can
be
made
to
be.
A
Then
you
could
say,
give
me
a
core
and
the
fact
that
I'm
running
on
a
sure
the
provisioner
knows
how
to
map
that
one
core
node
onto
an
azure
node,
that
it
spins
up
and
initializes
and
joins
to
my
cluster
and
I.
Could
I
could
run
that
same
command
against
my
GP
cluster
and
the
GCP
provisioner
knows
to
add
a
single
core,
node
and
initialize
it
and
add
it
to
my
cluster.
Then
the
autoscaler
effectively
just
automates
that
process
where
it
can
look
at
the
set
of
nodes
that
exist.
A
It
can
say
if
I
were
to
add
a
node
like
this
and
run
a
simulation.
This
pod
would
now
go
from
pending
to
scheduled.
Let
me
declaratively,
say
I
think
a
new
node
should
exist.
It
looks
like
this
and
the
provisioner
for
whatever
cloud
it's
running
on
could
add
that
node
and
in
the
pot
you
become
scheduled.
Okay,.
A
I
C
Is
in
the
autoscaler
has
kind
of
two
responsibilities
today,
it
not
only
decides
that
we
should
scale
up
and
how
large
the
cluster,
but
also
needs
every
cloud
provider
that
we
support
to
know
exactly
how
to
create
a
new
node
and
Azure
versus
GCE,
and
so
it
hasn't.
It
doesn't
have
this
intermediary
interface,
where
it
could
just
decide.
I
want
to
scale
up-
and
this
is
something
close
I
want
and
then
have
a
completely
independent
process,
actually
fulfill.
C
That
yeah,
like
let's
say,
GCE,
but
in
a
new
kind
of
way
that
also
works
device
manually
scale,
my
cluster
or,
if
I,
also
specialized
GPU
scaler.
That
knows
about
my
workload
away
from
my
machine
learning
work,
and
so
we
can
do
having
that.
Inflection
point
allows
both
sides
to
evolve
independently,
instead
of
one
tool
having
to
do
everything
and
yep.
I
F
Have
questions
about
process
if
we
can?
Yes,
oh
yeah,
if
we
I'm
kind
of
imagining
we're
all
sort
of
sitting
here,
shaking
our
heads
yes
say
and
like
okay,
this
sounds
like
kind
of
thinking
of
the
same
thing,
at
least
vaguely
to
begin
work
on
on
this.
I
imagine
this
was
sort
of
a
proposal.
Style
exercise
we're
going
to
be
going
through.
What
does
that
process
look
like,
and
how
would
we
start
making
formal
proposals
of
what
an
api
might
look
like
one
day.
F
C
In
fact,
if
we
have
time
in
this
meeting,
I
can
go
through
some
slides
of
the
way
I've
been
tackling
it
and
how
I've
been
thinking
about
it
and
what
it
looks
concretely
like
today,
but
yet
for
at
least
the
no
portion
I
have
something
that
is
interesting
enough
to
discuss
I'll,
say
later
today.
I
think.
F
And
then
I
one
thing
in
the
name
of
the
control
thing
that
I
wanted
to
mention
was:
we
had
talked
about
it
being
almost
a
one-to-one
mapping
of
cube
ATM
moving
forward.
So
yes,
there's
a
possibility
that
there
may
not
be
much
work
from
us
on
that
front
as
well,
but
yeah
anyway,
I
wrote
going
through
the
node
stuff
anybody
else,
yeah.
C
B
F
A
J
I
have
one
thing
I'd
like
to
ask
before
you
dive
into
the
technical,
so
on
the
multi
cluster
side,
there's
been
effort
to
create
a
cluster
registry
both
for
discovering
of
clusters
that
are
available
to
give
an
organization
and
also
for
Federation
to
know
like
which,
which
clusters
to
target
and
I
guess
I'm,
just
wondering
like,
is
there
any
overlap
here?
It
kind
of
seems
like
if
you're
using
this
cluster
API
to
you
know
manage
your
clusters.
J
That
would
be
an
easy
entry
point
for
discovery
for
the
class
of
users
that
just
want
to
use
a
cluster
registry.
For
that
use
case,
and
maybe
would
you
know,
provide
a
way
for
Federation
to
ignore
a
lot
of
the
details
and
just
you
know,
point
to
the
the
clusters
that
are
managed
using
the
cluster
API
I'm
just
curious.
If
there's
been
any
discussion
with
the
multi
cluster
team
around
this
issue,.
C
Yeah
so
so
early
on,
when
we
were
brainstorming,
scope
and
as
people
have
brought
up
like
scope,
is
so
important
in
this
project.
So
we
don't
just
boil
the
ocean
and
take
forever
to
actually
deliver
something.
We
were
doing
a
lot
of
brainstorming
about.
Do
we
want
to
completely
like
subsume
the
the
Federation
effort?
Do
we
want
to
be
able
to
have
a
single
control
plane?
How
is
the
the
definition
for
multiple
clusters
and
allow
you
to
reconcile
remote
clusters
and
have
like
one
master
cluster?
C
That's
actually
doing
the
reconciling
across
many
different
clusters
and
then,
when
we
found
out
about
that,
the
cluster
registry
project,
it
seemed
like
a
really
nice
delineation
of
concerns
would
be
a
cluster
API
for
for
a
single
API
server.
That's
housing
definitions
for
this.
It
would
be
it's.
It
really
simplifies
things
if
you
say
it
should
only
house
the
definition
for
a
single
cluster
and
that
any
sort
of
aggregation
you
need
across
clusters
should
use
the
cluster
registry
so
that
it
just
has
really
nice
semantics.
C
If
you
need
listing
use
the
cluster
registry
to
first
discover
all
of
the
clusters
that
you
care
about,
then
once
you
connect
to
them,
then
you
can
use
the
cluster
API
to
actually
actuate
each
one
of
them
independently
and
that
decoupling
I
think
really
simplifies
things.
But
if
there's
a
really
strong
need
to
to
revisit
that
separation
like
this
is
the
time
to
bring
it
up.
No.
J
C
And
if
you
want
to
write
a
controller
or
a
tool
that
is
multi
cluster,
aware
I
think
it's
reasonable
to
say
here
is
the
endpoint
from
a
cluster
registry
and
use
that
to
discover
all
the
clusters,
and
then
you
actuate
them
based
off
of
that.
Instead
of
having
the
cluster
API
attempt
to
do
both
scenarios
or
handle
everything.
Okay,.
J
A
That's
a
really
good
point,
though,
because
it
wasn't
clear
to
us
when
we
started
thinking
about
this
either
whether
the
cluster
API
was
a
single
or
multi
cluster,
API
and
I.
Think
as
Jacob
said,
we've
we
fallen
on
the
side
of
single
cluster
API
because
it's
a
lot
simpler
and
because
there's
another
group
of
folks
that
are
actively
working
on
the
multi
cluster
abuse
cases
and
and
Chris
asked
in
chat.
If
we
implicitly
create
a
registry
by
doing
this
and
I
think
the
answer
is,
is
not
exactly
I
think
we
can.
A
We
could,
if
we
wanted
to
like
specific
deployment
tools,
could
create
a
registry
inside
of
the
cluster
right.
The
registry
right
now
is
implemented
as
a
pod
that
you
can
run
in
a
kubernetes
cluster,
so
we
could.
Cuba,
corn,
could
spin
up
a
cluster
install
the
cluster
api
and
it's
also
registry
inside
that
single
cluster.
I
think
they're
also
going
to
be
used
cases
where
there's
sort
of
an
external
cluster
registry,
and
you
want
to
create
or
cluster
and
register
it
with
with
that
separate
registry
as
well.
C
And
a
bit
of
an
open
question
that
I
think
is
a
little
implicit
here
is
how,
if
we're
doing
a
kubernetes
tile
API,
where
do
these
objects
actually
live
and
for
the
node
portion
for
all
the
use
cases
I've
been
thinking
through
I
think
it
makes
a
lot
of
sense
for
them
to
live
in
the
cluster
that
where
the
nodes
are
supposed
to
exist,
it
allows
you
to
to
actuate
them
on
the
cluster
itself.
You
can
just
cute
cuddle,
apply
or
to
cuddle,
edits
and
and
create
new.
F
A
C
You
know
the
authority
of
what
your
control
plan
should
look
like
completely
off
of
the
cluster,
and
it
gives
you
that
flexibility
without
having
to
bake
it
into
the
actual
API,
where
these
objects
should
live,
and
that
might
be
a
safer
operation.
Just
in
case
you
accidentally
completely
wipe
out
your
control
plane,
you
don't
you
don't
prevent.
The
reconciler
is
from
being
able
to
even
access
what
the
control
plane
should
look
like
to
be
able
to
fix
it.
But
I
I
don't
think
that
we
have
that
same
problem
necessarily
with
the
node
portion.
C
C
C
What
actually?
Maybe
we
should
go
through
these
temps,
because
this
is
this
kind
of
important
context,
so
for
the
overall
cluster
API
efforts
and
and
also
for
this
machine's
API,
we've
strictly
said
we're
not
trying
to
get
into
kubernetes
core,
as
Robert
said,
like
the
the
president
has
been
set,
that
core
kubernetes
does
not
care
about
machine
management's
and
there's
even
been
a
proposal
that
was
turned
down
to
try
to
add
no
concept
of
node
pool
to
kerbin
and
a
score,
and
so
all
of
this
is
going
to
be
strictly
outside
of
kubernetes
core.
C
It's
it's
a
little
TBD
whether
these
will
be
API
extensions
or
using
API
aggregation
or
if
there
will
be
custom
resource
definitions.
We
definitely
want
it
to
be
kubernetes
style,
but
we're
not
trying
to
get
this
into
the
actual
kubernetes
codebase
and
also,
as
a
general
goal,
we're
trying
to
separate
out
in
order
to
maintain
portability.
It's
important
to
call
out
what
types
we
think
are
reusable
insurable
across
clusters
and
completely
different
environments
versus
the
types
that
are
strictly
tied
to
exactly
one
provider
and
versus
the
types
that
are
strictly
tied
to
a
specific
cluster.
C
C
The
priorities
here
are
a
little
in
flux,
we're
trying
to
get
a
better
understanding
with
our
PM
from
the
Google
side,
with
what
we
think
we
really
want
to
deliver
this
quarter
versus
what
we
should
ultimately
have
in
scope,
long
term.
So
just
going
over
a
few
things,
node
creation
super
simple.
So,
given
some
form
of
templates
that
somewhat
describes
your
node,
can
we
create
a
new
node,
and
can
we
delete
notes,
specific
note?
Deletion
is
important
for
a
few
tools
like
the
cluster
autoscaler
doesn't
just
want.
C
Let's
say
we
have
a
notion
out
of
a
node
pool
like
a
group
of
nodes
with
just
a
number
to
scale
up
how
many
instances
you
want
it's
not
really
powerful
enough
for
something
like
the
cluster
autoscaler,
which
actually
wants
to
look
at
the
workloads
running
on
specific
nodes
and
target
the
ones
that
are
nearly
idle
and
delete.
Those
specifically,
instead
of
just
generically,
saying
well
I,
want
a
few
fewer
consensus.
Please
randomly
delete
them.
E
C
A
little
TVD
at
this
point,
presumably
we
would
drain
I,
don't
know
if
that
should
be
so
right.
Now.
All
of
our
draining
code,
as
far
as
I
understand,
is
client-side.
It's
baked
into
cute
cuddle,
it's
baking
into
other
clients
that
want
to
specifically
evict
pods
from
nodes
before
they're,
taken
out
of
service
I,
don't
know
if
that
should
be
automatically
this
API,
but
we
at
least
need
some
form
of
I
would
like
to
delete
this
node.
A
Of
it,
yeah
I
mean
right
now
that
code
is
duplicated
right
like
take
upside,
it's
in
queue,
petal-like,
cerrado,
scalar,
also
unschedulable,
x'
and
drains
nodes.
Before
removing
specific
notes
to
as
the
gke
resizer,
there
is
a
existing
issue
to
move
drain
into
the
server
and
so
I
think
that
as
we
go
here,
that's
we're
gonna,
try
to
bump
the
priority
of
that
issue.
And/Or
help
implement
it
because,
like
other
things
that
started
out
in
queue
pedal
as
client-side
code
like
the
draining
should
really
be
done.
E
C
That
flexibility,
now,
let's
assume
that
deleting
a
node
actually
just
rips
it
out
of
existence
as
soon
as
you
say,
I
want
this
to
be
deleted.
You
have
the
flexibility
of
first
in
maybe
in
a
workload
aware
way
or
in
just
a
generic
I
wanted
Victor
the
pods
first
way
you
can
do
that
and
our
API
doesn't
necessarily
need
to
represent
that.
But
if
we,
if
we
build
in
the
behavior
that
you
always
safely
evict,
then
it
removes
that
flexibility
I
understand
that
we
could
have
the
strategy
of
how
to
delete
baked
into
the
API.
H
Just
an
observation
come
here,
you
know
in
the
mode
or
the
machine
you're
sort
of
assuming
that
it's
gonna
have
an
OS
image
and
the
Kuban
a
nice
version
and
is.
Is
there
a
thought
here
that
you
would
say
you
count
more
generic
machines
that
are
used
as
part
of
a
Cuban
in
this
cluster,
such
as
net
CD
instances,
because
we
we've
can't
face
the
problem
that
when
standing
up
a
cluster,
it
is
not
just
a
couplet
machine
and
across
the
patrolling
machine.
H
You
also,
as
part
of
the
cluster
needs,
to
stand
up
at
CD,
we're
also,
in
our
case
easing
fault
for
standing
up
cluster
pki.
So
we
would
really
like
to
refer
to
all
machines
in
the
same
way,
because
otherwise
you
start
having
to
differentiate
the
way
that
you
refer
to
an
SD
machine
from
the
control
plane
from
the
nodes.
Yes,.
C
So
it's
definitely
thinking
that
nodes
would
have
this
notion
of
a
role
which
is
ORS
cubic
or
now,
as
those
cops
has
this,
where
you
say
I
want
you
to
create
a
node,
and
this
is
strictly
a
master
node
or
this
is
strictly
a
worker,
node
or
its
master
and
worker.
So
it
you
should
be
able
to
schedule
workloads
on
it.
H
H
A
I'm
actually
really
interested
to
drill
into
your
use
case,
so
you
have
a
net
CV
at
CD
machine
and
your
are
you
running
sed
just
as
a
like
a
systemd
process,
I
think
most
people
running
through
rallies
run
at
CD
inside
of
a
container,
which
means
that
you
would
also
be
running
a
cubelet
on
that
machine.
But
it
sounds
like
you
guys,
aren't
doing
that.
No.
C
Interesting
things
yeah,
that's
really
a
few
initial
responses
to
that,
which
is
the
way
that
the
API
is
structured
right
now
is.
We
could
continue
to
add
these.
You
know
enumerated
things
that
we
think
would
be
these
numerator
roles
that
would
potentially
have
use
across
different
environments,
and
one
of
them
could
be
important
enough
or
significant
enough
to
say.
I
want
an
at
CD
only
mood.
If
that's
a
pattern,
we
think
that's
going
to
be
generally
reusable.
C
The
other
thing
is
that
I
think,
as
Robert
said
earlier,
like
the
power
from
this
from
this
API
comes
from
the
ability
to
actuate
after
deployment
and
I.
Don't
know
if,
as
an
operational
thing,
using
the
standard
set
of
tools
to
be
able
to
operate
on
kubernetes
nodes,
if
you
want
to
be
able
to
take
that
at
CD,
node
out
of
service
or
add
another
at
city
node,
so
at
another
potential
way
to
tackle
this
is
you
can
still
have
a
completely
custom
installer?
C
That's
says
in
addition
to
all
these
worker
nodes
and
the
normal
master
nodes.
I
know
how
to
create
these
other
hosts
that
are
Etsy,
be
specific
and
don't
have
cubelet
and
I'll
just
create
those
as
special
snowflakes
and
then
later
on.
I
can
still
use
the
cluster
API
and
other
existing
tools
to
work.
On
my
you
know,
strictly
speaking
worker
nodes
or
to
upgrade
my
control
plane
or
all
these
other
things,
but
maybe
you
won't
get
the
full
value
of
the
cluster
API
for
those
EDD
nodes.
That's
just
one
other
way
of
looking
at
it.
C
H
I
think
in
that
case,
that
would
produce,
we
would
sign
up
to
I
mean
we
would
have
a
more
dedicated
controller.
That
might
be
responsible,
for,
for
instance,
is
a
rolling
upgrade
of
xcd
itself,
yeah
I'm,
just
thinking
that
is
when
we're
picking
up
a
cluster
I'm,
just
think
of
the
other
roles
that
might
play
a
part
you
would
want
to
deal
with
in
the
same
way,
but
yeah
I
mean
I
recognize
it's
probably
more
specific.
H
C
Is
a
really
interesting
use
case?
One
of
the
other
factors
that
we've
been
conscious
of
is
not
only
do
a
lot
of
people
want
to
create
a
cluster,
but
they
also
want
to
create
a
whole
lot
of
infrastructure
around
it
to
support
the
clusters
needs,
and
so
we've
kind
of
been
struggling
to
draw
the
line
for
where
this
specific
API
should
end,
and
you
should
start
just
opting
into
other
better
tooling
for
those
purposes.
C
So
I
think
the
last
thing
we
want
to
do
is
accidentally
re-implement
terraform,
which
allows
you
create
completely
arbitrary
cloud
resources
and
is
really
good
at
doing
that.
But
those
resources
might
be
completely
orthogonal
to
bringing
up
your
cluster
or
maintaining
it
over
time.
So
I
don't
know
exactly
where
the
line
is
drawn,
but
there's
definitely
something
we
want
to
stay
away
from
I.
Think
completely.
H
C
I
Curious,
what
does
what
does
no
deletion
look
like
from
the
perspective
of
a
declarative
API,
and
is
that
something
like
our
be
imagining
that
all
of
the
nodes
are
listed
one
by
one
individually
in
this
cluster
API?
Or
is
this
just
something
that's
called
out
from
like
an
all?
Around
ecosystem
needs
to
be
able
to
do.
C
So
at
this
point
at
this
slide,
it
was
like
all
around.
We
should
have
this
ability
to
give
you
a
brief
preview.
When
we
originally
crazy
on
on
how
to
represent
nodes,
we
started
with
the
concept
of
grouping.
It's
just
so
natural
to
say
we're
gonna
have
a
lot
of
a
lot
of
them,
are
gonna,
become
obvious.
I
probably
want
to
be
able
to
scale
them
up
and
down.
C
C
Cases
for
I
just
want
to
experiment
with
this
one-off,
node
and
I,
don't
necessarily
want
to
create
a
whole
sets
that
it's
just
size
one,
and
so
this
is
absolutely
up
for
debates,
but
the
way
that
I'd
been
thinking
about
it
so
far
in
the
API
is
to
have
an
API
object.
That
declaratively
says
I
would
like
a
new
to
exists
and
I
would
like
it
to
look
like
this
right
now.
The
concept
of
nodes
as
an
object
exists
in
core
and
they
have
a
spec
and
a
status.
They
aren't.
This
isn't
really
declarative.
C
You
can't
just
say
you
know
it
reports
the
version
but
cubelet
that
it's
running,
but
you
can't
just
say
in
the
spec
well
I'd
like
to
run
this
version
then
have
it
upgraded.
So
so,
if
you
imagine
a
node
as
it
exists
today
in
core
as
an
entire
status
of
the
cubelet
and
I
want
to
create
a
new
object,
that
was
actually
the
specification
for
that.
C
So,
if
you
create
one
of
these,
it's
kind
of
like
you
can
create
a
pod
at
first
its
unscheduled
and
then
ultimately
well
to
a
node,
and
you
can
delete
that
pod
and
get
some
that
node.
You
can
create
this
declarative
I'm,
just
calling
in
a
machine
at
this
point
you
create
a
machine
with
this
of
the
case
of
life
and
mode
to
look
like
and
then
that
node
should
come
into
existence.
If
you're
in
an
environment
where
they
can
heat.
Auto
provision
and
then
it
won't
delete
that
node.
C
I
C
F
A
question
about
note
creation:
yes,
one
of
the
things
we
see
a
lot
and
keep
according
we
saw
this
in
cops
was
users
who
want
to
bring
their
own
aftermarket
logic
while
strapping
a
note.
A
really
simple
use
case
is
I.
Have
some
security
tool
that
I
need
to
yum
install
before
I
can
run
kubernetes
pods
on
whatever
right?
Some
are
security
logic
that
like
user
assistance
and
the
trainer's
want
to
run.
We
turn
our
notes
down
to
MIT
and
cops
and
said
it
was
an
anti-pattern.
F
C
E
I'll,
throw
out
like
compute
engine
VMs
if
I
have
the
notion
of
startup
scripts,
and
so
this
is
a
really
common
style
of
of
thing.
I
think
what
my
take
would
be.
We
should
enable
you
to
pass
such
blobs
to
the
controller.
Is
it
worth
having
a
standardized
mechanism
across
all
controllers
to
support
that
functionality?
That's
a
fair
question
to
write.
F
Like
on
one
hand,
it
could
be
up
to
the
controller
to
have
to
sort
of
care
about
what
the
actual
implementation
of
bringing
up
the
node
looks
like
and
then,
on
the
other
hand,
we
could
actually
have
a
blob
that
we
could
define
that
says,
go
run
these.
You
know
bash
script.
These
fast
commands
in
an
order
or
something
yeah.
A
Also
mention
that
on
gke
we
also
sort
of
turned
out
I
was
up
at
that
that
pattern
and
said
that
we
aren't
gonna
support
no
specific
startup
scripts
and
you
should
use
daemon
sets
instead
and
that
we
initially
got
some
pushback
from
customers.
But
recently
people
have
not
been
asking
for
startup
scripts
anymore
for
no
customization.
E
A
A
Excellent
I,
like
this
I,
will
do
a
quick
time
check.
We
have
six
minutes
before
the
meeting
specifics
attend
my
proposal
to
get
to
the
other
three
slides
on
capabilities
today
and
then
Jacob
send
a
PR
with
the
actual
API
struct
definitions
rather
than
trying
those
during
this
meeting,
and
we
can
review
them
next
week.
C
The
concept
of
what
an
OS
image
is
could
be
different
in
different
environments,
different
if
you're
in
cloud.
Maybe
this
is
a
single
string
in
GCE.
We
actually
have
the
this,
like
nested
structure,
to
define
a
single
OS
image
that
actually
has
the
project
and
family
in
an
ID
and
if
you're
on
premise,
your
concept
of
an
OS
image
might
actually
be
more
like
I'm
using
Debian
met
this
version,
and
maybe
some
other
metadata,
but
on
a
per
node
basis,
again
kind
of.
C
If
anyone
feels
strongly,
this
should
be
on
a
per
group
basis
or
shouldn't
even
be
considered
for
this
API.
It
seems
useful
to
be
able
to
actually
upgrade
nodes,
and
that
could
be
so.
We
want
the
way
that
I'd
raised
it
here.
We
want
that
it
the
notion
that
I
want
to
upgrade
this
node
to
be
declarative,
but
the
way
that
gets
actually
it
could
be
different
in
different
environments.
C
So
if
you're
in
a
cloud
environment,
the
controllers
that
you've
set
up
mites
just
strictly
to
replace
the
node
with
a
brand
new
node,
conforming
to
the
new
spec,
and
that
was
bound
to
our
declarative
notion
of
a
machine
boy
for
your
ants
on
premise.
It
could
just
be
actuated
by
apt-get
upgrade
or
some
other
in-place
installation
that
doesn't
actually
replace
the
node.
But
as
a
capability,
upgrading
the
operating
system
or
whatever
definition
that
is
in
your
environment,
seems
useful,
independent
of
being
able
to
upgrade
the
kubernetes
version,
which
would
be
the
actual
hewlett.
C
C
Anything
on
that
before
I
go
to
the
next
slide.
Actually,
let
me
blast
through
just
the
next
two
slides
and
then
we
can
come
back
if
there
any
questions
or
comments.
So
I
kind
of
alluded
to
this
very
similarly
will
specify
the
container
runtime
that
you
want
to
use,
and
it's
version
so
I,
don't
know
how
big
of
a
use
case
it'll
be
saying.
C
I
want
to
switch
from
docker
to
certainly
being
able
to
say,
I
want
this
machine
to
run
docker
at
this
exact
version,
and
I
would
like
to
be
able
to
independently
appraised
that
in
a
real,
you
know
node
by
node,
without
affecting
the
version
of
kubernetes
or
the
operating
system
image,
but
this
adds
lower
priority,
because
this
is
something
you
could
achieve
by
making
a
new
OS
image
if
you're
in
the
cloud
just
have
it.
Pre,
bundled
in
the
operating
system.
C
Image
and
I
think
it
called
out
as
a
separate
field,
but
it
seems
like
really
useful
functionality
to
be
able
to
Rev
container
own
time,
independent
of
cubelet,
independent
of
operating
system
and
as
a
super
low
priority.
This
might
be
addressed
with
the
concept
of
bootstrap
scripts
or
might
be
useful
from
an
overall
like
what
does
kubernetes
look
at
like
as
a
distribution,
but
we
could
use
the
same
sort
of
if
we're
already
versioning
the
cubelets
and
average
this
amount
and
your
container
runtime.
What?
C
C
I
think
this
is
a
less
important
thing
to
immediately
focus
on,
certainly
I
think
the
project
wouldn't
be
as
successful
if
we
couldn't
eventually
rebase
the
autoscaler
on
top
of
it,
but
we
already
have
auto
scaling
for
a
lot
of
different
cloud
providers.
It's
not
new
functionality
that
we're
enabling
it
just
gives
us
kind
of
a
better,
consistent
view
of
nodes.
So,
but
but
if
we
want
to
tackle
auto
scaling,
they
have
these
concrete
requirements
of
being
able
to
do
accurate
predictions.
C
So,
instead
of
just
saying,
I
want
this
instance
type
and
I
would
like
several
more
machines
of
it
and
then
once
they
come
up,
I'll
then
figure
out
how
much
memory
they
have
and
how
many
CPU
cores
they
have
in
ours
just
enough
to
be
able
to
actually
predict
ahead
of
time
if
I
scale
up
this
set
of
nodes
or
create
this
new
node
on
the
fly.
What
are
the
capabilities
that
we'll
have
after
that?
C
That
I
need
to
scale
right
now,
instead
of
just
being
completely
ignorant
to
cost,
and
you
know
scaling
up
what
looks
like
a
good
machine,
you
could
actually
have
these
weighting
mechanisms
to
say:
I'll
try
these
they're
the
most
efficient
in
this,
in
this
case
right
now.
Okay,
so
I've
reached
through
those-
and
we
only
have
a
few
minutes
left,
but
anyone
want
to
add
more
table
we'll
keep
them
to
lose
that
they
really
feel
strongly
about
or
want
to
drill
into
any
particular
one
of
these
and
discuss
their
needs.
C
I
C
I
I
can
get
into
there's
a
lot
of
technical
details
there.
The
way
that
I
was
thinking
about
it
was
making
sure
that
we
wouldn't
build
any
sort
of
pricing
into
the
node
portion
of
the
safety
either
the
machines
API,
but
maybe
we
support
all
of
the
providers
provider
agnostic
inputs
that
they
need
in
order
to
be
able
to
model
the
price
in
the
way
that
they
do
today.
Otherwise,
it's
kind
of
a
hard
stop
from
them
that
they'll
never
rebase.
On
top
of
this
api.
C
C
Think
we're
at
time,
if
there's
any
other
concerns,
you'll
reach
out
to
any
of
us,
I
I
think
the
best
place
is
probably.
We
can
certainly
wait
till
next
week's
meeting,
but
I
think
a
conversation
is
still
going
on.
The
cluster
lifecycle,
mailing
lists
or
in
our
slack
Channel,
certainly
reach
out
to
any
of
us
individually.
I'm
gonna
stop
sharing
my
screen
the
reactor.