►
From YouTube: Kubernetes SIG Network meeting for 20200920
Description
Kubernetes SIG Network meeting for 20200920
A
First
item
on
the
agenda
also,
please
add
any
other
agenda
items
to
the
bottom,
just
a
note
that
we
will
be
enabling
passcode
on
the
sig
meetings
starting
next
meeting.
That's
a
request
from
for
all
sigs
for
kubernetes
to
deal
with
moderation,
issues,
zoom
bombing,
that
kind
of
thing
there's
a
link
there
with
a
little
bit
more
information.
A
B
A
A
E
G
C
All
right
I've
been
having
some
trouble
with
zoom
web
client
and
getting
audio
glitches.
So
please
scream,
if
you
can't
hear
me
if
it
glitches
out
also,
my
kids
are
about
to
get
online
for
school
again,
so
I
might
start
fighting
for
bandwidth.
So
let's
do
it
all
right,
starting
at
the
top
support
multiple
cluster
sliders
in
cube
controller
manager
by
our
very
own,
anthony.
A
H
C
A
A
C
But
we
wanted
we,
we
took
a
bpr's
at
the
end
of
last
year
to
make
cube
proxy,
not
look
at
the
cluster
cider
right,
the
goal
being
that
human
proxy
shouldn't
need
to
be
aware
of
the
cluster
cider
for
almost
anything,
and
so
the
this
was
the
multi-uh
multi-cider
work.
That
satya
was
doing.
If
you
guys
remember
that
which
goes
to
the-
I
guess
the
previous
issue,
but
I'm
trying
to
understand
what
this
one's
about.
H
So
we
added
a
bug
fix
that,
sometimes,
if
you
lose
packets
and
then
you
get
an
incoming
packet,
it
will
cause
because
of
ip
tables
and
contract
weirdness.
It
will
cause
your
long-term
connection
to
suddenly
be
dropped
like
a
long-term
connection
from
outside
the
cluster
to
a
service,
or
maybe
the
other
way
around
anyway.
H
We
added
a
fix
for
it,
but
it
turns
out
that
it
breaks
people
who
are
doing
crazy
things
with
multiple
interfaces
and
stuff
like
that
asymmetric
routing,
yeah,
there
we
go
so
they're
saying
we
need
to
limit
the
the
rule
in
q
proxy
that
drops
invalid
packets,
but
it
gets
hard
to
do
that.
Well,
because
q
proxy
doesn't
necessarily
know
which
packets
it
is
and
isn't
supposed
to
be.
C
H
What's
the
admissions
if
a
packet
gets
dropped
and
then
contract
sees
a
packet
with
the
wrong
sequence
number
it
ends
up
like
not
getting
natted
or
unnatted
correctly
or
something,
and
then,
when
it
sends
back
the
response,
the
peer
sees
the
the
packet
you'll
have
to
read
it
and
get
all
the
details,
but
it
ends
up
causing
the
pure
to
send
to
reset
and
kill
the
connection,
because
ip
tables
and
contract
are
are
doing
the
wrong
thing.
Basically,.
A
G
B
C
G
C
I
E
C
J
C
For
broader
context,
there
was
some
discussion
with
say
test
folks
that
I
had
last
week
about
whether
it
makes
sense,
in
the
long
term
to
have
e
to
e
the
project
e
to
e
tests
that
are
being
exercised
via
the
cloud
provider
logic
or
whether
it
would
make
sense
to
write
a
fake
ingress
controller.
That
just
came
back
and
said.
Like
yes,
end
to
end.
This
did
in
fact
do
the
right
thing,
but
not
actually
waiting
for
provisioning.
E
A
C
C
You
got
it
thanks
to
everyone
else,
who's
watching
the
triage.
Remember
we're
not
asking
you
to
fix
the
bugs
we're
just
asking
you
to
help
triage
them,
so
don't
be
don't
be
shy,
feel
free
to
sign
up
cube
proxy
configuration.
Api
tests
are
not
validating
errors
correctly.
The
q
proxy
config
api
validation
test.
That's
a
long
phrase,
cube
proxy's,
config,
api
validation.
I
think
we
can.
K
C
K
C
C
H
D
D
C
L
H
C
C
C
A
C
C
C
B
H
H
C
G
G
H
H
Now
capability
will
move
to
beta
when
the
following
criteria
have
been
met.
Kubernetes
types,
finalized,
cri
types,
finalized,
pods,
support,
multiple
ips
nodes,
support,
multiple
ciders
service
resource
supports
pods
with
multiple
ips
cubenet
supports
multiple
ips,
so
I
guess
kubernetes
types
finalized
is
the.
C
H
C
A
F
A
A
A
A
M
M
M
A
D
D
H
It's
a
convenient
way,
but
it's
nice.
If
the
cloud
provider
can
know
that
it's
getting
a
consistent
request.
Like
you
know,
the
cloud
provider
has
to
double
check
to
make
sure
that
the
the
requested
load
balancer
id
are
the
same
as
the
the
target
ips
that
it's
going
to
be
load
balancing
it
to
then
that's
just
creating
extra
work
for
for
every
single
cloud
provider.
G
F
C
G
C
M
C
C
Yeah
I'm
worried
like
lars
says.
You
know,
I
mean
a
comma
separated
list
feels
like
it
was
a
little
bit
out
of
bounds,
but
I
didn't
look
at
the
pr
that
changed
the
validation.
I
probably
would
have
flagged
that
as
potentially
breaking
changing
it
so
that
it
has
to
be
the
ip
addresses
the
families
that
match
like.
If
it's
not
families
that
match,
I
don't
see
how
it
would
work
right.
C
A
C
K
C
So
they
are
the.
I
don't
think
we
should
expose
them
because
they
are
implementation,
details
of
the
default,
but
not
exclusively
only
controllers.
Right,
like
we
know
it's
possible
for
services,
service
ips
to
be
allocated
out
of
some
other
ipam
system
or
not
service
like
these
pod
ips
to
be
allocated
out
of
some
other
ipam
system,
and
so
we,
like
the
those
fields,
may
have
no
meaning
in
some
systems.
A
K
A
A
I'd
be
really
curious.
What
people
want
to
do
with
these
values
if
they
had
them,
it
seems
like
it's,
like
tim,
said,
an
implementation
detail
of
how
the
network
plug-in
sets
things
up,
and
I
guess
I'd
expect
that
the
network
plug-in
implementing
this
would
already
know
those
values.
So
maybe
there's
a
better
way
of
doing
what
components
that
want
to
know
these
things
that
do
as
opposed
to
reading
the
cluster
citers.
K
Yeah,
I
think
it's
the
cni
people,
I
guess
in
general-
that's
where
we
hit
it
was
you
know,
we've
got
to
see
an
eye
and
it's
like
needs
to
know.
If
the
service
ips
are
cuz,
it
wants
to
set
up
some
rules,
and
you
know
the
way
it
gets.
Those
right
now
is.
We
have
to
plumb
them
through
the
install
process.
K
G
So
I
I
agree
around
cluster
cider
like
the
cni,
should
know
that
ahead
of
time.
But
I
think
there
are
some
use
cases
specifically
for
service
sider,
where,
like
the
cni,
might
need
to
know
what
that
ranges
to
route
traffic
in
different
ways
and
there's
no
way
to
like
easily
query
the
service
sider
from
the
api
server
or
anywhere
so,
like
the
users
have
to
configure
server
sider
into
the
cni
as
well,
which
is
inconvenient.
C
So
if
I
can
rant
for
a
second
like
one
of
the
medium
term,
objectives
still
is
to
get
rid
of
those
places
that
have
one
sider.
So
it
seems
completely
inevitable
to
me
that
eventually
we
end
up
with
multiple
service
siders,
so
we
have
to
build
that
into
the
schema
right
away,
but
also
that
that
could
change
dynamically.
So
we've
had
customers
who
have
you
know
built
a
cluster
with.
You
know,
x,
space
for
services
and
realized
that
that
wasn't
enough
and
then
they
want
to
know.
C
C
C
C
Cubelet
knows
some
about
this,
see
the
bug
about
hostport
manager
and
cubeproxy
knows
some
of
this
and
the
api
server
knows
some
of
this
and
the
controller
manager
knows
some
of
this
and
the
network
policy.
Implementation
knows
some
of
this
and
each
of
them
kind
of
wants
to
know
information
about
each
other,
because
they're
not
completely
mix
and
matchable,
and
so
I
keep
coming
back
to
like,
I
feel
like
the
model
is
fundamentally
broken
and
we
need
to
if
we're
going,
to
try
to
make
these
things
more
aware
of
each
other.
C
Let
me
back
up,
imagine
imagine
an
omnibus
driver
that
covered
all
of
the
various
networking
topics
right
and
you
pick
one
right.
So
I'm
going
to
pick
the
fubar
network
driver
and
that
includes
which
cni
I'm
using
which
services
implementation,
which
network
policy
implementation,
which
ipam
etc,
and
those
things
can
all
know
about
each
other
because
they're
all
highly
coupled
but
from
the
outside
it's
effectively
a
black
box.
A
A
C
G
A
F
H
C
So
at
risk
of
contradicting
myself,
would
it
make
sense
for
us
to
offer
like
a
an
optional
internally,
scoped
crd
or
something
that
that
was
very
specifically
like?
This
is
an
implementation
detail
and
if
you
depend
on
it,
you
are,
you
know
in
inherently
depending
on
the
implementation,
but
here's
some
information,
you
probably
shouldn't
know.
A
C
A
C
A
Well,
yes,
but
what
I
mean
is
like
there's
a
difference
between
the
current
way
that
we
do
cluster
cider
pod
cider
allocations
in
network
plug-ins
with
their
own
ipam
versus
what
we
do
for
service
citers,
where
the
service
controller
is
the
thing
that
does
it.
You
can't
swap
that
implementation
out,
so
you
either.
C
For
better
or
worse,
the
only
way
that
we
are
currently
offer
to
do
service
cider
is
through
the
api
server
and
it
is
going
to
track
currently
a
bitmap
of
all
the
service
ips
that
it
has
allocated
now.
I
know
some
customers
have
put
like
an
admission
controller
in
front
of
services
and
they
do
their
own
allocation,
but
the
api
server
still
is
going
to
validate
it
against
the
range
and
a
bitmap
right.
C
A
C
C
G
N
Yeah
so
dan-
I
already
spoke
about
this,
and
a
few
of
you
have
also
spoken
about
this.
Basically,
I
came
across
a
bug
where
the
user
was
having
multiple
cluster
siders
and
our
plug-in
was
trying
to
call
cryptroxy
for
the
local
traffic
detection
and
it
wasn't
working.
Obviously,
I
was
pointed
to
the
specification
that
I've
linked
in
the
in
the
agenda.
N
I
thought
it
was
implemented,
like
antonio
helped
me
verify
that
it's
not
so
the
proposal.
As
per
the
proposal,
we
should
be
supporting
cluster
side
and
outsider
interface
or
bridge,
but
today
I
think
we
support
only
the
cluster
and
node
and
nodesider,
I'm
still
not
sure.
If
it's
fully
supported
or
not,
I
am
quite
new
to
the
project,
so
I
might
need
help
verifying
that
and
also
the
cli
part
according
to
the
implementation
there's
also
cli
part,
I
don't
really
care
about
the
cli
part.
N
C
C
N
I
don't
think
so.
I
mean
we
discussed
this
and
our
plugin
does
not
really
leverage,
because
nodesider
is
actually
using
the
node.spec.podsiders
or
cider,
and
we
don't
leverage
that
as
of
today,
so
we
were
actually
looking
to
either
have
the
interface
thing
implemented,
which
is
what
dan
vinshave
suggested,
or
maybe
even
the
bridge
for
that
matter.
C
N
J
J
C
J
J
C
H
C
J
C
Don't
you
might
be
right?
I
don't
recall
that,
but
my
memory
is
terrible,
so
the
harry,
the
issue
that
I
am
worried
about
is
the
service
author
specifically
said.
I
want
this
to
be
a
vip
and
if
we
offer
any
record
at
the
services
name,
that
is
different
than
that.
It
seems
counter
to
what
the
user
asked
for.
J
M
C
C
C
C
C
C
J
C
O
Yeah,
I
will
try
to
make
it
quick,
so
there
is
a
very.
I
don't
think
it's
complicated
issue
like
small
pr
that
I
would
love
somebody
from
this
group
to
review.
It
requires
couplet
approvers,
but
it's
clearly
sig
network
related.
The
reason
I
came
here
is
I
wanted
to
ask
what
the
best
practices
and,
like
maybe.
O
Some
standards,
how
like
kublet,
operates
with
cni
in
this
particular
case,
the
duplication
of
not
port
methane
happens
in
kublet
and
then
pass
to
cni.
So
I
was
wondering:
do
we
need
to
have
the
duplication
logic
at
all
on
google
on
complete
side,
or
we
need
to
pass
it
to
cni
and
like
forget
about
it?
O
Yeah,
this
is
a
restart
of
pr
that
got
rotten,
so
I
just
restarted
it
and
I
cleaned
up
some
logic
around
this
pr
as
well.
So
there
were
a
lot
of
questions
in
previous
pr.
How
name
is
used?
How
like,
like
how
kubot
configures,
node
port
mapping
and
I
removed
all
those
legacy
codes?
So
it's
much
easier
to
review
now.
C
O
C
O
O
O
So
this
is
a
host
port
mapping,
so
mapping
node,
not
port
to
container
port
and
if
port
definition
has
multiple
mappings
that
are
matching
that
exactly
the
same,
then
only
one
will
be
used.
Only
one
will
be
passed
to
cni
my
question.
My
end
warning
will
be
reported
to
customer
like
it's
a
warning,
clog
message.
So
the
question
is:
do
we
need
this
logic
at
all
or
we
just
pass
all
the
port
mappings
to,
as
is,
and
cni
will
figure
out
how
to
do
this
application
better.