►
From YouTube: Kubernetes SIG Network 2018-05-17
Description
Kubernetes SIG Network meeting for May 17th, 2018
A
All
right
welcome
everybody.
This
is
the
Signet
work
meeting
for
Thursday
May,
17
2018,
and
the
first
item
on
the
agenda
is
testing
review,
but
also
just
kind
of
a
general
reminder
that
the
111
code
freeze
appears
to
be
June
5th.
That's
not
really
that
far
away,
that's
about
two
and
a
half
weeks
away,
and
so,
if
you
have
outstanding
issues
or
PRS,
you
might
want
to
try
to
get
those
reviewed
as
quickly
as
possible.
There
are
also
some
other
deadlines
for
issue
tagging
and
features,
and
things
like
that.
A
I've
added
the
release
schedule
in
as
a
link
into
the
agenda
document
and
before
I
forget
I
will
also
paste
the
agenda
document
link
into
the
zoom
chat
so
that
everybody
can
follow
along
if
they
don't
have
that
already
pasted.
Now
so
yeah
get
your
stuff
in
order.
If
you
have
things
to
get
in,
do
you've
any
other
comments,
Tim
about
release
coming
up
or
anything
like
that.
If.
B
A
A
B
A
A
A
C
A
A
E
A
B
B
F
A
F
B
E
B
F
A
D
D
A
B
A
D
So
be
short,
I
just
wanted
to
get
some
clarification.
Everyone
on
how
we
correlate
tests,
flakiness
/
failures
with
going
G
a
so
there's
two
particular
ones.
If
you
look
at
the
IPS
tests,
you
can
see
they're
not
really
flaky,
they're
kind
of
failing,
but
I
just
wanted
to
clarify
that
stuff
like
that,
should
be
needs
to
be
fixed
before
it
goes.
You
think.
A
B
I
A
I
A
D
J
A
D
B
A
D
B
That
was
something
somebody
brought
up
for
me
last
week
to
when
this
goes
sideways.
How
are
people
going
to
know
how
to
debug
it?
There's
there's
a
couple
of
Doc's
out
there
and
how
to
debug
through
the
IP
tables
implementation.
It
would
be
nice
to
extend
those
do
how
to
debug
through
the
IPS
yeah
cool
awesome.
Great
work
guys
was
a
long
road
cubic
on
Seattle
I'm
buying
the
beer.
E
E
E
B
That
sounds
great
I'm.
Still
the
debate
around
whether
the
binary
lives
in
your
space
or
our
space
and
who
builds
it.
Those
sorts
of
things
are
still
ongoing.
It's
a
very
tricky
conversation,
but
it's
looking
like
the
general
consensus
is
leaning
towards
getting
just
some
processes
in
place
around
specifically
around
security
releases
like
across
projects,
making
sure
that
the
core
Dinah's
project
has
a
security
process.
B
Recently,
with
the
dns
mask
issue,
right
and
kubernetes
has
a
I
think
a
fairly
reasonable
process
in
place
for
the
core,
kubernetes
repo
and
so
we're
and
and
associated
repositories.
We're
able
to
do
it
for
the
cube.
Dns
I
want
to
make
sure
that
if,
when
that
happens
again,
we
can
do
it
with
a
cross
project.
Okay,.
E
Sorry,
one
pier
to
to
produce
I
guess
we
will
send
before
and
not
maybe
Monday
Tuesday
a
way
to
a
way
to
upgrade
using
the
Christian
of
great
that
Sh
I
have
watched.
One
question
here
is
that
way
to
upgrade
is
used
in
production.
It's
only
using
the
end-to-end
test.
Does
someone
know
that
the
Cuba
stuff,
the.
B
E
E
B
G
E
G
E
Okay
and
then
so
what
we
have
now
is
we
we
send
a
bunch
of
peers
for
the
best
test,
DNS
that
was
asked
for
Co,
DNS
and
and
to
end
tests
for
config
map
and
the
scalability
DNS
specific
test.
So
all
these
PR
has
out-
and
we
are
waiting
some
reviews-
you,
okay,
after
I,
don't
know
who
I
try
to
ping
each
time
who
can
help,
but
so,
if
you
want
rested
in
that
way,
please
contact
me
more
say
me.
Ask
me
to
go
into
that.
To
add
you
in
that
peer
and
I.
E
Think
that's
it
on
another,
and
we
ever
I
have
a
long
time
of
maybe
three
months
ipv6
and
to
end
test
for
core
DNS.
Oh
I,
upgraded
the
ipv6
and
to
end
test
for
DNS,
so
that
includes
QBs
and
co.
Dns
except
one
is
not
working
which
to
be
honest,
but
that's
cube.
Dns
and
I.
Don't
know
how
we
go
ahead
with
this
ipv6
and
to
insist:
that's
not
really
linked
to
Katya
initiate
another
thing.
I.
E
K
Gain
yeah
I
can
hear
me
yeah,
yes,
it
would
not
be
going
GA.
Our
hope
is
to
very
into
beta
the
there's.
There's
a
PR
out
for
the
ipv6
TI
test
has
been
out.
She
was
about
two
months
now,
but
I
would
I
would
imagine
that
once
that
is
merged
that
you
could
take
take.
What's
there
that
we
ran
to
spend
on
a
GCE
instance,
you
could
take
what's
there
and
ads
from
core
DNS
ipv6
tests
to
that.
Would
that
make.
E
B
K
Apologize
sorry,
oh
no
worries
I
should
should
be
pushing.
We
also
I
had
I
had
been
pushing
for
a
while
and
then
I
we're
waiting
for
Marant
is
to
come
out
with
a
stable
branch
and
now
now
we're
using
that
their
stable
branch
and
I
was
gonna.
I
was
going
to
start
pushing
that
myself.
So
so,
let
me
let
me
ping
them
again,
Tim
and
if
I
don't
hear
from
them
in
the
next
couple
days,
I'll
pain,
you
all
right
and.
E
Okay,
so
I
think
I
have
my.
Let
me
just
check
one
thing:
I
am
I'm
go
ahead
and
to
enter
switching
with
you
going
word
and
we
have
the
scalability
test
for
DMS,
that's
okay,
so
we
what
I
understand
is
we
have
to
push
this
KP
for
default,
and
so
we
can
have
the
approval
on
this
one:
okay,
P.
Okay,
thank
you.
C
L
C
Good,
okay,
it
looks
good
to
me
alright,
thanks
for
giving
us
some
time.
I'm
Doug
Smith,
with
Red
Hat
and
I'm
joined
today
by
Tomo
from
Red,
Hat
and
crawl
from
Intel
and
we'd
like
to
demonstrate
for
you
our
reference
implementation
of
the
specification
put
forward
by
the
network
plumbing
working
group,
that
is,
for
multiple
network
attachments
in
kubernetes.
We're
gonna,
try
to
rip
through
this
demo,
nice
and
quick
and
keep
it
short
and
sweet
for
you
guys.
C
So
if
you
don't
mind
saving
your
questions
for
the
end
or
better,
yet,
if
you
have
even
more
detailed
questions,
you
can
bring
them
to
our
regular
meeting
somewhere.
You
can
hit
the
next
slide,
please
Thanks
cool,
so
the
network
plumbing
working
group.
This
was
formed
this
past
year
at
a
cube
con
in
Austin
Texas
and
we're
currently
addressing
multi
networking
in
kubernetes.
C
Initially,
here
we're
defining
a
de
facto
standard
CRD,
so
it's
a
custom
resource
definition
that
you
use
to
extend
the
kubernetes
api
that
will
be
used
for
attaching
multiple
networks
to
a
pod.
The
multi-home
pod
story
has
been
going
on
for
a
good
couple
years,
at
least,
and
we've
formed
this
group
in
order
to
unify
the
efforts
of
the
community,
both
in
their
proposed
and
their
implementations.
C
Our
specification
is
becoming
a
more
and
more
stable,
as
time
goes
on,
but
we'd
love
to
invite
you
to
come
participate
in
our
meeting.
That
happens
on
alternate
weeks
of
this
meeting
in
the
same
zoo
meeting
room
the
same
time
the
day
everything
so
please
come
on
along
to
discuss
and
especially
to
help
us
out
with
our
implementations.
We
would
much
appreciate
it
next
slide.
Telmo
thanks.
C
So
our
standard
that
we've
been
working
on
is
trying
to
help
normalize
the
user
experience
when
you
go
to
express
your
intent
to
attach
multiple
networks
to
a
pod.
So
this
lets
the
user,
be
agnostic
to
the
technology,
that's
used
behind
the
scenes
and
gives
them
kind
of
a
congruent
experience
if
they
move
between
technologies
as
well.
C
The
implement
the
specification
as
it
stands
uses
a
kind
of
a
sidecar
network,
so
you're
still
attached
to
a
default
network
that
typically
be
pod
the
pod
and
then
you
add
other
attachments
to
networks
as
sidecars
to
this.
Our
current
implementation
is
a
meta
plugin,
so
that's
a
CNI
plug-in
that
can
talk
to
other
CNI
plugins
and
the
implementation
as
it
stands
is
out
of
tree.
So
it's
not
in
github
comm
/,
kubernetes,
/
kubernetes.
It
stands
on
its
own.
C
The
goal
of
this
implementation
right
now
is
to
move
the
specification
forward
and
it's
just
one
reference.
Anyone
can
make
an
implementation
based
on
this
spec
and
the
implementation
doesn't
have
to
necessarily
be
a
medical
again.
Our
specification
is
written
in
such
a
way
to
allow
a
creative
use
of
this
specification.
C
M
Thanks
dad
so
why
we
choose
multiple
the
reference
implementation,
because
Maltese
is
very
simple
CNI
which
supports
multiple
networking
and
there
is
no
need
to
add
additional
plugins
or
the
code
to
make
it
work.
It's
very
generic
and
it
does
only
a
single
job
that
is
multi
networking
and
it
reused.
The
concept
of
delegates,
which
is
the
final,
also
does
the
same
thing
and
in
addition
to
that,
it
also
cached
networking
information
during
the
creation
and
et3
use
those
information
for
deletion
for
some
cases.
M
What
happens
like
if
the
reference
network
object
is
deleted
or
the
config
file
is
moved
or
is
changed,
so
it
make
sure
that
it
will
releasing
or
deleting
the
particular
network
resources
and
it's
this
project
is
quite
stable
and
it's
already
in
field
trial
and
in
production
for
nfe
use
cases.
So
next
slide
please.
So
we
divided
the
reference
implementation
into
two
parts:
phase
1
and
phase
2.
So
in
phase
1
you
are
getting
basic
functionality,
such
as
looking
at
the
validation
of
POD,
annotation,
that
CRT
objects
and
the
reference
implementation.
M
Dozens
not
change
the
philosophy
of
kubernetes
networking
that
kubernetes
assumes
that
all
ports
can
communicate
with
other
ports,
regardless
of
which
hosts
they'll
and
so
on.
All
parts
in
kubernetes
can
communicate
to
any
ports.
So
in
this
phase
1
we
provided
option
called
default
networking,
so
we
hold
the
default
networking
options
for
all
the
nodes
so
that
any
ports
can
talk
to
any
ports
inside
the
container
inside
the
node
and
the
meta
plugin
is
just
provides
you
additional
network
such
a
that's.
M
The
only
choppy
task,
so
multi
is
the
one
which
provides
you
the
additional
work.
So
the
current
implementation
supports
three
modes.
The
first
mode
is
you
have
cna
config
Jason,
that
is
the
network
object,
so
you
can
put
all
the
CH
information,
the
JSON
format
inside
the
network
object
and
second
one
is
basically
for
the
dick
plugin.
M
So
stick
plugin
in
this
case
could
be
Korea,
saying
I
plug
in
our
ODL,
so
in
which
you
don't
need
to
specify
any
see
any
configuration,
so
it
does
its
own
job
and
the
third
one
is,
which
is
an
interesting
one,
is
providing
the
siene
configuration
storing
on
disk
file.
So
you
can
store
all
you
were
saying:
a
configuration
as
a
JSON
as
a
file,
so
you
just
need
to
mention
the
network
information
of
that
particular
file,
so
the
meta
plight.
You
know
what
multis
will
find
that
network
or
trick
for
you
and
phase.
M
Two
is
kind
of
additional
or
extra
witcher
implementation.
Like
this
phase,
two
is
comes
with
some
fancy
features
like
providing
IP
request
and
mac
request
to
the
plugins,
so
that
meta
plug-in
could
find
whether
this
particular
IP
address.
For
example,
tomb
was
developed
at
the
I
Pam
called
static,
so
in
this
case
they
user
may
request
for
your
particular
IP
address
and
your
meta
plugin
check
whether
it's
getting
the
particular
IP
address
or
MAC
address
or
not.
The
second
use
case
is
to
add
the
network
attachment
information
back
to
the
port
annotation.
M
L
So
there
we
are
showing
the
demo,
then
they,
these
demos
materials,
is
available.
In
the
example
directory
in
the
motors
kid
blip
on
their
network,
prompting
working
group
branch
I
mean
here
this
one,
so
you
can
trick
the
network
pump
in
working
group
branch
and
then
the
so
you
can
running
the
equipment.
Others
Craster
using
the
cuba,
any
tools
which
is
the
keyboard
or
mini
cube
world
cube
multiple,
so
the
I
directors
show
the
demo
scene
are
about
that.
L
So
the
on
the
left-hand
side
that
we,
how
about
you,
move
up
or
networks
EOD
the
these
two
files
and
opposed
definition.
So
we
can
using
the
cube
control
to
put
these
mm
file
in
the
actual
object
and
then
in
the
pod
creation
network.
Co
the
object
to
the,
for
example,
the
Mac,
Baren
or
frana
is
used
as
a
reference
to
create
networks
in
addition
to
the
default
network.
So
in
this
demo,
dia
we
default
network
is
the
frontal.
L
Now
one
pot
is
created.
Maybe
it's
like
the
this
workflow,
the
cubelet
inbox,
the
runtime
and
the
runtime
Diaz
CNI
problem
motifs
and
then
CNI
Malta's
inbox.
The
master
I
mean
the
default
Network,
probably
and
then
after
that,
looking
the
kubernetes
api
and
then
their
checks,
the
CLD
object
and
then
create
the
mimic
child
minion
network,
probably.
L
Port
with
several
networks
with
default,
Network
made
on
the
one
in
steam,
Aquino
and
another
is
a
funnel
and
the
belong
is
also
in
the
target,
and
here
is
the
demo
scenarios
and
the
demo
networks,
which
is
created
in
the
demo.
There
is
for
Matt
Leon
configuration
and
then
1
billion
configuration
and
then
bid
on
configuration
in
sitting
in
the
Annette
and
s1
namespace
is
a
different
name
space
and
then
the
rest
is
their
frontal
that
this
front
is
different
from
the
default
network.
L
We
create
the
afore
pots,
the
podcast
one
uses
the
Mac
veena
and
then
this
is
a
simpler
notation
and
the
second
uses
the
JSON
a
notation
format
and
then
creates
the
to
interface,
knock
Pina
and
the
Veera
and
the
B
neural
interface
is
renamed
as
the
villain
1-1
from
a
different
naming
convention.
The
podcast
3
is
that
we
have
a
three
interface,
not
villain,
config,
to
interface
from
same
network,
and
we
also
create
the
frontal
to
interface.
L
This
is
the
second
refre
know
over
a
network,
and
then
this
problem
is
read
by
the
app
from
a
file
instead
of
the
ACL.
The
object,
and
the
last
case
is
the
adjuster
regression.
I
mean
the
without
the
network
on
notation.
Ok,
let's
go
the
demo.
You
can
sit
here,
this
demo,
I'll
say
YouTube
as
well,
but
ok
can't
see
in
my
movie:
ok,
ok,
ok!
L
L
L
L
L
Now,
okay,
though,
at
the
time
for
for
network
for
parties
available,
so
here
is
the
master
node
is
net.
One
interface
is
different
than
the
usual
is
one
okay.
So
now
the
year
I
entered
the
apart
case,
one
in
the
podcast
one
here
here
is
the
llamo
file.
At
that
time
we
create
the
macro
VLAN
configuration
additionally
with
the
default
network.
L
L
L
Okay,
let's
go
to
the
another
case
case
and
then
at
that
time
we
checked
the
villa
interface
over
master
node,
and
then
we
entered
a
podcast
in
podcast.
We
created
the
another
notation
style,
I
mean
the
JSON
and
the
two
creates
the
the
interface
is
created
in
addition
to
the
default,
so
the
three
interface
will
be
coming.
One
is
the
macro
veera
and
another
is
the
villain
sitting,
the
intestine
s1
and
then
the
interface
requests
changing
the
interface
name,
so
kunti
default
child
networks
name.
Does
the
net
brunette
one
or
something
like
that?
L
L
L
L
L
L
L
Them
check
the
route
for
a
frontal
dot
to
add
the
master
goes
to
the
net
to
the
interface
of
the
pot
and
then
pings
works.
Fine
then
last
case
is
just
simple:
one.
I
mean
the
usual
one
with
there
is
no
network
or
notation.
At
that
time
we
can
see,
we
can
usual
interface
output,
it
works
fine
and
then
that's
it.
C
Awesome
thanks,
don't
go
and
yeah
just
a
reminder
that
feel
free
to
come
and
follow
up
with
us.
Well,
hopefully,
go
deeper
into
this
demo
during
network
plumbing
working
route
meetings
and
we'll
have
some
more
feedback
there.
So
if
you
want
to
get
into
the
nuts
and
bolts
if
you
want
to
get
up
and
running,
feel
free
to
come
by
and
get
in
touch
with
us.
Thank
you
guys
for
letting
us
have
the
time
here.
A
A
D
B
H
B
F
B
B
B
The
the
challenging
part
for
me
is
that
it
has
to
be.
We
have
to
find
a
way
to
make
it
really
simple
for
simple
cases
and
then
possible
for
crazy
cases
and
anyway,
so
I
think
that
was
the
the
main
rub
of
it
was
treating
network
attachment
as
an
API,
not
as
a
static
thing
and
tell
me
how
far
off
your
mark,
I
am
yeah.
H
Often
people
inclusively
have
all
kinds
of
other
things
that
is
being
are
being
done
for
them
there
and
just
and
you
you
basically
shut
that
entire
problem
off
when
you
are
just
knitting
together,
l2
segments
or
things
of
that
nature,
and
so
well
having
a
method
that
would
allow
you
to
do
those
simple
cases
simply,
but
also
allow
you
to
do
the
harder
cases
with
a
complexity.
That
scales,
like
the
complexity
of
the
thing
you're
trying
to
do
is
a
very
serious
gold
here
and
I
would
be
delighted
to
come.
H
B
H
So
I'll
stop
something
down
there
and
and
put
up
sort
of
a
SPOC
of
a
block
for
time.
We
can
figure
out.
You
know
what
we
can
chop
that
down
to
to
make
room
for
other,
because
I
do
realize.
There
are
important
things
like
you
know.
Good
evening,
IDs
the
core
DMS
talked
on
that
need
to
take
precedence.
M
Hi,
this
is
good.
Also,
we
have
put
some
proposal
on
SRV
network
device
plugin,
so
we
have
seen
there
has
been
a
lot
of
discussion
about
how
to
do
the
network
allocation
way
through
network
device
plug-in
or
through
the
CNI.
So
last
network
resource
management
hooking
face
to
face,
so
you
had
a
discussion
with
the
team
and
then
recording
that
and
we
caught
some
ideas,
how
we
could
have
kind
of
a
relationship
between
both
the
device
plug
in
and
the
CNI.
M
So
we
developed
kind
of
a
shim
CNI
which
could
be
able
to
communicate
with
both
the
device
plug-in
and
CNI.
So
it
could
be
a
perfect
match
for
the
network
allocations
for
the
finite
or
networks
like
s
or
a
V,
so
we
developed
a
prototype
model
on
that
one.
So
if
time
permits
for
the
next
meeting,
we
can
put
some
slides
and
the
demo
as
well.
Thank.
M
So
we
included
the
Numa
awareness
future
as
well
in
that
once
because,
if
you
have
CPU
and
I
sort
of
enix,
both
should
be
in
the
same
node
to
get
high
performance
stuff.
So
we
included
that
one
which
we
will
showcase
may
be
in
phase
2
releases.
So
it's
a
combination
of
Numa
managers,
cmk
main
CPU
manager
and
also
the
NIC,
so
it
combining
all
this
stuff
together.
So
it
that's
why
the
proposal
looks
like
13
pages
actually.
But
if
you
look
at
the
block
diagram,
it's
very
simple.
Actually,
okay,.
B
M
B
It
meshed
with
this
I,
sent
out
a
slide
deck
trying
to
capture
a
little
bit
more
of
this
concept
of
I
had
asked
sort
of
which
forms
of
connectivity
people
were
actually
expecting
to
support
through
the
multi
network
problem
and
I
got
some
feedback
on
it,
but
not
a
ton.
I
would
ask
if
people
have
a
few
minutes
to
go
through
that
deck.
It's
in
the
archives
for
the
mailing
list,
I'm
trying
to
understand
when
it
comes
to
multi
network,
especially
when
it
comes
to
multi
networking
devices
like
s
RI,
o
V.
B
How?
How
are
things
people
are,
how
are
people
actually
wiring
up
their
infrastructure
because
I
think
that's
going
to
inform
the
evolution
of
how
we
are
able
to
describe
what
is
available
on
a
given
node.
So
I've
seen
you
know
three
or
four
different
proposals
now
of
how
to
manage
multi
network
from
a
node?
B
So
if
people
have
five
minutes,
please
go
look
at
that
slide
deck
and
tell
me
like
a
if
it
makes
sense.
So
thank
you
for
all
the
people
who
helped
me
to
clarify
the
deck
and
B
which
of
these
cases,
if
you
care
about
multi
network,
especially
if
you
care
about
device
oriented
multi
network
which
of
those
cases
you
actually
care
about
I.