►
From YouTube: Kubernetes SIG Node 20230905
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20230905-170609_Recording_1920x1096.mp4
A
Hello,
hello,
it's
September,
5th
2023.
It's
a
signaled
weekly
meeting.
Welcome
everybody
I
have
few
item
on
agenda.
Let's
jump
right
into
it.
Parker
are
you
here
for
the
first
item.
B
B
This
issue
we
have
discussed
in
the
issue,
and
currently
we
think
this
is
a
future
request
and
for
Contender
level
CPU
static
policy
design.
The
current
design
is
only
about
guaranteed
the
pod,
but
in
this
case,
if
you,
if
the
set
car
or
the
other
containers
in
the
Pod
is
not
guaranteed,
but
one
of
the
container
is
guaranteed
and
with
the
integer
CPU
limit
and
request,
should
we
do
the
same
thing
for
those
containers.
B
Is
to
add
a
new
CPU
stack
CPU
policy
like
a
contender
level,
static.
D
I
just
want
to
jump
in
for
a
little
bit.
Actually
Francesco
and
I
were
commenting
on
the
this
issue
and
I.
Think
one
thing
we
can
definitely
evaluate
is
either
a
policy
or
policy
option
for
this,
but
I
would
like
to
understand
why
putting
these
pods
into
separate.
D
Oh
sorry,
splitting
these
containers
into
separate
pods
is
not
an
option
and
I
think
the
other
concern
I
have
is
the
implication
around
guarantees,
because
if
you
have
a
pod
with
a
guaranteed
container
and
a
non-guaranteed
container,
the
guarantee
can,
if
you,
if
you
allocate
exclusive
CPUs
to
a
guaranteed
container,
the
expectation
would
be
that
that
it's
it's
a
workload.
D
That's
you
know
that's
consuming
those
CPUs
and
it's
a
performance,
sensitive
workload
or
something
really
important
that
we
want
to
keep
for
a
long
time,
but
because
this
particular
pod
is
not
going
to
have
guarantee
quality
of
service,
it
could
be
evicted
by
another
pod
that
has
higher
priority.
So
those
are
that
that's
kind
of
the
only
concern
I
have
but
I
think
in
general.
This
could
be
a
useful
feature.
E
I
think
this
also
matches
a
recent
request.
We
got
where,
like
you
have
pod
with
two
different
kind
of
processes.
Ones
are
always
pinned
the
other
ones,
aren't
running
all
the
time,
so
if
they
assign
CPUs
for
the
ones
that
are
running
all
the
time,
we
are
wasting
resources.
So
we
need
a
way
where
you
know
some
are
pink
and
some
processes
aren't
print.
I.
Think
this
kind
of
intersects
that
kind
of
use
case.
D
Yeah,
absolutely
actually
that's
one
of
our
team
members
who's
working
on
that
team.
In
this
case
and
and
the
use
cases
that
you
know,
one
application
is
performed
sensitive
and
the
other
one
is
maybe
logging
or
something
that's
doing
stuff
in
the
background.
So
so
it
makes
sense,
but
like
I
I'm
still
not
able
to
visualize
how
we
we
will
saw
the
overall.
You
know
priority
Problem.
E
E
Maybe
we
keep
the
whole
pod
guaranteed
like
in
the
guaranteed
class,
even
if
a
sidecar
is
not
using
full
CPUs.
That
could
be
one
way.
A
You
mentioned
that
even
worker
pod
can
not
need
the
whole
CPU
reserved.
Yes,.
A
E
Adjust
the
definition,
I
I
think
we
have
a
class
of
PODS
where
you
need
some
things
full
CPUs,
but
then
they
have
helper
processes
that
don't
necessarily
need
full
CPUs.
So
can
guaranteed
definition
be
expanded
to
include
that,
and
we
have
some
way.
Maybe
they
can
be
sidecars
when
they
are
not
using
full
CPUs.
You
still
stay
guaranteed.
E
F
G
E
A
F
Particularly
the
person
why
so
site
also
used,
so
if
you
want
exclusive
CPU
allocation,
usually
it's
a
process
which
is
doing
well
like
a
full
busy
Loop
and
those
processors
are
usually
not
really
happy.
If,
if
something
else
start
to
consume
the
same
CPU
course
so
having
side
cars
on
separate,
probably
shared
CPU
set
is
better
way.
F
A
A
E
A
Yeah,
for
me,
it's
not
one
or
another.
It's
just
do
we
need
options
to
have
a
switch
between
two
behaviors,
so
we
just
need
to
look
on
one
behavior
and
have
it
it's
default,
not
configurable,
because
I
I
feel
that
more
we
discuss
is
your
CPUs
and
sidecars.
More
I
think
that
it
certainly
makes
sense
to
have
them
have
sidecars
by
default.
Have
not
using
the
same
resources.
A
Thank
you
for
bringing
it
in
Kevin.
You
are
next.
H
A
Thank
you,
Ryan.
C
Yeah,
can
you
give
me
share
access.
C
A
C
C
Personal,
okay,
good,
okay,
so
normal
pod
termination
usually
sends
a
30-second
grace
period
for
to
terminate
upon,
and
if
the
Pod
spec
sets
a
graceful
termination
period
seconds,
then
that
termination
and
grace
period
is
honored
during
Pawn
termination,
and
so
the
cubelet
comes
around
sees
that
a
pawn
needs
to
be
terminated
since
the
initial
Sig
term
to
the
pod,
Waits,
For,
That
termination
and
if
the
Pod
hasn't
exited.
C
Yet
since
the
sick
kill,
that's
the
normal
life
cycle
for
a
pod
with
graceful
shutdown,
we
intend
the
Pod
to
be
gracefully
terminated
and
we
want
static.
Pods
demon
sets
replica
sets
on
this
node
shutdown
via
the
system.
D
signal
to
gracefully
terminate
the
Pod
I
included
a
link
to
the
documentation
there
for
everyone
who
doesn't
know
about
it.
C
C
C
Openshift
specifically
runs
CI
with
all
of
its
configuration
in
place,
and
so
we
would
like
to
set
the
notes,
great
node,
graceful
shutdown
to
an
hour,
but
then
have
the
Pod
gracefully
terminate
correctly
and
Upstream.
Ci
is
not
running
the
end-to-end
test
with
graceful
shutdown
on,
and
so
the
test,
pods,
brain
and
CI
would
wait
an
hour
to
terminate
and
so
we're
getting
timeouts
on
the
CI
side
of
things
on
doing
the
end-to-end
tests.
C
When,
arguably,
we
probably
should
not-
and
so
I
proposed
a
fix
here
in
this
PR-
that
we
do
send
a
30
second
shutdown
sequence
to
the
pod.
C
This
would
allow
pods
to
do
their
normal
shutdown
sequence
and
in
the
worst
case,
we
set
the
graceful
termination
to
the
group's
shut
down
grace
period
seconds.
C
This
means
that
the
configuration
configuration
items
that
we
have
for
a
graceful
shutdown
if
they
were
set
to
an
hour,
the
Pod
would
terminate
in
either
30
seconds
or
if
the
termination
grace
period
was
set
on
the
Pod,
it
would
wait
that
period
of
time
or
in
the
worst
of
cases.
It
would
wait
for
the
entire
hour
to
to
terminate
that
pod
and
finish
its
reboot,
and
so
this
sort
of
is
different
than
how
the
feature
was
originally
conceived.
I
think
but
I
believe
it's
correct
for
how
we
should
go
forward
with
it.
C
I'd
like
to
see
this
PR
go
in
and
I
think
we
need
to
improve
the
end-to-end
test.
Excuse
me
in
Upstream
kubernetes
to
enable
graceful
shutdown
so
that
we
can
test
end
to
end
with
it
as
well.
C
Go
ahead.
Yeah.
E
I
Yeah
yeah
I
just
wanted
to
mention
I.
Think,
first
of
all,
thank
you
so
much
for
for
putting
together
the
presentation
and
all
the
info
I
think
it's
super
helpful,
yeah
I
think
when
we
conceived
the
feature
we
were
probably
looking
and
kind
of
anticipating
use
cases
with
much
shorter
Grace
periods.
You
know
like
30
SEC,
like
shutdown
periods.
A
I
I
What
type
of
value
should
you
set
right
and
I
guess,
there's
two
options:
there
you
either
use
the
maximum
sign,
which
is
sounds
like
what
we
do
today
or
you
just
use
30
seconds,
because
it's
the
defaults
for
regular
termination,
so
I
think
that
makes
sense.
I
think,
like
the
maybe
counter
arguments
you're
using
the
longer
one
is
like.
Maybe
you
would
expect
the
application
to
be
well
behaved
and
exit
early,
but
I,
guess
you
can't?
I
You
know
it's
application
specific,
so
overall,
yeah
I'm,
definitely
supportive
I!
Think
of
using
the
30
seconds
if
it
doesn't
specify
anything.
It
sounds
like
the
right.
The
right
call
to
align
with
normal
termination.
C
Okay,
that
sounds
good.
Our
use
cases
that
we
have
some
pods,
that
customers
are
running
for
firmware
updates,
and
so
that's
why
they
need
such
a
long-termination
period.
I.
H
Ryan
thanks
for
the
the
put
this
together.
Actually,
this
is
a
plan
explains
why
I
saw
some
production
issues
and
customer
complaining
to
me
say:
oh,
we
I
only
have
the
batch
jobs,
but
I
afford
that
every
time
when
you're
upgrade
I
have
to
wait
for
one
hour
at
least
especially
for
the
large
cluster,
so
the
upgrade
take
forever
for
to
to
customer
perspective,
I
was
kind
of
I
keep
suggesting
to
using
grease
powder
grease
period
shut
down
period.
H
A
Graceful
determination
or
you've
seen
it
with
some
kind
of
upgrade,
because
I
think
similar
issue
may
happen
in
with
any
drain
scenario,
we're
going
to
be
set
every
right
of
graceful
period.
E
I
C
C
Maybe
somebody
maybe
Peter's
on
the
call
on
knows
for
sure.
If
cryo
doesn't.
H
E
H
Think
cumulate
decided
that
30
seconds
the
kubernator
tried
to
be
a
really
conservative.
So
that's
why
a
lot
of
places
in
the
old
time
even
is
like
the
four
hour,
and
so
then
we
introduced
one
hour
so
30
seconds.
I,
don't
remember
at
all.
G
I
Yeah
the
reason
I'm
asking
I'm
just
curious
because
to
answer
the
other
question:
if
it's
covered
for
drain
scenarios
and
so
forth,
right
I
think
that,
like
depending
where
it's
done
right,
because
all
the
drains
will
probably
go
through
eviction
API,
which
is
on
the
Epi
server
side
right.
So
if
that's
done
there
then
I
would
imagine
the
defaulting
would
also
happen.
But
if
it's
not
it's
roughly
via
Kublai
like
graceful
shutdown,
then
we
don't
have
that
defaulting
rate
so
yeah.
It
would
be
good
to
understand
that.
But
we
can
look
at
that
later.
I
C
Yeah,
thanks
for
the
review,
so
I
will
I
just
wanted
to
bring
this
to
everyone's
attention
and
get
some
reviews
on
the
PRS
and
the
issue.
Thanks
Ryan.
A
C
Yeah
I
can
do
that
and
the
code
here
is
only
in
the
node
shutdown,
well
known,
graceful
shutdown
files,
but
I'll
take
an
action
item
on
the
other
section.
Thank
you.
H
Actually,
there's
the
one
more
topic
rough.
Do
you
want
to
talk
about
that?
Api
things?
I
keep
saw
that
the
item
on
the
signal,
but
never
speak,
scheduled.
J
Oh
yeah,
sorry,
so
just
real
quickly.
We
have
a
new
cap.
That
is
a
follow-up
from
what
we
discussed
last
week
and
this
is
covering
new
API
in
kublet.
That
would
return
pod
information,
specifically
Readiness
information
and
just
a
heads
up
that
it
has
turned
from
a
dock
into
a
cap,
and
we
would
appreciate
any
reviews.
A
A
Yeah
yeah
last
topic
we
have
is
follow
up
on
in
place,
vpa
plus
core
bindings
I'm,
not
sure.
K
Yeah
here
Jackson's
here,
yeah
right
in
the
I
think
two
or
three
weeks
ago.
You
know
our
teammate
linear,
shared
The
Proposal
with
the
community,
and
we
split
the
like
some
problems
into
four
sub
sub
issues
and
for
some
of
them
currently
we
already
created
PR's
and
one
cap,
and
we
are
like
we
will
try
to
like
sync
with
the
community,
follow
up
with
the
community
again
on
the
next
steps.
K
Do
you
think
we
should
have
some
like
owners
from
signal
boost
or
is
just
a
I
think
have
some
other
like
process
or
what's
the
next
steps.
K
E
D
G
K
You
mean
what
kind
of
announcement
so
right
now
we
we
just
like
move
like
the
individual
Sub
sub
issues
into
a
PR
or
cap
I
think
only
one
currently
need
a
cap
and
the
rest
that
we
just
send
out
the
PRS,
and
we
write
the
like
descriptions
in
the
pr
and
the
problem
statement
in
the
pr
as
well.
Do
you
think
we
need
like
additional,
like
kind
of
announcement,
talk
or
something
else?
No.
H
H
H
We
have
tibac
Force
discussing
if
I
remember
correctly,
one
of
those
things
I
do
I
think
in
last
time
we
discussed,
we
did
explain,
there's
the
interesting
on
that
usage
use
cases.
K
K
H
K
Yeah,
okay!
So
since
there's
a
like
kind
of
important
planning
meeting
next
week,
if
I
understand
correctly,
do
you
think
it's
better
for
us
to
participate?
The
discussion.
K
H
K
H
F
H
K
Information:
okay,
no
problem,
so
so
for
the
cap,
one,
we
felt
the
issue
and
the
corresponding
PR.
Or
do
you
think
that's
enough
or
we
need
a
separate,
a
separate
dog.
K
I
guess
right
right,
yeah,
I
I
gave
the
issue
links
in
the
documentation
and
the
visually
have
the
pr
Associated
yeah.
H
A
And
I
placed
the
agenda
item
for
next
item:
Kappa
planning.
So
let's
do
kept
playing
next
week.
I,
don't
think
we
will
have
time
for
many
topics
beyond
the
planning.
E
A
Yeah,
if
you
own
a
cap-
and
you
have
a
PR
to
update
it
to
129
or
anything
like
that,
try
to
think
on
a
slug,
so
we
can
try.
We
like
it
will
be
best
to
have
a
lot
of
things
cleaned
up
before
the
meeting,
so
we
will
go
faster
if
you
own
something,
please
send
APR
early,
so
we
can
Target
it
for
release.