►
From YouTube: Kubernetes SIG Network meeting for 20230914
Description
Kubernetes SIG Network meeting for 20230914
A
Hello,
everyone
and
welcome
to
the
September
14th
Edition
of
the
Sig
Network
meeting
as
usual.
This
meeting
is
governed
by
the
kubernetes
code
of
conduct,
which
effectively
boils
down
to
be
nice
to
one
another.
So
please
do
be
nice
to
one
another.
If
you
can,
when
you
want
to
interject,
ask
questions
and
stuff
like
that.
Please
use
the
raise
hand
feature
in
Zoom
because
that's
very
helpful
for
us
to
prioritize
and
kind
of
keep
things
moving.
A
We
have
a
very
late
agenda
for
today.
It
is
an
open
Agenda.
So
if
you
want
to
add
something
after
the
last
agenda
item,
that
would
be
fine
if,
for
some
reason
we
had
like
10
all
of
a
sudden
any
that
we
don't
get
to,
we
can
flood
over,
but
I
doubt
that'll
happen
and
we'll
start
off
with
triage.
A
So
I
have
already
opened
in
order
oldest
to
newest
all
of
the
unassigned
triage
issues,
including
this
one.
That
was
a
reopen
nodes
behind
Nat,
not
starting
which
Tim
it
looks
like
you're
the
last
one
to
look
at,
but
it.
B
E
A
B
E
E
D
I
mean
I,
remember
looking
at
the
issue
and
going
wow,
that's
not
really
one
we
planned
for
and
then
it
went
away,
and
you
know
like
so
many
issues
here,
somebody
whoever
filed
it
got
satisfied
enough
that
they
didn't
bother
following
up
and
and
it
aged
out,
is
what
it
looks
like
yeah,
exactly
Theta
bot,
okay,
it's
it's
not
that
I'm,
saying
like
no,
we
don't
want
to
solve
this.
D
F
The
public
IP,
even
known
here,
I,
mean
I,
see,
has
a
variable
for
us,
but
so
I
should
assume
that
at
least
it's
known
when
doing
this
or
is
it
method
on
the
outside
somewhere.
D
Also,
a
good
question
thought
it
was
known
if
I
remember.
C
E
A
F
A
D
D
A
Foreign,
maybe
it's
not
something
we
can
figure
out
synchronously
right
now,
but
we
need
to
take
some
time
to
think
about.
So,
if,
if
anybody
wants
to
do
that,
just
you
don't
have
to
commit
to,
like
anything
other
than
just
trying
to
tease
it
out
a
little
bit
further,
and
just
we
get
to
a
point
where
we
want
to
maybe
not
accept
it.
A
D
I'll
leave
it
open
to
think
about
it.
I
hadn't
looked
at
it
yet
this
week,
I.
F
B
D
C
I
was
going
to
say
first
there.
There
is
also
another
ancient
issue
somewhere
about.
It
should
be
possible
to
register
an
external
IP
for
like
in
in
the
cubelet
args,
which
might
also
help
this
person.
What
is
node
IP,
actually
used
for
yeah,
so
I
think
a
lot
of
cni
plugins
use.
It
is
one
thing
you
know,
for
instance,
for,
for
you
know,
tunneling
packets
to
other
nodes.
They
use
the
the
publish
node
IP
of
the
of
the
node.
D
D
If
that's
the
case,
then
setting
node
IP
to
the
natted
address
would
go
out
their
private
Network
and
back
in
in
order
to
go
node
to
node,
yep
I
know
we
use
it
in
things
like
describe
or
get
service.
You
know
the
the
end
points
for
a
host
for
host
pods
right.
We
we
set
the
host
IP
there.
C
Yes,
host
Network
pods
will
have
a
pod
IP.
That
is
the
the
nodes
node
IP.
D
Calling
it
the
node
IP
is
actually
really
not
a
great
idea.
I
mean
it
seems
like
the
wrong
semantic
to
me
to
go
outside.
C
C
A
Indeed-
and
they
did
have
this
other
one-
that
wasn't-
it's
not
labeled
sign
Network
yet,
but
Antonio
talked
to
them
a
little
bit
about
it,
and
it
looks
like
just
asking
for
clarifications
so
I'll
try
to
follow
up
and
see
if
we
can
get
some
clarifications
here.
I
appreciate
anybody
who
can
drop
some
comments
with
some
questions
for
clarifications
and
we'll
see.
If
we
want
to
move
forward
on
this
one
or
not.
D
I
think
this
is
one
of
those
dirty
Corners
that
nobody
has
really
wanted
to
try
to
sweep
up
this
whole
node
addresses,
stuff
and
and
Dan
has
done
a
lot
of
work
there,
but
the
dirt
is
pretty
deep.
D
E
Mean
it's
not
necessarily
unreasonable
that
you
might
want
to
have
I
think
what
we
used
to
call
a
stretch
cluster
in
openshift,
where
you've
got
like
a
node
way
over
there
somewhere
and
a
node
over
here
and
somewhere
in
the
middle.
Of
course.
You've
got
issues
with
latency
between
those
nodes,
but
assuming
that
latency
is
not
a
problem,
you
know
you
could
have
those
nodes
in
different
places
and
they
could
be
netted,
and
so.
D
The
problem
is
that
the
problem
is
that
the
node
addresses
started
with
assumption
that
everything
was
in
a
flat,
Network
space,
and
then
that
turned
out
to
not
be
true
and
we've
sort
of
chipped
away.
At
this
idea
of
of
like
split
Horizon
addressing
depending
the
address
you
get
depends
on
where
you're
coming
from.
But
we've
done
a
really
poor
job
of
sort
of
drawing.
E
F
D
No-
and
we
know
things
like
the
connectivity
that
you
know-
control
plane
back
to
nodes
is
not
assumed
to
be
connected
anyway,
right.
D
F
So
they're
going
to
make
a
picture,
but
it's
easy
to
understand
I
still
worse
than
that.
Why
is
that
address?
I?
Think
it's
on
the
outside
I!
Think
that's
what
it's
saying
and
it's
not
on
the
Node
itself.
It
happen
on
the
outside
and
then
it's
really
up
to
the
service
to
set
this
up
what
you
can
expect
and
then,
when
you
know
what
you
can
expect
well
then
you
can
use,
maybe
some
tricks.
D
D
That's
why
we
have
this
RPC
connectivity
API,
like
maybe
the
answer
here,
is
actually
you
need
to
implement
a
connectivity
plugin
that
understands
how
to
reach
from
the
control
plane
back
to
the
nodes,
even
if
it's
just
a
simple
like
extract
the
DNS
name
from
a
different
field
and
talk
to
that.
Instead,
right,
like
we
had
the
SSH
implementation,
we
have
the
new
agent
connectivity
implementation.
We
have
a
flat
implementation.
Maybe
this
is
a
different
sort
of
flat,
but
DNS
implementation.
A
Worries
no
I'm
going
to
kind
of
gloss
over
this.
No
that's
good
I'm
going
to
kind
of
gloss
over
this
one,
because
Windows
is
kind
of
moving
it
along
and
it's
Windows
specific,
but
we
can
come
back
to
it
if
they
need
our
help.
How
to
manually
disable
IPv6.
A
Yeah
yeah
I
know
if.
A
You're
moving
backwards,
not
forwards.
What
are
you
doing
wants
a
way
to
disable
IPv6.
C
C
D
C
A
Yep
so
they're
probably
taken
care
of
I'll
double,
read
it
just
to
make
sure
there's
nothing
missing
in
the
minutia
of
it,
but
it's
probably
just
closed
done.
I
mean
job
constantly
failing
on
replica
set
and
replication
controller
tests.
This
is
just
Antonio
reporting
a
problem
with
our
tests,
see
where
he
left
off
with
it.
The
fix
is
in
that
one,
so
this
is
accepted.
This
is
in
this
is
being
worked
on.
A
A
These
are
great
ones.
I
love
this
kind
of
triage,
everything's
done
or
all
right
umbrella
issue.
Oh
I,
remember
this
one
Jay
just
made
this
one.
The
other
day
there's
been
a
lot
of
conversation
on
this,
so
the
tldr
for
this
one.
There
are
many
moving
Parts
in
case
clusters
that
may
use
or
depend
on
these
annotations
tapes,
and
you
know
in
ambiguous
ad
hoc
sort
of
ways.
This
makes
it
confusing
for
users
and
vendors
to
know
when
they
should
or
shouldn't
manipulate
the
values
of
such
I.
A
A
C
C
This
is
basically
we
I
guess
we
should
accept
it.
The
the
the
docs
are
not
totally
explicit
on
the
fact
that
Network
policy
applies
to
connections
rather
than
packets,
and
it's
currently
not
clear
that
it
only
applies
to
connections
made
after
you
define
the
network
policy,
which
I
don't
know.
You
know
if
we
want
to
make
that
explicit
or
not,
but.
F
D
Yeah
my
concern
with
documenting
it
as
connection
oriented
I
mean
I
think
we
did
discuss
this
way
back
in
the
day
when
we
were
first
talking
about
Network
policy,
which
you
know
as
an
aside
I
have
a
interesting
memory.
Pin
on
that
one,
because
I
remember
sitting
in
line
to
get
into
Star
Wars
the
Force
awakens
working
on
network
policy,
design
docs,
so
I
was
at
the
mall
sitting
on
the
floor
so
like
in
my
memory.
There's
like
one
thing
that
pins
it
to
a
timeline.
D
That's
how
long
ago
it
was
I
remember
discussing
whether
we
would
consider
it
invalid
for
an
implementation
to
be
packet
oriented
instead
of
connection
oriented.
If,
if
an
implementation
shows
hey,
there's
a
new
policy
I'm
going
to
break
that
TCP
connection.
Is
that
wrong?
Or
is
that
acceptable.
C
F
D
Agree
so
yes,
reply,
packets
are
should
be
implicitly
allowed
and
connection
versus
packet
is
implementation
defined.
Is
that
fair
yeah?
So
we
accept
it?
Is
somebody
going
to
go
and
update
Docs
volunteers.
B
C
F
A
A
E
Yeah
I
just
thought
it
might
be
useful
to
come
back
around
to
this
one.
The
meeting
agenda
Doc
is
and
has
been
for
geez
eight
years
on
my
personal
Gmail
account
as
the
owner
I
know.
We've
talked
in
the
past
about
moving
this
to
a
more
official
location.
E
That
didn't
happen.
So
does
anybody
know
what
other
teams
are
using
for
agenda
and
stuff
like
that,
I
think
at
one
point
we
discussed
trying
to
move
ownership
of
the
document
to
some
other
official
Cube
account,
but
I
don't
think
that
panned
out
for
various
reasons
you
know
if
nobody
knows
anything
off
the
top
of
their
head,
I
can
go.
Ask
other
teams
what
they
do
and
we
can
figure
something
out.
D
D
So
we
would
need
to
talk
to
God,
I,
don't
even
know
who
owns
that
domain.
Now
somebody
and
Kate's
infra
will
know.
Maybe
our
no
or
Ben
will
have
an
idea,
and
the
small
number
of
people
who
actually
have
domain
accounts
should
be
able
to
create
a
doc
for
us
now.
I,
don't
know
if
that's
the
done
thing
or
not,
but
I
would
imagine,
it
probably
should
be,
and
then
they
can
add
us
all
as
owners
of
the
doc.
E
Okay,
I
mean
that's
a
good
place
to
start,
so
thanks
I'll
go
track
that
down.
A
F
A
C
D
Okay,
I
didn't
prep
for
today
to
do
like
kept
reviews,
but
we
need
to
do
that.
So
maybe
we'll
put
that
on
the
agenda
for
two
weeks
from
now
and
figure
out
what
caps
we
want
to
push
again.
And
you
know
what
else
is
going
through
just
run
through
the
dashboard
and
make
sure
that
we're
making
progress
where
we
want
to
be.
A
Sounds
good
do
that
next
time,
I
don't
know
just
since
we're
here.
My
one
last
thing
is
today's,
the
last
day
or
tomorrow
to
do
a
contributors
Summit
cfp,
it's
just
a
Google
form,
it's
really
basic.
So
if
you
have
anything
that
you
want
to
bring
to
the
contributor
Summit
one
last
day
to
put
that
in,
please
do
I
love
the
contributor
Summit
I'd
love
to
see
tons
of
talks
there,
especially
Sig
Network
talks
so
and.
D
Especially,
let
me
Echo
that
completely
I
love
the
talks
that
are
like
the
reality
of
working
within
a
Sig
and
how
we
made
it
work
for
us.
You
know
caps
can
be
unpleasant.
You
know
people
who
write
Caps
or
review
caps
talk
about
what
we
do
to
make,
that
less
terrible
I
proposed
a
talk
on
using
debuggers,
because
I
keep
seeing
people
with
print
apps
and
I
I
love
me
some
debugger
and
I
realize
not.
Everybody
knows
how
to
use
it.
You
know
all
sorts
of
talks
are
welcome.
So
please,
if.
F
No,
so
we
should
push
them
together.
Working
with
go
it's
a
very
cool
cool
tool.
I
mean
I've,
seen
it
because
since
I
want
to
discuss
getting
to
go,
it
basically
makes
it
possible
to
go
to
any
time
in
the
process
Lifetime
with
or
the
memory
as
it
was,
and
then
you
can
see
all
transactions
back
and
forth.
So
if
we
can
get
them
to
support
for
use
of
in
kubernetes,
that
would
be
quite
cool.
The
guy
that
found
it
has
left.
But
it's.
D
A
very
cool
tool,
interesting
I'm
I've,
been
using
delve
a
few
years
ago.
It
was
pretty
crappy
and
I
think
a
lot
of
people
wrote
it
off,
but
more
recently,
it's
actually
gotten
pretty
darn
good
and
when
I'm
trying
to
take
apart
something
that
I
just
can't
figure
out,
you
know
where
is
it
going
jumping
through
some
interface
definition
that
I
then
lose
track
of?
You
know
like
the
like
the
prisoner
running
across
the
river.
The
Bloodhound
loses
the
scent,
but
the
debugger
can
just
illuminates
everything.
A
Yeah,
that's
cool
yeah,
because
I
I
did
GDB
forever
and
then
I
went
to
lldb
and
I.
Do
that
for
rust.
But
delve
is
great
because,
like
in
Rust,
a
few
use
like
some
async
framework,
it's
a
mess
with
an
lldb,
but
delve
gives
you
like
all
that.
Go
routine
awareness,
which
just
makes
everything
so
much
easier.
Yeah
is
the
command.
D
Can
jump
between
them?
It's
great,
very
cool,
yes,
but
but
even
like
that's
true,
but
I
would
call
that,
like,
like
200
level
usage
like
even
100
level,
usage
of
just
being
able
to
step
up
and
down
through
the
stack
and
see
what's
going
on
and
inspect
your
variables
like
is
so
useful,
and
so
many
people
still
don't
know
how
to
do
it
now.