►
From YouTube: Introduction to SIG Cluster Lifecycle - Lubomir I. Ivanov, VMware & Justin Santa Barbara, Google
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Introduction to SIG Cluster Lifecycle - Lubomir I. Ivanov, VMware & Justin Santa Barbara, Google
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/ekH4
A
Hello,
everybody
welcome
to
the
introduction
to
sig
cluster
lifecycle.
My
name
is
justin
santa
barbara.
I
am
one
of
the
sig
cluster
lifecycle
co-leads,
I'm
also
a
software
engineer
at
google.
My
github
handle
is
just
an
sb
lubermir
and
myself
are
going
to
be
giving
this
presentation
together,
but
we
are
representing
the
work
of
a
great
many
people
within
the
sig.
B
So
here
is
what
we
are
going
to
talk
about.
Today
we
are
going
to
explain
what
is
sequence,
the
lifecycle.
What
is
the
mission
and
philosophy
of
the
special
interest
group?
Also,
we
are
going
to
cover
the
stack
of
subprojects
that
we
maintain.
In
particular,
we
are
going
to
highlight
three
of
them.
These
are
cluster
api
component,
config
and
image
builder,
and
finally,
we're
going
to
show
you
how
you
can
get
involved
into
contributing
to
the
special
interest
group.
B
Sequester
lifecycle's
objective
is
to
simplify
the
creation,
configuration
upgrade,
downgrade
and
tear
down
of
kubernetes
clusters
and
their
components
as
a
special
interest
group.
You
also
have
a
vision
to
develop
the
tooling
necessary
to
build
a
highly
automated
meta
cloud.
Americorps
here
means
imagine
something
that
is
a
kubernetes
cluster
that
can
be
deployed
on
any
cloud
provider.
B
We
want
to
avoid
the
pitfalls
of
the
past,
because
we
had
some
unsuccessful
experiments
in
the
past.
Everything
should
be
declarative.
Api
driven
arcades,
like
deployment
type
of
style
and
managing
these
questions
should
be
as
easy
as
managing
the
kubernetes
objects
like
pots.
That
is
a
familiar
pattern
to
everyone.
B
B
B
B
Equestrados
is
a
project
where
we
are
working
on
standardizing
the
way
adults
are
deployed
in
a
cluster
and
they're
managed
as
a
life
cycle
like
how
do
you
upgrade
them?
How
do
you
downgrade
them?
Quasar
api?
A
lot
of
people
should
be
familiar
with
quest
api
as
well.
This
is
a
project
where
you
can
create
clusters
using
a
declarative
model,
it's
very
similar
to
the
kubernetes
declarative
patterns.
So
if
you
combine
these
two,
these
tools,
you
can
potentially
produce
artifacts
that
you
can
then
fit
to
your
image
builder.
B
An
image
builder
can
create
like
a
virtual
machine
image
for
you,
and
the
virtual
machine
image
can
then
be
fed
to
the
cosa
provisioner,
which
is
a
layer
on
top.
The
costa
provisional
can
create
you,
a
cluster
that
uses
this
virtual
machine
image
and
finally,
on
the
left
we
have
component
config.
Corporate
config's
idea
is
that
we
can
configure
all
these
components
on
the
right
side
with
the
declarative
api
that
is
very
similar
to
the
kubernetes
api
and
in
fact
it
uses
the
same
machinery.
B
B
Every
computing
infrastructure
project
that
initially
meets
one
need
well
will
eventually
expand
in
scope
to
only
meet
several
needs
poorly.
This
is
something
that
we
have
to
avoid.
We
also
expect
the
output
of
every
program
to
become
the
input
of
another
program
and
combining
all
the
tools
that
we
have.
We
want
to
create
this
voltron,
like.
B
Software
on
this
slide,
you
can
see
a
seldo
voltron
example.
It's
a
immutable,
node
update
type
of
scenario,
so
the
left
side.
We
have
a
ci
that
triggers
a
rebuild
of
artifacts
notifies
an
operator
to
update
customer
manifests
that
are
potentially
consumed
by
the
cluster
api.
The
cluster
api
can
then
perform
a
rolling
update,
then
a
bootstrap
provider
which
in
this
case
is
cube
atm
to
trigger
the
new
nodes
to
join
the
cluster.
B
B
Currently,
there
is
a
proposal
to
shift
to
a
three
releases
per
year
process
instead
of
four.
This
seems
to
be
a
very
favorable
option.
By
a
lot
of
users,
the
upgrade
process
can
be
difficult
due
to
core
api
changes
and
applications
and
removals.
Basically,
we
saw
a
number
of
comments
about
this
as
direct
responses
in
the
survey
itself
ubuntu
as
an
operating
system
for
vms
docker
as
a
container
runtime
using
docker
shim
in
this
case
and
calico
as
a
cni
appear
to
still
be
the
most
used
projects
in
their
respective
areas.
A
A
Some
important
things
to
understand
this
is
different
from
the
kubernetes
cloud
provider,
which
provides
workload
cloud
resources
like
volumes
and
load
balancers.
This
is
provisioning,
similar
infrastructure,
but
for
the
cluster
itself,
and
one
of
the
important
design
decisions
was
that
the
specification
of
a
machine
is
immutable.
A
A
We
want
to
follow
the
kubernetes
api
design
patterns
and
in
kubernetes
there
is
indeed
a
similar
design
pattern.
Pods
are
immutable,
but
pods
are
wrapped
by
replica
sets
which
runs
a
number
of
them.
A
replica
set
remains
immutable,
but
a
deployment
creates
mutability
over
those
replica
sets.
It
is
able
to
create
a
new
replica
set
and
scales
down
the
old
one
and
scales
up
the
new
one,
so
we
use
exactly
the
same
pattern
and
cluster
api.
A
A
machine
like
a
pod
is
immutable.
A
machine
has
a
number
of
replicas
in
a
machine
set
like
a
replica
set
and
a
machine
set
is
still
immutable,
but
a
machine
deployment
can
create
a
new
machine
set
scale
down
the
old
machine
set
and
scale
up
the
new
one.
A
machine
deployment
is
just
like
a
deployment
and
that's
how
we
can
achieve
immutability
at
the
machine
deployment
level.
A
The
machine
is
the
same
crd,
whether
this
is
on
aws
or
gcp
or
vmware,
and
there's
an
analogy
here
to
storage
classes
in
kubernetes.
There
is
similarly
a
machine
class
machine
class
is
a
kubernetes
object
that
describes
attributes
of
the
machine
that
are
specific
to
that
cloud
provider.
Just
as
a
storage
class
describes,
attributes
that
are
specific
to
a
particular
storage
backend
cluster
api
is
a
newer
api
and
we've
actually
developed
our
thinking
around
this
design
pattern
over
time.
Machine
class
objects
are
actually
typed
objects.
A
A
A
In
order
to
get
to
beta.
The
really
big
thing
we
need
is
better
documentation
which
goes
hand-in-hand
with
more
feedback
from
real
world
users,
like
you,
also
getting
it
integrated
into
some
of
those
higher
level
tools.
So,
for
example,
cops
is
planning
to
support
cluster
api
initially
for
the
nodes
and
getting
the
existing
kubernetes
e
to
e
tests
using
cluster
api
on
gcp
and
on
aws.
B
B
B
They
use
a
lot
of
flags
and
often
times
the
flags
across
different
components
that
do
exactly
the
same
thing
have
different
names.
The
solution
for
that
is
that
the
core
component
should
implement
component
config
and
in
fact,
most
of
the
core
components
have
already
started
doing
that.
Another
problem
is
that
it's
pretty
hard
to
write
a
cades
like
component
with
declarative
config,
so
adding
a
corporate
coffee
itself
is
not
that
easy.
B
So
the
solution
for
that
is
that
we
should
factor
common
logic
for
component
related
code
in
the
repository
designated
for
that
that
is
component
base,
and
it's
a
toolkit.
It's
going
to
make
it
easier
to
write
a
new
component
that
immediately
implements
a
corporate
config
that
uses
cades
api
style
of
configuration
and
existing
components
should
be
retrofitted
to
use
the
same
toolkit.
B
B
B
And,
finally,
it's
also
declarative
open
api
information
can
be
exposed
using
component
config
and
used
for
generating
documentation
for
your
config
to
learn
more
about
component
config.
You
can
watch
this
talk
that
lucas
kelstrom
gave
a
previous
cube
call,
and
in
this
talk
you
can
actually
see
some
of
the
details.
Implementation
details
around
how
we
are
actually
implementing
component
config
in
existing
components
or
how
do
we
want
future
components
to
implement
it?.
B
B
Another
project
that
we
wish
to
highlight
is
image.
Builder
image
builder
is
essentially
a
tool
for
building
virtual
machine
images
not
to
be
confused
with
container
images.
It
includes
ansible
and
packer
scripts,
which
are
well
supported
by
vmware,
microsoft
and
other
companies
for
creating
quasar
api
machine
images.
The
current
list
of
supported
operating
systems
include
ubuntu,
centos,
307,
photon,
amazon,
linux
and
flat.
Car
support
is
coming
soon.
Image
builder
is
targeting
vmware
aws,
azure,
qmo
and
digital
ocean
as
providers
of
infrastructure.
B
Here
are
some
of
the
goals
of
the
image
builder
project
provide
a
consistent
tooling
for
all
approaches
for
building
images
so
that
we
can
create
more
standardized,
reusable
adjustable
images,
make
it
easier
for
downstream
consumers
to
customize
their
own
images
and
keep
their
customizations
up
to
date.
Testing
of
images
to
verify
conformance
using
tools
like
inspec
and
goss
release
of
images
for
different
cloud
operating
system,
combinations
with
regular
updates.
B
B
A
A
So
we
need
your
help
and
I'd
suggest
this
is
also
an
opportunity,
sometimes
as
a
kubernetes
contributor,
it
can
feel
like
everything
that
can
be
done
has
either
already
been
done,
or
there
are
10
existing
issues
stating
why
you
can't
do
it.
That
is
very
much
not
the
case
in
sig
cluster
lifecycle.
There's
a
lot
of
work
still
to
do
that.
Work
is
very
concrete
and
we
are
very
oriented
around
encouraging.
A
Contributors
specifically,
we
have
some
onboarding
documentation,
which
is
a
great
place
to
start
along
with
our
community
page.
Many
of
the
sub-projects
are
excellent,
triaging
issues.
They
label
issues
with
good
first
issue
or
help
wanted
to
try
to
steer
you
to
issues
that
don't
require
the
in-depth
knowledge
that
you'll
likely
gain
over
time.
A
A
great
way
to
get
involved
is
with
documentation
or
even
just
trying
out
different
things
and
reporting
any
issues
you
encounter.
There
are
a
number
of
zoom
meetings,
there's
an
overall
sig
cluster
lifecycle
week,
meeting
bi-weekly
and
many
of
the
sub-projects
have
their
own
bi-weekly
meetings
as
well.
So
please
attend
ask
questions.
Introduce
yourself,
introduce
yourself
on
slack,
there's
a
very
active
slack
channel
where
you
can
find
people
at
all
hours
of
the
day
and
night,
if
you're
not
yet
a
kubernetes
contributor.
A
I
encourage
you
to
attend
the
new
contributor
sessions
that
are
run
by
sig
contributor
experience
in
general.
The
kubernetes
community
philosophy
is
that
you
earn
your
place
at
the
table
by
chopping
wood
and
carrying
water
by
taking
on
the
tasks
that
need
to
be
done,
so
everyone
is
expected
to
get
involved,
and
the
flip
side
of
that
is
that
you
are
therefore
welcome
and
encouraged
to
get
involved.