►
From YouTube: Multi-Network community sync for 20230517
Description
Multi-Network community sync for 20230517
A
But
yeah
last
week
we
we
discussed
about
the
Dynamic
resource
allocation,
that's
already
an
alpha
kubernetes
and
then
our
other
clip
the
QRS
resources
clip
and
how
they
might
fit
in
within
some
of
the
multi
networking
use
in
this
case
is
and
then
for
this
week.
A
B
A
So
this
proposal
is
about
improving,
like
quality
of
service
of
applications,
kubernetes,
okay,
General
qos
mechanism
for
for
different
kind
of
let's
say
resources
or
resource
sharing
or
throttling
I
start
with
the
slide.
I
took
a
look
at
the
kind
of
multi-network.
A
Requirements
skip
okay,
that
is
already
available.
You
know
the
enhancements
repo
and
try
to
kind
of
map,
not
those
user
stories
correctly
presenter
how
they
might
be
shared
with
with
the
different
mechanisms
that
we
have
have
in
place
or
the
all
the
proposals
or
mechanisms.
So
here
we
have
like
I
have
the
user
storage.
Then
I
have
like
three
three
different
Technologies
or
proposals.
A
The
first
one
is
the
tra
Dynamic
resource
allocation,
which
is
so
far
like
device
allocation
and
attachment
a
very,
very
flexible
way
of
doing
that
that
we
discussed
in
quite
detail
last
week,
then
the
other
column
is
cures
resources.
This
skip
that
this
presentation
is
mostly
about
and
the
third
one
is
in
your
eye,
node
resource
interface,
which
is
a
plug
plugin
mechanism.
A
Now
very
new
experimental
thing
in
in
the
cryo
and
container
the
runtime
at
the
moment,
so
kind
of
plugable,
runtime
level,
level,
extension
interface,
so
generally
I
think
that's
kind
of
dra
would
probably
fit
or
be
it
be
able
to
kind
of
resolve.
As
far
as
I
understand.
A
My
best
understanding
kind
of
all
the,
although
you
use
it
scenarios
if
any
so,
it's
very
like
flexible,
flexible
and
flexible
mechanism
to
like
have
a
parameterization,
multiple,
multiple
kind
of
devices
or
or
interfaces
and
and
so
on,
but
it's
also
kind
of
heavy
mechanism.
A
In
sort
of
that
you
need
to
have
the
scheduling
is
heavier
and
you
need
to
have
like
no
neutral
node
per
node
driver
to
do
that
and
do
the
kind
of
allocation
and
and
management
of
the
interfaces
so
in
in
that
sense,
I
put
some
green
green
boxes
to
the
keywords:
resources:
okay,
that
it
could.
In
some
scenarios
the
Qs
resource
cap
probably
probably
help
or
be
an
option
to
implement
Implement
some
scenarios.
A
A
A
Let's
go
forward
so
excuse
proposal,
it's
about
adding
a
sort
of
new
type
of
resource
to
kubernetes,
and
the
goal
is
like
General
to
be
able
to
improve
the
quality
of
service
of
application
for
enabling
some
technologies
and
mechanism
mechanisms
that
are
so
far
like
not
available
in
kubernetes
kubernetes.
So
we
are
talking,
for
example,
cat
and
cash
and
memory
memory,
bandwidth,
control
or
or
like
some
bocao
c
groups.
C
group
is
contrast,
are
two
examples
that
we
are
targeting
here.
A
Then
we
have
also
we
prototyping
with
with
network
GEOS
in
this
space
as
well
There's
the
link
link
to
the
cap
and
well
at
the
moment,
we're
kind
of
targeting
for
Alpha
in
kubernetes
128.
A
And
to
get
this
to
basically
about
adding
a
new
fundamental
resource
type
to
kubernetes,
so
instead
of
assigning
I
didn't
certain
certain
identifiers,
like
bronze
silver,
gold
to
containers
and
pods
so
kind
of
tagging.
Those
with
audit
IFR
instead
of
allocating
some
specific
amount
of
resources
or
or
allocating
some
like
numerical
capacity
and
fun
general
idea
is
that
multiple
containers
support
can
be
assigned
to
the
same
for
us
and
One.
A
Design
principle
here
is,
is
that
the
curious
resources
would
be
as
opaque
to
kubernetes
as
possible,
so
configuration
and
management
of
this
Qs
resources
would
be
handled
handled
in
the
content,
runtime
or
or
below,
but
anyway,
below
below
kubernetes.
So
kubernetes
only
only
knows
what
types
of
doors
resources
are
available
and
of
which
nodes
and
which
classes
of
each
type
of
curious
resource,
but
the
kubernetes
doesn't
need
to
know
about
the
implementation
details,
so
that's
opaque
to
kubernetes
as
possible.
A
A
The
runtime
is
responsible
for
that
and
then
in
step,
two
runtime
advertises
those
curious
resources
to
Google
it
and
then
cubill
it.
In
turn,
in
step,
three
updates:
the
node
status.
A
With
those
curious
resources,
so
in
this
case
example,
we
will
have
three
cures:
resource
type
slog
a
b
and
c,
and
then
some
classes
like
for
resource
able
to
have
gold,
silver
and
bronze
classes,
and
so
on
available
on
this
node
X
and
then
in
step.
Four
report
is
created
an
API
server
and
it
would
have
some
requests
for
Curious
resources.
A
The
requests
are
really
simple:
like
resource
name,
a
class
name
type
of
key
value
pair,
basically
so
no
no,
no
arbitrary,
parameterization
of
of
that
class,
so
just
the
resource,
type
and
class
name,
and
then
the
scheduler
picks
that
picks
the
product
up
and
do
it
does
that
normal
filtering
or
possibly
scoring?
And
it
can.
It
says
that
okay,
node
X
is
actually
able
to
satisfy
the
Qs
resource
requests,
so
node
X
has
for
resource
a
it,
has
class
gold
available
and
for
resource
C.
It
has
a
class
high
priority
available.
A
Then
it
schedules
it
under
the
node
X
equivalent
takes
the
Pod,
spec
and
then
cable.
It
then
over
CRI
gives
the
information
the
runtime
about
about
the
Qs
resource
assignments
and
then,
in
the
last
step,
number
eight.
A
runtime
and
then
actually
actually
enforces,
or
does
the
tricks
too
actually
apply
apply
whatever
the
resource
Curious
resource
assignments
mean,
but
anyway,
within
a
forces,
resource
assignment.
C
Yeah
Marcus
I
had
a
question.
Yeah
is,
isn't
the
device
driver
plug-in
model
very
similar
to
this,
except
that
it
talks
to
cubelet
directly
instead
of
through
the
runtime?
Is
there
a
reason
why
that
wouldn't
solve
providing
a
cost
resource
through
a
device
driver
plugin.
A
Yes,
yes,
I,
guess
one
main
difference
is
that
with
those
you
always
have
some
amount
of
some
like
capacity,
so
you
have
like,
let's
say:
vendor.io
Slash
accelerator
device,
X,
and
then
there
is
some
numerical
capacity
like
10
available
on
this
node
and
and
here
we
are
basically
having
Plus
IDs.
A
So
like
like
tags,
you
know
in
a
sense,
so
different
different
kind
of
mechanism
in
that
that
sense,
so
you
don't
necessarily
allocate
any
number
of
let's
let's
say-
or
there
might
be
no
capacity
for
for
this
certain
plus,
if
it's
let's
say
some
throttling
parameters,
so
you
can
have
lost,
apply
those
parameters
to
us
as
many
many
any
containers
or
or
pods.
As
you
like.
C
So,
just
to
clarify,
if
a
board
says
it
wants
to
use
cross
rests
C.
C
A
C
C
A
But
possibly
or
if
you
know
your,
if
you
know
your
workloads,
you,
you
know
that
you
want
to
give
give.
For
example,
your
your
like
High
high
priority,
like
container
in
in
a
pod
like
better
priority.
So
you
probably
want
to
give
that
let's
say
plus
gold
and
then
then
for
for
some
like
plugins
or
some
other,
not
that
important
sidecar
put
it
put
it
into
in
the
low
priority
so
that
it
would.
It
wouldn't
interfere
with
your
with
your
important
important
workload.
A
Yeah
then
yeah,
okay,
so
then
yeah
it
proposal
in
the
further
further
further
implementations
in
the
future
yeah
we
have
kind
of
plans
to
or
yeah
we
have
plastic
extend
the
resource
quota
mechanism
in
in
kubernetes
and
and
the
limit
ranges
as
well
to
so
to
you
could,
but
from
the
admin
level,
restrict
the
usage
of
of
some
classes
for
public
per
namespace,
so
limit
like
completely
ban
some
classes
or
or
the
limit
limit.
The
usage
usage
of
classes.
A
A
So
we've
extended
the
cni
spec,
our
parsing
of
the
CNS
packing
in
containerd.
They
have
a
new
kind
of
top
level
field
or
qos
under
which
you
can
specify
specify
no
classes
in
this
example
on
the
right
like
fast
and
slow,
and
then
you
can
specify
the
capacity
and
then
we
use
the
capabilities
mechanism
in
this
Pro
concept,
actually
kind
of
enforce,
enforce
the
parameters
or
deliver
the
parameters
to
the
CNR
plugin.
A
A
C
A
We
could
go
ahead
and
yeah
okay,
cool
yeah,
so
this
is
the
OneNote
cluster
running
pretty
recent
present
version
of
kubernetes
and
container
d,
with
a
proof
of
concept,
code
code
running
and
we
have
or
I
have
limited
this
implemented
this
network
cures
here.
A
So,
let's
see
first
the
kind
of
how
the
Sienna
concrete
Loops
like
so
here
like
simple,
simple,
the
basic
plugins
setup
is
really
simple,
bridge
and
and
then
bandwidth
plug-in
here,
and
then
we
have
a
few
qos
classes
defined
for
this,
so
slow,
normal
and
and
fast
and
let's,
for
example,
in
this
past,
you
have
like
capacity
of
only
one
and
then
then
we
have
capability
as
well.
All
the
only
bandwidth
bandwidth
capability,
Define
defined
for
this
or
any
of
any
of
these
classes,
and
then,
if
I,
take
a
look
at
the
note.
A
We
can
say
that
there
are
like
pod
level
keyword
resources,
only
one
so
net
resource
and
it
has
like
Fast
normal
and
slow
classes
available,
and
then
there
are
like
capacities
so
fast,
one
normal
kind
of
eight
users
and
slow,
slow
Network.
You
can
have
infinite
number
of
users,
and
then
there
are
some
level
container
level
curious
resources
as
well
like
plot
guy
or
product
local
disk,
IO
and
then
rdts
for
the
cash
and
memory
bandwidth
controls
and
then,
like
a
simple,
odd,
would
look
like
this.
A
So
you
would
have
on
the
Pod
stack
this
curious
resources
or
could
have
on
this
pod
level,
kind
of
viewers,
resource
requests
like
name
net
and
then
the
class
fast
and
then
per
container.
You
can
also
have.
We
are
not
interested
dosing
this
this
demo,
probably
that
much
but
similar
similar
thing
for
for
container
level
resources
and
then,
if
I
run,
that
that
workload.
A
A
A
C
Yeah
and
I
thought
there
are
a
couple
of
questions,
so
so
the
reason
why
this
network
course
is
in
the
cni
config
I
mean
every
time
you
need
to
add
a
new.
C
You
know
class
you
need
to
put
in
the
cni
config
or
have
some
tool
change
it
in
the
in
all
the
nodes.
That's
outside
of
the
skip.
A
And
I
think
yeah.
Actually
sorry
sorry
to
interrupt.
So
basically,
this
cap
is
is
really
really
about.
The
the
cap
itself
is
really
about
the
kubernetes
API
and
the
CRI
API
between
the
with
the
equivalent
and
the
runtime.
So
all
the
cni
bits
and
kind
of
the
implementation
details
of
how
specific
use
resource
or
mechanism
like
let's
say,
Network
keyword
or
this
cat
bandwidth
allocation
or
or
or
whatever
block
I
o
or
some
other
Qs
mechanic.
C
And
so
when
I
mean
I,
don't
know
enough
about
the
CRI,
but
it
to
me
the
CRI
doesn't
do
much
when
it
comes
to
networking
and
network
stuff
yeah,
and
in
this
case
its
job
is
to
only
like.
Why
is
the
CRI?
Why
does
it
even
need
to
know
about
Network
cost
classes?
What
does
it?
What
is
it
actually
doing.
A
Then,
when
when
report
is
created,
then
the
CRA
is
only
needed
to
when
the
Pod
sandbox
is
created,
to
able
to
say
that
okay,
this
pod
belongs
to
this
network
cloud
and
that's
that's
basically
it
so
nothing,
nothing
more,
and
then,
when
runtime
gets
that
okay
Network
class,
let's
say
first
then
at
the
in
this
proof,
comes
with
other
kind
of
thought:
sandbox
creation
and
then
the
network,
her
network
setup
set
of
it
then
actually
does
whatever
the
QRS
class
means.
C
I
see,
and
so
so
certainly
back
to
my
earlier
question
is:
if
the
device
plugin
interface
only
accepts
numeric
values,
which
is
the
major
concern
of
going
down.
That
path,
is
that
it
would
be
interesting
to
see
if
we
should
evolve
that
interface
to
support
this
use
case.
Is
that
always
inspired
to
support
this
use
case
Services
more
than
that.
B
Resources
is
not
to
teach
kublet
what
it
actually
means
so
like
to
let
the
all
the
implementation
details
out
of
the
kubernet
interface
is
hard
coded
to
like
a
certain
level
of
assumptions
like
where
countable
extended
resources
is
one
thing
so
like
you
cannot
have
Infinity
amount
of
resources
and
when,
like
all
the
advertise
resources,
is
equal,
meaning
what
like
what
couplet
will
make
a
decision
which
one
to
allocate
and
when
like
it
has
like
bunch
of
parameters
which
is
related
only
to
devices
like
accelerators
and
so
on.
B
So
extending
wet
interface
is
pain
and
practical
level,
like
the
whole
reason
why
things
like,
for
example,
like
Dynamic
resource
allocation
was
implemented
or
what
this
QRS
classes
was
implemented
is
because,
like
this
yeah
device
manager,
device,
plugins,
Beyond
of
being
refactored.
C
B
Yes,
so,
like
Remain,
the
main
design
differences
between
what
was
done
for
device
plugins
are
compared
to
What,
dra
is
doing
or
what
qos
clusters
doing
is
what
Google
doesn't
know
anything
about
what
it
is
and
and
runtime
to
some
extent
also
doesn't
know
what
it
is.
What
we
can
do
and
what
is
part
of
a
protocol
between
the
components
is
but
like
it
knows
what
what
is
discovered-
and
it
knows
like
when
we're
port
or
containing
a
request,
something
so
it
passes,
will
identifiers
and
when
we're
like
well
low
level.
B
Implementation
actually
expands
were
also
energy
fires
to
some
some
of
the
parameters,
like
example,
what
Marcus
was
showing
in
his
cni
config,
so
CMI
config
defines
what
like
I
know.
The
qos,
Fubar
and
I
know
the
capacity,
and
that's
the
only
information.
What
could
like
runtime
passes
to
cool
blood
and
Kublai
passes
to
scheduler,
and
vice
versa,
like
when
we
put
this
requesting
it
says:
I
want
to
use
qos
class
full
bar
and
Google
just
for
passes,
with
a
string
full
bar
down
to
run
time
and
in
cni
invocation
pass.
B
This
full
bar
is
actually
expanded
to
like
injected
with
capabilities
fields.
B
A
Okay,
yeah
and
then
one
yeah
one
one
one
more
like
aspect
of
these
skewers
under
kind
of
dried
coupling,
that
the
runtime
is
that
many
of
these
gross
mechanisms
are
kind
of
really
tightly
tied
to
the
kind
of
oci
level.
A
Let's
say
container
life
cycle
and
and
kind
of
you
need
to
do
the
right
things
in
the
at
the
at
the
very
kind
of
right
right
moment
in
the
kind
of
pod
or
containers
life
cycle
and
then
having
this
device.
Plugins
mechanism
like
outside
runtime
plugins,
is
not
really
feasible,
at
least
with
the,
with
the
current
current
design
and
yeah
kind
of
pro
Beyond
repair
on
that
on
that
side.
So.
C
So
so
I
mean
the
device
plugin,
which
is
also
used
for
Sri
and
a
bunch
of
other
use
cases
right.
It
is
also
the
one
that
is
doing
the
actual
enforcement
or
implementation,
because
cubelet
is
a
pass-through
even
for
the
device
plugin.
As
far
as
I
understand
I
guess
what
you're
saying
is
that
I
mean
kubernet
is
a
bastard
for
device
plugin,
and
it
seems
that
cubelet
is
a
pass-through
for
CRI.
In
this
particular
case
as
well,
the
I
mean
the
only
difference.
C
I
could
sort
of
glean
from
the
demo
is
that
at
least
with
the
networking
use
case,
whatever
information
you
pass
through,
CRI
gets
passed
on
to
the
cni,
so
the
cni
doesn't
need
to
go
and
look
at
the
you
know,
look
up
the
information
from
some
other
resource
right.
It's
getting
it
through.
The
cni
call
right.
A
C
C
You
know
it
could
be
beneficial,
but
then
every
time
you
want
to
add
some
parameter
or
some
you
know
you
want
to
modify
I
mean
the
good
thing
about
the
earlier
approach
would
be
that
if
you
want
to
change
the
spec
to
add
a
new
field,
you
know
the
cni
would
need
to
change
versus
the
CRI
and
I.
Don't
know
if
cubelet
would
need
to
change.
If
is
it
opaque
for
kubernet
or
not
in
this
particular
case,
so
that
is
I
guess
a?
C
C
Let's
say
that
you
know
you
have
this
course:
slow
capabilities,
bandwidth,
Etc
right,
let's
say:
there's
one
more
field.
Let's
bandwidth
right,
I
have
no
rate
limit
or
something
you
just
think
of
something
right
is
that
so
you
would
just
need
to
change
the
cni
conflict,
because
the
CRI
would
map
The
Source
name
to
to
the
name
of
slow
football
normal
and
take
whatever
capabilities.
Are
there
and
then
pass
it
on
to
the
cni
call?
Is
that
how
it
would
work?
Yeah.
A
Exactly
so
yeah
from
the
CRI
cable
at
to
run
time,
you
only
get
this
Network
and
then
class
name
slow
and
then
the
in
this
well
in
this
car
approval
concept,
tender
runtime,
okay,
notice,
that
okay,
this
pod
belongs
to
class
low,
and
then
it
goes
into
the
takes
a
look
at
the
cni,
config,
okay,
slow
means,
then
capabilities
and
then
pass
whatever
capabilities.
A
It
has
and
passes
that
to
all
the
all
the
plugins
that
are
interested
in
this
capability,
so
yes,
okay
and
then
yeah
so
and
then
yeah
I'm
in
the
perspective
of
multi-networking.
Definitely
this
iPhone
won't
I.
I.
Don't
believe
that
this
curious
resource
mechanism
would
be
a
kind
of
managing
managing
devices,
or
anything
like
that.
That
said
so,
that
would
be
tra,
but
possibly
just
to
kind
of
get
and
kind
of
give
you
the
understanding
what
this
Gap
is
about.
A
So
possibly
this
could
be
yeah
used
in
some
like
multiple
scenarios
to
like
pick
the
kind
of
default
Network
or
something
like
that.
So
you
would
have
just
capability
whatever
and
then,
through
this
capabilities
mechanism,
pass
down
some
parameters
to
models,
or
we
could
add,
like
environment
variables
here
as
well,
but
anyway,
I'm
gonna
pass
down
some
parameters
to
the
Sienna
Plugin
or
plugins.
C
So
if
the
cni
plugin
doesn't
need
to
go,
look
at
something
in
the
API
server
and
it
could
get
everything
through
the
cni
call
add
or
delete
or
whatever
it
is
yeah
I
guess
this
could
be
useful,
but
also
I'm,
not
sure
if
changing
the
cni
config
dynamically
every
time
you
change,
you
add
a
new
class
to
move
class
or
change
Fields.
You
have
to
change
the
config
and
you
need
a
tool
for
that.
I'm,
not
sure.
C
If
that
is
a
typical
pattern
on
kubernetes
I,
don't
know
if
others
have
have
any
comments
about
that
I
mean
I
thought,
that's
what
CRS
were
for,
but
maybe
you
know
well.
B
B
Second
thing
like
like
some
of
the
cni
plugins,
like
with
network
way
like
when
the
demon
set
is
deployed
by
provision
where
all
I'm
saying
I
can
fix.
So
it's
it's
demanded
by
by
your
nature
and
runtimes,
are
handling
what
like,
if,
if
everything,
if
anything
in
with
cni
configuration
directory
changes
it
rarely
it's
the
configuration
so
the
next
ports,
which
will
be
started
that
we'll
be
using
the
new
configuration
files.
B
C
No
I
and
I'm
sorry
I,
understand
that
part,
but
adding
a
new
VLAN
or
which
you
know
translates
to
perhaps
adding
a
new
network
is
a
dynamic
enough
change
that
we
would
expect
that,
for
example,
there
are
Trunk
ports
where
you
don't
really
need
to
add
a
new
VLAN
on
the
interface
to
say
that
you
know
this
VLAN
is
available
on
the
smoke
right
and
but
you
would
want
to
model
it
somehow
so
that
a
pod
could
say
when
I
send
traffic.
Please
make
sure
it
goes
out
with
this
VLAN
tag.
C
B
Here's
what
two
big
differences
like
like
materials
classes-
it's
considered
to
be
like
for,
let's
say
like
scenarios
when
you
need
to
select
the
default
Network
like
one
or
another,
and
we
also
usually
like
pre-provision
it
and
at
what
node
start
part-time.
B
We
are
picking
back
on
what
runtime
can
re-read
the
configuration.
So
we
can
update
those
resources,
but
it
we
are
not
requiring
it
so
what's
another
one
was
particular
Villa
needs
to
be
provisioned,
it's
better
fit
into
GRE
usage
pattern.
C
Yeah,
so
we
should
talk
more
about
the
dra
and
I,
don't
know
if
folks
on
the
Forum
have
read
up
on
it
or
seen
a
demo
of
it,
but
it's
possibly
of
more
interest
in
the
multinetworking
space.
The
dra
part
I
I
have
a
bunch
of
questions
in
that
area.
Yeah,
so
is
that
I'm
not
sure
do
we
have?
Is
that
something
we
should
schedule
for
the
next
session?
A
Yeah
I
think
that
would
be
interesting.
Yeah,
yeah,
okay,.
C
A
I,
don't
yeah
I
agree
on
it.
I.
Definitely,
as
I
said,
I
definitely
agree
that
the
dra
would
be
the
well
in,
in
my
opinion,
if
any
of
these
kind
of
the
solution
that
would
kind
of
be
able
to
solve
the
user
stories
that
you
have
listed
but
yeah
that's
kind
of
just
sharing
information
about
the
QRS
resource
cap
and
how
that
might
be
in
some
some
scenarios
possible
to
kind
of
use
that,
but
definitely
it's
it's
not
this
curious
resource
Gap
is
not
not
kind
of
okay.
So.
C
We
could
we
could.
We
can
add
it
to
the
agenda
item
next
week
and
and
Machi
will
be
back
so
you,
you
know
we'll
have
more
context
about
it,
because
I
remember
watching
myself,
I'm
sorry
I
forgot
this
person's
name
running
into
someone
in
kubecon
us
and
Detroit
last
year
and
they
were
presenting
dra
back
then.
A
C
C
At
that
point
we
went
and
read
through
the
cap,
I'm,
not
sure
if
the
cap
has
changed
after
that
point,
the
dra
kept.
That
is,
but
we
have
a
at
least
I
have
a
lot
of
questions
specifically
about
in
my
mind.
For
some
reason,
dra
keeps
mapping
to
helping
with
scheduling,
and
if
it's
more
than
that,
then
maybe
it's
time
to
refresh
at
least
my
knowledge
of
it.
So
yeah.
B
If
I
may
reply,
because
you
previously
was
asking
about
what
device,
plugins
and
so
on
so
helps
those
scenarios
similar
to
the
device
plugins
all
right
it
it
also
in
the
current
implementation
talks
about
like
where,
let's
say,
like
PCI
devices
or
interactive
devices,
so
like,
if
your
VF
provision
isn't
support
as
a
PCI
pass
through
device,
let's
say
for
gpdk
usage
GRE
within
current
shape.
It
can
help
and
the
main
thing
what
it
can
help
is
to
pass
the
parameter.
B
So
you
can
say
I
want
VF,
which
is,
let's
say,
connected
to
particular
trunk
port
or,
let's
say
I
want
to
provision
like
something
to
to
particular
Villa.
Like
my
my
thoughts,
so
fifth
interface,
and
so
on.
So
like
it,
it
allows
you
to
do
the
parameters.
B
It
allows
you
to
like
Dynamic
reconfiguration
of
a
accelerator
devices,
and
it
allows
you
to
to
put
like
pass-through
devices,
but
it
cannot
handle
the
net
like
network
devices
in
terms
of
like
Linux
network
interface,
things,
and
this
is
where
we
want
to
have
like
this
plan
being
done
for
POS
resources
and
4D
array
to
also
handle
those
kind
of
interfaces
like
like.
C
So
so
I
think
that's
the
part.
I
also
have
some
questions
on
the
I
mean
the
resource
management.
It
seems
like
what
is
the
underlying
resource
that
is
going
to
back.
You
know
the
network
path
for
a
new
network
that
that
a
pod
wants
to
use
which
is
either
VA
for
a
salary
or
whatever.
It
is
that's
one
part,
but
the
representation
of
the
network
itself,
in
other
words,
is
that
a
vxlan
network
right
I
I,
want
to
connect
a
pod
to
a
vxlan
network,
not
a
physical
Network.
C
So
what
is
the
vxline
network
that
I
want
to
create?
What
is
the
tunnel
parameters?
What
is
the
other
end
of
the
you
know,
tunnel,
etc?
Those
kind
of
definitions
also,
once
you
assign
a
once
a
bot,
says
I,
want
to
connect
to
the
network,
red,
blue
and
green,
where
red
is
a
VLAN
blue
is
vxlan
and
green
is
something
else.
How
do
we
do
ipam
for
some
of
these
right?
Where
does
the
is?
Where
do
we
Define?
How
ipam
is
going
to
get
done?
Is
it
coming
from
the
network?
C
Is
it
coming
from
somewhere
else
Etc
and
the
other
part
is
after
the
Pod
has
come
up?
How
do
we
represent
these
networks
in
other
kubernetes
Concepts
like
Services?
When
you
create
a
service?
Would
you
want
to
say
that
I
want
a
service
for
the
blue
Network
I
pick
my
pick,
these
set
of
PODS
that
are
participating
the
blue
Network
and
create
a
service
for
them
right
and
those
parts
could
be
in
blue
red
and
green.
C
But
you
only
pick
the
interface
from
the
Google
can
use
that
as
a
back-end,
so
representing
that
interface
inside
a
pod
after
the
Pod
has
come
up
so
that
it
can
be
used
in
other
second
level,
constructs
like
Services
Network
policy,
Etc
and
doing
ipam,
while
bringing
up
the
Pod
and
identifying
how
do
I
plumb
the
networking
stack
on
Linux
so
that
it
can
go
to
the
right
tunnel
or
the
right,
VLAN,
etc.
B
Like
just
to
to
reply
to
some
of
your
questions,
so
regarding
ipam
and
like
all
the
parameters,
let's
say
stuff
like
for
vx1
provision
it
can,
it
can
fit
into
a
semantics
what
gay
race
do
so
you
can
see
you
can
have
like
where
your
custom
parameters
which
say
I
want
vxlan
I
want
to
use
with
those
parameters,
and
all
of
this
will
be
in
your
vendor
specific
logic.
So
it's
not
part
of
a
core
kubernetes.
You
don't
need
to
change
anything.
B
You
know
so
that
easy
part
regarding
iPhone,
like
my
understanding
right
now,
is
done
again
like
the
part
of
the
cni
config.
We
we
can
discuss
what
will
be
robust
method
of
doing
that.
So,
if
we
have
like
still
piggyback
on
we're,
seeing
my
specification
when
we
can
run,
for
example,
like
report
this
different
cni
config
or
with
like
doing
like
few
invocations
with
different
scene,
I
can
fix
it's
also
possible,
but
again.
B
B
Regarding
Services
again
we
have
some
ideas:
how
we
can
reference
what
so,
instead
of
like
Port
selector,
we
can
point
to
the
claims,
let's
say
like
reclaim,
which
says
like
blue
network.
We
can
point
it
to
to
those
claims
in
reports
and
when
it
can
get
from
status.
Fields
like
API
business
profit.
C
We
should
we're
probably
out
of
time
this,
the
session
anyways.
We
can
add
this
to
the
agenda
item
for
next
week
and
you
know
Machi
can
come
and
help
coordinate
that
part,
but
all
right
so
I
I
does
anyone
else.
Have
any
other
comments,
questions.
A
B
Marcus,
if
you
can
bring
one
for
a
few
seconds
with
slide
with
different
user
stories,
yeah.
A
B
So
I
just
wanted
to
again
comment
about
this
particular
thing
so
like
there
are
several
like
moving
pieces
and
in
all
of
this,
like,
whereas
Theory,
where
sqls
resources
for
results
so
another
thing
which
is
called
then
right,
node
resource
interface
like
plug-in
mechanism,
one
where
container
runtime
sites,
so
some
of
them
can
help
with
different
scenarios
and
like
well
integration
to
this,
like
third-party
entities
like
services
and
so
on.
It's
also
like
one
on
big
open
questions,
but
we
think
what
Marcus
is
doing
with
qas
resources.
B
It's
really
it's
a
more
convenient
way
to
password
parameters,
to
a
plugins
like
models
or
like
bandwidth,
instead
of
annotations.
So.
C
C
I
think
that
came
out
quite
clearly
thank
you
for
that
and
I
I
I
guess
we'll
just
have
to
see.
If,
if
you
have
to
go
to
the
API
server,
to
look
up
some
CR
anyways,
does
it
help
I
mean?
Does
it
matter?
If
the
information
comes
through
the
cni,
you
can
also
get
the
same
information
through
the
CF
lookup.
That's
that's!
What
I
was
trying
to
look
too
well.
B
So
I
think,
what's
the
thing
we're
trying
to
avoid
it,
we
want
to
pass
enough
information
like
up
to
to
a
stack
like
to
Google,
to
scheduler,
to
make
a
decision
like.
Should
we
spot
running
on
this
note
or
not
and
at
the
same
time
like
not
to
teach
for
kubernetes
about
like
complex
things
like
what?
What
will
strength
means
so
like
pass
enough
information
to
apply
whatever
resource
constraints
is
needed
to
a
workload
without
like
forcing
you
to
look
up
information
somewhere
else?
That's.
B
Well
again,
what's
the
reason
of
this
table
so
like
when
gra
can
pass
a
lot
of
information
down
to
like
to
to
consume
or
on
one
note
and
what
what
was
specifically
designed
for
device
plugins,
where
we
can?
What
fit
all
we
needed?
Parameters
like
like
Mount,
environment
variables,
device
notes
like
hooks
or
whatever,
like
annotation
additional
ones,
if
needed
so
like
where,
when
we
injecting
device
into
a
container
or
like,
we
don't
need
to
to
go
and
fetch
information
anywhere.
B
So
we
for
for
Network
scenario
of
GRA
usage.
We
want
to
have
with
exactly
the
same
thing
like
figure
out
what
information
needs
to
be
passed,
so
you
can
get
the
same
experience.
I
see.
Okay,
okay
and
qos
is
just
like
more
simple
way
for,
for
things
like
what
can
be
expressed
instead
of
annotations
like
including
like
quarters
and
default
mechanisms,
so
again
like
putting
put
in
more
order
instead
of
like
wild
wild,
west
or
sanitations.
So.
C
That's
that's
true,
but
but
I
think
what
I'm
going
to
call
out
is
that
networking,
as
you
can
imagine,
is
not
a
one-size-fits-all
right.
Every
thought
can
have
a
completely
different,
a
completely
different
default.
Network,
every
part
could
say,
body
could
say
red
is
my
default
and
Part
B
could
say:
blue
is
my
default,
so
it's
a
very
part
specific
configuration
and
if
we
have
a
way
to
pass
that
around
without
going
to
the
prospect,
that's
great
right,
yeah.
B
A
C
Of
yeah,
these
configurations
that
I'm
talking
about
has
nothing
to
do
with
scheduling.
Right
I
mean
scheduling,
is
basically
saying
the
part
has,
can
I
put
the
bar
in
the
node
after
that
decision
has
been
made.
The
the
stuff
that
I'm
talking
about
is
how
do
I
set
up
the
pods
Network
Plumbing
right
so
for
the
scheduling
part
I
understand
I
mean
either
you
know
we
use
device,
plugin
method
or
dra
method
or
one
of
those
right
to
identify.
Can
the
spot
fit
in
on
the
floor.
C
Does
all
the
requirements
of
the
Pod
need?
It
means
it
needs
red,
blue
and
yellow.
Are
those
networks
available
on
this
node
right?
That's
that's
that
I
I
I
can
see
that
right.
The
the
part
is
like
okay,
they
are
available
now.
How
do
I
plumb
this
information
and
which
of
these
networks
is
the
default
for
this
particular
part
right
now,
so
it's
beyond
scheduling.
That's
that's.
Why
I
mentioned
the
last
team
meeting
as
well
that
there's
stuff
that's
happening.
Beyond
skating
scheduling
is
just
the
first
step
for
the
network
from
BPS.
C
B
In
case
OS
was
scheduling
also
inside
like
decision
chains,
because
again
like,
like
you,
can
express,
with
default
network
using
qos
classes
like
red,
blue,
whatever
else,
but
not
all
of
those
Network
might
be
provisioned
on
all
of
your
cluster
nodes.
So
it
will
help
to
select
like
if
a
port
says
I
want
blue
as
default
Network.
It
will
be
scheduled
only
on
the
Node,
where
it
can
be
done
and.
C
It
does
tell
cubelet
and
cubelet
does
tell
the
scheduler
what
is
available
on
each
node.
That's
enough
to
get
the
scheduler
to
decide
whether
to
put
the
power
on
the
note
or
not.
The
question
is:
is
the
network
available
there
or
not?
That
is
the
first
question
once
that
is
answered
and
you
land
a
part
on
the
Node,
then
the
plumbing
for
that
part
on
the
Node
is
handled
locally
on
the
cloud
through
cni
and
whatnot.
Yes,.
B
C
C
This
is
really
great.
I
think
I
hope
everyone.
All
those
also
you
know,
benefited
from
the
quas
demo.
I
I
think
I
have
a
better
understanding
of
what
the
course
cap
is
trying
to
do.
Thank
you.