►
From YouTube: Kubernetes SIG Network meeting for 20230622
Description
Kubernetes SIG Network meeting for 20230622
A
This
meeting
is
being
recorded,
hello.
Everyone
welcome
to
the
June
22nd
edition
of
the
Sig
Network
meeting.
As
a
usual
reminder,
this
meeting
is
covered
by
the
kubernetes
code
of
conduct
boiling
down
to
effectively.
Please
be
nice
to
one
another.
So
please
do
be
nice
to
one
another
and
please
use
the
raise
hand
option
in
Zoom
when
you
can,
when
you
need
some
to
say
something
so
that
we
can
organize
making
sure
we
prioritize
people's
comments
and
so
forth.
A
Yeah
super
light
agenda
for
today,
so
we
will
go
over
triage
and
then
I
have
an
item
and
then,
if
you
have
any
other
items,
it's
an
open
Agenda.
If
we
have
time
you
know,
fill
it
up,
I
think
we're
only
a
little
bit
late
today.
So
we
should
have
plenty
of
time.
If
you
have
some
topics,
you
want
to
bring
up
all
right.
A
A
A
B
C
A
E
A
A
Okay,
so
load
balancers
should
be
able
to
preserve
UDP
traffic
when
server
pod
cycles
for
load
balancer
service
in
the
same
node,
this
test
is
flaking.
Does
anyone
here
have
some
time
to
at
least
triage
this
forward?
Take
it,
it
looks
like
you
pretty
much
from
here.
Just
have
to
go,
take
a
look
and
see
if
you
can
identify
why
the
test
is
flaking.
F
A
F
D
D
A
D
E
A
A
A
B
A
B
A
B
A
A
Could
be
improved
as
a
part
of
this
that
was
three
weeks
ago,
but
this
is
okay,
so
he's
just
basically
saying
there
may
be
some
improvements
through
the
issue
that
we
have
open
so
yeah.
Okay,
should
we
ping
Sergey
and
just
be
like
hey?
Did
you
have
any
specific
thoughts
about
how
we
can
move
this
one
forward.
A
Okay,
we'll
see
if
that
just
kind
of
brings
them
back
into
the
fold
a
little
bit
and
if
he's
got
some
ideas,
all
right,
the
next
one,
this
one's
from
this
year,
okay,
we're
back
we're
up
to
2023..
Is
it
still
necessary
to
maintain
the
limitation
on
exposing?
Oh
I,
remember
this.
We
talked
about
this
one
fairly
recently,
yeah.
A
F
D
B
A
B
It
I
mean
I
I,
don't
even
really
remember
I,
remember
some
of
why
we
did
it
I,
don't
remember
the
full
scope
of
it.
If
I
recall,
you
know
it
was
about
at
least
on
GCE.
The
load,
balancers
and
firewalls
were
set
up
in
a
way
that
made
this
a
little
bit.
Scary
and
I
know
that's
evolved
a
lot
in
the
last
nine
years
or
whenever
we
filed
this,
so
I
need
to
go
back
and
see
like
do
other.
B
A
B
F
No
I
took
it
with
him
just
one
hour
ago,
okay,
but
this
is
part
of
the
knowledge
on
chains
and
when
he
introduced
the
the
controller,
only
some
person
like
Jordan
goes
to
a
North
PR.
That's
got
Merchant
realized
that
the
semantics
of
the
nose
a
little
bit
different
that
the
devil's
letter-
and
he
made
me
open
this.
F
F
A
E
A
A
C
Yeah,
this
was
a
good
reminder.
I
did
just
comment
on
it.
I
I,
don't
know
what
we
can
do
with
it.
It
sounds
like
they're
using
something
custom
that
is
writing
to
end
points,
and
they
also
are
unable
to
reproduce
the
issue.
So
I
I
asked
some
follow-up
questions,
but
I'm
not
sure
we'll
be
able
to
do
much.
A
A
All
right
traffic
is
getting
sent
to
unready
pod
and
kubernetes
this
one.
They
can
look
at
it.
In
the
past
we
have
an
added
Readiness
probe
in
the
container
is
an
unready
State
until
it
is
fully
loaded,
but
in
case
of
horizontal
Auto
scaling
new
pod,
which
is
an
unready
state,
starts
getting
traffic.
A
A
A
G
F
G
F
B
B
A
D
B
A
A
A
So
in
the
previous
weeks
and
months
we've
been
talking
a
little
bit
about
this
and
I
drafted
this
document
a
few
weeks
ago,
shared
it
with
Tim
shared
it
with
Zappa
and
shared
it
with
the
leads
kubernetes
leads
and
stuff
like
that,
and
now
I
figured
it
was
probably
ready
to
share
with
Sig
Network.
This
is
effectively.
A
C
Yeah
I
almost
added
this
on
the
dock
itself.
I
I
took
a
quick
skim
of
this
earlier
and
one
of
my
questions
you
know
I
think
Gateway
is
one
of
the
sub
projects
that
would
be
included
in
scope
for
this,
and
my
reading
of
this
is
that
it's
actually
different
than
what
we've
been
doing
so
far.
So
I
wanted
to
understand
if
that's
intentional
or
accidental,
but
you
know
as.
G
C
A
No
I,
like
gaps
and
actually
I've,
been
influencing
helping
the
influence
of
npeps
in
network
policy,
which
is
basically
just
a
carbon
copy
of
gep,
with
a
funnier
name,
and
so
I
do
I
like
the
autonomy.
So
if
I
have
language
in
here,
that
makes
it
sound
like
everything
has
to
go
through
the
zig.
That
was.
C
Not
to
clarify
what
I,
what
I
meant
was
I
was
interpreting
the
last
section
of
selection
process
as
meaning
that
the
leads
meant
sub-project
leads
and
they
would
be
selected
by
Sig
Network
shares,
which
I
think
makes
sense,
but
I'm
just
wondering
like
for
the
the
day-to-day
maintenance.
If
a
lead
changes
like
we've
had
happen
recently
in
Gateway,
API
and
Gamma,
specifically
how
how
far
that
should
bubble
up
I
guess
and
we
can
take
this
offline,
it
doesn't
need
to
be
I
just.
A
D
F
A
But
there's
some
problems
that
I've
seen,
which
are
part
of
the
reason
why
I
decided
I
wanted
to
be
a
chair,
including
in
like
KP
G,
which
has
had
some
turmoil
where
there's
not.
We
don't
want
to
have
too
much
structure.
We
want
to
have
autonomy,
but
there's
not
enough
structure.
In
some
cases,
there's
not
a
good
feedback
loop.
A
Basically,
sigs
can
get
into
a
position.
Gateway
API
is
probably
a
bad
example
of
a
Sig
that
has
had
problems
because
Gateway
API
has
just
been
gotten
so
many
people
on
it
and
it
has
been
moving
so
quickly.
But
with
some
of
the
other
groups,
it's
been
hard
difficult
to
kind
of
get
the
support
that
they
need,
like
kpng
and
network
policy,
to
kind
of
know.
A
What
to
do
next
in
the
case
of
kpng
and
move
forward,
so
having
some
some
some
structure
in
place,
that
kind
of
says
what
these
sub-projects
actually
are,
how
they
should
be
run
and
making
a
mutual
kind
of
like
it
has
to.
There
has
to
be
some
effort
from
chairs
and
leads
at
the
higher
level.
There
has
to
be
some
effort
from
the
project.
The
person
who's,
organizing
the
project
has
to
have
some
responsibilities,
should
make
it
harder
to
kind
of
get
into
a
bad
spot
is
part
of
what
part
of
the
motivation
here
is.
A
F
B
Not
every
Sig
is
as
broad
as
Sig
network
is.
So
when
we
look
at
you
know
nominating
people
to
become
TLS
of
the
entire
Sig.
The
question
is:
does
that
make
sense,
or
does
it
make
sense
more
to
have
multiple
areas
each
with
obvious
tech
leads
part
of
it?
Is
you
know
recognizing
the
work
that
people
are
already
doing,
which
I
think
is
actually
really
important?
B
Part
of
it
is
making
sure
that
there
are
people
who
can
own
and
approve
specific
code
right
without
running
through
me
necessarily
right,
for
example
like
if
people
touched
all
the
service,
API
stuff
right,
Antonio,
you've
sent
PR's
here,
and
you
got
to
get
me
to
approve
it
because
there's
nobody
else
that
doesn't
make
sense
and
also
part
of
it.
I
was
discussing
this
just
yesterday.
B
It's
not
alone
with
Sig
network,
but
caps
right.
There
are
caps
that
are
like
sub
system
specific
that
still
need.
Someone
like
me
to
approve,
even
though
the
actual
owners
of
the
area
are
fine
with
it
right.
So
practically
speaking,
it
doesn't
make
sense
for
I'll
pick
on
Dan
because
he's
my
obvious
example.
It
doesn't
make
sense
for
somebody
to
send
a
cube
proxy
related
cap
and
then
Dan
says
okay
and
then
I
come
along
and
rubber
stamp
it
right
because
well,
Dan
said
it's:
okay,
it's
Dan's
problem,
so
that
doesn't
make
sense.
F
A
Yeah
and
in
addition
to
that,
seeing
the
burnout
of
the
last
couple
years
and
wanting
to
help
reduce
that
by
providing
more
support
and
a
little
bit
more
structure,
I
I,
also
personally
kind
of
have
been
coming
from
the
perspective
that
I
would
like
to
see
more
project
management
in
projects
sub-projects,
and
so
there's
a
little
bit
of
language
in
here.
For
that
too.
A
B
A
Just
if
everybody
who's
even
remotely
interested
in
understanding,
like
maybe
having
some
say
in
this
like
what
this
ends
up
looking
like,
please
make
comments
on
the
it's
a
it's
just
the
few
of
us
that
has
access
to
this,
make
any
comments.
Don't
worry
about
being
rude
or
anything
just
whatever,
whatever
you're
thinking
or
anything
that
bothers
you
or
anything
that
you
want
to
see
in
included,
please
add
it
there.
That
would
be
very
helpful.
B
Yeah
really
truly
go
ahead.
Truly
I
mean
the
the
proposal
that
Shane
has
put
together.
Thank
you
for
that
is
really
about
making
the
sig
healthier
and
making
things
move
faster
and
easier
and
making
sure
the
people
who
are
actually
doing
the
work
are
getting
recognized
for
doing
the
work.
I
know
that,
for
some
of
us
this
is
our
job
job
and
that
matters
the
recognition
matters
and
so
I
want
to
make
sure
that
we're
not
shortchanging
anybody
for
the
great
work
they're
doing.
A
G
B
Cool
so,
for
some
reason,
I
put
this
under
kubernetes
projects
instead
of
kubernetes
enhancements,
so
maybe
I'll
move
it
to
kubernetes
enhancements
in
the
end,
but
every
cycle
every
kept
cycle.
We
go
through
that
kep
cards
board
and
we
move
things
between
columns
and
I'm,
always
getting
lost
as
to
what's
been
done.
B
What's
coming
up
because
that's
based
on
the
old
GitHub
projects
structure
and
it
has
very
limited
metadata,
and
so
you
know
things
like
whether
the
code
was
actually
checked
in,
for
this
is
carried
only
in
comments
on
the
issues
and
the
Milestone
is
really
the
only
thing
we
have
so
I
was
sitting
there
through
this
kept
cycle
thinking.
What
would
I
want
a
dashboard
to
look
like
so
that
we
could
stare
at
it
with
this
as
a
group
and
say:
okay,
what's
moving
forward,
what
didn't
move
forward?
How
do
we
change
it?
B
So
I
came
up
with
this
I
imported
all
of
the
Caps
that
are
labeled,
Sig,
Network,
I,
think
all
of
them,
if
I
missed
any
please
tell
me
assignees,
is
auto
populated
status
is
something
that
I
created
for
us.
So
we
can
keep
track
of
where
things
are
currently
so
what
I
wanted
to
represent
here
was:
when
did
the
status
get
changed?
B
B
You
know
whenever
you
get
a
moment,
take
a
look
at
it.
You
can
help
populate
it.
There's
a
gate
column
here
that
we
can
go
paste
in
all
the
feature
Gates
so
that
we
don't
have
to
go
searching
through
caps
for
them.
Unfortunately,
it
is
yet
another
source
of
information.
There's
kepiamo,
there's
the
text
itself,
there's
the
issue
that
goes
with
the
kep
and
now
there's
this
I,
don't
know
how
to
link
all
these
things
together.
B
I
have
this
tickle
in
the
back
of
my
brain
that
if
we
set
this
up
properly,
maybe
parts
of
kept.yaml
can
go
away
and
something
like
this
could
become
a
source
of
Truth
but
I'm,
not
sure
yet
so
I
apologize
for
adding
one
more
source
of
truth.
I
am
reminded
of
the
xkcd
and
making
yet
another
standard,
but
I
wanted
to
see
if
anybody
else
finds
this
useful,
if
not
I
will
continue
to
use
it.
Just
for
myself.
F
F
F
B
B
B
When
you
go
to
the
right
hand,
side
under
projects,
you
can
actually
expand
it
and
you
can
sorry
you
can
expand
it
and
you
can
see
all
the
metadata
fields
that
I
added,
so
we
can
actually
manage
them
from
here.
Right.
I
can
now
add
extra
information
per
issue
and
manage
them
right
here
in
the
screen.
B
B
So
anyway,
this
is
what
I've
been
spending
a
little
time
playing
with
through
the
last
kept
cycle.
I
found
it
useful
I
have
my
own
version
of
this,
of
like
caps
that
I'm
personally
Tracking,
not
all
Sig
network
but
but
more
I
found
it
super
useful
and
I
hope
that
it's
useful
for
the
Sig
and
I'm
open
to
all
sorts
of
feedback
on
how
to
make
it
more
useful.
B
F
F
E
F
B
So
take
a
look
if
people
have
other
ideas
like
I'm
happy
to
see
them.
You
know
this
isn't.
Project
is
a
relatively
new
system,
so
you
can
always
go
to
your
own
GitHub
account
and
just
create
some
projects
and
Tinker
around
and
see
what
other
cool
things
you
can
make
it
do,
and
then
we
can
talk
about
it.
A
A
A
B
Okay,
we
have
a
small
attendance
today,
anyway
cool
well.
The
call
for
proposals
is
closed
for
kubecon
I.
Hope
lots
of
people
got
really
great
proposals
in
and
we'll
have
some
pity
for
the
poor
program
committee.
Who
now
has
to
read
these
thousands
of
proposals
and
in
a
month
or
two
we'll
figure
out
who
all
is
going
to
be
there
doing
what
talks
I
did
just
get
a
flood
of
cncf
emails
in
my
mailbox
about
maintainer
track
and
other
stuff.
So
we'll
have
to
talk
about
that
at
our
next
session.