►
From YouTube: Kubernetes SIG Node 20220823
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20220823-170443_Recording_1920x1040
A
B
A
So
I
want,
if
I
understand
the
correctly
you
I
guess
you
just
want
to
update
the
community
about
the
some
delay,
because
Summer
Time,
a
lot
of
people
take
vacations.
Is
that
true?
So
you
want
to
update
and
change
that
to.
B
A
C
Yeah
next
one's
mine,
so
I
wanted
to
get
some
background
from
various
stakeholders.
We
have
some
customers
that
mount
varlib
containers
and
varlo
cuboid
onto
different
discs
and
the
ephemeral
storage.
That's
reported
by
the
cubelet
appearingly
propagates.
The
root
file
system,
instead
of
the
variological
or
varloop
containers
and
I,
was
wondering
what
the
background
of
the
feature
is
for
ephemeral
storage
and
whether
it
makes
sense
to
report
more
accurate
information.
On
those
two
mountain
points.
D
It's
my
my
memory
on
this
Ryan
was
that
the
cubelet
believes
anything
believes
the
disc
that
varlib
Cuba
is
mounted
to
is
the
root
of
s,
and
it
would
only
do
tracking
there
and
then
for
container
writable
layers.
D
If
the
container
runtime
had
reported
like
a
different
location,
the
writable
layer
may
not
have
been
accounted,
but
the
the
root
of
it
was
not
to
use
it
overload.
A
term
was
to
just
not
have
to
support
too
many
complex.
E
C
What
is
the
correct,
should
the
cubelet
be
extended
out
to
support
more
ephemeral
locations,
or
should
we
only
restrict
it
to
the
root
partition,
because
we
have
a
there's
a
lot
of
customers
that
are
mounting
these
disks
differently
and
they're,
not
getting
the
correct
reporting
from
the
kilowatt
on
this
yeah.
D
D
If,
if
any
other
providers
on
the
call
might
be
dealing
with
users,
that
might
not
always
agree
with
the
existing
like
default
project
posture
or
getting
pushed
to
support
more
flexible
disk
layouts,
because
even
for
red
hat
like
we
say
this
is
our
layout
and
then
we'll
run
into
field
folks
who
might
change
it
and
not
read
our
own
documentation
that
lets
Ryan.
Have
these
problems
I
guess
but
usually,
if
there's
some
local
reason
or
local
policy
that
makes
the
customer
think
that
they
need
to
do
something
different
than
the
project
Advocates.
A
I
also
want
to
say
that
actually,
that's
the
original,
that's
our
assumption
so
to
at
least
that
time.
We
start
that
the
design
it
is
to
simplify
problems.
So
that's
why
we
did
the
co-op.
That's
our
assumption,
and
here
it
is
how
the
node
configure
so,
but
I
do
say
that
people
say
that,
oh
maybe
I,
like
Santa,
you
say
that
we
maybe
want
to
rethink
about
this
one,
but
I
just
want
to
say
that's
the
Assumption
we
made
it
back
then.
C
Well,
maybe
if
we
can
take
the
discussion
to
the
issue,
that'd
be
best
and
I
just
wanted
to
raise
it
for
awareness.
A
Thanks
Ryan
to
reach
this
issue.
Actually,
now
is
the
time
Alexander.
If
you
have
the
something,
can
you
just
Sue
in
the
issue
run
created
there
as
you
can
get
some
attention,
so
we
do
looking
forward
to
her
the
more
feedback
on
as
well
and
that's
the
Assumption.
If
the
documentation
make
that
assumption
and
that's
the
how
the
node
config
is
unclear,
cause
some
confusing,
then
we
fix
stock.
If
people
think
about
it
right
now,
we
should
expanded
kubernetes
and
kubernetes
and
also
layout
is
not
meet
today's
change.
D
D
C
A
Thanks
relay.
F
Yeah
hi
hi
Dawn,
so
an
update
on
the
In-Place
about
vertical
scaling.
I
did
the
pr
got
merged
the
for
the
cap,
so
we
should
be
a
documentation,
wise
and
record
keeping
wise.
It
should
be
good
for
that
kept
to
be
targeted
for
v20
126
Milestone
I
also
created
a
separate
PR
for
the
API
changes.
If
we,
this
has
already
been
reviewed
and
it's
not
changed
in
a
while,
except
for
rebase
fixes
that
keep
happening
from
time
to
time.
F
If
there
is
no
objections,
I'm
wondering
if
we
can
look
into
merging
this
early,
then
it
will
save
me
the
headache
of
doing
rebases
and
then
I
can
only
focus
on
the
the
main
the
mothership
PR,
which
currently
carries
the
scheduler
and
the
couplet
implementation
and
I
did
get
a
chance
to
update
to
work
on
the
C
group
V2
implementation
last
weekend
and
that
the
CI
passed
it's
been.
F
I
tried
it
out
a
few
more
times
a
few
times
on
both
V1
and
V2
setups
in
GK
deployed
Cuba
and
then
the
product
cluster
with
multiple
nodes
and
then
tried
it
out.
I
think
I
want
to
get
a
couple
of
more
rebase
tries
in
the
CI
before
it's
like
I
feel
fully
confident
about
it.
So
but
then
it
can
be
reviewed
at
this
point.
I
don't
know
from
Renault.
Bo
had
initially
suggested
this.
A
few
changes
there
and
I
think
I
took
most
of
his
suggestions.
F
Yeah
I
think
that
it's
too
early
I
don't
have
a
lot
of
data
at
this
point,
but
I
feel
there
might
be
some
bugs
in
the
C
group
V2
on
the
implementation
side.
Do
you
think
there
is
or
do
you
feel
it's
stable.
F
Or
whether
memory
limits
are
being
enforced,
that
that's
the
question
I
have.
F
Yeah
no
I,
just
so
I've,
been
experimenting
with
a
little
demo
setup.
So
there
is
for
this
is
for
the
kubecon
and
I
think
our
idea
was
to
use
ebpf
to
detect.
You
know
certain
workloads
like
this
remote
Dev
environment
in
a
pod.
In
those
cases
you
can
know
ahead
of
time.
You
can
note
it
in
a
deterministic
way
when,
like
you're
writing
code
inside
that
pod,
it
doesn't
take
much
resources,
but
the
moment
you
hit
a
make
Command
or
you
want
to
run
a
bunch
of
tests.
F
You
immediately
need
more
resources.
So
that's
the
idea.
I!
Would
you
know
you
can
detect
that
event
with
ebpf?
And
you
can
you
know
potentially
Trigger
vpa
or
directly
ask
for
more
resources,
and
if
it's
there,
we
can
grant
it
and
in
that
I
tried
it
out
with
V1
without
any.
Without
this
ebpf
code
enabled
the
power
was
killed
as
expected
and
with
enabled
I
didn't
see
that
happen
so
I'm,
so
I'll
I'll
do
a
few
more
tests.
I
think
my
earliest
chance
I'll
get.
Is
this
coming
weekend?
F
E
F
Figure
out
something
yeah
I
can
I.
Think
I
can
share
my
code
out
as
well
that
it's
very
simple
python
code
just
attaches
a
a
ebpf
program
to
lock
traces
at
exec.
So
it's
very
simple
shouldn't
be
much
to
set
it
up
and
try
it
out.
Okay,
so
yeah
thanks.
Please
review
that
and
the
other
question
was
as
I
looked
through.
Implementing
this
I
was
wondering
whether
they
should
be
delegated
to
the
CRI
yeah.
You
have.
We
delegate
the
Pod,
sandbox
setup
and
tear
down
to
the
CRI.
Why
not
this?
F
F
Your
yeah
yeah
yeah,
the
thing
is
right
now:
I'm
we're
writing.
Okay,
it's
like
adapter
that
determines
which
C
group
file
to
update
right
for,
if
you're
increasing
memory,
then
in
C
group
V2,
you're
writing
to
memory.max.
If
it's
V1
and
you're
writing
to
memory
limit
bytes
to
update
that
limit
this
portion
of
it
is
it's
I
wonder
if
kublet
should
be
doing
it
at
all,
then.
F
For
the
pots,
okay
and
the
reason,
the
reason
we
need
to
do
this
separately
is
because
when
you,
if
you're
net,
increasing
the
container
resources,
then
you
need
to
update
the
Pod
C
group
first
and
then
increase
the
containers.
The
order
in
which
you
call
the
CRI
for
containers
in
the
Pod
increasing
the
Pod
matter
in
this
case.
So
but
then,
having
doing
this
in
couplet
seems
kind
of
asymmetric
or
a
little
off.
D
Yeah,
so
just
historically
of
an
eye
like
kubernetes,
had
challenges
in
container
runtimes
being
pot
aware,
I,
guess,
and
so
the
cubelet
like
organically
became
the
manager
of
pod
c
groups,
and
it
also
was
the
manager
of
its
Clause
hierarchy
above
pod
c
groups
which,
and
it
had
just
basically
delegated
to
the
containeracy
group
to
The
Container
runtime
part.
D
E
D
D
The
whole
thing
needs
to
go
to
the
CRI,
then
oh
okay,
and
then
related
to
a
difficulty
that
would
come
with
that
is
then,
when
we
do
with
when
we
do
out
of
resource
handling
like
the
cuboid,
is
the
one
that's
responsible
for
that
right
now,
and
so
that's
right.
It
has
to
read
those
two
group
levels
itself.
D
So
anyway,
it's
it's
just
a
complicated
topic
when
you
unwind
it
and
it
really
just
comes
down
to,
should
cubelet
do
any
c
group
management
at
all
and
right
now
it
just
says:
cubelet
does
all
C
group
management,
except
that
which
is
delegated,
and
it
only
is
delegating
the
container
portion.
F
D
Not
even
that,
like
you,
had
some
resources
that
were
only
accounted
because
they
were
used
in
volumes,
which
is
what
huge
Pages
was
doing.
Yeah
and
I
needed
to
span
like
the
life
of
any
container,
and
it
just
gets
very
complicated.
So
I
appreciate
why
you're
asking
the
question
and
gradual
evolutions
of
it
might
make
sense,
given
where
we
are
now
it's
just
historically.
That's
why
we
are
where
we
are
okay,
we
can.
D
H
Exactly
right,
so
we
we
are
putting
a
new
set
of
services
down
lower
for
sandboxing
inside
of
containerdy,
so
that
we
can
refactor
how
we're
doing
you
know
pod
support
today
and
containers
on
those
pods
to
the
to
the
point
where
we
should
be
able
to
support
microbians.
H
Additionally,
going
forward
and
yeah
I
mean
that's
going
to
require.
You
know
additional
integration
work
with
the
kublet,
so
yeah
I
think
it's
best
to
talk
about.
How
do
we
do
that
at
the
Pod
level?
You
know,
with
some
kind
of
sandboxing
common
sandboxing
service
support
as
a
quality
of
services
required.
F
A
Thanks
Willie
always,
and
next
one
is
actually
the
I
put
there,
and
the
wenjing
and
I
recently
go
over
the
our
CI
test,
because
I
think
a
year
ago
we
have
really
terrible,
coordinate
here
and
relabinated
issue.
So
then
we
found
the
this
is
their
project,
Sabo
project
and
the
thanks
to
the
Sergey
and
alala
and-
and
we
achieve
a
lot
of
progress
last
I,
think
more
than
one
year
and
also
and
also
Daniel
and
I
I.
A
Think
Daniel
is
not
here
today,
so
but
recently,
because
both
the
Sergey
and
Anna
they
take
some
time
off.
So
that's
why,
when
you
and
I
spend
the
time
and
also
there's
the
group
of
Engineers,
like
the
wunjings
team,
actually
weakness
still
monitor
those
critical
test
jobs.
So
then
we
found
a
lot
of
several
things
falling
apart.
So
that's
why
we
want
to
bring
this
the
community
bring
this
back
to
the
community
and
get
everyone's
attention.
I,
you
have
the
co-host.
Maybe
you
want
to
talk
you.
I
I
H
I
Can
anyone
help
me
to
share
the
screen?
I
think
the
major
thing
I
want
to
call
out
is
a
few
test,
Grid
or
consistently
failing,
and
maybe
it's
worse
to
look
at
it
together
to
see
if
they
are
still
relevant
or
they're
already
covered
by
another
tester
grid.
I
So
we
can
do
some
cleanup
and
if
they
do
have
some
coverage
they're
the
only
one
cover
some
certain
feature
or
area,
then
maybe
we
can
work
together
to
make
them
green
back
again,
as
as
the
next
focus
of
the
CI
group
I
want
to
hear
feedback
from
the
group.
A
At
least
I
want
to
mention
that,
because,
when
I
poke
around
there's
the
one
swipe,
that's
the
job
is
the
constant
of
the
field
for
last
at
least
the
two
or
three
months.
What
we
can
say
so
should
we
do.
We
have
other
swap
related
tests
somewhere,
and
it's
just.
This
is
particularly
always
image
related
stuff
because
there's
this
kind
of
expressive
this
talk
about.
A
So
all
we
just
have
to
find
someone
to
to
look
into
this
one
and
and
also
some
there's
the
comment
in
the
CI
that
that
spreadsheet
people
mentioned
that
it
looks
like
the
test
infrastructure
problem,
so
I
just
wondering
since
people
working
the
CIS
sub
project,
they
they
because
many
Communists
just
say
oh,
this
is
just
missing
of
the
artifacts
doing
brought
this
to
the
sixth
best
group,
because
that
looks
like
that
to
me
is
the
test
infrastructure
project
instead
of
we
retired
the
return
of
the
test
that
we
need
to
fix
of
the
test
infrastructure
in
standard
negative
because
test
infrastructure
problem.
A
E
A
Well,
Brad,
thanks
for
this
update
do
we
have
like
the
one
bag?
Basically,
it
is
summarize
those
test.
Artifacts
is
missing,
so
then
assigned
to
the
the
team,
and
so
we
can
at
least
the
signal.
The
community,
at
least
the
wealth
us
like
wanji
and
myself
can
chasing
because
the
those
people
fail.
Give
us
no
signal
about
our
quantity
right.
A
So
that's
why
so
at
least
the
weekend
working
together
with
you
and
the
chasing
and
make
sure
they
are
really
address
those
problems.
A
I
think
that's
the
that's
the
one
of
the
top
costs
for
me
to
look
at,
of
course,
that
I
still
have
the
flaky
test,
but
fully
kit
has
at
least
there's
the
reasonable
engineer
can
working
out,
but
that
is
test
infrastructure
problem
another
and
we
need
to
address
the
treated
as
the
top
priority
and
address,
and
another
thing
is
just
like:
that's
a
swab
test
and
I.
A
Look
at
that
sweptice
also
some
of
it's
caused
by
that
the
same
region,
test
infrastructure
missing
of
the
artifacts,
but
the
sum
is
not
so,
but
the
only
apparent
name
to
me
is
just
always
a
fair.
So
that's
why
I
kind
of
the?
Hopefully
we
don't
have
the
signal
for
the
swap
right.
So
this
is,
of
course,
luckily
we
also
put
into
plan
to
promote
it.
So.
G
Make
sure
Don
I
took
a
quick
look
and
it
looks
like
it's
running
into
an
SSH
issue.
It
may
be.
It
may
be
similar
to
things
we
have
fixed
on
chorus
earlier,
so
maybe
I
don't
know
like
maybe
Peter
or
Herschel
can
take
a
quick
look
and
we
can
get
back
next
week
like
what's
happening
with
that
job.
Sure.
A
I
A
G
A
Friends,
thanks
for
the
update
right,
it
just
took
me
some
time
to
find
the
Army
about
it,
but
yeah
I
can
help
with
it
yeah
thanks
menu
and
Ruben
on
this
one
and
also
Brian.
Thanks
for
the
updates,
I
will
put
your
comments
into
the
thing
to
the
agenda
and
the
proposed
next
week.
We
can,
if
we
have
some
data
and
update
to
the
community,
yeah
and
I'm
gonna,
do
the
same
thanks.