►
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
Rightsize Your Pods with Vertical Pod Autoscaling - Beata Skiba, Google
Specifying CPU and memory needs for your application is often a fortune-telling exercise where time will almost certainly prove you wrong. Assigning too few resources endangers you with CPU starvation and Out Of Memory events; assigning too much hinders cluster utilization. Predicting the right values is challenging since workloads change and evolve. In this talk, we'll teach you how Vertical Pod Autoscaler can set resource assignments for you and how using it with Cluster Autoscaling and Scheduling can give you peace of mind.
To Learn More: https://sched.co/GrYe
A
So
in
kubernetes
the
size
of
the
pot
is
expressed
as
a
resource
requests.
So
let's
first
take
a
look
at
what
it
means
and
how
it
impacts
your
applications.
You
have
probably
all
seen
something
like
this.
This
is
the
simple
deployment.
Actually
it's
a
part
of
a
simple
deployment,
but
for
the
sake
of
simply
simplifications,
so
that
shouldn't
be
too
hard
right.
You
just
want
to
deploy
a
simple
thing
to
your
kubernetes
cluster.
I
would
like
to
focus
specifically
on
the
part
that
is
shown
at
the
bottom,
so
the
resource
request
part
here.
A
We
say
that
deployment
needs
100,
megabytes
of
memory
and
250
milli.
Suppose,
ok,
that's
fantastic,
but
how
do
we
know
that
so
the
reality
looks
more
often
like
this.
We
don't
know
we
have
no
idea
how
much
resources
our
applications
will
actually
need.
But
why
is
that
even
important?
Why
is
the
fact
that
we
often
don't
know
how
to
see
set
those
resource
requests
harmful
for
our
applications?
So,
to
start
with,
the
resource
request
is
actually
a
contract.
It's
a
contract
between
your
workload
and
the
kubernetes
scheduler.
A
The
resources
that
you
requests
are
guaranteed
to
be
reserved
for
your
workloads,
provided
that
they
are
available
in
the
cluster.
So
this
means,
for
example,
that
if
you
require
a
certain
amount
of
CPU
or
memory,
kubernetes
scheduler
promises
never
to
put
your
workloads
on
a
note
that
can't
support
that
that
doesn't
have
that
resources
available.
So,
on
the
other
side
of
this
bergen,
if
there
is
no
such
place
for
your
workload
currently
available
in
the
cluster,
the
scheduler
will
not
schedule
your
pod
anywhere.
So
a
short
disclaimer.
A
This
is
not
entirely
true,
because
now
we
have
priority
and
preemption
in
kubernetes,
but
assuming
all
your
pods
have
the
same
priority
at
the
moment.
This
is
what
will
happen.
So
we
know
now
about
resource
requests.
Is
the
contract,
but
that's
a
big
word,
and
what
does
it
really
mean
in
practice?
So
we'll
analyze
two
example
situation
to
see
how
resource
request
impacts
the
situation
of
your
workloads
in
your
cluster.
So
this
is
the
first
one
and
we
have
two
notes
in
the
cluster.
A
They
are
both
free
and
they
have
9990
use
available
space
and
we
have
two
pods
just
waiting
to
be
scheduled.
One
is
requesting
200
mils,
another
six,
600
million
views.
Okay,
this
one
is
easy
right.
One
pod
guts
goes
into
OneNote.
Another
part
goes
into
another
node,
but
now
imagine
that
we
have
mistakenly
set
the
resource
requests
of
the
first
spot,
the
red
one.
So
we
said
it
actually
needs
200
new
CPUs,
but
it
actually
uses
500,
miss
abuse.
So
at
the
moment
it
also
okay
right.
A
There
is
spare
capacity
on
the
note
where
you're,
scheduled
and
kubernetes
is
so
specifically.
Cubelet
will
give
you
those
spare
resources,
because
it
makes
no
sense
to
have
that
CPU
sitting
idle.
But
now
we
have
another
pod
there's
another
part:
it
requests
600
and
a
CPU,
and
it's
a
good
citizen.
It
actually
uses
the
exact
amount
of
resources
that
it
requests.
Of
course
that
never
happens,
but
let's
assume
and
according
to
your
contract
of
the
scheduler,
you
only
need
200
million
views
and
that's
what's
guaranteed
for
you.
So
what
scheduler
will
do?
A
It
will
go
ahead
and
schedule
the
pot
in
that
free
space.
So
now
we
have
the
situation.
Your
workload
is
are
happy.
It
doesn't
have
this
free
space
that
it
previously
depended
on
so
well,
it's
actually
not
going
to
also
it's
not
going
to
get
better
with
time,
because
the
scheduler
only
use
it
looks
at
the
resource
requests.
So
it
doesn't
actually
know
that
your
workload
is
unhappy.
A
800
meters,
the
other
one,
is
the
same
as
before
so
far.
So
good
scheduling
is
easy.
One
part
guards
on
one
note
another
on
the
second
one,
but
what
if
the
situation
is
reversed
from
what
we
had
in
the
first
place?
What
if
we
said
that
we
need
more
than
we're
actually
using
at
this
moment.
This
is
not
such
a
big
deal
because
well
those
resources
would
sit
idle
anyway,
right
we're
not
harming
anyone
else
in
this
cluster.
A
But
again
we
have
a
new
pod
and
what
happens
now
is
scheduler
again
takes
a
look
at
all
the
contracts
that
it
has,
and
it
sees
that
there
is
no
space
to
schedule
the
new
pod,
because
otherwise
it
would
have
to
violate
one
of
the
contracts
that
it
has.
So
basically,
your
pod
is
pending
and
it
stays
spending.
So
this
is
not
good.
You
have
the
workload
that
you
want
to
run
and
it's
not
running,
even
though
the
resources
are
there
like
in
theory,
they
are
there.
A
So
things
get
a
tad
better
if
you
have
cluster
two
scalar
configured
in
your
cluster,
because
the
pending
pod,
the
permanently
pending
pod,
is
just
a
signal
that
cluster
of
the
scalar
waits
for
in
order
to
trigger
it's
Kayla.
So
it's
seize
your
pot.
It
sees
that
it's
in
a
pending
state
it
kicks
in
and
it
adds
a
new
machine
for
you.
Okay,
so
that's
a
little
bit
better
right,
because
the
schedulers
notices,
the
new
note
schedules
the
pot,
and
now
everyone
is
happy
right.
A
Well,
maybe
all
your
across
all
your
workloads
run,
that's
good.
They
have
enough
resources,
they
actually
have
more
than
enough
resources,
but
if
the
resource
requests
were
set
correctly
in
the
first
place,
we
wouldn't
need
that
fir'd
note,
so
we're
actually
using
more
resources
than
we
need.
So
summing
up,
there
is
danger
in
both
too
small
and
too
big
boxes
for
your
workloads.
If
your
requests
are
too
low,
as
we've
seen,
the
scheduler
will
pack
your
notes
tightly.
A
Then
the
pots
don't
have
enough
resources
root
to
run,
and
this
results
in
several
unhappy
endings.
You
can
have
out
of
memory,
error
errors
or
workloads
evicted
due
to
memory
pressure,
and
these
both
cause
disruption
to
your
workflows.
They
cause
your
your
pots
to
be
evicted
and
rescheduled
on.
They
can
also
become
pending.
A
If
you
have
CPU
starvation,
then
your
workers
will
be
underperforming
because
they
actually
need
more
CPU
than
they're
given,
and
what
is
more,
this
will
be
the
worst
when
you
need
it
the
most,
because
when
your
cluster
is
under
high
load
and
you
needed
to
perform,
you
need
your
workloads
to
perform
on
their
best.
They
will
actually
be
frugal
and
they
can
actually
become
evicted
because
of
not
enough
memory.
So,
lastly,
as
I
mentioned
before,
this
will
not
get
better
over
time.
A
Nobody
used
looks
at
the
actual
usage
of
your
applications
only
on
the
requests,
so
until
you
come
and
change
them
yourself,
you're
in
D
and
happy
state,
so
it
ends.
What
is
more,
this
will
not
get
better.
Even
if
you
cluster
autoscaler
configured
because
as
we've
seen,
it
depends
on
seeing
a
pending
pod
that
has
no
space
to
run,
but
that
this
in
turn
depends
on
the
scheduler
to
see
that
this
part
should
be
pending,
which
in
turn
again
depends
on
correct,
correctly,
said:
resource
requests.
A
On
the
other
hand,
if
we
specify
too
high
resource
requests,
then
this
may
cause
us
to
waste
resources.
If
we
overshoot
them,
the
scheduler
will
spread
the
pods
on
more
nodes
that
we
actually
need
and
the
cluster
the
scaler
with
will
kick
in
earlier,
because
it
was
depending
pods
that
don't
have
space
to
schedule
in
your
cluster.
A
So
that's
not
a
pretty
picture
that
we
painted.
What
can
we
do
about
it?
How
can
we
set
resource
requests
right?
There's
a
couple
ways
that
you
can
do
you
can
try
out
your
applications
by
creating
cannery
deployments,
you
can
try
simulating
production,
Road
and
then
set
requests
for
your
production
workloads.
Based
on
that,
you
can
also
go
with
trial
and
error
sort
of
a
trial
and
error
procedure.
You
deploy
your
workloads
with
some
requests.
Then
you
see
if
they're
happy,
they
are
happy.
You
look
at
their
actual
usage.
Do
they
need
more?
A
Do
they
need
less
and
you
sort
of
figure
it
out
on
the
way
you
can
also
just
try
to
guess,
and
it's
actually
a
bit
frightening
and
but
sort
of
understandable.
Looking
at
how
hard
it
is,
there
is
a
lot
of
people
doing
it.
This
way,
it's
hard
setting
resource
request
is
hard,
so
all
of
those
bad
fights
have
downsides
and
testing
and
caring
they
require
additional
resources.
Right.
They
require
require
time
effort.
They
require
additional
computational
resources.
A
What
is
more,
your
results
will
they
make
and
they
most
probably
will
differ
from
what
you
later
see
in
production
and
the
last
one.
The
last
one
is
the
like
the
most
infuriating
one,
because
even
if
you
tailor
your
research
like
perfectly
for
for
this
moment,
actually
the
resource
needs
of
your
applications
will
change
over
time,
just
because
the
load
is
changing,
the
traffic
is
shifting.
A
So
let
me
present
the
hero
and
all
this
unhappiness.
It's
vertical
productive
scalar
and
it
essentially
does
three
main
things.
It
does
the
thing
that
I
said
kubernetes
scheduler
never
does
it
goes
ahead
and
looks
at
the
actual
usage
of
your
applications.
While
they
run
then
based
on
these
observations,
it
makes
recommendations
for
what
your
workloads
should
actually
be
using
and
then,
if
you
configure
it
to
do
so,
it
will
update
the
resource
requests
of
your
running
workloads
and
that
last
part
is
experimental
and
I
will
comment
more
on.
A
Why
that
is
a
little
bit
later
and
all
the
information
about
vertical
scaling
is
contained
in
a
vpa
object.
It's
defined
as
a
customer
services,
customer
search
definition,
and
it
is
divided
as
most
kubernetes
objects
into
spec
and
status,
so
the
spec
controls
what
and
how
should
be
scale
and
the
status
is
where
your
recommendations
are
actually
provided.
A
So
since
VP
a
object
is
the
central
point
of
everything
we're
talking
about
onwards.
Let's
take
a
closer
look
at
what
it
contains
and
what
it
like.
What
does
it?
Let
us
do
so
VP
a
spec
is
the
way
for
you
to
provide
the
information
on
what
and
how
you
want
to
scale.
So
this
is
an
example
spec
that
vertically
scale
of
a
worker
deployment.
A
Now,
where
do
I,
don't
that
from
so
the
selector
is
the
what
to
scale
part-
and
this
is
expressed
as
a
regular
kubernetes
label
selector,
and
this
gives
us
quite
a
bit
of
flexibility,
because
this
example
shows
how
to
outer
scale
a
single
deployment,
but
you
can
actually
say
that
only
part
of
your
deployments
should
be
vertically
scale
or
I.
Have
this
two
deployments
and
they're
actually
pretty
similar?
Please
scale
them
together.
For
me,
the
how
to
scale
part
consists
of
update
policy
in
resource
policy.
A
The
a
bleep
I
see
lets
you
control
the
actuation
part.
So
how
are
the
equipment
recommendations
applied
to
your
workloads
and
there
are
free
update
modes
available?
Currently,
the
first
is
off
and
it's
sort
of
a
dry
run.
It
lets
you
get
the
feel
of
how
EPA
works
for
you,
because
it
provides
the
recommendations,
but
it
will
never
never
actually
modify
your
pod
requests.
A
The
second
mod
is
an
initial,
and
this
will
only
change
parts
requests
during
creation,
but
it
will
never
forcefully
restart
your
parts
to
change
their
requests,
so
this
will
tap
into
any
pod
creations
that
are
caused
by
something
else
than
vpa
system,
so
evictions
caused
by
other
systems.
Adding
new
parts
to
deployments
was
killing
it
horizontally,
then
rolling
updates.
A
But
if
your
workloads
are
very
stable,
you're
not
adding
pods
they're,
not
crashing
and
restarting,
then
it
will
not
apply
your
recommendations
to
the
running
pods
and
the
last
one
is
outer,
and
this
is
a
full
thing.
So
this
will
take
a
look
and
the
pods
running
in
your
cluster
and
restart
them
once
their
requests
are
too
far
off
from
the
recommended
resources,
and
you
can
also
control
the
scaling
of
containers
inside
the
pods
that
are
controlled
by
by
your
VP,
a
specifying
per
container
policies.
A
A
This
is
the
status
it's
the
output
of
vertical
part
of
the
scaler.
This
is
where
recommendations
are
provided
and
the
recommendations
are
provided
on
a
container
level.
So
we
recommend
resources
for
all
the
containers
that
were
configured
to
be
vertically
scaled.
The
recommendations
contains
three
things:
it
contains
the
target
value
a
lower
and
upper
bound,
so
the
target
is
it's
highlighted
because
it's
the
most
important
thing-
and
this
is
the
actual
recommendation.
This
is
what
we
currently
think
that
your
workload
should
be
using
at
the
moment.
A
The
lower
and
upper
bounds
are
sort
of
indicators
of
confidence
of
our
recommendation.
What
this,
what
they
actually
say
is
anything
below
lower
bound
is
known
to
be
not
enough
for
the
workload
and
anything
above
upper
bound
we
know
is
wasteful
and
the
bounds
get
closer
to
the
target.
The
more
usage
samples
we
collect
so
the
more
confident
we
are
that
the
recommendation
that
we're
providing
is
based
on
a
lot
of
data.
So
it's
more.
A
We
have
more
confidence
that
it's
right,
so
this
finishes
the
part
that
you
need
to
know
as
the
user
and
now
for
those
interested.
How
basil
looks
under
the
hood.
Let's
take
a
look
at
how
vpa
provides
actually
provides
recommendations
for
you,
so
this
is
a
slight
I'm,
not
very
proud
of,
because
there's
a
lot
of
things
in
it.
But
what
I
would
like
to
focus
on
is
that
vpa
is
actually
divided
into
three
independent
parts
and
these
are
actually
free,
independent
binaries
and
they
all
interact
only
through
the
VPA
object.
A
Never
directly,
so
we
have
VP
a
recommender,
and
this
is
the
like
the
brain.
This
is
the
thing
that
provides
recommendations
for
you.
We
have
a
VP
admission,
plug-in
that
plugs
into
the
pod
creation
process
in
kubernetes
to
actually
update
the
resource
requests
of
your
pods
when
needed,
and
the
third
part
is
the
VP
updater,
and
this
watches
the
running
pods
and
restarts
those
that
have
their
requests
too
far
away
from
recommendation
again.
If
this
is
configured
to
be
done.
A
So
so
the
fact
that
these
three
are
separate
and
that
the
only
communicate
via
VP
a
object--
is
important
from
extensibility
and
plug
ability.
Part
because
if
you
have
it's
very
easy
to
provide
an
environment,
specific
recommender
that
will
calculate
the
recommendations
completely
differently
and
there's
a
whole
things
the
works,
you
can
also
switch
out
updater
if
you
want-
and
this
whole
thing
still
works.
So
let's
take
a
look
at
all
those
errors
and
boxes
that
were
there
in
more
detail.
So
first
I
want
to
talk
about
DP
recommender.
A
So
this
is
the
part
it's
the
most
important
part.
It
watches
what's
happening
with
your
pods,
the
positives,
you
configure
it
to
be
vertically
scaled
and
it
gets
actual
resource
usage
from
metric
server,
and
it
also
gets
events
that
are
connected
with
memory
usage.
So
out
of
memory,
events
and
evictions
due
to
memory
pressure-
and
it
takes
a
look
at
VP-
a
expect
to
see
which
parts
it
should
actually
calculate
calculate,
recommendations
for
and
based
on
the
observations,
it's
revised,
the
recommendation.
A
So
what's
the
math
behind
this,
you
know
waving
of
a
hands
in
the
magic
VPN.
Kubernetes
currently
uses
a
recommendation
model
that
has
been
used
successfully
in
google
borg
infrastructure.
It
collects
usage
samples,
history
in
a
histogram
and
then
takes
a
very
high
percentile
of
that
as
target
recommendation.
It
currently
does
this
for
the
last
eight
days,
so
the
history
is
accumulated
for
the
last
eight
days,
if
it's,
if
it's
available-
and
it's
important
to
note
that
this
is
not
part
of
the
API,
as
I
said
before,
the
recommender
is
pluggable.
A
A
So
now
we
have
our
accommodation
ready
now
we
would
like
to
make
use
of
it.
So
when
a
part
is
created,
it
goes
through
in
kubernetes.
It
goes
through
a
series
of
admission
plugins
and
one
of
those
is
a
mutating
weapon
at
mission,
plugin
with
which
can
be
configured
to
call
external
web
hooks
to
do
some
things
to
the
pod
that
is
currently
being
created,
and
one
of
those
plugins
is
the
VP
admission
plugin
and
what
it
does
it's.
It's
aware
of
all
the
active
vertical
part
out
of
scaling
objects
in
the
cluster.
A
It
sees
the
pod
that
is
currently
being
created.
It's
it's
watch.
It
takes
a
look
at
the
VP,
a
objects
and
verifies
if
this
this
pod
actually
matches
one
of
those
and
if
you
have
configured
your
pod
to
be
actually
actuated
upon.
So
the
initial
and
outer
moat
that
I
said
that
I
talked
about
before
it
will
modify
the
resource
request
to
the
target
of
the
recommendation.
A
In
the
last
part,
the
experimental
part
is
actually
updating
pods
running
pods
during
their
lifetime.
So
this
is
experimental
and
there's
several
reasons
for
that.
Firstly,
in
kubernetes,
the
pot
spec
is
immutable,
so
what
this
means
it's
actually
impossible
in
the
kubernetes
system
to
change
resource
requests
in
place.
You
cannot
modify
your
search
request
of
a
pub
during
its
lifetime,
so
what
do
you
have
to
do?
A
Is
you
have
to
evict
the
pot
and
let
it
be
recreated,
and
only
then
you
can
assign
the
correct
resource
requests,
so
this
will
cause
actual
disruption
to
your
workload
and
there's.
A
second
reason
currently
vpa
is
not
aware:
it's
not
very
aware
of
the
infrastructure
that
you're
running
in
a
way
that
it
can
recommend
pot
sizes
that
don't
fit
your
cluster,
for
example,
too
big
for
all
your
notes,
when
it
happens,
it
will
stop
updating
your
pods,
but
still
this
will
cause
this
can
make
cause
actual
disruption.
A
So
the
way
this
works
now
now
we
have
this
disclaimer
of
experimental
out
of
the
way.
The
way
this
works
is
updater,
constantly
analyzes
the
list
of
pods
and
when
it
notices
that
there
is
a
pod
that
is
too
much
out
of
sync
with
the
recommendation,
and
this
translates
actually
to
if
the
requests
is
outside
of
the
lower
and
upper
bound
that
we
talked
about
before
this
means
that
it
needs
to
be
updated.
So
the
updater
goes
ahead
and
evicts
the
pod,
and
this
goes
through
the
kubernetes
eviction
api.
A
So
it
will
observe
any
pod
disruption,
budgets
that
you
have
and
then
it
depends
on
a
controller.
So
the
pod
has
to
be
created
by
a
replica
set
or
stateful
said
it
would
not.
So
we
rely
on
the
controller
to
recreate
a
pod
and
then
go
through
all
those
submission
plugins
again
and
get
correct
resource
requests
assigned.
A
So,
like
literally
I
mean
we
were
just
about
to
open
a
final
PR
with
updates
to
documentation
and
we
were
ready
to
go
so
I
expect
if,
when
you
come
back
from
this
cube
colony,
we'll
find
it
that
it
is
indeed
in
beta
and
then
what
are
the
plans?
What
we
believe
is
we're
still
missing.
The
most
are
two
key
areas
and
the
first
one
is
setting
application
limits
because,
as
maybe
some
of
you
notice,
through
all
of
the
talk
I've
been
talking
about
requests.
A
So
if
that
happens,
and
we
will
be
able
to
take
advantage
of
that
and
to
also
be
able
to
do
non-disruptive
updates
to
your
workloads
whenever
that's
possible,
because
imagine
you
just
want
to
shrink
your
pod,
it's
not
going
to
use
more
requests,
it's
still
going
to
fit
on
the
note
why
we
started
right.
So
there
is
like.
We
recognize,
however,
that
this
effort
will
require
significant
amount
of
work.
A
So
we
are
watching
this
we're
trying
to
help
with
the
with
the
community
movement
to
to
make
those
resource
requests
mutable
and
also
make
that
this
work
actually
for
for
VP
a
so
that
we
can
take
use
of
it
to
provide
not
don't
not
don't
not
disruptive
updates,
I'm,
not
sure,
that's
very
visible,
but
we're
actually
part
of
stick
out
of
scaling.
You
can
find
us
at
the
kubernetes
autoscaler
repo
on
github.
Please
go
check
it
out,
check
vpa
out.
Let
us
know
how
it
works
for
you
and
I
guess
that's
it.
A
B
A
The
question
was,
will
be
ever:
will
the
updater
epoch
pods
gradually?
It's
very
much
depends
on
your,
so
it
uses
the
eviction
API.
So
if
you
have
a
pod
disruption
budget
that
only
says
you
can
also
only
have
one
put
down,
then
it
will
just
update
one
by
one.
It
also
has
some
internal
rate
limiting.
So
we
have
I,
don't
remember
the
exact
numbers,
but
it's
probably
something
like
not
more
than
10%
of
your
workload
can
be
down
at
one
go,
but
you
can
control
it
very
well.
A
So
the
question
was:
if
you
have
a
new
version
of
your
deployment
and
it's
actually
different,
because
it's
a
new
version
and
has
different
memory
needs,
it
actually
needs
more
memory.
Will
the
same
history
be
used?
So
the
answer
at
the
moment
is
yes,
the
same
history
B
will
be
used
so
we're
in
early
stages,
and
we
will
be
looking
at
how
we
can
also
be
smarter
with
the
deployment
lifecycle
right.
A
So
the
question
was
it
integrates
with
metrics
server,
but
does
it
also
have
a
way
to
plug
in
other
metric
metric
providers
or
does
it
work
with
other
metric
providers
I
believe
we
have
some
integration
of
Prometheus
I'm,
not
sure
how
well
that
works?
Actually
we
don't
have
it.
We
definitely
don't
have
it
extensively
tested,
but
there
is
a
way
to
provide
different
to
have
a
different
metrics
provider
in
a
system.
Oh.
A
Yes,
yes,
that's
so
the
question
was:
can
you
explain
how
this
works
with
HBA?
So
at
the
moment
the
answer
is
with
CPU
and
memory.
It
doesn't,
unfortunately,
so
they
will
erase
each
other.
They
were
not
aware
of
each
other,
so
they
will
race
each
other
with
it's.
Actually
we
haven't
tested
it
extensively,
but
the
intuition
is.
It
won't
work
very,
very
well
on
the
same
metrics,
but
what
you
can
do
is
HPA
now
supports
custom,
metrics
and
external
metrics,
and
we
actually
have
people
successfully
using
VP
a
with
H
configured
on
custom
metrics.
A
A
A
So
the
question
is:
if
there
is
no
CPU
requests
or
memory
quest
specified
for
the
deployment,
will
it
still
work?
Yes,
it
will
still
work.
We
don't
depend
on
the
request
initial
requests
to
to
work.
We
will
just
look
at
your
usage.
The
only
problem
is,
if
you
actually
so,
if
you
have
no
resource
request
set
at
the
beginning,
if
you
don't
use
the
outer
mode,
if
you
just
deploy
your
deployment,
it
takes
some
time
for
DPA
to
generate
the
recommendation.
A
If
the
pods
are
already
running
and
they're,
not
you
know
being
restarted
for
whatever
other
reason.
If
you
don't
have
automatic
updates
in
VPI,
they
will
just
run
without
the
requests.
But
if
you
have
auto
mode
on
or
if
something
happens
to
your
application,
we
have
new
pods
coming
then
this
they
will
get
the
new
recommended
resources.
I
think
I've,
seen
here
questioned
for
some
time.
A
A
We
ask
kindly
ask
kubernetes
a
big
de
pot
for
us
and,
however
long
it
takes
it
will
it
will
accept
that
so
we're
we
were
actually
thinking
of
limiting
the
graceful
termination
period
period,
because
if
you
have
a
very
long
graceful
termination
period
that
will
make
your
VP
a
very,
very
slow
in
updating
your
pods.
But
at
the
moment
this
is
your
choice.
If
you're
apart
have
a
very
long
graceful
termination
period,
we
will
definitely
observe
that.
B
A
Two
questions
first
was:
how
long
does
it
take
for
the
lower
and
upper
bounds?
Who
actually
calls
for
evictions?
And
so
let
me
first
answer
that,
so
this
is
heavily
dependent
on
how
your
workload
is
dependent.
There
is
we're
behaving
I
can.
If
you
come
later,
I
can
show
you
specifically
what's
how
it's
done,
but
I
think.
Basically
it
is
conservative,
so
at
the
moment
I
think
after
12
hours
you
need
to
be.
A
If
you're
overshooting
you
need
to
overshoot
by
I
think
at
least
three
times
something
like
that,
and
then
it
goes
down
after
a
day.
It
goes
much
closer.
So
once
you
have
actually
accumulated
full
history,
it
can
react
very
fast.
It
will
also
react
faster
if
you
have
actual
out
of
memory
errors,
so
it
will
see
that
and
will
actually
bump
it
up
very
much
so,
but
it's
very
it's
very
work
on
specific.
So
there's
no,
like
you
know
after
this
time
the
update
will
happen.
A
As
I
said,
I
can
come
and
then
I
can
show
you
the
actual
piece
of
the
code
that
the
comments
in
the
code
that
describe
how
it's
done,
and
there
is
the
second
question,
the
domino
effect.
So
is
it
so
whenever
one
part
needs
updating,
probably
the
other
and
it
gets
killed,
the
other
Pods
will
get
more
load
and
then
they
need
to
be
killed
too
because
they
start
like
they're
even
worse.
So
the
way
this
works,
the
recommendation
is
provided
for
the
whole
workload.
So
all
of
your
parts.
A
So
at
the
moment
we
decide
we
need
to
update
your
pods.
We
decide
we
app.
We
need
to
update
all
your
parts
if,
in
the
meantime,
your
pod
gets
shut
down.
The
recommendation
may
vary
slightly
because
of
the
domino
effect
that
you
mentioned,
but
I
would
actually
have
to
see
it
in
the
world
to
see
that
this
actually
causes
domino
effect,
because
I
think.
B
B
B
A
The
suggestion
was
only
update
on
surface
upgrade
and
I
think
this
is.
This
is
handled
if
I
understand
collect
correctly.
What
you
mean
this
is
handled
by
the
initial
mode,
so
this
is
this:
takes
this
never
forcefully
automatically
restarts
your
pods.
It
will
only
apply
the
recommendations
if,
for
some
other
reason,
for
example,
an
upgrade
your
pods
are
being
recreated
and
we
see
them
created
so
I
think
this
is.
This
is
what
covers
this
use
case,
and
it
should
be.
It
should
be
useful.
C
A
The
question
was:
is
there
any
overhead
running
this
permanently
as
opposed
to
just
learning
and
then
using
that?
So
this
is
actually
running
in
your
cluster.
If
you
deploy
it,
it's
it's
actually
adding
some
loud
to
your
cluster,
because
this
is
free,
free,
binaries,
additional
binaries
running
in
your
cluster.
It
will
also
cause
some
additional
load
on
your
API
server
because
it
needs
to
fetch
it'll
push
all
the
data
and
the
metric
server
or
another
metric
provider.
A
A
So
I
only
heard
the
first
part.
The
first
part
was:
is
there
a
lower
like
hard
low
lower
bound?
So
the
answer
is
yes
and
I.
Don't
remember
this
I
think
it's
I,
don't
remember
the
specific
numbers
because
we
changed
it,
but
I
can
go
and
check
it,
but
there
is
actually
we
there
is
a
lower
bound
under
which
we
don't
recommend
resources.
A
So
this
so
the
question
is,
is
it
limit
range
aware
I
mean
so
the
answer
is
I.
Think
limit
range
also
works
as
an
admission.
Plugin
am
I
correct,
so
it's
sort
of
with
admission
plug-in,
like
VP,
is
also
an
admission
plugin.
So
this
this
depends
on
how,
on
the
on
the
order,
so
I
think
I'm
not
sure
how
this
works
with
the
web
hook.
Plugins,
because
it's
possible
that
the
web
park
admission
plug-in
runs
at
the
very
end,
and
then
this
will
not
work.