►
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.
Cluster API Deep Dive - Katie Gamanji, American Express & Carlos Panato, Mattermost
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 for its consumers. In this deep dive, we will examine how the Cluster API simplifies the cluster management experience for cluster operators by enabling consistent machine management across environments, and bringing declarative upgrades to Kubernetes clusters.
https://sched.co/ekGv
A
Hello:
everyone,
my
name,
is
katie
comanche
and,
alongside
carlos
penato,
we're
going
to
give
a
deep
dive
into
cluster
api.
As
mentioned,
my
name
is
katie
rumanji
and
currently
I
am
a
cloud
platform
engineer
for
american
express.
I
have
been
in
this
role
for
the
past
year
and
I'm
part
of
the
team
that
aims
to
transform
the
current
platform
by
embracing
the
cloud
native
principles
and
making
the
best
use
of
the
open
source
tools
as
well.
I
am
one
of
the
toc
or
technical
oversight
committee
for
the
cncf.
A
B
B
Today,
we're
going
to
talk
about
the
cluster
api,
and
this
is
our
agenda
for
today,
we're
gonna
like
give
a
quick
overview
about
cluster
api.
We're
gonna,
explain
the
control
plane.
Okay,
we're
gonna
talk
a
little
bit
about
cluster
ops
and
argo
cd.
We're
gonna,
see
a
demo
and
we're
going
to
talk
a
little
bit.
What's
the
next
10
planet
features
for
the
cluster
api
and
how
you
can
get
involved.
B
Y
cluster
api,
like
today,
we
have
more
than
100
installations
tools
for
kubernetes
and
also
the
cluster
lifecycle.
It's
very
hard
to
deal
with
it
like
the
day
two
day.
One
day,
two
of
the
cluster
and
the
idea
of
a
cluster
api
is
bring
in
a
in
a
central
place
like
a
easy
way
to
create
your
cluster
provision,
your
workload
cluster
and
manage
this
cluster
in
terms
of
upgrading,
repair
out
scaling
and
deleting
the
cluster
as
well.
In
the
end,.
B
B
B
Okay,
how
it
works.
There
is
a
lot
of
yaml
files
that
everybody
likes
that
and
it's
a
declarative
spec
that
you
declare
your
cluster
and
we
have
like
a
management
cluster
that
you
install
your
cluster
api
and
the
cluster
api
providers
and
that
can
bootstrap
kubernetes
clusters
across
several
cloud
providers,
including
also
bare
metal
as
well,
for
example
this
example
here.
So
you
can
declare
your
configuration.
B
It
you're
gonna,
apply
this
to
the
cluster
api
and
again
create
cluster.
For
in
this
example,
we
have
aws
vmware
via
sphere,
google
cloud
and
azure.
You
can
imagine
this
like
being
an
indian
cluster
for
a
a
team,
a
and
another
one
in
vmware
for
the
product
b
and
so
on.
You
can
have
multiple
cloud
providers
and
you
have
your
management
cluster
in
one
place.
Only
that
can
manage
several
classes
across
various
cloud
providers.
B
Where
the
cluster
api
are
right
now,
like
we
are
part
of
the
sikh
cluster
life
cycle
sub
project,
we
have
more
than
200
contributors
and
we
are
in
the
alpha
stage.
We
like
we
are
most
likely
to
in
the
end
of
doubt,
offer
stage
we
had
like
release
alpha
one,
which
was
the
initial
implementation
and
the
poc
to
validate.
If
this
everything
works,
then
we
got
alpha
two
which,
with
solid
foundations
and
like
building
the
bootstrapping
agnostic
infrastructure.
B
B
What
we
want,
where
do
we
want
to
be,
is
like
the
idea
of
the
cluster
api
is
making
the
managing
the
lifecycle
of
kubernetes
very
boring
and
like
to
be
easier
to
people,
use
the
cluster
api
and
create
you
are
managing
your
clusters.
We
also
have
a
lot
of
support.
A
lot
of
use.
Cases
like
you
can
write
your
own
plugin.
You
can
write
your
own
providers
and
the
idea
is
also
support,
like
security
requirements
and
different
topologies
in
different
complex
scenarios
as
well.
A
Now,
at
this
stage,
I'd
like
to
give
a
deep
dive
into
the
control
plane
resource
now
in
the
v1
alpha
3
release,
which
is
the
current
release.
This
control
plane
resource
was
introduced
and
it
provides
a
lot
of
powerful
operations
of.
How
can
we
manage
our
masters
before
I
move
forward?
With
this
topic,
I
would
like
to
introduce
the
custom
resource
definitions
introduced
by
cluster
api.
At
the
moment,
there
are
five
of
them
cluster
control,
plane,
machine
machine
set
and
machine
deployment.
A
It
comes
with
a
very
powerful
rolling
out
strategies
between
machine
sets.
One
thing
I
would
like
to
mention
here
is
the
machine
resource
is
immutable.
That
means
that
if
you
push
new
configuration
to
the
cluster,
the
instance
with
all
configuration
is
going
to
be
taken
down
and
the
machine
with
new
configuration
is
going
to
be
brought
up.
There
is
no
patching.
There
is
only
mutability
to
fully
understand
how
we
can
create
a
cluster
using
cluster
api
and
how
all
of
these
resources
interact
between
themselves.
A
I
would
like
to
introduce
kind
of
a
higher
point
of
view
or
perspective
of
how
can
you
use
these
resources
overall
now,
to
begin
with
will
require
a
cluster
resource,
as
mentioned.
This
is
going
to
contain
the
entire
networking
configuration
for
cloud
provider
we'll
be
able
to
create
resources
such
as
vpcs,
subnets
and
so
forth,
with
the
cluster
automatically
we're
going
to
have
associated
a
control
plane
with
it,
so
we're
going
to
have
a
control,
plane
resource,
and
that
is
going
to
manage
a
set
of
machines.
A
Now
these
machines
are
going
to
be
our
master
nodes.
The
control
plane
information
is
going
to
install
the
core
components
for
a
cluster,
so
we're
going
to
have
the
api
server.
The
scheduler
control
managers
pretty
much
all
pack
back
package
nicely
together
and
the
last
thing
for
working
cluster
is
our
worker
nodes
or
the
data
plane.
A
Now
the
worker
nodes
is
something
we
attach
to
a
cluster.
It's
not
something
which
comes
by
default,
we'll
be
able
to
attach
different
sets
of
kind
of
working
notes
to
our
cluster
as
such,
we're
going
to
have
a
machine
deployment,
and
that
is
going
to
have
an
abstraction
layer
above
the
machine
set
and,
of
course,
the
machines
themselves
which
are
going
to
be
our
worker
nodes.
A
As
you
can
see
in
our
cluster,
we're
gonna
have
the
networking
specified
we're
gonna
choose,
select
a
slash
16
for
our
pods.
However,
I'd
like
to
draw
your
attention
towards
the
control
plane
reference
now.
This
is
the
section
which
will
invoke
a
different
manifest,
which
is
going
to
be
a
declarative
representation
of
our
control.
Plane
be
mindful
here
that
this
is
actually
a
trimmed
output.
So
we're
going
to
see
the
full
yaml
definition
through
the
demo.
A
A
If
it's
going
to
be,
for
example,
in
aws,
we'll
be
able
to
specify
the
region,
the
instance
type
pretty
much
configuration
parameters
like
that,
the
cubed
adm
config
spec
is
going
to
focus
on
how
can
we
initialize
and
join
new
machine
to
the
cluster
and
as
well
within
the
control
plane
we're
going
to
define
its
amount
of
replicas?
So
the
amount
of
masters
would
like
to
have,
along
with
the
version
of
our
kubernetes
cluster,
and
the
last
section
we
have
in
our
cluster
is
the
infrastructure
reference.
Now.
A
This
is
actually
going
to
have
the
information
of
how
we'd
like
to
define
those
networking
components.
I
was
mentioning
before
as
such.
If
we
look
at
the
manifest
for
aws
cluster,
we're
going
to
have
a
region
specified
in
this
case,
it's
going
to
be
uwest1
and
we're
going
to
attach
an
ssh
key
to
our
instances,
and
for
now
it's
going
to
be
the
default
ssh
game.
A
A
A
Once
we
have
this
templating
layer,
it's
going
to
be
very
easy
for
us
to
apply
changes
and
reconcile
any
changes
with
a
tool
such
as
argo,
cd
and
flux.
For
the
sake
of
this
demo,
we're
going
to
use
a
helm
template
for
our
cluster
api
manifest
and
we're
going
to
reconcile
any
changes
using
argo
cd
and
let's
look
exactly
how
we'd
be
able
to
upgrade
the
cluster
by
using
just
one
command
or
one
commit
for
for
our
manifest
at
this
stage.
In
the
top
view,
you're
gonna
see
our
class
cluster.
A
A
I
have
used
argo
cd
and
pretty
much.
I
have
an
application
here
which
is
going
to
go
and
look
for
the
helm
chart.
So
if
you
look
at
the
application
details
we'll
be
able
to
see
our
helm
chart,
which
is
declaratively
defined
here,
so
we're
going
to
have
a
template
fairly
standard
for
that
and
the
values
file
we're
going
to
use
is
the
values.demo
which
represents
1.18
the
amount
of
replicas
well
masters
and
workers
which
are
going
to
be
free,
and
we
can
further
confirm
that
by
looking
at
our
parameters.
A
A
If
I
just
hit
refresh
we'll
be
able
to
see
that
we
are
out
of
sync,
we
have
a
new
commit.
If
you
look
at
alchemy,
that's
the
only
change
we've
done
so
we've
changed
our
version
of
kubernetes
and
because
I
have
manual
reconciliation,
I'm
just
going
to
hit
sync
button
and
it
will
synchronize
our
resources
now.
A
The
most
interesting
thing
is
to
actually
look
at
how
exactly
the
machine
resources
behavioral
cluster
api
resources
behave
as
you
can
see,
already
have
a
new
machine
being
provisioned,
so
one
for
our
masters
and
one
for
our
workers
as
well,
and
this
is
going
to
be
pushed
another
thing.
I
would
like
to
showcase
if
you
look,
for
example,
in
aws
straight
away,
we'll
be
able
to
see
that
we
have
two
instances
initializing.
A
So
we
already
have
the
new
machines
rolling
or
at
least
creating.
Once
we
have
a
machine
being
ready
with
the
new
version.
It
is
going
to
be
added
to
the
cluster,
so
let's
wait
for
maybe
one
or
two
minutes
and
see
if
that's
actually
going
to
roll
out.
The
full
demo
is
already
recorded
as
well.
We'll
make
that
available
on
social
media.
A
Technically
we
can
attach
a
youtube
link
to
that,
so
you'll
be
able
to
see
a
speed-up
version
of
the
entire
process,
but
for
out
once
we
have
a
new
machine
with
a
new
configuration
that
is
going
to
be
added
to
the
cluster
and
a
machine
with
the
old
configuration
as
mentioned
is
going
to
be
taken
down.
There
is
no
patching.
There
is
only
mutability
now,
let's
see
that,
will
progress
fast
enough
for
us
looking
back
into
our.
A
A
Initializing,
oh,
you
can
see.
We
have
a
new
machine
with
1.19.1
already
added
to
the
cluster.
It's
not
ready,
yet
it
will
be
ready
once
the
networking
calco
actually
is
going
to
be
propagating
through
and
you'll,
be
able
to
see
as
well
that
a
machine
this
one.
For
example,
the
scheduling
is
disabled.
A
It
is
going
to
move
all
the
pods
transition,
all
the
parts
to
a
worker,
but
to
a
working
node
and
subsequently
it's
actually
going
to
be
removed,
and
this
is
going
to
be
performed
over
and
over
again
up
to
the
point
in
the
new
cluster,
which
is
going
to
have
all
the
nodes
within
the
version
and
just
to
confirm.
As
you
can
see,
this
machine
is
in
the
deleting
stage
it's
going
to
be
removed.
A
A
And
this
pretty
much
concludes
the
deep
dive
we
wanted
to
showcase
about
cluster
api.
There
are
a
few
takeaways
we'd
like
to
leave
with
you
before
concluding
the
talk.
The
cluster
api
has
been
so
successful
and
efficient
in
just
one
year
and
a
half
because
it
uses
the
building
blocks
principles.
It
does
not
concern
itself
to
bring
new
apa
points
for
kubernetes
to
consume
its
capabilities.
It
actually
builds
on
top
of
the
existing
primitives
and
making
the
best
use
of
customer
service
definitions.
A
A
very
important
thing
about
cluster
api
is
the
fact
that
it's
cloud
agnostic.
It
truly
provides
that
one
interface
that
allows
the
infrastructure
changes
to
plug
into
different
cloud
providers,
but,
more
importantly,
by
reusing
these
manifests.
So
we
have
a
better
management
of
our
clusters
overall,
and
currently,
cluster
api,
as
you
can
see,
is
under
continuous
development.
So,
if
you'd
like
to
have
new
features,
if
you'd
like
to
propose
a
new
provider
to
be
integrated
with
cluster
api,
please
reach
out
to
the
team
and
contribute.
A
Now
is
the
perfect
time
to
customize
cluster
api
to
use
case,
if
you'd
like
to
find
a
bit
more
information
about
cluster
api
and
some
of
the
the
knobs
and
the
kind
of
maintainers
point
of
view,
you'll
be
able
to
watch
the
webinar,
which
was
provisioned
well
recorded
with
help
of
cncf,
the
link
is
provided
below
and
if
you'd
like
to
find
out
a
bit
more
of
how
to
get
started
with
cluster
api.
How
can
you
integrate
a
cluster
api
with
argo
cd
and
how
you'd
be
able
to
do
this?
A
B
If
you
want
to
like
start
contributing
like
in
the
project
itself,
you
don't
need
to
have
only
like
coding
skill
like
if
you
write
writing
skills.
If
you
write
like
writing,
documentation,
writing
writing
guides
and
so
on,
like
we
have
a
lot
of
places
that
you
can
contribute
for
that.
If
you
have
like
more
product
skills
like
we
can
like
collect,
use
cases
and
compile
and
do
all
the
the
stuff
like,
we
can
see
the
use
cases
and
then
we
can
build
and
plan
better
features
as
well
as
well.
B
If
you
have
coding
skills,
you
can
review
requests
and
become
an
approver
like
you
can
search
for
help
when
the
tickets
are
good.
First
issues
across
the
entire
cluster
api,
not
cluster
api,
but
also
the
cluster
api
providers
as
well.
There
is
a
lot
of
help
wanted
tickets
that
we
need
help
on
that.
If
you
have
any
other
skills
like
you
can
like
provide
feedback
to
us,
you
can
make
demos
you
can
ask
questions.
A
So,
as
mentioned,
if
you
would
like
to
have
more
information
about
today's
talk,
please
reach
out
to
us
on
social
media.
Here
we're
going
to
be
available
on
twitter
lnt
as
well.
Please
read
articles.
I
have
on
the
medium
account
and
reach
out
with
any
questions
you
have
enjoy
the
rest
of
the
conference.
Thank
you.