►
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.
SIG Scheduling Deep Dive - Aldo Culquicondor, Google & Mike Dame, Red Hat
Kube-Scheduler is the component of Kubernetes that assigns pods to nodes based on the configured scheduling requirements. These requirements can be high availability, resource efficiency and other policies and heuristics. This talk will provide an overview of the new and upcoming features in the scheduler, including the scheduler framework, and the new component config API that enables scheduling profiles. In addition, we'll present updates on other sig-scheduling projects like the Descheduler. We will dedicate about half of the time of the presentation to audience questions and users' feedback.
https://sched.co/ZeuJ
A
A
A
A
A
We
have
also
merged
the
reserve.
Another
serve
extension
points
into
a
single
one.
This
is
to
reduce
configuration
burden
for
cluster
operators
and
the
last
feature
is
the
new
post
filter
extension
point,
the
post
filter
extension
point.
It
only
runs
if
the
scalar
failed
to
find
any
suitable
candidates,
any
suitable
nodes
for
your
pod,
and
the
intention
is
that
the
pos
filter
plugin
would
act
in
the
cluster
to
change
change
it
in
some
way,
so
that
the
the
pod
can
be
scheduled.
A
A
These
spots
might
be
removed,
might
be
evicted
to
make
space
for
this
pod.
That
is
higher
priority,
but
you
can
extend
or
you
can
create
your
own
field,
your
own
plugins,
to
do
to
implement
different
behaviors
for
the
scheduler,
and
here
comes
again
the
scheduling
the
new
scaling
plugins
repository.
A
And,
as
I
said,
the
the
the
framework
is
center
center
in
developers,
whereas
for
cluster
operators,
this
looks
as
simple
as
scheduling
profiles,
so
this
is
the
cluster
admin
facing
api
and
what
they
can
do
is
disable
default.
Plugins
enable
custom,
plugins
and
maybe
reorder
them.
This
could
be
important
for
for
filtering.
A
A
So
in
a
single
binary
you
can
serve
different
configurations
which
will
have
different
behavior
and
the
pods
can
select
which
profile
they
want
to
use
by
using
the
scheduler
name.
That
is
an
existing
api,
quite
all
from
1.6
or
so,
and
in
119.
We
have
graduated
this
api
to
beta
here
in
the
right.
You
can
see
one
such
configuration,
for
example
in
this.
In
this
configuration
we
have
two
profiles.
A
A
A
So
then
a
preemption
could
happen
or
maybe,
if
you
have
cluster
of
the
scalar,
you
could
have
an
auto
scale
or
a
scale
up
or
it
could
be
soft,
meaning
that
scalar
will
try
to
do
its
best
to
satisfy
this
criteria.
But
if,
if
it
can,
it
will
still
place
the
pot,
but
you
might
not
have
the
the
best
balance
so,
and
one
new
feature
we
introduced
in
118
is
that
you
could
also
set
a
default
well
default.
A
Cluster
level
default,
which
will
be
applied
to
all
deposits,
belong
to
a
service
or
a
replica
set
such
that
you
can
have
some
kind
of
automatic
spreading
and
in
in
1819.
We
have
graduated
this
to
to
ga
and
we've
been
working
in
119
in
in
getting
this
score,
really
influenced
scheduling,
so
so
that
you
can
actually,
with
with
your
soft
constraints,
you
can
actually
have
very
good
spreading,
but
if
you
don't
want
such
such
strong
spreading,
you
can
also
use
the
max
skew
field
to
control
this.
A
You
can
see
that
we
have
one
one
constraint
with
a
max
key
of
two:
this
this
constraint
is
defined
for
zones
and
it's
a
hard
constraint.
You
can
see,
do
not
schedule
if
you
cannot
satisfy
the
condition
and
as
any
as
most
as
several
other
apis,
you
can
define
a
label
selector
to
to
detect
which
pots
are
affected
by
by
this
constraint.
A
B
A
Nodes,
we
have
also
improved.
We
also
improved
the
latency
of
specialized
features,
such
as
port
affinity.
Here
we
actually
obtain
a
very
big
boost.
We
achieve
24
x,
improvement
for
for
preferred
affinity
and
seven
times
for
required
affinity
in
118
and
119.
We
focused
on
again
these
specialized
features.
We
even
improved
affinity.
Further,
we
achieved
two
two
times
improvement
in
latency
and,
as
we
were
preparing
to
graduate
what
what
the
ball
just
played
into
ga,
we
also
work
on
on
its
latency
and
we
also
obtain
a
2x
improvement
and
now
this
this
spreading.
A
This
feature
is
if
you're
familiar
with
the
legacy,
selector
spread
priority.
This
new
plugin
is
equivalent
in
in
speed,
but,
as
I
said
earlier,
it
has
much
stronger,
spreading
guarantees
in
in
118
and
beyond.
We
want
to
focus
on
preemption.
We
want
to
make
it
faster
to
to
either
preempt
faster
or
skip
it.
If
we
already
know
that
preemption
is
not
helping,
and
we
also
want
to
focus
on
the
effect
of
unscalable
parts
once
your
cluster
has
a
lot
of
unscalable
pots,
it
can
affect
the
latency
of
the
scheduler.
B
B
The
problem
that
you
have
with
the
scheduler
is
that
it
will
take
a
new
pod
and
put
it
onto
the
cluster
based
on
the
series
of
defined
plug-ins,
but
once
the
pod
is
scheduled,
nothing
happens
to
counteract
for
that.
In
case,
the
state
of
your
cluster
changes
so
say
if
a
pod
gets
scheduled
onto
a
node
and
then
later
on,
that
node
gets
some
sort
of
taint
or
a
label
gets
applied
to
it.
That
doesn't
match
the
affinity
that
the
pod
originally
had.
B
B
So
the
first
thing
that
we
did
was
we
have
now
decided
on
aligning
the
deschedulers
releases
with
upstream's
releases,
so
that
means
that
we're
going
to
be
tagging
release
branches
along
with
the
upstream
release
schedule.
So
this
means
that
you'll
know
what
version
of
kubernetes
the
descheduler
is
compatible
with.
B
Another
part
of
that
is
that
we've
published
some
production
containers
for
anyone
to
consume.
You
don't
need
to
build
your
own
d
scheduler
now,
if
you
just
want
to
use
the
default
that's
available.
These
are
published
on
gcr
to
io
and
they'll
be
tagged
with
the
matching
release
numbers.
So
you
can
grab
this
and
run
it
in
your
cluster
without
having
to
build
the
descheduler
yourself,
which
makes
it
a
lot
easier
to
run.
B
So
the
next
thing
that
we
did
was
we've
added
a
couple
new
strategies.
The
full
list
of
available
strategies
for
the
descheduler
is
on
the
readme
for
the
repo
I've
mentioned
a
couple
of
them
so
far,
such
as
no
node
affinity,
pod
affinity,
there's
strategies
that
will
remove
if
you
have
duplicates
of
pods
running
on
a
node,
and
you
want
to
spread
those
out
more
it'll
try
to
evict
some
of
those
duplicates,
and
hopefully
they
get
rescheduled
onto
a
different
pod.
B
B
So
this
can
be
helpful
if
you
have
pods
that
are
constantly
crash
looping
for
some
reason,
and
you
want
to
get
in
there
and
evict
those
pods,
maybe
to
kick
them
onto
a
new
node
that
has
better
availability
for
them.
Maybe
they're
crash
looping
because
they're
having
trouble
connecting
to
some
mounted
network
volume
on
one
node,
but
once
it
gets
evicted,
it
goes
on
to
the
new.
B
B
The
next
strategy
that
we
added
is
a
pod
lifetime
strategy,
which
just
removes
pods
that
are
over
a
certain
a
number
of
seconds
old.
So
that's
pretty
self-explanatory.
If
you
have
long
running
pods
and
you
want
to
evict
those
in
favor
of
newer
pods
try
to
get
new
pods
into
the
system.
That
is
what
that
is
for
the
third
one
that
at
the
time
at
this
time,
is
in
progress.
B
What
we're
targeting
is
for
the
119
release
cycle
is
a
topology
spread
strategy
which
matches
the
topology
spreading
plug-in
that
aldo
mentioned
and
looks
at
if
your
topology
becomes
uneven
at
some
point.
While
the
pods
are
running
it's
going
to
go
through
and
try
to
work
on
or
try
to
affect
those
pods.
That
will
hopefully
be
rebalanced
in
the
way
that
you
want
with
your
strategy.
B
B
But
with
these
like
I'm
like
it
says
here,
we
are
always
looking
for
new
ideas
and
new
strategies
that
can
be
added
to
the
d
scheduler,
like
the
scheduler,
there's
infinite
number
of
ways
that
you
can
imagine
that
you
might
want
to
come
up
with
a
strategy
for
how
your
cluster
should
be
balanced
or
how
that
could
be
violated.
And
what
you
want
to
do
to
address
that.
So
any
new
ideas
with
use
cases
for
them
are
welcome
in
the
repo
and
any
new
contributors.
B
So,
along
after
those
changes,
we
have
a
couple
miscellaneous
improvements
to
the
repo
one
of
those
is
that
we
just
finalized
we're
going
to
be
publishing
a
helm
chart
automatically
with
our
release.
So
this
will
be
easier
for
people
who
are
consuming
home,
charts
to
publish
or
to
run
the
d
scheduler
they
will
be
able
to
grab
those
from
our
github
repo
would
be
published
with
github
pages.
B
Make
it
a
little
easier
to
deploy.
Another
thing
that
we're
adding
is
the
ability
to
run
the
descheduler
selectively
on
pods,
based
on
their
labels
or
on
specific
name.
Spaces
is
something
that
we've
had
people
ask
for.
I
just
want
to
run
the
descheduler
to
keep
this
one
project
balanced
instead
of
running
it
having
it
affect
my
whole
cluster,
that's
what
these
will
provide
for
you
and
another
thing
that
we're
looking
at
in
the
future
is
being
able
to
control
what
priority,
based
on
a
priority
class
threshold.
What
pods
are
eligible
for
eviction
too?
B
B
B
And
then
we
just
had
some
various
quality
of
life
improvements
to
the
code,
some
refactors,
one
of
those
being
that
we've
improved
the
logging
we've
improved
the
ability
to
see
why
pods
were
evicted
in
the
logs
as
well
as
raising
events
when
pods
are
evicted.
That
specifically
say
it
was
evicted
because
it
violated
the
pod
anti-affinity
of
the
node,
for
whatever
reason
happens
to
be
and
various
other
code
refactors
that
are
too
small
to
mention
here,
but
definitely
improve
the
readability
and
the
ability
for
people
to
contribute
to
the
code.
B
Looking
ahead,
we've
got
some
plans
that
we
plan
to
contribute
or
continue
improving
the
code
base.
One
of
those
is
we're
looking
at
our
api
to
configure
the
deschedulers
strategies
we
want
to
make
that
a
little
easier
to
configure
and
make
it
a
little
more
extendable
for
users
to
add
in
new
strategies.
B
A
A
A
First
from
the
q
scatter
perspective
in
general
yeah,
this
this
option
has
been
discussed
in
the
past
and
there
is
there
isn't
immediate
pressure
for
it,
so
we
are
not
not
doing
it
in
in
the
next
release
or
unless
there
are
contributors
that
come
in,
but
but
this
there
is
a
problem
here,
because
such
such
feature
would
require
that
the
cube
scheduler
starts
watching
running
pots,
which
it
doesn't
today,
but
but
the
api
is
not
just
about
the
scheduler,
it
can
be
enforced
by
other
components.
For
example,
we
have.
A
A
C
Yeah
pretty
much
exactly
what
you
said.
It's
come
up
a
couple
times
before
and
I
think
in
the
past,
when
I
have
seen
it
come
up,
people
tend
to
point
to
the
d
scheduler
for
it.
I
think
that
if
you
run
the
d,
scheduler
you'll
basically
get
that
behavior
right
now,
if
you're
looking
for
the
required
during
scheduling
required
during
execution,
but
it's
not
like
I
said
in
the
presentation
the
scheduler
isn't
watching.
C
A
C
Yeah
I've
heard
people
ask
about
it
before
it.
I
think
it
goes
back
again
to
look
just
like
what
we
were
just
saying
about.
You
know
if
the
scheduler
was
going
to
be
watching
pods,
it's
kind
of
taking
the
opposite
behavior
of
the
schedule,
so
it
would
have
to
run
as
like
a
separate,
routine
or
maybe
be
a
separate
binary,
but
it
depends
on
how
you
want
to
define
integrating
it
into
the
scheduler.
C
I
don't
think
right
now,
there's
too
much
looking
at
it
and
we're
trying
to
get
some
of
the
scheduler
actually
integrated
into
the
d
scheduler
by
getting
those
plug-ins
and
making
them
available
to
be
imported
and
use
the
d
scheduling
strategy.
So
in
that
way
the
d
scheduler
is
kind
of
a
weird
implementation
of
a
scheduler
in
a
way
on
its
own.
So
I
don't
know
if
we're
really
going
to
be
looking
at
moving
d
scheduling
into
the
scheduler
anytime
soon,
but
if
there
is
enough
interest
for
that
coming
up,
I
would
not
be
against.
C
A
A
Well,
there
is
first
of
all
the
the
ability
to
iterate
faster.
If
you
have
a
separate
project
you
can
incubate,
you
can
put
it
in
a
separate.
It's
a
repository
and
people
can
contribute
faster
because
the
scatter
is
old.
You
don't
wanna,
you
don't
want
to
break
it.
You
don't
want
to
break
people's
clusters
as
they
update,
so
it's
safer
to
to
start
a
separate
project
and
and
even
better
for
this
kind
of
thing,
where
you
have
a
separate,
entirely
separate
routine.
C
Yeah
and
tagging
on
to
that,
the
like
you
said
that
people
can
contribute
a
lot
faster
to
the
d
scheduler
as
a
separate
project,
we're
not
so
strictly
tied
to
kubernetes
release
cycles.
Even
though
we
try
to
keep
them
lined
up.
You
know,
code,
freezes
and
stuff.
We
can
be
a
little
looser
on
and
just
have
a
faster
iteration
that
people
can
contribute
to.
A
A
A
What
do
you
think
is
the
most
exciting
challenging
problem
for
granted
scheduling
today,
I'm
gonna
say
basically,
two
things
one
is
scalability
is
a
lot
of
people
in
the
community
asking
for
for
some
contention.
I
mentioned
in
the
talk
this
problem
of
unscheduled
pots
that
affect
scheduling.
So
that's
one
and
it's
hard
because
there
are
so
many
events
happening
in
the
the
cluster,
the
bots,
both
removed
or
pots,
terminated
and
or
nodes
new
nodes
or
remove
nodes.
So
it's
not.
A
C
I
know
topology
aware
scheduling
is
also
another
thing
that
we
have
the
default
topology
spreading
plug-in
that
you
talked
about
in
the
presentation,
but
I
know
that
there's
a
lot
of
people
trying
to
work
on
their
own
solutions.
For
that
too,
I
think
that
there's
an
entirely
separate,
topology
aware
scheduling
channel
in
the
gate
slack
where
people
are
working
on
really
interesting
solutions
to
it
and
I'd
pop
in
there
every
now
and
then
to
see
what's
going
on,
but
it
gets
a
little
over
my
head.
A
A
Is
there
a
memory
type
aware
scaling
available
example?
Kubernetes
knows,
with
dram
versus
nodes,
with
p
p
m
e
m
ram,
sram,
etc.
Not
that
I'm
aware
of
there
is
some
discussion
about
node
topology.
So
if
you
have
a
numa
nodes,
there
is
that
discussion
that
is
already
started,
and
I
imagine
this
problem
would
be
kind
of
similar,
but
I
don't.
I
haven't
seen
any
discussions
around
this.
C
C
I
wasn't
actually
around
for
the
very
start
of
the
descheduler,
but
it's
been
something
that
was
being
considered
for
a
while
and
especially
now
that
the
framework
has
become
the
main
way
that
the
scheduler
configures
its
plugins.
So
really
once
we
got
the
switch
to
the
scheduler
framework
with
plugins
the
consideration
of
bringing
those
plugins
into
the
scheduler
started
to
come
up
right
away.
So
we
have
been
thinking
about
that
for
a
while,
but
it
wasn't
a
main
driving
force
of
developing
the
framework.
C
As
far
as
I'm
aware,
although,
but
it's
something
that
we
want
to
make
easily
and
portable
now,
so
that's
just
a
nice
side
effect,
and
now
we
are
kind
of
using
that
to
drive
breaking
out
these
plug-ins.
We
have
the
scheduler
plug-ins,
separate
repo
that
I
think
we're
going
to
try
to
move
some
plug-ins
to
eventually-
or
at
least
it's
an
incubating
repo
for
new
plug-ins.
Now
something
that
word
that
we've
considered
thought
about.