►
From YouTube: Intro: SIG Cluster Lifecycle - Timothy St. Clair, VMware
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
Intro: SIG Cluster Lifecycle - Timothy St. Clair, VMware
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 focused on creating kubeadm, a streamlined installer tool and building block to simplify the installation and upgrade experience, and building a Cluster API to provide an abstraction of machines across different deployment environments and 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.
https://sched.co/Uajp
A
Right
so
I
don't
get
started
here
so
welcome
and
thank
you
for
attending
the
I.
Don't
even
know
how
many
sessions
that
I've
done
of
this
of
the
introduction
to
say
cluster
lifecycle
I
am
one
of
the
co-chairs
of
the
seed
cluster
lifecycle
inside
of
the
community
I'm.
Also
a
member
of
the
steering
committee
we've
been
at
this
game
for
a
long
time.
So,
if
you're
new
to
the
community,
welcome,
it's
always
good
to
see
new
faces
and
to
get
new
people
involved.
So
what
I'm
going
to
talk
about
today?
A
We're
gonna,
give
you
an
overview
of
broad
strokes
of
what
sig
coaster
life
cycle
does
what
are
the
key
sub
projects
that
are
involved
where
to
find
more
information,
there's
a
lot
of
other
talks
that
are
going
on
in
this
conference.
So,
if
you're
interested
in
a
particular
topic
area,
they'll
try
to
drop
as
many
details
as
I
can
for
the
other
areas
and
last
but
not
least,
is
how
to
get
involved.
The
community
is
basically
everyone
who
comes
to
these
meetings.
A
Everyone
who
comes
to
the
event
who
wants
to
contribute,
write
the
what
makes
kubernetes
better
is.
Is
the
community
being
involved
inside
of
the
activities
of
what
we're
trying
to
design
and
develop?
We
need
you
to
keep
us
honest
right
if
something
doesn't
work.
The
way
you
wanted
to
your
feedback
is
critical
to
making
the
product
or
the
project
itself
successful.
A
So
what
exactly
is
a
cluster
lifecycle?
Every
single
cig
inside
the
kubernetes
community
actually
has
a
charter
or
a
mission
statement.
The
mission
force,
a
cluster
lifecycle,
is
to
simplify
the
creation,
configuration
upgrade
downgrade
and
teardown
of
kubernetes
clusters
and
their
components.
So,
ideally
we
want
to
commoditize
the
deployment
of
kubernetes
clusters.
Make
it
simple
make
it
secure,
make
it
everywhere
right.
We
don't
want
to
have
prevent
the
path
prevent
the
problems
that
happen
in
the
past.
A
So
if
you
look
at
other
clustering
software
in
the
past
and
how
those
open-source
ecosystems
evolved,
you
often
found
that
one
vendor
would
try
to
pit
themselves
against
another
vendor
with
just
a
distribution
of
software
right
of
the
base
core
piece
of
component
tree.
We're
trying
to
avoid
that
by
creating
a
tool
set
or
a
tool
chain,
that's
composable
that
anyone
can
build
their
own
set
of
installers
or
opinionated
solutions,
the
top
of
it.
A
A
The
the
idea
is
that
you
want
to
be
able
to
not
care
about
which
infrastructure
you're
landing
on
at
all
and
make
it
ubiquitous
so
that
way,
kubernetes
the
promise
of
corinne
ities
is
that
you
can
run
your
workloads
anywhere
across
any
provider
across
any
infrastructure
right
and
by
creating
that
unifying
set
of
tools
or
abstraction
layers
that
we
can
do
for
deployment.
It
simplifies
the
spreading
the
base,
so
that
way
you
can
leverage
it
across
different
providers.
A
We
want
to
develop
declarative,
API,
driven
kubernetes
deployments.
That's
part
of
what
the
mantra
of
cluster
API
is.
We
want
to
be
able
to
use
the
same
primitives
practices
and
processes
that
we
use
inside
of
communities
for
the
actual
creation
of
kubernetes
clusters
themselves,
make
managing
clusters
as
easy
as
managing
a
pod
deployments
across
all
providers.
A
So
if
you
can
roll
an
upgrade
for
your
pod
deployment
and
have
a
canary
add
deploy,
we
want
to
be
able
to
do
the
exact
same
thing
for
clusters
themselves
and
avoid
the
pitfalls
of
yesteryear,
like
I,
mentioned
before,
by
creating
a
set
of
tools
that
are
individual
atoms.
That
are
reusable
components.
It
allows
us
to,
you
know,
have
a
set
of
installers
throughout
the
ecosystem
that
leverage
key
pieces
of
the
infrastructure
that
we
create.
A
One
of
the
other
key
driving
principles
or
part
of
the
vision
is
to
make
the
80%
use
case
simple,
but
the
20%
use
case
possible.
So
anyone
who's
worked
or
looked
at
kubernetes
cluster
deployment.
There's
a
lot
of
knobs
in
there
right
and
it's
a
lot
to
manage
and
think
about.
So
we
want
to
provide
same
defaults
that
are
reasonably
secure
for
the
80%
use
case,
but
also
make
customization
and
the
optimization
available
for
those
who
want
to
be
able
to
do
it
and,
as
mentioned
before,
spread
the
base
far
and
wide.
A
So
here's
kind
of
the
overview
of
the
componentry
of
the
stack
of
sequester
lifecycle
like
we
are
one
of
the
largest
SIG's
inside
of
the
Karoo
naze
community.
We
have
several
sub
underneath
our
banner
umbrella.
Alright.
So
when
you
look
at
the
top
of
the
stack
when
you
seek
aids
clustered
provisioners,
there
are
many
of
them.
There
are
several
of
them,
but
what's
underneath
the
hood,
how
is
it
composed
at
the
base
level
layer?
A
A
What
we
want
to
do
is
we
don't
want
to
maintain
the
code
inside
of
Ruby
Dee
and
proper,
which
we
actually
manages
the
lifecycle
of
it
city
today,
we'd
like
to
abstract
that
away
into
its
own
separate
tool
and
then
have
kubja
DM
leverage,
the
binaries
and
artifacts
and
libraries
from
Etsy
dat
M,
then
there's
cuvee
DM,
which
is
the
the
who's
heard
of
Covidien.
By
the
way
most
people
know
a
lot
all
right,
so
that's
the
main,
that's
the
main
central
project
that
has
the
most
limelight
at
least
today
for
the
for
the
cig.
A
It's
basically
the
universal
bootstrapper.
It
allows
you
to
bootstrap
your
control
plane
and
your
cluster
very
very
easily
outside
of
that,
our
cluster
add-ons.
These
are
the
key
components
that
we
are
required
to
make
a
cluster
operational
things
like
DNS,
the
coop
proxy.
You
can
even
think
of
CNI
2
as
well.
On
top
of
that
is
the
cluster
API.
This
is
a
declarative
way
to
manage
your
entire
deployment
of
your
clusters,
as
I
was
mentioning
earlier.
That's
the
that's
part
of
the
endgame,
but
you
know
it's
not
the
end
endgame
then.
A
The
whole
idea
is
that
every
single
one
of
these
tools
or
components
can
then
be
used
individually
by
your
individual
provisioners.
So
if
you're
a
company
who
has
a
highly
opinionated
security
view
of
the
world,
you
can
take
any
one
of
these
components
and
deploy
them
in
your
infrastructure
and
create
your
own
provisioning
system
right
and
a
lot
of
people
do
that
today.
So
you
see
it
used
in
several
other
tools
across
the
ecosystem
and
to
the
right
there
is
image,
minting
or
image
Stamper.
A
If
you're
not
doing
image
minting
and
immutable
deployments,
I
highly
recommend,
taking
a
look
at
that.
So
what
makes
the
tool?
What
are
the
guiding
principles
that
we
use
to
create
tools
for
the
tool
chain
and
sequester
lifecycle?
It's
basically
following
UNIX
philosophy
right
make
each
program.
Do
one
thing
well
set
explicit
boundary
lines
about
what
the
tools
should
not
do.
Seda
DM
was
born
out
of
the
fact
that
we
don't
want
to
manage
this
inside
of
rubidium.
A
We
don't
feel
like
we
feel,
like
rubidium
scope
has
gone
a
little
bit
too
far
than
what
we
feel
comfortable
for,
so
we
want
to
take
those
pieces
out
of
both
at
CDA
DM
into
sed
diem,
as
well
as
push
him
into
cluster
add-ons,
so
there's
pieces
of
that
that
we
would
like
to
see
pushed
in
two
separate
locations
setting
angles.
There's
there's
a
joke
that
a
friend
of
mine
made
a
long
time
ago
as
he
space.
A
If
he
says
every
computing
infrastructure
project
that
eventually
meets
one
need
well,
eventually,
expanding
scope
to
meet
several
needs
poorly
right.
This
is
very
common
right.
You
start
out
with
one
tool
all
of
a
sudden.
It
just
becomes
this
balloon
monolithic
thing
that
does
nothing
well
right,
so
we're
trying
to
explicitly
not
do
that
in
the
community.
Each
tool
is
bounded
in
scope.
A
Initially
from
its
inception,
before
some
project
gets
added
onto
the
thing,
we
make
sure
that
it
has
a
set
of
non
goals,
and
then
you
know,
UNIX
philosophy
expect
the
output
of
one
program
to
be
used
as
the
input
of
the
other
program
so
together
when
they
use
them
all.
Together,
that's
when
you
form
Voltron,
that's
the
Voltron
moment,
so
here's
a
pseudo
example,
it's
very,
very
high-level
and
abstract,
but
it's
enough
to
give
you
the
idea
of
how
the
workflow
can
work
in
your
environment
right.
A
So
if
I
went
back
a
couple
of
slides,
one
thing
I
didn't
mention,
which
is
the
image
stamper,
which
is
on
the
right,
so
you
can
have
a
CI
infrastructure
which
is
constantly
monitoring
your
OS
distribution
or
the
stack
component
tree
that
you
have
to
basically
mint
a
new
image
all
right
so
that
kicks
off.
Whenever
you
see
a
new
update,
CVE,
whatever
you
name
it
it
midst
the
new
image
for
you,
then
part
of
that
could
be
a
notification
to
whatever
system
you
have
to
your
op
system.
A
To
let
you
know
that
a
new
image
has
been
created
and
a
new
cluster
manifest
has
been
generated
with
that
new
image
as
part
of
the
cluster
manifest
right
from
there,
you
can
actually
roll
out
a
new
update
through
Cappy
part
of
the
cap.
You
roll
out
an
update
is
basically
includes
new
KB
Kubb
ATM
bits
and
they
use
the
enjoy
and
it's
part
of
the
actual
control
plan
flow.
So
here's
like
a
pseudo
moment
where
all
the
pieces
of
the
puzzle
kind
of
flow
together.
A
Alright.
So
let's
talk
about
each
individual
sub
project,
so
kuba
DM
is
is
a
a
tool
whose
primary
function
is
to
set
up
a
best
practices
cluster,
whose
optimized
for
user
experience
right,
ku,
Vidya,
minute
and
joined,
should
work
on
day,
one
across
a
number
of
infrastructure
providers
and
just
work
and
be
simple
right:
it's
not
meant
to
take
on
management
of
infrastructure.
It
never
has
never
will
all
right.
That's
kind
of
one
of
the
implicit
non
goals
right.
A
It's
meant
to
deal
with
only
local
file
system
and
also
doesn't
take
on
the
cni
itself.
Right,
that's
a
s
and
after
effect
like
you,
can
apply
the
cni
after
you
have
actually
deployed
your
cluster
one
of
the
things
that
most
people,
don't
necessarily
recognize,
is
even
though
we
kind
of
tout
it
all.
The
time
is
that
Kuby
neum
is
brokering
up
into
a
set
of
phases.
Each
one
of
those
phases
are
reusable
sets
of
componentry
that
you
can
use
in
your
own
custom
installation
method.
A
If
there's
an
aspect
to
the
workflow
of
a
deployment
for
bootstrapping
that
is
specific
to
your
environment,
you
can
take
just
the
phase
you
need
in
order
for
you
to
actually
do
your
deployment.
If
you
want
to
do
certs
management,
there's
a
separate
sub
command
that
exists
for
certs
management,
you
can
take
every
piece
of
the
workflow
of
the
puzzle
that
it
takes
to
bootstrap
a
cluster
and
use
it
independently
of
one
another.
A
So
where
does
it
fit
in
the
picture
it
kind
of
fits
over
in
this
view,
I
know
Liz
hates
this
slide
so
much
with
a
fiery
passion,
but
it
allows
people
to
understand
a
view
of
the
world
right.
It's
it's
kind
of
at
that
bootstrap
layer
right
and
then
you
can
vision
your
your
your
infrastructure,
as
well
as
higher
level
tools
living
a
top
of
it.
A
So
what's
coming
up
in
cuvee
DM,
how
can
you
get
involved?
What's
interesting?
What's
new,
one
of
the
things
that
is
coming
up
is
simplifying
the
day
to
operations.
I'll
go
into
cluster
API
in
a
moment,
but
cluster
API
is
meant
to
be
immutable.
Kubb
ADM
is
meant
to
have
that
ability
to
mutate,
so
immutable
infrastructure
basically
means
like
you
shoot
your
machines.
They
go
away
right.
You
shoot
your
images
on
your
machines.
Immutable
infrastructure
is
I
want
to
just
deploy
a
patch
set
or
a
minor
revision.
A
Update
that'll
occur
across
my
infrastructure
right
so
to
simplify
day
two
operations,
we're
looking
at
creating,
what's
called
a
cube,
ATM
operator
right,
the
ability
to
actually
do
my
toe
patch
updates
across
your
infrastructure
in
a
rolling
fashion.
Okay,
there's
a
number
of
other
options
and
things
that
we
want
to
do
with
cuvee
diem
in
the
future
machine,
readable
output.
A
Last
but
not
least,
we're
trying
to
move
could
be
any
amount
of
tree
this
for
people
who
are
not
familiar
with
kubernetes.
If
you
look
at
the
codebase,
it's
very
much
a
monolith
and
what
we
want
to
do
is
we
want
to
isolate
the
dependencies
in
the
dependency
management,
as
well
as
the
versioning
apparatus
for
crew
medium,
so
that
it
could
be
at
a
faster
clip.
A
If
you
want
to
know
more
about
Covidien
for
breach,
CEO
who's
over
there,
you
can
ask
questions
of
him
later
and
Yago
are
gonna,
be
doing
a
deep
dive
on
Thursday
it's
from
320
to
355,
I
highly
recommend
going
and
they'll
give
you
all
the
lowdown
and
details
much
more
than
what
I've
given
you.
So,
what's
another
key
sub
project
of
say,
cluster
lifecycle,
the
second
probably
most
high-profile
sub
project
that
exists
is
cluster
API,
whose
it
has
heard
or
knows
what
cluster
API
is
wow.
It's
a
lot
more
than
I
thought.
Okay,
it's
it's!
A
A
This
is
the
lifecycle
of
all
the
associated
infrastructure
around
that
deployment
and
currently
there
there's
an
able
miss
for
multiple
bootstrap
providers
within
the
side
of
there,
but
the
primary
default
one
is
cube
ADM,
but
that's
the
another
notion
that
we
have
inside
of
the
cig
is
that
batteries
are
included
but
swappable.
So,
where
possible,
we
try
to
make
sure
we
have
seen
defaults,
but
if
a
provider
decides
that
they
would
like
to
have
their
own
mechanism
for
bootstrapping,
we
always
want
to
make
sure
that
we
enable
that.
A
Last
but
not
least,
is
the
deployment
of
of
cluster
api
is
immutable.
It's
an
immutable,
node
infrastructure
deployment.
So
the
idea
is
that
you
drain.
If
you
want
to
do
a
rolling
update
of
your
cluster,
you
basically
corn
and
drain
your
nodes,
then
delete
that
node
and
then
a
new
node
that
will
come
online
with
the
new
version
of
the
software
stack.
A
What
it
is
not
a
lot
of
times
when
you
look
at
cluster
API,
the
name
is
kind
of
a
misnomer.
It's
not
the
best
name
like
whenever
you
try
to
name
something
bidding.
Sometimes
you
always
regret
it
later
on.
It
is
not
just
an
API,
it's
call
most
kind
of
like
a
framework
so
but
it
is
definitely
not
a
cub
abstraction
layer.
We
are
not
trying
to
abstract
or
wrap
the
details
of
a
cloud
provider.
A
We
are
trying
to
provide
if
a
facility
or
means
or
a
set
of
patterns
that
we
can
use
to
generate
or
create
clusters
in
a
similar
fashion,
as
I
mentioned
before
it's
immutable,
so
there's
no
in
place
upgrades,
but
that
doesn't
mean
that
you
can't
use
other
tools.
The
top
of
it
you
can
create
your
own
operator
use
the
Cabrini
operator
where
she'll
come
next
year.
So
what
are
the
core
pieces?
A
It's
meant
to
be
a
replica
of
a
lot
of
the
core
component
area
that
exists
inside
of
kubernetes,
so
machine
deployments
machine
sets
and
then
there's
the
cluster
object
itself
over
time.
We
we're
adding
more
components,
read
there's,
there's
other
pieces
that
are
missing
from
here,
but
this
gives
you
the
basic
premise
of
why
this
pattern
sort
of
repeats
itself
over
right.
So
you,
if
you
think
of
a
machine
set,
you
should
think
of
a
replica
set.
You
know
machine,
a
pod,
etc.
A
There's
the
machine
pool
work
that
Microsoft
has
been
working
on
and
there's
the
intent
testing
framework
and
infrastructure
and
there's
cluster
cuddle
v2
cluster
cuddle
v2
is
meant
to
be
a
means
by
which
you
can
do
cross
provider
workflow
in
a
similar
fashion.
So
one
of
the
things
that
is
hard
across
providers
is,
you
can
never
have
the
abstraction
layers
the
same,
but
you
can't
have
a
workflow,
that's
the
same
so
long
as
you
have
a
way
of
record
of
registering
and
generating
for
those
different
providers.
A
So
folks
are
working
really
hard
to
optimize.
The
user
experience
there's
a
bunch
of
things,
even
technical
debt
that
was
created
as
far
as
UX
goes
in
v1,
alpha,
2
and
part
of
this
could
be
from
defaulting
write
as
a
lot
of
times.
We
have
explicitly
set
parameters
inside
of
there
which,
for
the
80%
use
case,
it
should
be
a
default
right.
That's
specified
all
throughout
folks
are
working
in
building
test
automation
if
you're
interested
in
that
it.
If
you're
interested
in
any
of
this,
please
come.
A
Let
us
know
afterwards
and
we'd
be
happy
to
help
get
you
involved
in
the
community,
but
the
build
test.
Automation
is
kind
of
a
little
funny.
We
are
building
a
set
of
core
technologies
that
are
basically
meant
to
add
a
way
to
automate
away
a
lot
of
your
IT
operations
right,
but
we
as
a
community
or
not
necessarily
good,
at
building
the
automation
that
builds
the
automation
to
deploy
and
manage
our
our
code.
A
So
we
need
help
there
we
in
the
next
year
or
so
will
be
also
focusing
a
lot
of
our
effort
towards
shorter
drive
towards
a
beta
release.
So
we
want
to
make
sure
that
we
are
setting
ourselves
up
for
long
term
support
capabilities
so
that
we
do
a
lot
less
churn
getting
to
getting
across.
Multiple
alphas
is
hard.
It's
like
every
part
of
a
problem
about
working
on
something
that
crosses
so
many
providers,
and
so
many
domains.
A
Is
that
there's
a
lot
of
opinions
so
that
way,
it
takes
a
little
bit
of
time
to
settle
those
opinions
down
to
get
us
on
a
good
trajectory
forwards.
So
hopefully,
by
the
end
of
next
year,
we
should
hopefully
be
in
a
beta
which
has
longer
term
support
guarantees.
Kubernetes
has
well-defined
notions
of
what
halfa
and
beta
and
Gi
support
equals,
as
well
as
adoption
goals
for
the
next
year.
So
getting
it
incorporating
the
cops
for
those
who
are
interested
in
Azure.
A
They
have
been
very
helpful
in
trying
to
get
the
the
cap
Z
provider
up
to
stuff
and
last
but
not
least,
a
near
journey
under
my
heart,
I
would
love
to
replace
the
slash
cluster
directory,
kill
the
fire,
because
it's
been,
it's
been
an
anthem
ax
and
has
existed
in
perpetuity
since
the
beginning
of
the
project.
No
one
likes
it.
It's
just
been
lingering
around
forever.
A
So
if
you
want
to
learn
more,
if
you're,
if
you
have
questions
afterwards,
Vince
in
Anish
ashish
is
going
to
are
going
to
have
a
deep
dive
on
thursday
or
feel
free
to
hang
out
a
little
bit
afterwards.
We
can
answer
any
questions
you
might
have
one
of
the
other
key
sub
projects
that
kind
of
ride
across
all
of
our
componentry
is
component.
Config
component
thing
is
hard:
it's
like
very,
very
hard,
as
I
mentioned
before.
A
If
you
look
at
the
total
flag
set
that
exists
across
all
the
components,
it's
on
the
order
of
like
six
to
seven
hundred
different
flags
across
all
the
components.
What
we're
trying
to
do
with
component
config
is
unify
and
create
a
standard
API
for
how
we
deal
and
manage
with
these
things.
It
is
hard.
It
is
not
easy.
It
takes
a
very
long
time.
A
It's
like
wrangling
cats,
but
in
the
the
way
the
kubernetes
community
works
and
the
way
the
infrastructure
works
is
that
there
are
separate
owners
for
a
lot
of
these
different
components
and
sometimes
you're
changing
one
or
all
of
them
at
any
time,
you're
making
a
change,
and
that
requires
a
lot
of
buy-in
to
make
it
happen.
I
know
I'm
really
selling
this
to
you,
but
it
is
probably
the
most
important
aspect
in
my
opinion,
for
the
long-term
health
of
the
componentry,
and
we
need
help
there.
A
We
need
people
in
the
community
who
can
chop
the
wood
and
carry
the
water
and
can
make
this
change.
If
you
want
to
earn
your
stripes
in
the
community,
you
will
get
double
gold
stars.
Your
you
will
be
on
top
of
the
stage
with
a
chop,
wood
and
carry
water
award.
If
you
help
on
this
effort,
so
component
country
component,
config
I,
could
go
on
forever,
like
I
have
slides
which
talk
about
it,
but
in
reality
the
the
TLDR
component
of
fig
is
that
you
want
to
be
able
to
just
treat
it
like
an
api.
A
You
want
to
have
a
well-defined
declarative
set
of
configuration
knobs
that
you
can
apply
to
a
component.
That's
the
magic,
some
of
those
some
of
the
components
already
have
it.
Some
do
not
so
getting
getting
them
to
an
actual
beta
or
GA
state
is
where
we
want
to
end,
because
every
time
these
things
churn,
they
also
affect
the
rest.
They
ripple
through
the
rest
of
the
system.
So
if
we,
if
we
can
get
those
things
to
GA
and
well-supported
versions,
then
we
can
have
a
lot
less
churn.
A
I
didn't
go
too
deep
into
other
provisioning
tools.
Remember
that
that
top
bar
the
slide
that
deck
that
I
had
originally
at
the
beginning
was
the
different
types
of
provisioners.
So
there
is
a
separate
talk
or
a
deep
dive
for
cops
by
just
in
Santa
Barbara
on
Thursday,
there's
also
a
deep
dive
for
mini
cube
by
Thomas
and
midea.
B
A
All
of
these
different
components
are
in
a
different
state
right,
there's
still
a
lot
of
work
to
do
to
build
Voltron
in
its
true
form.
Right
right
now,
it's
kind
of
like
it's
a
half
Voltron.
There
might
be
a
couple
of
dead,
robot
cats
somewhere,
but
we're
trying
to
build
it
again
right,
it's
hard
to
do
it's
really
hard
to
do
so.
A
Cluster
API
is
still
in
alpha
state
cube.
Atm
is
in
GA
it's
possibly
the
most
mature
one.
Other
cost
of
provisioners
are
also
very
mature
that
exists
inside
the
ecosystem,
but
we
need
your
help.
So
a
good
way
to
get
involved
is
there
is
a
recording
that
we
did
a
lot
while
ago
of
a
new
contributor
onboarding,
which
kind
of
walks,
through
all
the
details,
goes
through
the
philosophy,
the
ideas,
how
things
evolved,
etc,
etc.
A
A
It
seems
intimidating,
I
get
that
right,
but
once
you
start
contributing
in
your
ask
questions
you'll
find
that
everyone
that
works
on
this
is
super
enthusiastic
to
have
people
get
involved
like
you
want
to
help
fix
this
bug
and
I
don't
have
time
to
fix
it.
Yes,
please
thank
you.
That's
you're,
helping
us
right.
A
So,
if
you're
interested
in
getting
involved,
I
recommend
navigating
to
the
community
page,
we
have
a
listing
details
of
all
the
different
sub
projects
for
cig
cluster
lifecycle,
as
well
as
their
meeting
times
all
the
other
details
about
where
you
can
send
emails
to
what
are
their
slack
channels,
how
we
communicate
how
we
work
right,
sometimes
being
a
lurker,
isn't
a
bad
thing
if
you
want
to
get
involved,
so
take
a
look
at
the
different
repos
for
the
different
sub
projects.
Look!
A
What
are
good
first
issues
see
how
the
different
sub
projects
operate
like
go,
to
go,
to
attend
a
meeting
and
then
every
now
and
then
say
I
would
like
to
work
on
something.
No
one
will
say
no
to
you.
No
one's
gonna
be
angry
for
somebody
to
say
you
know,
please
don't
work
on
this,
so
if
it's
marked
as
good
first
issue
or
Help
Wanted,
we
could
use
your
help
and
I
get
as
I
mentioned
before
everyone
in
the
community
who
who
sees
someone
who's
new.
A
We
actually
welcome
them
into
the
fold
and
we
try
to
even
do
a
separate
little
session
or
intro
section
if
they're
interested
in
coming
along
also
feel
free
to
introduce
yourself
on
slack.
Even
if
he's
just
for
questions,
that's
an
okay
thing
now
I
do
recommend
not
asking
a
lot
of
user
facing
questions
all
the
time
on
slack.
There
are
separate
channels
for
that.
A
So,
if
you
inundate
the
developers
with
the
user
facing
questions,
sometimes
they
have
a
tendency
to
turn
it
off,
because
sometimes
it's
better
to
go
to
the
user
communities,
because
users
will
help
users
right.
If
you
are,
if
you're
a
cooperate,
kuba
TM
user
I
highly
recommend
going
to
the
cuvette
dium
channel.
A
There
is
a
lot
more
information
if
you
want
to
become
a
contributor
to
as
well
inside
of
the
kinetics
group,
so
you
can
go
there.
They
have
a
whole
tutorial
and
set
for
how
to
get
involved
in
the
community
beyond
what
we
do
inside
the
sig
itself,
and
the
mantra
that
you
heard
at
the
main
stage
in
the
keynote
is
that
we
chop
wood
carry
water.
You
earn
your
stripes
in
the
community
by
doing
the
work
right
we
are.
A
One
of
the
things
that
kind
of
frustrates
is
frustrating
as
a
developer
or
maintainer
is
that
some
people
will
come
in
and
have
an
expectation
that
this
should
work
like
this
right
and
we
understand
that
and
it
might
be
frustrating
for
you.
But
a
lot
of
the
people
here
are
doing
multiple
things
at
once.
A
It's
a
community,
so
please
be
kind,
be
mindful
that
everyone
here
is,
is
probably
pulling
double
duty
or
triple
duty
on
some
things
right
in
order
to
make
this
community
be
what
it
is
today,
but
last
but
not
least
like
I
mentioned
before,
when
you
chop
wood
and
you
carry
water,
your
social
capital
that
you
earn
is
is
how
is
how
the
community
flows
right?
Your
trust
that
you
earned
your
stripes
are
your
the
bars
you
get
inside
the
community.
A
Last
but
not
least,
thank
you.
Thank
you
for
taking
the
time
to
come
in
the
intro
session.
If
there
are
any
questions
that
you
might
have
feel
free
to
ask
them,
I
only
ask
that
just
raise
your
hand
say
the
question
and
I'll
try
to
repeat
it
for
the
recording
and
then
we
cannot
I
can
answer
for
you
good.
A
A
The
question
was:
is
Kappa,
which
is
cost
rate,
prefer
cluster
API
provider
AWS?
Is
that
a
is
that
a
mature
thing,
yet
I
would
recommend
tinkering
it
if
people
are
using
cluster
API
today,
my
recommendations
are
typically
to
wrap
the
behavior
of
cluster
api
behind
whatever
you
are
you
doing
on
your
infrastructure,
because
we
are
changing
so
so
some
people
may
have
adopted
and
being
honest.
This
is
a
community-based
project
which
has
alpha
in
the
title.
They
may
have
adopted
it
a
little
too
early
as
the
core
front
facing
piece
of
their
component
tree
once.
A
If
you
want
a
front
face.
A
lot
of
your
details,
I
think
alpha
3
is
the
most
mature
facing
things,
but
even
on
other
things
that
some
of
the
things
that
we
do,
we've
wrapped
the
behavior
so
that
there's
a
little
bit
more
of
a
friendly
front
facing
user
piece
that
it
that
exists
in
the
front
right.
So
that's
my
recommendation
for
at
this
stage,
but
about
v1,
alpha,
3,
I,
think
it'll
be
more
mature
and
we'll
probably
we're
gonna
have
a
roadmap
towards
beta
2
as
well
yep.
A
B
A
So
the
question
was:
it
is
immutability,
a
still
a
contentious
point,
I
think
for
some
of
the
people
it
is
in
the
community,
I
think
for
the
people
of
been
around
since
the
beginning,
cluster
API.
It's
not
I
think
there
are
two
separate
set
of
tools
or
ways
of
managing
this
and
there's
no
reason
you
can't
tie
them
together
right.
A
So
if
you
wanted
to
have
a
mutable
way
of
managing
this,
you
could
use
an
operator
style
model
that
did
the
modification
to
this
becker
status
inside
a
cluster
api
and
it's
basically
the
wrapping
view
of
cluster
api.
So
if
you
wanted
to
have
a
mutating
version
that
basically
did
in-place
upgrades,
you
do
an
operator
model
that
then
just
changes
the
spec
of
the
status.
Now,
if
you
wanted
the
immutable
model,
then
you
would
just
use
clustered
api
proper
to
be
just
roll.
The
update
itself.
A
A
So
usually,
if
somebody
wants
to
build
their
own
because
there
there
is
a
number
of
providers,
we
just
ask
that
they
PR
that
the
docs
updates
to
the
main
repo
one
of
the
things
we're
doing
as
well
is
like,
as
we
have
this
federated
set
of
repositories,
we
are
starting
to
develop
a
set
of
content
test,
Suites,
similar
to
the
way
coronet
eases.
So,
ideally,
we
want
to
have
a
set
of
conformance
tests
to
ensure
that
certain
behaviors
of
the
core
component
REO
cluster
API,
are
consistent
across
all
providers.
A
Yes,
I
highly
recommend
going
to
the
Diaa.
The
question
was:
have
people
enumerated
the
state
space
of
what
needs
to
get
done
in
component
config
and
what
are
the
key
areas
that
want
to
address?
Yes,
they
have.
They
have
done
the
hard
work
of
figuring
out.
What
are
all
the
pieces
that
need
to
get
done
and
what's
the
high
value
areas
they
want
to
address.
First
I
highly
recommend
going
to
the
deep
dive
and
talking
with
Michael
Towson.
A
A
Think
for
sure
we
will
get
to
beta
in
the
next
year?
Hopefully
we're
gonna
create
the
roadmap,
we're
actually
creating
the
road
back
now,
for
what
we
think
is
the
cut
line
for
beta
I'm
I'm
less
concerned
about
the
transition
to
GA.
What
I'm
concerned
about
the
transition
to
beta
the
way
API
is
evolved
inside
of
kubernetes
propers
the
support
guarantees
of
what
it
means
to
be
beta
or
GA,
usually
for
GA.
That
means
a
deprecation
cycle.
That
is
very
very
long.
A
So
we
might
tail
beta
to
be
a
little
bit
longer
because
we
might
want
to
make
a
set
of
changes,
but
we
will
always
support
the
upgrade
process
right.
So
you
even
support
the
upgrade
process
across
alphas
today,
right
and
well
now,
for
one
now
for
Tuesday
little
weird,
but
the
no
alpha
2
alpha
3,
we
will
definitely
supports
the
upgrade
process.
So
we
did
this
same
model
for
for
kuba,
DM
and
it's.
It
seems
a
little
conservative
because
some
people
kind
of
over
fit
on
what
the
notion
of
GA
is.
A
But
if
you
actually
look
inside
of
a
lot
of
the
kubernetes
api
s,
they've
been
beta
for
years
like
years
and
people
used
it
all
the
time,
extensions,
API
or
the
for
jobs
and
an
Apps
API,
those
those
have
been
beta
for
years
and
years,
and
it's
just
a
matter
of
being
mindful
of
what
the
deprecation
cycle
means
for
when
you
want
to
change
this
at
the
end.
But
we
will
definitely
hit
beta
I.
Think
in
the
next
year.
A
A
The
question
was,
when
you
say
beta:
does
that
mean
across
a
given
set
of
providers?
I
think
what
we
will
try
to
do
is
we
will
try
to
make
sure
that
AWS
provider
people
who
have
known
interest
in
helping
out
we
will
probably
actually
try
to
get
them
so
most
likely
we
will
get
there's
a
high
degree
of
confidence.
We
will
get
AWS
provider,
we
will
probably
work
on
Azure
provider
because
I
work
for
VMware.
A
We
will
definitely
have
the
vSphere
provider
MA,
and
the
question
is
whether
or
not
we
will
be
able
to
get
GCP
provider
up
to
that
state.
We
probably
will,
because
we
have
broader
plans
in
the
community
for
getting
that,
so
those
will
be
the
primary
ones
that
we
will
focus
on.
There's
there's
a
whole
suite
of
other
clouds
that
I
do
not
know.
If
we
will
support
going
through
or
whether
or
not
we
will
create
the
test
apparatus
to
do
the
verification
independently.