►
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.
Deep Dive into Autoscaling - Maciek Pytel & Joe Burnett, Google
Come and see how to debug and optimize your autoscalers and decrease your monthly infrastructure costs even further. During this talk members of SIG-Autoscaling will discuss the internals of HPA, VPA and Cluster Autoscaler, their peculiar features, and ways to fine tune them across dimensions like cost and availability. After this talk you will know where to look for information about the autoscaler activity, what settings can be changed and which flags should probably be left alone.
https://sched.co/ZeyB
A
Hello,
welcome
to
the
sig
auto
scaling
deep
dive.
My
name
is
joseph
burnett
and
I'm
here
with
my
check
patel
we're
going
to
be
going
into
some
auto
scaling
topics
a
little
bit
deeper
than
the
introduction,
so
we'll
be
sort
of
assuming
that
you
know
a
little
bit
about
kubernetes,
auto
scaling
and
that
maybe
you
have
seen
the
sig
intro.
A
I'm
going
to
talk
a
little
bit
about
workload,
autoscaling
that
is
increasing
and
decreasing
the
number
of
pods
in
a
cluster,
and
my
check
is
going
to
follow
up
with
a
little
bit
about
a
cluster,
auto
scaling
which
is
increasing
and
decreasing.
The
number
of
nodes
on
which
those
pods
run,
in
particular,
I'd
like
to
highlight
some
new
features
in
hpa,
coming
in
kubernetes
118,
which
are
called
scale
controls,
and
I
think
that
it
would
be
also
helpful
to
go
over
a
little
bit
about
custom
metrics
in
the
hpa
and
the
hpa
life
cycle.
A
Okay.
So
let's
talk
a
little
bit
about
the
recommendation.
Life
cycle
so
hpa,
like
every
other
object
in
kubernetes,
is
something
stored
in
scd
and
when
you
want
to
want
to
scale
a
deployment
or
another
scale,
sub-resource
horizontally,
you
declare
your
intent
in
an
hpa
object
in
spec
and
the
hpa
controller
tries
to
reconcile
to
that
intent.
So
the
first
step
in
that
reconciliation
is
to
get
the
hpa
object.
A
A
So
it'll
come
up
with
some
recommendation.
For
example,
if
you,
if
you've
decided
that
you
want
your
application
to
run
on
average
at
50
cpu
utilization,
the
hpa
controller
will
get
the
current
number
of
pods.
Maybe
it's
10.
it'll
get
the
current
cpu
utilization
from
the
metrics.
Maybe
cpu
utilization
is
75
and
it
will
decide.
Okay,
actually,
you
need
more
pods
to
bring
that
down
to
the
target,
so
it
will
give
you
five
additional
pods.
A
Then
after
it's
calculated
the
new
desired
state
for
each
metric,
it
will
limit
and
stabilize
the
maximum
recommendation.
So
limiting
is
like
not
going
above.
The
specified
maximum
not
going
below
this
specified.
Minimum
stabilization
is
a
part
of
the
algorithm
that
waits
for
five
minutes
before
you
scale
down.
So
it
actually
so
light
keeps
a
window
of
recommendations
for
five
minutes
and
chooses
the
maximum
recommendation
over
that
time.
This
prevents
flapping
and
scale
down.
Stabilization
allows
you
to
scale
up
quickly
in
response
to
new
load,
but
sort
of
come
down,
gracefully
without
flapping.
A
So
that,
finally,
when
the
hpa
recommender
has
a
has
a
scale,
it
will
turn
around
and
set
that
back
onto
the
scale
sub-resource
and
then
wait
for
15
seconds
before
repeating
the
process.
It
does
this
for
each
hpa
object.
Every
15
seconds
goes
in
this
reconciliation
loop
checking
the
current
state
of
the
world,
making
an
adjustment
checking
to
see
if
it
needs
to
make
subsequent
changes.
So
there's
a
there's:
a
feedback
loop.
A
So
hpa
has
two
versions
available:
there's
v1
and
v2
v2
is
currently
in
beta
2..
You
can
get
them
from
the
command
line
with
these
commands
here.
Just
this
is
normal
kubernetes
stuff.
You
just
have
to
qualify.
V2,
don't
look
too
closely
at
this.
I
just
wanted
to
show
you
the
shape
and
I'm
going
to
go
through
each
one
of
these
sections,
one
at
a
time.
A
The
second
part
of
the
spec
is
the
metrics,
so
in
in
v1hpa,
there's
just
one
top
level
target,
which
is
cpu
utilization
percentage,
but
in
hpa
v2.
You
can
provide
more
than
one
metric,
so
you'll
notice
that
metrics
on
the
right
hand,
side
is
a
list,
and
this
is
what
cpu
utilization
looks
like
for
the
new
v2
metrics.
A
A
So
I
mentioned
that
hpa
v2
can
have
multiple
metrics,
so
the
other
kind
of
metrics
that
you
can
add
in
there
to
that
list
are
called
custom
and
external
metrics
custom.
Metrics
are
anything
that's
inside
of
the
kubernetes
ecosystem,
so
this
is
pods
or
deployments
ingress.
Whatever
there's
two
kinds
of
custom
metrics
one
custom
metric
is
a
pod
metric
and
then
so
the
hpa
will
expect
to
find
one
of
these
for
each
pod
in
the
deployment,
and
then
it
will
average
them
for
an
object.
A
A
I
want
to
take
a
moment
and
talk
a
little
bit
about
how
custom
metrics
are
wired
into
the
system,
because
this
is
something
that's
important
to
know
if
you're
going
to
set
up
hpa
on
custom
metrics.
So
the
api
server
has
a
mechanism
by
which
it
can
delegate
calls
to
some
objects
to
other
api
servers.
So
you
can
see
there
that
the
main
api
server
has
fcd
storing
things
like
hpas
deployments,
pods,
etc,
but
when
it
gets
a
request
from
metrics,
it
routes
it
to
a
different
server.
A
There's
a
metric
server,
that's
part
of
the
normal
kubernetes
distribution,
which
provides
memory
and
cpu
and
that's
runs
typically
in
the
user
space
of
the
cluster.
The
access
pattern
for
a
database
like
that
is
very
different.
So
this
is
one
of
the
reasons
why
it's
a
different
implementation.
It's
a
time
series
database,
not
just
a
key
value,
store,
there's
another
server
that
is
in
this
routing
path
as
well,
which
is
the
custom
or
external
metrics
adapter.
A
A
So,
for
example,
if
you
have
a
prometheus
instance
that
has
the
metrics
that
you
want
for
custom
and
external
metrics,
you,
you
install
an
adapter
that
will
take
those
get
requests
to
the
api
server
objects
and
translate
it
into
a
backend
query
for
the
the
data
source
that
you
have
so
this
is
this
is
where
the
data
comes
from
when
hpa
retrieves
it
so
moving
on
sort
of
through
the
life
cycle.
Here
you
can
see
that
calculating
the
state
is,
is
kind
of
the
core
value
of
this
of
the
hpa.
A
This
is
the
part.
That's
going
to
reconcile
you
the
number
to
to
try
to
achieve
your
target,
so
the
current
utilization
is
first
achieved
by
either
averaging
that
all
the
pods
are
just
taking
the
single
value,
and
then
it's
going
to
be
divided
by
the
target.
So
say:
if
you
want
50
percent
and
you
get
75,
you
end
up
with
a
one
and
a
half
times
what
you
should
have
in
terms
of
utilization.
A
So
there
are
a
few,
so
these
are
so
scale.
Controls
are
a
new
field.
Top
level
field
in
the
v2
api
inside
of
the
behavior
field
is
two
structures:
they're
identical
one
is
called
scale
up,
one
is
called
scale
down,
and
each
of
these
has
the
stabilization
as
well
as
relative
and
absolute
policy
that
can
be
applied
in
term
for
limiting
the
rate.
A
There's
a
couple
of
defaults
that
were
already
part
of
hpa,
which
have
become
defaults
for
the
scale
controls
one.
Is
that
there's
a
flag
on
controller
manager
that
sets
the
down
scale
stabilization
window,
which
is
by
default
five
minutes?
So
this
is
the
default
for
scale
controls
as
well,
and
this
is,
as
you
can
see
here,
inside
the
scale
down
structure.
A
So
this
was
sort
of
just
a
small
optimization
and
also
there
was
a
limit
in
the
controller
which
said
that
you
can
only
scale
up
by
2x
each
time,
each
reconciliation,
so
these
become
defaults
in
the
scale
controls,
but
you
can
change
them.
So,
for
example,
if
you
want
to,
if
you
want
to
come
down
slowly,
if
you
sort
of
expect
your
traffic
to
maybe
come
back,
you
can
limit
the
rate
at
which
you
scale
down.
A
If
you
want
to
maybe
have
a
shorter
stabilization
window
to
come
off
of
a
spike
more
quickly
or
a
longer
one,
you
can
set
that
it's
actually
also
possible
to
set
a
scale
up
stabilization
window,
which
is
sounds
kind
of
counter-intuitive.
At
first,
but
it
could
be
useful
for
a
batch
workload
where,
for
example,
you
have
some
number
of
pods
running
and
a
whole
bunch
of
messages
land
in
the
queue,
but
you
may
care
more
about.
A
You
know
utilizing
your
pods
and
resources
as
efficiently
as
possible,
rather
than
latency.
So
you
might
want
to
wait
a
few
seconds
or
a
few
minutes
to
wait
and
see
if
the
pods
that
are
already
there
can
handle
all
the
messages.
So
that's
what
a
stabilization
window
could
be
used
for
for
scale
up
so
explore
the
documentation,
there's
kind
of
a
cool
feature.
That's
there
in
118.
A
And
the
there's
a
lot
more
details
about
what
they
mean
in
the
actual
like
golang
docks.
So
I
recommend
you
go,
take
a
look
at
it
again.
That's
in
the
v2
beta,
2,
hpa
structure,
so
big
thanks
to
ivan
and
arjun
for
writing
the
cap
and
doing
the
implementation
and
pushing
this
through
for
quite
some
time.
It's
it
could
be
difficult
to
make
changes
in
kubernetes.
It
can
take
time
and
patience
and
they
definitely
did
a
great
great
thing
here
to
put
this
with
the
scale
controls
in.
So
thank
you.
A
One
last
thing
about
the
v2
api
I'd
like
to
mention
before
I
close
the
workload
section
is
that
there's
also
conditions
which
are
added
to
the
v2
api
and
status.
So
conditions
are
a
pattern,
a
newer
pattern,
newer
than
v1
hpa,
which
just
gives
you
some
insight
into
how
the
reconciling
controller
is
doing
towards
achieving
your
desired
state
and
if
it's
not
in
the
desired
state.
A
Why
not
so
it's
kind
of
a
structured
way
to
sort
of
get
some
insight
and
observability
and
there's
three
sort
of
types
that
are
worth
noting
scaling
active
able
to
scale
and
scaling
limited.
So
I'd
like
to
talk
for
a
moment
about
what
each
of
those
means
scaling
actives
means
that
you
have
provided
metrics
that
exist.
A
They
can
be
retrieved,
so
it's
possible
to
sort
of
know
where
we're
at
in
terms
of
the
metrics
that
you
provided.
So
if
able
to
if
scaling
active,
is
true.
That's
that's.
A
good
thing
able
to
scale
means
that
the
scale
target
ref
is
able
to
be
retrieved
and
updated.
So
that
also
should
be
true,
and
if
it's
not,
then
there'll
be
a
message
there
to
tell
you
a
little
bit
more
specifically,
what
went
wrong
scaling
limited
is
a
little
bit
more
of
a
just
informative.
A
It's
not
necessarily
a
problem
if
you're
scale
limited
because
usually
you're
limited
because
of
some
policy
limit
or
a
stabilization
that
that
has
been
put
in
effect
for
a
reason.
So
this
is
just
for
you
to
know
that
the
raw
desired
number
of
replicas
is
being
constrained
in
some
way,
either
upwards
or
downwards,
and
this
should
also
tell
you
why.
A
All
the
new
and
unknown
fields
into
annotations,
so
it's
possible
to
interact
with
a
v2
hpa
object
as
a
v1
with
a
read,
modify
right
loop
as
long
as
you
only
modify
the
spec
fields
for
that
particular
version
in
case
you're
wondering
where
these
things
go
and
when
you
just
say
cube,
control,
get
hpa.
Most
of
the
most
of
the
interesting
stuff
is
in
annotations.
So
it's
worth
worth
pulling
down
the
v2
object,
so
that's
sort
of
a
summary
of
scale
controls
and
v,
hp,
v2
and
some
custom
metrics.
B
B
So
this
is
going
to
be
things
like
notes,
size
notes,
allocatable
and
port
resource
requests
and
but
also
things
like
pots,
note,
selectors,
node
affinities,
pod
affinities,
hospitals,
any
sort
of
storage,
related
requirements
and
so
on.
Basically,
anything
that
can
go
into
kubernetes
scheduling
what
it
doesn't
look
at
is
metrics,
because
kubernetes
scheduling
doesn't
take
into
account
actual
cpu
usage
or
memory
utilization
of
the
vms,
so
neither
does
class
delta
scale.
B
For
that
part,
you
need
workload,
auto
scaling
and
before
we
proceed,
there
is
one
more
concept
that
we're
going
to
need,
and
that
is
a
node
group.
A
node
group
is
basically
a
set
of
identical
notes:
a
resizable
set
of
auto
identical
nodes.
So
whenever
the
cluster
to
scalar
wants
to
scale
up
what
it
really
does,
is
it
resizes
a
particular
node
group,
adding
some
number
of
nodes
to
it
and
the
actual
implementation
of
node
group
is
going
to
be
different
on
each
provider.
B
So,
let's
quickly,
look
at
the
architecture
of
class
autoscaler,
so
class
autoscaler
is
a
pot
that
runs
in
your
cluster
either
on
notes
on
the
master
vm
and
it's
really
made
of
three
main
parts.
There
is
the
cluster
auto
scaler
logic,
the
color
logic
of
auto
scaler.
That
sort
of
does
the
whole
the
whole
auto
scaling
logic,
but
there
are
two
important
parts
that
are
also
there.
B
What
we
do
is
we
just
import
the
scheduler
code
and
use
it
to
run
sort
of
hypothetical
scenarios
to
explore
what
would
happen
if
a
node
was
added
to
the
cluster
right?
Would
that
help
any
of
the
ports
that
are
currently
pending
get
scheduled?
But
what
would
happen
if
some
node
was
removed
from
the
cluster?
Would
all
pods
running
there
will
be
able
to
schedule
on
some
other
nodes
and
instead
of
replicating
all
the
schedule,
scheduler
logic
in
autoscaler,
we
just
import
scheduler
code
and
ask
it
those
questions
and
the
other.
B
The
other
external
part
is
the
cloud
provided
module,
it's
basically
a
rich
client
to
a
given
cloud
provider,
so
something
like
aws
or
gc
azure,
or
something
more
abstract
like
a
cluster
api,
and
this
is
what
class
autoscaler
uses
to
actuate
its
decisions
whenever
class
autoscaler
wants
to
scale
up
it.
Really
all
it
does
is
request
a
vm
from
the
cloud
provider,
and
then
it
doesn't.
It
isn't
actually
involved
in
the
process
of
that
vm,
starting
up
or.
B
In
kubernetes,
all
it
really
does,
is
it
make
a
request
to
cloud
provider,
so
I
think,
with
that
background,
we're
ready
to
dive
into
the
an
example
scale
up.
So
what
I
have
here
is
basically
a
sort
of
hypothetical
scenario,
and
there
is
a
cluster
with
three
node
groups.
So,
as
you
can
see,
there
is
a
node
group
with
large
nodes
that
have
a
label
a
and
also
node
group
of
equally
large
nodes
with
label
b.
B
And
finally,
a
third
node
group
of
smaller
nodes
and
these
dimensions
of
nodes
are
meant
to
be
a
some
sort
of
abstract
representation
of
resources
available
on
those
nodes.
So,
for
example,
you
can
think
of
it
as
a
maybe
vertical
size
of
the
node
would
be
how
many
calls
it
has
and
then
the
horizontal
size
would
be
how
much
memory
there
is,
and
similarly
there
are
a
bunch
of
pods
which
also
have
size,
which
would
be
the
same
with
that.
B
That
would
be
the
pot
resource
requests
and,
as
you
can
see,
some
of
the
pods
also
have
a
node
selector.
So
this
is
to
illustrate
like
other
type
of
constraint.
That's
not
resource
related,
but
it's
also
respected
by
clustered
auto
scalar.
So
in
this
case,
some
of
those
spots
can
only
run
on
nodes
with
label
a
which
means
basically
nodes.
From
the
first
note.
A
B
So,
let's,
let's
start
the
hypothetical
scenario
we're
starting
with
a
bunch
of
empty
notes
and
a
bunch
of
pending
parts.
So
obviously
the
first
thing
that's
going
to
happen
is
scheduler
will
jump
in
and
schedule
as
many
pods
as
it
can
on
existing
nodes.
So
this
is
basically
what
what
we
can
see
in
these
slides.
B
All
the
parts
that
can
fit
on
the
nodes
are
already
dead
and
the
notes
are
pretty
much
full,
but
there
are
still
some
pots
that
remain
so
what
will
happen
with
those
is
the
scheduler
will
say
that
it
cannot
schedule
them,
because
there
is
not
enough
resources
available
in
the
cluster
and
it
will
mark
them
as
unscheduleable.
More
specifically,
it
will
set
a
status
condition
on
on
those
spots,
and
that
is
the
signal
signal
for
cluster
autoscaler
to
jump
in.
B
It
basically
looks
for
those
unscheduleable
ports
and
tries
to
help
them
and
the
way
it
does
it
is
it
explodes
those
hypothetical
scenarios,
so
the
first
thing
autoscaler
could
do
is
think.
Okay,
what
would
happen
if
there
was
one
more
of
those
label
a
node?
Basically,
what
would
happen
if
a
node
first
node
group
had
two
nodes
instead
of
one?
Until
to
this
end,
it
will
create
an
in
memory,
fake
representation
of
a
node.
It
doesn't
correspond
to
any
real
vm
or
anything
like
that.
B
Yet
it's
just
an
in-memory
object
and
it
would
ask
schedule
okay.
What
would
happen
now
like
if
you
had
this
extra
note,
so
in
this
case
the
scheduler
would
be
able
to
schedule
some
of
those
pending
pots
on
this
new
note,
but
not
all
of
them.
I
did.
The
one
note
is
not
enough
to
fit
all
of
those
pending
posts,
so
crosstalk
autoscaler
will
just
continue
to
do
the
same.
It
will
add
one
more
identical
node,
so
basically
explore
okay.
B
So
what
would
happen
if
I
resized
this
node
group
from
one
to
three
and
once
again
it
would
ask
scheduler
and
the
scheduler
would
put
small
ports
on
this
new
node
and
basically,
we
would
reach
a
state
where
all
the
pots
that
are
pending
and
could
now
be
scheduled
if
two
more
nodes
were
added
to
the
first
node
group.
So
that
is
what
we
call
expansion
option.
That's
basically
one
action
available
to
cluster
auto
scale
which
will
help
depending
pots,
but
of
course
there
are
other
possibilities
there.
B
B
So
if
we
do
very
similar
logic
where
we
add
nodes
for
as
long
as
we
can
put
more
of
the
pending
points
on
them,
and
we
do
this
process
for
the
second
node
group,
we
can
see
that
we
could
add
three
more
of
those
small
nodes
and
that
would
help
three
of
those
spending
pots.
However,
no
there
is
no
way
we
can
help
the
large
pending
posts
by
adding
small
nodes,
just
because
each
individual
pod
is
too
large.
B
If
we
think
about
this
once
again
that
the
horizontal
dimension
is
memory,
the
small
nodes-
just
don't-
have
enough
memory
to
run
the
large
board
so
that
there
is
no
way
we
can
help
them
by
adding
the
small
nodes.
But
that's
fine
that
that
is
an
expansion
option.
So
we
we
can
remember
that
we
can
add
three
small
nodes
and
that
will
help
those
small
pots
and
we
can
proceed
to
the
next
simulation
and
explore
what
would
happen
if
we
were
to
resize
the
fence,
node
group
and
the
end
of
this
result.
B
Here
is,
we
can
add
two
nodes
and
that
will
help
all
the
ports
except
the
one.
With
the
node
selector
a
there
is
actually
enough
resources
on
those
two
new
nodes
to
run
all
the
ports,
but
we
cannot
schedule
one
of
them
because
of
the
node
selector
constraint,
so
that
illustrates
that
class.
Auto
scaler
is
also
taking
these
sort
of
constraints
into
account.
B
So
this
is
basically
how
the
exploration
of
various
scenarios
would
look
like
in
class.
The
autoscaler
note
that
all
the
options
with
considering
is
always
resizing.
One
node
group
by
a
certain
amount
of
nodes-
and
it's
always
the
largest
amount
of
nodes
that
actually
helps
any
help
spots
right,
so
we're
not
going
to
consider
an
option
where
we
would
resize.
Let's
say
the
felt
node
group
by
just
one
node,
because
adding
one
more
node
still
help
spots
so
we'll
just
greedily.
B
B
So
after
all
the
simulations
are
done.
We
really
left
with
three
of
those
expansion
options
that
we
discussed
earlier
and
class
autoscaler
is
going
to
use
something
we
call
expander
to
choose
one
of
those
options.
Expanded
is
basically
just
a
holistic
that
takes
all
the
available
expansion
options.
Basically,
how
many
nodes
are
needed
to
help
what
set
of
pots,
and
it
just
evaluates
them
to
choose
the
best
one?
There
are
multiple
different
expanders.
There
is
a
random
expander
which
just
chooses
a
random
option.
B
There
is
a
pricing
expanded
available
for
some
platforms,
which
tries
to
choose
the
cheapest
in
terms
of
dollar
cost
like
the
cheapest
option
in
terms
of
dollars,
and
there
is
also
a
priority
expanded
where
you
can.
Basically,
the
user
specifies
a
list
of
preference
between
node
groups
and
class.
Auto
scaler
will
try
to
choose
whichever
one
is
the
most
preferred.
That's
particularly
useful
when
you
have
some
sort
of
much
cheaper
instances
like
maybe
sport
or
preemptible
instances,
or
you
can
implement
your
own
expander.
B
It's
actually
a
simple
go
like
interface,
and
it's
not
very
hard
to
implement
one,
and
the
one
remaining
question
is
okay.
Some
of
those
expansion
options
only
help
some
of
the
pending
pots.
What
what
about
the
other
parts-
and
the
answer
is
after
doing
the
first
scale
up
if
any
pots
remain
pending
class,
auto
scale
will
run
another
iteration
and
do
the
whole
simulation
again
and
pick
some
other
scale
up,
and
it
will
continue
doing
so
until
it
helps
all
depending
pots.
B
We
have
meetings
every
monday
at
4,
00
pm
central
european
time,
and
they
happen
on
zoom,
and
everyone
is
of
course,
welcome
to
attend
this
and
ask
any
questions,
discuss
any
suggestions
and
so
on.
We
also
have
our
own
channel
on
kubernetes
slack,
where
I
think
it's
quite
active.
So
if
you
have
any
problems,
I
think
that's
a
good
place
to
either
ask
for
help
or
just
engage
us
for
discussing
features
and
so
on.
And
finally,
most
of
our
code
is
in
our
own
github
repository
and
that's
it
for
me.
Thank
you
very.
A
A
A
so
and
those
defaults
come
from
that
flag
and
where
the
hard
code
is
where.
So,
if
you
start
a
controller
manager
or
118,
and
you
set
the
flag,
horizontal
pod,
auto
scaling
down
scale,
stabilization
equals
10
minutes
and
you
create
an
hpa
and
you
load
it
and
you
get
it
back
and
you
look
at
the
value
for
behavior
scale
down
stabilization
window
seconds.
A
A
B
So
you
need
some
sort
of
private
cloud
setup
and
currently
the
supported
ones
is
using
openstack,
magnum
and
cluster
api.
I
think
both
of
those
could
be
potentially
used
on
them,
so
there
is
a
way
to
do
it.
If
you,
if
you
have
some
underlying
system
that
can
add
and
remove
nodes
but
class
autoscaler
cannot
do
it
by
itself.
B
Okay,
so
another
question
is:
why
does
the
scheduler
need
the
fake
representation?
If
you,
if
we
add
a
new
node,
and
why
cannot
it
explicitly
be
calculated?
How
many
nodes
we
need
for
the
workload?
So
this
is
because
there
are
multiple
different
requirements.
I
try
to
illustrate
that
by
using
a
node.
B
So
another
question
is
how
node
selector
get
the
value
of
new
added
node.
So,
as
I
mentioned,
a
node
group
is
expected
to
be
a
set
of
identical
nodes.
So
basically,
when
you
have
a
node
already
in
a
given
node
group,
cluster
autoscaler
will
just
copy
it
and
assume
the
new
node
will
be
identical,
and
that
includes
things
like
labels.
Basically
everything
there
is
also
scale
from
zero
logic
available
for
some
providers,
and
this
is
provided
specific.
B
B
B
Another
question
is:
are
there
any
plans
to
open
up
class
autoscalers?
Other
frameworks
can
trigger
scaling
actions,
so
this
is
quite
complex.
The
the
problem
here
is
that
classic
autoscaler
doesn't
necessarily
have
much
of
a
notion
of
an
action.
It's
really
just
sort
of
reconciling
cluster,
so
there
is
always
enough
space
to
schedule
all
parts
and
it's
actually
starting
like
it's
basically
simulating
scheduling
from
scratch.
Every.
A
B
B
However,
there
are
quite
a
few
like
systems
or
in-home
solutions
that
various
people
use
and
the
general
idea
is
a
scale
up-
can
be
triggered
by
creating
low
priority
pots.
So
those
spots
are
basically
enough
that
they
just
and
pulse
image,
otherwise
do
nothing
and
they
have
a
low
scheduling
priority.
So
this
is
enough
to
trigger
a
clustered
autoscaler
scale
up,
but
it's
if
a
pod
with
a
higher
priority
will
be
created
at
the
airport.