►
From YouTube: Kubernetes SIG Node Intro and Deep Dive - Elana Hashman, Red Hat & Sergey Kanzhelev, Google
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.
Kubernetes SIG Node Intro and Deep Dive - Elana Hashman, Red Hat & Sergey Kanzhelev, Google
Kubernetes SIG Node is responsible for components that control interactions between pods and host resources, including the Kubelet, Container Runtime Interface (CRI), and Node API. SIG Node is responsible for the Pod’s lifecycle from allocation to teardown, to liveness checks and shared resource management. We work with the various container runtimes, kernels, networking, storage, and more; anything a pod touches is SIG Node’s responsibility! In this session, we will begin with an introductory overview of the SIG and what it has worked on in the past. We will then deep dive into ongoing efforts of the SIG, including features targeted for the 1.21 and 1.22 releases and future roadmap. Join this session to learn more about our SIG, and how you might get involved to make Node even better!
A
Hello,
everybody
and
welcome
to
this
year's
kubernetes
sig
node
intro
and
deep
dive
update
at
the
kubecon
europe
2021
virtual
edition.
My
name
is
elena
hashman
and
I'm
a
principal
software
engineer
at
red
hat.
I
currently
work
on
the
openshift
container
platform
engineering,
node
team
and
I've
been
involved
in
kubernetes
since
2018,
primarily
in
c
instrumentation,
but
more
recently,
also
in
sig
node.
B
B
B
So
what
is
signaled,
if
you
think
about
kubernetes
as
cluster
orchestration
solution,
you
will
think
about
nodes
as
something
that
manages
containers,
that's
scheduled
by
kubernetes.
So
once
kublet,
it's
an
agent
running
on
a
node
receives
a
port
that
needs
to
be
scheduled.
It
tears
down
into
individual
containers
and
schedules
them
according
to
resource
management,
constraints
and
other
possible
limitations.
B
So
signat
contains
of
sub
projects
like
couplet
container
runtime
interface,
and
it
also
includes
some
specific
tools
that
help
in
signaled
like
tools
to
manage
containers
like
cry
tools
or
detecting
problems.
From
this
container,
like
not
problem
detector,
you
can
follow
the
link
and
find
more
sub
projects
that
we
own
and
signal
is
huge.
A
Thanks
sergey,
so
one
of
the
things
that
I
want
to
talk
about
today
are
what
we've
been
up
to
in
sig
node
in
the
past
few
releases,
what
sorts
of
features
we've
graduated?
What
sorts
of
features
are
on
our
upcoming
roadmap?
That
kind
of
thing,
so
one
of
our
themes
for
the
most
recent
releases
have
been
graduating
features
stuck
in
beta.
So,
for
example,
we
have
a
cisco
support
which
was
alphaed
in
one
four,
but
we
recently
graduated
that
in
the
121
release
as
well.
A
We
graduated
rana's
group
and
cri
log
rotation
in
121
and
in
120
we
graduated
pid,
limiting
runtime
classes,
third-party
device,
monitoring,
plugins
and
many
more
we're
also
working
on
new
features.
So
some
of
the
things
that
we've
seen
in
the
past
couple
of
releases
we've
added
cri
support
on
windows
which
graduated
in
120
in
121.
We
graduated
immutable
secrets
and
config
map
support
in
the
cubelet
we've
also
added
alpha
support
for
memory
management
in
the
cubelet,
which
enables
pneuma
use
cases.
We
have
added
the
pod
resource
api
extension
to
ga.
A
So
that's
now
been
graduated.
We've
launched
graceful,
node
shutdown
in
beta
as
of
121,
and
many
more
we've
also
worked
on
a
couple
of
enhancements
that
are
bug
fixes,
particularly
around
probes,
so,
for
example,
we've
fixed
exec
probe
timeouts
in
120,
and
we've
added
a
configurable
grace
period
for
probes
that
began
alpha
in
121
in
order
to
override
the
pod
level
spec
in
terms
of
our
upcoming
roadmap.
A
B
So
docker
was
the
very
first
runtime
that
kublat
was
using
to
schedule
containers
you
can
think
of
kublet
as
something
that
receive
signals
from
api
and
it
schedules
these
containers
on
machine,
but
to
schedule
them
like
actually
do
work
of
putting
them
running
them.
It
uses
docker,
so
it
calls
docker
sim
through
the
api
called
cri
container
runtime
interface
docker
in
in
its
turn,
calls
into
container
d
and
container
d
schedules
containers.
B
You
may
note
that
docker
also
provides
extra
set
of
tools
to
work
on
these
containers
and
it
also
puts
them
in
a
special
docker
environment.
So
containers
have
more
information
about
each
other,
so
docker
provides
more
tooling
around
containers
than
kublet
needed
without
the
like.
For
many
years
already,
we've
been
working
on
removing
dependency
on
docker
to
eliminate
this
other
head
of
extra
features.
That
kublet
doesn't
need.
B
With
this
direct
call
into
runtime
through
container
runtime
interface,
you
get
a
little
bit
faster
scheduling
because
you
don't
have
this
overhead
of
docker.
You
have
less
dependencies
on
your
machine
and
better
portability
of
your
environment,
because
you
don't
take
dependencies
on
docker
as
a
container
runtime
interface
as
a
runtime
runtime
of
a
choice.
B
We
also
getting
a
faster
feature:
development
as
a
benefit,
because
now
before
I
would
say
now
now,
with
the
docker
and
other
runtimes,
we
need
to
implement
every
feature
on
docker
as
well
as
cri
to
work
on
all
the
runtimes
with
the
removal
of
docker
shim
out
of
the
tree.
We
only
need
to
concentrate
on
few
run
times,
and
this
will
make
feature
development
faster
and
test
coverage
of
this
feature
better.
B
So
we're
coming
to
migrate
off
the
docker
stream
now
before
124
will
come,
and
you
already
can
do
that,
because
container
d
and
cryo
is
production.
Quality
is
well
supported
and
you
can
use
them
at
any
moment
now,
so
what
you
will
be
losing
generally,
you
wouldn't
be
losing
anything
because
your
containers
were
around
the
same
way.
You
will
only
get
problems
if
you
intentionally
or
unintentionally,
took
a
dependency
on
docker.
B
B
B
Some
things
will
work.
If
you
install
docker
like
docker,
build
may
still
be
working
if
you
have
docker
on
the
machine,
but
why
would
you
do
that?
If
you
have
other
tools
that
doesn't
have
that
doesn't
require
to
run
in
privileged
ports?
So
you
may
not
want
like
you,
can
run
docker
build
and
pull
and
push
off
images,
but
you
may
not
want
to
do
that
and
eliminating
this
dependency
will
make
your
workload
even
more
portable
and
faster.
B
So
please
migrate
of
the
docker
shim
with
a
docker
shim.
You
we're
using
a
little
bit
different
code
path
as
we
use
with
cri
in
general,
and
that
increases
the
need
for
test
coverage
and,
in
general,
the
amount
of
component
signal
manages
an
amount
of
areas
we
are
responsible
for
make.
The
tests
coverage
is
a
big
issue
for
us,
so
in
signot
we
always
prioritize
stability.
First
and
we've
been
taking
tests
over
features,
we've
been
taking
tests
over
bug
fixes.
B
So
we
form
this
ci
sub
project
of
sig
node
and
we
have
separate
meetings
and
we
have
separate
like
subset
of
people
who
really
like
working
on
this
area.
So
what
we're
working
on
we're
looking
at
test
matrix
test
matrix
is
something
you
can
learn
about
by
going
to
community
kubernetes,
community
website
and
you're,
looking
specifically
on
signal
tests
and
whenever
we
see
some
flaking
test
or
failing
test,
we
schedule
somewhere
someone
to
work
on
this
flake
and
fix
it.
B
This
way
we
have
constant
attention
on
a
test
on
test
matrix
and
we
can
guarantee
that
the
kubernetes
code
base
is
stable
and
can
be
released
successfully
with
the
cci
subgroup
is
very
welcoming
community
and
we
it's
a
really
good
place
to
start
learning
about
kubernetes,
because
you
learn
from
doing
some
actual
work,
and
this
work
is
something
that
we
prioritize
really
highly.
So
please
join
us
in
ci
sub
project,
and
now
we
will
talk
about
the
scale
of
signaled
elana.
A
Yeah
for
sure,
so
one
of
the
interesting
things
about
working
in
sig
node,
which
is
a
vertical
sig,
is
that
sig
node
in
terms
of
absolute
workload
is
the
third
largest
sig
in
the
kubernetes
project
and
that's
out
of
about
two
dozen
sigs.
So
what
does
that
translate
to
in
terms
of
contributor
volume?
A
On
an
average
day,
we
have
about
200
open
prs,
and
in
a
given
week
we
usually
merge
or
close
anywhere
between
20
to
80
prs
per
week.
We
have
hundreds
of
contributors
that
work
on
sig
node
and
in
the
past
year
we've
had
contributors
for
over
39
companies.
So
your
help
is
needed.
We
can't
do
this
alone
and
one
of
the
ways
that
I've
worked
to
manage
this
scale
is
moving
a
lot
of
our
work
into
project
boards
that
help
us
track
the
state
of
these
hundreds
of
prs.
A
So,
as
you
can
see
on
the
right
of
this
slide,
it's
a
quick
snapshot
which
will
zoom
in
on
the
next
slide
of
a
project
board
with
multiple
columns
that
help
to
track
the
state
of
a
pull
request
and
for
now
we're
currently
at
the
kubernetes
kubernetes
level.
Tracking
specifically
prs
within
sig
node,
with
the
hope
of
expanding
to
project
issues
in
the
future.
A
So
at
the
scope
of
sig
node,
we
look
at
and
separate
prs
out
into
categories
of
needing
triage
waiting
on
author
waiting
for
a
reviewer
waiting
for
an
approver
and
done,
and
this
allows
new
contributors
who
want
to
jump
right
in
to
ensure
that
pull
requests
are
correctly
categorized
in
the
right
column
on
the
board.
The
correct
labels
are
applied
and
that
if
you
want
to
go
ahead
and
start
either
reviewing
pr's
or
approving
prs,
the
column
of
everything
that
you
need
to
work
on
is
right
there.
A
So
this
is
an
example
of
how
we're
doing
this
on
the
triage
board
for
the
ci
and
test
sub
project.
So
on
this
subproject
we
also
focus
on
issues
since
people
sometimes
file
flaky,
test
issues
against
us
and
we
need
to
track
those
to
ensure
that
they
get
closed.
So
we
have
multiple
columns
here
for
issues
and
pr
reviews
and
there's
more
columns.
A
If
you
were
to
scroll
right,
but
we
can't
do
that
on
the
slide,
and
here
you
can
see
in
the
search
box,
I've
applied
a
no
assignee
search
which
allows
us
to
look
at
all
of
the
items
on
the
board
that
don't
currently
have
an
assignee,
which
means
that
probably
nobody's
working
on
them
right
now.
So
we
might
want
to
ensure,
before
the
end
of
our
meeting,
that
someone's
assigned,
we
can
also
filter
on
labels
on
whether
a
pr
is
open
or
not.
Whether
something
is
a
pr
versus
an
issue
and
so
on.
A
So,
as
I
mentioned,
we're
focused
on
pull
requests
in
the
121
release,
but
we
do
hope
that
in
the
future
we
might
be
able
to
expand
this
to
issues
as
well,
and
I
would
look
forward
to
help
from
the
community
to
make
that
happen.
And
so,
if
you
look
at
our
slides
after
the
talk,
we've
included
lots
of
links,
and
so
you
can
access
the
sig
node
pr
board,
as
well
as
the
ci
and
test
enhancements
board.
A
One
of
the
other
things
we've
been
working
on
as
part
of
triage
is
improving
our
documentation,
so
more
people
can
jump
in
and
get
involved.
So
if
the
board
looks
a
little
intimidating
or
you're
not
really
sure
where
to
jump
in
or
what
does
reviewing
a
pr
even
mean,
or
how
do
I
find
an
approver
we've
written
all
of
that
down
to
make
it
easier
for
you
to
get
started
or
if
you
haven't
worked
on
the
project
in
a
while
to
get
a
refresher.
A
We're
also
looking
to
add
a
contributing
file
specifically
to
help
you
get
started
with
sig
node.
So
you
can
use
that
as
your
one-stop
shop
to
get
started.
It'll
have
links
to
all
sorts
of
things
that
you
need
to
focus
on
in
terms
of
working
with
the
cubelet
working
with
the
cri
and
getting
started.
A
A
And
that
is
to
say,
we
really
want
you
to
get
involved
and
we're
trying
to
make
it
easy
for
you.
So
what
can
you
work
on
as
sergey
said
earlier?
We're
prioritizing
stability
first,
so
we
want
to
make
sure
that
our
test
coverage
is
good
and
our
tests
are
passing
before
we
start
working
on
bug,
fixes
or
known
open
issues
and
then
prioritizing
features.
Last
of
course,
we
graduate
things
from
all
three
categories,
but
if
you're
looking
for
somewhere
to
get
started
highest
impact
stuff,
you
can
work
on,
are
probably
tests
and
bug
fixes.
A
We
also
need
help
with
our
test
infrastructure,
monitoring
and
health.
We
also
want
to
improve
both
the
user
experience
for
an
operator
of
a
cluster
who's
working
with
cubelets
and
the
developer
experience
for
folks
who
want
to
work
on
sig
node.
So
it
is
very
helpful
if
you
want
to
contribute
documentation
or
help
improve
our
logging
and
metrics
or
help
us
keep
on
top
of
pull
requests
and
issues,
because
there's
just
so
many
on
the
board
in
the
latest
release.
A
One
of
our
exciting
new
features
was
that
we
graduated
or
we
migrated
the
entire
cubelet
to
structured
logging.
So
that's
one
example
of
one
of
these
sorts
of
efforts
where
new
contributors
found
it
relatively
straightforward
to
get
involved
and
are
now
more
involved
in
sig
node,
so
more
to
come.
Things
like
that.
A
Thanks
all
so,
okay
you're
interested
in
contributing
you
know
approximately
what
you
want
to
work
on
and
you're
excited
to
get
involved.
How
do
you
do
it
attend
our
sig
meetings?
That
is
usually
your
first
stop.
So
our
sig
meetings,
which
are
weekly
cover,
features
kubernetes
enhancement,
proposals
and
more,
and
they
typically
involve
all
of
the
wider
discussions
as
a
sig
that
we
would
undertake
our
ci
and
triage
meetings
are
a
smaller,
hands-on
group
that
still
happen
weekly.
A
So
again,
here
I've
got
links
to
our
triage
guide
as
well
as
both
of
our
boards.
In
case
you
want
to
get
involved
there.
We
also
welcome
people
to
adopt
new
features
and
give
feedback.
Writing
code
is
not
the
only
way
that
you
can
make
kubernetes
better
and
it's
really
important
for
a
lot
of
our
features,
particularly
as
we
are
focusing
on
graduating
things
from
beta
to
graduation
that
we
get
test
data
from
real
environments
in
order
to
ensure
that
we're
not
introducing
any
regressions.
A
B
A
So
where
can
you
find
us
specifically?
Our
regular
meetings
are
weekly
on
tuesdays
at
a.m,
specific
time,
pacific
time
and
if
you
click
on
the
link
you'll
be
able
to
convert
that
into
your
local
time
zone.
Our
ci
and
triage
meetings
are
weekly
on
wednesdays
at
10
a.m.
Pacific
time
our
slack
channel
is
pound
sig
node
on
the
kubernetes
slack.
Our
mailing
list
is
the
kubernetes
sig
node
google
group
and
our
sig
chairs
are
don
chen
at
google
and
derek
carr
at
red
hat
in
case.