►
From YouTube: SIG Cluster Lifecycle Intro – Justin Santa Barbara, FathomDB & Lucas Käldström (Any Skill Level)
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)
SIG Cluster Lifecycle Intro – Justin Santa Barbara, FathomDB & Lucas Käldström (Any Skill Level)
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. Since the group's formation we have primarily focused on creating kubeadm, a streamlined installer tool and building block to simplify the installation and upgrade experience, and enhance kops, the easiest OSS way to get a production-grade Kubernetes cluster up and running in AWS. We have recently begun building a Cluster API to provide an abstraction of machines across different deployment environments along with a common control plane configuration. In this introduction session, we will present the SIG's mission statement, review recent accomplishments, and discuss our future plans, where you are very welcome to contribute to the discussion. We will also focus on how new contributors can get involved in helping shape the future of Kubernetes' cluster lifecycle management.
About Justin
Justin is one of the kubernetes sig-aws leads and started the kops project, so loves to talk about how to install and operate kubernetes, or on all things kubernetes-on-AWS or on other clouds (particularly GCP, having just joined Google!)
About Lucas
Lucas is a passionate Kubernetes Maintainer and Certified Kubernetes Administrator that is excited about all things cloud native. Lucas has been engaged in Kubernetes work for about two years now and been involved in work like porting Kubernetes to multiple platforms, getting Minikube off the ground, being a core contributor in SIG Cluster Lifecycle and maintaining kubeadm. Besides Upper Secondary School Lucas runs a consulting company for Cloud Native tech programming tasks and runs the official CNCF & Kubernetes meetup in Finland. Lucas has been speaking at KubeCon in Berlin and Austin previously, and was awarded the Top Cloud Native Ambassador of 2017 together with Sarah Novotny.
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)
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
Hi
and
welcome
everyone
to
this
c-class
lifecycle
introduction
session
today
we're
going
to
talk
about
what
what
our
special
interest
group
is
doing,
where
we
meet
how
often
and
what
our
plans
are
for
the
future
and
also
what
we
have
done
so
far
so
I'm
Lucas,
Kallstrom,
c-class,
the
lifestyle
cycle,
co-lead
and
CNCs
ambassador
I'm
doing
contracting
for
weworks,
while
I'm
not
in
high
school.
So.
A
Cool,
so
Sigma's
life
cycle
basically
examines
how
we
can
change
kubernetes,
to
make
it
easier
to
operate
easier,
to
create
clusters
to
configure
them
and
to
upgrade
them.
For
example,
high
availability
is
also
a
question
like
how
do
we
make
this
whole
process
easier
to
manage
certificate
rotation?
Everything
at
CD
Management
we're
gonna
talk
about
this
more
later,
so
we
divided
our
responsibilities
and
work
items
into
five
logical
pieces
of
work
and
the
first
one
is
control
plane,
installation
management.
So
this
is
basically
cubed.
M
is
the
output
of
this
effort.
A
I
want
to
get
a
kubernetes
up
and
running
as
quickly
as
possible
as
smoothly
as
possible
and
as
as
fast
as
possible.
So,
for
example,
we've
deprecated
the
old
guides
getting
started
guides
that
have
been
our
data
for
a
long
time
and
instead
replacing
them
with
cubed
M
that
we
consider
being
a
building
block
for
the
future
and
generally
improving
docks
as
part
of
this,
but
also
control
plane
configuration
management.
A
So
how
do
I
specify
arguments
to
the
api
so,
for
example,
how
do
I
configure
my
cube
proxy
add-on
or
how
do
I
run
cube,
DNS
stuff,
like
that?
Our
sake
has
published
guidelines
for
component
configuration,
which
is
this
structured
api,
like
all
other
kubernetes
api
s--,
that
you
can
pass
to
kubernetes
components.
B
Yes,
and
so
those
first
two
items
we
sort
of
have
a
control
plane
up.
We
have
it
configured,
there's
another
piece
of
the
cluster
API,
which
is
the
machines
API,
and
this
is
about
bringing
new
nodes
or
machines
into
your
cluster
scaling
it
up
and
down
destroying
them
doing
rolling
updates.
So
that's
the
third
area
and
then
the
the
next
area
is
add-on
management.
So
you
have
a
basic
cluster
up
and
running,
but
typically
you
need
definitely
some
core
system.
Add-Ons
you're
almost
definitely
needed
almost
definitely
need
a
CNI
network
provider,
for
example.
B
You'll
need
a
DNS,
it's
very
debatable.
What
is
the
control
plane
and
what
is
you
know,
you're
moving
out
into
user
space,
but
there's
definitely
some
core
of
system
add-ons,
which
we
probably
need
to
install
as
part
of
our
group
and
think
about
the
configuration
of
and
the
lifecycle
of
some
of
those
things
will
change.
The
versions
of
those
things
will
change
and
need
to
be
upgraded.
B
Alongside
your
kubernetes
upgrades
like
DNS,
so
that
one's
a
pretty
active
area
of
debate
right
now,
we
can't
even
really
necessarily
decide
exactly
what
is
in
and
out
of
scope.
There,
but
we
know
that
there
is
definitely
spits
that
are
in
scope
there
and
that
need
to
be
addressed
yeah
and
in
the
final
one,
which
is
sort
of
that
I
think
the
most
contentious,
but
actually
I,
think
everyone
wants
someone
to
deal
with
it
and
so
sick
bastard
lifecycle
seems
to
be
the
one
that
is
willing
to
do
that.
B
I'm,
a
big
proponent
of
it
personally,
everyone
finds
EDD
very
challenging
to
operate
and
manage
that's
not
entirely
at
CDs
fault.
It's
partially.
It's
really
because
we've
put
all
of
our
control
planes
state
into
Etsy
D,
and
so
it
is
therefore
the
one
piece
we
put
all
the
hard
stuff
into
Etsy
D
and
so
surprisingly,
enough
SC
d
is
hard.
So
that's
that's
the
fifth
pillar,
I
guess
of
our
our
cover
of
our
work,
yeah,
yeah
and
so.
C
B
B
A
B
Is
sort
of
the
the
the
vision
the
lioka
is
actually
doing
pretty
well
at
the
moment,
so
we
have
a
good
idea
of
what
the
API
will
look
like.
The
implementations
are
much
more
of
a
work
in
progress,
but
there's
actually
some
really
exciting
implementations
happening
right
now
and
so
come
along
to
the
office
hours
I,
don't
know
we
have
meetings
on
Wednesdays
which
are
really
exciting
to
see
what
happens
there.
Great
progress
in
that
area,
but
the
cluster
API
defines
a
bunch
of
API
new
API
types
in
the
kubernetes
api.
B
The
first
one
it
defines
is
a
cluster
which
is
a
container
for
the
sort
of
cluster
level
configuration
your
generic
or
not
generic.
Your
broad
cluster
configuration
things
like
your
networking
configuration
is
the
primary
one
right
now.
Then
we
have
another
object.
Called
a
machine
and
a
machine
is
a.
This
is
a
circular
definition,
but
a
single
physical
or
virtual
machine.
So
it
might
be
an
instance
on
Google
cloud
or
Amazon.
B
B
We
are
so
and
what
we'll
talk
about
the
controller,
there's
controller
that
will
basically
create
that
create
a
machine
or
provisioning
machine
or
get
control
of
a
machine
from
a
pool,
for
example,
in
a
in
a
physical
environment
and
what's
good
about
this,
is
it
lets
us
build
up
these
other
concepts
called
machine
sets
and
machine
deployments.
So
if
we
think
of
a
machine
as
being
like
a
pod,
we
have,
on
top
of
that
we
have
in
kubernetes,
we
have
wrap
on
top
of
pods.
B
We
have
replica
sets
and
deployments,
and
most
people
now
work
with
deployments
instead
of
at
the
at
the
pod
level,
and
it's
the
same
thing
here
most
people.
The
intention
is
most
people
work
with
machine
deployments
and
then
a
machine
deployment
controller
will
create
machine
sets.
Machine
set
controller
will
create
machines
and
then
the
machine
controller
will
go
and
create
or
requisition
the
actual
machines
yeah.
A
So
it's
when
we
have
this
set
of
API
specs
we
can
aim
in
the
future-
is
that
we
can
have
this
specification
in
a
Yama
file,
for
example,
and
if
we
give
it
the
VMware
tool,
it
will
spin
up
or
this
specification
in
VMware
cluster.
If
we
give
it
to
the
AWS
tool
that
implements
this,
it
will
do
its
thing
in
AWS.
It
will
give
it
to
corpses,
can
do
both
AWS
or
GC
or
whatever,
and
then
we
will
have
a
much
higher.
You
know
we
can
unify
yeah
the
neck.
B
Exactly
and
I
think
what's
particularly
citing,
is
that
like,
if
you
imagine
what
GCE
or
AWS
or
IRA
have
to
do,
they
really
only
have
to
implement
one
controller,
the
machine
controller,
and
we
can
share
those
higher-level
controllers.
The
Machine
set
the
machine
deployment
controllers,
and
so
you
know
we
have
this
incredible
diversity
of
tooling
right
now
and
hopefully
we
can
try
to
unify
at
least
the
user
experience
of
it.
So
you
will
be
working
with
machine
deployments
and
not
have
to
worry
as
much
about
you
know,
cops
or
cube,
ATM
or
whatever
tooling.
A
So
here
is
a
diagram
of
what
this
all
looks
like
and
first
we
start
with
some
kind
of
infrastructure,
be
it
my
raspberry
pi
stack
at
home
or
my
physical
boxes
at
the
office
or
like
AWS
Asher,
GCP,
whatever,
but
somewhere,
where
we
have
access
to
a
couple
of
machines
on
top
of
these
machines.
So
the
lay
one
is
then
infrastructure
machines,
layer
two
is
we
use
cubed
M,
for
example,
as
a
building
block
to
bootstrap
the
cluster
and
create
a
unified
kubernetes
cluster.
A
That
checks
am
I
running
the
amount
of
notes.
I
should,
in
my
machine
deployment
or
should
I
create
more,
am
I
running
too
many
or
some
of
the
machines
unhealthy,
and
this
small
controller,
as
Justin
said
that
handles
the
machines
is
environment,
specific,
but
the
rest
of
the
API
and
the
rest
of
the
higher-level
controllers
are
the
same
and
they're.
A
And
here
I
try
to
summarize
it
so
cuba
m
is
a
small
thing
that
runs
just
gets
the
cluster
up
and
running
to
the
bare
minimum
level
that
you
could
even
call
a
kubernetes
cluster,
no
extra,
don't
see,
not
even
a
network
provider.
You
have
to
give
that
yourself,
but
cops
is,
has
a
much
larger
scope
and
basically
wraps
everything
the
whole
world,
these
tools,
cloud
provider,
add-ons
versus
monitoring
things
like
that,
and
it's
also
one
of
the
new
consumers
of
cluster
API
spec.
A
So
you
give
the
specific
specification
of
what
you
want
in
the
cluster
API
the
cops
and
it
will
do
its
thing
in
the
future.
As
I
said,
the
cluster
API
is
still
in
alpha.
We
have
a
working
group
for
it
inside
of
the
class
lifecycle
that
meet
on
Wednesdays,
so
please
do
come
and
get
in
touch
and
get
involved
with
that
effort.
A
If
you
have
ideas
and
for
cubed
M,
it
should
set
up
a
best
practice
cluster,
but
not
anything
more,
just
just
the
bare
minimum
and
use
be
as
secure
as
possible
for
each
minor
version
and
so
on
and
so
forth.
The
user
experience
should
be
simple,
with
aim
for
this
like
cube
area
minute
and
you're
basically
done
just
have
to
install
like
we
were
flannel
or
calico
or
whatever
of
your
choice,
and
then
we
have
the
the
scope
is
limited,
unlike
cops,
and
it's
intended
to
be
a
building
block.
A
I'm
actually
doesn't
care
about
how
the
cubit
is
run.
It
just
assumes
a
cubelet
is
running
somewhere,
and
that
means
you
can
run
it
dr.
rice.
You
can
run
it
on
system
d.
You
can
run
it.
However,
you
want,
but
as
long
as
you
have
something
that
executes
and
favoring
one
specific
c
ni
implementation
is
out
of
scope.
A
That
was
one
of
the
early
design
decisions.
You
should
be
able
to
choose
your
favorites
and
then
it's
just
a
cube.
Detail
apply
way
of
the
cube
and
in
it
yeah
such
the
faces,
sing
and
the
audience
for
cube.
Adam
is
people
who
build
our
first
faster
people
who,
like
have
the
three
these
three
machines
at
the
roughest.
They
want
to
stitch
them
together
and
have
a
cabanas,
or
that
is
one
group
or
higher
level
tools
like
cops
cubic
own
cluster,
API
implementations
or
larger
enterprise
services
like
G
key
and
people
like
that.
A
A
So
recently,
two
bananas
110
was
released
and
with
that
cube,
a
team
as
well
as
part
of
the
race
process
that
gave
us
support
for
advanced
auditing
TLS
encryption
for
the
local
HDD
on
the
master
and
an
update
to
at
CD
3.2
as
part
of
the
rest
of
kubernetes
as
well
and
codeine
is
graduated
to
beta.
So
now
it's
available,
you
can
run
cube
Adam
in
it
and
feature
gates
coordinates
true,
and
it
should.
B
Work
and
we
recent
released
cops
won.
Nine
cups
has
a
its
delayed
release
schedule
we
worse
we're
shifting
to
a
faster
release
schedule,
but
the
decision
we
had
previously
made
was
that
the
release
of
cups,
one
nine
means
that
kubernetes
one
nine
and
cops
one
nine
and
all
the
CNI
providers
and
everything
we
install
is
believed
production
ready.
So
that's
why
cops
tends
to
lag
by
typically
about
a
whole
o
minor
release.
So
we
recent
release
one
nine
one.
B
Nine
support,
obviously
bug
fixes,
there's
a
huge
change
list
if
you
want
to
check
it
out,
but
the
big
ones
are
sort
of
improved
GCE
support.
There's
initial
digitalocean
support
going
in
there,
which
I'm
excited
about,
and
we
have
a
it's
sort
of
plan
for
EDD,
and
so
the
real
thing
that's
happening
right
now
is
is
trying
to
make
sure
that
we
have
a
plan
to
get
everyone
able
to
move
from
to
an
NC
d
manager.
B
That
the
the
spec
is
there,
it's
a
community,
SIG's
github,
comma,
slash
community
SIG's
cluster
API.
Now
the
spec
is
in
great
shape,
I
think
the
api's
in
great
ship
shape
and
the
there's
some
implementations
happening,
there's
a
sort
of
canonical
GCE
implementation,
and
there
are
lots
of
other
ones
in
the
community
which
are
great
and
exciting
to
see
yeah.
A
B
So
yeah
quick
overview.
What
cups
does
so
a
easy
for
the
user,
but
very
very
opinionated
way
of
building
clusters
on
AWS
and
GCE
and
other
ones
in
the
future.
So
the
sort
of
user
experience
you
cups.great
cluster,
the
DNS
name
with
my
cluster
here
we're
doing
a
one
with
three
masters
and
we
want
to
run
all
three
masters
in
one
zone
in
AWS.
B
The
big
items
on
the
roadmap
so
currently
cops
combines
everything
into
one
sort
of
mega
opinionated
system
and
sort
of
working
on
splitting
it
out
into
components
and
becoming
more
modular.
You'll,
see
this
sort
of
lines
up
a
lot
with
the
cluster
lifecycle
goals,
so
that
the
hope
is
to
sort
of
provide
those
as
as
opinions
or
and
options
that
we
can
consider
for
for
the
cluster
API.
So
the
sorry
for
the
cluster
lifecycle
work
items.
So
obviously
we
want
to
adopt
the
cluster
Machines
API.
B
The
machines
API
itself
will
be
much
easier
for
cops
to
adopt
because
then
the
cluster
API,
so
the
machines
API,
is
really
what
we're
focusing
initially
cops
has
an
add-on
manager
for
better
or
worse,
that's
built
into
it
right
now.
It
would
be
great
to
share
some
of
our
positive
and
negative
learnings
about
that,
and
you
know
sort
of
make
some
progress
on
add-on
management.
One
of
the
big
goals
I
think
about
our
management
is
to
take
that.
B
If
we
get
a
good
at
our
manager,
we
don't
have
to
worry
as
much
about
add-ons
in
cluster
lifecycle.
In
other
words,
the
idea
is
to
to
build
the
framework
so
that
we
don't
have
to
update
cops
every
time
a
new
calico,
like
version
comes
out,
which
is
the
current
situation
and
is
sort
of
not
a
very
great,
not
a
great
situation
to
be
in.
So
we
want
to
sort
of
make
that
a
generic
add-on
manager
across
all
the
tooling
at
CD
Manager.
We
need
something
to
operate
at
CD.
B
Cups
has
one
built
in
and
we're
working
on,
splitting
that
out
to
be
more
generic
and
reusable
and
powerful.
So
what
I?
Actually,
to
allow
upgrades
as
well
that's
a
lot
of
the
cups
users
are
using
at
CD.
Most
coughs
users
are
using
head
CD
two
because
of
sort
of
that
timelines
of
when
people
started
using
cups
and
when
cups
started,
and
we
are
sort
of
leading
the
or
working
on
the
working
on
the
work
to
get
from
Ed
CD
to
to
at
CD
three.
A
Well,
we
want
to
get
things
into
a
GI
State,
of
course,
and
get
them
more
more
production
ready
and,
for
example,
cubed
M
is
right
now
in
a
beta
state,
and
it
has
been
that
for
a
year
in
order
to
graduate
it
to
general
availability.
We
need
basically,
the
components
configuration
that
I
talked
about
earlier.
A
There's
like
one
component
configuration
for
each
component
in
kubernetes,
but
most
of
these
are
in
the
alpha
stage
right
now,
because
the
community
in
general
hasn't
really
had
decided
on
the
exact
format
or
structure
of
these.
This
configuration
types,
and
in
order
for
for
us
to
promote
cubed
and
to
GE,
we
have
to
have
these
components
configuration
types
at
least
in
the
beta
state,
so
people
can
rely
on
them
for
cube
atoms
configuration
in
turn.
A
So
that
is
one
thing
we're
working
on
with
the
rest
of
kubernetes
community
and
then
the
cluster
API
spec
itself
would
be
nice
to
have
him
beat
a
shape.
Probably
later
this
year
and
yeah
component
configuration
as
I
talked
about
together
with
the
rest
of
rest
of
the
community,
and
then
Ziggler's
life
cycle
also
deals
with
documentation
as
everyone
else
and,
for
example,
things
we
want
to
improve
still
is
our
recommended
cluster
parameters.
So
what
is
what
is
the
recommended
configuration
for
a
tree
master?
Ten
node
cluster,
for
example?
A
Last
year
we
created
a
guide
on
companies,
IO
ducts
to
how
you
can
create
a
H,
a
cluster
with
Q
Batum,
and
that
is
I
mean
there's
always
room
for
improvement
there
to
streamline
that
flow,
even
more
and
in
gem,
more
in
general,
talk
about
what
how
we
could
make
Bonet
sha
a
bit
simpler
and
then
external
dependencies
are
all
like.
There's
a
lot
of
external
dependencies
for
kubernetes
like
the
runtime,
sometimes
even
for
Copsey
deals
with
the
hallways.
A
A
And
so
how
can
you
contribute
to
the
cig?
We
have
a
document
where
we
still
need
to
fill
in
some
some
cop
stuff
and
cluster
API,
but
you
will
will
share
these
slides
afterwards,
so
you
can
find
link
and
also
you
can
find
it
from
other
cyclists
lifecycle
documents
from
kubernetes,
slash
community
we're
working
growing,
the
number
of
contributors,
contributors,
reviews
and
approvals
to
scale
the
cig.
We
have
office
hours
for
cups
by
week,
laces
on
Fridays
every.
A
For
Cuba
name
is
every
Wednesday
as
far
as
I
know,
and
the
sig
meeting
itself
is
on
Tuesday
you'll
find
the
exact
time
in
your
time
zone
on
the
kubernetes
community
repo,
and
then
we
have
kubernetes
cubed
and
for
tracking
cubed
M
issues.
Eventually
we'll
move
out
the
code
there
after
our
release
process
has
it's
more
flexible
to
multiple
repulsed
and
then
we
have
so
that
we
have
like
milestones
for
each
release.
A
A
A
We
have
eight
minutes
left
and
for
for
questions
related
talks
or
I
have
a
talk
on
what
is
a
production
ready,
what
a
could
be
considered
a
production
ready
cluster,
some
thoughts
about
that
and
what
it
actually
means,
because
it's
a
like
production
ready,
it's
a
buzz
word
like
people
throw
around
it
a
lot.
But
what
is
the
meaning
and
do
we
actually
agree
with
it
with
each
other?
What
a
production
rather
cluster
means
is.
Could
we
find
some
kind
of
definition?
A
B
B
A
Here
are
a
lot
of
links.
You
can
join
us
on
slack,
that's
where
the
well.
The
much
of
the
much
of
the
communication
is
happening
where
we
concluded.
We
have
already
five
different
channels,
so
you
should
be
able
to
find
us
somewhere
at
least
we've
written
some
blog
post
on
Renee's
blog
latest
in
general
and
August
last
here,
there's
documentation
and
yeah.
Our
meeting
notes
is
a
good
source
of
information.
What
we're
thinking
about
doing
at
this
time!
D
Questions
thanks
so
I
think
Google
maintains
these
is
useful,
yum
and
app
repose
for
cubelet,
acute
control,
etc
and
I've
only
seen
them
referenced
in
the
cube.
Atm
guys
and
I
was
wondering
if
those
repos
are
associated
with
with
the
sig
or
sort
of
who
owns
them.
You
know,
but
maybe
that's
maybe
that's
kind
of
an
off
topic
question
but
sorry
who
owns
which
repo
those
abdun
and
yum
repos
is,
does
the
sig
own
them
or
is
that
just
kind
of
a
you
know?
Google.
A
Repo,
so
I
mean
ownership
is
hard,
but
I
would
say
say:
class
lifecycle
owns
them
together
with
sig
release.
The
the
tricky
part
is
only
Googlers,
can
push
to
these
repos
and
actually
make
changes
so
we're
dependent
on
a
Googler
doing
releases
and,
for
example,
when
after
each
release
a
Googler
has
to
go
in
or
actually
let
us
change
now
yeah.
A
Now
it's
part
of
release,
formerly
it
used
to
be
like
we
release
one
eight
and
then
a
Googler
has
to
go
and
upload
the
Deb's
and
rpms
that
sometimes
took
like
20
hours,
and
then
people
were
confused
like
we
have
a
new
combination
but
new,
not
new
depths
and
rpms
and
I
want
to
try
it
now.
So
we
got
a
bug
issues
filed
for
that,
but
now
it's
streamlined
so
yeah.
B
A
B
The
background
is
like
we
need
somewhere
to
store
the
signing
keys.
Mm-Hm.
Currently,
Google
has
infrastructure
to
do
that,
so
they
stepped
up
I.
Think
there's
a
move
to
move
that
to
the
CN
CF
yeah,
and
that
will
help
with
the
multi
repo
type
scenario.
I.
Think
sig
release
is
the
one
that's
really
sort
of
driving
that
process.
It
would
be
more
consumers
of
that
effort,
but
yeah
it's
who
holds
the
secrets,
is
sort
of
the
problem.
B
A
E
B
So
I
mean
cops
in
cuba,
corn.
I
think
you
know,
I
don't
know
if
chris
is
here,
I
don't
see
her
but
they're
different
toolings
with
different
opinions,
I
think
I
I
think.
The
hope
is
that
every
all
the
installation
tools
like
it's
not
just
cops
in
Cuba
coin,
there's
a
you
know
a
whole
bunch
of
them
and
I
think.
The
hope
is
that
we'll
all
use
that
API
I
mean
I
can
speak
to
the
like
cops.
B
Has
our
own
API
types
currently,
so
it's
definitely
gonna
be
non-trivial
to
figure
out
how
to
do
that
without
breaking
existing
users.
I
I,
don't
know.
I
would
hope
that
my
hope
is
that
if
I
remember
now,
I
had
cops
as
the
last
little
like
thing.
There
is
because
the
idea
is
that
the
things
that
will
be
left
in
cops
will
be
so
small
that
the
tooling
will
be.
You
know
pretty
trivial,
so
the
hope
at
least
for
cops
is
that
cops
essentially
becomes
a
very
thin
shame
over
commodity
kubernetes
components.
B
C
F
G
So
I
have
the
question
about
the
cluster
API
and
the
types
there.
So
you
have
these
machine
deployment
and
control
for
that
which
creates
machines.
Guy
said,
then,
machines
guy
said
controller,
creates
machines,
and
then
the
implementation
has
to
deal
with
the
machines,
and
this
is
provider
specific.
Let's
say
so:
is
it
possible
for
the
implementation
to
use,
for
example,
as
your
scale
size
or
AWS
after
scaling
groups?
How
does
it
fit
with
the
design
and
is
there
a
plan
for
that.
B
H
H
Mccain
group,
so
for
I,
mean
it's
very
hard
to
to
provide
this
behavior.
That
is
a
requirement
for
the
for
the
for
this
automation.
So,
and
the
problem
is
that
if
you
have
to
implement
the
Machine
set
for
four
different
cloud
providers
and
with
having
only
the
Machine
creation
and
deletion
and
open
operation
implementation,
it's
much
easier.
H
F
B
B
It
would
be
to
try
to
make
it
so
that
we
lose
that
tight,
binding,
we're
the
API
server
currently
talks
to
at
CD
on
localhost
and
doesn't
have
to
sort
of
discover
at
CD,
and
that
will
then
make
it
easier
to
get
that
in
to
end
and
testing
and
then
we're
going
to
figure
out.
You
know
what
happens
to
performance
because
it
is
you're
right.
It
is.
It
is
an
issue
that
they
are
co-located
and
you
have
to
scale
them
together.
B
I
guess
the
question
is:
is
it
going
to
be
better
to
just
scale
it
up
or
just
you
know,
separated
them
out
and
I
think
I.
Think
core
OS
was
a
big
proponent
of
running
them
separately.
If
I
recall
correctly,
I,
don't
know
you
want
to
give
some
background
on
your
question,
but
I
I
think
there'll
be
a
great
way
to
get
involved.
If
you're
interested
in
getting
involved
but
yeah
getting
an
under
testing
would
be
a
great
first
step.
I
B
Can
you
repeat
the
question
of
yes
so
I
think
this
is
about
moving
the
cloud
provider
controllers
out
of
coop
controller
manager
into
I?
Guess
a
per
cloud
provider
per
cloud
provider,
cloud
controller
manager
and
the
question
was:
is
there
other
plans
to
enforce
that
insig
cluster
life
cycle
is
essentially
to
require
it
yeah.
A
So
cloud
provider
refactoring
work
group
was
formed
for
exactly
this
possible
purpose.
Last
fall
and
they
have
been
doing
great
work
so
far
and
work
is
ongoing
to
split
it
up
to
different
repos.
They
exact
name
or
place
of
the
repos
and
as
far
as
I
know
decided
fully
upon
yet,
but
there
is
an
the
the
current
situation
is
deprecated
and
we're
looking
to
run
the
cloud.
A
The
cloud
specific
controllers
in
this
cloud
controller
manager
only
and
I'm,
working
with
the
rest
of
the
community
to
work
out
edge
cases
like
improving
the
node
registration
process
in
a
way
that
is
flexible
enough
for
a
controller
to
to
deal
with
them,
and
things
like
that.
But
yeah
plans
are
to
enforce
the
move
out,
but
we
don't
know
exactly.
When
is
that's
gonna
happen?
This
we
have
to
support
the
current
uses
for
a
pretty
long
period.
I
think
it's
one
year
the
force
table
features
income
analyst,
the
replication
buyer
is
one
year.