►
From YouTube: OpenShift 4: Cluster Scaling
Description
In this video we will look at different ways to scale the worker nodes of an IPI based cluster up and down. We will see how easy it is to scale up and scale down a cluster manually. We will understand the architecture concepts behind the scaling. Next we will look at the concepts of auto scaling and create the necessary OpenShift components, generate workload and autoscale the cluster. We will see how the cluster sizes itself up and down based on the workload.
For more information, please visit: openshift.com
A
In
this
video
we
will
explore
how
cluster
scaling
works
for
worker
nodes.
As
the
workload
running
on
the
cluster
changes,
we
can
scale
the
IP
I
provisioned
OpenShift
cluster
in
two
different
ways:
one
manual
scaling
or
two
auto
scaling.
Both
types
of
scaling
are
managed
using
custom
Kuban
these
objects
in
a
kubernetes
native
way.
Let
us
understand
how
manual
scaling
works.
First,
every
worker
node
corresponds
to
an
object
called
machine.
These
machines
are
managed
by
what
we
call
as
machine
sets.
A
Just
like
how
the
replica
sets
manage
parts
machine
sets
manage
machines,
you
need
a
machine
set
per
availability
zone.
So
if
you
want
to
increase
the
number
of
machines
in
an
availability
zone,
you
will
edit
the
count
for
this
machine
set.
Let's
look
at
these
objects
using
CLI.
First,
as
I
said,
these
are
custom,
kubernetes
objects,
so
we
have
custom
resource
definitions
for
machines
and
machine
sets.
So
we
are
looking
for
custom
resources
of
type
machines
and
machine
sets.
Machines
and
machine
sets
are
both
in
OpenShift
machine
api
namespace.
A
So
let's
get
a
list
of
machines
in
the
open,
shipped
machine,
API
namespace.
This
shows
us
three
machines
that
represent
masters
and
three
machines
that
represent
nodes.
Let
us
also
look
at
the
machine
sets.
These
are
the
four
machine
sets
one
for
each
availability
zone,
but
we
have
machines
running
only
in
the
first
three
availability
zones,
which
is
us
West,
2a,
2b
and
2c,
so
the
machine
sets
are
only
defined
for
the
worker
nodes.
A
Let
us
see
these
on
the
web
console
now
we'll
go
to
the
compute
section,
so
we
have
six
nodes,
three
masters
and
three
worker
nodes,
and
we
have
six
machines
correspond
to
those
nodes,
and
the
four
machine
sets
that
we
saw
from
the
CL
eyes.
So
2a,
2b
and
2c
availability
zones
are
running
one
machine.
Each
will
edit
the
count
for
the
first
machine
set
in
you
to
a
and
we'll
change
this
number
from
1
to
2,
and
this
will
scale
up
the
cluster.
A
A
You
can
see
that
the
new
virtual
machine
is
getting
initialized
and
that
virtual
machine
is
now
running
and
if
we
go
back
to
check
the
nodes
that
newly
spun
off
machine
is
now
getting
ready
to
become
a
worker
nor
the
status
has
now
changed
already,
which
means
that
it
is
ready
to
accept
the
workloads.
So
to
summarize,
just
by
changing
that
count,
machine
set
created
a
new
machine
and
the
corresponding
controller
spun
up
a
new
virtual
machine
on
AWS,
and
then
it
installed
OpenShift
to
make
it
a
worker
node.
A
Now,
in
order
to
scale
down,
we
can
do
the
exact
reverse
of
that
I'll
edit
discount
from
2
to
1
and
within
no
time
the
number
of
worker
nodes
reduced
from
4
to
3,
and
you
can
see
there
are
only
3
nodes
running
while
the
entire
scaling
mechanism
of
spinning
up
a
new
virtual
machine
and
installing
openshift
on
that
and
making
it
a
node
on
the
cluster
is
all
automated
still
I
have
to
manually
go
and
edit
the
count
in
order
to
scale
up
the
cluster.
Can
we
automate
this
part
as
well?
A
That
is
based
on
the
amount
of
workload
running
on
the
cluster?
Can
the
cluster
are
just
its
size
automatically
so
that
it
can
spin
up
additional
work?
Nodes
were
needed
and
scaled
down
when
it
is
not
needed,
and
that's
where
we
get
into
cluster
auto
scaling
for
cluster
auto
scaling.
We
have
to
set
up
two
more
objects:
a
machine
order
scalar
for
each
machine
set
that
manages
the
number
of
replicas.
That
is,
it
edits.
The
count
on
the
machine
set
based
on
the
workload
needs
and
a
cluster
order.
A
Scalar
that
manages
the
machine
order
scalars
to
scale
up
and
scale
down
the
number
of
machines
there
is
just
one
cluster
autoscaler
for
the
cluster
will
have
minimum
and
maximum
number
of
replicas
configured
for
each
machine
autoscaler.
Why
is
that?
So?
Because
we
don't
want
the
cluster
to
go
out
of
control
and
keep
on
spinning
up
additional
nodes,
just
in
case
of
a
bad
job,
consuming
a
lot
of
resources.
So
we
want
to
set
some
limits
within
which
the
cluster
scales
up
and
down.
A
A
In
the
same
way,
I'll
create
two
more
machine,
auto
scalars
for
rest
to
be
and
Wester
to
see
now
how
we
machine
Auto,
scalars
punch
one
for
each
availability
zone
with
minimum
number
of
machines
as
one
and
maximum
number
of
machines.
As
for
now,
let's
create
a
cluster
autoscaler.
I
am
setting
the
maximum
number
of
worker
nodes
on
the
cluster
to
be
capped
at
10
and
went
to
scaled
on
a
cluster.
Let's
create
the
cluster
order.
Scalar.
Now
we
have
set
up
everything
needed
for
cluster
auto
scaling.
A
At
this
point,
we
are
ready
to
generate
some
workloads
that
will
scale
up
the
cluster.
I
am
creating
a
new
project
and
I'll
be
deploying
a
workload
generator
to
this
project
as
this
job
gets
started.
Let's
look
at
the
number
of
parts.
There
are
a
bunch
of
parts
that
get
spin
up
and
each
one
of
them
consumes
a
lot
of
CPU,
so
it
will
force
cluster
to
scale
up.
As
you
can
see,
some
of
the
containers
are
getting
created
and
the
others
are
painting
and
waiting.
Let's
look
at
the
number
of
machines.
A
We
can
see
that
new
machines
have
already
come
up,
so
the
cluster
order
scaling
is
working
in
a
few
minutes.
All
these
new
machines
that
got
spun
up
will
become
open
shift
nodes.
Let's
switch
her
to
Griffin
R
to
see
how
the
workload
is.
Increasing
I
mean
that
name
space
where
the
workload
is
being
generated
and
they
shows
the
amount
of
CPU
usage
and
the
memory
usage.
The
Machine
sets
shows
that
it
is
trying
to
scale
up
to
4
machines
in
u.s.
West
to
C
and
two
machines
in
u.s.
to
s
us
West
to
B.
A
Now
the
machines
that
scaled
up
are
now
mapped
to
nodes.
So
if
we
look
at
the
nodes,
almost
all
the
roads
are
now
ready.
So
this
shows
you
how
the
cluster
can
be
set
up
to
scale
up
automatically
and
as
this
job
completes,
which
takes
a
few
minutes
after
which
the
cluster
will
scale
down
automatically.
We
can
see
that
the
workload
has
now
gone
down,
both
in
terms
of
CPU
usage
and
memory.
This
happened
a
few
minutes
back
and
the
cluster
is
gradually
scaling
down
zones.
A
Uswest,
2a
and
2b
are
just
running
one
machine,
a'
and
uswest
to
see
is
still
running
3
and
it
should
go
down
in
a
few
minutes
and
the
total
number
of
nodes
has
now
reduced
to
5.
All
the
powers
are
now
in
completed
status,
so
I
waited
for
a
few
more
minutes
and
the
cluster
is
completely
scaled
down.