►
From YouTube: Kubernetes SIG Node 20201013
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
B
Thanks
doug,
yes,
so
to
update
everyone
here
we
had
a
a
meeting
about
the
sector
cap
and
we
decided
not
to
move
forward
with
this
kept
for
at
least
one
training
and
instead
to
start
from
scratch
and
recollect
all
the
use
cases
and
try
to
see
a
good
design
to
to
to
accommodate
them
all.
B
So
I
wanted
to
ask
here
in
thing:
node,
if
it's
okay,
to
merge
the
pull
request
with
the
factor
curve
and
mark
it
as
rejected,
maybe
in
the
state,
and
so
we
start
with
a
different
cap
with
the
follow
up
following
work,
because
I
think
it
will
be
quite
quite
different,
and
I
also
wanted
to
ask
exactly
how
to
proceed
like
we
created
the
document
and
there
are
some
use
cases
there.
B
I
plan
to
add
some
more,
but
is
there
any
established
process
that
used
usually
used
here
like?
Should
we
start
writing
like
proposals
in
an
informal
way
and
discuss
them?
Who
would
like
to
do
that
or
yeah?
How
do
you
usually
do
it
during
signal.
A
So
we
used
any
of
those
work
started
from
the
new
use
cases.
Cytoka
container
is
really
complicated
topic.
It
is,
we
do
have
real
use
cases
still
and
a
service
message.
We
do,
I
believe,
last
time
when
we
talked
there,
a
lot
of
people
expressed
that
problem.
It
is
the
set
card
container,
is
too
powerful
right.
A
So
so
how
we
are
going
to
the
we've
been
talk
about
back
of
us
and
even
make
the
tgr
decision
couple
times
based
on
the
new
either
we
did,
unlike
the
set
kind
of
static
container,
then
to
completely
address
all
the
issue
is
still
our
services
much
less,
but
on
other
hand
the
static
container
itself
is
really
powerful,
so
many
people
think
about
it.
They
could
do
something
but
which
also
give
us
consent,
because
how
safely
we
allow
other
use
cases
to
using
and
not
cause
destabilize
our
system.
A
This
stephen
excuse
me
so
so.
This
is
why,
like
the
for
me,
this
is
like
one
of
those
top
most
difficult
topic
we
had
so
the
problem
is
other
use
cases
and
clear:
we've
been
hired,
many
people
raise
their
hands
and
say:
oh
settler
can
learn.
We
want,
especially
for
the
workers
independence.
What
kind
of
the
signal
deleted
so
so
their
leader
of
the
next
container
start
and
the
secretions
start,
or
they
need
a
container
finished
successfully
finished.
All
they
need
is
container
start,
but
it's
ready
to
serving
the
real
traffic.
A
So
all
those
technology
is
unclear
and
obviously
people
can
see
that
like
right
now
I
don't
have
use
cases,
but
I
can
quickly
think
about
that's
the
this
is
a
circle
or
different
signal
we
can
give
and
also
some
is
like
that
is
only
at
the
start
of
the
time
I
waiting
for
signal
all
have.
Next,
the
shutdown
are
waiting
for
some
ziggler.
Should
I
shut
down
my
container
this
data
container?
Oh
my
second
container
down.
I
need
a
shutdown
application
container.
A
So
all
those
kind
of
open
questions,
so
I
think
the
best
it
is
just
you
stick
with
the
working
of
the
use
cases.
We
want
to
support
and
lay
out
those
use
cases
and
then
can
see
that
the
how
we
are
going
to
settle
containers,
support
that
use
cases
and
figure
out
what
is
non-goal
and
then
figure
out.
If
that's
not
non-goal
can
customer
can
abusive,
they
used
to
care
abusive
using
satellite
container
to
enable
some
longer
kisses.
So
it's
not
there.
It's
kind
of
the
things
we
we
need
to
discuss
there.
A
So
all
maybe
like
the
even
I
think
the
people
also
touch
base
in
their
another
meeting.
We
had
just
dedicated
for
the
second
container.
They
also
say
easter.
The
people
means
that
issue.
A
lot
of
issue
actually
could
be
addressed
by
some
other
way.
We
are,
we
don't
know
right,
so,
if
is
to
issue
can
be
addressed
another
way.
What's
another
way
in
that
case
is
still
there
are
people
asking
for
certified
container
for
other
use
cases.
Then
we
need
to
dig
more.
A
What's
that
real
use
cases?
So
I'm
sorry,
I
think
you
really
more
the
more
like
the
defined
process
here,
because
this
is
really
complicated
problem,
the
problem
so
this.
This
is
why,
in
that
meeting,
I
even
call
that
the
power
of
the
spike
washington-
obviously
that's
not.
We
are
not
really
open
to
do
that,
but
it's
to
me
like
that
sounds
like
if
we
don't
do
careful
name
right.
B
So
so,
let's
say
we
collect
all
the
use
cases
in
this
document.
Let's,
let's
assume
that
that
happened,
how
we
should
proceed
after
that.
B
Should
we
try
to
form
a
small
group
and
meet
with
this
small
group
or
different
groups
to
explore
different
ideas
and
then
sync
between
the
groups
or
yeah?
I
don't
know
I'm
open
whatever.
A
A
We
need
something
like
the
small
small
group
and
who
interesting
on
this
topic
and
or
do
you
have
some
use
cases,
hopefully
secret
container
or
can
address
this
problem
or
is
the
someone
found
a
services
mesh
and
have
that
obviously
understand
their
use
cases
and
can
help
move
forward
nice,
but
I
want
to
hurt
other
people's
opinions
here.
C
Yeah
I
mean
some
of
the
use.
Cases
is
seth,
got
enumerated
in
that
issue
or
the
or
the
kep
pr,
but,
like
b
being
able
to
start
a
a
container
that
is
supposed
to
stay
running
before
init
containers,
which
was
you
know,
letting
indicator,
get
basically
letting
like
an
ingress
or
a
network.
C
Proxy
containers
start
before
the
init
containers,
because
the
indic
containers
might
need
network
access
as
well,
and
you
want
all
network
access
to
go
through
the
proxy
and
then
another
use
case
just
off
the
top
of
my
head.
That,
I
remember
was
something
called.
I
think
it
was
called
critical
containers
where
it
was
if
this
container
dies,
that
should
be
considered,
considered
fatal
for
other
containers
in
the
pod,
and
they
should
all
be
restarted.
B
Okay,
yeah,
I
the
one
about
in
it
containers.
I
think
it's
already
there
in
the
dock,
the
one
about
the
subtle
to
bother
container.
I
think
it's
not
there
but
I'll
make
sure
to
to
add
it.
C
And
then
one
thing
that
another
thing
that
should
be
captured
container
shutdown
order
right
now
we
don't
have
any
notion
of
in
what
order
containers
should
be
shut
down,
but
with
this
ingress
with
the
network
proxy
thing
it's
there
should
be
some
way
to
indicate
that
it
should
be
shut
down
last
because
the
other
ones
depend
on
it.
B
B
Right,
yeah
yeah,
but
do
you
have
in
mind
some
use
cases
where
you
want
to
start
the
containers
in
one
order
and
shut
them
down
in
other
order?.
C
B
Right
so
so
I
was
planning
to
well
I'll,
add
these
use
cases
to
the
dock
and
some
more
use
cases
and
try
to
create
some
pre-proposals.
B
If
someone
wants
to
explore
different
ideas,
please
just
write
me
on
a
slack
and
we
can
create
a
meeting
between
us
and
uncoordinate
or
just
go
ahead
and
explore
on
your
own.
I
think
as
that's
if
this
makes
sense
for
for
everyone
or
don,
do
you
think
we
should
do
something
else.
A
Actually,
yes,
good
good
yeah,
so
I
will.
I
will
summarize
what
we
discussed
and
then
just
like.
What
do
you
suggest?
Then
it's
an
exact
rejection.
While
we
reject
the
kind
of
type
express
it,
then
then
you
can
start
another
one.
So
so
I
just
documented
so
then
you
can
you
can
you
can?
Can
you
I
do
what's
next
there
also.
So
then
we
can
close
that
tab
then
move
to
the
new
cab.
The
new
dock
and
the
new
cab
new
process
is
that
okay.
A
A
D
Yes,
hi,
it's
it's
gay,
so
I
just
wanted
to
share
some
use
cases
for
for
topology
over
scheduling.
D
A
Grant
you
sorry,
you
need
the
switch
here
right.
So
let
me
give
you
host,
so
you
can
start.
A
Okay,
sorry
yeah
already.
D
Okay,
so
I
used
this
for
for
to
approach
your
scheduling
and
I
wanted
to.
D
Bring
the
the
viral
use
airplane
use
case
here,
so
this
is
a
quite
common
telecom
use
case
when
we
are
running
the
dvr
and
workloads
in
kubernetes.
D
We
need
a
robust
scheduling
because,
because
we
you
need
time
constraint
for
for
restarting
the
ports,
because
these
ports
are
really
like
handling
critical
workload,
and
if
we
have
a
hardware
failure
and,
for
example,
we
need
to
evacuate
the
hardware,
then
we
have
to
ensure
that
these
ports
are
starting
for
for
the
the
first
time.
D
So
that's
the
first
there's
the
first
use
case.
The
other
use
case
is
it's
related
to
to
ai
and
and
and
gpus.
So
in
this
case,
we
should
have
the
the
nic
and
the
gpu
and
then
and
and
the
cpu
sorry,
the
leak
and
the
gpu
should
be
normally
aligned.
But
the
cpu
is
not
needed
to
be
a
numeral
line,
so
this
time
indicate
that
that
the
requirement
for
new
alignment
is
is
resource
based.
D
And
we
have
a
third
use
case,
but
I
would
let
what
it
would
describe.
So
I
don't
know
who
I
did.
Okay.
E
Yeah
so
the
first
one
is
kind
of
very
generic
capturing,
essentially
the
problem
statement
itself.
So
it's
about
the
read
the
scenario
where
run
away.
Pods
are
created
because
the
because
the
resources
cannot
be
aligned
and
the
scheduler
is
topology
unaware
in
a
scenario
it
just
ends
up
creating
a
series
of
pod
which,
which
are
which
cannot
be
scheduled
on
the
right
node,
so
that
is
kind
of
a
high
level
problem
statement.
E
So,
like
the
few
use
cases
that
you
mentioned
here,
those
were
those
are
use
cases
coming
kind
of
from
customers.
So
we
just
want
to
bring
it
to
the
table
here
and
bring
it
to
everyone's
notice,
and
the
other
reason
is
that
we
want
to
kind
of
start.
The
conversation
in
terms
of
if
other
people
have
use
cases
we'd
be
happy
if
they
could
just
kind
of
append
those
use
cases
here.
So
we
have
kind
of
a
stronger,
stronger
case
in
pushing
topology,
aware,
scheduling
and
kubernetes.
F
I'm
sorry
I
just
wanted
to
say
thank
you.
We
also
working
on
this
same
use.
Cases
as
you
described,
also
guys
from
samsung,
also
working
on
the
same
telecom
use
cases,
and
you
can
chan
the
spring
had
a
presentation
here
in
the
signature
meeting
about
telecom
use
cases.
C
F
D
Thank
you.
Yes,
we
also
can
add
that
in
the
current
language
foundation,
technical,
even
there
was
a
a
presentation
about
where
about
the
usage
of
kubernetes
in
intel
communications
and
the
and
the
clear.
D
Trend
was
that
humanitas
used,
introduction
in
telecom
networks
already
and
and
telecom
operators
are
planning
to
to
run
more
and
more
network
functions
on
on
kubernetes,
and
this
is
why
we
need
these.
These
features
because,
because
currently
accumulators,
let's
see,
makes
it
possible
to
run
signaling
core
network
elements
which
are
pretty
much
similar
to
web
servers.
D
They
are
just
using
some
a
bit
more
crazy
protocols,
but
if
we
are,
if
you
would
like
to
run
user
plane
elements
which
are
really
handling
the
media
streams
from
the
devices,
we
need
to
have
this
kind
of
real-time
features.
D
D
D
D
Still
about
the
the
use
cases,
can
we
discuss
a
bit?
What
else
is
needed
for
use
cases?
Should
we
like
polish
them
more
or
is
there
any
aspect?
What
we
should
highlight
in
the
in
the
document
I
see
now
lots
of
people
are
looking
into
it.
A
Comments
from
the
community,
especially
people
plan,
to
use
in
this
feature
and
to
support
the
high
performance,
sensitive
work,
note
and
all
those
kind
of
the
require
of
the
new
binding
support
here
and
the
please
share
your
opinion,
and
so
so
all
those
use
cases
listed
here.
It
makes
sense
to
me
and
and
also
I
saw
those
requirement
requests
in
the
past
and
yeah.
So
any
other.
A
The
next
step
is
just
to
incorporate
those
use
cases
into
our
into
the
dock,
and
then
we
can
carry
on
the
discussing
video,
the
architecture
and
yeah.
A
A
A
We
have
some
because
we
intel
build
the
plugin
and
the
scheduling,
plugin
and
other
things.
I
just
want
to
say
that
do
you
have
any
opinion
on
the
use
cases
and
what
you
are
thinking
about.
What's
next
step.
G
Oh,
that's
what
you
already
mentioned.
The
use
cases
is
something
what
we
know
about
for
quite
a
long
time
and
we
have
similar
things
and
similar
desires,
so
the
first
step.
What
swati
is
working
on
on
the
apology,
extender
plugin
for
scheduler?
It's
it's
good
step
forward
and
based
on
what
we
will
be
building
on
top
of
it.
So
I
don't.
I
don't
see
anything
needing
to
comment
at
the
moment
in
the
long
run
verbally
actually
mentioned.
G
One
interesting
scenario
is
what
distinguishing
between
the
containers,
which
have
alignment
to
devices
so
the
one
which
doesn't
really
care
about
what
devices
alignment,
or
vice
versa,
aligning
for
device,
but
not
aligning
for
cpu
and
so
on.
At
the
moment,
I
think
we
don't
have
neither
in
topology
manager
or
way
to
specify
what
nor,
in
in
the
scheduling,
primitives
or
import
spec,
to
specify
interconnect
between
or
dependencies
or
requirements
for
resources.
A
I
also
have
one
more
complicated
scenario,
especially
earlier
we
are
talking
about
the
sector
container,
so
kind
of.
After
all,
those
resources
we
talked
about
even
at
the
touch
base,
some
before
current
design
is
either
popular,
but
for
the
pneuma,
especially
for
you,
and
to
support
some
high
high-performance,
sensitive
work.
Note
so
they'll
maybe
have
that
clown
container
that
wall
and
they
may
have
some
helper
container
wheezing
off
the
parts
majority
time.
A
There's
no
problem,
but
sometimes
it
is,
they
may
be
next
to
both
the
helper
container
or
application,
which
is
a
really
performance.
Sensitive
workload
share
the
single
node.
They
may
have
like
the
performance
impact
to
that.
So
I
didn't
see
that
in
the
past,
so
I
mean
in
the
burger
environment.
So
so
obviously
this
is
too
complicated
at
this
moment.
I
just
threw
out
here-
and
we
are
that's
not
unless
it
should
be
the
first
things
we
need
the
initial
we
need
address,
but
I
just
want
to
listen
here.
G
Yeah
and
something
what
I
said
back
in
may
when
I
was
doing
the
presentation
about
our
project,
so
we
we
have
scenarios
of
one
application.
As
you
said,
what
is
a
high
performance
container
which
require
strict
alignment
for
all
the
resources
and
one
there
is
helpers
like
loggers
or
something
like
side,
cars
which
support
a
new
application.
G
G
But
again,
we
need
to
find
the
way
how
how
to
bring
in
lab
stream
and
report
stack
specification,
how
we
are
specifying
these
dependencies
of
our
resources.
A
That's
that's
beyond
a
little
bit
beyond
the
scheduling.
That's
also
have
to
be
how
we
represent
the
abstract,
the
requirement
for
such
requirements,
so
at
the
api
level.
So
that's
another
powder
spike
upgrade
enhancement
issue.
So
unless
we
can
figure
out
that
one
then
there's
it's
just
hard
for
us
to
talk
about
how
to
support
those
things.
G
So
speaking
about
the
scheduling
and
and
then
actually
this
resource
topic,
so
one
thing
which
we
were
discussing
together
with
alexey
and
swati,
and
one
marcus
from
nfd
the
way
how
we
will
be
exposing
the
topology
and
resources
available
on
the
node
to
receive
these
to
the
scheduler
extension.
So
practically
we
come
up
with
a
data
structure
which
allows
us
to
describe
all
kind
of
zones,
all
kind
of
moma,
topologies
or
cpu
approaches
or
any
other
resources
in
genetic
way.
G
So
as
soon
as
we
do
it
land,
we
will
have
enough
information
in
the
scheduler
to
actually
make
with
this
theorem.
So
next
it
will
be
to
change
the
algorithm
of
a
topology
manager,
so
instead
of
thinking
in
the
pneuma
combinations
to
actually
think
about
like
resource
zones,
contaminations
and
availability
of
resources
in
those
zones.
So
we
are
we
moving
step
by
small
steps
into
what.
A
A
And
we
are
looking
forward
for
the
design
architecture
and
the
coming
and
for
the
new
ma,
nema
awhile
scanning
and
the
incorporators
use
cases
there.
Anyone
can
discuss.
Oh
there's
the
oh
there's,
someone
share
some.
The
tiny
cluster
will
result.
Do
you
want
to
talk
about
sorry
if
anyone
interested
so.
A
A
E
E
Yeah,
I
think
gerkley
just
spoke
through
it,
and
he
mentioned
that
these
are
some
of
the
findings
from
a
survey
of
how
kubernetes
is
now
used
in
telco
environment.
That's
my
understanding.
We.
E
D
It
was
for
for
me
I
I
had
some
method
instruction.
I
couldn't
get
so
yes,
that
what
I
shared
is
just
the
presentation
which
was
presented
today
in
the
elephant
technical
event-
and
I
just
wanted
to
highlight
some
facts
from
here
like
the
main
thing-
is
that
out
of
the
40
telecom
operators,
87
percent
is
already
using
kubernetes
and,
from
these
more
than
half
are
using
kubernetes
in
production.
D
D
So
this
is
why
we
need
these.
These
telecom
specific
features
incubators
to
support
these
these
these
users,
so
they
don't
need
to
maintain
different
clusters
for,
for
the
real
time,
workloads
and
the
in
the
normal
time.