►
From YouTube: SIG Autoscaling Updates And Feature Highlights - Marcin Wielgus & Jayant Jain, Diego Bonfigli
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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 - Marcin Wielgus & Jayant Jain, Google; Diego Bonfigli, Sysdig
Speakers: Jayant Jain, Marcin Wielgus, Diego Bonfigli
Come hear about the latest updates and features from the Kubernetes Autoscaling community. In this talk, we will cover the status and future plans for the SIG owned projects - Cluster Autoscaler, Horizontal Pod Autoscaler, Vertical Pod Autoscaler. We will show all of their new features, performance improvements and describe the newly added gRPC extension points of Cluster Autoscaler. If you are curious about autoscaling in Kubernetes or would like to learn more about how to get involved with this community, don’t hesitate to join us!
A
Hello:
everyone,
my
name,
is
Marty
Vegas
and
I'm,
representing
seek
Auto
scaling
group
here.
First
of
all,
Let
Me,
Explain,
Who
We
Are
seek
Auto
scaling.
Is
a
group
of
people
within
the
kubernetes
community
focusing
on
reducing
the
cost
of
running
your
clusters.
Of
course,
we
cannot
regurgitate
your
contract
with
your
cloud
provider.
We
cannot
give
you
discounts
codes
to
buy
cheaper
Hardware.
A
We
don't
optimize
your
optimize
applications
either,
but
we
can
make
sure
that
you
always
have
just
enough
instances
of
your
applications
they
are
properly
sized
and
that
the
computing
power
provided
to
run
those
application
tightly
fits
their
needs
in
other
ways
that
you
are
not
wasting
resources
and,
at
the
same
time,
your
applications
are
not
overloaded,
but
having
just
enough
resources
doesn't
only
improve
your
efficiency.
It
also
helps
with
the
ease
of
the
deployment,
development
and
reliability,
as
your
environment
will
adjust
to
the
changes
made
to
your
applications.
A
Foreign
owns
a
bunch
of
components
that
can
help
you
to
execute
and
mention
goals
during
this
presentation.
I
will
very
briefly
explain
what
these
components
do
so
that
people,
so
that
the
people
who
came
here
for
some
introductions
get
it
and
then
I
will
describe
what
are
the
newest
developments
there.
A
The
first
component
I
want
to
talk,
is
horizontal
Port,
Auto
scalar,
horizontal
scalar
is
based
on
metrics
that
Express
the
load
and
that
the
application
gets.
It
can
be
either
some
real
CPU
usage
or
something
more
custom
like
the
number
of
queries
per
second
on
or
other
codes
like
value
provided
by
the
user.
Hpa
takes
this
value.
Take
the
value
of
this
metric
Compares
it
with
the
user
defined
Target
and,
depending
on
this
comparison,
adds
or
removes
replicas
hoping
to
move
the
metrics
towards
the
desired
value.
Let's
take
a
look
on.
A
How
does
it
work
in
practice
here?
The
metric
will
be
utilization,
understood
as
the
ratio
between
the
actual
CPU
usage
of
a
pod
and
the
amount
of
CPU
that
the
Pod
requested.
As
you
can
see,
we
have
here
four
parts
that
are
getting
quite
a
bit
of
traffic.
They
are
using
around
90
of
their
requests
and
if
the
traffic
increases
they
may
not
have
enough
resources
to
handle
the
requests.
A
Hpa
has
been
around
for
quite
some
time.
We
reached
a
stable
version,
V2
back
in
late
2001.
to
2021.
It
means
that,
with
the
accordance
with
the
API
deprecation
policy,
the
better
versions
are
about
to
be
removed.
V2
beta
1
was
removed
in
1.25,
and
Vito
beta
2
will
be
removed
in
1.26.
If
you
are
still
using
the
old
definitions
of
HPA,
please
update
them
as
soon
as
possible,
because
with
your
next
cluster
update,
they
may
stop
working
in
1.26.
We
finally
made
the
controller
multi-threaders.
A
A
A
A
A
Well
so
far,
there
was
no
good
answer
to
these
questions,
so
we
decided
to
provide
some
solution
to
the
problem
as
I
think
we
are
bringing
a
new
tool,
a
new
controller
and
a
new
crd
based
API.
The
central
element
of
this
API
will
be
called
balancer.
The
balancer
object
will
have
pointers
to
multiple
deployments
or
anything
that
exposes
this
mentioned
skill
sub
resource.
A
Each
of
these
deployments
may
have
a
different
node
selector
different
tolerances
possible,
even
different
configurations,
but
what
they
have
in
common
is
that
the
pods
from
these
deployments
build
kind
of
one
service
or
one
application.
Balancer
main
task
will
be
to
properly
size
these
deployments.
A
Each
balancer
will
have
a
placement
policy
According
to
which
it
will
distribute
replicas
across
its
Target,
for
example,
with
the
proportional
policy
of
7030.
It
will
distribute
a
10
replicas
like
this
7
will
go
to
the
first
one,
the
transom
spot
and
free
to
the
other,
one
that
runs
on
regular,
on-demand,
VMS,
okay.
Now
what
if
the
cloud
provider
Runs
Out
spot
instances
and
start
to
preempt
virtual
machines
on
which
these
seven
parts
are
running
as
a
result,
killing
the
pods?
A
Well
after
all,
configurable
timeout,
balancer
notices
that
the
instances
on
preemptable
nodes
are
not
going
back
and
increases
the
size
of
the
second
deployment
in
order
to
account
for
replicas
that
are
failing
on
the
first
deployment,
and
it
will
still
keep
the
first
deployment
at
size
7.
Why
chances
are
that?
Are
you
are
running
a
cluster
autoscaler
in
case
of
cluster
Auto
scalar?
It
will
keep
on
trying
to
bring
nodes
for
those
seven
pods
targeted
at
spot
instances.
A
So
what
is
the
status
of
balancer
project
which
reach
an
agreement
about
the
API
within
six?
The
code
is
almost
done
in
the
Google
internal
repository
yeah
Google
in
actually
wanted
to
start
it
on
gke
first,
but
change
your
mind
in
flight
and
it
will
be
open
source
in
November,
assuming
that
all
of
the
open
source
code
reviews
will
go
smoothly.
So
we
expect
the
initial
release
sometime
this
year.
A
The
next
thing
that
seek
Auto
scaling
ohms
is
a
vertical
potato.
Scaler
vertical
portal
to
scalar
helps
you
to
get
the
pot
size
right.
It
is
based
on
actual
historically
resource
usage
of
the
pods.
It
looks
at
CPU
memory
usage
and
pays
attention
to
out
of
memory
events.
It
recommends
the
pot
or
actually
its
container
sizes
to
keep
the
real
usage
within
the
requested
capacity.
A
So
if
a
pod
is
using
something
like
95
percent
of
its
current
requests
and
maybe
even
occasionally
going
above,
100
vpa
will
increase
the
post
slash
container
size
in
this.
If
this
situation
is
opposite,
it
will
decrease
the
pot
size
and
vertical
potato
scalar
has
also
been
around
for
a
while.
But
despite
that,
seek
managed
to
make
a
couple
of
important
improvements.
A
The
biggest
one
is
probably
the
ability
to
have
multiple
recommenders
running
at
the
same
time,
each
recommender,
which
recommends
what
should
be
the
pot
size,
may
have
a
different
configuration
or
even
a
completely
different
algorithm,
and
you
can
decide
which
one
to
use
by
providing
its
name
in
the
vpa
object
specification
to
support
this
feature.
You
can
now
provide
the
percentiles
used
by
the
standard
vpa
recommender,
while
the
default
90
percentile,
plus
a
little
bit
of
buffer
works
for
quite
a
lot
of
user.
A
You
may
want
to
increase
this,
should
your
workload
be
more
spiky
or,
and
you
care
about
latency
or
maybe
decrease
it.
If
you
want
to
over
subscribe
to
your
nodes
more
soon,
we
hope
to
have
an
ability
to
keep
a
fixed
ratio
between
a
CPU
and
memory.
We
want
to
limit
the
direction
of
the
updates
so
that,
for
example,
containers
and
pod
only
scale
up,
and
we
really
really
hope
to
have
this
kubernetes
in
play.
A
The
last
component
I
would
like
to
talk.
Is
cluster
rotoscaler
cluster
Auto
scaler
ensures
that
your
pod
always
have
a
place
to
run.
It
provides
new
nodes
for
the
pods
that
could
not
be
scheduled
and
removes
nodes
that
are
not
that
needed
anymore.
It
doesn't
use
any
metric,
it
uses
spot
declared
request
and
a
lot
of
scheduling
simulation
to
tell
what
would
happen
if
some
actions
were
made.
Let's
take
a
look
at
this
in
more
detail
here.
We've
have
four
nodes
with
pots.
A
If
a
new
Potter
arrive,
it
can
be
placed
on
the
third
node,
but
if
the
situation
is
different
and
all
nodes
are
kind
of
busy,
then
the
green
pot
has
no
place
to
go.
The
scheduler
marches,
as
unschedulable
cluster
Auto
scalar
waits
for
this
signal.
It
makes
some
simulation
and
notices
that
if
one
extra
note
was
added,
then
the
Green
Pod
could
go
there,
so
it
talks
to
your
cloud
provider
and
resizes
the
cluster.
A
Accordingly,
the
new
note
shows
up
and
scheduler
places
the
port
right
there
and,
let's
take
a
look
at
the
different
setup
here.
We
have
two
nodes
that
are
not
used
to
its
full
capabilities.
But
if
we
move
the
green
part
to
the
third
node,
then
the
fifth
note
could
be
deleted
without
any
problem.
Lowering
your
Cloud
bill.
A
A
We
are
expanding
the
plugability
of
cluster
Auto
scalar
by
allowing
you
to
have
both
grpc
cloud
provider
and
expander,
we'll
talk
about
geopysical
provider
in
a
moment,
and
we
are
working
on
better
clouds,
better,
much
support
her
use
cases
by
integrating
cluster
autoscaler
better
with
job
and
queue.
That
has
been
mentioned,
like
a
bit
before
on
six
scheduling
updates.
B
B
The
logic
behind
the
scaling
decisions
are
common
for
any
environment,
but
at
the
end
the
ca
needs
to
interact
with
the
specific
underlying
infrastructure
like
create.
A
new
hosts,
remove
a
VM,
give
me
the
list
of
the
current
distances
and
so
on,
and
this
is
done
by
calling
apis
for
the
specific
cloud
provider
where
the
cluster
is
running.
B
B
B
If,
then,
you
want
to
contribute
back
to
the
community
and
you
want
your
fork
to
be
merged
back
to
the
official,
faster
Auto
scale.
You
must
respect
some
rules
like
you
cannot
add
new
dependencies
at
top
level.
Vendor
I
mean
in
the
go.mod
file
of
the
project,
and
this
is
because
of
the
problem
with
version
conflicts
in
transitive
dependencies.
B
B
You
can
understand
that
it
could
be
useful
to
have
a
pluggable
cloud
provider,
something
external
to
the
classroom,
to
scalar
core
that
implements
only
the
things
specific
to
our
cloud
provider
and
leaves
the
core
logic.
I
mean
the
scaling
decisions
on
the
cluster
Autos.
Here
with
the
cloud
provider,
Logics
move
it
to
a
different
service,
then
there
is
no
need
anymore
for
a
fork
of
the
ca.
B
For
example,
you
need
to
keep
track
of
Upstream
updates,
you
need
to
integrate
them,
and
then
you
need
to
carefully
get
them
to
understand
if
new
dependencies
back
your
also.
Now
you
can
release
new
versions
of
your
cloud
provider.
Whenever
you
want,
without
waiting
for
a
new
official
CA
release,
you
can
use
libraries
that
you
could
not
use
before,
for
example,
because
they
are
not
under
the
Apache
license,
and
you
can
also
use
your
own
language
of
choice
if
you
want
to
avoid
column.
B
B
C
B
B
Let's
digress
for
a
moment
on
some
general
requirements
that
whole
Cloud
providers
needs
to
meet
both
in
three
Cloud
providers
and
a
new
out
of
three
was
created
with
the
plugin
system
fears
in
the
cluster
of
the
scale.
There
is
a
concept
of
node
groups
to
scale
the
CR
CA
works
with
groups,
no
single
nodes.
This
means
that
when
it
needs
to
add
nodes,
the
ca
actually
choose
a
group
to
scale
out.
B
For
example,
your
implementation
can
can
fake
those
groups,
but
it
helps
when
I
was
killing.
Instead,
the
ca
deletes
specific
nodes
in
another
group,
so
cloud
provider
must
provide
a
way
to
delete
a
single,
node
and
also
resize
the
group.
At
the
same
time,
and
also
for
this
to
work,
there
must
be
a
way
to
correlate
our
kubernetes
node
to
the
actual
host
of
the
cloud
provider,
and
usually
there
is
a
node
field
for
this
called
provider.
B
The
where
Cloud
providers
add
information
to
correlate
kubernetes
nodes
to
cloud
provider
hosts
all
these
requirements,
I
said
are
important,
because
if
you
want
to
create
a
cloud
provider,
you
will
need
to
implement
apis
that
assume
these
Concepts.
You
can
see
a
summary
of
rpcs
apis
on
the
left
here.
B
This
is
very
important
to
use
mtls
for
this,
even
if
you
can
switch
it
off
for
development
purposes,
because
if
you
look
at
the
rpcs,
you
are
essentially
giving
the
permission
to
create
and
delete
notes
in
your
cluster
to
whoever
is
able
to
connect
to
this
server.
So
please
use
mtls
in
production
environments.
B
B
B
B
Keep
in
mind
that
if
you
want
to
escape
from
zero
in
a
group,
meaning
groups
with
zero
nodes
in
some
specific
specific
circumstances,
when
you
have
mirror
codes,
then
calculation
performed
by
the
ca
to
understand
if
a
pending
pod
could
fit
a
new
node
could
not
be
correct.
It
could
be
slightly
half
because
the
information
about
the
full
ports
pods
for
another
are
not
in
the
grpc
cloud
provider.
B
Another
minor
thing
to
know
is
that
the
function
gets
resolution
is
not
available,
but
its
use
is
really
limited
and
almost
no
problem
implements
it
anyway
and
don't
be
confused
by
some
missing
functions
in
the
product
file.
With
respect
to
the
golang
interfaces,
because
some
functions
are
indeed
deprecated
in
the
class
in
golang
interfaces
and
so
I
have
not
been
implemented
as
rpcc
here,
okay,
we
are
at
the
end
of
the
presentation.
B
A
A
C
D
A
A
It
gets
metrics
from
a
metric
server
and
storage
them
as
a
histogram
hotel
in
tcd,
so
we've
got
a
snapshot.
However,
if
you
wanted
to
use
something
some
other
source,
then
you
need
to
do
it
by
yourself.
There's
there's
some
code
around
for
getting
the
metrics
from
Prime
videos.
I
can
probably
point
you
to
to
it.
You.
D
Have
another
question
regarding
cluster
Auto
scaler
right,
for
example,
in
the
cluster
scalar
for
minimum,
we
put
like
four
nodes:
a
maximum
equal
to
10
nodes
and
four
nodes
are
using
around
80
percent,
but
we
put
the
Threshold
at
70
if
it
is
70
less
than
that,
remove
the
node
right,
so
four
nodes
are
using
around
like
80
percent
and
the
fifth
node
is
using
around
thirty
percent.
So
how
does
a
cluster
Auto
scalar
like
behaves?
A
So
as
long
as
all
your
pots
are
scheduled,
it
will
do
nothing,
so
it
will
pack
your
notes
completely
as
long
as
the
pots
feeds
there.
If
the
pot
cannot
be
fitted
to
your
node
and
scheduler
marks
the
pot
as
unschedulable,
then
cluster
autoscaler
kicks
in
analyzes
your
cluster
analysis.
What,
as
your
configuration
and
checks,
whether
adding
new
node
will
help
yeah,
it
I
think
new
note
usually
helps,
but
if
you
a
mistype,
for
example,
pot
size
and
you
put
400.
A
A
So
a
cluster
Auto
scaler
does
a
lot
of
simulation
and
it
invokes
a
lot
of
calls
to
see
what,
if
what,
if
we
added
that
node,
what
if
we
added
another
node,
so
it
rescheduler
a
little
bit
of
like
a
black
box.
So
it
doesn't
look
closely.
What
is
in
pod
specification?
It
just
shows
it
new
nodes
and
checks.
Whether
scheduler
will
put
it
or
not.
Okay,
so
doing
it
with
crd,
is
either
impossible
or
will
take
ages
to
do
communication
via
API
server.
E
Yeah,
so,
regarding
the
the
instance
types
available
on
the
cloud
providers
right
now,
everything
is
hard
coded
into
the
into
the
cluster
autoscaler
code
and
it
has
to
be
maintained.
So,
for
example,
it's
using
AWS
and
AWS
releases
a
few
easy
new
instances
that
I
want
to
use
cluster
Auto
scalar
is
not
going
to
have
support
until
somebody
actually
patches
that
into
the
code.
A
So
it
is
up
to
cloud
provider
implementator,
so
someone
who
coded
it
how
to
handle
it
so
on
gke
we
have
this
process
automated,
but
other
Cloud
providers
are,
for
some
reasons,
not
not
adding
this
type
of
support.
If
you
are
interested,
please
feel
free
to
contribute
to
the
cloud
provider
that
you
are
running
on
and
will
definitely
accept
those
types
of
patches,
so
they
are
not
like
against
getting
current
configuration
current
setting
and
so
on
is
more
than
welcome.
F
A
Removing
nodes
will
not
the
make,
will
not
make
the
life
of
the
spending
Port
harder.
So
if
it's
like
completely
independent
and
the
spot
has
no
chance
to
run
on
this
node
that
we
are
removing
anyway,
then
we
are
okay
with
removing
it.
However,
we
keep
we
don't
scale
down
if
well.
Scheduler
has
not
yet
managed
to
process
the
port,
and
the
Pod
is
likely
to
benefit
from
those
those
being
around.
F
A
F
A
So
yeah
it
we
were
thinking
about
adding
it.
So
why
do
we
have
node
groups?
It
is
because
kubernetes
in
early
version
was
running
on
node
groups
and
we
have
we
are
having
cluster
Auto
scalar
since
2016,
or
something
like
that
and
most
of
the
cloud
providers
operate
with
the
concept
of
node
group,
node,
post,
Auto
scaling
group
or
what
whatever.
A
A
So
you
can
get
rid
of
this
full
concept
and
bring
your
notes
if
you
hard
code,
a
lot
of
code
and
that
figures
out
what
would
be
the
good
note
for
that
particular
pod?
What
is
the
cloud
offering
What
notes
are
supported
what
are
their
prices
so
that
you
don't
get
like
the
most
expensive
one
and
so
on
so
a
lot
of
very,
very
Cloud,
specific
code
that
needs
to
get
in
and
that
may
work.
A
Probably
about
and
yes
gke.
We
had.
We
made
this
effort
of
coding
a
feature
that
we
called
node
Auto
provisioning,
so
it
creates
a
new
node
pool
for
you.
Should
this
notebooks
that
you
have
in
the
cluster
were
not
enough,
like
were
too
small
or
didn't
have
the
requested
GPU.
But
there's
a
lot
a
lot,
really
a
lot
of
Cloud
specific
code
that,
even
if
we
open
source
it
would
be
hard
for
the
other
cloud
provider
authors
to
benefit
from
because
they
will
need
to
do
the
very
same
coding
but
specific
to
their
Cloud
providers.
A
So
for
that
reason,
cluster
autoscaler
is
like
it
is.
If
you
want
Carpenter
experience,
then
please
come
to
gke
and
if
someone
wants
to
devote
their
time
to
coding
providing
this
not
as
a
provisioning
experience
to
other
Cloud
providers,
we
are
very
happy
to
give
you
support
and
tell
you
how
to
do
it
in
cluster
of
the
scalar.
But
the
warning
is
that
well,
it
requires
quite
a
bit
of
of
work
to
get
it
done
properly.
F
A
A
Need
to
implement
this
whole
logic,
that
is
very,
very
specific
to
cloud
provider
and
also
they
have
where
you
create
the
cluster,
how
you
expand
and
how?
How
is
it
built?
What's
the
offering,
what
how
the
how
to
create
new
notes
and
what
they
would
do
it
like
like
a
lot
of
code
I
will
keep
single
cross
for
Carpenter,
but
it
will
be
hard
for
them
to
replicate
it
on
other
Cloud
providers.
A
H
So
the
cluster
Auto
scaler
is
aware
of
node
groups
and
has
some
awareness
of
cloud
providers
for
the
HPA
and
the
vpa.
Is
there
any
like
talk
in
the
community
of
sake?
Auto
scaling
about
adding
some
support
and
the
reason
I
ask
is
because
you
may
have
a
heterogeneous
set
of
nodes
that
your
application
is
running
on
and
because
HP
or
sorry,
because
vpa
provides
a
single
recommendation
for
CPU
and
memory.
It
may
not
fit
all
of
your
nodes
that
your
application
is
running
on
with
the
same
request.
A
H
A
So
running
your
workload
on
significantly
different
nodes
will
cause
your
problems,
because
the
application
on
one
note
may
run
orders
on
magnitude
faster
than
the
other,
and
that
will
confuse
horizontal
but
autoscaler.
What
is
actually
going
on
so
you
can
run
your
application
will
know
that
don't
differ
that
much
probably
we
can
handle
like
10
percent
of
performance
differences
without
any
problems.
But
if
you,
the
other
note,
is
like
three
times
better
than
the
other
than
historical
data
gathered
by
vertical
pot,
autoscaler
will
not
be
valid.
A
Hpa
will
be
confused
whether
you
are
above
or
below
the
Target,
and
whether
you
should
give
you
more
replicas
the
rest
replicas.
It
may
actually
shrink
your
replicas
and
leaving
one
that
is
on
this
spoon,
node,
supervised
training
and
causing
some
type
of
Errors
to
the
customers.
So
at
this
moment,
running
here,
workloads
on
very
heterogeneous
nodes
is
rather
not
recommended,
with
auto
scaling
and
probably
even
with
auto
scaling
too,
because
what
you
need
to
size,
the
pots
somehow
and
exercise.
This
will
be
different
for
different
types
of
nodes.
H
G
Sorry,
this
might
be
kind
of
a
newbish
question
in
terms
of
HPA.
We're
currently
utilizing
it
pretty
well,
but
vpa
is
fairly
new
to
us
from
a
usability
perspective
when
it
comes
to
HPA
a
lot
of
git
Ops
pipelines
such
as
flux
in
terms
of
replication
come
into
a
problem
with
like
three-way
merges
where,
like
flux,
will
give
a
static,
replica
count
and
HPA
will
give
a
dynamic
or
different
replica
count
and
you'll
get
like
a
change
has
already
been
applied.
Please
try
again
later
error
on
some
signs.
A
A
G
A
We
didn't
do
it
because
the
updating
deployment
will
cause
Pottery
creation
and
it's
not
necessarily
the
thing
that
you
would
like
to
have
at
the
moment.
Vpa
has
couple
of
operating
modes,
so
you
can
have
it
have
only
recommendations
without
any
actuation.
That's
for
your
information.
You
can
see
what
would
a
vpa
give
to
your
call
center
apply
it
manually
or
completely
ignore
I.
See
other
option
is
to
have
a
onion
creation
time,
so
vpa
gives
you
recommended
size
when
the
Pod
is
created,
however,
doesn't
touch
existing
pods.
A
So
if
something
is
running,
it's
running
fine,
we
don't
touch
it
even
if
we
wanted
to
give
a
little
bit
more
CPU
and
the
third
mode
is
automatic
when
we
updated
pause
if
they
are
outside
of
the
reasonable
values
for
pod
sizes.
So
not
only
if
they
are
a
little
bit
different
from
the
recommended
value,
but
different,
so
that
we
think
it's
worth
to
update
them
and
even
then
we
respect
things
like
pod
disruption
budget
and
we
try
to
do
it
slowly.
A
So
yeah,
if
you
are
running
vpa
from
time
to
time,
you
should
update
your
deployment
so
that,
if
vpa
is
idle
for
some
reason
not
to
are
running
or
you
have
want
to
have
some
idea.
What
would
be
the
size
of
the
deployment
if
created-
and
you
should
put
it-
take
the
values
from
VIP
object
and
put
your
put
those
in
the
deployment
gotcha.