►
From YouTube: SIG Autoscaling Updates and Feature Highlights
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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 Updates and Feature Highlights - Michael McCune, Red Hat; Joachim Bartosik, Google; Guy Templeton, Skyscanner; David Morrison, Airbnb
Come hear about the latest updates and features from the Kubernetes Autoscaling community. In this talk, we will cover the current status and future plans for the SIG owned projects (Cluster Autoscaler, Horizontal Pod Autoscaler, Vertical Pod Autoscaler), the timeline for deprecating the autoscaling v2beta2 API, improvements to the Vertical Pod Autoscaler API, and a highlight of gRPC extensions to the Cluster Autoscaler. If you are curious about autoscaling in Kubernetes or would like to learn more about how to get involved with this community, come join us!
A
A
Why
don't,
I
guess
we'll
go
through
some
introductions
to
begin
with,
my
name
is
michael
mccune.
I
work
for
red
hat,
I'm
an
engineer,
we're
all
engineers
who
work
in
the
sig
auto
scaling
community.
This
is
joachim
bartosik
from
google,
guy
templeton
from
sky
scanner
and
david
morrison
from
airbnb,
and
so
when,
when
and
if
we
can
get
the
slides
going,
we're
going
to
talk
to
you
about
some
changes
that
have
been
happening
on
the
horizontal
pod,
auto
scaler
we've
got
an
update
about.
A
A
There
have
been
some
changes
to
the
programmatic
api
interface,
so
if,
if
you're
writing
code
that
uses
the
hpa
as
a
library,
you'll
probably
want
to
look
at
the
release,
notes
on
the
pr
and
on
the
hpa
so
that
you
can
know
there
are
a
couple
functions,
I
think
the
change
name.
That
was
all
it
looked
like
to
me.
But
for
the
most
part
it
should
be
a
seamless
transition
from
v2
beta,
1
or
v2
beta
2
into
the
v2
api.
A
A
And
you
know,
if,
for
all
of
you
who
are
taking
notes
out
there,
if
you're
really
curious
about
this,
you
want
to
go
to
the
kubernetes
kubernetes
repo
and
look
for
pull,
request,
102
534
and
that's
where
the
merge
happened.
You
can
read
the
release,
notes
there.
Now
that's
pretty
much
the
end
of
what
I
had
to
say
and
unfortunately,
for
you
all.
I
only
had
a
couple
slides
with
a
little
bit
of
text
on
them.
A
A
A
B
B
B
B
So
first
thing
that
cluster
auto
scaler
does
is.
It
looks
for
all
of
the
unscheduleable
pods
things
that
can't
be
can't
fit
anywhere
on
the
cluster,
and
then
it
looks
at
all
of
the
different
node
groups
that
it
has
available.
So
a
node
group,
if
you're
using
aws,
for
example,
might
be
an
auto
scaling
group.
B
Just
as
a
reminder,
cluster,
auto
scaler
one
of
the
requirements
is
that
all
of
the
nodes
in
a
node
group
have
to
be
identical
from
an
auto
scaling
perspective,
so
they
all
have
to
have
the
same
amount
of
cpu
same
resources.
If
you're
using
things
like
pod,
topology
spread,
they
often
be
in
the
same
az,
etc.
B
B
So
we're
going
to
be
focusing
today
on
the
best
option
function
here.
So
again,
just
as
a
reminder,
what
are
the
types
of
expanders
that
cluster
autoscaler
has
available?
The
default
is
random.
Does
what
it
says
on
the
tin
picks
a
node
group
at
random
scales
it
up
most
pods.
In
least
waste
are
kind
of
complementary
to
each
other.
Most
pods
tries
to
pick
a
node
group
that
will
schedule
the
most
unschedulable,
pods
least
waste
kind
of
does
the
converse.
B
B
So
the
one
we're
going
to
talk
about
today,
the
one
that's
new
is
the
custom
grpc
expander.
So
let's
talk
a
little
bit
about
why
we
wanted
to
write
a
new
one
of
these
things.
We
were
looking
at
what
is
available
previously
in
clusterautoscaler,
and
none
of
them
quite
did
what
we
wanted
to.
We
wanted
to
be
able
to
sort
of
dynamically
change
things
on
the
fly
and
you
like
you,
can
kind
of
do
that
with
the
priority
one.
You
can
update
the
priority.
B
Config
map
and
it'll
take
that
into
account,
but
we
really
wanted
to
have
more
complicated
logic
here.
So
then
we
talked
a
little
bit
about
well.
What
if
we
just
built
a
new
expander
and
contributed
upstream,
we
really
don't
want
to
be
running
a
fork
of
cluster
autoscaler
we'd
like
to
stay
with
what's
sort
of
available
to
everyone
else,
but
we
couldn't
really
come
up
with
something
that
was
both
going
to
solve
our
business
needs
and
would
also
be
appropriate
to
upstream,
and
so
we
finally
settled
on
this
grpc
expander.
B
The
first
is
that
it
allows
us
to
encode
our
business
specific
scaling
logic,
so
it
allows
us
to
do
things
like
take
into
account
our
aws
contract,
which
might
change
as
we
renegotiate
things,
we're
looking
at
trying
to
run
more
spot
instances
and
spot
you
know,
depends
a
lot
on
the
time
of
day.
It
depends
on.
The
price
depends
on
what
else
is
running
in
our
cluster,
and
so
it's
kind
of
hard
to
figure
out
how
to
generalize
that
and
then.
B
The
other
thing
that
we
were
concerned
about
is
cluster,
auto
scaler
releases
roughly
in
lockstep
with
mainline
kubernetes,
and
we
needed
some
more
flexibility.
So
if
you
know
our
traffic
patterns
change
or
if
our
contract
changes
or
like
anything
changes,
we
wanted
to
have
the
ability
to
up
update
our
scaling
logic,
and
so
what
we
settled
on
is:
let's
build
a
interface
that
allows
us
to
sort
of
encapsulate
all
of
our
business
specific
logic
as
a
separate
service
and
it'll
just
talk
to
cluster
auto
scaler
over
grpc.
B
So
that's
what
we
did.
This
is
the
one
and
only
diagram
in
my
section
of
the
talk,
so
I
hope
you
like
it
on
the
left.
You
can
see.
You've
got
a
node
in
your
cluster
cluster
autoscalers
running
on
it
somewhere
and
what
we
built
is
inside
cluster
autoscaler.
There's
a
grpc
client
that
conforms
to
the
expander
interface.
B
That
service
will
then
take
all
of
the
options
that
cluster,
auto
scaler
did
or
provided
to
it,
and
it
will,
you
know,
do
whatever
business
logic.
You
want,
and
then
it
returns
the
choice
back
to
cluster
auto
scaler,
where
the
grpc
client
will
then
translate
it
back
into
cluster,
auto
scaler
lingo,
and
it
goes
on
from
there.
B
B
B
B
So
you
use
your
standard
boilerplate
to
set
up
your
grpc
server.
You
create
a
new
expander
interface.
You
register
it.
You
start
listing
for
requests
from
cluster
autoscaler
and
then
here
is
an
example
of
what
the
best
options
function
inside
your
custom.
Expander
might
look
like.
This
is
a
really
dumb
best
options
function.
I
don't
really
recommend
that
you
actually
use
this.
This
just
picks
the
node
group
that
has
the
longest
name.
B
The
only
other
sort
of
tricky
thing:
it's
not
actually,
that
tricky
is
configuring
cluster,
auto
scaler,
to
talk
to
your
expander
service.
This
is
pretty
straightforward.
You
just
have
to
pass
in
three
command
line
arguments
to
your
cluster,
auto
scale
or
invocation.
So
the
first
one
dash
dash
expander.
B
We
actually
another
feature
that
landed
in
ca
fairly
recently
is
you
can
specify
multiple
expanders?
We
recommend
doing
this
when
you're
doing
this
custom
expander.
So
here
we're
saying
grpc
is
your
first
expander
and
then,
if
something
goes
wrong,
if
there's
a
network
partition,
you
know
your
expander
service
crashes,
for
who
knows
whatever
reason
then
it'll
fall
back
onto
the
priority.
Expander
so
definitely
worth
having
a
fallback
there
and
then
the
other
two
are
just
telling
cluster
autoscaler
how
to
talk
to
the
expander,
so
grpc
expander
url,
says
hey.
B
This
is
where
you
need
to
send
your
requests
and
then
the
second
one
grpc
expander
cert,
says
these:
are
the
tls
certificates
that
you
need
to
use
to
encrypt
that
communication?
So
it's
pretty
straightforward.
If
you've
done
anything
else
like
there's,
the
grpc
provider
has
a
similar
sort
of
pattern.
B
B
So
I'm
just
going
to
finish
up
with
a
bunch
of
links
you
can
download
this
from
the
sked
site.
First
is
a
link
to
our
design
proposal.
The
second
is
a
link
to
the
actual
pull
request
that
got
upstreamed
inside
there.
There's
a
readme,
that's
just
a
sort
of
text
version
of
what
I
just
said,
there's
also
some
example
code
in
there.
So
if
this
is
something
that's
interested,
that's
a
good
jumping
off
point.
So
sorry,
if
this
is
something
you're
interested
in
that
example,
code
is
a
good
jumping
off
point
for
you.
B
I
don't
think
this
has
gone
live
yet,
but
we
have
written
a
blog
post
about
the
expander
work
that
we've
done
as
well
as
a
few
of
the
other
contributions
we've
made
to
cluster
autoscaler,
I
think
that's
going
to
go,
live
on
our
blog
either
today
or
tomorrow.
I'm
not
sure
exactly
when
I
will
update
the
slides
once
that
blog
post
is
live
for
right
now,
that's
just
a
generic
link
to
our
engineering
blog,
but
hopefully
you
all
can
read
that
and
get
some
interesting
information
out
of
there
as
well.
C
So
what
does
vpa
do?
We
have
we
do
three
things
and
corresponding
to
that?
We
have
three
components
and
we
have
three
modes
of
operation.
So
first
thing
we
always
do
when
you
create
vpa
object,
is
to
generate
recommendations
and
record
those
recommendations
in
the
dvp
object
and
a
component
responsible
for
that
is
recommender.
C
C
C
But
on
the
other
hand,
we
don't
want
to
extend
the
window
to
be
very
long
because
then
our
reaction
would
be
slow,
so
it
would
would
be
good
to
choose
different
windows
for
different
workloads.
Similarly,
workloads
which
answer
user
queries
might
want
to
be
able
to
react
very
quickly,
even
if
there
is
a
load
spike.
C
So,
like
you
can
see
here,
multiple
recommenders
would
read
the
object,
but
only
one
would
actually
write
the
recommendation,
but
to
use
multiple
choose
from
multiple
recommenders.
You
need
to
actually
run
multiple
recommenders
in
your
cluster
and
to
do
that
right
now
you
have
to
implement
your
own
recommender.
C
On
the
other
hand,
one
recommender
might
might
recognize
multiple
names,
so,
for
example,
the
default
recommender
writes
recommendation
either.
If
there
is
no
recommender
name
specified,
because
that
was
the
behavior
before
or
if
you
specified
that
the
default
recommender
should
write
the
recommendation
explicitly.
C
C
We
will
disrupt
your
workload
if
we
evict
them
only
pod,
but
it's
not
a
good
behavior
for
everyone,
because
if
you
have
only
one
running
pod
in
your
controller
by
design,
then
we
will
never
apply
recommendations,
and
this
might
not
be
what
you
want
before
there
was
a
option
you
could
set
to
change
this
behavior
for
all
vpa
objects
in
your
cluster.
But
again
this
might
not
be
what
you
want,
because
you
might
be
running
different
workloads
for
some
workloads.
C
You
might
want
to
wait
for
multiple
pods
to
appear
so
that
at
least
some
will
be
working
for
other
workloads.
You
might
want
to
do
every
the
only
part
to
apply
recommendations
and
the
other
problem
was
that
sometimes
you're
not
controlling
your
cluster
somebody
else's
and
then
you
couldn't
set
the
option.
C
C
Time
durations
between
our
releases
going
forward,
we
would
like
to
do
releases
every
time.
There
is
a
kubernetes
release
so
three
times
a
year,
yeah,
and
if
you
would
like
to
learn
more,
I
linked
to
caps
about
the
enhancements
I
talked
about.
Also,
if
you
want
to
help,
we
have
some
ideas
we
I
would
like
to
make
it
possible
to
configure
pass
parameters
to
recommenders
when
you
specify
them.
C
It
would
be
nice
to
make
it
possible
to
expose
multiple
recommendations
in
one
vpn
object
so
that
you
can
preview
whatever
and
different
recommender
recommends
before
you
actually
make
the
switch,
and
it
will
be
good
to
make
the
default
recommender
more
configurable
so
that
you
can
use
it
as
a
alternate,
multiple
recommenders,
writing.
Multiple
instances
is
without
writing
your
own
code,
and
with
that
I'm
hanging
over.
D
Thank
you,
so
you've
heard
a
lot
about
the
the
new
features
new
extensibility
that
we've
shipped
over
the
last
year
and
a
bit.
However,
this
is
where
we
need
your
help.
You've
heard
obviously
ideas
for
future
improvements
to
the
vpa
cluster,
auto
scalers,
improving
its
extensibility.
You
know
people
can
write
their
own
grpc
expanders
now,
so
we
need
your
help.
We
we
own
a
lot
of
projects
like
you've
heard
about
the
hpa
you've
heard
about
the
cluster
autoscaler
vpa.
We
we
only
have
a
small
number
of
maintainers.
D
We
can't
do
all
that.
We
want
to
do
just
just
with
the
number
of
engineers
we
currently
have
and
contributors.
So
we
want
your
feature:
requests
implementation,
bug,
bug
reports,
what's
not
working
for
you,
what
you
would
like
to
see
work
better
and-
and
we
also
need
your
help
with
bug,
triage
and
response.
We
don't
have
enough
contributors
at
the
moment
to
triage
all
the
bugs
that
we
get
reported.
D
We'd
really
love
to
improve
that,
as
well
as
infrastructure
improvements
to
improve
the
the
testing
around
all
of
our
components,
to
make
it
easier
for
us
end
users
to
contribute,
and
we
we
definitely
want
to
expand
our
maintainers
as
well.
At
the
moment,
we
know
that
there's
there's
diff,
for
instance
in
the
cluster
autoscaler,
despite
the
extensibility
now
with
grpc
expanders
and
grpc,
potentially
cloud
providers.
At
the
moment,
most
of
the
big
cloud
providers
are
baked
into
cluster
autoscaler,
so
we
need
maintainers
for
those
cloud
provider
implementations.
D
A
lot
of
the
big
cloud
providers
do
do
support
that,
but
we
need
we
need
more
to
improve
their
responsiveness
and
prove
how
often
we're
releasing
cluster
auto
scholars
as
well
and
and
as
you
already
heard,
we
want
to
improve
the
extendability
so
that
you're
not
dependent
on
us
cutting
releases.
But
you
can,
if
you
want
to
bake
in
business
logic,
whether
it
be
in
a
an
expander
or
a
cloud
provider,
implementation
that
you
can
do
that
out
of
band
as
well.
We've
got
links
here
to
our
community
charter.
D
If
you
want
to
get
involved
and
we've
also
got
a
mailing
list-
that's
not
massively
active.
However,
we
also
have
that
also
enables
you
to
edit
our
officers,
put
things
on
the
agenda
and
and
we're
also
fairly
active
on
the
segout
scaling
channel.
There's
also
a
sega
auto
scaling
api
channel
for
discussion
about
things
like
the
hpa,
v2,
api
and
potential
few
other
future
improvements
to
the
api
side
of
things
and
we'd
love
to
have
you
involved
any
questions.
E
C
F
C
C
C
Yes,
so
if
you
have
pod
disruption
budget-
and
you
want
at
the
pod
disruption
budget
says
you
want
at
least
three
pots
running,
then
this
lock
will
not
change
anything
for
you
like.
This
is
extra
check.
We
do
in
vpa,
in
addition
to
re,
following
whatever
restriction,
spot
disruption.
Budget
sets
right.
A
A
You
know
data
science
to
analyze
the
usage
patterns
in
their
clusters
to
create
models
that
they
could
then
predict
like
how
they're
gonna
auto
scale,
in
my
opinion,
you'd,
probably
be
better
off
just
looking
at
like
the
traffic
logs
for
whatever
you're
doing
and
it's
like
well,
we
know
that
friday
at
9,
00
pm
we
get
hit.
So
we
we
already
know
the
prediction
friday
at
9,
00
pm.
A
B
A
Cool
thanks,
so
there
are
a
couple
more
questions
here.
One
question
is:
where
can
we
find
the
slides?
I
don't
think
they're
on
the
sketch
page
yet,
but
we
will.
They
are
okay.
So
look
on
the
skedge.org
or
sketch.com
page
for
this
presentation.
You
can
download
it.
It's
got
all
the
links
in
there.
There's
one
other
really
cryptic
question,
and
maybe
this
is
a
good
one
to
end
on,
because
it
it
seems
kind
of
maybe
an
existential
question.
A
It
just
says
what
about
node
auto
scaling?
What
what
about
it?
Yes,
I'm
not
sure
how
deep
to
go
there.
There
is
a
cluster,
auto
scaler
and
it
does
node
auto
scaling.
Maybe
this
person
was
asking
about
some
sort
of
like
vertical
node
scaling
or
something
like
right
now,
the
the
yeah
right,
exactly
something
like
carpenter,
where
you've
got
different,
auto
scaling.
You
know
primitives
and
whatnot,
where
it's
selecting
machines
in
a
different
way
than
the
kubernetes
cluster,
auto
scaler
does
so
what
about
node
auto
scaling?