►
From YouTube: Everyone Gets a Data Plane! Multi-Networking Kubernetes with the NPWG... - Dan Williams & Doug Smith
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Everyone Gets a Data Plane! Multi-Networking Kubernetes with the NPWG Spec - Dan Williams & Doug Smith, Red Hat
When one pod network isn't enough, the Network Plumbing Working Group's Multi-Network specification comes to the rescue. In this talk we'll present a detailed overview of the specification and how it helps enable Kubernetes applications in the multi-tenant, media-streaming, NFV, and performance-sensitive application areas. We'll dive into existing implementations like Multus CNI and demonstrate how it makes multi-networking a Kubernetes cluster simple for the app developer and cluster administrator. In addition, we'll cover the future direction of the specification and the Working Group, including what's on the table for Version 2 and the path to natively enhancing Kubernetes' networking capabilities.
To learn more: https://sched.co/GrWZ
A
A
My
name
is
Dan
Williams
and
I
work
on
the
networking
services
team
at
Red
Hat,
with
a
focus
on
container
networking,
kubernetes,
OpenShift,
container,
orchestration
and
other
related
projects
like
CNI
as
well.
I'm.
Also,
the
co-chair
of
the
kubernetes
network,
cig
lean
in
the
network,
plumbing
working
group
and
also
a
CNI
maintainer
hi.
B
A
So
quick
overview
of
what
we'll
be
talking
about
today,
first
off
we'll
talk
a
little
bit
about
kind
of
the
history
of
the
network,
plumbing
working
group,
why
it
was
created
and
how
it
kind
of
came
about
what
discussions
kind
of
precipitated.
It
will
also
have
an
overview
of
the
multi
network
specification
that
came
out
of
that
group
that
we've
been
working
on
for
the
last
year
and
was
finally
the
version.
A
So
what
do
we
actually
mean
by
all
of
this
for
multi
networking
for
moat
for
the
most
part
Cooper
applications?
They
don't
really
care
about
networking
beyond
the
fact
that
they
have
an
IP
address,
that
they
might
be
the
backend
for
a
service.
Everything
works
great
you're
in
the
cloud,
and
you
can
just
forget
about
the
network
and
build
your
application.
The
way
that
you
want
to
build
it
and
have
it
all
run
perfectly.
A
However,
there
are
some
cases-
and
this
is
you
know
the
things
that
we
found
out
and
tried
to
identify
over
the
last
year
in
the
plumbing
working
group,
where
that's
not
always
the
case
that
doesn't
always
work
out
for
everybody.
A
lot
of
these
workloads
are
have
special
requirements
on
the
network,
and
it
may
end
up
being
that
you
need
to
think
a
little
bit
more
about
the
networking
and
your
pod
needs
to
think
a
little
bit
more
about
the
networking,
as
you
try
to
accommodate
some
of
these
requirements
in
kubernetes.
A
So
what
do
we
actually
mean
by
any
of
these
workloads?
These
are
some
of
the
things
we
identified.
For
example,
if
you
have
specific
performance
and
bandwidth
requirements
for
your
application,
oftentimes
that
can't
be
accommodated
by
a
lot
of
the
cloud
providers.
So
a
lot
of
companies
are
looking
at
on-premise
deployments
for
kubernetes
to
kind
of
provide
their
own
hardware
that
might
have
or
be
able
to
provide
for
these
special
requirements
alongside
that
they're
also
latency
and
QoS
requirements.
A
You
don't
necessarily
want
that
to
impact
your
data
traffic
and
in
the
default
case,
most
clusters
are
organized
so
that
all
of
the
pod
data
and
control
traffic
for
the
cluster
go
over
the
same
network
link,
and
if
you
want
to
make
sure
that
your
application
has
specific
requirements
of
latency
QoS
guaranteed
bandwidth,
you
may
not
be
able
to
use
the
same
networks
that
the
control
traffic
goes
out
over.
Also,
some
businesses
have
requirements
around
segregated
networks
for
security
or
regulatory
or
whatever
means
that
mean
that
some
traffic
has
to
go
over
one
network.
A
Some
traffic
has
to
go
over
another
oftentimes.
That
means
physically
separated
networks
in
one
of
the
last
areas
that
we
identified
is
for
legacy
network
resources,
where
you
might
have
something
like
a
database
or
some
other
application
outside
your
cluster,
that
you
cannot
actually
move
into
the
cluster
or
that
you
cannot
read
number
for
whatever
reason,
and
so
you
want
your
pods
to
be
able
to
talk
directly
to
that
resource.
A
This
doesn't
mean
that
you
can't
do
some
of
these
things
in
a
more
cloud
native
way
or
have
proxies
that
bridge
these
kinds
of
resources
back
to
your
cluster,
but
oftentimes,
that's
a
little
bit
more
complicated
than
a
lot
of
people
want
to
deal
with
so
network
plumbing
working
Europe.
What
is
this
working
group?
A
Well,
Red
Hat
helped
found
this
working
group
as
a
result,
our
last
year
at
cube
con
Austin.
That
was
really
the
kickoff
and
impetus
for
the
group,
and
it
was
founded
to
take
a
lot
of
the
concerns
and
questions
around
how
we
take
these
workloads
and
make
them
slightly
more
cloud.
Natives,
let
the
more
kubernetes
aware
and
containerized
how
we
address
some
of
those
needs
in
kubernetes.
A
We'd
had
discussions
around
this
and
then
cig
network
for
quite
a
while
before
that,
and
we
decided
that
we
should
take
these
discussions
and
make
them
more
focused
and
try
to
address
these
problems
before
we
bring
them
back
to
cig
network
with
more
concrete
proposals.
So
the
group's
currently
focused
on
addressing
multiple
networks
in
an
out
of
tree
solution.
We
had
a
pretty
hard
goal
of
not
changing
the
kubernetes
api
in
any
way,
because
that
was
one
of
the
contentious
points.
A
A
Api
provide
a
forum
for
people
implementing
these
pocs
and
specifications
and
refinements
to
get
more
feedback
from
the
group
first
before
we
actually
try
to
propose
that
stuff
a
little
bit
further
upstream
so,
and
we're
continuing
to
working
on
these
things
and
expand
the
cases
that
we
have
even
further
than
the
v1
specification
and
the
Maltese
reference
plug-in,
which
Dunn
will
talk
about.
So
we
have
meetings
regularly
every
other
week.
We
kind
of
work
opposite
Signet
work,
so
if
anybody's
interested,
if
you
want
to
help
out,
we
love
contributions,
we
love
help.
A
So
this
is
also
a
kind
of
another
timeline
about
what
happened.
We
had
that
impetus
for
formation
of
the
group.
You
know
over
2017
and
then
we
finally
formed
the
group.
We
began
work
on
a
specification
in
early
2018
and
we
kind
of
refined
that
specification
got
a
lot
of
input
from
a
lot
of
different
members
who
had
these
use
cases
and
were
able
to
help
us
out
there.
We
finally
standardized
the
version
1
specification
in
early
August
and
then
have
been
working
on
the
reference
implementation
since.
A
So
what
is
this
specification
actually
cover?
It's
kind
of
a
de-facto
specification
again.
The
network
claim
and
working
group
is
not
an
officially
sanctioned
group
necessarily
for
kubernetes
is
just
kind
of
an
informal
group
offshoot
from
Signet
work.
To
do
these
things,
but
the
what
is
specification
cover?
It
is
a
short
term
solution,
and
this
is
we
wanted
to
make
sure
that
we
could
do
something
fairly
quickly,
get
some
things
done.
A
That
didn't
necessarily
require
a
lot
of
upstream
heavy
lifting
and
coordination,
and
so
we
wanted
to
do
something
within
like
you
know,
the
next
six
months
to
12
months
from
when
we
formed
the
group,
as
opposed
to
some
of
the
forward-looking
and
more
research
type
projects
around
network
services
and
service
function,
chaining
and
stuff
that
are
also
out
there.
We
did
not
want
to
change
the
kubernetes
api
in
any
way.
A
We
also
wanted
to
just
have
a
pretty
lightweight
standard
that
could
be
implemented
by
multiple
different
providers,
network
plugins,
other
organizations,
and
it
turns
out
that
there
are
actually
a
couple
not
just
the
reference
implementation
of
the
group's
working
on,
but
also
a
couple
other
ones
which
we
think
has
actually
fed
back
into.
The
spec
helped
us
refine
it
a
little
bit
and
really
kind
of
proven.
The
worth
of
that
specification.
A
So
a
really
short
overview.
There
are
a
couple
of
different
key
parts.
The
first
one
is
an
annotation
on
pods
to
select
these
other
networks
and
you
basically
select
them
by
name.
There
is
also
a
slightly
more
detailed
one
that
allows
you
to
set
some
other
attributes
for
the
pods
which
Doug
will
touch
on
in
a
second
and,
of
course,
once
you
have
actually
attached
multiple
networks
to
pod
there
to
a
given
pod,
you
want
to
be
able
to
figure
out
something
about
that
attachment.
You
know,
so
that's
kind
of
what
IP
address
is.
A
So
we
also
got
some
additional
components
to
help
out
other
implementations
and
help
out
client
applications
that
want
to
inspect
what
actually
is
going
on
with
the
network.
We
have
some
upcoming
stuff
too,
that
we're
working
on-
that's
not
quite
ready
yet,
but
the
first
two
on
that
list
are
actually
on
github
and
available
for
use
and
with
that
over.
B
We've
got
a
link
to
a
slack
we'd
love
to
hear
how
you're
using
it
or,
if
you
run
into
anything,
but
this
particular
implementation
follows
this
spec
and
we've
been
using
it
to
kind
of
give
some
feedback
into
how
we've
developed
this
specification,
and
it
is
a
fully
working.
You
can
pick
it
up
today.
You
can
use
it
and
you
can
attach
multiple
interfaces
into
your
pod.
Using
those
specifications,
as
Dan
mentioned
earlier,
there's
also
a
fair
amount
of
contribution
from
other
organizations
and
individuals.
So
you
know
don't
be
shy.
B
We're
happy
to
get
a
pull
request
any
day
of
the
week.
So
let's
take
a
look
kind
of
at
what
the
problem
is.
As
we
saw
before,
we
started.
You
know
developing
Malta's
as
to
what
it
is
today
and
really
the
way.
I
see
it.
It's
kind
of
twofold
you've
got
this
first
part
of
the
problem
where
you
bring
up
a
pod,
you
execute
IPA
in
the
pod.
And
what
do
you
see?
B
One
interface
right,
so
that's
one
part
and
then
secondarily,
you've
just
got
one
CNI
configuration
file
per
node
and
in
theory
you
could
have
different
CNI
configurations
on
different
nodes.
You
could
use
a
node
selector
and
you
could
like
kind
of
baby
where
your
pods
go,
and
you
could
get
some
multiple
configurations
that
way,
but
in
the
long
run
it's
really
kind
of
a
maintenance
headache
to
do
that,
and
it's
really
only
one
part
of
the
problem
is
how
do
I
get
a
dynamic
configuration.
B
So
you
bring
up
a
pod
and
it
has
this
annotation
attached
to
it,
which
basically
says
hey,
can
I
get
an
extra
attachment
to
a
network
and
montes
is
going
to
go
and
look
up
what
that
configuration
should
be
for
that
network
interface.
That's
going
to
attach
it's
gonna,
pull
down
that
configuration
dynamically
and
it's
gonna
say
sure.
If
you'd
like
an
extra
interface
and
you'd
like
to
back
it
with
a
Mac,
VLAN,
C&I
plugin
sure
go
ahead
and
do
that
as
dan
kind
of
touched
on
in
a
lot
of
ways.
B
Multis
looks
like
a
multiplexer
under
the
network.
Plumbing
working
group
nomenclature
you'll
often
see
this
referred
to
as
a
meta
plugin.
It's
a
CNI
plug-in
that's
able
to
call
other
CNI,
plugins
so
kind
of
on
the
left.
Here
we've
got
the
kubernetes
directly
calling
CNI,
so
you
know,
maybe
it
would
be
flannel
that
you
know
you'd
use
for
your
pot
pod
network
connectivity,
but
in
the
case
where
you
do
have
molted
Soraa
nother
reference
implementation,
that's
meta
plug-in.
B
B
Is
that
really,
when
you
have
a
pod
come
up,
you
expect
that
it
can
communicate
like
your
everyday
average,
run-of-the-mill
pod,
it
should
have
connectivity
to
other
pods,
so
you'll
hear
us
say
default
Network
and
often
what
we
mean
is
pod,
pod
connectivity
and
then
we'll
refer
to
the
other
network
attachments.
The
other
interfaces
that
you
have
available
in
the
pod,
sometimes
we'll
refer
to
those
as
sidecar
networks,
granted
that's
a
little
bit
of
an
overloaded
term
or
we'll
call
them
secondary
networks
or
network
attachments.
B
Next
custom
resources,
if
you're
not
familiar
with
custom
resource
definitions,
it's
a
term
that
people
often
throw
around
a
lot,
and
sometimes
it
sounds
like
more
of
black
magic
than
it
really
is.
Is
it's
really
just
a
way
to
tell
the
kubernetes
api
to
store
some
data
for
us?
So
we
have
a
net
definition
that
says
here's
kind
of
the
format
of
how
our
data
is
going
to
look
and
then
it
gives
an
application
in
our
case,
multi
C&I
a
way
to
query
for
that
data
that
you
stored.
B
B
B
So,
let's
take
a
look
at
kind
of
a
step
by
step
configuration
overview
and
let's
look
at
what
it
would
look
like
when
you're
right
at
the
command
line
creating
this
stuff.
First,
what
you're
going
to
do
is
you're
going
to
define
a
network
attachment
definition,
so
you
can
see
the
kind
of
this
custom
resource
we're
creating
is
network
attachment
definition.
That's
the
like
standardized
terminology
that
we're
using
as
defined
by
this
back
and
you're
gonna,
see
that
it
has
this
name
that
we
can
reference
in
other
places.
B
Lastly,
we've
got
the
config
there,
and
this
is
just
your
run-of-the-mill
cni
configuration
so
if
you've
ever
created
one
before
it's
the
same
thing.
So
we've
just
kind
of
got
a
fancy
house
for
it
to
live
in.
Otherwise
it's
just
completely
a
cni
configuration
next.
What
we're
gonna
do
is
we're
gonna
launch
a
pot,
and
we
want
to
tell
that
pod
that
we'd
like
to
use
this
additional
interface,
that
we've
defined
by
the
custom
resource
that
we
just
created.
B
So
all
that
we
have
to
do
is
just
create
an
annotation
that
references
that
that
one
that
we
just
created
now
you
do
not
have
to
have
this
annotation
at
all.
So
if
you
create
other
pods
that
don't
need
this
kind
of
treatment,
they're
just
gonna
get
the
default
Network.
So
it's
not
like
all
of
a
sudden.
All
of
your
pod
specs
have
to
change
just
the
ones
that
you
care
about
for
this
particular
case
and
what
happens
after
you
create
that
pod.
B
A
Doug,
let's
take
a
look:
we
want
to
do
a
little
bit
more
research
in
terms
of
services
right
now,
the
specification
because
of
the
requirement
that
we
imposed
on
ourselves
not
to
change
the
cube
API
right
away.
We
can't
yet
provide
services
on
these
additional
sidecar
networks.
They're,
basically
outside
of
the
cube
api
kubernetes,
doesn't
know
anything
about
these
sidecar
networks
other
than
the
annotations
that
the
implementations
like
multa
c
and
I
published
back
to
the
pod
as
a
annotations.
A
Well,
let's
think
about
this.
What
do
we
really
need
out
of
it?
Now
that
we've
actually
got
specification,
implementations
for
at
least
a
base
of
multiple
networks
and
the
pods
it's
time
to
kind
of
go
back
and
see
what
we
can
do
around
the
service
architecture,
because,
of
course,
kubernetes
is
really
about
services
and
that's
a
way
or
one
of
the
big
things
of
kubernetes
that
enables
a
lot
of
the
cool
stuff
that
people
can
do
with
it.
A
So,
let's
we're
going
to
go
back
and
try
to
figure
out
how
we
can
bring
these
multiple
networks
and
the
the
characteristics
that
they
provide
into
a
more
service-based
micro
service
architecture.
We're
also
going
to
continue
looking
at
the
security
for
these
additional
networks.
Right
now,
what
we're
gonna
do
for
access
control
is
fairly
limited.
We
just
want
to
make
sure
that
certain
pods
that
shouldn't
be
able
to
access
given
networks
can't
but
we're
gonna,
keep
pushing
forward
on
that
and
see
if
we
can
make
that
a
little
bit
more
granular
and
flexible.
A
We
also
have
some
continuing
refinements
to
the
specification.
Obviously,
specifications
they're
almost
never
done,
and
once
we
approve
the
V
will
inspect.
There
continue
to
be
some
things
that
we
wanted
to
clean
up
and
some
additional
features
that
people
wanted.
One
of
those
that
might
be
interesting
is
that
you
don't
necessarily
have
to
use
a
CNI
delegating
plugin
or
a
meta
plugin
like
Malta
CNI.
To
do
this.
A
We
also
are
putting
together
conformance
testing
and
we're
gonna
work
on
a
conformance
test
framework
to
at
least
minimally
verify
that
implementations
meet
the
specification
and
work
correctly
as
the
spec
defines,
and
finally,
the
resource
management
working
group
for
kubernetes.
That's
another
sig.
They
there's
some
overlap
with
the
stuff
they
work
on,
because
when
you're
talking
about
high-performance
networking,
some
of
these
use
cases
involve
special
Hardware
on
the
machine
and
that
special
hardware
is
resource
constrained
as
well.
A
B
For
all
the
stuff
that
we
have
coming
up,
we
also
would
love
to
invite
you
to
come
and
help
out
with
the
group.
I
would
say
if
you
don't
follow
this
Signet
work,
mailing
list
and
you're
at
this
talk,
that's
a
probably
a
good
thing
to
follow,
but
you'll
also
find
a
recent
thread
that
we
have
going
where
we
moved
our
particular
meeting
time.
So
it's
Thursday
morning's
East
Coast
time
it's
the
same
zoom
channel
as
we
use
for
sig
network
and
we'd
love
to
have
anyone
join
up.
In
short,
the.
B
We
just
met
up.
We
had
a
face-to-face
meeting
yesterday
and
we've
kind
of
determined,
like
a
series
of
goals
that
we'd
like
to
have
in
the
next
six
months
to
a
year,
but
we're
going
to
start
to
put
together
some
documentation
on
that.
So,
if
you
have
concerns
you
have
ideas,
we
want
to
hear
them
and
I
would
consider
the
group
to
be
quite
meritocracy
and
if
you're
able
to
get
in
there
do
the
work.
B
A
Also
one
last
plug
for
a
cig
network
itself.
You
know
a
lot
of
us
there's
a
lotta
cross-pollination
between
signal
work
and
employment
working
group.
A
lot
of
us
participate
in
both
groups
and
sig.
Network
also
needs
contributors,
and
so,
if
you
have
an
interest
in
networking,
we'd
also
love
to
see
you
in
cig
network
as
well.
C
C
B
You
use
it
in
a
particular
way
and
then
you
go
to
use
another
one
and
you
get
a
total
whiplash
from
it
right,
because
all
of
a
sudden,
you
have
to
like
change
your
tooling
for
how
how
you're
gonna
handle
this
stuff
I'm
not
I,
can't
speak
to
where
CNI
genius
we
have
had
Peter
Tsou
from
knitter,
which
also
provides
a
similar
functionality.
He
is
participated
in
the
group
and
has
made
some
progress
on
implementing
the
specification
there.
Yeah.
A
A
You
know
so
we'd
love
to
work
with
any
plug-in
that
attempts
to
implement
the
specification,
that's
kind
of
also
where
the
conformance
testing
comes
in
so
that
we
can.
You
know,
offer
that
to
people
who
want
to
implement
the
spec
and
make
sure
that
they
actually
do-
and
you
know
to
be
fair,
multi
CNI
does
not
perfectly
implement
the
specification
currently
we're
working
on
that,
but
yeah.
A
Okay,
yeah:
the
question
was:
how
does
it
work
when
you
have
like
sto
as
a
sidecar
container
in
the
pod,
and
you
have
multiple
interfaces
and
how
does
the
traffic
get
routed
at
this
point?
That
would
depend
on
how
the
sidecar
containers
set
up
the
rules
if
they
have
like
a
default
route
and
they
switch
the
default
route
to
funnel
all
the
traffic
through
it
through
the
sidecar.
A
Then
that
could
conflict
with
the
multiple
networking,
but
it
really
depends
inside
the
pod
how
the
routing
is
set
up
by
the
other
CNI
plugins,
and
what
that
service
mesh
might
do
with
the
routing
table
inside
the
pod
to
capture
that
traffic
and
send
it
out.
But
the
intent
is
that
only
the
cluster
wide
default
network
has
the
services
at
this
point,
and
so
all
the
service
traffic
ideally
should
be
going
out
over
that
cluster
wide
default
network
interface
that
every
pod
gets
regardless.
A
Because
if
you
don't
do
that,
then
we
run
into
questions
of
you
know.
How
do
you
know
that
two
pods
that
are
trying
to
access
a
service
or
actually
on
the
same?
They
have
actually
have
a
connection
and
have
IP
connectivity
between
each
other
and
I
mean
that's
kind
of
what
we're
looking
at
trying
to
figure
out
for
the
next
six
months.
For
the
group.
B
It's
a
very
interesting
that
you
bring
that
up,
because
we
have
been
looking
at
that
particular
use
case.
A
guy
in
my
team
at
Red.
Hat
has
done
a
couple
pocs
along
that
you'll
actually
find
a
recent
poll
request.
I
believe
that
we
just
merged
that
says:
here's
how
you
can
define
your
default
network
as
a
custom
resource
in
order
to
be
able
to
have
some
dynamic
control
over
the
migration
of
the
default
network.
So
yeah
definitely
search
through
some
of
the
most
recently
merged
pull
requests,
and
you
can
give
that
a
try.
I.
A
In
progress
and
I
think
that's
like
at
the
technical
level,
there
are
some
other
concerns
or
questions
around
like
you
know.
What
does
that
do
for
your
connectivity
at
a
certain
point
in
time
you
know:
is
there
outage?
How
does
that
work
with
service
model?
If
you
know
you're
doing
rolling
upgrades
or
something
like
that,
but
it's
definitely
an
area
of
interest
that
people
are
looking
into
well.
A
Each
one
would
have
its
own
subnet,
each
one
would,
you
know,
have
its
own
MAC
address
and
that
information
would
get
published
back
to
the
cube
API
as
separate
annotations
on
the
pod
for
each
network,
so
yeah
and
one
other
quick
point
about
that-
is
that
we
also
spend
some
time
on
multiple
attachments
to
the
same
network.
So
you
know
if
you
do,
for
whatever
reason
need
that
capability,
we
identified
I,
think
one
or
two
use
cases
pretty
limited,
but
we
felt
that
was
important
to
cover
for
the
spec
that
can
also
work.
A
B
I
am
not
exactly
familiar
with
having
multiple
calicos,
but
I
do
believe
that
we
have
some,
at
least
in
our
last
iteration
of
documentation.
We
actually
had
some
examples
and
the
multi
CNI
Doc's
about
attaching
flannel
multiple
times
right,
and
so
there
was
kind
of
some
additional
work
that
had
to
be
done
to
like
separate
it
out
and
say,
like
okay,
hey
I'm,
gonna
need
to
like
instantiate,
multiple
daemon
sets
of
flannel,
for
example,
so
yeah,
it's
definitely
CNI
plug-in
by
CNI,
plug-in
so
I
guess
also
kind
of
worth.
B
A
So
the
question
is
some
nodes
in
the
cluster:
have
certain
capabilities,
certain
interfaces
and
other
ones
might
not
yeah
yeah,
currently
there's
a
lot
of
work
going
on
with
the
resource
management
working
group,
and
so
that
group
is
looking
at
scheduling
and
making
sure
that
pods
don't
land
on
nodes
that
don't
have
the
hardware.
The
specification
that
we
have
here
does
not
necessarily
address
that
yet,
but
we're
working
in
close
concert
with
that
group
to
figure
out
how
we
can
address
that
to
make
sure
that
you
know
if
you
use
an
S
or
Rio.
A
If
you
plug
in
to
put
an
interface
into
the
container
that
you
know
you
have
enough
of
those
on
the
machine
that
you
can
do
that,
and
you
know
the
same
goes
for
like
even
Mac
VLAN,
because
some
cards
have
a
certain
limit
for
the
number
of
MAC
addresses
that
they
can
deal
with.
So
that's
not
perfect
yet,
and
it's
not
really
addressed
yet,
but
in
the
future
we'll
be
if
I
understood
the
question
correctly.
Yeah.
B
B
Let
me
see
if
I've
got
that
right.
So
the
question
is:
if
you
have
a
requirement
that
the
additional
network
interfaces
are
managed
by
external
piece
of
software,
does
the
specification
cover
that
which
currently
it
does
not?
Certainly,
we
would
definitely
like
to
hear
your
use
cases
and
opinions
there
to
see
if
this
is
something
that
we
could
cover
under
the
spec
for
sure.
A
I
mean
the
spec
doesn't
specifically
address
that
and
I
don't
think
the
implementations
do
either,
because
once
the
interface
is
added
to
the
pod,
it
doesn't
something
has
to
do
that
edition
and
something
could
then
also
manage
that
interface
later
and
that's
really
up
to
the
CNI
plugin
that
has
developed
to
provide
that
network
functionality.
So
there's
a
couple
of
different
kinds
of
plugins
like
some
of
the
really
simple
ones,
like
the
reference
plug-in
set
for
CNI
and
there's
others
that
we
sort
of
call
thick
plugins
that
are
more
heavyweight.
A
They
have
a
process
that
might
run
continuously
on
the
machine
to
manage
the
connectivity
between
all
the
different
nodes
and
pods
on
the
node.
You
know
I
mean,
for
example,
calico
I
think
would
be
more
of
an
example
or
OpenShift
s
the
end
of
a
heavyweight
plug-in
that
needs
to
manage
these
things
over
time.
So
I
think
it's
definitely
possible
to
have
that.
It's
just
that
the
spec
doesn't
exactly
address
it.
Most
of
that's
left
up
to
the
plugins
themselves,
any
more
questions
yeah
way
over
there.
B
Great
question:
that's
awesome
yeah,
so
we
have
had
I
guess
this
has
been
a
feature
that
has
been
implemented
in
the
last
couple
months.
So
I
believe
that
it
also
has
it
the
last
iteration
of
it
is
also
provides
the
capability
to
mutate,
the
annotations
as
well.
So
you
know
it's
going
to
do
some
validation
of
the
custom
resources
as
you
create
them,
which
we
kind
of
believed
would
improve
the
user
experience
because
it
can
be
difficult
to
debug.
If
you
put
something
in
there
wrong.
We
also
added
some
improved
logging
recently,
but
yeah.
B
The
the
last
iteration
provides
a
mutation
and
something
to
look
for
is
we
actually
recently
created
a
network
plumbing
working
group,
github
organization
and
we're
actually
going
to
take
the
work.
That's
been
done
on
the
admission
controller
for
multis
and
we're
going
to
publish
it
as
part
of
the
network,
plumbing
working
group
github
board
so
that
we
can
use
so
that
anyone
who
implements
the
specification
actually
could
use
the
same
admission
controller,
because
we
believe
that
that's
probably
agnostic
to
your
actual
implementation.
Yeah.
We
plan.
A
To
put
kind
of
plug
in
new
chiller
vendor-neutral
resources
on
the
github
board
for
the
network,
plumbing
working
group,
we
currently
have
a
CRD
generated
Sandi
client
code
there,
so
you
can
actually
use
the
CRD
from
some
of
the
normal
cube
api's
for
like
list
watch,
get
that
kind
of
thing
and
not
have
to
like
you
know,
do
riot,
you
keep
your
requests
yourself.
So
that's
pretty
cool
and
the
specification
is
also
there
in
a
couple
of
different
formats
and,
like
you
said,
the
emission
controller
will
be
there
fairly
soon.
A
So
we
intend
for
that
to
be
a
place
where
you
know
not
just
plugins
that
implement
the
spec,
but
also
other
clients
that
want
to
like
read
the
pod
annotations,
to
figure
out
what
the
status
of
these
different
attachments
is,
or
even
you
know,
a
door
to
get
the
add
or
remove
or
mutate.
The
list
of
networks
I
think
we're
pretty
much
out
of
time
if
I'm
correct.
But
if
you
find
us
somewhere
else
out,
there
feel
free
to
stop
us
and
talk.
So
thanks.
Everybody.