►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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 Scheduling Intro and Deep Dive - Mike Dame & Jan Chaloupka, Red Hat
SIG Scheduling is responsible for kube-scheduler and its related subprojects such as the scheduling framework and Descheduler. These projects share the common goal of enabling users and developers to ensure that pods are assigned to the appropriate nodes based on various scheduling criteria. This talk will introduce attendees to SIG-Scheduling with an overview of the current goals and ongoing work within the SIG, as well as opportunities for new contributors to get involved. About half of the time will be devoted to informal Q&A and feedback.
A
A
A
A
Currently,
we
have
two
co-chairs,
abdullah
guybeck
from
google,
and
way
huang
from
ibm
meetings
are
taking
place
every
second
week
on
thursday
at
1
pm
eastern
time,
and
if
you
want
to
reach
us,
you
can
find
us
at
the
scheduling
channel
on
the
slack.
The
seeker
scheduling
is
home
to
several
projects,
namely
plugins.
This
is
home
to
out
of
three
plugins
which
can
be
used
alongside
the
entry
plugins,
which
are
provided
in
the
scheduling
framework.
A
There's
a
discard
your
project,
whose
goal
is
to
make
sure
that
but
violating
scheduling
constraints
are
evicted,
then
there's
a
cluster
capacity,
which
is
which
whose
goal
is
to
estimate
a
remaining
scheduling
capacity
in
terms
of
parts,
so
example,
if
you
want
to
know
how
many
instances
of
your
database
pot
can
be
still
scheduled
in
your
cluster,
then
there's
a
queue
batch
project,
which
is
an
implementation
of
the
gang
scheduling
and
there
is
a
position
which
is
an
implementation
of
the
fibament
scheduler
in
case.
You
are
interested
in
more
details
about
the
projects.
A
So
the
we
are
not
going
to
talk
in
detail
about
how
scheduling
works
or
what
it
is,
because
the
last
two
talks
given
at
kubecon
discussed
those
parts
the
chalk
are
given
at
kubecon.
North
america
discussed
the
scheduling
from
the
perspective
of
the
user,
admin
and
developer
and
the
talk
given
it.
Europe
talked
about
the
scheduling
framework
and
what
the
disclosure
is.
A
So,
in
short,
how
this
scheduling
works.
You
have
a
few
of
pots
which
are
still
needs
to
be
scheduled,
which
means
they
have
no
node
assigned
to
them
yet
and
there's
a
list
of
nodes
which
are
suitable
for
scheduling
and
there
is
a
scheduler
component
which
what
it
does
is
that
it
takes
every
part
which
needs
to
be
scheduled
and
find
the
most
suitable
node
for
it.
A
So
the
sketcher
was
designed
with
the
goal
to
provide
a
very
simple
implementation
and
to
maximize
throughput
and
basically,
how
it
works
is
that
you
get
a
list
of
nodes.
You
run
filters
which
gives
you
a
list
of
the
physical
nodes
and
in
case
there
are
two
or
more
nodes
just
score.
Plugins
will
give
you
the
node,
which
is
the
highest
score.
A
So
once
a
part
is
scheduled,
this
catcher
no
longer
knows
what's
going
to
happen
with
the
pot,
so
eventually
some
of
the
pots
may
diverge
from
the
original
scheduling
plan.
So
that's
where
the
discussion
component
comes
and
its
goal
is
to
make
sure
that,
based
that
some
of
these
scheduling
criteria
are
still
respected,
contains
a
list
of
strategies,
each
strategy
responsible
for
a
scheduling,
constraint,
and
once
it's
run
it
goes
through
every
pot,
every
node
and
in
case
a
pot
violates
the
constraint.
The
body
is
evicted
from
its
node.
A
A
New
document
has
been
created
which
describes
how
the
scheduling
views
work,
ensure
there
are
three
scheduling:
queues,
active
queue,
back
of
queue
and
unscheduled
queue.
Active
queue
keeps
pots
which
can
be
scheduled
back
off.
Queue
keeps
pots
which
are
put
to
sleep
for
a
while,
and
the
unscheduled
the
q
keeps
pots
which
cannot
be
scheduled
for
some
reason.
A
There's
a
the
document
describes
a
lifecycle
of
report,
how
it
transitions
between
individual
cues
based
on
certain
conditions
or
events.
So
if
you
are
interested
in
more
detail,
you
can
take
a
look
at
the
new
document,
there's
also
a
new
document
describing
the
code
architecture
of
the
default
scheduler
and
how
it's
built
on
top
of
the
scheduling
framework.
A
A
B
Yeah
thanks
john
I'm
mike
dame
like
you
mentioned,
and
I'm
gonna
go
over
there,
some
other
things
that
are
going
on
in
the
sig
here
that
were
some
improvements
that
we
have
for
the
scheduler.
The
first
one
is.
This
has
been
kind
of
an
ongoing
project
of
refactoring
out
some
of
the
internal
dependencies
on
our
default
plugins.
B
We
have
a
lot
of
a
lot
of
the
plugins
will
depend
on
parts
of
code
that
are
from
case
io,
slash,
kubernetes
and
them
being
connected
to
this
large
codebase
is
makes
it
difficult
for
the
plugins
to
be
more
modular
and
which
would
be
helpful
if
they
could
be
used
by
other
projects
like
descheduler
or
any
sort
of
scheduling
subprojects
that
you
might
have
so.
We've
just
been
working
on
trying
to
remove
those,
and
one
of
the
great
outcomes
from
this
has
been.
The
new
component
helpers.
B
So
you
know
that
you're
getting
a
good
maintainability
that
if
I'm
using
this
function
from
somewhere
it'll
always
have
you
know
a
semantic
meaning
behind
it
that
the
team
is
supporting.
So
if
you
check
out
this
issue,
you'll
see
that's
been
going
on
for
a
while
and
you'll
see
links
to
the
component
helpers
repo.
I
think
it's
just
github.com
kubernetes
component
dash
helpers,
but
you'll
see
it
in
there
too.
B
B
B
Previously,
the
the
event
queue
or
the
unscheduled
queue
would
just
re-cue
pods
kind
of
indiscriminately
whenever
events
came
in
and
the
work
that's
been
going
on
with
this
allows
certain
plug-ins
to
register
for
certain
events
that
should
trigger
pods
to
go
back
to
the
unschedulable.
So
this
will
be
more
efficient
re-cueing
of
those
pots
that
will
probably
hopefully
be
more
reactive
to
things
that
are
actually
going
on
in
the
cluster.
B
B
So
in
this
picture
here
you
can
see
like
we
have
three
different
nodes
and
if
we
wanted
these
pods
from
different
name
spaces,
for
whatever
reason
that
we
have
to
be
co-located
on
the
same
node,
there
wasn't
really
a
way
to
do
that.
But
now
you
can
broaden
the
scope
of
pod
affinity
to
look
at
multiple
namespaces,
which
would
be
hopefully
useful
for
some
people.
B
But
there's
still
improvements
to
be
made
to
that,
including
some
of
the
things
that
I've
listed
here.
Some
some
of
the
plugins
that
have
been
replaced
by
other
more
more
feature.
Full
plugins
are
being
deprecated.
So
that's
things
like
node
labels,
service
affinity,
no
preferred
void,
pods,
those
are
going
to
be
deprecated,
moved
away
from
and
there's
replacements
for
them
that
are
available.
B
We
also
have
the
node
resources
plugins,
the
various
node
resources,
such
as
balance,
usage
least
usage,
which
stress
to
spread
pods
out
most
most
allocated
resources,
which
is
for
bin
packing
when
you
want
to
prefer
nodes
that
have
the
most
resources
on
them.
Already
we're
going
to
be
trying
to
unify
those
into
a
single
plugin
because
they're
a
bunch
of
similar
plugins
that
are
adjacent
to
each
other.
B
So
it
would
be
a
lot
easier
for
people
to
understand
if
they
can
be
configured
from
a
single
place
also
been
exploring
the
possibility
of
fully
qualified
plugin
names,
especially
for
our
entry
plugins.
The
ones
that
are
part
of
the
core
kubernetes
would
like
to
provide
a
well-defined
name
semantics
for
them,
so
that
you
can
at
least
identify
in
an
entry
plug-in
from
a
custom
plugin-
and
this
is
a
big
part
of
the
framework
sort
of
ecosystem
of
trying
to
have
out
of
tree.
B
Plugins
coexist
well
with
entry
plugins,
it's
just
an
organizational
up
for
them
and
then,
in
this
issue,
some
various
backwards
compatibility
removals
that
we
currently
have
in
place
so
need
to
get
too
much
into
detail
of
those
a
couple.
Little
hacks
just
to
make
like
older
versions
of
the
policy
work
with
newer
versions.
B
But
as
this
config
is
evolving,
obviously
we're
going
to
have
to
move
away
from
that.
So
if
you
are
heavily
using
this
current
scheduler
config,
it's
important
to
stay
up
to
date
on
some
of
these
changes
and
be
aware
of
them,
you
know
nothing
will
be
removed
outside
of
the
allowed
deprecation
timeline.
B
B
These
are
links
to
some
blog
posts,
so
the
slides
will
be
shared
and
you'll
be
able
to
check
these
out,
but
they're
very
interesting.
First
one
is
from
cockroach
labs,
basically
discussing
how
they
came
up
with
their
own
custom
filter
plugin
and
how
they
use
that
what
their
problem
was
to
be
able
to
scale
cockroachdb
up
and
down.
B
B
I
see
a
lot
of
people
that
try
to
they
want
to
distribute
like
a
deployment
of
pods
across
nodes
and
the
run,
the
descheduler
for
resource
balancing
I'll,
say
one
wire,
two
or
three
of
these
pods
still
on
the
same
node.
It's
because
you
have
to
consider
the
resource
usage
of
the
entire
node,
but
with
topology
constraints
like
this,
you
can
specifically
say
I
want
these
pots
to
be
distributed
evenly,
no
matter
what
and
that's
just
very
helpful
for
making
sure
that
you
can
get
those
spread
out.
B
The
second
blog
post
here
was
from
openai,
and
that
is
less
specifically
about
their.
What
they're
doing
with
the
scheduler,
but
talking
about
scaling.
Kubernetes
up
to
7
500
nodes
very
interesting:
they
talk
about
some
scheduling
aspects.
They
have
some
sort
of
controller
that
is
managing
taints
automatically
based
on
who's.
Creating
certain
pods
adds
tolerations
for
those
taints
based
on
teams.
B
With
the
caveat
that
when
you
set
a
pod
anti-affinity
to
itself,
you
can
only
have
one
copy
of
that
pod
per
node
and
with
pots
biology
constraints
you
can
set
up
having.
I
want
two
or
three
within
a
certain
skew,
but
this
was
a
an
older
way
to
kind
of
hack
the
scheduler
into
getting
a
nice
even
spreading,
no
matter
what,
regardless
of
resource
usage,
but
they
they
ultimately
end
up
going
with
the
co-scheduling
plug-in
from
the
scheduler
plugins
repo,
which
john
mentioned
a
couple
slides
back.
B
B
First
thing
to
talk
about
here
is
that
we've
added
we've
updated
our
reviewers
and
approvers
to
add
some
of
these
great
contributors.
You
know,
besides
myself
and
yan,
we
have
sean
and
lee
who
have
been
really
active
and
are
just
doing
great
stuff
with
this
project
so
along
with
adding
these
people,
so
that
you
as
a
new
contributor,
if
you're
interested
your
pr,
should
get
assigned
to
a
relevant
administrator
of
the
project
and
if
you
have
any
questions,
these
are
some
of
the
active
contributors
to
work
with.
B
We
move
some
of
our
existing
maintainers
to
an
emeritus
status,
so
that's
like
amesh
and
ravi
and
klaus,
and
those
guys
were
great
for
getting
the
project
started
and
establishing
it.
That's
a
good
way
to
recognize
their
contributions
that
they've
done,
even
though
they
might
not
be
able
to
actively
review
prs
right
now.
So
these
are
people
to
get
in
touch
with
a
couple
new
features
that
we
added
this
released,
some
prometheus
metrics,
which
was
a
big
ask.
B
So
the
d
schedule
will
record
or
metrics
on
odds.
Is
that
number
of
pods
that
are
evicted?
And
things
like
that,
so
you
can
track
how
it's
running
in
your
cluster
label
selector
filtering
for
different
strategies
to
be
able
to
select
pods,
more
specifically,
eviction
based
on
pod
topology,
spreading
soft
constraints,
which
originally
added
this
just
with
the
hard
constraints
for
topology
spread.
B
But
people
asked
about
adding
the
soft
constraints,
so
we
went
ahead
and
did
it,
and
that
is
an
option
now.
Also
the
ability
to
ignore
clouds
with
persistent
volume
claims
the
scheduler
by
default.
It
ignores
pods
with
local
storage,
but
some
people
wanted
to
specify
that
just
for
the
pvc
instead.
So
now
you
can
prevent
evicting
those
pods
that
are
attached
to
the
pvc
and
something
else
that's
going
on
we're
trying
to
work
on
a
way
to
make
the
descheduler
more
reactive
to
events
in
the
cluster
kind
of
similar.
B
We
are
always
looking
for
new
contributors
for
this
project
as
well,
so
yep.
That
is
our
presentation,
and
I
want
to
thank
everyone
for
coming
at
this
point.
We
will
be
opening
up
for
live
q,
a
if
you
have
any
questions
on
something
we
talked
about
or
something
that
we
didn't
talk
about.
That
you
were
hoping
that
we
could
get
to
now
is
the
time
to
ask.