►
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
Introduction to Autoscaling - Marcin Wielgus, Google & Vivek Bagade, Google
Come and see how to reduce the cost of your cluster and make your workloads more robust by dynamically adjusting them to the current traffic. During this talk members of SIG-Autoscaling will explain why you should be autoscaling both applications and clusters, and what tools Kubernetes provides to do that. You will learn the mechanics of Cluster, Horizontal Pod and Vertical Pod Autoscalers, their new features as well as the best practices for applying them in production.
https://sched.co/UaiK
A
A
So
you
prepare,
you
are
logging
monitoring,
alerting
you
check
whether
your
applications
are
well
configured.
You
do
load
test
and
analyze
traffic
first
to
validate
the
apps
themselves,
but
also
to
answer
questions
like
how
many
pots
should
I
have
in
my
deployment
how
big
the
pots
should
be,
how
much
resources
do
I
need
in
my
cluster,
and
these
are
not
easy
questions.
Of
course,
lots
of
measurements,
tests,
checks
and
what
difference
can
be
performed.
However,
most
of
technical
people
don't
have
strong
clairvoyant
skills
and
life
will
always
find
a
way
to
surprise.
A
Someone
may
start
another
workload
in
the
cluster
depleting
its
capacity
and
you
will
be
called
to
fix
it
according
to
Murphy's
laws,
more
likely
at
the
worst
possible
time,
and
obviously
you
don't
want
to
be
woken
up
in
the
middle
of
the
night
or
interrupted
during
vacation.
You
would
like
to
have
an
automation,
a
robot
would
observe
your
cluster
and
add
or
remove
a
computational
capacity
when
needed,
to
keep
your
workloads
healthy
and,
at
the
same
time,
to
keep
your
monthly
bills
low
lucky
for
you.
A
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
the
application
gets.
It
can
be
either
CPU
usage
or
something
a
little
bit
more
custom
like
the
number
of
queries
per
second
or
some
other
gods,
like
value
provided
by
the
user.
A
Hpa
takes
the
value
of
the
metrics,
compares
it
with
the
user-defined
target
and,
depending
on
this
comparison,
adds
or
removes
replicas
hoping
to
move
the
matrix
towards
the
desired
value.
Let's
take
a
look
on
how
does
it
work
in
practice,
but
before
that,
let
me
clarify
something.
While
talking
about
HPA
I
will
use
a
word.
Utilization
I
understand
it
as
a
ratio
between
the
current
load
expressed
by
some
metrics
and
the
maximum
amount
of
load
that
the
application
can
handle.
A
For
example,
if
a
pot
requested
one
CPU
and
is
using
only
0.5,
then
the
CPU
utilization
is
50%.
If
the
pot
can
handle,
let's
say
1000
Q
PSS,
but
is
processing
only
200
at
this
given
moment,
then
the
utilization
is
obviously
20%.
Okay.
Now
the
mentioned
example.
On
this
example,
we
have
four
pots
that
are
burning
hot.
They
are
reporting
very
high
utilization.
Their
load
is
above
the
target
they
use
almost
all
of
their
capacity.
Should
the
traffic
increase
there
might
not
be
enough
computing
power
to
handle
it.
A
A
If
the
situation
is
slightly
different
and
for
each
of
the
pots
the
load
is
below
the
target,
then
it
might
be
actually
beneficial
to
delete
one
of
the
pots.
Then
the
traffic
on
the
remaining
pots
will
increase,
the
pots
will
be
better
utilized
and
you
will
have
more
free
resources
in
your
cluster,
and
this
is
what
horizontal
pot
autoscaler
does.
It
adds
and
deletes
what
replicas,
when
needed,
when
to
use
horizontal
pot
autoscaler
horizontal
path,
autoscaler
weren't,
the
best
we've
stated
serving
workers
that
can
spin
up
in
replicas
reasonably
fast.
A
You
can
also
use,
for
example,
autoscaler
with
other
workers
like
something
related
to
Cubase
processing
and
so
on.
How
to
enable
it
horizontal
photo.
Scanner
is
a
part
of
core
kubernetes
api
s--
HPS
is
controlled
by
an
HP
object.
You
created
this
object
either
we
manually
with
providing
here
mode
definition
or
by
cube
outer
scale
command.
Cpu
utilization,
auto
scaling,
is
available
out
of
the
box.
Custom
metrics
require
a
little
bit
more
work.
Please
check
the
documentation
for
details
while
setting
up
HPA.
A
It
is
crucial
to
set
the
target
value
or
a
more
general
target
utilization
right.
One
utilization
is
your
spike
capacity
and
the
driver
for
scallops
small
buffer
made
prevent
scallops
and
may
overload
your
application
too.
Big
obviously
causes
a
waste.
The
value
of
the
target
utilization
should
allow
you
to
run
with
the
increased
traffic,
but
with
the
old
number
of
replicas,
for
let's
say
two
three
minutes
and
still
have
a
bit
of
buffer.
A
What
are
the
other
best
practices
for
horizontal
pot
autoscaler
applications
under
HPA
should
correctly
handle
seek
terms.
This
means
that,
after
receiving
this
signal,
the
application
should
not
stop
immediately,
but
finish
all
of
the
requests
that
are
in
flight
and
still
listen
for
incoming
connection
that
may
arrive
after
the
pod
termination
begins
why
it
takes
a
while
to
update
all
cubed
proxies
and
all
load
balancers,
sometimes
even
one
minute,
if
your
application
dies
before
all
queue
proxies
until
all
balancers
are
updated,
I
mean
your
replica
dies
before
all
queue
proxies
and
twelve
others
are
updated.
A
Some
requests
may
up
end
up
in
the
void,
causing
errors
on
the
client
side.
Also,
neroli
cos
should
not
receive
requests
before
they
are
ready
for
that.
To
ensure
that
please
PLEASE
setup,
readiness
group
and
like
this
prop
by
the
way,
it's
a
good
practice,
even
without
result
about
autoscaler
but
is
particularly
important
when
your
pots
are
constantly
starting
and
stopping
also,
please
keep
your
metrics
server
healthy.
It's
the
source
of
CPU
utilization,
metrics
and
without
it
HP
a
on
CPU
will
not
work.
Last
but
not
least,
please
enable
cluster
autoscaler
while
adding
new
replicas.
A
What
types
of
savings
you
can
expect
from
using
horizontal
portal
to
scalar
simplifying
a
bit
what's
under
HP
L
will
request
one
divided
by
the
utilization
target,
more
resources
that
is
absolutely
needed
to
handle
traffic.
So
if
you
set
your
target
utilization
to
65%
earpods
will
be
over
provisioned
by
50%
without
HP
a
you
will
always
use
the
same
maximum
amount
of
resources,
most
likely
over-provisioned
way
more
than
50%.
The
second
robot
from
our
happy
auto-scaling
family
is
vertical.
A
Without
the
scalar
vertical
quad
autoscaler
monitors
the
real
CPU
and
memory
usage,
as
well
as
out
of
my
more
events
to
estimate
what
should
be
the
pod
size
in
terms
of
requested
CPU
and
memory.
What
request
is
used
by
the
scheduler
to
decide
where
to
put
the
body
only
machine
that
has
enough
free
resources
can
has
de
port?
What
request
also
defines
how
much
resources
will
be
guaranteed
to
the
application?
If
it's
too
small,
then
the
application
may
be
trotted
down
or
throw
some
out
of
memory
exceptions.
A
If
it's
too
big,
then
resources
are
obviously
wasted.
So
it's
important
to
set
all
requests
right.
So
what
a
vpat
does?
Let's
take
a
look
at
the
example
here
we
have
a
palette
that
uses
95%
of
the
requested
capacity
for
a
significant
period
of
time.
It
is
definitely
not
a
healthy
situation
and
in
this
case,
vertical
pot
autoscaler
will
recommend
increasing
the
pot
size
so
that
the
same
load
consume
and
consumes
only
let's
say
75%
of
the
capacity
not
95
in
the
similar
fashion.
A
If
the
load
on
the
pot
is
low
for
an
extended
period
of
time,
BPA
will
recommend
to
decrease
pot
size
to
free
some
space
and
allow
better
utilization
of
your
machines
vertical
path.
Autoscaler
can
work
in
three
modes
in
first
it
only
provides
recommendations
but
doesn't
change
anything.
The
user
is
responsible
for
setting
this
pot
request
manually
in
the
second,
it
only
said
for
the
request
on
new
pots.
A
It
doesn't
change
the
existing
pots,
even
if
they
have
suboptimal
a
request
and
in
the
last
mode,
auto
VPI
kills
existing
parts
and
recreate
them
with
updated
requests.
If
they
have
this
suboptimal
requests
present,
you
can
use
VPA
for
both
stateless
and
stifled
workloads,
especially
if
they
cannot
be
handled
by
HP.
Obviously,
VP
is
particularly
useful
when
you
have
no
idea
how
to
set
what
request
right
and
outer
mode
is
very
handy
when
your
application
can
be
restarted
and
you
gained
enough
confidence
with
VP
recommendations
when
running
it
in
recommendations
on
remote,
vertical
path.
A
Autoscaler
is
not
a
part
of
core
kubernetes.
You
either
need
to
install
it
as
an
additional
component
or
enable
it
on
your
kubernetes
managed
solutions
like
GK
with
the
appropriate
cloud
provider
specific
commands,
then
you
create
a
VPN
objecting
to
your
application
in
a
similar
fashion,
as
in
HP
a.
A
However,
there
is
no
dedicated,
keep
CTL
command
yet,
ok,
now
the
list
of
best
practices
for
VPA,
as
mentioned
earlier
start
your
adventure
with
VP
a
in
recommendation
and
in
mode
give
it
away
like
a
day
or
more
convince
yourself
that
the
recommendations
are
good
and
then
consider
switching
it
to
auto.
When
running
in
auto
mode
set
your
pot
disruptions
but
budgets,
it
will
allow
BPA
to
know
how
much
pods
can
be
updated
and
killed.
At
the
same
time.
A
Actually,
you
should
set
for
disruption
budgets
in
many
other
situations
of
leaf
wisdom
when
configuring
VP
a
set
minimum
and
maximum
container
size
in
VP
object
just
to
be
on
the
safe
side
in
outage
life
situation,
for
example,
when
the
traffic
is
not
coming
for
you
to
your
application
for
hours.
Maybe
even
this
severe
outage,
we
might
reduce
pot
size
significantly,
and
then
you
will
have
a
very
unpleasant
surprise
when
the
traffic
suddenly
is
back,
vpf
looks
for
a
longer
time
horizon
and
doesn't
immediately
have
adjust
the
recommendations.
A
Doesn't
update
deployment
specification,
it
only
update
spot
requests
on
the
newly
created
pots
in
admission
control
change,
so
a
good
practice
is
to
put
reasonable
pot
requests
taken
from
our
example
from
VP
recommendations
in
the
deployment
itself.
Just
in
case,
for
example,
someone
turned
off
VP
acted
accidentally,
VP
a
doesn't
like
huge,
abrupt
changes.
A
For
example,
if
you
have
30
pots
put
replicas
right
now,
please
don't
change
it
to
five
in
a
one
step,
but
do
it
gradually
so
that
VP
a
can
adjust
VP,
restores
history,
a
very
significant
change
in
your
application,
like
completely
new
version
completely
new
behavior,
may
require
a
new
VP
a
and
to
do
it
properly.
You
should
create
a
new
deployment
with
a
slightly
different
label
set
because
VP,
a
touching
spot
usage
based
on
labels
that
they
have
and
the
period
takes
metrics
from
Martin
metric
server.
A
Can
you
mix
horizontal
and
vertical,
but
also
scalar
on
the
same
workload?
Well,
the
short
answer
is
no.
The
more
detailed
answer
starts
with
execute
cautions
and
it
depends
technically.
You
can
always
use
VP
a
in
recommendation
mode.
It
is
saved,
nothing
has
changed
and
nothing
bad
should
happen
to
you.
However,
in
order
to
get
stable
results,
you
should
either
use
custom
metrics
in
HP
or
absolute
values
for
HP
target
when
scaling
on
CPU,
because
VP
or
college
is
changing.
A
Ok,
few
words
about
potential
savings
with
vp
l.
You
only
request
the
resources
that
are
actually
needed
with
out
of
EPA.
You
use
your
best
gas
or
maybe
some
wintering
for
providing
pot
sizes.
Usually
people
significantly
over
provisions,
sometimes
couple
times
now.
The
third
and
last
robot
cluster
out
a
scalar,
horizontal
and
vertical
pot.
Auto
scalars
are
targeted
at
scaling
user
workloads.
Cluster
autoscaler
scale
is
the
underlying
computing
infrastructure.
It
provides
nodes
for
pods
that
don't
have
a
place
to
run
in
the
cluster.
It
also
compacts
the
underutilized
nodes.
A
A
Here
we
have
four
pots.
Three
pots
are
big.
One
is
small
and
leave
some
free
capacity
on
its
node.
If
a
new
pot
comes,
then
it
may
actually
fit
on
this.
Ferno
and
scheduler
will
place
it
there.
However,
if
all
nodes
are
kind
of
full
and
the
scheduler
has
no
way
of
placing
the
pot
and
you
notice
needed,
and
then
cluster
autoscaler
comes
into
action.
It
talks
to
your
cloud
provider
and
spin-ups,
and
you
note
the
new
node
arrives
and
scheduler
puts
the
appending
pot
on
the
new
empty
node.
A
On
some
other
occasion.
Some
nodes
might
not
be
utilized
to
their
full
potential
like
on
this
picture.
Small
year,
ol
and
green
pods
have
notes
for
themselves.
However,
if
we
move
the
green
pot
to
the
third
node
will
get
a
free
note
that
can
be
safely
deleted,
like
this
reducing
your
monthly
cloud
provider
bill,
and
this
is
exactly
what
cluster
autoscaler
does.
A
It
removes
and
as
new
nodes
to
your
cluster
as
needed
when
to
use
cluster
autoscaler,
and
the
short
answer
is
always
especially
when
you
have
more
than
two
free
nodes
and
your
cluster
were
close
change
in
time.
The
cluster
of
the
scaler
works
with
multiple
cloud
providers.
We
have
support
for
Alibaba
AWS,
either
by
digital
ocean
Google
cloud
OpenStack
and
market
plus
there
are
some
cloud
providers
supported
out
of
the
core
kubernetes
/
autoscaler
repository,
which
we
seek
out
the
scaling
don't
closely
follow
to
enable
a
cluster
autoscaler.
Please
follow
provided
specific
guys.
A
Some
environments,
like
GK,
have
built
in
easy
to
switch
the
turnout,
cluster
autoscaler,
but
many
require
additional
manual
stuff.
So
please
check
the
appropriate
documentation
for
details.
Best
practice
use
the
hosted
version
of
cluster
autoscaler
when
possible
pick
the
version
of
class
autoscaler
that
matches
your
cluster
version.
They
might
be
some
subtle
differences
between
version
of
scheduler,
which
might
result
in
inconsistent
cluster
or
the
scaler
behavior.
If
you
take
old
class
router
scaler
and
put
it
on
new
cluster
and
vice
versa,
and
define
pod
disruption
budget
for
applications.
A
A
Savings
cluster
autoscaler
will
drive
your
cluster
utilization
about
10%
above
scale,
don't
result
which
is
by
default
50%,
so
utilization
will
get
somewhere
around
60
percent
in
terms
of
requested
capacity,
but
rated
as
a
sum
of
all
pot
requests
on
your
node.
If
you
want
to
learn
more
how
to
squeeze
more
performance
from
clusters,
color,
please
come
and
join
us
on,
seek
auto-scaling,
deep
dive
tomorrow
without
clusters.
A
Carry
your
utilization
depends
on
your
own
bin,
packing
skills
and
a
bit
of
luck
unlocked
cluster
on
average,
the
utilization
is
significantly
lower
than
it
could
have
been
with.
If
you
had
cluster
autoscaler
enabled
as
the
stock
is
slowly
getting
to
the
end,
I
would
like
to
give
you
a
little
bit
more
information
about
the
seek
auto-scaling
itself.
A
We
have
meetings
every
Monday,
as
most
of
our
contributors
are
in
Europe.
The
meetings
are
held
at
4
p.m.
European
time,
which
is
unfortunately
7
p.m.
on
the
west
coast,
and
we
have
the
meeting
so
zoom.
The
link
is
is
here,
but
you
can
also
find
it
on
our
little
documentation.
We
have
quite
active
slack
channel,
so
if
the
meeting
time
doesn't
suit,
you
feel
free
to
ask
your
questions,
concerns
or
new
ideas.
A
When
your
your
new
ideas
there
and
most
of
our
staff,
cluster
autoscaler
and
vpa,
assists
in
kubernetes
/
autoscaler
repository
on
github
HP
itself
is
in
the
core
kubernetes
/
kubernetes
repo
and,
as
I
said,
we
have
sequel
to
scaling
deep
dive
on
Wednesday
at
the
1150.
My
colleague
vivek
will
tell
you
more
about
cluster
autoscaler
options
to
debug
it
and
options
to
find
unity.
B
B
I'm,
good,
okay,
so
I'm
you
enter
from
JD
comm.
You
not
recommend
the
mixing
of
the
V
PHP
a
what
in
your
case,
we
do
see.
Indeed,
in
particular,
when
we
run
a
state
for
application
there
right.
We
want
to
do
VP
a
first,
but
if
it
exceeds
the
capacity
of
the
nodes-
and
we
have
to
do
the
HP,
a
so
I
just
wandering
in
a
community
and
any
player
or
you
do
not
see
a
leader,
the
Fortius,
a
big
thing
of
the
HTP
of
api,
even
the
CA,
and
I
find
that
the
integration.
A
Yes,
that's
a
no
problem
so
so
far
we
have
been
working
on
graduating
vp
itself.
It
has
been
mark
GI
this
summer,
/
autumn,
so
the
next
step
will
be
to
making
sure
that
all
the
environment
works
together.
Right
now
we
so
far
we
have
been
focusing
more
on
making
sure
that
individual
building
blocks
are
perfect.
So
we
are
aware
of
the
problems
working
on
it.
Hopefully,
we'll
have
some
good
solution.
C
Nice
talk
question
about:
could
you
elaborate
a
little
bit
about
the?
How
does
the
autoscaler
work
in
term
of
deaf
fragmentation
assuming,
for
example,
in
my
cluster,
I
have
large
pod
that
consumed
a
large
portion
of
the
node
mix
with
really
really
small
pods?
How,
because
do
you
understand
a
little
bit
my
question.
C
D
A
D
D
A
E
Thank
you,
hi
I'm,
getting
from
IBM
I
have
two
questions
for
you,
one
for
the
cluster
autoscaler
you
mentioned.
It
doesn't
monitor
foreign
metrics
on
the
CPU
or
memory
it
notices
say
pending
pods
and
you
know,
does
the
scale
of
operation.
What
are
some
of
the
ways
or
approaches
you
can
suggest
for
having
the
autoscaler
trigger
a
scale-up
operation
based
on
some
sort
of
threshold
on
the
CPU
memory
when
on
the
cluster
utilization,
rather
than
noticing
the
pending
parts
and
the
the
second
question
around
the
VP,
a
memory.
A
B,
let's
do
it
one
by
one,
because
I
will
forget
what
the
first
question
was
about.
Okay,
sorry,
yeah
I
have
limitations,
so
y+
autoscaler
is
networking
on
metrics,
so
cluster
autoscaler
is
already
complicated
this
and
we
decided
that
we
will
separate
Auto
scalars
work
out
out
of
scalars
work
on
matrix
because
we
can
actually
observe
the
matrix
there.
A
And
if
you
want
to
optimize
your
pod
shape
or
the
number
of
power
pods,
you
should
use
HP
on
or
VP,
respectively,
hey
Dell
class
autoscaler
assumes
that
the
workloads
are
kind
of
already
optimized,
so
they
are
not
overrunning
their
pottery
class
and
you
have
the
correct
number
of
them.
So
each
of
the
node
is
kind
of
healthy.
So
it's
not
that
you
requested
just
a
half
a
node,
and
here
we
are
trying
to
use
twice
of
the
capacity.
A
So
this
is
the
assumption
that
is
in
base
of
Castille
to
scalar,
and
then
we
use
scheduling
simulation
to
decide
whether
you
will
need
a
one
extra
node
to
handle
the
pending
post
that
you
have,
or
maybe
five
extra
notes
and
decide
based
on
various
heuristics.
What
shape
of
the
nodes
should
be,
if
you
have
multiple
auto-scaling
groups
notice
or
whatever
your
provider
has
yeah.
E
Question
on
the
VP
a
you
mentioned:
VP,
it
doesn't
necessarily
act
on
the
you
know
changing
the
matrix,
but
it
provides
the
suggestions
and
actually
any
newer
started
parts
and
in
that
can
be
limitations.
If
we
have
resource
quotas
based
on
name
species
and
deployment
level
and
doesn't
make
any
changes
to
the
deployment
itself,
would
you
suggest
it
is
we
should
you
know,
leverage
VP,
a
to
make
changes
to
the
names,
namespace
level
quota
or
deployment
to
automatically
end-to-end?
You
know
leverage
VP
a
or
would
it
be
not.
A
A
good
idea,
so
VP
a
does
for
changes
before
the
quota
is
checked.
So
if
you
have
quota
the
updated
part
will
pass.
If
you
don't
have
quota,
then
obviously
the
pot
will
be
rejected.
So
quota
is
fully
for
the
respected
and
most
people
set
up
quota
for
in
company
building
reasons
or
to
reducing
the
cost
of
final
development
or
whatever
and
right
now
we
haven't
seen
much
need
for
updating
water
itself
in
VP
a.
E
A
Doing
changes
to
to
the
deployment,
however,
any
change,
the
deployment
trigger
spot
recreation
and
it
doesn't
necessary-
adhere
to
poke
disruption
budget,
so
it
could
have
more
severe
effect
on
your
deployment
that
you
would
wish.
So
at
this
moment
we
have
no
plans
to
update
the
deployments
because
of
body
disruption,
budget
issues
and,
secondly,
deployment
Stork
history.
So
every
single
change
made
to
deployment
is
stored
there.
So
if
vertical
cut
out
to
scale
are
doing
is
doing,
let's
say
10
updates
per
day
based
on
the
changing
patterns.
A
Also
on
your
valuable
history
would
be
completely
overwritten
by
not
so
wild
valuable
VP
activity.
So
at
this
moment
there
is
no
way
to
change
things
in
deployment
without
writing
it
to
the
deployment
history.
And
for
this
and
couple
of
many
of
other
reasons,
we
decided
that
we
will
rather
stick
to
what
our
base
and
ask
users
to
update
the
deployment
by
themselves.
But
if
you
have
strong
case,
please
come
to
seek
out
the
scaling
meeting
on
Monday
and
we
can
discuss
it
further
sure.
A
A
Cluster
autoscaler
will
kill
and
healthy
nodes,
so
we
monitor
the
situation
of
the
nodes
and
if
node
is
unhealthy
and
your
cluster
can
be
scaled
also,
you
set
the
min
and
Max
cluster
size.
Accordingly,
we
will
delete
the
node.
However,
if
you
are
already
at
the
boundary
of
your
cluster
size,
we
will
not
delete
the
unhealthy
node
and
the
node
and
I
hope
you
know.
Deletion
will
happen,
I
believe
like
20
minutes
after
we
spot.
This
is
not
ready
or
something
like
that.
Okay,.
A
So
we
kind
of
assumed
that
CPUs
are
equivalent
in
the
same
fashion
as
kubernetes
system.
So
when
you
request
some
capacity
input
request,
you
just
specify
one
CPU,
you
don't
specify
it
I,
don't
know
in
meets
teraflops
or
whatever
you
just
say
one
one
CPU
and
you
hope
for
the
best.
So
unfortunately
we
don't
have
any
extra
tolling,
except
like
what
request
or
maybe
label
SEC
selector
in
your
pots
to
ask
for
particular
performance
of
of
the
machine.
G
A
H
A
Unfortunately,
that's
how
deployment
works
and
if
deployment
changes
the
strategy
for
scale
down,
we
would
get
it
automatically
a
plus.
So
we
work
with
any
open
an
object
that
has
scale
sub
resource.
So
the
strategy
is
not
only
limited
to
two
deployment
deployment
itself.
Does
it
allow
you
to
kill
a
particular
pod,
so
we
cannot
do
it
from
the
HP
itself,
so
our
hands
are
a
little
bit
tight
and
random
port
is
killed.
Sorry
for
that,
in.
H
A
A
We
have
various
strategies
there
deciding
which
node
to
pick.
The
first
thing
is
that
we
will
pick
nodes
that
are
less
utilized,
so
we
have
the
threshold
and
nodes
above
a
particular
address.
What
will
not
be
cut
so,
for
example,
by
default,
because
it
knows
that
have
at
least
50%
of
their
capacity
used
as
well
utilized,
and
we
don't
compact
them,
you
can
change
it.
If
you
want
to
learn
how
to
change
it,
please
come
on
Wednesday
to
the
talk.
A
Otherwise
we
just
some
notes
that
provides
that
allows
us
to
D
delete
the
pods
samples
may
have
pod
disruption
budget,
some
postman,
some
nodes
may
be
holding
like
important
system
components,
and
even
if
they
were
like
the
best
candidates,
there
cannot
be
killed,
because
there
is
a
metric
server
running
there
and
killing
metric
server
could
could
cause
an
outage
or
there
is
a
DNS
server
or
something
like
that.
So
the
actual
strategy,
there
is
a
little
bit
more
complex.
Thank
you,
I'm
afraid
I
have
run
out
of
time.