►
From YouTube: Tutorial: kubectl Create Cluster...-K Muldoon, S Singhal, Y Rao Kakaraparthi & S Büringer, J Francis
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
Tutorial: kubectl Create Cluster: Production-ready Kubernetes with Cluster API 1.0 - Killian Muldoon, Shivani Singhal, Yuvaraj Balaji Rao Kakaraparthi & Stefan Büringer, VMware; Jack Francis, Microsoft
Speakers: Yuvaraj Balaji Rao Kakaraparthi, Stefan Büringer, Shivani Singhal, Killian Muldoon, Jack Francis
Attention: Please note this tutorial requires that some tools like Docker are already locally installed. To provide a smooth experience during the tutorial, please install the preqrequistes already before the session. Detailed instructions can be found under Prerequisites. MacOS and Linux are fully supported, but Windows support is best-effort only. Minimum Resources: 4 CPU, 16 GB RAM and 32 GB free disk space.
Did you know you can create and manage a fleet of Kubernetes clusters just as easily as deploying Pods? Learn how to leverage Cluster API to create, update and manage your infrastructure, whether in the cloud or on-premises. Cluster API brings declarative management of entire clusters to the infrastructure provider of your choice.
Using your local machine you will learn how to create a fleet of clusters with Cluster API, scale up and down the number of nodes, and run a one-touch upgrade of entire clusters, all in just a few minutes.
This tutorial is designed for people who have some experience managing Kubernetes, and are interested in a new approach to solving the problem of operating clusters. You will leave this tutorial with the skills to automate fleets of clusters running production-grade Kubernetes.
Please note, this tutorial focuses on showcasing Cluster API features with the Docker provider which is using Docker on the local machine.
A
Jack
and
Shivani
is
supposed
to
be
presenting
with
she
couldn't
be
here
due
to
travel
restrictions,
we're
going
to
have
a
video
from
her
in
a
few
minutes.
So
a
couple
of
announcements,
there's
prerequisites
on
the
tutorial
at
the
link,
if
you've
all
run
through
them
can
I
just
get
a
sense
in
the
room.
Can
you
put
up
your
hand
if
you
have
done
the
prerequisites.
A
So
we're
going
to
take
a
few
minutes
now
to
just
let
people
run
through
the
prerequisites,
a
couple
of
important
things
if
you're
running
on
Fedora
on
your
laptop
or
whatever.
If
you
go
to
our
troubleshooting
guys,
there's
a
specific
setting
you've
got
to
set
in
Fedora.
The
tutorial
can
be
unstable
on
Fedora
because
of
yeah
system
limits.
So
please
just
check
that
out
also
for
Windows,
if
you're
using
Docker
for
Windows
to
run
this
tutorial,
you
won't
be
using
Docker
for
Windows
4.10.1.
A
A
A
So
yeah,
so
the
prerequisites
are
up
there
on
screen
they're
also
on
the
repo.
This
is
the
link
to
the
repo
see
if
any
need
to
type
it
in.
It's
also
on
the
shared
entry,
the
description,
so
it's
there,
the
CPU
limits,
RAM
32
gigs
of
disk
space.
You
need
to
install
Docker,
Cube,
cuddle,
kind,
cluster,
cuttle
and
Hound.
All
of
the
instructions
for
installing
those
things
are
in
the
guide
and
there
will
be
people
circling
around
the
room
for
the
next
few
minutes.
Just
if
you've
got
any
trouble
with
that.
D
C
G
A
C
B
C
E
A
A
Okay,
so
there'll
be
people
circulating
through
the
room
throughout
this
tutorial
put
your
hand
up.
If
you
want
help
with
any
of
the
steps,
if
you
still
haven't
passed,
the
prereqs,
please
yeah
ask
for
help
later
on.
If
you
need
it
so
now
we're
going
to
hear
from
Shivani
Shivan
is
going
to
give
us
a
quick
overview
of
cluster
API
as
a
project.
What
the
project
is
doing
and
yeah.
Let's.
F
A
C
H
H
H
Tooling
is
very
difficult:
there
are
several
tools
that
solves
a
part
of
the
problem,
and
this
is
that
is
intentional,
like
as
the
Sig
which
is
focusing
on
building.
This
tutorial
wants
to
solve
the
prop
pieces
of
the
problem
and
never
tries
to
build
one
solution
and
even
not
try
to
build
one
solution
that
fit
all
problems.
That's
because
they
don't
believe
that
will
actually
have
Traction
in
the
community
as
everybody's
needs
are
so
different.
H
Cluster
management
is
really
difficult
and
one
of
the
pieces
that
difficult
is
cluster
creation,
so
we
have
cubarium
for
that
piece,
but
another
another
part
of
problem
is
managing
infrastructure.
So,
even
if
you
have
bootstrapping
tools
like
Cube
ADM,
they
assume
that
you
already
have
physical
or
virtual
machines
to
run
cubadian
commands
on
top
of
it.
But
to
get
this
environment
we
should
have
our
infrastructure
specific
knowledge.
H
H
So,
like
till
here,
we
have
discussed
a
bunch
of
problems,
but
now
we'll
see
how
we
can
solve
it.
Using
the
cluster
API
first
and
foremost
like
cluster
API,
is
a
declarative
API
and
prior
to
this,
the
kubernetes
ecosystem
didn't
really
have
a
way
to
represent
clusters
and
machine
inside
of
a
kubernetes
cluster
itself.
H
It
not
only
helps
in
creating
and
managing
kubernetes
objects,
but
also
provides
declarative
apis
to
orchestrate
the
underlying
infrastructure
components.
We
really
think
that
it's
important
to
have
the
pluggable
architecture.
Well,
we
don't
want
to
provide
common
logic
to
solve
these
use
cases
for
people.
It's
not
gonna,
be
one
size
to
fit
all
problems.
So
one
place
where
it's
really
important
to
have
a
pluggable
architecture
is
the
level
where
we
interact
with
infrastructure
provider
for
infra,
provisioning
or
management.
H
H
So
now
we
understand
how
cluster
API
helps
and
what
is
cluster
API.
But
let's
now
look
at
the
official
definition
of
cluster
API.
We
also
call
it
as
gappy
and
it's
a
project
of
sick
cluster
lifecycle.
It
uses
kubernetes
to
manage
kubernetes,
which
is
also
referred
by
kapi
logo
Turtle,
all
the
way
down
and
by
official
definition.
H
Cluster
API
is
a
kubernetes
project
to
bring
declarative,
kubernetes
style
apis
to
not
only
manage
kubernetes
objects
like
pod
deployment,
but
also
useful
in
Creation
in
cluster
creation,
configuration
and
management
so
have
we
are
done
with
cluster
API
basic
introduction.
Now,
let's
look
take
a
look
at
next
item
from
our
agenda
so
to
establish
a
common
language
that
you
and
I
can
use
throughout.
The
remainder
of
this
tutorial
I
would
like
to
provide
you
some
definitions
for
frequently
used
term.
So
first
is
management.
H
This
enables
the
management
cluster
to
manage
the
life
cycle
of
other
kubernetes
clusters
that
are
known
as
workload
clusters,
and
this
is
the
place
where
we
like
deploy
our
workloads,
our
app
and
our
application.
We
also
have
another
term
like
self-hosted
management
cluster.
There
are
type
of
management
clusters
that
manages
itself
so
to
accomplish
this
life
cycle
management.
Cluster
API
also
leverages
the
concept
of
a
provider
providers
have
names
like
cluster
API
provider,
for
AWS,
for
cluster
API
provider
for
Azure
and
similarly
vsphere
and
many
more.
H
These
providers
are
also
known
by
their
acronyms
like
Kappa
cap,
z,
cap
V
and
so
on,
so
they
provide
the
support
for
an
integration
with
a
particular
infrastructure
platform,
and
in
the
last
of
this
glossary
section,
we
discuss
what
all
things
comes
under
inside
cluster
life
cycle
management.
So
it
includes
creation
and
deletion
of
your
kubernetes
cluster,
including
the
underlying
infrastructure,
managing
the
underlying
infrastructure,
scaling
up
scaling
up
and
down
the
number
of
nodes
in
the
cluster
and
upgrading
clusters
to
another
kubernetes
version.
H
So
now,
let's
see
how
does
cluster
API
work,
but
before
directly
jumping
into
the
cluster
API
functionality?
I
want
to
give
a
brief
overview
of
kubernetes.
Some
of
the
kubernetes
concepts
that
are
heavily
used
in
cluster
API,
so
at
the
core
of
kubernetes
is
a
control
Loop.
We
also
call
it
reconciliation
room
that
is
responsible
for
reconcile,
reconciling
the
desired
State
and
the
actual
State
reconciling
desired.
State
and
actual
State
simply
means
changing
actual
state
to
look
like
the
desired
one.
H
H
The
kubernetes
way
to
specify
the
desired
state
is
through
objects,
called
custom
resource
definitions.
The
cids
have
a
spec
object
representing
the
star
desired
State
and
Status
object
representing
the
actual
State,
along
with
crds,
we
Implement
their
controllers
and
cluster
API
uses
these
crds
and
controller
to
extend
kubernetes
to
manage
the
life
cycle
of
clusters.
Basically,
users
want
to
specify
the
configuration
of
clusters
and,
based
on
this
configuration,
let
the
controllers
implemented
by
cluster
API,
to
create
and
manage
the
cluster.
H
This
way,
the
building
blocks
provided
by
kubernetes
in
the
form
of
crds
and
controllers,
are
used
to
create
or
manage
your
new
kubernetes
clusters.
Let's
see
this
again
for
more
understanding
with
this
diagram.
Here
we
have
a
management
cluster
on
which
our
we
are
running,
our
cluster
ePay
components
and
we
have
one
client,
so
the
user
specifies
the
declarative
cluster
configuration
in
the
form
of
crd
to
the
management
cluster.
H
H
Now,
let's
see
what
all
cluster
API
components
are
running
inside
management
cluster,
so
the
controllers
are
divided
into
four
types
of
Provider
based
on
their
responsibility
and
each
provider
has
a
manager
which
runs
their
respective
controller.
So
in
cluster
API
components
we
have
four
iPhone
managers,
core
controller
manager,
bootstrap
controller
manager,
infrastructure
controller
manager
and
the
last
one
control
plane,
controller
manager.
H
With
the
help
of
this
diagram,
so
core
provider
manager,
infrastructure
provider,
manager,
control,
plane,
provider
manager
and
bootstrap
provider
manager,
they
are,
they
contain
some
type
of
crds
and
their
definition.
So
the
core
one
have
four
type
of
crds
cluster
machine
deployment,
machine
set
and
machine
crds.
Similarly,
infrastructure
provider
contain
inpra
infraspecific
controllers
that
are
responsible
for
connecting
with
the
infrastructure,
beat
cloud
or
bare
metal
servers,
whereas
in
the
middle
you
can
see,
control,
plane
provider
and
it's
responsible
for
initializing,
your
control,
plane
and
bootstrap
provider.
H
So
in
the
next
few,
slides
I'll
explain
each
of
the
cids
mentioned
in
the
previous
slides
and
their
interaction.
First,
we'll
take
a
look
at
cluster
CRT.
It's
a
root
of
whole
thing
and
responsible
for
maintaining
the
cluster
life
cycle
environment.
Specific
configurations
like
pod,
serviceiders
and
DNS
domain
goes
into
the
cluster.
H
Oh
sorry,
DNS
DNS
domain
goes
into
the
cluster
specification.
Next
we
have
infrastructure,
cluster
infra
can
be
AWS,
Azure,
vsphere
or
even
bring
your
own
host
and
specifications
are
under
infra.
Cluster
are
based
on
underlying
infrastructure
and
have
details
required
for
that
particular
environment.
Next,
we
have
configurations
for
initializing
your
control
plane
by
default.
Cappy
supports
cubeadm,
and
it's
related
specifications
like
init
and
join
configuration
are
mentioned
in
control,
plane,
crd,
so
once
control
plane
is
initialized.
We
need
machine
deployments
that
defines
machine
for
the
worker
nodes.
H
So
that's
how
the
these
all
these
crds
interact
with
each
other
and
dependent
like
their
flow
is
streamlined
and
they
are
dependent
how
they
are
dependent
on
each
other.
Next,
we
discuss
about
cluster
class
and
managed
topology.
It's
a
huge,
huge
ux
Improvement
on
how
end
users
interact
with
cluster
API
and
it
basically
reduces
customers
surface
area
of
interaction.
H
This
sole
idea
behind
cluster
class
is
we
just
want
to
define
the
structure
of
a
cluster
or
the
topology
of
a
cluster
once
and
reuse
it
across
multiple
clusters,
so
that
we
just
have
one
object,
called
the
cluster
object
in
which
we
will
have
a
topology
section,
which
then
can
be
used
to
Stamp
Out
clusters,
that
look
alike.
So
that
would
look
something
like
this
like
this
on
the
screen.
H
So
if
you
see,
on
the
left
hand
side,
we
defined
a
cluster
class,
it's
a
collection
of
templates
and
when
we
provide
different,
managed
topologies
to
the
cluster
class,
like
we
have
here,
cluster
a
man
is
topology
and
cluster
B
manage
topology.
Then
they
refer
it
then
the
cluster.
Then
they
refer
this
cluster
class
to
create
two
different
cluster
object,
which
looks
alike
but
also
different
in
their
own
way.
H
A
D
A
Serious
problems
that
they'd
like
help
with
at
this
point
again
hand
up
any
time.
Somebody
will
come
to
you
so
yeah
for
those
of
you
that
have
your
Docker
kind.
Everything
set
up
it's
time
to
get
your
first
cluster
running.
So,
let's
see
what
that
looks
like
so
at
the
bottom
of
the
prereqs.
If
you've
got
that
open
on
the
tutorial,
there's
a
link
to
the
next
section,
which
is
creating
your
first
cluster
or
cluster
API.
A
Okay,
so
the
prerequisites
mentioned
this
a
bit,
but
there's
going
to
be
a
cluster
you're,
going
to
set
up
using
Docker
infrastructure,
so
you're
going
to
set
up
kubernetes
clusters
where
each
node
is
running
in
a
Docker
container
on
your
local
machine.
So
we
have
a
cluster
API
provider
called
CAP
D
cluster
API
provider,
Docker
infrastructure
that
manages
this.
For
us.
A
You
can
also
use
cluster
API
to
set
a
clusters
up
across
any
number
of
clouds,
bare
metal
environments,
there's
loads
of
different
providers,
and
we
have
a
quick
start
guide
for
a
lot
of
those.
The
actual
flow
of
the
quick
start
might
be
a
bit
different,
which
I'll
explain
in
a
few
minutes
but
yeah.
So
you
can
set
up
clusters
on
AWS,
Azure,
gcp,
digitalocean
and
we've
got
a
list
of
providers
on
the
cluster
API
book
online.
A
So
for
this
guide,
this
part
of
the
tutorial,
like
the
prerequisites,
is
split
up
into
Linux,
Mac
and
windows.
So
select
the
version
that's
closest
for
you.
The
windows
version
is
Powershell,
with
Docker
for
desktop,
if
you're
running,
in
something
more
like
a
Linux
environment
on
Windows
or
VM
or
WSL,
or
something
you
might
want
to
follow
the
Linux
guide.
Instead,
we
also
click
on
one
of
those,
that's
closest
to
your
system,
the
Mac
OS.
A
So
the
first
thing
we're
going
to
do
is
set
up
a
single
kubernetes
cluster,
so
we
should
have
already
pre-polled
the
images.
So
these
are
all
the
docker
images
we
use
here
in
the
tutorial
during
the
prerequisites,
so
I'm
going
to
make
sure
I'm
in
the
right
directory
and
I'm
just
going
to
run
the
script
to
create
a
client
cluster.
This
is
a
normal
enough
coin.
Cluster.
It
just
has
a
couple
of
slight
changes
to
help
it
work
with
our
infrastructure
provider
for
docker.
A
So
this
cluster
is
going
to
perform
the
basis
of
our
management
cluster.
So
once
it's
up
and
running,
the
next
step
will
be
to
install
the
management
components
on
it,
and
those
components
are
what
will
manage
new
clusters
that
we
create
using
cluster
API,
manage
their
lifecycle,
manage
their
infrastructure,
all
of
the
providers
that
Shivani
showed
us
there,
so
the
core
controller
manager,
the
infrastructure,
controller
manager,
the
control
plane,
controller
manager
and
the
bootstrap
controller
manager.
They
run
on
the
management
cluster,
which
then
creates
other
clusters,
which
we
call
workload
clusters.
A
A
So
now
we're
going
to
install
the
management
components.
This
is
the
controllers
I
mentioned
earlier,
so
cluster
API
is
pluggable,
so
we've
got
the
idea
of
a
control,
plane
provider
and
there's
multiple
implementations
of
that.
So
the
specific
providers
we're
using
today
are
the
docker
provider
for
infrastructure
cap
Z,
which
is
the
Azure
infrastructure
providers
and
alternative
to
that
we're
using
the
core
cluster
API
provider,
which
every
setup
uses.
That's
what
manages
the
fundamental
crds
that
cluster
API
manages
our
bootstrap
providers
using
kubernetm,
so
we've
got
a
core
in
our
core
repo.
A
A
So
we're
just
going
to
copy
this,
so
this
will
set
up
a
couple
environmental
variables,
so
one
of
them
is
the
repository
we
use
locally
I'm
just
going
to
let
that
role
model
explain
the
next
two
are
feature
flags
that
we'll
be
using
in
the
courses
tutorials.
These
are
recent
features
that
were
added
to
Cluster
API
over
the
last
I
guess
year.
18
months,
the
first
one
is
cluster
topology,
which
is
cluster
class.
This
lets
us
create
many
clusters
from
a
single
template
that
we
stamped
them
from
that
templates
called
the
cluster
class.
A
A
Runtime
SDK
is
another
feature
that
we're
using
we'll
see
that
a
little
bit
later,
and
so
this
will
install
all
of
our
controllers
and
it
installs
cert
manager
as
well,
which
we
just
need
to
manage
communication
between
components.
So
now
that
we've
installed
also
closure
kotlin,
it
does
all
of
that.
For
us,
we
can
just
see
what
parts
are
running
on
the
cluster
and
we
can
see
capti.
This
is
our
infrastructure.
A
So
now
we've
got
a
functioning
management
cluster.
The
next
step
is
actually
to
create
a
cluster.
So
the
first
thing
we're
going
to
do
is
create
the
cluster
class,
which
I
mentioned
earlier.
That's
this
command,
so
all
of
these
are
in
the
repo.
So
we
just
apply
that,
like
any
other
kubernetes
resource
and
that
will
create
the
cluster
in
our
API.
So
we
have
that
successful.
We
can
take
a
look
at
the
what
the
cluster
looks
like
just
before
we
create
it.
A
So
this
culture,
because
the
specific
spec
of
the
cluster
is
defined
in
our
cluster
class.
It
hides
a
lot
of
that
complexity.
So
this
cluster
is
a
very
simple
object:
it
has
a
name
namespace
a
little
bit
of
networking
information
and
then
under
the
topology,
which
is
how
we
stamp
the
shape
of
it.
This
is
the
cluster
class
that
we've
just
created.
It's
just
called
quick
start:
we've
got
a
kubernetes
version,
we've
got
the
number
of
replicas,
we
want
in
the
control
plane
and
then
under
workers
we've
got.
We
want
a
single
machine
deployment.
A
A
And
we're
going
to
use
cluster
cuddle,
so
cluster
cuttle
is
the
CLI
that
comes
packaged
with
with
cluster
API.
So
it's
part
of
the
core
repo,
so
you
should
have
been
able
to
download
this
during
the
prereqs
I'm
going
to
use
watch
here.
If
you
have
it
installed,
let's
encourages
watch
for
a
minute,
so
with
cluster
coddle
described,
we
can
see
all
of
the
different
parts
of
the
cluster
come
up
so
cluster
API.
After
creating
that
yaml,
simple
yaml
with
10
or
20
lines,
we
create
the
cluster.
A
It
goes
away
and
links
it
all
together.
It
creates
machines
in
the
infrastructure,
in
this
case
Docker
containers,
it
will
bootstrap
those
machines
into
nodes.
It
will
boots
up
the
first
machines
into
a
control,
plane,
node
and
then
create
a
second
node.
That
will
be
a
machine
deployment
which
is
a
worker
node,
and
this
is
all
then
managed
centrally
from
our
management
cluster.
A
D
A
A
A
A
A
A
A
So
we're
going
to
use
Helm
to
install
this,
you
should
have
all
the
charts
and
everything
locally
so
run
that
Helm
command.
We
can
see
it's
come
up
here
and
the
next
step
is
so
we're
going
to
just
run
a
port
forward.
You
might
want
to
do
this
in
a
different
terminal
window
and
leave
this
running
in
the
background,
because
this
visualizer
is
a
really
interesting
thing
to
look
at
throughout
the
tutorial.
So
it's
really
good
to
get
an
overview
of
what
your
cluster
looks
like.
A
So
we're
going
to
run
power
forward
and
like
that
command,
you
can
either
run
it
in
the
background
in
your
terminal
or
run
in
another
terminal
and
just
make
sure
it
stays
up.
It'll
take
a
couple
minutes
to
get
up
and
when
you
contact
it
it
does
tend
to
die
if
it's
not
up
yet
so
just
try
that
in
a
couple
seconds.
A
So
this
is
our
management
cluster
we're
going
to
click
into
doc,
plus
one-
and
this
is
the
overall
topology
of
our
cluster
once
you've
got
your
cluster
up
and
running
in
your
machine
run.
This
like
I,
said
if
you
keep
it
running
in
the
background
on
your
machine
you'll,
be
able
to
check
this
throughout
the
tutorial
that
we
should
go
through
different
operations,
scaling
and
see
what
happens
so
I
think
for
the
next
few
minutes,
we're
just
going
to
run
around
and
just
help
everybody
who
can
get
up
their
first
cluster.
Just
before.
G
G
C
E
E
G
G
G
E
E
D
C
G
G
G
G
E
G
G
G
G
G
G
F
G
E
All
right,
so
the
next
section
we
are
going
to
go
through
is
cluster
topology.
So
when
we
say
cluster
topology
in
cluster
API,
we
mean
you'll,
hear
terms
like
shape
and
size.
So
typically,
it
means
things
like
the
number
of
control
plane
nodes
running
on
your
cluster.
The
number
of
worker
machines
running
on
your
cluster
is
another
number
of
pools
working
of
worker
machines
running
on
your
cluster
and
what
we
can
demonstrate
now
that
you've
built
a
cluster
with
cluster
API.
E
So
the
first
thing
we're
going
to
do
is
we're
going
to
add
a
new
pool
of
worker
nodes.
So
if
you
have
your
clusters,
all
ready
and
set
up,
what
we're
essentially
going
to
do
is
Define
a
new
declarative
spec
that
declares
a
new
worker
pool
node
we're
going
to
point
our
Cube
CTL
to
the
worker
cluster
that
we're
running
and
we're
going
to
apply
that
spec
and
we'll
see
an
entirely
new
pool
of
nodes
show
up
in
our
cluster.
E
E
E
So
here
is
here's
the
current
set
of
nodes
running
on
the
system,
so
you
can
see
I've
got
one
control,
plane,
node,
it's
that
second
one
in
the
list
and
then
I've
got
one
worker
node
with.
If
you
look
right
in
the
middle
you
can
see,
even
though
the
text
is
really
small,
you
can
see
that
little
prefix
md-0
so
again
we're
going
to
apply
a
spec
that
installs
a
new
pool
and
it's
going
to
be
identified
with
md-1,
so
I'm
going
to
run
this
Cube
ctail
apply
command
and
now
I
can
do
this.
E
E
E
So
you
can
see
it's
identified
there
in
the
middle
of
that
long,
gnarly
string
with
an
md-1
and
now
we've
gone
to
ready.
So
that
was
an
example
of
let's
like
sort
of
revisit.
What
we
just
did.
That
was
an
example
of
a
really
simple
Cube,
CTL
gesture
against
the
management
cluster
to
add
a
new
worker
pool,
and
so
then,
on
our
worker
node
we've
got
a
new
node
coming
online.
E
And
another
fun
thing
we
can
do
is:
if
we
go
over
here
to
our
visualize,
you
can
actually
see
you
saw
there
for
a
second,
the
visualizer
sort
of
refreshed
itself.
So
now
we
can
see,
even
though
it's
a
little
tight
in
there,
we
can
see.
We've
got
another
machine
deployment,
that's
a
cluster
API
crd!
So
again,
we're
looking
at
in
this
visualizer
we're
looking
at
the
cluster
API
abstraction
layer.
So
these
are
the
this
is
the
view
of
the
cluster
from
cluster
api's
point
of
view,
but
you
can
see
if
we
expand.
E
This
we've
got
md1
which
joined
the
pre-existing
md0
..
So
this
can
this.
This
visualizer
is
a
really
nice
Tool.
In
addition
to
doing
this,
watch
command
in
the
command
line,
it's
sort
of
similar
to
that
as
we
modify
the
topology,
the
visualizer
will
sort
of
show
some
in
progress,
visual
visualizations,
to
indicate
what's
going
on
all
right.
So
now
we're
going
to
do
the
same
thing
in
Reverse,
so
I'm
going
to
item
potently
apply
the
original
cluster
spec
and
that
this
is
going
to
now.
E
This
is
going
to
going
to
determine
that
there's
a
Delta
between
the
new
spec
and
this,
this
spec
right
here,
where
there's
no
longer
that
md1
in
the
configuration
and
I'm
actually
going
to
use
the
visualizer
this
time,
we
should
see
that
md1
machine
set
disappear,
so
the
way
that
you
can
sort
of
infer
this
works
is
that
the
authoritative
set
of
pools
in
that
array
is
understood
to
be
the
definitive
configuration.
So
if
we've
got
say
there,
we
go
just
got
rid
of
md1.
E
F
E
So
there
is
a
section
here
that
I'm
actually
going
to
skip
because
it
takes
about
10
to
15
minutes
and
in
the
interest
of
time
we
don't
have
to
wait
for
for
this
to
happen,
but
in
your
own
time
definitely
go
through.
This
is
a
super
powerful
gesture
for
cluster
API
to
scale
out
your
control,
plane
nodes.
So,
as
you've
probably
noticed
you
wouldn't
run
a
production
cluster,
like
we've
been
doing
in
this
demo
with
only
a
single
control,
plane,
node,
so
to
get
that
to
three
or
five
or
some
appropriately
redundant
number.
E
E
E
F
E
Kubernetes
resources,
so
this
should
be
familiar
to
folks
if
you
want
to
like
edit
a
deployment
to
increase
the
replicas,
or
perhaps
you
want
to
change
the
image
from
the
image
reference
points
to
V1,
and
you
want
to
update
that
to
V2.
So
we
can
do
something
similar
for
all
these
cluster
API
resources.
So,
as
we
see
here
in
the
the
cluster
resource,
we've
got
a
replicas
count
for
the
control
plane.
E
F
E
F
E
To
colon
WQ,
because
VI
is
my
configured
editor
here
and
I've
got
the
output
from
that
command
that
the
docker
cluster
one
resource
was
edited
now
I
can
go
over
to
the
visualizer.
I
could
also
do
a
cube,
CTL
minus
w
and,
as
we
see
right
now
under
here,
if
you
can
follow
my
mouse
on
the
screen,
we've
got
one
machine
under
this
machine
set.
So
what
we
should
see
in
30
seconds
or
so
is
that
expand
to
three
and
these
these
scale
out
events
will
happen.
Concurrently.
F
E
B
F
E
E
E
The
next
page
in
the
docs
are
about
machine
health
checks,
so
I'll
quickly
give
an
overview
of
what
this
is.
So
a
machine
health
check
is
really
a
way
of
declaring
certain
vectors
that
inform
the
health
of
a
particular
machine,
and
when
that
Vector
goes
unhealthy,
then
cluster
API
will
coordinate
and
drain
and
replace
that
machine.
F
E
Here
is
an
example:
hopefully
it's
big
enough
of
the
sort
of
at
least
for
me.
These
are
these:
are
sort
of
canonical
Health
vectors
to
check
so
at
the
top
we've
got
this
under
machine
health
check,
node,
startup,
timeout,
so
you're
able
to
declare
a
sort
of
Maximum
timeout
value,
Beyond,
which
you're
no
longer
going
to
wait
for
that
node
and
you're
actually
going
to
re-initiate
the
provisioning
process,
you're
going
to
clean
up
that
machine,
replace
it
with
a
new
one.
So
that's
one
way
of
configuring:
a
machine
health
check.
E
There
are
these
two
other
conditions
that
are
under
the
unhealthy
conditions
array
there
and
one
is
defined
as
type
ready
status
false.
So
essentially,
what
that
means
is
a
machine
is
deemed
to
be
unhealthy
if
the
ready
condition
is
not
met.
So
when
you're
doing
like
a
cube,
CTL
get
nodes,
the
the
thing
you'll
see
in
the
status
column
is
not
ready,
so
we've
got
a
timeout
defined
here.
E
What
that
tells
us
is
that
if
we,
if
cluster
API,
observes
that
a
node
is
in
a
not
ready
condition
for
five
minutes,
then
it's
going
to
go
ahead
and
recycle.
That
node,
it's
gonna,
consider
that
an
unhealthy
event,
and
similarly
this
example
here
for
ready
unknown.
So
if
you've
got
a
node
in
an
unknown
State,
it's
going
to
recycle
that
machine.
F
E
If
I
go
down
here
further,
here's
an
example
of
a
novel
machine
health
check
that
we're
defining
we're,
calling
it
demo
node,
healthy
and
similar
to
the
examples
above
this.
If
the
status
is
false
for
60
seconds
or
more,
then
we're
going
to
consider
that
node,
unhealthy
and
the
reason
we're
defining
this
novel
condition
is
so
that
we
can
easily
reproduce
this
so.
E
So
the
we
ship
these
machine
health
checks
in
that
original
cluster
class
spec.
That's
in
the
example,
so
I
should
see
those
running
here.
Okay,
great!
So
as
we
see
here,
we've
got
our
machine
health
check
output.
There's
not
that
much
detail
there.
We
could.
We
could
get
more
if
we
wanted
to
drill
down.
But
what
I'm
going
to
do
here
is.
E
Think
I
think
the
way
this
command
works.
It's
going
to
manually
patch
all
the
nodes
in
the
in
the
dock,
I
believe
we
scale
back
down
to
one
before
we
proceed,
but
this
will
be
fun
anyway.
Let's
do
it
live
demo,
so
this
is
going
to
manually
patch
these
nodes
with
these
the
condition
that
we're
looking
for
in
our
demo
demo
node
healthy
machine
health
check.
So
you
can
see
here
in
this
sort
of
gnarly
escaped
Json
data
that
we're
doing
that.
F
F
F
F
F
E
F
F
E
In
the
visualizer
and
over
here
in
our
Watcher,
which
there
we
go,
we
see
the
new
machine.
So
now,
cluster
API
has
cordon
and
drained
that
prior
machine,
according
to
the
machine
health
check,
condition
being
fulfilled
and
then,
according
to
the
rolling
update
configuration
recycled,
that
machine
brought
a
new
one
online
and
now.
F
F
E
G
G
G
B
And
also
while
people
are
working
on
this
feel
free
to
continue
this
lab
at
home
or
whenever
you
find
time
and
if
you
have
any
problems,
feel
free
to
reach
out
to
us
on
the
upsync
kubernetes
lag,
the
slack
handle
is
called
cluster
API
and
we
should
be
able
to
address
any
of
the
problems
there.
If
you
have
any
issues,
we
should
be
able
to
sit
up
there
and
feel
free
to
open
up
open
up
a
discussion
thread
and
we'll
take
a
look
yeah.
B
So
let's
take
a
look
at
what
we
have
right
now,
so
we
do.
We
have
one
workflow
cluster,
that's
that
has
one
control,
plane,
node
and
one
worker
node,
which
are
both
at
124.6
version.
Let's
try
to
upgrade
this
to
our
125
version,
and
so
since
class
API
is
declarative.
We
like
following
the
same
pattern
as
we
have
for
the
other
examples.
We
just
have
another
yaml
file
that
dictates
how
the
dictates
the
change
inversion
of
the
target
cluster
and,
if
you
take
a
look
at
that
change,
foreign.
B
Field
in
the
yaml
so
from
we
changed
it
from
124
6
to
our
125.2,
and
that's
it
that's
the
only
thing:
you'll
have
to
change
to
be
able
to
bump
up
to
a
kubernetes
version,
and
it's
as
simple
as
that.
Right
just
change
one
value
in
the
yaml
and
you
see
our
kubernetes
cluster
upgrade
should
be
triggered,
and
let's
do
that
right
now,
so
I'm
applying
the
change.
B
Yeah,
so
my
chains
of
change
is
applied
and,
let's
just
watch
the
Philippines
to
see
that
it's
changing,
oh
and
you
can
see
that
the
way
closely
type
performs
an
upgrade
on
these
workflow
clusters.
Is
it
first
upgrades
the
control
plane
nodes,
all
of
them
to
the
Target
version
and
only
after
they
are
successfully
upgraded
to
the
Target
version.
G
B
B
Yeah,
so
the
control
plane
is
completely
upgraded
to
the
Target
version,
and
now
it's
moved
on
to
upgrading
the
machine
deployment.
You
can
see
that
a
125
2
version
machine
for
the
md0
machine
deployment
is
now
being
provisioned
and
as
soon
as
that
was
ready,
the
124
6
machine
for
the
machine,
deployment
and
d0
will
be
scaled
down,
will
be
deleted
and
then
our
control
and
then
our
cluster
is
completely
considered
as
upgraded.
B
B
So
yeah
the
machine
for
the
machine
inflammation
are
completely
upgraded
and
the
control
plane
is
now
completely
updated.
So
now
we
just
have
like
one
control,
plane,
node
and
one
machine
deployment
node,
so
the
same
topology
as
for
same
topology
as
the
Clusters
that
we
had
before.
It's
just
that
both
of
them
have
been
upgraded
to
the.
F
B
Now,
let's
move
on
to
the
next
section
so
before
that
we
can
just
clean
up
this
cluster
for
now,
so
we
don't
need
this
anymore.
So
let's
just
delete
the
cluster
that
we
would
the
top
plus
the
one
cluster
that
we
have
been
using
and
after
that,
after
that
successfully
deleted.
Let's
move
on
to
the
next
section,
which
is
plus
lifecycle
books,
it's
pretty
interesting.
B
B
As
you
can
see
in
the
topology
that
we
have
here,
the
management
cluster
sends
certain
events
to
a
targeted
extent,
test
test
extension
server
that
could
be
running
anywhere
in
this
demo.
We'll
just
run
that
as
a
deployment
within
our
management
cluster
itself
and
once
the
extension
server
receives
these
events,
it
can
send
back
a
particular
response,
depending
on
the
event
that
it
received,
and
then
that
can
affect
the
Clusters
life
cycle
in
certain
ways.
A
simple
example
would
be
when
a
new
workload
cluster
is
requested
to
be
created.
B
The
management
cluster
can
then
send
a
before
cluster,
create
hook
to
the
extension
server.
The
Exchange
Server
can
either
send
back
and
allow
response
or
a
block
response.
So
if
a
block
response
is
sent,
the
workload
cluster
will
be
not
created
and
in
the
cluster
API
will
just
keep
requesting
the
test
extension
server,
depending
on
some
of
the
parameters
that
it's
sent
back
on.
Okay,
am
I
allowed
to
create
the
workload
cluster.
B
No,
if
not
just
let
me
know
when
I
need
to
check
back
and
so
on,
so
you
can
set
up
an
environment
like
like
so
where
you
have,
maybe
not
one
maybe
have
multiple
extension
servers,
each
of
them
dictating
if
you
need
to,
if
you're
allowed,
to
go
ahead
and
create
the
workload
cluster
or
if
you
need
to
wait
before
the
workload
cluster
is
created.
The
before
cluster
create
Hook
is
just
one
example.
B
So,
as
I
mentioned
before
in
this
demo,
we'll
be
running
a
test
extension
server
test
extension
server,
that
is
within
the
management
cluster,
because
it's
easier
for
this,
but
ideally
you
could
imagine
you
could
possibly
imagine
a
case
where
you
are
running
an
external,
so
external
service,
or
you
can
run
it
in
any
other
cluster
you're
not
required
to
always
run
management
cluster.
As
long
as
it's
reachable,
it
should
be
fine,
so
for
this
demo,
let's
just
run
test
actions
in
server
deployment
within
our
management
cluster.
F
B
Just
make
sure
that
our
deployment
is
running
our
text
extension
server
is
running
it's
running
it's
up.
We
have
the
one
replica
available,
so
we
should
be
able
to
move
ahead
once
the
test
extension
server
is
running.
We
need
a
way
to
register
that
with
cluster
API,
so
the
cluster
API
knows
where
it
is
how
to
reach
it
and
additional
information
like
certificates
and
so
on.
B
So
for
each
extension,
config
you
just
you
need
a
unique
name
and
I'm
using
I'm
I
have
some
CA
injection
mechanism
set
up
right
here,
so
this
is
just
to
be
able
to
inject
the
corresponding
CA
and
the
certificates
and
the
client
config
refers
to
where
the
extension
server
lives.
Since
my
extension
server
lives
within
my
within
my
management
cluster,
so
I
just
have
a
reference
to
that
particular
service.
That's
exposed
as
part
of
the
deployment,
and
it
should
be
able
to
reach
the
cluster.
B
B
I'll
I'll
leave
that
for
you
guys
to
explore
now
that
we
have
an
exchange,
server
registered
and
an
extension
server.
That's
already
running.
Let's
actually
look
at
some
of
these
events,
so,
as
I
mentioned,
cluster
API
right
now
supports
six
lifecycle.
Hooks
we'll
take
a
look
at
two
of
them,
so
we'll
try
to
create
a
workflow
cluster,
we'll
see
that
the
extension
server
receives
an
event
called
before
cluster
create
and
then
it
just
logs
it.
It
doesn't
block
the
cluster
creation
operation.
B
B
B
Yeah
so
I
did
receive
the
extension
server
received
the
before
cluster,
create
event
and
I
just
logged
it,
and
you
can
see
that
it
sent
back
a
success
response
with
retry
0
retry
0
just
implies
that
do
not
block
the
creation.
Just
let
it
go
through.
Let
it
allow
it's
basically
equal
into
an
allow
response.
B
There
is
a
there
is
a
section
at
the
end
of
this
tutorial
which
in
which
it's
an
it's
completely
optional,
in
which
you
can
try
to
change
the
extension
server's
logic
so
that
it
blocks,
and
it's
completely
optional.
Try
that
when
you
have
some
time
for
this
tutorial,
we'll
just
continue
with
the
yellow
responses,
but
I
would
highly
highly
encourage
you
to
try
it
out
to
get
a
feel
of
how
extensions
how
powerful
runtime
extensions
are
and
how
you
can
use
them.
B
Now,
let's
also
try
to
delete
the
cluster
and
we
should
receive
similarly
receive
a
delete
cluster
hook
and
again.
This
extension
server
def
defaults
to
just
allow
allowing
the
operation
to
go
ahead
and
it
doesn't
block
any
of
the
operations
and
it
should
allow
the
workload
cluster
to
get
deleted.
But
as
I
mentioned,
there
is
an
optional
option
section
in
which
you
should
be
able
to
block
it
and
see
that
the
workload
cluster
deletion
is
blocked
until
the
extension
server
responds
with
the
success.
Allow
response
foreign.
F
C
We
would
have
had
one
last
section,
which
is
about
self-hosted
clusters,
so
how
to
use
cluster
API
to
manage
cluster
API
itself
feel
free
to
follow
up
at
home.
If
you
have
any
problems,
any
questions
we
are
in
the
Upstream,
cognatus
slack
Channel
cluster
API
feel
free
to
ask.
Whenever
you
need
anything
yeah,
that's
it
feel
free
to
stick
around.
Ask
some
questions,
but,
let's
say
to
official
Park
thanks.
Everyone.