►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Introduction to Autoscaling - Marcin Wielgus & Beata Lach, 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/ZeyE
B
A
Of
grief,
sadness
and
sorrow,
many
people
lost
their
loved
ones.
The
economy
all
over
the
world
went
to
a
standstill.
Lots
of
business
had
to
close.
Almost
everyone
had
to
adapt
to
new
sanitary
requirements
in
I.t.
We
are
privileged.
We
could
move
from
offices
to
our
homes
and
pretend
it
was
business.
As
usual,
computers
were
easy
to
move.
Video
conferencing
had
been
there
for
ages,
so
is
it
business
as
usual?
A
A
A
A
A
A
Let's
start
the
first
robot
I'm
going
to
talk
about
is
called
horizontal
put,
auto
scaler
horizontal
port
autoscaler
is
based
on
metrics
that
express
the
load
that
the
application
gets.
It
can
be
either
real
cpu
usage
or
something
more
custom,
like
the
number
of
queries
per
second
or
other
gauge
lag
value
provided
by
the
user.
A
B
A
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.
For
example,
if
a
pot
requested
one
cpu
and
is
currently
using
only
half
of
cpu,
then
the
utilization
is
50.
A
A
A
Cpu
usage
is
available
out
of
the
box.
Custom
metrics
require
a
little
bit
more
work,
while
setting
up
hpa
is
crucial
to
set
the
target
value
or
more
generally,
target
utilization
and
write.
One
minus
utilization
is
your
spike
capacity,
and
the
driver
for
scale
ups
too
small
buffer
may
prevent
scale
ups
and
may
overload
the
application
too.
Big
obviously
causes
waste.
A
What
are
the
other
best?
Practices
for
hpa
applications
under
hp
should
correctly
handle
seek
terms.
That
means
that,
after
receiving
the
signal,
the
application
should
not
stop,
but
finish
all
of
the
requests
that
are
in
flight
and
still
listen
for
the
incoming
connections
that
may
arrive
after
the
bot
termination
begins.
A
A
A
A
Please
keep
your
metric
server
healthy.
It
is
the
source
of
cpu
utilization
metrics
and
without
it,
hpa
will
not
work.
Last
but
not
least,
please
enable
cluster
auto
scaler
while
adding
new
replicas.
You
may
end
up
without
any
free
capacity
in
the
cluster,
and
you
need
something
to
fix
it
up.
Also,
when
the
number
of
your
pods
decrease
something
needs
to
decrease
the
size
of
your
cluster,
as
I
said
before,
hpa
adjusts
the
number
of
pots
to
keep
the
desired
utilization.
A
B
B
But
why
are
pod
requests
exactly
like
boxes
for
cats?
They
should
neither
be
too
small
nor
too
big
fun
requests
are
what
kubernetes
scheduler
uses
to
decide
where
to
put
your
pots
based
on
how
much
free
space
a
given
machine
has.
The
request
is
also
what
kubernetes
guarantees
to
provide
to
your
application
to
run.
B
This
means
that
if
the
requests
are
too
low,
the
scheduler
may
put
your
pod
on
a
note
that
doesn't
have
enough
resources
to
provide
for
your
pod.
This
in
turn,
can
result
in
out-of-memory
errors,
workloads,
evicted
due
to
memory
pressure
or
your
workloads
underperforming,
due
to
not
enough
cpu
available
note
that,
from
the
point
of
view
of
your
customers,
this
is
already
an
outage.
B
B
So,
let's
take
a
look
at
the
simple
example:
we
have
a
pod.
It
uses
95
of
the
requested
capacity
for
an
extended
period
of
time.
It
might
also
occasionally
burst
and
use
more
than
hundred
percent.
What
vpa
will
do
is
it
will
recommend
increasing
pot
size
so
that
only
let's
say
75
percent
of
capacity
is
used.
B
B
Vpa
works
in
three
modes
in
the
first
one.
It
only
provides
recommendations,
but
it
doesn't
change
actual
resource
requests.
You
may
then
choose
to
apply
the
recommended
settings
manually
in
the
second
one.
It
only
sets
requests
for
parts
that
are
newly
created.
It
doesn't
change
pods
that
are
already
running
and
the
last
one
third
one
automatic
mode
allows
vpa
to
evict
an
existing
pod
if
it
has
sub-optimal
requests
and
recreate
it
with
recommended
ones.
B
Vpa
is
best
suited
to
figure
out
usage
patterns
over
longer
periods
of
time.
It's
not
tailored
to
responding
to
sudden
changes
of
usage
for
this
hpa
is
definitely
the
better
tool
you
can
use
vpa
for
both
stateful
and
stateless
workloads,
especially
if
they
are
not
a
good
fit
for
hba
and
with
current
implementation.
B
Only
mode
vpa
is
not
a
part
of
kubernetes,
so
you
either
need
to
install
it
as
an
additional
component
or
enable
it
in
your
kubernetes
managed
solution
like,
for
example,
gke,
and
then
you
do
it
with
the
appropriate
cloud
provider
specific
commands
after
you
do
that
you
still
have
to
create
a
vpa
object
pointing
to
the
application
that
you
want
to
scale.
This
is
similar
to
what
we've
seen
with
hpa.
B
However,
here
we
have
no
dedicated
cube
ctl
command,
but
you
can
check
out
the
examples
of
how
to
configure
this
in
our
auto
scaler
repository
now
some
tips
on
what
to
watch
out
for
when
using
vpa.
As
I
mentioned
earlier,
you
should
start
your
advantage
with
vpa
in
recommendation.
Only
mode
give
it
a
couple
days
convince
yourself
that
the
recommendations
that
you're
seeing
are
according
to
your
expectations
and
then
consider
switching
it
to
auto
mode.
B
You
should
always
do
this,
regardless
of
using
vp
or
not,
but
it
is
especially
important
if
you're
using
vpa
in
auto
mode
as
a
safeguard,
you
should
always
set
minimum
and
maximum
container
sizes
in
the
vpa
object,
and
also
keep
in
mind
that
vpe
doesn't
update
the
deployment
spec.
It
only
updates
poll
requests
for
pods
as
they
are
created.
So
a
good
practice
is
to
take
a
reasonable
pod
request,
like
the
one
taken
from
vpa
recommendation
and
put
it
in
the
deployment
itself.
B
B
That
means
that
very
significant
changes
should
either
be
done
gradually,
or
they
may
even
require
an
epa
object
and
to
do
this
properly,
you
should
also
create
a
new
deployment
with
a
different
set
of
labels
to
function
correctly.
Vpa
takes
its
metrics
from
a
metrics
provider
by
default
in
kubernetes.
This
will
be
metric
server.
B
B
Technically,
you
can
always
use
vpa
in
the
recommendation
only
mode,
it's
safe.
It
doesn't
change
anything
on
your
workloads,
so
nothing
bad
will
happen
to
you.
However,
in
order
to
have
confidence
in
the
results
you
get,
you
should
not
configure
hp
and
cpu
utilization
and
use
vpa.
At
the
same
time,
the
options
that
you
do
have
is
to
either
use
custom
metrics
for
hpa,
like
requests
per
second
or
use
absolute
values
for
hpa
targets.
B
B
B
B
It
provides
nodes
for
pods
that
don't
have
place
to
run
in
the
cluster
and
it
also
compacts,
underutilized
or
empty
nodes.
It's
important
to
note
that
it
is
based
on
simulation
of
scheduler
decisions
and
declared
spot
requests.
It
doesn't
use
any
actual
dynamic
metrics
like
usage
or
observed
requests
per.
Second,
we'll
take
a
look
at
how
it
works
in
practice.
B
B
B
Cluster
autoscaler
works
with
multiple
cloud
providers.
You
can
see
the
list
on
the
slide
here.
In
addition
to
that,
there
are
some
cloud
providers
supported
out
of
the
core
repository
in
which
we
ask
sig,
auto
scaling
to
not
closely
follow
now
to
enable
cluster
of
the
scalar
in
your
cluster.
You
should
follow
cloud
provider
specific
guides,
some
environments
like
gke.
They
have
a
built-in
easy
to
use,
switch
to
turn
on
cluster
to
scaler
in
others.
B
B
There
may
be
some
subtle
differences
between
versions
of
scheduler
and
cluster
autoscaler,
and
this
may
result
in
some
very
subtle
and
very
hard
to
debug
issues
and,
lastly,
again
define
pod
disruption
budgets
for
your
applications.
We
mentioned
when
discussing
vpa
that
you
should
always
do
this,
but
for
cluster
to
scaler.
It
will
let
you
control
how
often
it
can
restart
your
pods
when
it
wants
to
scale
down
a
node.
B
So
generally
you
will
see
somewhere
around
60
utilization
in
the
cluster,
if
you're
not
using
cluster
2
scalar.
Your
utilization
depends
mostly
on
your
own,
pin
packing
skills
and
on
large
clusters
that
is
actually
really
difficult
and
would
be
seeing
seeing
there
out
in
the
wild
on
average.
It
would
be
significantly
lower
than
it
would
have
been
if
you
had
clustered
scalar
enabled.
B
B
B
New
stuff,
like
cluster,
auto,
scaler
and
vpa,
sits
in
the
kubernetes
auto
scaler
repository
hba
is
the
oldest
outer
scaler
robot,
and
it
sits
in
the
car,
kubernetes
kubernetes
repo,
and
at
this
virtual
kibcon
edition,
we
have
a
couple
more
autoscaling
talks
that
we
encourage
you
to
check
out.
Just
to
mention
two
of
them.