►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: SIG Autoscaling - Marcin Wielgus & Maciej Pytel, Google
Come join members of SIG Autoscaling for a look at a "big picture" view of autoscaling in Kubernetes. We'll briefly discuss the different types of autoscaling (horizontal, vertical, and cluster), how they fit together, and where to use them.
To learn more click here: https://sched.co/FuLI
A
We'll
talk
a
little
bit
about
how
to
scale,
and
actually
we
have
one
additional
person
who
will
help
us
on
this
talk,
at
least
at
the
very
beginning
and
I
guess
this
guy
doesn't
need
an
introduction
here.
Everyone
knows
Bruce
Lee,
so
he
wants
a
very
nice
sentence.
A
wise
man
can
learn
more
from
a
foolish
question
that
a
fool
can
learn
from
a
wise
answer.
A
You
are
on
cube
con
and,
more
importantly,
you're
I
will
talk,
so
you
must
be
wise,
so
we
will
start
with
couple
quest
and
there
are
various
questions
that
people
ask
in
their
life.
Some
of
them
are
trivial,
like
what
should
we
eat
for
lunch?
Some
of
they
are
turning
your
life
upside
down.
Like
will
you
marry
me
and
obviously
there
are
a
couple
of
foolish
questions,
but
today
we
will
focus
on
a
question
that
is
slightly
different,
mainly
how
much
resources
do
you
need
in
your
cluster?
A
If
you
ask
this
question
to
application
developers,
you
will
get
various
answer
ranging
from
I
don't
know,
or
it
has
not
been
yet
decided
to
a
semi
random
number.
Like
places
40
took
CPUs,
which
is
probably
much
more
than
the
application
really
needs.
Sometimes,
if
you
are
lucky,
the
developers
actually
did
some
tests
at
some
version
of
the
application
based
on
some
rough
impression
of
what
the
application
usage
may
be.
If
you
are
lucky,
this
estimates
may
be
quite
accurate.
A
However,
more
often
than
not,
this
estimates
are
lacking
one
most
important
factor:
the
change
in
the
modern
software
engineering
world.
The
version
change
all
the
time.
Continuous
delivery
pipeline
pushes
in
new
versions
over
and
over
the
new
version
might
be
either
faster
than
the
previous
one
or
there
might
be
some
performance
regression
which
may
not
necessarily
be
caused
by
the
test.
A
The
traffic
may
change
some
real-world
events
may
cause
a
sudden
inflow
of
requests.
Newly
launched
feature
may
make
your
application
much
more
popular
or
miscommunication
between
development
teams
may
result
in
the
inappropriate,
API
usage
and
so
on
and
so
on,
and
these
changes
may
cause
you
a
lot
of
problems.
Your
application
might
crash
or
become
unresponsive
and
drop,
same
grief
and
a
serious
embarrassment
on
youth,
not
to
mention
financial
implication
for
your
company
and
your
future
personal
career.
A
A
The
mission
of
this
robot
will
be
to
automatically
adjust
resources
to
match
the
current
needs,
but
what
does
it
actually
mean?
The
first
goal
of
auto-scaling
is
to
save
you
from
from
this
crashing
application,
outages,
unhandled,
requests
caused
by
increased
load
or
performance
impacting
changes.
The
second
goal
of
auto-scaling
is
to
save
you
money
based
on
the
first
goal
alone.
You
could
just
provide
an
insane
amount
of
resources,
pallet
and
stuff,
and
call
it
a
day,
but
obviously
you
don't
want
to
pay
an
insane
amount
of
money.
A
You
probably
want
to
pay
just
what
is
paper,
what
is
really
needed,
so
the
ultimate
goal
of
auto-scaling
is
to
automatically
keep
the
right
balance
between
what
you
pay
and
how
much
spare
capacity
or
resources
you
have
in
your
cluster.
So
let's
go
consult
this
problem:
how
to
maintain
the
decent
load
in
your
application?
You
can
think
about
polls
and
application
as
pipes.
A
There
are
some
values
on
these
matters
that
were
indicating
that
the
load
starts
to
be
unsafe
to
the
pot,
for
example,
when
it
is
using
more
CPU
and/or
memory,
then
it
has
initially
requested.
If
the
loads
go
above
the
safe
threshold,
it
might
be
beneficial
to
start
a
new
pot
lucky
starting.
A
new
pot
is
much
easier
than
lying.
New
pipes,
thanks
to
deployments
or
stateful
sets
getting
yet.
Another
pot
is
more
similar
to
cooking
a
cookie.
A
Let's
take
a
look
at
some
more
concrete
example:
let's
imagine
that
the
gouge
say
shows
the
ratio
between
how
much
resources
I
put
really
uses,
and
that-
and
the
pot
here
has
initially
requested
on
this
example.
We
have
four
pots.
They
are
burning
hot.
They
are
almost
out
of
their
capacity.
Should
there
be
any
traffic
increase,
there
might
be
not
enough
computing
power
to
handle
it.
A
However,
if
we
add
pot
today
and
the
same
traffic
spread
across
five
pots,
then
the
average
per
pot
load
will
obviously
decrease,
leaving
more
space
for
the
spikes
in
the
future.
If
the
situation
is
slightly
different
and
the
port
load
is,
let's
say
below
50%,
meaning
that
more
than
half
of
the
resources
are
wasted,
then
it
might
be
actually
beneficial
to
remove
one
or
two
of
the
pots.
And
then
the
remaining
part
will
be
handing
study
more
traffic
and
the
requested
capacity
will
be
better
utilized
in
general.
A
We
want
to
specify
a
target,
not
too
big,
but
not
too
small,
something
that
we
would
be
happy
with.
Then
the
autoscaler
will
try
to
add
and
remove
replicas
to
move
the
load
more
towards
this
target
value,
and
this
is
what
horizontal
pot
autoscaler
in
kubernetes
does.
Horizontal
pot
of
a
scalar
is
built-in
took
the
core
of
kubernetes
from
quite
a
long
time.
It
adjust
the
number
of
replicas
to
maintain
the
target
load,
but
what
is
load
exactly
for
a
long
time?
C
A
There
was
a
hipster
which
is
now
replaced
by
metric
server,
that
scraped
basic
metrics
like
CPU
and
memory
usage
for
all
containers
running
inside
of
the
kubernetes
cluster,
and
we
created
a
simple
controller
that
talked
to
this
hipster
slashed
metrics.
Everything
that
obtained
the
utilization
and
based
on
this
utilization
is
scaled,
the
deployments
or
something
else
up
and
down.
Ok,
so
we
have
the
CP
obey
scale.
However,.
C
A
Utilization
is
not
the
only
way
to
express
the
load
for
some
people.
The
best
metric
expressing
the
load
would
be
a
request
per
second
for
others,
something
like
queue
size
if
they
are
running,
let's
say
batch
processing
workloads
for
others
who
would
like
to
have
something
more
as
a
loss
focused
and
the
good
metrics
would
be
the
latency.
And
for
that
reasons
well,
some
time
ago
we
introduced
custom
metrics
to
horizontal
path,
autoscaler
with
custom.
A
Metrics
user
are
allowed
to
point
horizontal
quad
autoscaler
to
some
metrics
stored
in
their
monitoring
solution
and
scaled
based
on
it.
On
google
kubernetes
engine,
the
metrics
are
I'm
a
beast
artist
and
driver
on
some
other
cloud
provider
or
on
Prem
it
might
be
Prometheus
or
something
completely
different.
A
A
I
said,
horizontal
part
of
the
scaler
is
controlled
by
an
API
object.
So
to
configure
it,
you
need
to
create
an
object
point
it
to
the
appropriate
deployment
replica
set
or
something
else.
You
need
to
come
up
with
the
right,
metrics
type
for
your
scaling,
so,
for
example,
CPU
load
or
something
more
custom.
You
need
to
express
the
target
load
for
CPU
utilization.
A
good
value
would
be
something
between
70
and
80%.
You
probably
shouldn't
go
much
higher,
because
then
you
will
not
have
much
space
for
spikes
and
any
scale.
A
Ups
in
the
future
may
be
slowed
down
for
the
CPU
load.
You
might
use
cubes
ETL
autoscale
comment
and
it
will
create
the
authors.
Hp
object
for
you
for
custom
metrics.
You
need
to
play
with
Yamal
a
bit
when
to
use
it
horizontal
pot.
Autoscaler
is
the
best
for
stateless
servings
workloads,
some
think
like
nginx
front-end
server
or
a
lightweight
micro
service,
something
that
starts
reasonably
fast
and
can
be
removed
and
added
at
will.
You
need
also
the
right
matrix
to
drive
the
scaling.
A
A
I
showed
you
one
way
of
dealing
with
the
load.
Let's
take
a
look
at
the
other
one.
Those
of
you
who
have
kids
are
probably
aware
of
this
problem.
You
are
in
the
constant
process
of
buying
new
clothes,
new
shoes,
new
trousers,
new
jacket
and
so
on.
For
some
reasons,
this
clothes
doesn't
have
a
knob
that
would
allow
you
to
adjust
the
size
as
the
kids
grow,
and
if
you
don't
act
proactively,
one
day
at
the
worst
possible
moment,
the
kid
will
say:
daddy,
I,
don't
worry,
wear
this.
It's
too
tight
and
start
crying.
A
If
you
try
to
put
it
on
for
the
very
last
time
and
actually
having
small
shoes
for
small
shoes
by
no
means
can
be
a
substitute
for
the
pair
in
the
right
size.
Grown-Ups
are
not
much
easier,
we
lose
and
what
is
unfortunately,
more
common.
We
gain
weight,
making
the
previously
bought
clauses
obsolete
and
kubernetes.
We
have
similar
situations,
application
grow.
The
containers
are
too
big
or
too
small,
some
workloads
don't
scale
well
horizontally,
and
for
this
workload
we
have
vertical
path:
autoscaler,
it
adjusts
container
sizes
based
on
the
real
world
usage.
A
Let's
take
a
look
at
this
this
case
we
have
a
pot
that
is
constantly
using
95%
of
its
resources.
It's
not
the
safe
situation.
If
any
traffic
spice
comes,
there
will
be
no
space
to
handle
it
or
the
container
might
even
crash
a
crash.
In
this
case,
the
pot
size
should
be
increased.
If
this
increase
and,
for
example,
the
traffic
stays
in
the
same
place,
then
it
stays
in
70%
loss.
So
there
is
a
space
for
this
bike.
So
it's
much
much
safer
situation.
A
Vertical
port
autoscaler
is
simple.
There
is
a
recommender
that
provides
spot
size
recommendation.
There
is
a
bidet
tur
that
checks
whether
the
pots
are
under
the
pots
on
the
repay,
have
good
resources
request
and
if
some
of
the
pots
don't
have
good
resources,
updater
is
responsible
for
restarting
them,
and
once
the
pods
are
restarted,
they
are
assigned
the
right
request
by
admission,
plugins
and
vertical
path.
Autoscaler
can
work
in
three
modes.
The
one
is
to
assign
recommendations
at
the
very
beginning.
A
The
one
is
like
a
full
trust
mode
in
which
you
give
full
control
over
your
deployment
to
the
vertical
path.
Autoscaler
or
if
you
don't
want
to
trust
vertical
path.
Autoscaler,
it
can
work
in
a
dry
run
mode
in
which
it
provides
you
only
with
the
recommendation
that
you
can
apply
or
not
apply
on
your
own.
A
How
to
use
it
vertical
patatas
color,
similarity
to
horizontal
patatas
color
is
contiguous,
is
controlled
by
a
API
server
object.
But
in
this
case
we
are
not
built
into
the
default
API.
It's
a
custom
resources,
the
definition,
and
if
you
are
creating
a
vpa
object,
you
need
to
select
obviously
a
set
of
policy.
You
want
to
scale
using
collaborator.
You
need
to
decide
which
mode
so
either
any
time
full
outer
or
dry
run
mode.
A
You
need
also
to
specify
boundaries
in
which
VP
should
work
like
minimum
and
maximum
size
of
the
container
and
so
on
and
so
on
when
to
use
it.
As
I
said,
VP
is
suitable
in
cases
where
horizontal
pot
autoscaler
is
not
an
option.
So
in
cases
when
you
need
to
have
a
fixed
amount
of
pots
or
the
change,
you
change
the
number
of
pots,
rarely,
for
example,
to
make
sure
that
your
staple
set
always
has
the
has
enough
memory.
A
Vp
is
recommend
in
the
recommended.
Only
mode
is
used
to
investigate
the
right
amount
of
resources
that
can
be
applied
later
later
in
time.
Okay,
so
yeah,
as
I
said,
vertical
patatas
killer
is
not
a
part
of
coke
or
kubernetes.
However,
it
is
developed
in
kubernetes
repository
and
if
you
want
to
learn
more
about
it,
it's
here
so
in
kubernetes,
slash
of
the
spill
area
on
github,
okay,
so
everyone
like
spices,
good
spices.
However,
some
really
good
spices
don't
always
go
well
together.
A
Can
you
mix
horizontal
pot,
autoscaler
and
vertical
pot
autoscaler
at
the
same
time?
Well,
not
really
not
yet,
and
not
always.
Please
notice
that
horizontal
and
vertical
pot
autoscaler
are
trying
to
solve
the
exact
same
problem.
They
keep
the
right
balance
between
what
the
pot
consume
and
what
the
pot
request.
So
if
you
run
HPA
and
we
pay
for
managing
scipio
related
stuff,
you
may
end
up
with
too
big
scale
up
our
to
big
scale.
Downs,
combining
custom
metric
base,
HPA
and
VPI
is
a
bit
safer.
A
B
Ok,
so
imagine
you
have
your
perfectly
configured
pot
out
of
Skylink
already,
and
there
is
a
big
traffic
spike
in
your
cluster
and
HPA
reacts
to
it
by
maybe
adding
some
more
replicas
of
your
application,
or
maybe
VPA
makes
your
existing
crap
recast
larger.
The
problem
is
all
that
effort
is
basically
wasted.
If
you
don't
have
space
in
your
closet,
editor
and
those
new
pots,
I
mean,
I
guess
you
can
have
monitoring
can
just
add
mod
VMs,
but
that
requires
some
manual
intervention
and
it's
really
not
very
fast
or
you
could
approach
this
problem
differently.
B
Over-Provision
and
just
always
have
enough
capacity
in
your
cluster
to
handle
any
possible
spike.
In
that
case,
the
problem
is
you're.
Basically,
most
of
your
resources
are
going
to
be
idle
most
of
the
time
so
you're
not
very
cost
efficient
and
modern
cloud
providers
have
a
lot
of
capacity
available
on
demand
whenever
you
need
it.
So
it's
it
would
be
pretty
cool
to
be
able
to
just
use
that
and
buy
as
much
VMs
as
you
need
when
you
need
them
and
just
stop
using
them.
B
When
you
no
longer
need
them
to
save
money
and
that's
exactly
what
no
doubt
of
scaling
does
so,
let's
see
how
that
works.
Basically,
what
we're
trying
to
do
is
to
make
sure
we
always
have
the
right
amount,
the
right
number
of
nodes
in
our
class
dead
and
to
talk
about
no-doubter
scaling.
We
have
to
start
with
scheduling,
since
this
is
the
inter
talk,
I'll
just
sort
of
do
a
very
high-level
basic
overview.
B
So
basically,
kubernetes
schedule
is
the
component
that
puts
pots
on
the
nodes
and
each
pot
has
a
size.
It's
basically
how
much
resources
it
requests.
So
maybe
a
small
pot
can
only
request
a
fraction
of
a
single
CPU
call,
and
maybe
a
very
large
pot
can
request
multiple
lines
on
25
to
50
CPUs
and
the
same
goes
for
memory,
GPUs
and
other
resources,
and
the
scheduler
will
only
put
a
port
on
a
node
which
actually
have
enough
resources
for
the
pot
to
learn.
B
So,
let's
consider
a
simple
example:
we
have
four
nodes
and
each
of
them
is
already
running
a
pod
and
we
have
a
new
green
pod,
which
has
just
been
created
and
I
mean
just
visually.
We
can
see
it
will
no
not
fit
with
those
large
pots,
so
what
the
scheduler
would
do,
I
see
to
just
put
it
on
the
single
node
that
actually
has
enough
space
for
this
pot.
To
run
now.
Imagine
the
same
scenario
but
slightly
changed.
B
B
So
what
we
would
like
I
will
know
how
to
scale
to
do
in
this
case
is
just
add
a
new
node,
so
there
is
enough
capacity
to
run
all
our
world
clothes.
Different
scenario
would
be
this.
We
already
have
five
nodes
and
each
of
them
around
some
pots,
but
some
of
them
actually
only
run
very
small
pots
and
have
some
actually
quite
a
lot
of
spare
capacity.
So
what
we
could
do
is
if
we
move
the
green
pod
to
the
yellow
port.
B
B
Does
it
up
selves
the
ports
in
the
cluster
and
if
it
sees
any
posts
that
are
pending
and
it
was
that
cannot
be
scheduled,
it
will
add
more
notes,
so
those
ports
can
be
scheduled
and
it
also
monitors
all
the
existing
nodes
and
if
it
finds
a
note
that
is
not
very
highly
utilized
and
can
be
removed
without
disturbing
any
ports
permanently.
It
will
remove
this
note
and
that's
sort
of
a
very
high-level
overview
of
how
cross
Delta
scale
works
and
the
important
difference
between
class
Delta
scale
and
pod
autoscaler
is
pull
out
of.
B
Scalars
is
what
they
look
at
so
h:
PA
and
V
P
a
look
at
actual
usage
metrics,
so
basically
how
much
your
CPU
actually
uses
and
how
that
relates
to
what
you
would
like
it
to
use
across
the
autoscaler.
On
the
other
hand,
only
cares
about
the
stuff
that
component
is
scheduler.
Cad
cares
about.
It
won't
help
you
if
you
actually
you'll
pull
the
requests
way
way
less
resources
than
it
needs
to,
and
it
just
crashes,
because
you'll
note
doesn't
have
enough
resources.
B
All
it
does
is
it
makes
sure
that
every
pot
can
be
scheduled,
and
that
includes
both
resource
requests
and
motor
scheduling,
more
advanced
kubernetes
scheduling
mechanisms
so,
for
the
best
effect
it's
good
to
use
both
pod
outer
scaling
and
crust
out
or
scaling.
They
are
designed
to
complement
each
other
okay,
so
how
to
use
cross
Delta,
Scylla
well,
I
mean
contrary
to
put
out
of
scalars
its
it
lives
in
between
a
kubernetes
cluster
and
cloud
provider.
B
So
basically,
every
cloud
needs
a
specific
integration
with
cluster
Delta
scalar
and
currently
supported
clouds,
Google
cloud
platform,
AWS,
agile
and
recently
added
Alibaba
cloud,
and
unfortunately,
the
configuration
is
slightly
different
on
each
of
those
platforms
on
GK
is
just
a
simple
assigning,
a
single
comment
in
other
crowds.
I
believe
you
need
to
run
your
own
cross,
the
autoscaler
deployment
and
all
the
details
are
documented
in
our
repo.
So
that's
the
best
place
to
start.
B
B
Basically,
where
are
we
with
all
of
those
components?
So
Christ
autoscaler
is
generally
available
and
have
been
in
GA
for
about
a
year
now.
So
it's
a
pretty
major
and
stable
product
HPA
based
on
cpu
utilization,
has
been
in
GA
for
even
longer
and
HP.
A
with
custom.
Metrics
is
currently
in
beta.
Finally,
VP
a
is
in
alpha,
but
we're
about
to
graduate
it
to
beta,
so
it
should
be
in
beta
release
on
and
what's
the
progress
or
what?
What
are
we
working
on
right
now
in
improving
those
features?
B
Finally,
they
were
in
I
believe
kubernetes
112.
Some
changes
to
the
HPA
API
that
allows
you
more
control
over
exactly
which
metric
is
used
for
auto
scaling.
On
the
VPI
front,
we
received
a
lot
of
feedback
from
our
alpha
users,
so
if
any
of
you
use
it
in
alpha,
thank
you
and
we've
basically
managed
to
fix
a
lot
of
buck
and
approve
the
and
approved
instability.
So
we
believe
we
ready
almost
ready
for
beta.
B
Finally,
on
the
crust
out
of
Scylla
will
mostly
just
maintaining
it.
We
have
done
a
lot
of
work
to
improve
the
performance
recently,
so
we
hope
you'll
be
able
to
use
it
on
larger
clusters
than
before
and
also
there
is
an
ongoing
effort
to
integrate
cluster
to
scaler
with
cluster
API,
which
is
a
separate
kubernetes
project.
B
B
B
So
if
you
want
to
just
use
out
of
scaling,
features,
ask
us
about
anything
contribute
something
to
the
auto
scaling
space.
In
kubernetes
we
have
Sigma
ting
each
Monday
at
4:00
p.m.
Central,
European
Time,
that's
the
zoom
link
and
we
also
have
a
channel
on
the
kubernetes
slack
and
a
lot
of
our
most
active
contributors
are
quite
active
on
this
channel.
So
that's
also
quite
a
good
place
to
ask
us
any
questions
of
discuss
any
features
you'd
like
finally
most
of
our
stuff
lives
in
this
repository.
B
So
that's
a
good
place
to
look
at
the
code
open
any
issues
or
just
the
documentation.
The
only
exception
is
HPA
which
actually
lives
in
the
main
kubernetes
kubernetes
repo,
and
the
very
last
thing
I
want
to
mention
is
other
auto-scaling
talks
on
this
cube
con.
So
tomorrow,
at
half
past
eleven
me
and
machine
will
do
seek
out
the
scaling
deep-dive.
Well,
we'll
talk
more
about
vpa
and
cross.
B
The
autoscaler
sort
of
in
more
detail
talk
about
more
advanced
use
cases
and
how
it
works
internally,
and
I
was
a
friend
alexander,
I
will
have
a
talk
tomorrow
at
5:00
Pacific
discussing
how
to
get
cross
the
autoscaler
to
work
on
other
clouds
that
have
not
yet
supported,
and
basically,
what's
involved
with
this,
and
that's
it
from
us.
Thank
you
very
much.
If
you
have
any
questions.
D
A
D
But
only
when
utilization
value
is
not
enough
because
maybe
I
have
mutti
all
skating
group
different
screen
group
is
for
different
use
case
y
is
for
big
data
table
is
for
online
work
loss,
but
maybe
they
have
different
utilization
value
per
current.
We
we
can
only
decide
what
and
why
is
for
CPU,
GPU
memory
and
odd
metrics
I
think
maybe
we
should
have
different
utilization
module
and
for
different
I
was
getting
group.
A
So
if
you
need
please,
please
send
code,
we
may
do
it
by
ourself.
However,
it
may
take
a
while
anyway,
also
the
all
the
class
or
the
scalar
code
is
in
public.
So
if
you
think
that
something
extra
is
needed-
or
there
is
a
use
case
that
we
didn't
fought
about-
please
come
to
our
meeting
course
and
as
PR
or
file
an
issue
and
will
gladly
accept
any
contribution
in
that
area.
C
A
Be
a
generic
as
possible,
so
we
have
a
separate
API
to
get
a
matrix
that
is
independent
of
any
mentoring
solution
that
is
on
the
market.
So
we
don't
want
to
bless
any
monitoring
social,
for
example,
make
Prometheus
the
only
sub
natively
support
associate.
So
all
matrix
solutions
are
kind
of
considered
equal
and
all
of
them
probably
will
require
some
kind
of
adapter,
which
is
relatively
lightweight.
So
it
shouldn't
be
like
a
great
problem
unless.
E
A
But
there
are
other
winter
exposure
on
the
market,
so
if
we
blessed
prometheus,
then
guys
from
data
dock
would
also
like
to
have
the
same
level
of
support,
and
obviously
our
company
will
ask
us
to
do
the
same
for
star
driver
and
we
will
be
originally
supporting
the
whole
range
of
monitoring
solution
in
the
core
of
kubernetes,
which
we
don't
want.
Please
remember
that
HPA
sits
in
the
main
controller
manager
so
plug
in
there.
Any
libraries
that
are
specific
to
a
particular
monitoring
solution
may
not
be
well
as
well.
E
We
may
have
some
situation
data.
We
know
that
in
the
future
we
have
some
activity
and
then
we
know
like
maybe
tomorrow
at
the
10:00
we
have
some
requests
pi.
So
if
I
currents,
time
enabled
I'll
just
butt,
autoscaler
and-
and
we
haven't
heard
so
many
requests
and
at
hours
go
down
my
resource.
So
how
can
how
can
I
prevent
this?
Maybe
well
I?
Don't
I
need
to
prepare
for
tomorrow
that
there
will
be
a
spike.
The
spike
over
very
high
and
autoscaler
were
not
skill.
My
resource
immediately.
B
A
Fill
up
your
motor
spinning
groups,
whatever
you
not
group
equivalent,
you
use
on
your
cloud
or
you
can
mark
your
notes
as
unremovable
and
we
then
cluster
autoscaler
will
not
touch
them.
We
don't
yet
have
an
integration
of
any
of
our
two
scalars
with
calendar,
so
you
cannot
say
that
I
don't
know
at
1:00
p.m.
on
Friday.
C
C
A
B
F
Welcome
to
Shanghai
and
this
year
for
HP
and
I,
my
team
is
running
the
companies
on
top
of
it
a
sec,
ETS,
okay,
and
you
can't
use
the
cloud
formatting
to
manage
the
nose
and
in
a
scale,
I
was
killing
such
crime
things.
So
my
question
is:
if
we
use
this
cluster
autoscaler,
so
is
there
any
specific
value
we
can
be
added?
On
top
of
you
know,
you
can
see
moment.