►
From YouTube: Kubernetes SIG Node Intro And Deep Dive - Sergey Kanzhelev & Dawn Chen, Google; Derek Carr, Red Hat
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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 - Sergey Kanzhelev & Dawn Chen, Google; Derek Carr, Red Hat
Speakers: Dawn Chen, Derek Carr, Sergey Kanzhelev
These are exciting times for Kubernetes SIG Node. Many deprecation and graduations happened and many new initiatives are starting now. Come to our maintainers track session to learn about the recent releases of Kubernetes, full of exciting improvements and get a glance into the SIG Node roadmap. 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! We will talk more about cgroup v2 adoption and exciting opportunities it brings, how we invest in small quality of life improvements and working on new exciting big features. Join this session to learn more about our SIG, and how you might get involved to make Node even better!
A
Hello:
everyone
welcome
to
the
2028
news.
Cubican
North
America
here
is
the
signaled
intro
and
the
Deep
dive
talk.
My
name
is
Don
Chen
I
am
a
software
engineer
from
Google
and
the
current
working
on
gke
and
answers.
I
am
one
of
the
funding
Engineers
for
kubernetes
and
initiate
the
signals
back
in
2016,
together
with
Derek
Derek.
B
A
Before
we
get
into
today's
agenda,
I
want
to
briefly
means
in
the
previous
signaled
update
we
made
at
the
coupon
Europe
earlier
this
year.
We
you
can
access
related,
slides
records
by
clinking
clicking.
Those
links
here
is
the
today's
agenda
and
we
are
going
to
first
recap
Signal's
responsibility.
Then
we
are
going
to
talk
about
the
current
activities
since
the
last
update
the
load
might
perform
the
1.25
to
1.6
and
VR.
Then
some
of
interesting
projects
and
the
efforts
currently
driving
by
signaled
SQL
version
2
in
place,
the
Pod
recessing
event
pled.
A
After
that,
we
are
briefly
introduced
several
new
sub-projects
initiated
by
signaled
since
last
update
kernel
modules,
Dynamic
resource
management
and
the
batch
group
participants,
then
circuit
will
update
us
with
CI
project,
which
is
the
highest
priority
in
our
community.
Finally,
we
are
going
to
talk
about
how
to
get
involved
with
and
how
to
get
help
from
the
community.
A
What
is
the
signal
and
its
responsibility?
Let's
briefly
talk
about
the
node
responsibility
in
kubernetes.
Kubernetes
is
a
cluster
or
transition
solution
for
containerized
applications
and
services,
including
kubernetes
controllers
running
on
the
nodes
on
each
node.
There
is
an
agent
called
kubernetes
kubernetes
register
node
to
the
cube
kubernetes
control
plane
kubernetes,
together
with
the
container
runtime,
manages
part
and
containers
life
cycle
and
doing
the
doing
the
setup
run.
Tear
down
and
the
cutting
up
kubernetes
also
does
the
node
level
resource
management,
such
as
ensure
of
the
services,
get
the
request.
A
Resources
detects
the
node
91
resource
establishing
issues
and
take
actions
to
prevent
out
of
resources.
Situation
kubernetes
also
send
the
status
back
to
the
control
plan.
I,
always
concubinated.
The
bring
of
the
node
in
summary,
signaled
owns
all
controllers
running
on
the
nodes
which
ensure
the
node
itself
and
applications
running
happily,
signal
is
very
large
and
on
many
projects
you
can
click
the
link
here
to
find
them
all.
C
Recently,
starting
120,
we've
been
focusing
on
elimination,
permanent
betas,
permanent
bait
is
a
feature
that
enters
beta
stage.
We
start
collecting
feedback
and
accumulated
many
customers
and
many
usage
of
the
feature,
but
never
made
it
official
GA
and
to
create
some
confusion
among
customers
and
generic
bad
for
software.
So
we
deliberately
try
to
eliminate
betas
as
well,
as
did
other
major
duplications
like
Docker
shim
removal.
C
We've
been
doing
a
lot,
we
removed
and
G8
features,
and
we
graduated
very
small
features
that
been
used
already,
but
whenever
I
had
time
to
be
officially
called
ga,
but
the
work
is
not
complete.
Yet
we
still
have
a
few
feature
Gates
and
features
still
in
beta.
They
go
all
the
way
to
back
to
one
four
of
kubernetes
we're
working
on
eliminating
this
as
well.
C
We
also
have
very
old
features
that
are
long
in
beta
are
like
CPU
manager,
but
for
this
kind
of
features
we
have
actively.
We
are
actually
working
on
new
policies
and
collection
feedback
to
make
sure
that
this
feature
is
done
right.
So,
even
though
it's
beta
for
a
long
time,
we
actually
working
on
it.
That's
why
it's
still
in
this
status
and
not
graduation
to
GA.
Yet
after
that,
we
even
with
this
focus
on
eliminating
permanent
betas,
we're
still
working
on
new
features.
Thousand
brand
new
sounds
I'm,
just
updating
Alpha
to
Beta.
B
Thanks,
okay,
so
in
in
125
we
graduated
a
number
of
features
that
were
in
development
to
stable
or
generally
available
status.
So
what
this
meant
was
that
the
feature
was
well
tested,
well
understood
and
documented
and
offers
a
backward
compatibility
guarantee
going
forward.
Two
I'll
highlight
here
that
I
think
are
particularly
interesting.
Are
those
issues
numbers
that
are
low?
Kubernetes
has
been
a
project
for
a
very
long
time
and
some
features
take
a
long
time
for
us
to
mature
and
bring
to
stable.
A
thermal
containers
is
a
good
example
of
that.
B
You
have
a
feature
that
is
changing
the
life
cycle
of
a
pod
and
how
we
run
containers
in
those
pots.
So
it's
really
good
to
see
that
feature
go
to
stable
and
125
and
start
to
close
out
these
very
early
issue
numbers
in
this
case
277.
other
features
of
Note
here,
thermal
storage
capacity
isolation.
So
you
can
schedule
on
node
local
storage
that
graduated
to
stable,
C
group
C2,
which
we'll
discuss
in
a
little
more
detail
later,
is
also
stable.
So
we
can
better
support
a
newer,
more
modern
Linux
distributions.
B
An
example
of
a
use
case
that
was
removed
from
the
cubelet
was
the
ability
for
the
cable
to
advertise
particular
GPU
accelerator
usage
match.
This
has
now
been
offloaded
to
individual
GPU
device,
plugins
and
vendors
and
then,
lastly,
a
feature
that
went
to
stable.
That
I
really
appreciate
is
now
you
can
identify
the
the
operating
system
that
is
required
by
a
pod.
So
if
you're
running
Windows
nodes
or
Linux
nodes,
you
can
actually
look
at
the
Pod
now
and
know
this
should
land
on
a
Linux,
node
or
a
Windows.
A
B
A
very
helpful
feature:
next
slide:
we
had
fewer
features
graduate
to
Beta.
The
one
of
note
here
was
enabling
SEC
comp
by
default.
This
has
been
long
explored,
and
so
it
was
good
to
see
that
this
feature
continues
to
make
a
progress.
One
note
I'll
make
about
beta
Concepts
going
forward.
Is
it
used
to
be
beta?
Features
were
on
by
default.
B
There
has
been
a
posture
change
in
the
project
to
make
beta
features
off
by
default,
so
keep
that
in
mind
for
future
beta
graduations
and
then
last
Sergey
noted
We
are
continuing
to
explore
new
new
features,
so
things
that
are
alpha
typically
mean
that
they
might
not
be
as
richly
tested
they're
definitely
off
by
default.
The
problem
space
they
explore
are
complicated
and
often
need
more
time
to
mature.
The
one
issue
I
will
highlight
here
is
a
username
space
support
which
you
can
see
at
a
very
early
issue.
B
Number
of
127
username
spaces
has
been
a
complicated
topic
to
talk
about
throughout
kubernetes,
and
the
problem
space
is
large
as
particularly
as
it
intersects
with
storage.
We
chose
to
make
some
forward
progress
in
the
space
to
try
to
facilitate
username
space
support
for
stateless
pods
and
it'll
be
interesting
to
see
that
that
feature
continue
to
evolve
going
forward.
B
B
Ahead
to
126
and
onward,
we
are
hoping
to
continue
to
make
progress
on
better
resource
sizing
of
PODS,
particularly
allowing
you
to
Resource
update
resource
requirements
in
place
for
things
like
CPU
and
memory,
always
in
signode
we're
trying
to
bring
down
the
management
overhead
of
supporting
your
node.
So
you
have
more
resources
available
for
your
workloads
to
that
effort.
You'll
hear
in
this
discussion
more
detail
on
an
effort,
we're
calling
the
event
to
plug,
and
then
security
is
a
concern,
obviously
in
the
kubernetes
community
broadly
into
our
users.
B
So
areas
of
improving
the
ability
to
better
integrate
with
secured
image
sources
is
important
and
you'll
see
work
in
that
space
and
then.
Finally,
as
we
look
to
support
the
evolving
environment,
we
are
trying
to
explore
possible
prudent
evolutions
of
both
the
Pod
life
cycle
and
resource
plugins
that
pods
might
consume
going
forward.
You'll
hear
more
details
on
those
in
this
presentation.
B
So,
let's
dive
a
little
bit
on
C
group
C2.
We
talked
about
this
a
little
bit
in
the
last
signode
update,
but
I
think
it's
important
to
emphasize
now
that
it
went
stable
because
it
will
likely
get
more
production
usage.
So,
as
you
go
to
the
next
slide,
just
to
level
set
and
remind
folks
c
groups,
V1
and
V2
have
had
feature
parity
support
since
kubernetes
1.24.,
but
many
Linux
distributions
or
many
environments
where
users
were
running
workloads
in
production.
B
We're
still
only
using
C
group
C1
and
V2
support
is
still
something
that
we
are
anticipating
feedback
on
in
the
years
ahead.
We
are
not
actively
deprecating
secret
V1
support,
just
because
we
added
V2
support.
We
will
tolerate
both
C
group
controllers
for
an
extended
period
of
time,
except,
as
we
add
new
Resource
Management
features
into
signotes
domain.
B
We
will
likely
only
do
new
resource
controllers
on
V2
if
you
are
exploring
Linux
hosts,
whether
that's
a
newer,
Fedora,
Ubuntu
cos
or
distros,
it's
very
possible
that
those
districts
Now
default
to
boot
into
secrecy2,
and
so
it
would
be
great
now
that
the
cubelet
can
work
in
a
stable
base
on
that
platform.
So
you
definitely
be
aware,
as
you're
exploring
this
feature,
there's
not
a
unique
knob
to
turn
on
it.
Kind
of
is
self-identified
based
on
how
you
configured
your
operating
system
for
new
features
in
the
space
that
we're
excited
about.
B
B
Sometimes
you
might
need
to
update
those
runtimes
in
order
to
take
to
have
awareness
of
a
c
groups
V2
host,
so,
for
example,
on
golang
you
might
need
to
manually
set,
go
Max
prox
or,
if
you're,
using
older
jdks.
You
might
need
to
update
to
have
your
jdk
be
aware
of
a
V2
environment,
so
for
those
who
are
starting
to
explore
this
and
want
to
give
production
feedback
or
areas
for
improvement.
Please
reach
out
to
the
signal
community
and
we're
excited
to
continue
to
see
this
be
successful.
Next
slide
don.
A
Thanks
Derek
I'm,
going
to
talk
about
the
ongoing
feature
In-Place
product
resizing
before
we
get
into
the
detail.
I
want
to
quickly
summarize
the
auto
scaling
features
offered
by
the
kubernetes
today.
The
horizontal
Part,
auto
scanner
automatically
adds
the
remove,
Acts
or
removes
part
based
on
the
usage
rate
of
your
application.
A
This
is
great
of
the
hand
done
in
more
requests
when
you
have
the
enough
space
to
run
more
parts
on,
but
if
there's
no
space
to
run
additional
Parts,
even
if
the
parental
part
of
the
skin
wants
to
add
more
out
of
luck,
unless
you
are
using
cluster
auto
scanner,
what
class
the
autostyle
does
it
is.
It
adds
more
resources
to
your
clusters
in
these
cases,
more
machines,
more
nodes
that
post
camera.
A
Those
two
features
together
addresses
skill,
art
issues,
but
in
many
cases
the
application
would
run
out
of
the
memory
and
a
heavy
load
and
there
it
wasn't
a
real
good
way
to
estimate
how
much
memory
was
needed
at
any.
Given
time
vertical
part
of
the
auto
scanner
helps
modify
the
resource
provisioned
to
an
individual
services
like
if
a
part
doesn't
have
enough
CPO
or
if
has
too
much
of
the
memory
vertical
part
of
the
skin
that
exists
to
automatically
set
up-to-date
resource
limits
and
requests
for
the
containers
in
in
their
parts.
A
It
can
boast
down
skill
parts
that
are
over
requesting
resources
and
also
upskill
parts
that
are
end
requesting
resources
based
on
their
usage
over
time.
So
far,
everything
works
great,
except
vertical
powder
scanner,
app
power,
CPU
or
memory
resources
that
require
part
of
these
stats.
This
is
super
disruptive
to
the
services
and
the
expensive
for
long-running
applications.
A
A
the
project
was
actively
designed
and
implemented
until
2018.
By
relay
last
four
years,
we
lay,
together
with
the
community,
have
iterated
and
evolved
the
design
and
implementation
several
times
along
with
several
new
Resource
Management
features
huge
pity,
swap
SQL,
World,
2
and
so
on.
Finally,
we
are
ready
to
release
the
Alpha
version
in
Wednesday
26.
A
C
I
want
to
talk
about
invented
plaque
as
a
one
of
the
highlight
of
this
release.
We
plug
or
Port
lifecycle
event
generator
is,
was
an
improvement
over
the
way.
How
cubot
knows
about
container
events,
it
was
improvement
over
every
port
controller
was
creating
its
container
statuses
itself.
It
was
very
racy
like
we
need
to
talk
about
parallelism
and
like
who.
How
many
requests
container
time
needs
to
handle
for
life
cycle
event.
Generator
was,
is
a
single
thread
kind
of
I
releasing
of
all
the
containers
on
a
node.
C
It
asks
the
status
of
this
of
all
the
containers
and
then
make
updates
on
its
own
and
the
same.
What
containers
doing
based
on
this
status,
for
instance,
if
if
it
knows
that
container
was
running
and
now
it's
not
running,
then
Google
may
decide
whether
this
container
needs
to
be
restarted,
or
something
else
needs
to
happen
with
this
container.
C
What
this
is
working
very
good,
we
bought
lifecycle
event.
Generator
works
great
on
existing
environments.
It's
simple
implementation
is
very
straightforward.
It
guarantees
consistency
because
all
the
time
we
just
take
all
the
containers
information,
we
don't
rely
on
continue,
runtime
being
able
to
generate
events
for
us
and
performance
is
acceptable.
Open
source
kubernetes
only
supports
up
to
like
100
something
Imports
and
some
environments
support
a
little
bit
like
I
mean
two
times
more,
but
in
general
it's
very
it's.
C
Okay,
like
performance,
Wise,
It's,
okay,
but
we
started
with
even
more
requirements.
We
have
environments
with
many
ports
and
every
port
has
many
containers.
We
have
high
availability
requirements
for
workload
and
some
workload
was
much
faster
failure,
detection
that
you
can
provide
with
any
listing.
Also,
we
have
more
questions
about
low
overhead
environments
like
Edge
devices,
where
even
releasing
takes
a
lot
of
other
head
and
needs
to
be
eliminated
or
done
way
way.
Less
often
so
flag
V2
will
be
streaming
based.
C
We
will
rely
on
container
runtime
to
give
us
information
when
something
happens
instead
of
us
asking
constantly
if
anything
changed.
So
this
is
supposed
to
be.
This
should
be
a
very
good
improved.
It
will
help
a
lot
and
we
hope
that
you
will
install
a
new
version
of
kubernetes
and
you'll
get
free,
CPU
Cycles
out
of
it
just
because
we
made
some
internal
improvements.
C
So
again,
we've
been
talking
about
a
126
remote
map
and
we've
been
asking
feedback
for
one
GA
feature
one
alpha
feature
and
give
you
either
like
a
highlight
of
internal
improvements,
we're
making
with
things
like
event,
invented
plaque.
Now
we
want
to
talk
about
new
projects
and
new
sub
projects
that
we're
running
and
we'll
start
with
Derek.
B
Yeah
so
one
of
the
new
sub
projects
that
cignode
has
formed,
since
our
last
update
was
around
improvements
to
support
kernel,
module
management
on
kubernetes
platforms
for
those
who
are
interested
in
exploring
this
space
you'll
see,
there's
a
new
repository
in
the
carinae
6
GitHub
organization,
where
approaches
to
Kernel
module
Management
on
covering
nodes
are
being
explored.
This
is
a
area
of
interest
for
you,
please
reach
out
to
contributors
in
repository
and
help
make
the
solution
broadly
available
for
the
community
as
a
whole.
A
Dynamic
resource
allocation
is
another
non-desired
feature,
while
kubernetes
adopted
by
the
industry
as
the
standard
standard,
container
or
transition.
We
are
seeing
the
increasing
leads
to
better
support,
non-native,
Computer,
Resources
and
kubernetes,
which
is
covered
on
wide
range
of
the
resources
such
as
the
gpus,
high
performance,
leaks,
infinite
events
and
so
on,
and
such
resources
often
require
vendor
specific
setup
and
they
have
a
rich
set
of
the
different
properties
even
across
devices
of
the
same
type.
A
This
is
to
bring
on
new
requirements
to
the
kubernetes
signaled
proposed
the
initial
design
back
in
2018
and
a
better
deal
and
proud
has
the
implementation
due
to
the
complexity
and
the
overhead
and
in
Metro,
and
also
the
dependencies.
So
the
new
design
is
proposed
with
the
narrow
down
scope.
Now
it
is,
it
was
approved
for
1.25,
and
hopefully
we
can
have
the
alpha
implementation
for
the
one
that
26,
but
we
we
want.
We
call
out
of
this
feature
today,
because
we
want
to
get
the
community's
attention.
C
Next
I
want
to
talk
about
Budget
Group
participation
of
our
seek
batch
work
group
was
formed
very
recently,
as
a
response
for
which
has
been
not
ideal
environment
for
running
batch
workloads,
many
jobs.
We
have
many
problems
with
job
scheduling
and
ways
to
control
job
execution
around
kubernetes.
There
are
many
third-party
vendors
who
is
who
providing
ways
to
run
jobs
on
kubernetes,
but
all
the
solutions
are
quite
hacky
and
they
require
some
changes
in
core
of
kubernetes,
and
this
is
what
we're
doing
specifically
from
signal
perspective.
C
We
concentrate
on
caps
like
retrievable
non-retrievable
job
exit
codes,
so
we
will
be
able
to
be
more
granular
which
jobs
needs
to
be
retried
and
which
jobs
fail
forever,
and
we
don't
want
to
waste
resources
on
that,
as
well
as
some
life
cycle
controls
like
Keystone
containers
here
that
we
discussed
and
that
will
help
with
scheduling
jobs
with
sidecar
containers
and
such
plus
jobs
are
very
resource
intensive.
Typically,
they
don't
have
any
weight
expecting
some
users,
they
just
doing
a
lot
of
calculations.
C
That's
why
we
need
to
be
as
as
much
resource
aware
as
possible
and
other
scheduling
improvements
and
the
device
plugins
improvements.
It
all
helps
with
much
work
group
and
with
job
execution
and
all
that
all
the
sub
projects
are
only
possible
when
we
keep
our
signaled
are
stable
and
all
the
code
reliable.
We
keep
running
the
CI
War
group.
C
It
was
formed
two
years
back
and
we
keep
running
it
since
we
did
a
lot
of
good
progress,
so
we
had
very
successful
releases
recently
and
we
keep
improving
some
old,
failing
tabs
and
task
grid,
so
we
recently
improved
npg
test
grid
that
was
failing
for
a
long
time
and
nobody
paid
too
much
option.
We
finally
get
our
hands
to
it
and
it
was
fixed
as
well
as
some
other
improvements.
We're
running
more
environments
like
cryo
was
added
to
be
tested
regularly
and
now
it's
most
of
the
time
green.
C
So
we're
doing
a
lot
of
work.
We
get
some
regression
over
summer
time
because
less
people
will
participating,
but
now
we
hope
that
this
work
will
be
resumed
and
we
will
do
more
work
on
test
classification.
So
we
know
which
test
needs
to
be
looked
urgently
and
which
test
can
be
a
little
bit
less
urgently,
plus
doing
more
permutation
of
which
test
to
run
and
when
we
are
tracking
our
work
in
GitHub
project.
During
our
meeting,
this
board
is
publicly
available.
C
If
you
want
to
contribute-
and
you
don't
know
where
to
start,
you
can
always
pick
up
work
from
this
board.
We
also
proactively
controlling
reliability,
signal
by
three
action
box
of
a
signaled
and
again,
if
you're
interested,
which
issues
customer
experience
with
kubernetes
and
specifically
we
see
you
can
join.
This
meeting
can
hear
discussions.
We
have
on
back
dash
for
all
the
signaled
bugs
and,
as
I
said,
there
are
many
issues
and
we
need
to
get
you
involved
done.
A
Thanks
Sergey,
there
are
many
of
the
things
going
on.
Increasing
of
the
signals
by
far
signal
is
the
third
largest
of
the
community.
We
think
kubernetes
and
also
you
can
see
that
from
here
and
also
introduce
the
better
circuit
previously.
So
we
have
so
many
goals
going
on
and
the
signaled
by
the
workload
they
have
the
200
plus
of
the
average
open
PR
per
weeks.
We
also
merge
28
to
30ps
every
week
and
close
every
week.
A
We
also
have
the
developer
and
the
contributor
from
all
over
the
world
and
from
more
than
39
companies
dedicated
to
work
for
the
improve
of
the
signals,
and
we
really
need
more
people
more
contribution
from
from
you
from
the
community
so
how
to
contribute
and
here's
the
RC
node
agreed
priority.
First
thing:
we
are
really
King
on
the
stability
and
the
sustainability.
So
there's
the
effort
for
the
CI
project,
which
is
Sergey
just
mentioned
earlier,
and
we
tried
the
issues
and
those
meeting.
It
is
holder
every
Wednesday.
Please
join
like
the
effort.
A
If
you
want
to
help
on
the
signals
and
get
to
start.
That
is
the
first
thing
you
can
involve
and
we
also
started
to
focus
on
optimization
and
reduce
of
the
management
overhead
and
make
all
those
more
efficient
and
the
third
one.
It
is,
there's
more
features.
There's
the
there's,
some
like
new
sub-project
initiatives,
there's
also
ongoing
features
and
The
Graduate
the
alpha
feature
to
better
than
to
the
ga.
So
there
are
many
things
going
on
the
and
also
to
help
of
the
user.
A
As
a
developer,
we
have
another
of
documentation
and
user
guide
as
a
developer
guide.
We
need,
we
need
to
put
put
the
effort
in
and
so
welcome,
to
contribute
and
get
get
involved
and
contribute
for
all
those
items
and
the
categories
how
to
contribute
and
also
how
to
get
help.
If
you
have
UI
as
a
user,
you
can
attend
RC
meetings.
We
have
the
two
secret
meetings
to
sofa
regulating
hold
when
it
is
the
regular
signal
meeting
every
Tuesday,
which
is
current
features,
caps,
designs,
even
issues.
A
We
also
have
the
every
Wednesday
have
the
CI
and
the
traged
meeting,
which
is
the
smaller
but
and
which
is
goes
to
all
those
user
issue
specs
and
test
figures.
Then
you
also
can
join
our
our
slack
Channel
and
ask
a
question
and
and
also
write
a
proposal
and
the
file,
the
Box
issues
to
us
the
place
reach
out
to
us,
and
we
also
have
the
secret
note
the
main
list
you
can
send
off
the
suggestions
and
the
feedback
directly
to
us.