►
From YouTube: Kubernetes SIG Node 20221129
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20221129-180422_Recording_1532x818
A
A
A
A
C
B
We
can
just
start
off
from
the
kubernetes
issue.
Could
one
of
you
I,
don't
know
if
I
have
the
permissions
to
share
my
screen?
Youtube
blah,
oh
okay!
In
that
case
yeah.
Let
me
try
this.
B
Okay,
hopefully
you'll
see
my
screen
with
the
kubernetes
issue:
yeah.
B
Great
yeah
that
stays
oh
cool,
okay,
yeah,
okay,
just
a
quick
introduction,
I'm,
a
software
engineer
working
on
psyllium
and
I'm
here
to
socialize
our
feature
request
to
expose
for
C
group
path
in
a
standard
standardized
way,
and
we
believe
that
it
will
help
us
and
others
in
the
community
to
simplify
and
support
their
use
cases
so
yeah
before
we
get
to
the
pros
and
cons
with
the
existing
ways
to
retrieve
for
secret
path.
B
Let's
just
quickly
go
over
some
of
the
use
cases,
so
I
I
believe
we
have
context
around
what
part
C
group
paths
are
so
I
can
skip.
That
part
is
that
okay.
A
Yeah
I
think
everyone's.
Maybe
the
only
thing
you
could
clarify
here
is:
if
you
actually
want
the
Pod
C
group
path,
or
do
you
want
every
per
container
C
group
path
in
that
plot,
as
well.
B
So
parsley
group
path
is
a
good
start
and
well
I.
Guess
more
information
is
always
better.
So
if
getting
a
secret
path
at
the
container
level
is
possible,
then
yeah
that
that's
that's
even
better.
A
B
So
right
now
we
are
using
for
container
path,
but
just
using
it
should
suffice
for
our
use
case,
if
we
get
a
c
group
pad
at
the
Pod
level.
B
So
that's
the
psyllium
use
cases.
I've
I've
listed
other
open
source
projects
here,
I
don't
contribute
to
this
project,
so
I'm
not
intimately
familiar
with
this,
but
I
believe
we
are
using
Parts
degree
paths
for
like
variety
of
use,
cases
like
monitoring,
statistics,
collection
and
so
and
so
forth,
and
for
psyllium
we
use
ebpf
for
load,
balancing
policy
enforcement
and
other
use
cases,
which
is
where
we
require
pod
level,
secret
paths
so
yeah.
B
That's
the
that
that's
the
thing
on
use
cases,
and
so
these
are
some
of
the
ways
we
can
retrieve
part
C
group
path
and
every
approach
has
some
cons.
B
So
do
you
want
me
to
go
over
these
or
I?
Do
people
already
have
context
here.
A
I
mean
I,
know,
I
I,
have
context,
I,
don't
know
who
else?
If
anyone
wants
to
speak
up
I
think
it's
fine
to
go
through
it,
and
if
we
could
maybe
Timeless
discussion
to
about
10
minutes
and
we
can
either
choose
to
make
the
best
use
of
the
discussion
on
merits
are
doing
this
or
what
we
want
to
do
as
next
steps
or
get
everyone
on
the
same
page.
We
can,
we
can
see
as
you
we
can
go
either
out.
I,
guess:
okay,.
B
Yeah
I
guess,
if
you
have
only
10
minutes,
then
I
I
would
suppose
that
I
have
listed
all
the
information
on
the
issues.
So
people
can
just
reference
this
later,
but
yeah
the
merits
are.
These
are
all
the
projects.
B
This
is
not
an
investor
list,
but
it
keeps
a
feel
for
a
variety
of
use
cases
involving
particular
paths,
and
so,
if
you
click
on
these
links,
it
should
take
you
to
the
open
source,
so
we're
scored
where
you
can
see
how
every
project
has
its
own
way
of
retrieving
policy
group
paths.
So
there
is
no
like
a
clear
standard
way
and
then
these
are
the
limitations
with
each
of
these
approaches
that
is
open,
plus
projects
use,
including
philia.
A
That
I
could
see
wanting
to
put
the
C
group
path
on
the
kubernetes
API
in
the
in
the
Pod
status,
let's
say,
and
maybe
at
either
a
container
or
pod
level
granularity
is
that
you
have
a
control
component,
not
running
local,
to
the
node.
That
needs
to
do
something
with
that.
B
With
Celine
We
are
following
this
third
approach,
which
is
crafting
based
on
patterns.
We
do
it
on
code,
node
bases,
so
at
least
at
this
point
we
don't
have
like
a
centralized
component
where
this
information
is
needed,
but
it
could
be
possible
that
we
have
future
use
cases
for
that.
So.
A
A
B
Yeah
so
yeah
yeah
we've
taken
example
of
like,
for
example,
if
a
container
is
in
like
crash
loop,
it's
getting
three
creators,
so
this
container
ID
would
would
be
different
every
time
the
container
comes
up
and
in
this
case
I'm
not
sure
if
the
part
ID
Remains
the
Same
but
yeah.
If
there
is
a
change
in
part,
C
group
path,
then
we
would
want
to
get
notified
about
the
updated
part,
C
group
path.
F
One
question
I
have
is
like:
aren't
these
actions
that
are
adding
hooks
or
anything
in
the
c
groups
level
like
in
line?
If
you
try
to
do
it
offline,
it's
going
to
be
racy
right.
You
can't
wait
for
the
status
to
be
updated
and
go
and
do
something
because
by
that
time,
pod
is
already
up.
So
whatever
Network
policy
or
anything
you
want
to
inject-
is
kind
of
racing
with
the
Pod
running.
F
So
what
I'm
trying
to
say
is
like
isn't
this
something
that
would
run
as
part
of
your
cni
bring
up
portion
of
the
pod.
B
Well,
I
mean
yeah,
so
we
don't
have
access
to
this
information
in
the
cni
workflow
either,
because
the
secret
paths
are
not
exposed
to
whatever
the
CRI
spec
is.
A
F
B
So
I
can
give
a
data
point
here
when
we
were
evaluating
this
CRI
grp
interface
approach.
We
noticed
that
in
as
part
of
the
sandbox,
this
field,
like
the
container,
hasn't
been
created.
Yet
because
networking
only
after
networking
is
completely
set
up.
Does
the
cubelet
go
ahead,
goes
ahead
and
instructs
the
container
runtime
to
create.
So
what
we
noticed
is
as
part
of
the
sandbox
spec.
We
didn't
have
access
to
the
C
group
staff,
information.
F
That
doesn't
seem
right,
I
guess
we
will
need
more
details.
B
Sure
yeah
yeah.
A
A
Three
things
doing
it
with
like
on
a
per
container
basis,
particularly
if
those
c
groups
get
created
and
destroyed,
as
Bernal
noted
that
the
information
would
be
kind
of
latent
if
we
have
to
checkpoint
it
back
to
cube
API
every
time,
and
so
we
have
to
be
careful
about
that
and
then
I
guess
some
other
things
that
I'm
curious,
if
have
come
up
in
your
cni
use
case,
would
be
the
intersection
with
this
and
other
runtimes.
A
Handle
containers
differently
like
so
any
intersection
with
Kata
or
oh
I.
Forget
the
name.
What's
the
name
of
the
Google
project,
you
all
have
done
gvisor.
A
Doing
that
on
a
per
container
basis
still
really
problematic
to
me,
but
scoping
it
to
just
the
Pod
basis,
doesn't
seem
to
do
enough
to
be
expansive
to
the
monitoring
use
cases
you
talked
about.
So
what
I'm
wondering
is
like
if
we
can
just
narrow
the
use
case
to
be
cni,
get
ensure
that
cni
has
the
right
information.
It
needs
at
cni
startup,
rather
than
having
to
put
too
much
more
into
the
actual
pod.
Api
itself
is
kind
of
the
tension.
A
B
Yes,
that
sounds
really
appealing
because
going
back
to
I,
don't
know
who
was
the
person
who
mentioned
about
the
racy
conditions?
That's
definitely
possible,
especially
when
we
install
this
ebpf
hooks
that
are
invoked
at
a
socket
course
like,
for
example,
whenever
a
pod
make
like
a
connect,
call
or
something
it's
important,
that
we
have
this
information
available
before
any
network
traffic
is
passed
through
a
pod.
So
getting
access
to
this
information
at
as
part
of
the
sandbox
container
runtime
sounds
like
a
great
idea.
A
Next
step,
if
we
maybe,
if
we
relabel
this
issue
as
the
core
use
case
here-
which
this
thing
is
coming
up,
which
is
saying,
enables
cni
integrators
to
know
the
founding
C
group
of
a
pod
and
then
before
coming
to
this
particular
implementation
route,
we
could
also
look
at
the
other
alternate
route,
which
would
be.
What
could
we
do
to
ensure
you?
You
have
this
information
as
a
part
of
cni
setup
and
then
maybe
we
can
come
back
and
evaluate
pros
and
cons
on
either.
A
A
D
A
B
Yes
right
now,
since
we're
following
the
third
approach,
we
don't
have
to
elevate
any
security
privileges,
but
at
the
same
time
there
are
limitations
and
supporting
like
different
kinds
of
environments.
D
A
A
That's
just
like
a
document
convention
that
the
passer
you
use
now
have
been
in
place
since
a
very
long
time
now
and
we
haven't
had
strong
reasons
to
change
them
that
I
can
think
of.
But
there
are
users
who
do
change
the
C
group,
parent
path,
I
think
so
anyway.
That's
probably
another
thing
to
think
through,
but
is
that
next
step?
That's
basically
like?
A
Can
we
skip
this
to
just
how
to
make
sure
the
cni
has
this
information
and
then
put
this
option
among
one
of
many
and
then
we
can
come
back
and
revisit.
B
It's
like
don't
fully
understand
the
implications
of
doing
it
at
the
BNI
level
versus
like
exporting
it
as
part
of
the
static
field
you
did.
You
did
mention
like,
for
example,
if
it
was
default
to
CRI,
then
it
can
be
a
long
process.
So
can
you
elaborate
on
that
a
bit.
G
A
Looking
at
three
months,
four
months
to
get
that
into
an
alpha
phase
and
then
you're
looking
at
it's
basically
a
year
activity,
it's
what
I
was
just
trying
to
call
out,
and
it
could
be
that
there
are
other
faster
ways
for
us
to
get.
You
Dependable
ways
of
getting
this
information.
A
Just
changes
to
the
end
users
are
facing
API
or
given.
A
lot
of
scrutiny
is
basically
how
I
would
phrase
it
because
of
the
graduation
process.
They
need
to
go
through
and
it's
possible
that
the
alternative
path
of
seeing,
if
we
can
do
something
in
the
cni
bring
up
flow,
is,
is
a
equally
valid
and
faster
path
and
doesn't
make
users
look
at
the
cube
API
as
a
source
of
Truth
for
this
information,
particularly
if
it
rapidly
changes
so
like
crashing
pod
sandboxes.
A
We
wouldn't
really
want
to
go
and
drive
a
lot
of
right
rate
back
to
the
cube
API
server
right
so
in
general,
I
think,
there's
probably
a
lot
of
hesitancy
to
report
this
as
a
status
field
in
the
Pod
API
versus.
Can
we
find
other
ways
of
getting
you,
this
information,
stably
outside
of
the
Pod
API
and
maybe
Bernal
or
Don
or
others
chime
in
a
few.
F
H
I
think
there's
the
suggestion
on
the
Mac,
the
or
maybe
the
menu
and
yeah
just
on
the
local,
node
and
sorry
I
have
some
coffee,
so
the
so
the
CRI
implementation
can
pass
to
the
same
eye
at
the
runtime.
So
that'll
be
solve
your
problem
right.
I
I
I
just
want
to
add
one
other
or
sorry.
I
just
want
to
add
one
other
idea:
I
didn't
hear
a
race
yet
which
is
NRI
so
I,
don't
know
if
you're
using
container
D
or
cryo
but
containerdy
has
this
concept
of
NRI.
I
That's
been
a
little
bit
newer,
which
allows
you
to
kind
of
hook
into
container
creation
and
get
back
kind
of
events
right,
so
you
can
get
kind
of
a
call
back
when,
like
the
sandbox
container
started
and
using
the
sandbox
container,
you
can
extract
out
the
oci
spec
and
get
the
secret
path
through
that.
So
that's
like
another
option
to
explore
that's
kind
of
outside
kubernetes,
but
would
also
allow
you
to
get
this
in
your
path.
I
just
want
to
erase
that
as
a
possible
idea.
B
That
sounds
quite
specific
to
CRI.
Is
that
right,
all
right,
cryo,
sorry.
I
Sorry
that
was
a
continuity
based
feature,
but
but
I
think,
like
the
idea
is
hooking
into
the
Container
kind
of
you
know
it's.
It's
kind
of
like
oci
hooks
in
some
sense
of
getting
back
container
creation,
events
right
and
then
get
getting
the
ocis
back
and
extracting
the
secret
path
from
that.
I
J
Yeah,
it
would
be
specific
we
do
intend
on
supporting
NRI
and
cryo.
Eventually,
we
just
don't
yet
also
I,
don't
know.
C
A
Maybe
it
sounds
like
for
me:
I
would
say:
I
would
be
very
cautious
about
having
cubelet
to
cube
API
server,
write
traffic
be
expected
to
keep
this
data
field
up
as
a
source
of
Truth
for
you
as
a
cni
provider,
if
that
is
Meaningful
and
not
racy,
and
would
prefer
that
we
find
a
path
to
allow
you
to
get
this
information
local
to
the
node
without
needing
elevated
Privileges,
and
it
sounds
like
on
this
call.
A
Neighbors
next
steps
like
I'll,
throw
your
name
out
Peter
but
Peter
and
forget
the
gentleman
who
spoke
about
container
D.
Maybe
the
three
of
you
could
get
together
and
see
if
there's
an
alternative
path
that
hadn't
been
looked
at,
that
could
be
cross
runtime,
portable,
but
also
I.
A
Just
I
was
trying
to
look
at
myself
where
we
create
the
Pod
sandbox
right
now
on
the
cable
to
refresh
my
own
memory,
but
it
feels
like
we
should
be
able
to
do
something
at
that
point
without
needing
to
Rally
State
back
to
cube
API
and
the
more
we
can
do
that
I
think
the
better
and
more
narrow
the
solution
is
I.
Guess.
E
A
C
A
Put
their
names
in
the
chat,
so
we
can
get
a
group
together
to
do
follow-ons.
B
So
just
a
clarifying
question:
what
would
the
follow-up
discussion
happen
on
the
issue
itself?.
A
That's
fine
too
I'm
just
trying
to
make
sure
you
get
connected
to
the
right
set
of
people
to
help
out
driving
us
forward.
I
think
it's
personally
unlikely
that
we
will
want
to
report
this,
and
so
I
want
to
make
sure
we
get
the
right
group
of
people
to
to
know.
If
there's
things
that
can
get
you
the
outcome,
you
want
without
needing
us
to
do
that
last
resort.
E
Yep
yeah
Michael
Zapp
has
already
made
some
changes
in
the
cryo
and
containerdy
at
the
same
time
to
enhance
cni
support.
So
really
this
he's
the
right
guy
I
think
to
do
this,
one
because
I
know
he's
already
adding
another
field
or
two
that
we
that
we
can
pass.
So
the
only
only
issue
you're
going
to
run
into
is
without
going
through
some
kind
of
a
hook
mechanism
or
using
what
you
have
now.
You
have
a
versioning
issue.
You
know
until
this
is.
E
H
Okay
can
I
just
summarize
what
we
agree
about,
at
least
so
we
do
I
believe
signal
to
do.
Okay,
we
shouldn't
expose
this
no
level
OS
level,
it's
better.
It's
a
special,
particularly
from
the
mix
OS
level
of
the
details
to
our
API
server.
I
think
we
agree
on
this
one,
because
we
have
this
conversation
in
the
past
right.
H
H
Trend
then
later
come
back
again,
so
we
kind
of
already
going
on
the
community,
but
there's
the
mini
suggestions.
I
think
we
have
the
several
suggestions.
People
will
send
it
write
down
what
their
suggestions.
So
then
we
can
carry
on
the
discussing
in
the
issue
and
to
figure
out
what's
the
best
to
satisfy
this
did
I
summarize
this
correctly,
because
I
don't
want
the
people
to
think
about
it
later
say:
oh,
we
do
agree.
So
what's
the
next,
we
don't
agree
about
next
again.
A
Yeah
personally,
I
I
don't
want
to
expose
secret
pass
in
the
Pod
API
at
both
the
Pod
or
container
level,
unless
I
knew
all
other
options
were
exhausted
and
I
think
my
recommendation
is
that
this
option,
if
pursued,
would
come
with
other
negative
consequences
that
Renault
and
others
raised
here,
but
yeah.
If
we
could
just
update
this
issue
to
say
how
to
best
inform
a
cni
implementer
of
the
Pod
location,
then
we
would
understand
the
core
use
case
wanting
to
be
solved
and
then
can
find
the
right
outcome
for
that.
B
Brought
up
a
good
point
in
the
chat
it
seems
like
with
the
CRI
approach
it
all.
The
Cris
would
have
to
agree
on
the
spec
of
British
spec.
Is
that
right.
B
A
Yeah
I
think
we
just
need
to
write
down.
Maybe
other
approaches
to
solving
this
to
then
understand
their
various
pros
and
cons,
but
I
think
there's
immediately
negative
consequences
to
using
this
as
a
stable
source
of
Truth
value
for
you,
particularly
if
the
thing
that's
responding
to
it
is
running
on
the
Node
and
not
running
on
the
control
side.
A
If
there
was
a
use
case
that
said
why
the
thing
had
to
run
on
the
control
side.
That
would
be
interesting,
I
guess
to
dive
on.
A
But
if
your
thing
is
running
on
the
Note
side,
then
we
already
need
to
handle
use
cases
where
failure
of
a
cubelet
to
talk
back
to
cube
API
is
an
issue
how
to
deal
with
the
right
rate,
how
to
deal
with
a
number
of
other
things
that
can
put
pressure
on
qvpi
as
a
concern,
so
I
just
I,
don't
think
we
know
enough
on
the
other
pass,
but
I
think
everyone
now
understands
the
end
goal,
which
should
be
a
cni
provider,
should
be
able
to
know
the
C
group
sandbox
on
a
Linux
host
for
a
pod
and
a
stable
Manner
and
right
now.
A
This
approach
is
one
possible
approach,
but
it
has
negatives
and
I.
Think
right
now,
Don
and
myself
and
probably
Bernal
would
say
like
we
wouldn't
want
to
go
this
route.
Yet
before
wanting
to
look
at
the
other
approaches
and
because
we
really
do
not
want
to
hunt
the
pot
C
group
information
in
the
end
user,
API
yep.
A
A
Maybe
we
can
come
back
and
I,
don't
know
what
your
your
desired
timeline
was,
but
maybe
we
can
come
back
in
a
few
weeks
and
see
if
we've
moved
forward
on
that
with
more
information.
Does
that
sound
good.
A
A
So
that
the
next
topic
here
it
looks
like
the
author
is
not
here,
unfortunately,
so
this
was
around
wanting
to
move
forward
with
fine
grain.
Supplemental
groups
controls
I,
guess
probably
the
best
thing
we
can
do
is
who
would
want
to
help
move
this
forward
right
now?
The
cap
doesn't
have
any
assignee.
A
F
A
It
looks
like
Kevin:
are
you
on
the
call?
Is
there
anything
more
than
just
a
approval
needed
on
the
resource
management
stuff.
F
A
G
Yeah,
this
is
the
no
resource,
topology
API,
for
no
matter
scheduling
work.
We
had
a
discussion
about
this
last
week,
so
I
I
just
wanted
to
bring
this
up
again.
We
managed
to
get
a
bunch
of
approvals
on
this.
The
only
thing
that
we're
waiting
for
is
your
approval
from
kind
of
architecture.
Point
of
view.
If
you
could
take
a
look
at
that
I
think
we
can
get
this
close
done.
G
I
think
from
architecture
point
of
view,
the
direction
that
we
are
taking
from
no
point
of
view,
Dawn
approved
it
and
Tim
approved
it
as
well.
I
just
wanted
you
to
take
a
look
and
if,
if
it's
okay
to
move
forward,
yeah.
G
A
G
A
G
I
think
Tim
has
been
looking
at
it
and
he
he
took
a
look
at
the
the
new
PR
as
well,
so.
A
I
guess
at
the
CIU
and
for
money
in
the
list
of
API
approvers
on
here
and
I
was
just
wanting
to
make
sure
there
was
a.
If,
if
we,
if
there
was
anyone
else
who
maybe
came
forward,
that
wanted
to
do
that
as
well
or
not.
A
A
D
Well,
I'll
just
there's
a
question
on
there,
but
otherwise
yeah.
That's.
D
A
I
Right
Bobby
do.
I
Yeah
yeah,
it's
me
so
I
talked
a
little
bit
about
this
a
few
weeks
ago,
when
I
wanted
to
bring
up
this
topic
again,
I
got
a
little
bit
more
feedback
about
it.
So
to
give
everyone
a
little
bit
of
context,
the
idea
here
is:
there's
a
proposal
I'm
working
with
someone
kind
of
more
on
the
operational
monetary
side
that
we
want
to
add
the
kublet,
we're
gonna.
Add
a
health
check
to
kubl.
I
It
like
health
is
the
endpoint,
so
Google
already
already
has
a
healthy
endpoint,
but
we
want
to
add
the
ability
for
that
healthy
endpoint
to
also
report
that
the
CRI,
the
container
runtime
is
healthy.
So
the
container
runtime
today,
just
for
a
little
bit
more
context,
provides
us
like
a
status
RPC
and
it
returns
conditions
around
the
health
Phineas
of
the
CRI
itself,
and
so
there's
like
a
runtime
ready
and
network
ready
conditions
that
the
CRI
returns.
I
So
today
you
know
getting
that.
Information
is
quite
helpful
to
understand
like
if
the
container
runtime
is
up
and
we
need
to
do
some
type
of
corrective
actions
like,
for
example,
you
know
recreating
some
node
or
repairing
it,
or
something
like
that.
You
know
if
something's
not
healthy,
so
today
the
the
issue
is
that
kind
of
to
to
do
a
proper
health
check.
We
have
to
launch
cry.
Cuddle
is
what
we
do
internally.
I
I
So
the
ideal
thing
that
we
would
do
is
just
kind
of
integrate
this
into
the
kublet
Health
endpoint,
so
that
you
know
kublic's
already
running
so
everything's
already
in
memory,
and
so
we
can
just
ask
Kubla,
hey
it's
the
container
on
timeout
and
it
would
just
give
a
yes
or
no
Google
already
helped
has
a
healthy
endpoint.
Since
it's
not
a
brand
new
thing.
This
is
just
gonna
yeah.
You
know
slightly
increasing
the
scope
that
helped
endpoint.
A
The
node
is
not
healthy
if
the
plug's
not
responsive
I
was
just
which
is
also
trying
to
interact
with
the
container
runtime.
Is
there
something
different
here
that
I'm
missing.
I
Yeah,
so
the
main
difference
is
that
for
the:
if,
if
the,
if
the
container
runtime
is
not
responding,
you're
right,
the
flag
would
not
respond.
But
then
then
what
would
happen
is
like
the
node
would
try
to
report
the
status
right
to
the
API
server,
but
we
notice
in
some
cases
that
node
might
not
be
able
to,
for
example,
like
there
might
be
dispatchers
network
issues.
Something
like
that.
I
So
the
idea
here
is:
we
want
kind
of
a
local
check
on
the
Node
without
any
kind
of
API
server
connectivity
about
the
status
so
that
we
can,
for
example,
like
restart
Google
it
or
restart
the
container
runtime.
If
this
health
check
fails,
that's
sort
of
the
idea,
oh.
A
Okay,
I'm
sorry
I
missed
that
so,
basically
as
like
in
my
system,
D
unit
or
something
I
can
ask
if
my
my
giveaway
component
itself
is
healthy
or
not
and
drive
exactly
exactly
yeah
and
you
want
to
drive
a
restart
if
my
CRI
is
not
healthy
yeah.
I
So
I
mean
it's,
it
depends
on
the
problem.
Obviously
so
I
don't
think
people
will
always
fix
it,
but
that's
kind
of
what
we
do
today.
We
have
a
health
check
script,
actually
that
we
can
run
periodically.
That
goes
out
and
checks.
You
know.
Basically,
it
checks
out
the
kublets
up
by
querying
the
Kublai
helps
the
endpoint.
If
that's
not
responding,
we
restart
kublet.
If
we
and
then
we
also
launch
cry
cuddle
and
and
see
if
we
can
connect
the
container
on
time.
I
If
we
can't
watch
connect
the
container
on
time,
we
restart
container
D
on
our
side,
for
example.
So
we
have
kind
of
this
basic
health
check
script
that
we
run
periodically,
but
the
problem
with
it
is
that
it
has
to
continuously
launch
cry
pedal
which
is
going
to
have
to
connect
to
the
container
runtime,
and
we
ideally,
we
just
have
like
a
healthy
endpoint.
We
could
connect
to
okay.
A
I'm
just
trying
to
make
sure
I
understand
this
event,
so
the
in
the
case
where
the
the
CRI
provider
might
be
saying,
they're
healthy,
but
they're
unable
to
actually
accept
connections.
I
Maybe
something
like
that:
yeah,
like
some
connectivity
issue,
for
example
or
yeah,
so
something
a
good
work
somewhere.
So
we
often
see
that
you
know
just
simple
restart:
can
help
remedy
things.
So
that's
that's
kind
of
the
the
context
yeah.
D
A
J
Yeah
I'm
trying
to
think
of
like
internally,
if
we've
hit
situations
where
we
would
want
this,
usually
because
you
know
putting
the
red
hat
hat
on
the
because
our
nodes
there's
less
like
manual
touching
on
them.
So
if
something
goes
wrong
then
you
know.
J
The
the
admins
have
to
go
in
and
you
know
do
something
it's
like
I
could
see
it.
You
know
being
useful,
but
I
haven't
thought
of
a
specific
use
case
that
we
have
internally,
that
we've
used
it
for,
but
it'd
be
easy
to
implement
so
I'm
not
opposed
to
it.
I
And-
and
this
is
already
just
to
be
clear-
this
is
standardized
across
the
container
run
times
like
they
already
report
conditions
around
the
healthiness
of
them
right.
So,
if
you
ask
the
container
runtime
hey
give
me
those
conditions,
that's
already
implemented
in
the
container.
What's
not
implemented
is
there's
no
simple,
like
HTTP
Health
C
endpoint
on
the
container
runtimes
are
on
Google.
Let's
actually
get
that
status
right,
so
that's
kind
of
The
Proposal.
Here
it's
it's
basically
to
extend
the
Kubla
healthy
endpoint
to
just
report
back
that
information
from
the
container
on
top
and.
E
E
I
Makes
sense
like
for
our
use
case,
we
just
wanted
to
restart
things,
but
I
could
imagine
we
might
extend
in
the
future.
You
know
for
logging
for
like
there
could
be
more
action
taken.
You
know
we
could
report
that
condition
down
to
some
other
systems
right
that
could
do
some
type
of
remediation
or
something
like
that.
J
I
Like
the
last
time
we
we
brought
this
up
just
to
kind
of
get
a
little
more
context
like
there
was
kind
of
two
pieces
of
feedback.
One
was
like
potentially
if
this
makes
sense
to
integrate
in
the
container
runtime,
not
the
Kublai
that
I
think
was
as
decent
is
pretty
good
feedback.
I
We
kind
of
looked
into
that
a
little
bit,
so
the
issue
I
think
right
now
is
it's
not
standardized
across
the
container
runtimes
there's
no
Health
Z
kind
of
on
the
container
on
time
side,
so
something
we
could
bring
to
the
container
online
community
I
suppose,
but
the
other
issue
is
that
it
doesn't
really
show
the
connectivity
is
working,
which
is
something
we
wanted
as
well.
We
actually
want
to
check
that
the
Kublai
can
actually
make
that
connection
to
the
container
on
time.
Not
just
ask
the
container
runtime
directly
if
that
connections
up.
A
Don't
really
have
any
downsides
on
this
David
I
was
just
trying
to
think
like.
Does
this
actually
fix
anything
and
then
like
right
now,
we
don't
really
do
much
of
anything
in
a
health
check
on
the
kilo
process,
since
I
was
trying
to
think
through,
like
where
we
inline
see
advisor.
You
know
is
that
more
likely
to
wedge
like
of
the
things
that
we
actually
depth,
rather
than
communicate
out
to
the.
I
E
I
We've
seen
especially
like
in
throttling
cases,
sometimes
when
things
get
kind
of
work
like
there's
really
high,
I
o
latency
for
a
period
of
time
things
can
kind
of
get
wedged
periodically
and
like
can
restart,
and
it
helps
there's
things
out.
We've
seen
that
in
production.
So
that's
one
of
the
common
cases.
H
So
in
in
a
in
the
history,
kubernetes
did
this
before
U.S
I
just
want
to
say
the
what
what
did
David
request?
Actually,
it
is
something
we
changed,
but
there
is
nothing
but
just
moved
to
the
different
component.
So
in
the
older
time
kubernetes
detect
of
the
container,
which
is
darker,
is
not
responsible
or
it
is
bad,
then
we
will
restart
even
kubernetes.com.
The
docker
in
a
really
old
topic
stock
is
really
unstable,
always
and
responsible.
So
we
we
end
up.
H
Think
of
a
kubernetes
is
the
bring
on
the
Node,
so
have
decided
okay,
he
have
to
restart
a
certain
thing.
So,
but
that's
obviously
it's
not
the
good
thing.
So
then
we
move
that
The
Logical
out
to
the
system
D
some
people
and
the
sum
is
not
in
their
startup
script.
So
then
later
we
try
to
move
to
this
MPD.
The
problem
is
even
for
the
load.
H
The
problem
detector,
just
like
David,
said,
there's
the
certain
cases
this,
which
is
a
necessary,
complicated
and
also
certain
cases
we
didn't
cover
like,
for
example,
like
the
kubernetes
and
to
connect
to
the
to
the
container
runtime.
Those
kind
of
things
is
not
connected,
so
what
did
David
asked
for
here?
Even
today,
kubernetes
still
report
container,
Readiness
or
not.
It
means
useless
to
report
that
kind
of,
but
because
we
are
not
really
report
anything
except
of
the
collectivity
to
the
to
the
container
runtime,
but
that's
not
in
the
in
the
point.
H
So
what
David
just
say?
Okay,
another
way
to
surface
this,
to
the
kubernator
current
kubernetes,
that
the
continuity
it
is
workable,
is
connectable
available
or
not
so
I
do
think
about
that's
now
to
really
add
them
anything
additional
information
and
also
clean
up
more
standardized
and
clean
up
the
current
cases.
Yeah.
A
D
A
Through
is
like,
would
we
benefit
from
also
having
the
stats
provider
being
added
in
the
health
check
or
not,
and.
I
That's
I
think
actually,
so
the
way
that
this
was
implemented
currently
is
that
they
there
is
a
status
endpoint
on
the
container
runtime
right
and
it
returns
a
set
of
conditions,
and
so
we
check
I
believe
two
conditions
are
in
10,
runtime,
ready
and
network
ready
right,
which
means
that,
like
the
the
runtime
Services
up,
but
also
there's,
you
know
other
conditions
that
could
be
added
later,
like
the
image
Services
up,
you
know
SAS
provider
Etc,
so
maybe
that's
something
we
can
make
senseful
in
the
future.
I
F
E
F
I
A
On
the
C
advisor
interface
that
we
can
also
pull
for
a
health
endpoint
so
that
we
can,
we
can
maybe
do
two
things
at
once
here.
So
I.
I
For
C
advisor
it's
a
little
bit
more
on
the
like:
it's
scraping,
you
know
it's
using
I
notify
on
actual
C
group
path,
so
it's
not
always
connecting
to
the
container
runtime
socket
or
as
opposed
to
Google
it
that's
kind
of
the
main
difference.
I
guess,
yeah.
A
I
think
you're,
like
all
those
messages
where
it's
like
the
migrants,
I'm
thinking
of
horrific
node
logs
I've,
looked
in
the
past,
where
it's
like
the
interval
10
seconds
can't
be
met,
type
thing
and
20
000
times
in
a
row.
It's
my
memory
right
now
on
where
and
see
advisor.
That
would
be
a
the
equivalent
Health
endpoint
was
a
little
rusty.
So
I
need
to
go
check
that
out,
but.
G
I
I
Cool
okay,
so
I
guess
the
only
question,
then,
is
this
something
we
think
we
should
introduce.
There
was
a
question
around
like:
should
we
make
this
configurable
around?
What
type
of
conditions
are
considered
healthy
from
the
container
runtime
in
in
the
health
Z
endpoint,
or
should
we
pass
Maybe
the
the
healthy
endpoint
can
take
its
input,
the
conditions
we
want
to
be
considered
healthy.
That's
another
option,
that's
something
we
want
to
do
here,
or
should
we
just
stick
with
the
static
list
of
basic
conditions?
I
think!
That's
the
only
question.
That's
left.
J
Well,
if
we
start
off
by
just
returning
the
the
runtime
status,
whatever
it
is,
what
like
either
we
couldn't
get
one
or
here's.
What
the
runtime
said,
then
a
client
could
parse
that
and
then,
if
we
wanted
to
extend
it,
we
just
have
to
extend
the
number
of
conditions
that
the
runtime
can
send
when.
A
G
E
I
E
J
Yeah
yeah
well
I'm
I'm,
just
a
little
unclear
is,
is
the
proposal
now
to
have
this
health
C
for
the
CRI
then
cause
the
cubelet
to
make
like
an
intelligent
decision
about
what
to
do
about
it?
Like
you
know,
Derek
saying
it
shouldn't
be
restarted
on
network.
Not
ready,
like
is
to
keep
it
making
that
decision,
or
is
this
a
third
party
no.
J
J
A
A
A
J
Would
almost
have
it
be
the
unit
for
the
run
time
like
be
like
basically,
I,
think
the
manager
of
the
runtime
should
be
the
one
listening
for
this
to
keep
a
separation
of
responsibilities,
which
was
going
to
be
my
point,
but
if
the
cubelet
isn't
going
to
have
anything
to
do
with
it,
then
that's
okay
with
me.
A
This
is
saying:
if
the
cubic
can't
communicate
to
the
runtime,
then
the
cubelet
should
not
be
considered
healthy,
which
would
mean
the
manager
and
then
decide,
maybe
I'll
restart
the
cubelet,
and
that's
why
I
asked
earlier.
What
would
that
solve?
And
so
I
was
trying
to
think
through
the
error
case,
and
so,
if
it's
like
a
bug
in
the
client
library
that
talks
to
that
socket,
for
example,
Maybe,
maybe
that's
what's
being
fixed
and
I
trust
David
that
he
said
he
had
to
use
cases
where
this
helps
I
was
just
sometimes
jiggling.
A
The
handle
helps
a
lot
of
things.
We
didn't
know
the
root
cause,
and
so
I
just
didn't
know
if
we
knew
what
that
was
here,
but
if,
if
this
would
require,
if
this
would
make
like
many
unit
files
in
the
world
that
run
cubelets,
you
know
have
cable
to
be
restarting,
because
the
cni
was
not
yet
fully
deployed.
I
would
I'd
be
hesitant
on
that
that
one.
I
H
I
H
David,
even
today
we
have
the
container,
not
variety.
We
only
basically
add
the
kubernetes
start
of
point
right,
so
this
is
changing.
We
basically
have
the
periodic
the
Checker
code
right,
yeah.
I
Yeah,
so
the
idea
here
is,
for
example,
for
us
we
already
have
a
systemd
unit
that
does
a
periodic
health
check
right
yeah,
but
it
uses
cry
cattle,
for
example.
To
do
that
so
the
benefit
here
is
we
don't
need
to
load
in
this?
This
big
binary
of
health
check,
interval
right
and
just
use
something
that's
already
running.
Yeah.
C
A
That
would
be
a
non-starter
for
many
of
my
customers
use
cases
or
users
use
cases,
because
the
network
is
deployed
delayed.
I
I
C
H
Right
excellent,
well,
I
think
the
last
topic.
A
D
So
for
the
in
place,
resize
I
think
we're
just
targeting
it
for
127
now
and
I'm,
hoping
that
we
can
merge
the
API
really
early,
because
we
need
that
for
enabling
some
of
the
CI
tests
and
I'm
working
on
getting
the
full
job
fixed
up,
so
that
once
that
passes,
we
know
that
it's
passing
with
the
latest
container.
D
Okay,
okay,
I'll
be
on
vacation
for
the
rest
of
December,
so
I'll
meet
you
guys
in
January
and
have
a
great
vacation
have
a
great
holidays.
Happy
New
Year.
A
Yeah
same
to
you
as
well,
and
so
there's
no
other
topics,
then
we
will
end
today's
meeting
and
everyone
have
a
great
yesterday
bye
everyone.
Thank
you.