►
From YouTube: Kubernetes SIG Network 2018-06-28
Description
Kubernetes SIG network meeting for June 28th, 2018.
A
A
C
C
B
C
Just
speak
loud,
so
basically
a
debug
to
proxy
upgrade
and
downgrade
test
and
channel.
The
issue
is
so
during
the
test
that
some
of
the
cue
proxy
just
is
not
scale
in
your
arm.
Some
of
the
node
and
turn
out
is
because,
during
the
node
upgrade,
the
couplet
doesn't
update
an
old
label
given
by
the
node
label
flags
and
it
turned
out
that
is
intending
intended.
Behavior,
because
folks
are
trying
to
limit
what
the
cube
they
can
do.
C
C
A
D
It
looks
like
it's
an
issue
with
kubernetes
anywhere.
It
turns
out
that
cube.
Atms
Deb
requires
CRI
tools
and
it
doesn't
look
like
that's
actually
being
installed
or
even
attempted
to
be
installed,
even
though
it
is
pulled
down
to
the
nodes,
and
so
that's
what
it
looked
like
to
me.
I
did
a
PR
to
actually
install
that
where
it
looks
like
it
should
be
installed.
I
don't
know
who
gets
to
review
and
approve
that
one,
although
it
looks
like
Tim,
has
some
of
those
powers.
D
Hopefully
somebody
else
does
too
so
it
looked
like
that
was
the
problem
for
all
of
the
cube
ATM
tests,
and
it
looks
like
this
was
an
issue
after
all
of,
even
after
all,
of
Dane's
updates
for
some
of
the
other
packaging
stuff.
So
who
knows?
Maybe
if
this
gets
fixed
it'll
be
the
last
thing
to
actually
make
these
guys
turn
green.
D
D
E
E
D
D
A
F
As
far
as
so
we
will
take
care
of
this,
we
did
it.
There
is
a
let's
say
of
homework
issue,
because
we
we
run
10,000
Atlas
service
and
it
does
not.
It
does
not
fit
depending
the
way
you
you,
you
stuff
the
test,
but
we
know
we
we
troubleshoot
already,
if
several
weeks
ago,
with
scalability
guys-
and
we
know
how
to
do-
accept
that
when
we
knew
it
was
already
code
freeze,
so
we
did
not
push
to
to
fix
that,
but
we
started
today
so
in
two
days
that
will
be
okay.
A
G
A
H
Gave
us
to
talk
a
little
bit
about
the
network
service
and
their
stuff
a
couple
of
meetings
ago,
and
one
of
the
things
that
came
out
of
some
of
the
conversation
on
the
mailing
list
was
sort.
The
open
question
of
you
know:
what's
the
right
sort
of
formally
formalism
to
plug
in
to
is
it
a
signet
working
sub
project?
Is
it
some
kind
of
kubernetes
working
group,
basically
we're
just
trying
to
figure
out
what
makes
sense
and
what
would
be
sort
of
desirable
from
the
community's
point
of
view,
Oh.
E
H
H
I
was
saying
that
the
there
are
lots
of
sort
of
interesting
things
that
could
be
explored
with
various
SIG's
and
working
groups
within
kubernetes.
That
might
be
cool,
but
we
sort
of
are
like
touch
enough
that
we
don't
actually
need
any
changes
from
the
existing
six
in
order
to
function,
which
is
a
good
thing,
and
but
it
also
makes
the
question
a
little
more
interesting.
E
Yeah
I,
don't
think
it
changes
the
calculus
I
think
it's
still.
You
still
want
a
working
group
we're
actually
in
the
sort
of
at
the
tail
end
of
formalizing
the
working
group
creation
process,
but
basically
it
comes
down
to
a
short
dock
that
has
a
clear
mission
statement
and
a
statement
of
what
the
goal
of
the
group
is
like.
What
is
the
output
artifact
of
a
group
of
a
working
group?
It's
not
code
in
the
sense
that
working
groups
don't
own
code.
Sig's
do,
but
it
could
be.
E
H
E
Is
there's
I
mean
producing
code
is
not
necessarily
the
same
as
getting
code
into
quote,
quote
the
project,
and
if
it
were
to
go
into
the
project,
whether
that's
in
the
main
repo
or
in
a
in
a
associated
repo,
then
we
would
decide
which
sig
owns
it
I
think
it's
pretty
clearly
it
would
be
sig
network
that
would
own
it
and
that's
fine.
The
group,
the
goal
of
the
working
group,
though,
is
to
distribute
information
and
reach
consensus
across
the
interested
parties.
H
D
I
Hello,
can
you
hear
me
yep,
hello,
everyone,
so
I
was
advice
to
bring
this
request
to
this
ball.
It
is
about
the
CTP
supporting
we're,
not
assessing
you
here
for
protocol,
as
you
can
see
from
my
signature
I'm
from
Nokia.
There
are
two
other
guys
here
as
well
from
Nokia.
We
are
a
telecommunication
company,
as
you
know,
so
that's
why
I
CTP
is
kind
of
important
for
us
is
protocol.
I
We
use
it
among
our
services,
and
our
original
use
case
was
that
we
would
like
to
have
our
service
instances
to
get
into
Cooper
DNS
in
order
to
be
able
to
use
DNS
queries
to
find
the
peers-
and
it
turned
out
of
course,
we
year
ago
or
so
that
we
des
EDP
is
not
possible.
So
we've
got
this
request
and
then
we
were.
I
We
were
advised
at
that
time
that
we
should
not
limit
setp
support
for
headless
services,
so
we
should
try
to
be
implemented
for
every
possible
service
types,
but
it
took
a
year.
Unfortunately,
now
we
have
a
initial
pour
request
and
then
we
were
told
that
we
should
bring
the
topic
here
and
the
reviews
of
rotor
kubernetes
enhancement
proposal
document
for
this
purpose
yeah.
So
that's
why
we
are
here.
E
A
bunch
of
people
have
started
reviewing
it
already,
myself
included
some
real
concerns
raised
about
the
idea
of
kernel
mode
versus
user
mode
and,
honestly,
like
that's,
a
pretty
major
complicating
factor
that
doesn't
have
any
sort
of
precedent
or
examples
to
draw
on
from
within
the
rest
of
kubernetes,
and
that's
a
little
worrisome
to
me.
Can
you
briefly
tell
the
rest
of
us
what
that
issue
is
the
issue?
Let
me
see,
I
need
summarize
it,
and
you
guys
can
tell
me
if
I
get
it
wrong.
E
The
issue
is
that
there's
two
ways
to
consume:
SCTP
ones
through
the
kernel
interface
and
one
through
user
space.
If
you
consume
it
through
user
space,
and
then
you
load
the
kernel
module
for
it,
you
can
no
longer
consume
it
through
user
space.
So
if
you
have
a
job
that
wants
user
space
setp
and
you
have
a
job
that
wants
kernel
space
SCTP,
they
can't
use
the
same
machine,
did
I
get
it
right.
Yep.
E
We
don't
really
have
a
mechanism
that
is
there
to
sort
of
taint
a
machine
that
way
I,
say
tain
to
it
very
specifically,
because
we
do
in
fact
have
taints,
but
we
don't
have
a
way
of
automatically
detecting
those
sort
of
transient
tapes
and
I'm,
not
sure
how
transient
they
are
since
kernel
module,
unloading
is
actually
not
officially
a
supported
thing.
So,
basically,
once
you
do
that
the
machine
go
in
one
direction
and
one
direction
only
until
it's
rebooted.
E
I
I
So
on
someone
creates
an
sctp
service
in
kubernetes,
then
of
course
it
will
trigger
the
IP
tables
or
IP
vs
rule
creation,
which
automatically
loads
the
setp
module
into
the
camera
and
add
that
on
every
nodes
of
course,
and
at
the
same
time,
the
users
face
SCTP
publications
that
run
on
this
cluster
will
actually
fail
break
and
that's
why
we
included
this
aspect
into
our
to
our
proposal.
Request
because
actually
I
didn't
fear
that
I
myself
can
decide
that
it
can
be
left
out
right.
E
E
Do
we
like
I,
think
the
important
thing
to
ask
here
is
how
important
are
each
of
those
two
use
cases
I
think
realistically,
we
can
support
one.
If
the
proposal
supported
one
and
not
the
other,
then
we
could
actually
get
it
merged
and
as
long
as
we're
trying
to
support
both
it's
going
to
be
a
very
long
painful
process
where
I
don't
even
really
know
I
don't
have
a
mental
model
to
think
about
it
because
I,
just
don't
you
don't
have
anything
else
like
it
like.
I
H
Because
we
do
have
it
in
VPP,
which
is
a
user
space
to
the
plane,
we
do
have
stock
support
for
SCTP
and,
in
that
case,
knew
that
the
trick
is
actually
having
the
full
stack
behind.
It.
I
think
the
problem
you're
describing
happens
when
you
try
and
sort
of
mix,
kernel
mode
and
user
space
mode
when
part
of
your
stack
in
user
space
is
being
provided
by
the
Earl.
Is
that
more
or
less
correct,
yeah.
I
So
once
I've
heard
about
this
problem,
I
got
with
this
in
the
scope
of
this
request.
I
searched
for
the
for
Forex
and
then
I
found
a
lot
of
problem.
Descriptions
that
was
the
root
cause
was
that
there
there
was.
A
user
specifically
use
your
application.
So,
on
top
of
layer,
3
layer,
3
up
to
layer
3,
it
was
of
corazon
kernel
and
layer.
I
Yeah,
if
what
is
required
and
of
course,
what
we
can
first
do.
The
first
idea
is
to
how
to
say
copy
the
old
solution
that
was
before
containers
and
kubernetes,
which
means
that
machines
nodes
were
dedicated
for
user
space,
SCTP
applications
and
the
other
applications
were
those
will
run
on
on
other
machines
and,
of
course,
in
kind
of
kubernetes.
It
means
that
they're,
a
paint
that
you
talked
about
it
should
it
should
be
used
by
the
cubicle
to
proxy
itself.
I
E
Right,
that's
that's
new!
The
main
headache,
that's
something
that's
again
without
precedent,
but
doesn't
seem,
doesn't
seem
irreconcilable
to
have
sort
of
dedicated
pools
of
equipment
for
user
space.
I,
wonder
if
there's
other
creative
solutions
with
multiple
IPS
or
multiple
interfaces
or
some
other
way
to
distinguish
apps
that
want
to
use
user
space
and
kernel
space.
I
really
have
no
experience.
I
have
no
testbed
I've,
never
written
an
sctp
program,
so
I
have
to
a
little
bit
push
it
back.
Not
you
guys
and
say
help
me
to
find
a
way
to
make
this
doable.
E
H
You
know
so
I
think
I
think
that
the
trick
there
is
I
made
a
comment
there,
because
we
do
have
it
implemented
in
VPP.
We
take
sort
of
a
very
different
approach
than
riding
on
top
of
the
kernel,
l2
and
l3
stack,
because
we
have
a
fast
for
stack
for
l2
and
l3.
Then
the
kernel
is
I.
Do
know
that
there
are
user
space
stacks
for
TCP.
That
do
not
seem
to
have
this
problem
of
coexisting
with
the
kernel.
H
Think
last
look
pretty
if
I'm
wrong.
The
real
problem
is
that
if
you
have,
if
you
load
the
sttd
kernel
module
at
all,
and
someone
tries
to
speak
a
CTD,
which
has
a
unique
IP
protocol
number
that
effectively
the
SCTP
stack,
grabs
it
and
makes
it
inaccessible
for
anyone
who
were
to
say
open
a
raw
socket
on
an
interface
to
get.
It
is
that.
H
H
E
E
I
So
the
problem
description
was
something
like
that.
If
you
load
the
camera
module
as
well,
then
it
also
grabs
the
packets
and
and
then
it
just
says
that
it
is
not
recognizable
for
me,
it's
not
an
sctp
connects
connection
or
Association
that
I
know,
so
it
sends
an
abort
automatically
and
edit
the
attribute
it
just
switches
through
instead
of
connection
existing
connection
of
the
owner
of
the
user
and
setp
operation,
I
mean.
E
That
that
smells
like
a
bug
to
me,
but
it's
not
surprising
that
nobody
knows,
because
in
20
years
I've
never
used
SCTP.
So
it's
probably
a
very
niche
group
of
people
who
have
all
individually
worked
around
it
and
don't
actually
care
to
fix
it
right.
But
it
might
be
worthwhile
to
have
a
conversation
with
somebody
in
kernel
and
Linux
kernel
and
who
understands
this
area
on
the
net
dev
mailing
list
or
something
well.
B
I
So
of
course,
because
there
are
user,
specific
istex,
it
is
possible
to
put
it
into
the
coop
queue
proxy,
so
it
can
can
start
working
like
that.
The
problem
comes
when
you
know
you
would
like
to
direct
the
traffic
from
the
cluster
IP
to
this
user
face
and
a
city
respect,
because
currently
IP
tables,
ruse
and
ipbs
rules
are
used
for
death.
As
I
understand
on
the
note
now,
if
in
iptables
we
enter
the
protocol
like
a
CTP,
then
it
loads
the
camera
module,
which
is
wrong
bad.
I
So
what
we
have
to
do,
then,
is
that
we
have
to
solve
this
purely
based
on
IP
addresses
so
anything
sent
to
that
cluster
IP.
It
will
be
sent
up
or
sent
to
go
to
the
IP
address
where
the
user
land
a
city,
pista
reasons,
and,
of
course
it
means
that
this
service
that
got
disgusted
IP.
It
cannot
support
anything
else,
but
a
city
P,
so
it
cannot
be
TCP
or
UDP.
That's
a
limit
that
may
be
a
limitation
I
know.
I
didn't.
I
E
B
E
E
Maybe
maybe
I
mean
we
could
say
that
the
broadest
brush
we
could
paint
this
with
is
user
space
SCTP
is
out
of
the
scope,
and
if
you
want
to
do
that,
you're
on
your
own
have
fun
and
but
I
don't
know.
If,
like.
If
that's
80%
of
SCTP
users,
then
maybe
we
shouldn't
do
that.
That's
10%
of
SCTP
users
that
I
feel
less
bad
about
it
and
I
have
no
data
to
indicate
whether
that
which
which
of
those
cases
it
is.
H
Yeah
also
would
be
to
investigate
more
closely.
The
two
other
points
I
have
are
most
the
people
I
know
who
care
about.
Seq
in
the
modern
world
are
in
mobile
II
and
looking
at
these
stuff
for
5g
and
I
do
know
they.
On
the
TCP
horseback
side,
a
lot
of
people
looking
to
build
vnfs
are
looking
for
alternatives
to
the
kernel
stack
for
performance
reasons.
None
of
those
actually
directly
connect
up
to
anything
meaningful.
It's
just
interesting
that
there's
more
data
to
be
found.
Okay,.
D
I
E
D
I
I
A
J
Right
so
I
discuss
this
a
little
bit
on
mailing
lists.
I
know,
Casey,
you've
been
nervous
about.
This
is
Casey
here
yeah.
This
is
easy
right,
so
you've
been
nervous
about
the
idea
of
implementing
it
because,
well
specifically,
the
issue
is:
do
how
network
policy,
whether
Network
policy
contributes
in
that
high
rate
plus
plus
or
not,
and
if
so,
how
you
know
it
sounds
very
expensive.
The
way
we've
defined
it.
J
The
issue
is
that,
because
you
know,
the
definition
that
we've
been
bandying
about
is
a
very
complete
one
and
since
filtering
on
either
side
of
a
connection
contributes
to
the
readiness
of
both
pods
on
either
side.
Of
that
connection,
you
have
to
go
around
and
gather
a
lot
of
information
before
you
actually
know
that
a
given
pod
is
ready,
and
so
you
know
I'm
trying
to
figure.
Does
anybody
care
to
try
to
implement
a
network
policy
contribution
to
pod,
ready,
plus
plus?
And
if
so,
you
know
what
I?
J
A
A
That's
part
of
why
I
was
a
little
bit
concerned
about
a
trade
off
you
that
you
kind
of
touched
on,
which
is
the
more
complete
you
try
to
make
the
the
readiness
assertion
the
the
more
thud
I
start
to
feel
about
how
it
performs
in
a
thousand
or
two
thousand
node
cluster
with
you
know,
hundreds
of
thousands
of
pods,
so
yeah
there's,
certainly
some
worry
there
I
think
there's
you
know
it's
not
like
an
impossible
task
tackle.
We
could
implement
it,
but
I.
A
E
Is
there
anybody
who's
doing
network
policy
in
sort
of
a
non
fast
way
like
we
sort
of
get
away
without
this,
because
you
know
the
propagation
within
a
single
cluster
and
iptables
programming
is,
is
reasonably
quick,
and
so
it's
that
big
of
a
deal
but
I'd
be
curious
to
sort
of
echo
Mike's
question:
is
anybody
out
there
actually
planning
on
a
network
policy
implementation
that
is
based
on
something
that
has
like
whole
second
programming?
Ladies,
we.
D
Have
some
of
that
with
ovn
kubernetes?
But
that's
mainly
because
of
a
few
reasons
that
we
are
working
to
reduce
and
can
reduce,
and
that's
mostly
because
of
the
way
that
events
are
delivered
via
for
kubernetes,
that
you
know
like
the
namespace.
Events
are
different
from
the
pod
events
and
things
like
that,
and
it
could
be
a
few
seconds
or
something
like
that
before
things
actually
work
out,
because
you
have
to
propagate
those
events
all
over
the
cluster
and
then
make
some
local
changes.
D
But
again
that's
something
that
we're
working
to
reduce
the
time
on
that.
So
hopefully
we
can
get
it
down
to
like
less
than
a
second
or
something
like
that.
But
I
can
imagine
that
if
you
had
a
large
cluster
and
some
nodes
are
running
a
little
bit
behind
in
the
event
stream,
because
there
maybe
were
a
lot
of
events
that
you
might
not
get
the
necessary
events
for
Network
policy
before
before
the
container
came
up.
J
Right
but
as
you
say,
you
know
it's
it's
a
little
tough
to
say
that
it
hasn't
happened
or
won't
happen.
That's
ultimately,
there
is
an
argument
that
someone
made
earlier
I
forget
who
it
might
have
been
you
that,
with
a
little
bit
of
care,
we
can
call
this
an
advantage
rather
than
a
disadvantage.
That
is
to
say
first
off,
if
the
let's
see
yes
so
in
network
policy,
there's
the
only
blacklisting
is
the
implicit
blacklisting
at
the
empty
non-empty
discontinuity,
and
that's
that's
what
it
needs
to
propagate
fast.
So
the
other
thing
is
appropriate.
E
I
mean
I
I,
like
the
argument
on
its
face
I'm
concerned
about
the
same
sort
of
rolling
update.
If
you
that
we
have
today
with
load
balancers
like
let's
imagine,
a
pathological
metropolitan
takes
30
seconds
update
the
firewalling
in
in
fabric
in
that
case
is
not
participating
in
network
policy.
Then
you
could
start
the
rolling
update.
You
can
see
ready
and
you'd
blast
through
your
entire
deployment
before
policy
had
been
enabled
for
even
one
replica.
Is
it
a
huge
deal
for
external
facing
stuff?
E
It
is
fortunately
external
facing
stuff,
isn't
subject
to
network
policy
right,
oh,
not
that
huge
a
deal
had
it
from
the
inside.
It
would
just
appear
as
a
brief
outage
and
hopefully
people's
applications
are
resilient
to
that,
but
I
prefer
not
to
make
accidental
chaos
monkeys,
but
I
guess
in
that
case
I
mean
I'm,
imagining
a
model
where
the
firewalling
is
centralized
and
in
that
case
it
participate
in
ready,
plus
plus
because
it
doesn't
have
to
do
sort
of
them.
Both
ends
testing.
E
D
It
occurs
to
me
that
if
you
have
a
more
centralized
mechanism,
then
you
can
always
block
the
pod
from
even
returning
networking
readiness.
You
know
I
mean
from
returning
from
the
CNI
call
for
add
until
you're
sure
that
most
things
are
ready.
Wouldn't
this
only
be
a
problem
where
you
have
a
much
more
distributed
system
where
you
may
not,
because
you.
J
E
J
J
I
was
going
to
suggest
that
maybe
one
answer
is
that
we
settled
for
making
the
network
policy
contribution
to
pod
ready
concern
ocol
only
the
local
filtering
and
not
the
remote
filtering.
But
again
it
was
based
the
sort
of
argument
that
I
was
saying
earlier.
You
know
if
we,
if
the
only
gap
is
slow
whitelisting,
then
that's
gonna
be
okay
and
you're,
saying
you
don't
really
buy
that
so
I
guess
I,
don't
have
an
argument
still.
J
E
I've
certainly
I've
heard
people
who
wanted
to
do
firewall
like
fabric
firewall
based
implementations,
I,
don't
know
if
those
have
programming,
latency
issues
or
not
they're,
not
here
on
the
call
that
would
presume
they
would
be
similar
to
a
load
balancers.
So
probably
they
would
have
those
issues,
but
they're
centralized
I
mean
we
could
we
could
emulate
this
I
taking
calico
and
throwing
a
sleep
ten
in
for
you
right,
and
we
certainly
see
the
problem
I'm,
not
sure
that
that
would
do
anything
but
confirm
the
fact
that
we
suspect
this
exists
exactly.
J
A
J
J
D
E
Catches
up
with
me,
okay,
cool
I,
would
like
to
propose
that
the
main
focus
of
two
weeks
from
now
be
other
work
that
people
want
to
get
done
in
this
next
cycle.
Unless
there's
other
people
who
want
to
talk
about
that
stuff
now,
like
there's,
been
a
few
caps
that
have
crossed
my
radar
and
there's
a
bunch
of
open
proposals
that
I'd
like
to
be
able
to
circle
back
to.
If
we
can
but
like
everything,
they
all
need
stewards
and
without
stewards,
they're,
just
not
going
to
make
progress.