►
From YouTube: Kubernetes SIG Network 20170504
Description
Kubernetes SIG Network Meeting May 4th, 2017
B
B
A
B
B
A
C
C
E
So
this
morning
was
the
feature
discussion
meeting
or
the
coop
planning
for
one
seven.
For
whatever
reason,
the
two
features
that
I
thought
were
pretty
much
confirmed
to
go
on.
1.7
we're
tagged
as
no
milestone
and
the
two
that
probably
should
not
have
been
tied
for
107
we're.
So
the
you
to
reach
heights
1.7
or
FMVs.
In
love,
note
local
services
and
when.
E
Lot
of
discussions
around
the
design
around
these
and
I
do
not
think
that
they
are
a
fleshed-out
enough
to
be
considered
for
the
1
by
7
to
cut
off,
but
the
other
two
which
were
network
policy
to
GA
and
also
another
one
around
uke
for
source.
Ip
preservation,
probably
should
be
included.
41.7
does
anyone
disagree
whistle
is
so
you're
gonna
need
to
put
the
labels
around
and
I
can
do
that.
I
just
wanted
to
confirm
everybody.
B
So
I
think
that
sounds
right
to
me
in
terms
of
what
should
be
in
1.7,
which
wouldn't
be.
The
spreadsheet
has
a
little
bit
more
of
a
granularity
there
right,
there's
a
business
target
for
1.7
that
could
be
set
as
documentation
or
so
on,
but
in
terms
of
the
features,
repo,
yeah
I,
think
it's
Network
policy
and
the
source
IP
preservation
that
are
actually
valid
for
being
GA
and
one
one.
Seven
yeah.
E
A
C
B
B
A
C
E
C
B
E
Well,
I
put
the
high-visibility
flakes
visibility
just
because
it's
blocking
a
lot
of
fields
and
screws
up
on
a
man
in
those
squats.
That
is
two
of
them
here,
sort
of
simple,
it's
English,
I
think
I
mentioned.
Look
like
it's
open.
You
seem
like
they're
cross-cutting,
but
it
really
published
not
the
zones
by
sick
networks,
because
they're
yeah.
D
A
D
A
E
Say
there
are
a
number
of
flakes,
but
just
have
a
signet
work
tag
and
they're
not
still
feel
a
kinship
over
stick
close
by
or
20-sided
that
link
to
my
buckler
or
imagine.
A
lot
of
them
are
duplicates
and
this
probably
disclosed
them
and
showing
that
collection
time
they're
not
related
to
the
truth.
I.
E
B
E
B
B
A
A
Maybe
we
just
want
to
take
a
look
at
them
to
start
with,
in
the
first
few
minutes
before
we
actually
start
diving
into
what
I
think
the
contentious
areas
will
be,
which
is,
is
the
sea
skills?
The
kubernetes
should
try
to
address
in
some
way,
or
is
it
a
use
case
that
kubernetes
should
punt
out
to
the
plug-in,
either
through
third-party
resources,
annotations
or
some
other
mechanism?
C
B
B
A
Yeah
I
could
see
it
going
either
way.
Maybe
one
thing
I
can
I
tried
to
also
summarize
some
of
the
themes
of
the
use
cases
that
I
feel
like
I
could
pull
out
on
at
the
bottom
of
that
list
and
I
think
one
thing
that
two
aspects
actually
the
first
one
being
I,
feel
like
if
there's
a
case,
to
be
made
that
a
particular
pod
could
use
or
could
want
services
on
more
than
one.
A
A
You
know,
there's
other
use
cases
I.
Think,
like
you
know,
I
got
called
out
the
storage
network
and
legacy
app
network
cases.
Where
those
you
know,
if
you
want
to
talk
about
actual
interfaces
into
the
pot,
if
we
just
accept
that
you
know,
maybe
that's
the
way
the
pod
wants
to
do
it.
Some
of
those
interfaces
like
those
used
for
a
storage
network
or
those
used
for
talking
to
say,
like
a
legacy
database.
A
Those
probably
don't
need
services,
because
it's
the
pod
going
out
and
talking
directly
to
those
things,
as
opposed
to
the
pod,
providing
a
service
on
that
particular
IP.
Address
of
that
interface,
so
I
thought
that
was
kind
of
a
differentiator
that
I
could
pull
up
from
some
of
these
cases
and
maybe
just
showing
that
out
there,
maybe
for
the
storage
legacy
app
Network
take
these
cases.
Those
aren't
things
that
we
explicitly
address
in
communities.
A
At
this
point,
although
I
could
see
how,
if
we
solve
some
other
use
cases
that
those
storage
legacy
app,
things
would
kind
of
slot
right
in
so
I,
don't
know
I'm
just
trying
to
think
about.
You
know
ways
that
we
get
a
to
reduce
the
problem
space
or
that
we
can
start
from
a
fairly
simple
solution
to
try
to
address
some
of
the
use
cases,
and
then
you
know
get
something
down
so
that
we
can
continue
the
discussion,
but
still
you
know
solve
one
or
two
problems,
always
yeah.
G
A
A
That
you
know
I'm
just
thinking
in
terms
of
say,
you
have
a
set-top
box
and
that
set
top
box
wants
to
request
a
channels,
so
it
contacts,
it
has
a
command,
not
a
command
service.
Like
a
you
know,
there's
a
service,
but
the
except
I'll.
You
know
when
you
switch
the
channel
it
set
top
box
sends
a
command
to
particular
service
and
that's
on
a
low
bandwidth.
A
Interface
I
mean
obviously
on
your
set-top
box
and
your
pipe
to
the
internet,
your
provider
and
all
those
over
the
same
bandwidth
pipe
right,
but
in
the
data
center
that
would
potentially
be
a
completely
separate
service
in
the
separate
network
or
whatever,
but
low
bandwidth
latency
doesn't
matter
to,
but
doesn't
really
matter.
So
that
goes
to
one
interface
in
a
container,
but
then
the
container
also
has
you
know
whether
that's
s
RI,
o
V
interfaces.
H
A
C
there's
some
physical
NICs
on
those
machines.
It
has
another
interface
that
is
solely
used
for
media
streaming.
It
is
high
throughput
and
because
that
node
or
that
pod
might
serve
many
different
clients.
You
know
you're
not
limited
by
that
one
bandwidth,
but
that
service
also
has
excuse
me
that
media
streaming
part
also
has
a
service,
so
you
essentially
might
have
two
services
in
this
case.
A
G
A
But
what
I'm
thinking
of
in
is
in
terms
of
thinking
of
the
service
in
terms
of
a
way
to
have
one
particular
address
that
then
goes
to
an
arbitrary
back-end.
I
mean
I
know.
Currently,
the
proxy
stuff
is
more
or
less
limited
to
I
think
TCP
and
UDP,
but
a
lot
of
these
streaming
stuff
is
based
on
UDP,
and
so
that
could
still
be
clumped
through
in
lq
proxy.
A
But
you
know
at
this
point:
if
you're
talking
about
performance,
you
may
or
may
not,
once
you
actually
use
q
proxy
that
you
might
still
want
to
use
services-
and
you
know
dns
lookup
or
cluster
entities
before
in
package.
They'll
have
a
foreign
service,
so
I
don't
know
if
that,
if
that
makes
sense,
that
was
the
use
case.
That
I
was
thinking
of
there.
That's
sort
of
a
variant
of
what
some
installations
I
go
over
already
using
in
a
circular
brand.
A
G
A
Interface
and
the
IP
address
assigned
to
that
other
interface
require
could
be
a
service
or
not,
and
maybe
the
contention
here
is
that
if
it
doesn't
actually
require
a
community
service
to
reach
that
particular
endpoint
inside
the
pod,
then
maybe
it's
not
something
that
kubernetes
really
needs
to
add
to
the
API.
For
that
use
case,
at
least
that's
where
I
was
kind
of
coming
from,
if
that
makes
any
sense,
Mitch.
A
Yeah
I
mean
that
that
said,
for
all
of
these
use
cases
it
would
be
nice
from
the
management
and
statistics
perspective.
If
kubernetes
had
some
idea
of
what
these
interfaces
were
at
the
PI.
But
from
what
I
was
hearing
on
the
mailing
list,
the
contention
is
that
multi
networking
would
add
a
lot
of
complexity
to
the
kubernetes
api.
G
A
So
I
think
in
my
mind,
I'll,
try
to
say
it
briefly
and
shut
up
and
let
somebody
else
talk
in
my
mind.
The
base
complexity
that
we
could
have
is
adding
a
network
object
and
adding
kind
of
basically
what's
in
Georgie's
proposal,
except
skip
the
idea
of
services
for
now
and
kind
of
punt
that
down
the
road
and
figure
out
how
services
work
with
multiple
interfaces
later.
A
To
just
have
you
know,
network
objects
that
call
particular
plugins,
and
then
we
pass
some
IP
addresses
and
their
face
details
back
to
committees
that
can
present
it
through
the
API.
But
you
know
I
know
others
might
feel
that
that
is
complexity
for
nan
doesn't
benefit,
since
it
doesn't
actually
use
much
of
the
committee's
model.
So
that's
my
piece.
G
Right
so
can
we
just
say
right,
I'd
like
to
put
a
stake
in
the
ground.
It
says:
maybe
what
we
could
do
is
allow
talking
about
to
have
these
first
class
Network
objects
give
the
option
to
that
in
a
pod
spec,
you
can
request
multiple
attachments.
A
pod
data
model
can
record
multiple
attachments,
but
we
don't
try
to
worry
about
general
problems
and
getting
these
addresses
into
endpoints.
We
have
some
simple
prevention,
like
the
first
IP
address
is
the
one
that
goes
into
influence.
A
I
think
it's
important
to
point
out.
You
can
create
your
own
endpoints
through
the
API
to
you
know,
there's
nothing
the
quiz
ice
kind
of
side
creating
all
of
these
things.
It's
just
a
be
a
lot
easier
to
eat.
So
if
food
is
your
community
of
API,
if
you
talk
down
a
bit,
but
unfortunately
I
don't
see,
Tim
and
Christopher,
l
from
Tiger,
ax,
I
think
who
and
Thomas
traffic
enjoys
those
people
were
some
of
the
more
vocal
in
questioning
some
of
the
use
cases.
B
B
B
So
so,
in
addition
to
gathering
up
these
use
cases,
we
kind
of
have
to
set
that
bar
and
then
analyze
them
against
that.
If
so
I
think
I
think
we've.
You
know,
we've
got
this
list
of
use
cases
and
we
can
can
start
to
understand
those,
but
it's
something
we
also
need
to
be
thinking
about.
Is
you
know?
A
One
other
point
that
I
kind
of
came
out
of
some
use
cases
was
there's
an
interesting
use
case
from
Huawei
about
multi
network
per
node,
but
not
put
pod
I.
Think
it's
kind
of
an
extension
of
the
CNI
geni
sort
of
thing.
You
know,
which
is
you
still
only
have
one
network
applied,
but
you
might
have
multiple
network
plugins
available
on
the
node.
H
A
You
want
to
call
a
different
network
plug-in
potentially
for
each
different
pod.
You
know-
and
that
was
kind
of
an
interesting
use
case,
because
it
basically
avoids
the
whole
service
issue,
because
there's
only
still
one
network
in
the
pod
and
so
therefore,
services
and
everything
like
that
more
or
less
work-
and
you
know
I
thought
that
was
kind
of
a
even
that
use
case
might
be
a
use
case
for
multi
networking
in
kubernetes
that
isn't
as
far
down
the
rabbit
hole
as
some
that
we
have
but
and
then
I
think.
A
The
other
thing
they
want
to
bring
up
was
that
maybe
if
we
cannot
achieve
consensus,
Lovelace
class
API
objects.
What
are
these
solve?
Acts
that
we
could
potentially
sort
of
quasi
standardize,
one
to
at
least
achieve
some
consensus
and
then
maybe
continue
to
develop
that
into
a
API
stuff
later,
if
we
find
out
that
no
people
are
using
it
kind
of
like
we
did
with
no
policy,
we
started
off
with
third
party
objects
or
three
resources
and
annotations.
You
know.
Maybe
we
could
try
to
use
that
same
approach
here.
F
G
A
That
is
true,
I
mean
we
could
do
the
annotation
thing,
but
still
sort
of
use.
The
same
kind
of
format
you
know
have
an
annotation
that
is
the
network
name
and
then
an
annotation
is
whether,
like
a
network,
name,
comma
plug-in,
or
something
like
that,
if
we
wanted
to
I
think
there
are
ways
to
achieve
the
same
result
still
use
annotations.
A
G
A
G
H
Regarding
them,
my
question
regarding
the
surface
endpoints
recommend
for
Danica
interface,
so
I
want
to
reiterate
the
same
point:
what
to
Dennis
mentioned
of
both
IPTV.
So,
for
example,
if
you
take
in
IP
TV
for
nowadays,
they
are
trying
to
create
instance
of
the
set
of
box
as
a
container.
So
what
happens
is
whenever
you
initiate
something
from
the
IPTV?
The
corresponding
instance
is
created
as
a
container
and
then
for
the
container.
Then
you
require,
like
two
containers
inside
the
pod.
One
container
will
be
managing
the
control
panel
management
plane.
H
Another
another
container
will,
for
example,
you
can
control
data
plane.
So
in
that
case,
what
happens
is
that
you
need
one
service
which
could
able
to
manage
the
control
plane
or
management
plane
and
another
services.
We
should
required
to
manage
the
data
plane
and
these
two
services
could
be
using
two
different
net
plugins.
So
the
same
example.
What
Dan
proposal
one
can
could
be
the
bridge
plugin,
because
it's
a
very
low
overlay,
Network
and
another
could
be
a
server
which
requires
the
I,
throughput
or
high
performance.
H
H
H
G
H
It
can
talk
to
other
the
PMF
physical
network
functions
so
from
the
physical
network
function
it
can
be
given
to
the
set
of
box
it.
It's
not
like
it
directly.
The
client
is
talking
to
the
containers
that
could
be
some
intermediate.
P
enough
will
be
communicating
between
the
endpoints
for
them
examples.
H
The
endpoints
means
in
this
case,
could
be
the
set
of
box
or
set
of
box
will
be
communicating
to
the
P
and
P
I
mean
the
physical
and
for
function,
and
the
physical
network
function
is
contacting
the
server
and
in
the
server
the
corresponding
container
is
spin-off.
So
it's
not
it's
not
like
you
thinking
the
one-to-one
mapping
from
the
real
world
to
be
enough
to
the
container.
It's
not
like
that.
G
Sure
I
understand
you
have
more
complicated,
Network
setups.
My
question
I'm
trying
to
understand,
though,
if
you
have
a
situation
in
this
situation,
is
the
thing
that
needs
to
is
the
data
clean
conversation
right
is
the
client.
You
know
a
kubernetes
client
using
kubernetes
protocols
to
reach
the
data
link.
Add
a
plain
connection.
H
So,
for
example,
if
suppose
a
view,
controller
application
or
a
Services
Authority
you
having
a
services,
for
example,
if
you
have
a
to
micro
services
or
some
other
services,
they
have
to
talk
to
each
other.
They
have
to
talk
to
through
community
services.
Only
right.
So
all
you
can
a
up
expect
the
user
to
manage
that
one
networker
that
is
really
difficult
for
the
user
to
manage
that
particular
services
alone,
with
your
kubernetes
as
the
orchestration
engine
yeah
I'm.
G
Really
confused
about
what
kind
of
users
were
talking
about
in
the
world
of
TV,
we've
got
users
out
at
home,
or
we
got
operators
in
the
data
center.
We
got
operators
of
the
careers
cluster
and
then
the
application
programmers
who
are
deploying
TV
applications
on
the
kubernetes
cluster,
which
users
are
you
talking
about
I.
H
Mean
the
the
engineer
group
maintaining
the
data
center,
for
example,
if,
if
you,
if
you
are
saying
that
to
services
without
services,
if
you
want
to
communicate
with
the
two
pods,
it
means
that
it
directly
you
mean
to
say
that
it's
a
direct
communication
between
two
doctors
or
two
docker
containers.
It's
not.
H
A
H
A
That'd
be
awesome,
yeah
I
mean
it
also
in
response
to
your
question
like
I
will
take
some
time
and
try
to
come
up
with
a
diagram
for
my
use
case
as
well
for
the
IP,
IP
TV,
stuff,
I'm
kind
of
talking
about,
because
I
feel
like
I'm,
not
explaining
it
as
well
as
I
could
but
I
agree
that
I
know
it
would
be
very
interesting
to
find
cases
of
service
cases
that
include
services
on
two
different
interfaces.
Thank
you.
Both
yep,
then
I
feel
like
also
I.
Think
I
forgot
to
mention
this
earlier.
A
One
of
the
other
general
themes
that
I
kind
of
pulled
out
was
the
split
data,
plane,
control,
plane
thing
and
a
lot
of
that
had
to
do
with
performance
of
the
data
and
a
lot
of
that
was
around
either.
You
know
direct
NIC
assignment
to
containers
or
SR
IV
interfaces
into
containers
to
make
sure
that
you
have
certain
bandwidth,
guarantees
and
latency
guarantees
that
you
could
not
ensure
if
you
had
clustered
traffic
running
over
the
same
physical
network
as
the
actual
data
traffic
or
streaming
media
or
whatever
else
and
I've.
G
A
I
mean
especially
with
latency
as
well.
You
know
I
think
maybe
I
put
in
one
of
the
use
cases
around,
for
example,
something
like
InfiniBand
for
storage
networks.
We
have
some
use
cases
that
want
to
do
Gluster,
FS
and
that
can
run
on
InfiniBand
for
better
performance
than
on
ethernet,
and
so
you
know
if
for
ever
reason,
your
pod.
H
A
G
Kind
of
fits
kind
of
a
general
scene
here,
I'm,
not
quite
sure
you
pulled
out
right,
but
it
gets
into
this
name,
calling
about
close
to
native
all
right
at
some
level
we
say:
look,
we
have
all
sorts
of
stuff
you
want
to
implement
and
deploy
in
kubernetes,
because
it's
actually
nice
scalable
orchestration
engine.
You
know-
and
you
know,
there's
stuff
like
databases,
and
you
know
media
servers
and
all
sorts
of
stuff.
G
A
Or
API
well,
it
again
may
be
the
way
to
approach.
This
is
the
same
thing.
They
did
with
no
policy
which
is
have
annotations
that
actually
describe
the
network's
and
Health
Network
objects.
The
third-party
resources
for
the
moment
that
doesn't
solve
the
question
of
how
do
you
get
into
the
interface
and
iqs
back
into
communities?
Nord
is
a
soul
for
multiple
IPS
per
pod
problem,
that's
sort
of
orthogonal
sort
of
related,
but
maybe
it's
a
starting
point
that
doesn't
have
to
clear
that
bar
initially
yeah.
B
A
All
right,
why
don't
we
then
I
would
probably
talk
this
and
out
unless
anybody
else
wants
to
bring
something
up.
I
would
suggest
that
people
continue
to
add
use
cases
that
aren't
already
necessarily
covered
in
that
thirteen
bullet
point
list
and
you
know,
take
a
look
at
them.
I
would
say:
let's
debate
them
on
signaling
lists
it's
hard
to
keep
track
of
all
the
comments
in
the
Google
Doc.