►
From YouTube: Intro: Autoscaling SIG - Marcin Wielgus, Google
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: Autoscaling SIG - Marcin Wielgus, Google
Join members of SIG Autoscaling to learn how to automatically adjust your Kubernetes cluster and pods to match your current capacity needs. We'll discuss all available types of autoscaling - horizontal, vertical, and cluster. We will also explain ways to use them, when they are applicable and how they fit together.
https://sched.co/MPh6
A
B
A
I
would
like
to
join
the
keynote
speakers
and
welcome
you
at
cube
con
and
in
the
beautiful
city
of
barcelona.
Barcelona
is
a
very
popular
tourist
destination.
Many
people
visit
it
because
it's
the
gateway
to
beautiful
beaches
of
Costa,
Brava
and
Costa
Dorada.
Some
people
come
here
to
visit
famous
monuments
like
sagrada
familia
/,
guell,
gothic
district
other
enjoyed
the
city,
atmosphere
and
love
to
walk
for,
vivid
and
bustling
boulevards
like
redonda
there
among
acrobats
painters,
cartoonist,
burgers
and
pickpocketers.
A
If
they
look
carefully,
they
can
spot
them
fortune
tellers
the
force
of
ten
years
for
handful
of
euros
will
tell
you
your
future
will
tell
you
your
good
and
bad
moments
to
come,
would
be
your
prince
and
princess
arming
whether
your
current
love
will
last
for
the
lifetime
and
if
they
are
really
really
good,
they
will
tell
you
what
will
be
the
names
of
your
grandchildren.
They
will
answer
any
of
your
questions.
A
A
How
big
my
pots
should
be?
Well,
they
will
react
with
complete
astonishment.
The
set
true
is
that
currently
there
are
no
cloud
native
certified
fortune
tellers
who
understand
the
internals
of
kubernetes,
not
even
in
Barcelona,
not
on
la
rambla.
You
can
ask
these
questions
to
your
developers,
devops
admins
product
managers.
They
may
have
a
really
good
grasp
on
kubernetes
and
your
product
domain.
A
They
can
do
a
lot
of
measurements
test
checks.
However,
most
of
the
technical
people
don't
have
strong
clairvoyant
skills,
and
the
life
will
always
find
a
way
to
surprise.
You
proper
pod
count
for
today
may
be
too
little
for
tomorrow
when
the
traffic
increase,
an
absent-minded
developer,
may
forget
to
mention
that
he
increased
the
cash
in
your
application
ten
times
and
now
it
starts
rolling
out
of
memory
exception.
A
Someone
from
another
team
may
start
another
workload
in
your
cluster
depleting
its
capacity,
and
you
were
called
to
fix
it
if
lucky
within
your
business
hours,
you
slightly
less
lucky
at
3:00
a.m.
on
Saturday,
and
obviously
you
don't
want
to
be
woken
up
and
called
with
alerts.
You
would
like
to
have
an
automation,
a
robot
who
would
observe
your
cluster
and
add
or
remove
computational
capacity
when
needed,
to
keep
your
workouts
healthy
and
what
is
equally
important
to
keep
your
monthly
bills
as
low
as
possible.
A
Lucky
for
you.
We
have
a
couple
of
such
robots
in
kubernetes
and
now
I'm
going
to
describe
them
to
you.
The
first
robot
is
called
horizontal
pot.
Autoscaler
horizontal
pot
autoscaler
is
based
on
metrics
that
Express
the
load
that
your
application
gets.
It
can
be
either
real
CPU
usage
or
something
a
little
bit
more
custom
like
the
number
of
queries
per
second
that
are
coming
to
your
application
or
other
gouts,
like
value
provided
by
the
user.
A
A
But
before
that,
let
me
clarify
something.
While
talking
about
horizontal
pot,
autoscaler
I
will
use
a
word.
Utilization
I
understand
it
as
a
ratio
between
the
current
load
X
by
some
metrics
and
the
maximum
amount
of
load
that
your
application
can
handle.
For
example,
if
your
pot
requests
one
CPU
and
is
currently
using
half
of
it,
then
your
utilization
is
50%.
If
a
pot
can
handle
1000
QPS
but
its
processing
200.
At
this
moment,
then
the
utilization
is
20%.
A
A
But
if
we
add
another
pot
and
the
same
traffic
is
spread
across
five
pots,
then
the
average
per
pot
load
obviously
will
decrease.
Leaving
more
space
for
spikes
and
coming
closer
to
the
desired
target
in
this
way,
if
the
situation
is
slightly
different
and
four
and
all
the
pots
are
below
the
target
like
significantly
below
the
target,
then
it
might
be
actually
beneficial
to
delete
one
of
the
pots
and
then
the
traffic
on
the
remaining
pots
will
increase.
A
The
post
will
be
better
utilized
and
you
will
have
more
resources
in
your
cluster,
and
this
is
what
horizontal
pot
autoscaler
does
it
add
and
delete
replicas
when
needed
when
to
use
HP
a
horizontal
pot.
Autoscaler
works
best
with
stateless
serving
workloads
that
can
spin
up
new
replicas
reasonably
fast.
You
can
also
use
horizontal
pot
autoscaler
with
Q
based
processing
how
to
enable
it
HP
is
a
part
of
core
kubernetes
api
s--.
It
is
controlled
by
HP
object.
You
can
create
this
object
either
with
the
ml
file
or
by
cube
CTL,
auto
scale
command.
A
Cpu
usage
is
available
out
of
the
box.
Custom
metrics
require
a
little
bit
more
work
while
setting
up
horizontal
pot
autoscaler.
It
is
crucial
to
set
the
target
value
or
more
generally,
target
utilization
write.
A
simple
formula:
1
utilization
is
the
size
of
your
spike
buffer
capacity,
and
the
driver
for
scallops
2,
small
spike
buffer
may
prevent
scallops
and
may
overload
the
application
too
big,
obviously
waste
your
money.
A
The
value
of
the
target
utilization
should
allow
your
application
to
run
with
the
increased
traffic,
but
with
the
old
number
of
replicas
for
at
least
2
minutes
to
allow
HP
or
reaction,
possibly
not
provisioning
and
starting
new
pots.
So
if
you
expect
that
within
any
2
minutes
your
traffic
may
rise
by,
let's
say
50%,
your
target
utilization
should
be
set
to
65%
or
less
if
it
can
double
to
50%
or
less
and
so
on
and
so
on.
A
What
are
the
other
best
practices
for
horizontal
potato
scaler
application
under
HP
I
should
correctly
handle
6
terms.
This
means
that,
after
receiving
the
signal,
the
application
should
not
stop,
but
finish
all
of
the
requests
that
are
currently
in
flight
and
still
listen
for
the
incoming
connections
that
may
arrive
after
the
pod
termination
begins.
It
may
take
a
while
to
update
all
q
proxies
in
your
clusters
and
all
components
of
the
load
balancers,
sometimes
even
one
minute
or
more,
depending
on
your
cloud
provider.
A
Also,
your
new
replicas
should
not
receive
a
request
before
they
are
ready
for
that.
To
ensure
ensure
that
please
PLEASE
setup
readiness
probe
for
your
pots
and
by
the
way,
also
liveness
probes.
It
is
a
good
practice,
even
without
horizontal
potato
scaler,
but
it's
particularly
useful
when
your
pods
are
constantly
starting
instead,
pink.
Also,
please
keep
your
metric
server
healthy.
It
is
the
source
of
CPU
utilization,
metrics
and
without
it,
HPA
doesn't
work.
Last
but
not
least,
please
enable
a
cluster
autoscaler
while
adding
new
replicas.
A
A
Ok,
what
is
the
next
big
thing
for
horizontal
potato
scaler?
The
barrack
functionality
has
been
there
for
quite
a
while
CPU
base
scaling
is
considered
G
a
custom.
Metric
scaling
is
considered
to
be
like
delayed
beta,
but
we
are
adding
more
knobs
for
advanced
users.
We
have
couple
peers
in
flight
that
will
add
more
controls
and
speed
for
scale
up
scale,
downs
and
their
sensitiveness.
Moreover,
we
want
to
allow
scaling
down
from
zero
and
to
zero,
for
HP
is
driven
by
custom
metrics.
A
The
second
robot
from
our
happy
auto
scaling
family
is
vertical
path.
Autoscaler,
vertical
path,
autoscaler
monitors
the
real
CPU
and
memory
usage
to
estimate
what
should
be
the
best
pot
size
in
terms
of
requested
CPU
and
memory.
What
request
is
used
by
scheduler
to
decide
where
to
put
the
pot
on
which
machine
only
machine
that
has
enough
free
resources
can
host
the
pot
pot
request
also
defines
how
much
request
will
be
guaranteed
for
your
application.
If
it's
too
small,
then
the
application
might
be
either
throttled
or
Metro
out
of
memory
exception
or
both.
A
If
it's
too
big,
then
your
resources
are
obviously
wasted
and
your
money
is
wasted.
So
it
is
quite
important
to
set
pato
request
right.
So
what
does
vpa
do?
Let's
take
a
look
at
this
example.
Here
we
have
a
pot
that
uses
95%
of
the
requested
capacity.
It's
not
the
situation
in
this
case
vertical
path.
Autoscaler
will
recommend
to
increase
pot
size
so
that
the
same
load
consumes
only
let's
say:
75%
cup
of
capacity,
not
95.
A
If
the
load
on
the
pot
is
low
and
for
extended
period
of
time,
VP
or
it
will
recommend
to
decrease
pot
size
to
free
some
space
and
allow
better
utilization
of
your
machines,
vertical
pot,
autoscaler
can
work
in
free
modes.
In
first
it
only
provides
recommendation
but
doesn't
change
anything.
The
user
is
responsible
for
setting
the
spot
request
manually
in
the
second
slightly
more
automatic
mode.
It
only
set
spot
request
for
new
pots.
It
doesn't
touch
the
existing
pots,
even
if
they
have
sub
optimal
requests.
A
You
can
use
vertical
pot
autoscaler
for
both
stateless
and
stifled
workload,
especially
if
they
cannot
be
handled
with
horizontal
path,
autoscaler
and
obviously
vertical
pot.
Autoscaler
is
particularly
useful
when
you
have
no
idea.
What
should
be
your
pot
size
and
auto
mode
is
quite
handy
if
your
application
can
be
started
and
you
gained
enough
confidence
with
VP
recommendations
when
running
it.
In
recommendation
on
remote.
A
Vertical
pot
autoscaler
is
not
a
part
of
Cal
Cooper
Netta's.
You
either
need
to
install
it
manually
as
an
additional
component
on
an
able
it
on
your
kubernetes
managed
solution
like
GAE,
with
appropriate
cloud
provider
specific
commands,
then
you
create
a
vertical
pot.
Autoscaler
custom
resource
definition
object
pointing
to
your
application
in
a
similar
fashion,
as
in
HPA.
However,
this
time
you
don't
have
a
dedicated,
cube,
CTL
comment
now
a
list
of
best
practices
for
vp8
mentioned
earlier.
A
You
should
start
your
adventure
with
vertical
pot
autoscaler
in
a
recommendation
only
mode
give
it
a
while,
like
a
day
or
maybe
more,
to
learn
here.
What
is
your
workload
to
see?
What
are
your
daily
patterns
convince
yourself
that
the
recommendations
are
good
and
then
consider
switching
hit
total
vertical
potty
autoscaler
is
still
better
soon
being
a
little
bit,
cautious
may
be
addressed
while
running
in
the
outer
mode.
Please
set
pot
disruption
budgets.
A
Actually
you
should
set
them
and
way
for
many
other
reasons
when
configuring
vertical
pot
autoscaler
set
minimum
and
maximum
container
sizes
in
VP
object
just
to
be
on
the
safe
side.
In
outage,
like
situation,
for
example,
when
your
traffic
is
not
coming
over
to
your
application
for
hours
or
maybe
days,
vpmi
significantly
reduce
the
pot
size
and
then,
when
you
suddenly
enable
the
traffic,
you
may
have
an
unpleasant
surprise
vertical
pot
autoscaler.
Does
it
update
your
deployment
or
stateful
set
specification?
A
It
only
updates
spots
when
they
are
created,
so
a
good
practice
is
to
put
reasonable
pot
requests,
for
example,
taken
from
VP
recommendations
in
the
deployment
itself.
Just
in
case
you
have
some
problems
with
VP
a
or
someone
turns
of
VP
accidently.
You
don't
want
to
lose
like
this
evaluated
pot
sizes
vertical
pot.
Autoscaler
doesn't
like
huge,
abrupt
changes.
For
example,
if
you
had
40
pots
and
you
suddenly
decide
to
turn
your
deployment
from
30
to
5
pots
in
one
step,
it's
not
the
best
idea.
A
You
should
do
it
gradually
over
a
day,
a
VPS
truss
history,
so
very
significant
changes
like
a
completely
new
image.
Complete
redesign
may
require
a
new
VP
object
and
maybe
a
new
deployment
with
different
labor
set
VPI
takes
matrix
from
metric
server,
so
it
is
important
to
keep
metrics
server
a
healthy
and
in
the
same
way
as
horizontal
pot
autoscaler.
You
should
enable
cluster
autoscaler
in
your
cluster
in
case
vp,
a
enlarge
your
pot.
Beyond
your
available
capacity,
can
you
mix
a
horizontal
pot,
autoscaler
and
vertical
path,
autoscaler
on
the
same
workload?
A
Well,
the
short
answer
is
no.
The
more
detailed
answer
starts
with
execute
Gaussian
and
it
depends
technically.
You
can
always
use
vertical
path,
autoscaler
in
recommendation
on
any
mode
and
see
what
it
says.
It's
safe,
nothing
bad
should
happen,
and
you
can
always
discard
the
recommendations.
However,
in
order
to
get
stable
results,
you
should
either
use
custom
metrics
in
horizontal,
put
out
the
scalar
or
absolute
values
for
your
HP
targets
when
scaling
on
CPU,
and
you
should
make
sure
that
the
application
is
getting
enough.
Traffic.
A
Horizontal
potahto
scalar
should
not
be
running
at
the
absolute
minimum
number
of
replicas
and
way
beyond
the
target
utilization.
Switching
vertical
path,
autoscaler
to
auto
when
mixing
to
if
HP,
is
risky
and
should
shouldn't
be
done
without
the
deeper
understanding
of
HPV
piant
in
your
workload
characteristic.
A
Ok,
what
next
with
vpa,
we
have
200
major
things
on
the
road,
not
as
I
said
previously,
VP
a
is
in
beta
and
we
hope
to
graduate
it
to
GA
soon
and
we
are
working
on
the
support
for
in
place
spot
request
updates.
Currently,
in
order
to
update
pot
requests,
the
pot
has
to
be
recreated,
and
obviously
your
application
has
a
small
here
cap.
This
is
not
an
optimal
situation
and
we
are
working
with
come
in
G
particular
with
the
note
and
scheduling
teams
to
fix
it.
A
Now,
the
third
and
last
robot
cluster
autoscaler,
horizontal
pot,
autoscaler
and
vertical
pot
autoscaler,
are
targeted
at
scaling.
Your
workloads,
cluster
autoscaler
scale
is
the
underlying
computing
infrastructure.
It
provides
notes
for
your
pods
for
pods
that
don't
have
a
place
to
run
it
also
compacts
underutilized
nodes.
It
is
based
on
scheduling,
simulation
and
declared
port
requests.
It
doesn't
use
metrics
like
actual
CPU
use
it
or
mine
on
QP
ASIS.
So,
let's
take
a
look
on:
how
does
it
work
in
practice?
Here
we
have
four
nodes
and
with
four
pots
free
ports
are
big.
A
One
pod
is
relatively
small,
and
on
that
note
we
have
a
little
bit
of
free
capacity.
If
I
new
pod
comes,
then
maybe
it
will
fit
into
this
third
node
and
the
scheduler
will
place
it
there
and
it
will
start
running
there.
However,
if
all
nodes
are
kind
of
full
and
scheduler
has
no
way
of
placing
the
pot,
you
need
another
node
and
cluster
autoscaler
notices
this
situation.
It
talks
to
your
cloud
provider
and
spins
up
a
new
node.
A
The
new
node
arrives,
scheduler
notices
it
and
lays
the
pot
on
the
new
node,
and
everyone
is
happy
on
some
occasions.
Some
nodes
may
not
be
utilized
to
their
full
potential.
Let's
take
a
look
at
this
picture.
Small,
yellow
and
green
pods
have
notes
for
themselves.
If
we
move
the
green
pod
to
the
third
node,
then
the
last
node
will
be
empty
and
can
be
safely
deleted.
Like
this
reducing
your
monthly
cloud
bill-
and
this
is
exactly
what
cluster
autoscaler
does.
It
adds
and
removes
replicas
as
needed.
A
We
want
to
use
castrato
scalar.
This
short
answer
is
always
especially
if
you
have
more
than
two
free
nodes
in
your
cluster
and
your
workloads
change
all
the
time.
Cluster
autoscaler
works
with
multiple
cloud
provider.
It
has
support
for
Alibaba
AWS
as
your
Baidu
Google
cloud
platform
and
OpenStack
running
with
Magnum.
A
To
enable
cluster
autoscaler,
follow
your
cloud
provider
specific
guide
heads
some
environments,
like
google
kubernetes
engine,
have
built-in
easy
to
use
cluster
autoscaler,
but
many
require
additional
manual
steps.
Please
check
the
appropriate
documentation
for
details.
Best
practices
use
the
hosted
version
of
trust
autoscaler.
If
your
cloud
provider
supports
it
or
has
it
in
managed
solution,
pick
the
version
if
you're
running
it
manually
pick
the
version
of
cluster
autoscaler
that
matches
your
cluster
version
or
more
specifically,
scheduler
version.
A
There
may
be
some
subtle
differences
between
scheduler
versions
and
they
may
result
in
inconsistent
cluster
autoscaler
behavior
and
define
the
pod
disruption
budget
for
your
application
to
make
sure
that
the
critical
workloads
are
not
moved
too
frequently
or
in
large
extent,
as
I
mentioned
it
with
vertical
path
autoscaler.
But
it
is
also
useful
when
running
cluster
autoscaler
in
your
cluster.
A
What's
next
with
cluster
autoscaler
well,
the
project
has
been
in
gie
for
quite
a
long
time
and
no
bigger
changes
are
expected.
They're,
probably
the
only
bigger
thing
that
is
coming
is
the
support
for
clustering.
Pi2
support,
more
cloud
providers
and
mark
environments
like
on-premise
as
the
stock
is
slowly
getting
to
the
end.
I
would
like
to
give
you
a
little
bit
more
information
about
auto
scaling,
special
interest
group
itself.
A
We
have
meetings
every
Monday
at
4:00
p.m.
Barcelona
time
on
zoom'.
We
have
quite
active
slack
channel
where
you
can
ask
questions
and
propose
your
new
ideas
and
most
of
our
stuff,
like
cluster
autoscaler
and
vertical
path.
Autoscaler
sees
in
kubernetes,
slash,
autoscaler
repository
on
github
HP
itself,
seen
kubernetes,
/,
kubernetes,
repo
and
last
but
not
least,
I
would
like
you
to
I
would
like
to
invite
you
to
other
auto-scaling
talks.
A
We
have
sick,
auto-scaling,
deep
dive
where
we
will
get
into
details
of
cluster
autoscaler
and
vertical
path,
autoscaler
on
Thursday
at
3:55,
the,
and
there
are
two
talks
and
focus
on
pod
requests.
In-Place
upgrades
both
of
tomorrow,
the
first
one
is
at
11:05
and
the
second
one
immediately
after
yet
11:55,
and
this
is
the
end
of
my
talk.
Thank
you
for
being
and
training
with
me
today
and
now
we
have
a
couple
minutes
for
questions.
A
A
C
C
A
Have
any
possibility
to
do
it?
Yes,
it
can
move
pods
when
before
the
node
is
completely
empty,
so
the
default
setting
is
50
percent.
So
if
your
pod,
if
you're
noticed
utilized
in
less
than
50
percent
in
terms
of
pot
requests
and
cluster
autoscaler
khan,
starts
to
consider
this
knob
as
not
that
much
needed
and
if
it
finds
a
place
for
all
pots
from
this
node
to
be
moved
also
elsewhere,
and
there
are
no
system
pots
note
what
we
put
with
restrictive
pot
disruption,
budget
and
couple
of
other
conditions
are
met.
A
A
E
A
A
No,
no,
you
shouldn't
do
like
anything
like
super
special.
Your
readiness
probe
should
indicate
whether
your
application
is
ready
to
take
traffic
and,
let's
draw
for
the
cases
where
you
have
auto
scaling
in
the
picture
and
as
well
as
in
two
cases
where
you
don't
have
auto
scaling
in
the
picture.
Basically,
when
your
application
is
ready,
the
networking
part
of
kubernetes
adds
the
pods
to
the
service
and
reports
my
receive
traffic.
A
If
your
application
and
declares
that
is
not
ready
or
it's
not
ready
yet,
then
the
pods
are
not
added
to
the
service
and
they
will
receive
no
traffic,
so
the
readiness
probe
is
not
done
for
the
auto
scaling
itself.
It's
done
for
to
make
your
networking
aware
of
the
state
of
your
application.
It
wouldn't
be
that
important
if
you
had
a
very
stable
situation,
so
you
start
your
pods
at
let's
say
January
the
first
and
they
run
on
the
same
machine
for
for
a
year.
A
F
You
mentioned
that
I
shouldn't
stop
accepting
new
requests
when
I
receive
a
sitcom
because
of
as
a
movement
event
or
a
scaled-down
event.
So
what
actually
do
when
I
get
sick
Tom,
because
my
understanding
was
that
I
would
set
readiness
to
false
and
continue
processing
requests,
I
have
and
when
I'm
done
with
that
stop,
but
if
I
am
still
supposed
to
get
new
requests
when
when
do
I,
stop
doing
them.
Okay,.
A
So
let
me
answer
it
that
in
more
details,
so
what
happens
when
your
pod
declares,
that
is
an
unready
or
its
start
termination
process?
It
is
removed
from
the
service
endpoint
list
and
all
of
the
coup
proxies
in
your
cluster
will
be
notified
about
it.
However,
this
cube
proxies
have
a
control,
look
and
control
loop,
basically
execute
every
ten
seconds.
So,
if
you
are
unlucky,
it
will
take
ten
seconds
from
the
time
that
the
pot
is
declared
as
unready
to
the
time
when
it
is
removed
from
queue
proxy
on
a
particular
node.
A
If
your
cluster
is
big
and
there
is
a
lot
of
going
on
there,
it
may
take
longer
like
20
seconds
on
30
seconds
and
during
that
time,
all
nodes
or
some
nodes
in
your
cluster
will
still
think
that
the
pot
on
the
other
side
is
there
and
will
receive,
will
be
able
to
accept
new
traffic.
So
it's
a
problem
of
letting
all
of
the
components
in
your
cluster
know
what
is
going
on
and
it
takes
time
also
on
some
cloud
providers.
Updating
load
balancers
take
some
time.
A
A
Minion
yeah
and
then
you
will
receive
sick,
a
kill
signal.
If
what
at
this
moment,
your
application
will
deplete
it's
graceful
termination
time
and
will
receive,
kill
signal
or
you
can
terminate
after
one
minute
or
you
can
also
measure
how
measure
it
on
your
cloud
provider
in
your
deployment,
how
fast
it
reacts
and
wait
for
that
amount
of
time.
Everything
depends
on
specific
environment,
but.
B
A
G
G
A
Know
you
don't
have
it,
however,
services
like
hosted
version
of
services
may
have
cluster
out
the
scaler
built
in
and
it
will
be
easier
for
you
to
deploy
it
on
DK.
It's
just
a
single
command
to
enable
it
I
believe
on
Azure.
It
is
also
like
built
into
ETS,
so
we
can
enables
it
quicker,
but
on
other
cloud
providers
or
if
you
are
running
kubernetes
in
custom
mode
on
clock
infrastructure,
you
just
need
to
execute
a
little
bit
more
manual
step.
A
So
start
cluster
autoscaler
pod
manually
and
configure
it
in
proper
way,
but
you
can
use
it
on
all
of
the
cloud
infrastructure,
animation
heat
on
some
cloud
providers.
It's
a
little
bit
easier
on
some
other,
it's
a
little
bit
more
difficult,
but
in
general
you
should
not
have
like
much
troubles
with
with
it.
D
A
However,
as
I
mentioned
with
VP
a
please
be
careful,
so
VP
a
star
C
story
and
if
you
run
a
benchmark
and
then
don't
run
a
benchmark
for
let's
say
a
week,
and
then
you
enable
full
traffic
at
once
and
then
VP
a
will
be
slow
to
responding
to
this
traffic.
So
it
will
run
basically
that
there
was
nothing
there
for
a
week.
It
would
recommend
small
percent.
It
will
take
a
while
before
it
starts
recommending
like
bigger
pod
sizes
right.
A
B
A
Knows
so
her
cluster
autoscaler
supports
the
GPUs,
it
waits
until
they
are
properly
spinned,
but
well
kind
of
do
nothing
to
make
things
faster,
so
I
don't
have
like
and
you
like,
meaning
forget
the
advices
for
scaling
GP.
You
knows
it
also
depends
what
type
of
traffic
you
run
it
are.
Are
you
running
bad
jobs
or
some
serving
workloads,
zoomerton's.