►
From YouTube: SIG-Autoscaling: Introduction + HPA/VPA Updates - Joe Burnett & Marcin Wielgus, Google
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
SIG-Autoscaling: Introduction + HPA/VPA Updates - Joe Burnett & Marcin Wielgus, Google
During this talk we will give a detailed overview of autoscaling features in Kubernetes, covering both horizontal, vertical as well as cluster autoscalers. You will learn how to automatically adjust your Kubernetes cluster and pods to match your current capacity needs, which components should be used when and how to configure them properly to get best efficiency and cost savings. We will also discuss upcoming features like the new HPA v2 stable API and support for alternative recommenders in VPA.
A
A
Give
you
an
example
of
what
kubernetes
auto
scaling
does,
so
you
can
understand
some
of
the
terminology
and
how
to
use
it,
and
I'm
going
to
talk
a
few
minutes
about
some
upcoming
features
and
I'll
save
some
time
at
the
end
for
questions
so
who
are
we
sig?
Auto
scaling
has
the
scope
of
horizontal
and
vertical
polynomial
scaling.
A
This
is
changing
the
size
of
pods
vertically
or
making
more
or
fewer
of
them
horizontally.
Cluster
proportional
system
component,
auto
scaling,
is
just
a
very
simple,
auto
scaler
that
adjusts
the
number
of
pods
in
a
deployment
based
on
the
size
of
the
cluster,
so,
for
example,
cube
dns
uses
this
also
stig.
Auto
scaling
is
responsible
for
cluster
autoscaler,
which
actually
sizes
up
and
down
the
cluster
itself.
A
So
I'll
talk
a
little
bit
about
how
those
interact
with
each
other.
In
a
few
minutes,
the
chairs
of
segato
scaling
are
guy
templeton,
who
works
at
sky
scanner
and
marcin
vigulus,
who
works
at
google
and
here's
a
link
here
to
the
community
page,
which
should
be
linkable
from
the
pdf
uploaded.
With
this
presentation,
this
will
tell
you
all
about
the
sig
meetings
and
all
the
information
about
the
this
special
interest
group.
A
There
is
two
dimensions
here
to
consider
horizontal
and
vertical,
and
they
are
separated
by
two
layers:
pods
and
nodes,
or
workload
and
cluster
of
scheme,
so
hpa
scales
in
and
out
I
mentioned
already,
it
makes
more
or
fewer
pods,
based
on
metrics
that
you
predefine,
you
can
scale
on
more
than
one
metric.
If
you
want,
for
example,
cpu
utilization,
maybe
some
pub
sub
queue
length
or
something
vertical
pod.
A
Auto
scaling
in
cluster
auto
scaler
is
more
about
selecting
the
right,
node
pool,
so
it
sees
you
have
a
pod.
Where
do
I
want
to
put
that
it
knows
not
to
scale
out
a
small
vm
size?
It
needs
to
scale
out
one.
That's
big
enough
for
the
pot,
so
there's
a
aspect
of
vertical
auto
scaling
in
cluster
auto
scaler.
A
So
I'm
going
to
walk
you
through
kind
of
a
quick
example
cluster.
What
it
might
look
like
when
you
have
these
auto
scaling
systems
engaged
so
there's
two
workloads
here.
One
of
them
is
blue
workload,
which
is
configured
to
scale
horizontally
and
there's
a
purple
workload
which
is
also
configured
to
scale
horizontally
and
vertically,
maybe
vertically,
on
memory
horizontally
on
cpu
or
something
like
that
side.
A
A
So
it
figures
out
how
many
more
pods
you
would
need
it
in
order
to
bring
that
back
down
to
your
target,
assuming
that
all
the
pods
pretty
much
do
the
same
thing,
and
so
it's
it
turns
around
and
increases
the
desired
replicas.
The
way
that
it
actuates.
This
is
by
updating
the
scale
sub-resource
of
the
target,
so
you
can
point
hpa
actually
to
anything
that
implements
the
scale
sub-resource,
which
includes,
of
course,
deployments
and
replica
sets,
but
you
can
even
point
it
at
custom
resource
definitions,
crds.
A
A
A
They
get
scheduled
under
this
node
that
has
capacity
right,
pretty
pretty
normal,
so
suppose
that
that
the
purple
service,
I
also
get
some
traffic
and
it
scales
up
too,
as
you
can
see,
there's
not
enough
room
for
that
purple
pod
on
that
third
node
there,
so
it
actually
gets
created
unschedulable-
and
this
is
this
first
signal
that
clustering
autoscaler
responds
to
cluster
autoscaler-
is
going
to
see
this
unscheduleable
pod
and
it's
actually
going
to
create
a
new
node.
To
put
it
there,
so
you
can
see
it's
just
got
this
flat.
A
A
It
spends
its
time
looking
at
the
usage
over
time
and
building
a
histogram
histogram
in
it,
and
it
picks
a
conservative
place
of
what
it
thinks
you
probably
need
based
on
like
historical
usage,
and
it
vpn
has
decided
that
the
purple
server
is
way
over
provisioned
on
memory,
so
it
is
recommending
a
much
smaller
size,
so
the
vpa
is
actually
kind
of
divided
into
three
different
systems.
One
is
the
recommender
which
is
just
responsible
for
this
observation
and
recording
its
recommendation.
A
Then
there's
an
updater
system
and
the
updater
is
actually
an
active
process
that
just
looks
for
pods
that
are
not
matching
their
recommended
resource
consumption
and
the
update
is
responsible
for
going
through
and
deleting
those
pots.
So
the
one
of
the
most
important
aspects
of
the
vpa
updater
is:
it
doesn't
delete
them
all
at
once.
A
It's
very
careful
to
delete
them
and
try
to
respect
some
reasonable
limits,
so
it
deletes
a
pod,
not
all
of
them,
just
one
of
them,
with
the
expectation
that
it
will
get
recreated,
which
is
how
kubernetes
works
and
when
it
gets
recreated
there's
another
system.
The
third
system
is
an
admission
controller
that
actually
rewrites
the
pod
resource
requests
for
that
purple
pod
to
make
it
smaller,
and
so
it
gets
scheduled
at
the
correct
size,
and
that
is
basically
how
vpa
actuation
works.
A
So
the
same
thing's
going
to
happen
to
the
other
one,
the
updater
is
just
going
to
kind
of
keep
moving
along.
It
gets
deleted
boom
rescheduled.
It
actually
fits
really
nicely
inside
this
second
node
here.
So
you
notice.
We
ended
up
with
the
unused
node,
which
is
which
is
great
actually,
because
the
cluster
auto
scaler
will
then
it
periodically
scans.
A
The
cluster
it'll
see
that
this
node
is
empty
and
it'll
be
like
delete
it,
and
then
our
cluster
scales
in
all
right
suppose
that
now
the
day's
over
traffic
is
going
to
go
down.
Blue
service
gets
less
traffic
hpa
notices
that
this
target
utilization
is
lower
than
the
target,
so
we're
not
using
as
much
cpu
as
we
would
like
to
on
average.
So
it
will
again
figure
out
how
many
pods
it's
going
to
need
to
hit
the
target
and
adjust
accordingly,
it
scales
down
by
three
pods
and
then
the
underlying
deployment.
A
A
So
cluster,
auto
scaler
is
actually
going
to
kick
in
after
a
while
and
do
some
consolidation
defragging
and
it's
going
to
delete
the
pod.
That's
it's
first
thing
it
does.
Is
it
actually
taints
this
node
that
it
wants
to
get
rid
of
to
make
sure
nothing
shows
up
and
nothing
new
shows
up
there
and
then
it
it
evicts.
The
pod
it
deletes
the
pod
pod
gets,
goes
away
and
comes
back
as
usual.
It
gets
rescheduled
where
it
can,
which
is
on
that
third
node.
A
So
now
again
we
have
this
node
that
is
empty
and
cluster
autoscaler
can
delete
it,
and
then
we
get
this
final
state.
So
you
can
kind
of
see
how
both
of
these
systems
scale
in
and
out,
I
didn't
show
you
multiple
node
pools,
but
cluster,
auto
scaler
is
capable
of
selecting
from
different
sizes
of
nodes,
and
you
can
kind
of
see
how
how
they
interact
with
each
other
cluster.
Auto
scaler
only
responds
to
unscheduled
pots.
A
A
So
that's
essentially
kubernetes
auto
scaling
in
a
nutshell.
Now,
if
there
was
a
cluster
proportional,
auto
scaler
here,
it
would
be
creating
more
pods
when
there
are
more
nodes
and
fewer
pods
when
there
are
fewer
nodes,
just
very,
very,
very
simple,
algorithm.
It's
used
for
system
components
because
it
is
so
simple.
It's
it's!
You
know,
sort
of
a
baseline
okay.
So
let
me
take
a
few
minutes
and
talk
a
little
bit
about
some
upcoming
features,
so
hpa
has
actually
been
around
for
a
long
time.
A
It's
the
first
version
of
hba
hba
v1,
auto
scaled
only
on
cpu
utilization,
which
is
what
most
people
use.
It's
the
easiest
thing
to
use.
It
changes
quickly.
It's
compressible,
you
know
already
what
the
what
your,
how
much
you
have.
So
it's
easy
to
configure
right.
You
could
just
give
it
a
percentage
or
a
utilization
target,
and
you
already
know
what
the
capacity
is,
because
you
know
what
your
resource
request
is.
A
A
That
was
created
in
order
to
provide
multiple,
metrics
and
custom
metrics.
So
the
structure
of
the
hpa
changed
a
little
bit
inside
spec
in
the
hpa
object.
There's
a
metrics
field
and
the
metrics
is
a
list
and
it's
a
list
of
all
the
metrics
you
want
to
auto
scale
on
and
the
algorithm
will
actually,
the
hpa
algorithm
will
compute
a
recommendation
for
each
one
of
those
metrics
completely
independently.
A
Okay,
say:
okay,
so
cpu
says:
probably
we
need
seven.
Your
custom
metric
says
we
need
three
and
your
other
custom
metric
or
memory
or
whatever
says
you
probably
need
you
know
10.,
and
then
it
will
select
the
maximum
from
those
it's
sort
of
optimized
for
safety.
You
know
to
give
you
enough
capacity
and
it
selects
the
maximum,
which
would
be
that
that
10
recommendation
and
then
it
goes
into
a
phase
where
it
actually
applies
some
limitations.
A
So
it
limits
you
to
a
min
and
a
max
right.
You
can
configure
min
and
max
in
the
hpa,
and
you
can
also
configure
now
how
long
you
want
to
wait
to
scale
up
or
scale
down
and
also
what
rate
limit
you
want
to
apply.
So
let
me
give
you
an
example:
hpa
v1
has
an
algorithm
called
scale
down
stabilization
and
you
want
hpa
to
be
responsive
right.
Traffic
comes
in
cpu
goes
up.
You
really
want
to
give
it
capacity
as
quickly
as
possible.
A
It's
sort
of
optimized
for
services,
not
necessarily
for
patch
and
I'll,
get
to
that
in
just
a
minute.
So
you
want
to
be
able
to
scale
up
right
away.
So
you
want
to
react
quickly.
So
you
see
that
you
see
the
the
recommendation
go
up.
You
go
up
immediately,
but
you
also
don't
want
to
flap
because
the
metrics
they
kind
of
they
kind
of
go
up
and
down
right.
You
don't
want
to
keep
creating
and
deleting
pods,
because
it
creates
a
lot
of
churn.
A
A
So
this
is
really
actually
a
really
great
algorithm
for
most
use
cases.
But
again
it's
not
sufficient
for
all.
So
in
hpa,
v2,
there's
a
new
feature
added
called
behavior,
so
also
in
spec,
there's
a
behavior
field
and
the
behavior
you
can
configure
symmetrically
scale
up
and
scale
it
down
configurations
that
includes
the
stabilization
period.
The
default,
of
course,
is
scaled
down
five
minutes.
A
A
A
A
This
was
sort
of
the
canonical
use
case
used
for
that
cap,
and
so
maybe
your
pod
two
pods
can
handle
all
hundred
of
those
messages,
even
though
you
like
are
wanting
if
you're
sort
of
at
a
at
a
higher
rate,
maybe
you
you
know
that
they
need
to
be
having
fewer
per
pod,
so
scale
up.
Stabilization
is,
is
a
good
thing
to
be
able
to
configure
and
scale
down
rate.
A
Also,
I
mean
scale
up
rate
is
kind
of
obvious
because
you
don't
want
to
like
overreact,
but
also
scale
down
rate
limits
are
really
useful,
just
to
make
sure
that
you
come
down
off
of
your
scaled
down
or
the.
If
the
traffic
drops,
you
want
to
come
down
off
of
that
sort
of
gradually,
maybe
you
want
to
try
to
smooth
out
the
the
spikes
or
maybe
you
want
to
make
sure
your
capacity
is
not
going
to
be
needed
again
or
maybe
you
just
simply
have
limitations
on
how
fast
you
can
get
rid
of
pods.
A
Maybe
you
have
a
database
connection,
you
don't
want
to
like
overwhelm
it
with
something
I
don't
know
whatever.
So
anyway,
hpa
v2,
it's
been
around
for
a
long
time
in
beta
and
we
need
to
graduate
it
to
stable.
So
we've
been
working
on
this
for
a
little
while,
mostly
just
through
just
community
contributions.
A
bunch
of
people
have
chipped
in
to
create
the
cap
to
create
end-to-end
tests
for
the
new
features
to
fix
a
few
bugs
and
to
create
the
new
api
which
is
really
exciting.
A
It's
all
it's
it's
getting
along
there
and
I
think
it's
like
almost
ready
to
commit.
There's
just
a
few
more
comments
left
on
it
and
I
think
that'll
be
the
first
v2
api
for
kubernetes,
which
is
cool.
As
far
as
I
know,
correct
me,
if
I'm
wrong
yeah,
so
hpa
v2
viewed,
one
will
stick
around
for
a
while.
I
mean
like
it's
it's
ga
v2
is
gonna,
be
there
with
the
next
release
of
kubernetes
and
then
we're
going
to
start
deprecating,
the
v
2
beta
versions.
A
A
So
if
you're
scaling
up
it's
going
to
select
the
max
of
four
or
two
times,
but
if
you're
scaling
down
it's
actually
going
to
choose
max,
would
choose
the
smallest
number,
because
it's
actually
the
max
change
or
the
min
change.
So
we've
changed
the
value
of
the
enumeration,
because
early
users
of
this
feature
were
confused
by
it,
but
that,
I
think,
is
the
most
significant
change.
So
it's
mostly
the
same
as
the
is
the
beta
api
and
that
should
be
coming
soon.
A
A
Same
thing
vpa,
the
vpa
recommended
will
handle
when
this
field
is
not
present.
But
if
you
want
to
add
a
custom
vpa
recommender,
you
create
a
controller
that
handles
those.
It
just
ignores
anything
that
doesn't
have
its
name
on
it,
and
then
you
can
create
a
vpa
object
with
that
discriminator
and
target
that
recommender
and
then
the
rest
of
the
pipeline
will
be
the
same.
A
A
A
We
have
a
slack
channel,
sig,
auto
scaling
where
you
could
just
drop
in
and
ask
general
questions.
How
do
I
use
this?
Why
is
this
thing
doing
that?
I
have
an
idea.
What
do
you
think
we're
really
quite
friendly
people
are
asking
questions
all
the
time
on
there
and
there's
always
somebody
that
jumps
in
and
answers
questions.
A
So
it's
a
great
place
to
come
and
just
get
plugged
in
there's
an
another
slack
channel,
sig,
auto
scaling
api
was
created
partly
to
coordinate
the
hpa
v2
changes
because
there's
just
a
lot
of
different
contributors,
and
I
wanted
to
have
kind
of
a
long
running
thread
for
it.
So
api
related,
auto
scaling
stuff.
The
topic
is
currently
v2.
Ga
or
stable
hba.
A
A
So
if
you,
if
you
want
to
talk
about
something
at
the
meeting,
just
go
to
the
google
doc
there
linked
under
the
agenda
and
just
put
your
name
there
and
say
hey
here,
here's
something
I
want
to
talk
to
and
then
usually
in
the
sig
meeting.
We
just
go
in
order
from
top
to
bottom
and
there's
usually
plenty
of
time
to
ask
additional
questions
too.
A
So
come
see
us
we're
friendly,
we're
interested
in
new
ideas
and
we're
interested
to
see
how
you're,
using
these
new
features
and
yeah
it's
a
it's
a
good
community.
So
that
is
it
for
my
presentation.
I
hope
you
enjoyed
a
quick
overview
of
auto
scaling
and
some
upcoming
features
and
I
hope
to
see
you
online
bye.