►
From YouTube: Cluster API - Making Kubernetes easy to work with
Description
In less than a generation, we’ve gone from bare-metal servers to virtualization to containers. It’s a story of expanded possibilities aided by stakeholder communities coming together to solve problems. Over time, processes have become easier and more efficient for end users. We’ve learned to orchestrate containers with Kubernetes, and we can now manage Kubernetes clusters and their associated infrastructure needs across multiple cloud providers (and hopefully on-premises) with Cluster API.
Cluster API declaratively manages the lifecycle of clusters (create, scale, upgrade, and delete). By making use of the structured nature of Kubernetes APIs, it becomes possible to build higher-level cloud agnostic tools that allow for greater ease of use and more sophisticated automation.
Join this webinar to learn about Cluster API, how it works, the current state of it, and why it's crucial for the future of Kubernetes.
Speaker:
Andy Goldstein, Staff Engineer at VMware.
Andy Goldstein is a staff engineer at VMware (via Heptio) where he works on tooling to make operating Kubernetes clusters easier. In his past lives, Andy worked on Velero (a disaster recovery tool for Kubernetes) and OpenShift. He lives in Rockville, MD, with his wife, two children, and two noisy cats.
You can find the YAML files Andy used here:
https://gist.github.com/ncdc/cd71d87c97329630a435c62b476069b7
A
Hi
everyone
and
welcome
to
today's
webinar.
We
are
very,
very
excited
to
have
you
all
here.
My
name
is
Jonas
Roslyn
I'm,
an
open
source
community
manager
at
VMware
and
I
will
be
your
host
today.
Today's
webinar
is
all
about
kubernetes
cluster
API
and
with
us
to
explain
what
that
is
and
why
it's
critical
to
the
future
of
kubernetes.
We
have
Andy
Goldstein
Andy
is
a
staff
engineer
here
at
VMware,
where
he
works
on
tooling.
To
make
operating
kubernetes
cluster
is
easier
in
his
past
lives.
A
He
worked
on
Valero
a
disaster
recovery
tool
for
kubernetes
burn
in
a
future
webinar
and
openshift
lives
in
rockville
maryland
with
his
wife,
two
children
and
two
noisey
cats.
If
you
have
any
questions
throughout
the
webinar
here,
please
add
them
to
the
Q&A
or
the
chat,
and
we
will
answer
them
throughout
the
presentation.
With
that
I'm
gonna
hand
it
over
to
Andy
who
will
kick
things
off
Thank.
B
You
Jonas,
let
me
share
my
presentation
here.
Can
you
all
see
that
looks
good
great?
So,
as
Jonas
said,
I
will
be
talking
about
cluster
API
today.
So
just
a
brief
agenda
here,
I'm
going
to
introduce
myself
and
then
move
on
to
talking
about
what
is
a
kubernetes
cluster.
What
does
it
mean
to
bootstrap
a
cluster
moving
on
from
bootstrapping,
we'll
talk
about
installation
and
then
how
cluster
API
plays
into
all
of
this
and
I'll
end
up
with
some
next
steps
for
the
project
and
ways
that
you
can
get
involved
if
you're
interested?
B
Okay,
briefly
about
myself,
I
worked
for
Red
Hat
for
a
long
time
doing
consulting
Java,
back-end
and
front-end
web
development.
I
spent
a
couple
years,
developing
a
large
messaging
platform
for
the
railroads,
and
then
I
shifted
out
of
consulting
to
work
on
open
shift,
which
is
before
kubernetes
and
openshift
3,
which
is
based
on
kubernetes,
and
that
led
me
into
containers
and
to
docker
and
I
became
a
docker
contributor
to
support
some
of
the
efforts
that
we
were
interested
in
for
OpenShift
and,
namely
the
pull
by
digest
feature.
B
So,
if
you've
ever
seen
an
image
with
a
sha-256
identifier,
that
was
in
part
thanks
to
me
and
I'm,
also
a
kubernetes
contributor
I
did
the
initial
implementations
for
acute
control,
exact
attachment
port
forward
and
I
spent
a
decent
amount
of
time
working
on
velaro,
formerly
hefty
Oh
arc,
as
the
project
lead
and
today
I
am
VMware's.
Cluster
API
lead
okay.
So
what
is
a
kubernetes
cluster?
It's
made
up
of
actually
a
lot
of
things.
You
have
to
start
first
with
infrastructure,
so
you
need
networking
firewall
rules.
B
You
can't
have
anything
without
servers
and
usually
there'll,
be
a
load
balancer
involved
for
allowing
external
users
to
talk
to
your
API
server.
After
all,
the
infrastructure
is
in
place.
You
need
to
get
your
kubernetes
components
set
up,
we'll
talk
about
those
in
just
a
minute.
There's
add-ons
that
you
may
be
interested
in
using
so
for
disaster
recovery,
we'd
recommend
something
like
Valero
for
ingress.
We
have
contour
for
single
cluster
ingress
gimble
for
multi
cluster
ingress,
there's
the
harbour
registry
and
sauna
Bluebird
conformance.
These
are
just
examples
of
some
add-ons.
B
You
may
have
others
that
you're
interested
in
as
well
and
then.
Finally,
the
reason
for
running
a
kubernetes
cluster
user
applications.
These
are
the
things
that
run
in
your
enterprise
in
your
clusters,
for
your
departments
to
power
the
applications
or
to
be
the
applications
that
you
need
to
perform
your
work.
B
Alright,
let's
talk
about
these
kubernetes
components,
they're
very
important.
So
when
you
are
looking
at
a
kubernetes
cluster,
the
first
thing
that
you
have
to
have
is
the
container
runtime.
This
might
be
docker
container
d,
cryo
or
something
else,
but
this
is
where
you're,
what
you're
using
to
run
your
containers,
then
you
have
the
cubelet,
which
is
responsible
for
taking
the
pods
that
you've
defined
and
the
containers
that
are
in
those
pods
and
running
them
on
a
system.
B
@Cd
is
the
database
for
kubernetes,
so
all
of
your
pods
deployments,
config
Maps
everything
related
to
all
of
the
data
types
that
you
store
and
interact
with
for
kubernetes
goes
into
EDD
CD.
The
API
server
is
the
component
that
you
interact
with
the
most
when
it
comes
to
creating
resources
and
querying
them.
The
cube
scheduler
is
very
important.
B
It
takes
a
look
at
all
of
the
nodes
in
your
cluster,
the
pod
that
you're
trying
to
schedule,
as
well
as
its
configuration
details
like
affinity
and
anti
affinity,
rules,
resource
requests
and
limits,
and
it
determines
which
node
or
nodes
have
the
available
capacity
in
the
right
place
to
be
able
to
run
your
pod.
The
cube
controller
manager
is
a
process
that
contains
a
variety
of
control,
object
necessary
for
kubernetes
as
a
whole
to
function.
B
B
You
also
need
a
CNI
provider
most
likely
if
you
want
to
have
pod
pod
networking
and
then
there's
core
DNS
for
in
cluster
DNS.
So
this
is
a
lot
of
things.
How
do
we
bootstrap
them
and
by
bootstrap
I,
mean
configure
so
there's
going
to
be
command
line,
flags
configuration
files
or
some
combination
for
each
one
of
these
things
and
they're?
Not
always
the
easiest
to
configure,
and
some
of
these
components
have
dozens
or
even
hundreds
of
configuration
options.
So
how
do
we
do
this?
Some
of
the
options
include
do-it-yourself.
B
You
could
decide
that
you
either
want
to
do
it
by
hand.
Kelsea
high
tower
has
kubernetes
the
hard
way,
which
is
an
excellent
resource.
If
you
want
to
learn
the
ins
and
outs
of
how
to
get
everything
set
up,
but
that's
pretty
manual
you,
alternatively,
as
part
of
the
DIY
option,
could
create
your
own
scripts
or
find
configuration
management
tools
such
as
ansible
to
to
set
all
of
this
up.
B
B
It
uses
a
declarative
configuration
model,
you
can
see,
there's
an
it
configuration
cluster
and
joint
configurations,
and
it
provides
some
top-level
commands
like
cube,
ADM
an
it
to
create
a
new
control,
plane,
node
or
keep
idiom
join
to
join
either
a
new
control
plan
node
or
a
worker
node
to
an
existing
cluster.
There's
also
phases
that
you
can
invoke
that
break
down
into
individual
actions.
B
So
basically
cube
ADM
is
a
building
block.
It's
it's,
not
the
only
thing
that
you
need
to
have
in
your
toolbox,
but
we
have
designed
it
to
be
fairly
comprehensive
when
it
comes
to
bootstrapping
the
components
that
you
need
for
a
kubernetes
cluster,
but
it
doesn't
handle
infrastructure
so
queue.
Midium
is
not
the
sort
of
thing
that
is
going
to
create
a
virtual
machine
for
you
or
set
up
your
networking
or
anything
like
that
which
gets
me
to
installation.
So
we
have
all
of
these
things.
B
We
have
the
infrastructure,
the
kubernetes
components,
the
add-ons,
the
user
applications.
How
do
we
go
from
nothing
to
a
full,
fully
functional
kubernetes
cluster,
including
all
the
infrastructure
that
you
need?
So
there's
some
options.
You
can
do
it
yourself.
This
could
be
again
writing
your
own
scripts
to
provision
ec2,
VMs
or
Azure,
VMs
or
whatnot.
If
you
look
at
cube
ATM
again,
it's
just
for
bootstrapping
and
not
for
infrastructure,
but
it
should
be
part
of
your
installation
experience.
B
There
are
installers
out
there
that
will
do
both
infrastructure
and
kubernetes.
These
include
things
like
enterprise,
P
chaos,
cops
and
then
there's
other
installers.
That
expect
you
to
bring
your
own
infrastructure
and
they
focus
mainly
on
getting
kubernetes
configured,
which
is
something
like
cube
spray
and
then,
finally,
you
have
managed
kubernetes
providers,
including
things
like
cloud
PKS
gke
for
google
eks
for
amazon,
aks,
fraser
and
so
on.
B
So
that
brings
me
to
cluster
api,
which
gives
us
declarative
lifecycle,
management
of
kubernetes
clusters
and
what
do
I
mean
by
declarative
lifecycle
management?
This
is
the
ability
to
create
scale,
upgrade
and
delete
your
clusters.
The
machines
that
are
part
of
your
clusters
and
declarative
here
means
that
we're
using
API
concepts
that
everybody's
familiar
with,
if
you
know
kubernetes
so
just
like
you,
can
create
a
yamo
file
with
a
pod
in
it
and
send
it
to
the
api
server.
B
B
There
have
been
efforts
such
as
Cuba
corn,
to
try
and
and
get
some
of
these
concepts
laid
out
and
implemented,
and
as
these
discussions
were
going
on,
they
turned
into
a
kubernetes
enhancement
proposal
or
kept.
This
project
is
also
owned
by
say,
cluster
life
cycle,
just
like
Cuba
diem
and,
as
I
mentioned
before,
about
possibly
needing
different
installers
to
handle
different
cloud
providers
or
bare-metal
situations.
The
goal
of
cluster
API
is
to
be
able
to
handle
multiple
infrastructure
providers
so
that
you
don't
have
to
go
and
find
different
tools
for
different
different
cloud
providers.
B
B
All
right,
let's
go
into
an
overview
of
what
what
is
cluster
API.
So
there
are
some
custom
resource
definitions.
These
include
things
like
clusters
and
machines
and
I'll
go
over
that
in
a
minute.
There's
a
lot
of
common
logic,
that's
in
the
cluster
API
repository,
and
then
we
have
provider
specific
logic.
So
some
of
the
providers
listed
here
are
the
vSphere
provider,
which
we
called
cap,
V,
the
ADA
bs
provider,
that
we
call
CAPA
the
Azure
provider
cap
C,
there's
one
for
GCE
and
there's
a
lot
of
other
ones
as
well.
B
So
normally
you
would
start
and
you
would
have
a
management
cluster
that
already
has
cluster
API
installed
and
once
you
have
that
set
up,
you
can
create
a
cluster
resource
control,
plan
machines
and
machine
deployments,
and
this
will
translate
into
potentially
networking
firewall
rules,
a
load,
balancer
and
virtual
or
physical
machines
depending
on
your
provider.
And
you
can
do
this,
you
have
multiple
clusters,
multiple
sets
of
machines,
all
managed
in
the
same
management,
cluster.
B
Okay.
So,
looking
at
this
cluster
CRD
there's
a
few
things
in
here
that
are
common
to
any
type
of
kubernetes
cluster
you'll
have
the
the
pod,
cider
or
network
range
for
pods,
the
service
cider
and
the
service
DNS
suffix
and
then
what's
left
is
really
an
embedded
provider.
Specific
configuration
field
and
I'll
show
you
an
example
of
this
in
just
a
minute
and
then
from
the
status
side
of
things.
You'll
see
API
server,
endpoints
some
error
details.
B
If
there
were
any
errors
and
then
just
like
there's
an
embedded
provider,
specific
configuration
there's
one
for
status
as
well.
So
here
is
an
example
of
what
a
cluster
could
look
like
for
an
AWS
provider
or
CAPA
you'll
see
that
it
looks
very
similar
to
other
yamo
that
you've
seen
for
kubernetes
resources.
B
It's
got
an
API
version
and
a
kind
in
this
case
I've,
given
it
a
name
of
demo,
one
I've
specified
the
cider
box
for
pods
and
services
I've,
given
it
a
service
domain
and
then
this
provider
spec
down
towards
the
bottom,
is
that
embedded
provider.
Specific
configuration
in
this
case
is
an
AWS
cluster
provider.
Spec
and
I've
specified
my
desire,
AWS
region
and
the
SSH
key
pair
name
as
well.
B
B
So
the
next
main
CRD
that
you'll
be
looking
at
is
the
machine
customer
resource.
So
inside
of
the
spec,
you
can
specify
what
version
you'd
like
to
have
for
the
cubelet
and
what
version
you'd
like
to
have
for
the
control
plane.
The
control
plane
field
is
optional,
and
you
would
only
fill
that
in
if
you
want
this
particular
machine
to
act
as
a
control,
plane,
machine
and
then
similar
to
the
cluster.
B
There
is
an
embedded
provider,
specific
configuration
or
a
reference
to
a
machine
class
and
I'll
talk
about
that
machine
class
reference
in
just
a
minute.
Once
the
machine
has
been
created,
you
will
see
the
provider
identifier
for
that
machine,
so
this
would
be
an
AWS
instance
ID,
for
example,
and
I'll
be
able
to
show
that
once
we
get
a
machine
up
and
running
and
there's
a
couple
of
other
fields
that
I
list
with
an
asterisk,
the
node
taints
and
the
cubelet
config
source,
mainly
because
not
every
provider
currently
does
anything
with
these.
B
So
this
is
an
example
of
a
machine,
and
this
is
my
control
plane
machine
that
as
soon
as
my
cluster
networking
is
up
I'm
going
to
go
ahead
and
create
one
of
these,
and
this
looks
just
like
what
you'd
see
for
other
resources.
It's
got
a
name
in
this
case
I'm,
also
giving
it
some
labels,
so
I'm
telling
it
that
it
belongs
to
a
cluster
called
demo
one
and
that
its
purpose
or
set
is
control.
B
Plane,
I'm,
also
requesting
that
I'm
I
want
to
use
the
1.14
dot
one
version
of
kubernetes
for
the
cubelet,
and
I
want
this
to
be
a
control,
plane,
node
and
then
similar
to
the
cluster.
There
is
a
provider
specific
spec,
and
here
you
can
see
that
the
instance
type
that
I've
requested
is
an
m5.
Large
I
have
an
iamb
instance
profile
that
I'd
like
it
to
use
and
an
SSH
key
pair
as
well.
B
B
So
this
is,
it
only
has
a
single
field
for
embedded
provider,
specific
configuration,
and
this
is
meant
to
allow
you
to
put
commonly
used
fields
in
a
single
place
so
that
you
don't
have
to
copy
and
paste
them
for
every
single
machine.
It's
really
used
as
a
way
to
consolidate
these
provider
specific
details
into
one
place,
and
this
can
be
referenced
by
a
machine,
a
machine
set
or
a
machine
deployment.
So
it's.
B
A
handy
way
to
to
avoid
having
to
copy
and
paste
everything
next
up
we
have
Machine
set.
This
is
very
similar
to
replica
set,
so
you
can
list
how
many
replicas
you'd
like
to
have
of
a
particular
machine.
You
can
have
a
deletion
policy,
it's
got
a
label
selector
just
like
you'd,
see
in
replica
set
and
then
a
template
for
the
machine
to
create
and
finally
rounding
out
the
CR
DS.
We
have
machine
deployment.
This
has
a
replica
count.
B
I
did
have
to
compress
this
a
little
bit
to
fit
on
one
slide,
so
you
can
see
that
in
this
example,
I
have
three
replicas,
so
that
means
I
would
like
to
have
three
machines
created
from
this
machine
deployment
and
I'd
like
cubelet
version,
1.14
got
one
and
then
the
provider
spec
looks
very
similar
to
what
I
had
for
the
control
plane.
So
what
I'm
gonna
do
at
this
point
is
come
back
over
here
and
we're
gonna
go
and
see.
First
thing
I
need
to
do
is
grab
my
cube
config
for
this
particular
cluster.
B
This
is
something
that
is
generated
or
can
be
generated
on
the
fly.
So
what
I've
done
is
I
created
the
infrastructure
from
my
cluster
I
created
the
control
plane
machine
for
my
cluster,
but
in
order
to
talk
to
it,
I
need
my
cube
config,
and
so
that's
what
this
cluster
cuddle
alpha
phases
get
cube.
Config
command
will
do,
and
I've
already
got
my
environment
variable
for
cube
config
set
to
this
particular
file.
B
So
what
I'm
going
to
try
and
do
is
see
if
the
nodes
are
available,
and
what
you
see
here
is
that
my
node
is
not
ready.
The
reason
that
it's
showing
not
ready
is
that
the
way
that
the
AWS
provider
for
cluster
API
works
is
it'll,
create
a
machine
for
you
and
it'll,
create
that
first
control,
plane
machine
like
I've,
asked
it
to
do,
but
what
it
doesn't
do
the
box
when
I'm
managing
it
like
this
is
get
the
container
networking
interface
set
up.
B
A
B
We'll
wait
just
a
little
bit
for
that
to
show
up
there
we
go
so
now.
We
have
one
ready,
control,
plane,
node.
So
that's
that's
good,
but
it
would
probably
be
nice
to
have
some
regular
non
control,
plane
notes
as
well.
So
what
I
can
do
is
apply
my
workers,
yeah
Mille,
and
what
this
will
do.
Oops
sorry
I
did
that
in
the
wrong
place.
B
I
need
to
go
ahead
and
do
that
on
my
management
cluster,
which
is
this
tab
over
here
and
I'm
gonna,
go
ahead
and
apply
that
and
you'll
see
that
it
created
the
machine
deployment
for
me
and
if
I
come
in
here
and
I,
ask
it
to
look
at
the
machines
now.
I
have
my
control
plane,
zero,
which
was
the
one
that
I
originally
created
and
then
I
have
three
uniquely
named
machines
that
go
along
with
my
machine
deployment.
B
B
And
this
is
what
we
call
the
pivot
workflow,
and
this
is
something
that
I
wouldn't
expect
you
to
be
doing
too
frequently,
because
the
goal
is
to
get
your
management
cluster
up
and
running
and
then
use
that
as
a
means
to
create
other
clusters
and
manage
them.
But
if
you
don't
have
anything,
but
you
do
have
docker
and
a
laptop,
for
example,
you
can
do
this
pivot
workflow
and
we
have
a
command
line
tool
that
will
allow
you
to
do
this
and
so
the
way
that
this
workflow
works
is.
B
It
starts
by
creating,
what's
called
a
bootstrap
cluster
using
kind
or
kubernetes
and
docker,
and
this
is
going
to
be
running
on
your
laptop
and
the
the
workflow
will
install
all
of
the
cluster
API
C
or
DS
the
controllers,
the
actuators,
that
you
need
that
are
specific
to
your
provider.
Aws.
In
my
example,
all
of
this
gets
installed
in
the
bootstrap
cluster,
and
then
it
will
go
ahead
and
create
the
necessary
objects,
centrally
clustering
machine
to
get
the
control,
plane,
node
up
and
running,
and
once
we
have
that
cluster
running
in
AWS.
B
This
is
something
that
can
be
a
little
bit
confusing
if
you
are
new
to
cluster
API,
so
we
have
on
the
Left
here
a
list
of
everything
that's
in
the
cluster
API
repository.
So
this
includes
all
of
the
API
types
or
C
RDS,
and
then
a
series
of
controllers
for
clusters,
machines,
machine
sets
machine
deployments
and
then
a
special
node
controller
for
cluster
API
as
well,
and
then
inside
a
separate
github
repository,
that's
provider
specific.
B
You
would
find
the
provider
API
types,
a
cluster
actuator
and
a
machine
actuator,
and
there
might
be
some
other
tooling
as
well,
but
in
terms
of
how
things
are
our
split
and
the
repositories?
This
is
what
it
would
look
like
and
I
do
want
to
talk
just
a
little
bit
about
the
difference
between
controllers
and
actuators,
so
the
controllers
will
watch
resource
for
changes.
This
means
they'll
watch
a
cluster,
they'll
watch,
a
machine
said
machine
deployment
and
so
on.
B
The
controllers
that
are
in
cluster
API
provides
some
common
logic
and
then
anytime
that
there's
provider-specific
logic,
so
provisioning
infrastructure
for
a
cluster
provisioning
machines.
That's
where
you
have
these
things
called
actuators
that
have
that
provider
specific
logic.
So
I
want
to
talk
just
for
a
few
minutes
about
the
individual
controllers
and
what
their
functionality
is.
For.
So
the
cluster
controller
will
list
and
watch
cluster
resources.
It
will
configure
the
clusters
for
graceful
deletion,
so
that's
some
of
the
the
common
logic
that
I
was
talking
about
and
then
again
anytime.
B
The
Machine
controller
will
list
and
watch
machine
resources.
This
will
also,
as
part
of
its
common
logic,
configure
machines
for
graceful
deletion,
proper
deletion
order
and
cascading
deletion,
and
it
will
invoke
the
machine
actuator,
the
provider
specific
one
for
creating
the
machine,
updating
the
machine
and
deleting
it.
B
The
Machine
set
controller
is
very
similar
to
replica,
set
the
difference
being
attacks
on
machines
instead
of
pods,
so
it
will
list
and
wash
machine
set
resources,
configure
them
for
proper
deletion
order
and
cascading
deletion
and
it'll
also
adopt
orphan
machines.
So
there's
no
actuator
associated
with
a
machine
set.
B
It's
a
totally
generic
behavior,
so
its
sole
purpose
is
to
make
sure
that
if
you
specified
that
you
want
five
five
replicas
of
the
machine
that
there
are
five
and
if
one
of
them
gets
deleted,
it'll
make
sure
that
it
gets
scaled
back
up
and
if
there's
too
many
it'll
scale
it
down
the
machine
deployment
controller,
it's
very
similar
to
a
kubernetes
deployment.
It'll
list
and
watch
machine
deployment
resources
again
similar
to
the
other
ones,
make
sure
that
there
have
proper
deletion
order
and
cascading
deletion
setup.
B
If
this
one
will
manage
machine
sets
and
handle
rolling
updates
and
it'll
adopt
orphan
machine
sets
in
terms
of
rolling
updates.
This
is
a
very,
very
important
feature,
so
there's
a
couple
of
parameters
that
you
can
set
that
influenced
the
behavior
of
a
rolling
update
of
the
machine
deployment.
So
you
can
set
what
is
the
maximum
number
or
percentage
of
unavailable
machines
that
you
can
tolerate,
so
you
can
decide
I
will
tolerate
one
or
three
or
10%
that
can
be
unavailable
at
any
given
time
and
then
on
the
opposite.
B
We
use
two
stateful
sets
right
now
and
not
a
deployment.
The
reason
that
we
don't
use
a
deployment
is
that
when
you
update
it,
you
could
end
up
with
multiple
copies
of
the
pod
running
simultaneously
for
a
brief
time
and
with
a
stateful
set
you're
guaranteed
that
that
won't
happen.
So
the
first
stateful
set
we
run
has
the
common
cluster
API
controllers
in
a
single
pod
in
a
single
container
in
process.
This
is
the
machine
set
the
machine
deployment
and
the
node,
so
conceptually.
B
This
is
similar
to
the
controller
manager
where
it
has
multiple
controllers
running
in
a
single
container.
This
is
exactly
what
we
do
with
the
first
stateful
set
and
then
the
second
stable
set
will
have
your
provider
specific
controllers
and
actuators.
So
this
is
your
cluster
controller
and
actuator
and
machine
controller
and
actuator
so
project
next
steps.
B
We're
also
focusing
on
node
and
control
plane.
Lifecycle
management,
including
upgrades.
So
right
now,
when
you
create
a
control
plane,
especially
if
you
want
a
highly
available
control
plane,
we
recommend
and
encourage
you
to
use
machines
instead
of
machine
sets
or
machine
deployments,
because
you
have
to
be
very
careful
when
you
are
managing
at
CD
quorum,
for
example-
and
you
can't
just
add
and
remove
members
at
will
the
way
that
the
rolling
update
of
a
deployment
potentially
would
do
it.
B
You
have
to
be
very
careful
so
that
you
don't
lose
quorum
and
we
are
hoping
to
add
some
orchestration
around
control,
plane,
lifecycle
management
to
be
able
to
handle
that
we're
also
interested
in
working
on
common
tooling,
to
create
VM
images
for
multiple
infrastructure
providers.
We
would
like
to
have
a
single
place
where
you
can
or
a
single
tool
where
you
can
end
up
creating
images
for
AWS
as
your
vSphere
and
so
on,
without
having
to
go
use
a
different
tool
per
provider
and
we're
targeting
a
v1
alpha-2
sometime
later
this
year.
B
The
exact
date
is
TBD.
All
right.
I'm
gonna
take
a
little
break
from
my
slides
and
go
back
to
the
demo
here.
I've
been
watching
the
nodes
here
and
we
take
a
look.
We'll
see
that
there
are
four.
So
we
have
the
one
control
plane,
node
and
three
worker
notes
and
I
can
do
something
like
run
a
busy
box
image
and
get
a
shell
up
and
running
just
to
show
you
that
it
will
run.
B
And
here
you
can
see,
see
my
shell
when
I
can
less
and
I
can
do
a
curl
or
I
can't
do
a
curl.
But
I
can
do
an
end
up,
maybe,
and
so
we
have
networking
working
so
basically
I
guess
I,
don't
have
networking
quite
working
there,
but
I
do
have
a
running
pod
in
my
cluster
and
I
can
go
ahead
and
get
out
of
there.
So
I
have
a
functional
cluster.
It's
got
three
three
worker
nodes
and
if
I
wanted
to
I
could
scale
it
up
or
scale
it
down.
B
So
there's
some
see
a
key
pair
information,
there's
other
key
pair
information
and
then
there's
a
lot
of
details
about
subnets
and
availability
zones.
All
of
this
stuff
was
created
by
the
AWS
provider
and
not
anything
that
I
had
to
worry
about,
so
that
was
really
nice
and
then,
similarly,
similarly,
if
we
go
and
look
at
the
machines,
what
you'll
see
these
don't
have
as
much
detail
in
them,
but
you
will
see
that
there's
a
provider
whoops,
sorry
about
that.
B
You
will
see
that
there
is
a
provider
ID
for
the
machines
and
there's
some
cubed
cubed
e/m
information
as
well,
but
each
of
these
machines,
as
we
go
through
again,
has
the
provider
ID
filled
in,
and
so
you
can
just.
You
know
that
it's
running
and
if
you
go
to
your
AWS
console
for
example,
you
can
go,
look
at
that
and
and
get
more
details
there.
B
Okay.
So
how
can
you
get
involved
in
cluster
API
step?
Number
one!
Try
it
out.
We
definitely
encourage
everyone
to
take
a
look
at
the
github
repositories.
Read
the
documentation.
If
you
have
cloud
provider
access,
try
it
out
and
again
it's
p1
alpha
1,
so
there's
probably
some
some
bugs
somewhere
lying
around.
So
please
file
bugs.
If
you
run
into
them.
B
Are
there
any
refinements
to
the
data
model
that
were
that
would
make
sense
to
make
and
then
finally
control
plane
and
node
lifecycle
management
and
then
I
also
have
links
to
three
of
the
main
providers
that
my
teams
have
been
working
on.
So
at
this
point,
Jonas
I
will
turn
it
back
to
you
for
some
QA.
A
Sounds
good!
Thank
you.
So
much
Andy
a
lot
of
great
information
here.
So
thank
you
so
much.
We
do
have
a
few
questions.
The
first
one
from
Rajeev
he
was
they
were
asking
if
they
could
have
the
llamo
files
shown
in
the
demo.
I
certainly
can
do
that
awesome
so
will
will
share
that
later.
This
recording
will
also
be
up
on
YouTube.
So,
although
the
links
will
be
in
the
YouTube
description,
there
too
got
another
second
question
here
from
Ramiro.
You
talked
about
upgrades,
so
rolling
upgrades
of
your
of
your
machines.
B
B
There
may
be
some
issues
if,
if
there
are
changes
to
the
sed
database,
if
you're
doing
a
control
plane
upgrade-
and
that
includes
an
upgrade
to
EDD
CD,
you
may
not
be
able
to
rollback.
So
we
always
recommend
that,
if
you're
doing
something
where
you're
afraid
the
upgrade
might
fail,
if
you're
using
virtual
machines-
and
you
can
snapshot
them,
that
would
be
advisable.
A
A
B
B
So
if
you
need
a
load
balancer
and
it
makes
sense
in
the
context
of
running
your
cluster
and
for
that,
whatever
provider
you're
on
then
I
would
expect
the
provider
to
handle
that
load
balancer
just
as
an
example,
but
if
you're
looking
at
I
don't
know,
maybe
you
want
an
AWS
sqs
queue
setup.
That's
not
the
sort
of
thing
that
cluster
api
would
be
responsible
for.
B
A
B
Say
the
only
two
factors
would
be
whatever
your
provider
imposes
upon
you.
If
there's
any
limits
there
plus
there
are
theoretical
limitations
in
@cd
with
how
many
objects
you
can
put
in
there,
but
I
can't
imagine
that
you
would
run
into
those
limitations
before
you
would
run
into
cloud
provider
limitations
or
money
issues
if
you're
on
a
commercial
cloud
provider
where
it
costs
a
lot
of
money
to
to
run,
you
know
hundreds
or
thousands
of
machines.
A
B
A
A
Yeah
I
think
that's
it
for
today.
Thank
you,
so
much
Andy
for
all
this
wealth
of
information,
we'll
make
sure
everyone
gets
a
copy
of
the
the
presentation
and
the
YouTube
recording
and
everything.
Thank
you
so
much
for
everyone
who
attended
and
I
hope
to
see
you
all
soon
at
another
webinar.
Thank
you
great
thing
have
a
good
one.
Bye.