►
From YouTube: Kubenetes SIG Node Intro and Deep Dive - Elana Hashman, Derek Carr, Sergey Kanzhelev & Dawn Chen
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Kubenetes SIG Node Intro and Deep Dive - Elana Hashman & Derek Carr, Red Hat; Sergey Kanzhelev & Dawn Chen, Google
Kubernetes SIG Node owns 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.22 and 1.23 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
A
B
C
D
A
Before
getting
into
today's
agenda,
I
want
to
briefly
mention
the
previous
signaled
update
made
by
allah
and
the
circuit
back
in
may
I,
the
cubic
euro
and
click
click.
Each
of
those
link.
You
will
see
the
watch
of
the
record,
video
and
also
slides
next
here's.
Today's
agenda,
we
are
going
to
first
introduce
signals
responsibility.
A
A
What
is
the
signal
and
its
responsibility?
Let's
briefly
talk
about
the
node
responsibility
in
kubernetes.
First
kubernetes
is
a
cluster
orchestration
solution
for
containerized
applications
and
services.
Those
containers
included
of
the
kubernetes
control
planes
are
running
on
the
nodes
on
each
node.
There
is
a
agent
called
kubernetes
kubernetes
register,
node
to
kubernetes
master,
coordinate
together
with
container
runtime
managing
part
and
the
container's
lifecycles
on
the
node
setup
run
tier
down
and
clean
up.
A
Kubernetes
also
sends
the
status
back
to
the
control
plane.
Next,
in
summary,
signal
owns
all
controllers
running
on
the
nodes
which
ensures
node
itself
and
applications
running
on
it.
Running
happily,
signal
is
very
large
and
owns
many
projects,
and
this
and
and
you
can
click
the
all
those
following
of
the
links
you
can
find
so
many
interesting
projects
and
also
the
tools
and
the
demons
to
ensure
of
the
load
healthiness.
D
D
I
wanted
to
refresh
like
until
tell
what
we
actually
delivered
in
122
in
terms
of
caps
by
the
way
cap
is
a
our
way
in
kubernetes
to
track
features
and
improvements.
It's
it's
a
short
for
kubernetes
enhancement
process
and
we
track
all
the
caps
through
different
stages,
and
this
list
shows
caps
that
we've
been
working
on
in
one
page
too
and
actually
merged
it.
D
I
try
to
split
caps
into
themes
and
it's
really
hard
to
split
into
anything
in
the
teams.
It
seems
not
an
attribute
of
a
cap,
it's
just
our
way
to
attempt
to
group
it
to
demonstrate
what
we've
been
working
on.
I
think
it's
important
for
kubernetes
to
stay
on
the
edge
of
which
workload
we
support
between
high
performance
applications
or
some
databases.
D
D
I
just
I
wanted
to
highlight
again.
The
scripts
are
by
no
means
ordered
in
any
priority
order,
for
everybody.
Priority
is
different.
Some
people
care
about
some
features,
other
people
who
care
about
other
features.
I
just
ordered
that
by
number
by
cap
number
you
can
see
it
in
the
end
end
of
every
link
so,
and
it's
also
hard
to
structure
and
categorize
caps
into
themes.
D
C
D
B
B
It's
important
that
as
the
underlying
operating
systems,
the
keyboard
is
orchestrating
to
run
containers
on
that
we
keep
up
with
emerging
changes
at
the
actual
host
itself
at
the
kubernetes
tier
and
take
advantage
of
them.
A
lot
of
folks
might
not
realize
today
that
the
memory
request
on
a
pod
when
running
on
a
secret
v1
host
isn't
actually
used
to
provide
any
quality
of
service
guarantee
to
that
container
beyond
just
a
minimal
scheduling
guarantee.
B
A
Actually,
I'm
really
glad
that
we
finally
decided
to
deprecate
this
one.
So
this
I
first
started
at
the
beginning
about
the
kubernetes
at
early
adoption
stage
and
we
don't
have
like
the
clearing
of
the
node
spec.
We
also
don't
have
that
clear
of
the
standardized
of
the
system
configurations,
so
many
users
at
earlier
time
want
to
customize
their
know,
the
configurations
and
the
specs.
At
the
same
time
we
have,
we
don't
have
we
only.
A
We
have
tons
of
the
logs
flags
to
need
user
to
customize
our
offer
so,
which
is
uns,
structured
and
is
and
is
not
manageable.
So
through
this,
we
funded
this
project
and
back
in
2017,
and
so
while
to
support
this
one.
Actually,
we
are
defining
of
the
kubernetes
components
component
configurations
project
which
is
not
just
for
kubernetes,
actually
applied
to
all
the
control
plan,
and-
and
so
we
draw
those
things
successfully,
a
while
back
so
make
all
our
control
plan
can
be
managed
and
another
thing
it
is.
A
We
also
deprecated
tons
of
unused
of
the
flags
and
convert
them
to
the
kubernetes
config
fields
and
over
those
times,
and
we
also
realize
how
to
do
the
more
dynamically
kubernetes
configurations
at
node
level,
but
no
no
lead
have
this
intrusive
and
much
harder
to
manage
the
dynamic
kubernetes
config
resets.
So
I
think
this
is
serve
the
purpose
original
purpose
and
now
is
the
good
time
to
deprecate
this.
D
D
D
It's
a
very
good
number,
considering
everything
two
of
them
was
exception,
so
very
last
moment
and
four
were
almost
ready,
so
we
could
have
done
17,
but
exception
was
denied
by
different
reasons
and
from
things
that
went
well
again,
record
number
of
people
working
on
record
number
of
caps,
which
is
great.
We
now
more
looking
more
at
the
reliability
and
requiring
end-to-end
tests
and
early
stages.
D
It
allowed
us
to
cut
to
catch
some
issues
on
caps
that
wasn't
merged,
which
is
great
because
we
didn't,
we
don't
want
to
ship
something
that
is
not
working
and
create
a
better
impression
about
alpha
feature.
Also,
we
realized
that
all
small
caps
were
very
smoothly
merged
into
release
and
no
issues
on
the
road.
So
it's
it's
all
great.
D
Some
things
we
plan
to
improve
is
we
will
define
a
soft
early
deadline
for
pr
draft
that
will
allow
us
to
first
confirm
that
pr
like
that
cap
is
actually
on
track
for
release,
and
it
also
will
allow
us
to
request
early
api
review
this
release.
We
realize
that
api
review
is
a
bottleneck
for
us
too
many
caps
were
trying
to
merge
at
the
same
time
and
the
api
reviewers
just
don't
have
enough
bandwidth
to
satisfy
and
review
everything,
and
then
we
don't
have
time
to
react
on
this
reviews.
D
Plus
pr
process
is,
can
find
a
lot
of
issues.
We
just
started
using
pr,
and
we
realized
that
pr
may
early
discussions
in
pr
pr
stands
for
production
agency
review
by
the
way
can
find
a
lot
of
issues
that
will
enable
smoother
implementation
of
a
feature
anyway
great
release,
and
now
we
work
on
123
23
release
in
123.
D
It's
partly
handled
by
sikh,
instrumentation
and
mostly
handled
by
sig
instrumentation.
I
would
say
that
elan
is
the
chair
of,
but
at
the
same
time
we
in
signal
also
need
to
make
some
core
investments
in
and
core
features
to
enable
advanced
knowledge
that
are
outside
of
sequence,
limitation,
scope,.
B
C
D
D
I
think
containing
acid
fire
is
something
that
long
calculated,
for
it
will
enable
some
six
storage
related
features
and
improve
some
enable
some
workloads
another
way
that
features
jrpc
pro
support
and
from
intelligent
operations.
I
really
excited
about
in
play
spot
update.
This
is
this
is
something
that
was
discussed
for
a
long
time.
You
can
see
by
the
number
of
a
cap.
It's
like
1000,
less
than
everything
else
it
it
is.
D
D
C
Yeah
thanks
sergey,
so
it's
really
important
for
signo
to
be
able
to
pay
down
technical
debt
as
we
accumulate
it
over
time
and
so
to
give
you
a
little
bit
of
context
in
the
122
release
cycle,
we
went
and
did
some
pretty
substantial
refactoring
of
the
pod
life
cycle.
So
to
understand
that
refactoring
I
first
want
to
give
a
very
quick
overview
of
the
cubelet
as
part
of
our
sig
node
introduction.
B
C
C
C
So
the
the
core
design
has
remained
the
same
over
time
and
you
can
see
here
in
the
middle,
the
various
pod
workers
that
the
cubelet
spawns
in
order
to
manage
various
pods
and
pot
changes
so
pod
life
cycle
refactor.
Why
did
we
need
to
do
this?
Well,
so
initially
we
found
a
bug
wherein
pods
can
set
on
the
pod
specification,
their
termination
grace
period
seconds
to
zero.
C
C
So
we
went
to
submit
a
patch
to
fix
that
and
we
found
that
when
this
was
fixed,
we
started
finding
a
number
of
flakes
in
the
end
and
tests,
as
well
as
some
failures,
because
those
were
relying
on
this
undefined
behavior
and
so
in
order
for
everything
to
coordinate.
Without
this
forced
deletion,
it
was
no
longer
lining
up
as
far
as
the
timing
and
our
end
and
tests
go.
C
C
So,
while
fixing
this,
we
have
a
pretty
substantial
test
suite
in
kubernetes
and
we
started
uncovering
some
occasional
flakes
as
well,
which
led
us
to
find
more
rare
bugs.
So,
for
example,
we
might
encounter
a
rare
race
condition
on
pod
startup,
where
there's
a
cached
container
status
and
the
cubelet
thinks.
Oh,
there
are
zero
running
containers
which
is
not
correct
in
some
cases.
C
C
That
could
cause
a
rear
correctness
issues
as
well.
Some
loops
had
confused
whether
a
pod
was
terminating
or
already
terminated
and
as
a
result,
if
one
for
example,
assumed
that
a
pod
was
terminated
while
it
was
in
the
process
of
terminating,
then
these
components
could
race
with
each
other,
because
the
pod
wasn't
completely
torn
down.
C
What
did
we
learn
about
this?
What
went
well
well,
we
fixed
a
lot
of
these,
like
subtle,
really
difficult
to
reproduce
difficult
to
debug
bugs
by
going
back
and
fixing
this
code
and
as
well.
We
found
that
the
test
suite
worked
out
really
well,
it
caught
a
bunch
of
bugs
before
we
went
to
release,
and
so
we
were
able
to
fix
a
number
of
issues
that
might
have
been
sent
out
and
released
before.
B
C
C
C
D
Thank
you,
elana,
yes,
see.
I
support.
Some
group
was
originally
formed
as
a
reaction
on
one
release
where
many
released
blocking
tests
were
failing
and
nobody
were
around
to
fix
this
release
blocking
tests.
So
the
reaction
of
that
we
form
the
subgroup,
but
now
it's
way
more
than
just
reactionary
subgroup
to
fix
some
release
blocking
issues
we
actually
converted
into
reliability
group.
D
D
Last
half
year
we
switched
a
lot
from
being
reactionary
to
issues
that
emerging
and
ongoing
issues
that
just
uncovered
by
our
ci
with
a
new
check-in
so
like
with
the
transaction
change,
and
we
moved
more
proactive
mode
where
we
practically
cleaning
up
test
structures.
We
adding
tests
we're
requiring
tests
from
new
caps
and
doing
all
these
great
activities.
We
also
start
looking
into
reliability
more
and
realize
that
to
be
even
more
proactive,
you
need
to
start
looking
into
incoming
bugs
and
for
that
we
want
to
get
into
bhaktis.
C
Yeah,
absolutely
let
me
talk
about
bug
triage,
so
next
slide,
please!
Oh,
I
missed
the
one
before
this.
Yes,
here
we
go
so
sig
note,
sig
node
has
one
of
the
largest
workloads
in
the
entire
kubernetes
project.
I
believe
we're
around
the
third
largest
sig
by
absolute
workload,
and
so
that
means
in
a
given
week
we
have
over
200
average
open
prs.
C
We
tend
to
merge
in
a
given
week
anywhere
between
20
to
adpr's,
both
merged
and
closed,
and
over
the
past
year
we've
seen
contributors
from
nearly
50
countries,
companies
and
many
countries,
probably
more
than
that,
making
contributions
to
cigno'd.
So
your
help
is
needed.
We've
got
a
lot
of
work
to
do,
and
so
how
do
we
manage
such
a
large
workload?
C
Well,
we
focus
on
ensuring
that
we
have
efficient
processes
that
will
allow
anybody
to
be
able
to
jump
in
and
work
through
a
bunch
of
the
stuff
on
our
backlog.
So
in
121
and
122
we
focused
on
pull
requests
where
we
added
github
project
boards
for
tracking
the
lifecycle
of
prs
both
for
the
wider
sig
and
also
focused
on
ci
signal
and
testing.
C
So
that's
focused
on
pull
requests
well
in
the
122
release.
We
wanted
to
start
doing
a
better
job
at
tracking
bugs
because
we
had
when
we
started
a
particular
bug
scrub
event
over
450
bugs
on
our
backlog.
So
I
organized
a
very
large
scale,
global
event
where
we
tracked
three
different
regions,
all
working
together
for
48
hours.
We
had
over
90
attendees
in
our
slack
channel,
where
we
all
met
virtually.
C
C
B
Going
forward
great
ways
to
get
started
beyond
where
alana
and
sergey
have
talked
about
today
is
just
helping
improve
code,
documentation,
enhancing
the
actual
logging
and
metrics
reported
by
our
components
and
helping
us
generally
keep
up
with
the
workload
of
the
mistake.
So
we
go
to
the
next
slide
how
to
join
so.
The
first
step
was
participating
in
this
presentation.
Hopefully
you
saw
where
we're
happy
fun
people
to
to
talk
to,
and
so
we
welcome
you
to
join
one
of
our
regular
sig
meetings.
B
So
we
have
a
primary
meeting
where
we
cover
ongoing
features
caps,
maybe
broader
design
topics,
as
well
as
the
ci
triage
meetings
that
ilana
and
sergey
talked
about
earlier
and
critically,
as
the
sig
is
constructing
new
features
and
evolving
the
platform.
Please
give
early
feedback
for
your
own
real-world
environments,
so
we
can
inform
our
future
directions.
B
Finally,
for
the
next
slide
you
can
reach
out
to
us
by
joining
the
sig
meetings
linked
here,
as
well
as
join
our
slack
channel
reach
out
and
ask
questions,
send
a
note
to
our
mailing
list
and
reach
out
to
both
the
sig
chairs
and
the
sub
project
leads
and
we'd.
Be
happy
to
assist
so
thanks
again
for
everyone.