►
From YouTube: Kubernetes SIG Network Bi-Weekly Meeting for 20221013
Description
Kubernetes SIG Network Bi-Weekly Meeting for 20221013
A
B
Not
even
bother
I'll
just
respond
to
Hanz
issue,
that's
the
only
one
for
triage
and
we
can
just
proceed
with
the
agenda.
All.
C
Cool,
maybe
I
can
quickly
summarize
what
the
issues
were
so
I'd
like
to
basically
make
a
case
for
making
the
endpoint
slice
reconciler
available
as
a
library
so
that
it
can
be
consumed
by
other
custom
and
precise
controllers
and
basically
I
think
it's
fairly
tricky
to
get
right
and
there's
value
and
sort
of
sharing
a
robust
implementation
rather
than
forking
or
re-implementing,
which
is
I.
Think
more
common
now
also
I.
Think
from
like
an
endpoints,
an
endpoint
slice
migration.
C
It
sort
of
makes
sense,
because
It's
relatively
easy
to
write
an
influence
controller
and
just
from
initially
trying
to
find
custom
and
Quinn's
controllers,
able
to
find
a
bunch
of
controllers
that
still
haven't
migrated
to
endpoint
slices
and
I.
Think
having
a
library
that
sort
of
drop
does
all
the
hard
stuff
would
make
that
path
easier.
C
I
was
just
gonna,
say:
I'm,
not
too
familiar
with
the
mechanisms
for
doing
this,
but
my
understanding
is
there.
There
are
like
a
staging
repository
would
make
sense,
but
obviously
maybe
there's
a
better
option.
E
Yeah
I've
been
talking
with
Aquila
a
bit
about
this
as
well
and
I
know
it's
not
not
normal
to
you
know,
expose
any
controller
logic
as
a
library
like
this,
but
I'd
also
say
this
controller
is
a
bit
of
a
special
case
in
that
it's
something
that,
unlike
so
many
controllers
in
controller
manager.
This
is
something
that
we're
seeing
implemented
again
and
again
with
custom
implementations.
And
we
see
you
know
from
the
beginning.
E
E
So
we
we
are
already
seeing
examples
in
the
community
of
using
a
custom,
endpoint
slice,
controller
or
plenty
of
custom,
endpoints
controllers
that
have
not
moved
to
custom,
endpoint
slice
controller
and
the
endpoint
slice
logic
is
more
complicated
than
endpoints,
so,
although
I
would
usually
be
against
pulling
controller
code
out
and
making
it
a
library
that
people
can
use,
I
am
tempted
to
say
that
it
makes
sense
in
this
case
not
entirely
sure
where
this
belongs
or
how
we
do
it.
E
But
I
I
see
the
use
case
and
I
feel
like
it
will
make
the
the
rest
of
the
ecosystem
healthier
than
custom.
Implementations
that
are
fully
custom
would
be.
F
B
So
I
I
agree
with
all
that
and
I
see
more
and
more
things
that
are
being
designed
that
have
to
be
have
to
emulate
this
pattern
right.
This
is
one
to
many
pattern,
so
I
want.
Excuse
me
I,
wonder
if
what
we
really
should
be
doing
is
generalizing
this
a
little
bit
into
something
that
can
be
used
as
a
framework
for
building
these
controllers,
as
opposed
to
being
specific
to
endpoints
and
I'm,
really
reluctant
to
suggest
it,
but
we
have
kind
of
opened
the
door
to
generics.
B
H
I
I
In
the
chat,
yeah
I
think,
like
the
thing
that
part
of
the
design
of
endpoint
slice
requires
a
certain
kind
of
implementation
to
make
it
scale
and
that
that
was
always
the
sort
of
hard
part.
When
we've
looked
at
any
of
the
custom
implementations
out,
there
was
like
how
do
you
tell
people
to
do
the
right
thing?
So
that's
my
two
sets
on
why
this
makes
for
a
very
compelling
Library
generic
or
not.
We
should
see,
but
at
least
the
implementation.
F
B
I
mean
I
see
the
same
pattern
coming
up
where
people
want
to
do
something,
but
they
end
up
having
sort
of
an
unbounded
list
of
derivative
things,
and
we
have
to
say
sorry,
you
can't
put
an
unbounded
list
in
the
API,
it
doesn't
work.
You
follow
the
endpoint
slice
pattern
where
you
have
this
one-to-many
child
resource
thing.
B
I'm
saying
what,
if
the
request
was
expanded
to
say
we
handle
that
in
established
way,
so
that
we
could
build
the
endpoint
slice
controller
around
that
and
other
people
could
build
their
own
using
the
same
base.
Layer.
F
D
F
Employee
control,
the
employee
project
has
a
nice
goal,
controller
going
to
control
playing
project
for
people
to
do
in
this
kind
of
thing,
so
the
import
is
controller,
and
my
suggestion
is
this
is
just
do
this.
Endpoint
is
like
controller
as
a
separate
project
and
because,
if
you,
you
enter
the
code
as
soon
as
we
add
filter
grades,
or
we
add
something
we
are
going
to
break
everyone
yeah
true.
H
If
I,
if
I
may
I,
think
there
are
two
components
to
this
question,
the
first
component,
there
is
somehow
consensus
that
this
needs
to
be
offered
to
other
people,
because
other
people
are
either
trying
to
migrate,
endpoints
to
endpoint
slices
to
my
vehicle
controllers
or
writing
new
net
new
controllers
that
somehow
need
the
same
same
functionality.
H
What
is
confusing
to
me
and
I
think
it's
confusing
us
is
the
totality
of
which
of
which
we
are
using
the
word
controller
we
are
taking,
the
entire
thing
needs
to
be
rendered
out,
and
then
people
can
reuse
it
which
let's
face
it.
If
people
need
to
have
the
same
exact
functionality,
then
just
use
the
thing
as
if
so
the
question
I'm
asking
everybody
is:
are
we
looking
for
set
of
helper
functions?
H
Let's
say:
filter
out
dead,
endpoints
filter
out
the
meeting,
endpoints,
all
the
all
the
little
pieces
that
rope
has
in
this
code,
all
right
that
are
used
and
these
people
can
the
people
who
are
building
a
loop
can
reuse
these
helpers
and
that
way
they
can
compose
the
logic
anywhere
they
want.
Or
are
we
looking
for
a
controller,
the
loop
itself
right
with
hooks
that
people
can
register
callbacks
in
and
say,
okay
I'm
about
to
add
this
endpoint?
H
And
then
people
can
intercept
the
score
and
filter
out
whatever
the
the
come
back
and
say:
oh,
don't
edit
or
add
it,
and
that
way
the
base
implementation
is
the
same,
and
the
controller
manager
register
hooks
into
the
controller,
and
everybody
else
want
to
use
the
loop
all
right.
The
plot
chain
develop
ordering
the
compact,
like
everything,
we're
doing
it's
just
the
hooks
that
they
need
to
implement.
H
H
D
E
E
We
need
to
think
about
where
those
future
Gates
may
fit
in
and
allow
you
know:
Upstream
endpoint
slice
controller
to
continue
to
do
that,
even
if
we
expose
some
of
the
common
functions
like
reconciler
to
do
that,
so
the
use
cases
I'm
most
familiar
with
are
things
like
implementing
multi-cluster,
Services
right,
so
you're
trying
to
pull
endpoints
from
a
different
Source
than
endpoint
slice.
E
Controller
itself
is
familiar
with,
so
the
the
overall
logic
is
similar,
but
your
source
of
data
is
completely
different,
and
so
basically,
although
the
actual
controller
code
may
vary,
it's
all
calling
out
to
the
same
kind
of
reconciler
now
endpoint
slice
controller
is
almost
entirely
built
with
logic
inside
of
reconciler
idea
right
and
so
all
your
informers.
They
call
out
to
you
know
when,
when
a
new
service
is
added,
you
call
out
to
a
method
on
Rex
installer
reconcile.
E
You
know
ad
server
I
forget
the
specifics,
but
that's
the
idea
so
so
that
is
a
concept
that
is
relatively
easy
to
pull
out
into
a
library.
But
if
we
do
that,
we
need
to
be
very,
very
careful
to
ensure
that
we
still
have
room
to
add
new
features
and
not
completely
break
this
reconciler
pattern,
so
not
entirely
sure
how
that
what
that
looks
like,
but
I
agree
that
we
need
to
have
that
room
with
whatever
we
do.
J
J
That
work,
so
I
mean
the
original
ask.
Right
is
basically
looking
at
exporting
some
common
code
into
a
library
that
everyone
wants
to
use
like
we're
going
to
run
into
the
same
thing
with
kpng.
So
now
we
have
two
libraries-
and
we
can
talk
about
this
more
on
the
next
topic.
But
like
the
two
options,
there
are
right,
move
those
I
don't
really
care
what
the
libraries
do
right,
but
we
need
to
figure
out
where
they
live
like.
J
I
B
He's
refusing
okay
I
was
just
gonna,
say
yes,
I
agree
having
core
controller
logic
out
of
the
sudo
mono
repo
feels
weird
to
me,
having
dealing
with
cross
repo
stuff
right
now
in
a
separate
Branch,
it's
a
giant
pain
in
the
butt
and
having
things
in
that
the
pseudo
mono
repo,
the
staging
spaces,
is
nice.
B
The
I
think
that
everybody's
sort
of
nodding.
Yes,
this
is
a
real
problem,
but
the
actual
solution
isn't
as
obvious.
Is
it
literally
the
controller?
Is
it
helper
functions?
Is
it
something
else.
F
B
In
theory,
we
could
make
a
new
repo.
Can
you
hear
me
now?
Can
you
hear
me
Antonio?
Is
there
anybody
else?
Okay,
there
you
go
in
in
theory,
we
could
make
a
new
repo.
We
could
move
this
controller
to
that
new
repo
and
then
vendor
it
back
in
and
we
could
build
and
run
like
that.
That
would
be
technically
possible,
although
I
don't
think
it
would
be
sort
of
managerially
acceptable.
F
Yeah,
but
that's
the
problem
and
that's
the
thing
that
they
want
to
to
say
is
people
want
what
the
people
want
to
win.
I
mean
if
it's
only
the
logic
for
reconcile.
We
can
just
remove
only
the
parts
that
we
want
to
a
custom
Ripple
and
let
the
people
render
from
there
and
evolve
that
controlling
independently
of
the
car.
B
It
yeah
I
mean
I,
sorry,
I'm.
Reading
the
comments,
sorry
I,
I,
yeah
I'm,
not
sure
what
the
right
answer
is.
It
feels
to
me
like
there's
a
layer
which
is
the
reconciling
a
bunch
of
things
into
a
one-to-many
pattern
and
then
there's
the
controller
itself,
the
endpoint
slice
controller
and
the
endpoint
slice
mirroring
controller
which
could
use
that
lower
level
and
that
other
people
could
use
that
lower
level.
B
A
A
D
A
Sorry
I
was
just
gonna
say
it
sounds
like
like
none
of
the
options
are
either
have
precedent
or
are
particularly
palatable
like
it
could
all
be
separated
out
nicely
into
packages
in
the
actual
repo,
and
then
people
could
vendor
it
in,
and
we
could
kind
of
have
a
understanding
that
we
will
get
around
to
fixing
things
that
break
it,
and
then
people
could
vendor
that
in.
But
we
don't
typically
support
vendoring
pieces
of
cube
into
other
projects
in
this
way
right,
but
then,
depending
on
an
external
Library,
also
seems
problematic.
H
I
think
we're
mixing
the
what
was
the
how
right
first
is
the
what
like
First
thing:
how
we
want
to
do
this
and
then
the
how
even
if
we
have
to
step
on
some
somebody's
told
us-
and
we
probably
will
right
like
it-
looks
to
me
like
no
President-
we
didn't
do
this
before
so
that
does
not
mean
adoptions
are
bad
I'm,
just
saying
it's
probably
something
we
haven't
done
before.
We
can
figure
this
out
later
on,
but
at
least
now
we
don't
even
know
what
does
externalizing.
This
look
like
how.
H
A
list
of
features
or
functions
in
this
controller
that
would
people
need
to
change
since
they
chose
to
implement
something
similar
right,
like
Rob,
said
something
interesting
about
the
data
source
is
commonly
commonly
subject.
So
does
this
mean
if
we
just
offer
the
controller
with
an
external
data
source?
Is
this
possible
I
can
intervene
somewhere
right,
so
I
think
we
should
focus
first
on.
How
does
like
what
does
this
look
like
and
then
the
the
rendering
part
which
is
messy
I'm,
not
saying
it's
easy,
I'm,
not
saying
it's
not
going
to
be
a
straightforward.
H
B
Yes,
I'm
gonna
I
have
to
drop
in
in,
like
one
minute
agree.
Agree,
agree,
agree,
vendoring,
something
creating
a
new
staging
repo
and
putting
code
there
and
then
using
it
and
Publishing
it
to
external
repos
is
actually
not
that
difficult.
B
Nor
is
it
sort
of
like
a
frowned
on
thing
like
that's
what
the
staging
tree
is
there
for
so
I
have
no
problems
with
that.
I
think
it's
safe
to
say.
We
agree
with
the
problem
statement
and
I
would
be
open
to
looking
at
all
right.
I
would
be
open
on
Rob's
behalf
to
to
looking
at
PRS,
which
try
to
factor
the
code
in
a
way
that
produces
a
useful
Library
while
still
leaving
the
controller
in
tree
intact
and
satisfying
the
needs
of
things
like
feature
Gates.
E
Cool
yeah
thanks
thanks,
everyone
I
think
Akil
is
probably
going
to
be
I.
Guess
you'll,
probably
start
on
some
kind
of
thing
and
we
probably
need
some
kind
of
design
Docker
Plan.
Before
we
get
too
far
into
this
Cal,
it
looks
like
you're
volunteering
to
help
out
and
anyone
else
who
wants
to
be
involved.
Just
I
guess
we
can
talk
on
Slack.
H
So
I'll
start
the
doc
all
right.
I'll
go
read
the
dock
that
the
account
it
has
been
a
while
I'll
go,
read
the
doc
and
just
imagine
a
version
of
a
future
all
right.
My
focus
is
not
going
to
be
on
the
mechanism
of
rendering,
but
rather
the
mechanism
of
offering
external
features
and
then
the
rendering
piece
we
can
talk
about
later.
A
A
Great
thanks,
so
the
only
last
question
I
had
is
that
Rob
I
only
heard
your
use
case,
I'm
sure
Akil
has
a
use
case,
and
maybe
there
are
others
and
maybe
figuring
out
what
everybody
or
a
number
of
people
who
use
this
code
actually
want
out
of
it
and
go
towards
answering
Kyle's
question
about
utility
functions
or
the
actual
entire
controller.
Loop
Etc.
D
C
Maybe
I
can
speak
to
the
use
case
that
I
have
in
mind.
It's
quite
similar,
it's
related
to
multi-networking,
but
it's
similar
in
that
the
thing
that's
different
is
the
data
source
we're
presenting
a
different
view
of
the
world
to
the
controller.
The
core
reconciler
logic
is
still
the
same.
C
How
the
multiple
endpoint
slices
are
updated.
That's
all
consistent
and
I
think
I,
it's
certainly
possible,
but
I
find
it
hard
to
imagine
a
case
where
you
would
want
to
change
that.
Maybe
maybe
there
is
a
use
case
like
that.
E
Foreign
yeah
I'd
agree,
I
I
feel
like
the
again.
The
only
use
cases
I've
seen
and
I
I
think
I
kill
you.
You
mentioned
a
few
others
that
in
the
issue
that
you've
seen
of
custom,
endpoints
and
endpoint
slice
controllers,
but
largely
the
the
complexity
of
endpoint
slice,
is
in
the
reconciler
and
I.
Don't
see
people
changing
that
very
often
it's
more
just
the
input,
and
you
know
I.
E
If
yeah
it
seems
to
almost
always
be
different
inputs,
but
if
there
are
other
use
cases
that
I'm
missing
I
would
love
to
to
hear
them
now,
as
opposed
to
after
we
go
through
all
this,
like
with
the
theory
that
we
only
want
to
change
inputs,
and
then
someone
wants
to
change
something
else.
Yeah.
H
The
six
million
of
dollar
assumptions
that
we
just
made
is
that
he
concealer
logic,
as
is
Will,
withstand
the
future
requirements
from
external
parties.
That's
that's.
The
thing
that
really
gets
gets
gets
like
yeah.
Well
sure
the
click
on
cellular
logic
will
probably
be
used
as
as
the
keyword
here
is
as
of
now
all
right.
So
that's
something
also
to
think
about,
but
you're
right
most
people
are
interested
as
of
now
into
different
data
source,
or
somebody
eloquently
said
different
view
of
the
word
so
I
like
that.
H
J
Yeah,
can
you
give
me
permission
to
share
yeah?
Sorry,
no
worries
go
for
it.
Let's
see
if
it
works,
I'm
had
some
problems.
It's
gonna
work
for
now
sorry,
you're
gonna
get
infinite.
Okay,
I
can't
see
anyone,
so
if
you're
making
faces
of
me,
I
won't
be
able
to
see
it.
J
But
can
you
all
see
my
screen
looks
good
yeah
cool
awesome,
so
we
haven't
talked
about
kpng
in
a
while
I
think
most
people
on
the
call
know
about
kpng,
but
we're
just
gonna,
give
kind
of
like
a
quick,
quick
rewind
before
asking
for
the
community's
opinion
on
like
where
we
go
next.
So
this
isn't
just
me.
This
is
like
everyone
involved.
There's
a
bunch
of
people
in
the
call
today
who
is
involved
so
I'm
just
going
to
go
ahead
and
hop
into
it.
J
The
two
main
things
I
want
to
emphasize
is
like
kpng,
provides
an
easy
interface
for
new
users
to
come
and
write
service
box
years
in
whatever
technological
piece
they
want.
So
now,
users
can
reuse
the
same
bits:
let's
watch
the
kubernetes
API
and
kind
of
write
their
own
Logic.
On
top
of
it,
that's
awesome.
It
gives
a
really
good
developer
experience
for
people
wanting
to
write
new
back
ends
and
then
the
other
main
value
add
that
kpng
brings
is
like
it
gives
us
the
ability
to
have
an
extremely
flexible
deployment
model.
J
So
today
the
three
deployment
models
we
are
kind
of
seeing
is
running
it
all
in
a
single
process
like
cute
practice,
today
kind
of
like
a
Pernod
Damian,
there's,
not
a
ton
of
rationale.
To
do
that.
We
just
did
that,
because
that
was
what
was
working
before
and
people
are
used
to
it,
but
future
looks
future.
Looking
deployment
models
include
like
split
deployments,
single
tier,
where
you
have
a
single
intermediary
between
the
kubernetes,
API
and
node
local
state
and
even
further
future.
J
Are
there
any
questions?
This
is
like
an
open
discussion.
I,
don't
want
it
to
just
be
a
presentation.
J
Okay,
I'm
sure
there
are,
but
there's
more
so
kpng
today,
since
the
last
time
we've
talked
to
we've
added
some
cool
stuff.
We
have
some
testing
infrastructure
and
we
also
have
some
more
backends.
So
this
is
a
list
of
like
the
back
ends
that
are
around
today.
They
are
in
varying
state
of
completeness,
I
would
say:
Jay
can
hop
in
here,
but
iptables
and
nft
are
kind
of
the
two
most
complete
back
ends.
D
J
They're
all
running
e2e
tests
and
passing
I
believe
all
of
them,
but
we're
running
in
CI,
so
we
can
go.
Look
we've
also
added
a
bunch
more
contributors
like
now.
We
have
28
total
contributors
from
a
ton
of
different
companies,
and
that's
awesome
like
the
community
has
been
great.
It's
super
fast
paced,
everyone
gets
to
add
code
and
it's
been
a
lot
of
fun.
I
can
think
I
can
speak
for
the
community
there,
like
everyone's
friendly
and
there's,
not
really
any
gatekeeping.
It's
just
a
good
time.
J
So
again,
like
last
time,
we
presented
I
think
to
Signet.
We
didn't
really
have
CI
up
and
running
now
we
do
it's
pretty
much
there.
We
have
a
few
more
tests
to
clean
up
for
some
back
ends.
It's
really
easy
to
just
go
test
this
out,
like
one
liner,
you
can
go,
give
it
a
try,
deploy
dual
stack
single
stack.
Whatever
you
want
with
various
back
ends.
J
We
have
two
new
back
ends
that
we
talked
about
before,
which
is
Windows
kernel
and
ubpf,
go
check
them
out,
and
the
cap
has
been
under
constant
iteration,
so
the
cap
is
I'd
say
ready
for
another
look
from
everyone
here.
So
really
what
we
want
to
do
here
today
and
then
this
is
some
more
forward-looking
stuff
feel
free
to
look
into
what
we're
looking
at
new
test
for
services
and
adding
metrics
so
more
exciting
stuff.
J
That's
going
on
so
that's
like
where
we've
gotten
to
today
and
what
we
want
to
do
is
make
sure
we
figure
out
how
to
align
with
Sig
Network
in
the
future
right
we've
written
a
ton
of
awesome
code
and
we
want
to
figure
out
how
like
what
y'all
want
like
what
the
community
wants
to
do
with
it,
and
so
we've
proposed
some
options
here.
J
The
first
one
I
think
is
like
we
said:
we've
called
it
yolo,
it's
probably
not
going
to
happen,
and
that
is,
let's
put
all
the
codes
in
tree
and
it's
a
ton
of
code
and
that's
not
probably
not
going
to
happen,
but
we
threw
it
on
here
anyway
and
then
the
other
kind
of
way
we
could
see
a
lining
in
the
future
is
splitting
up
all
the
work.
We've
done
into
little
bits
and
pushing
it
back
in
the
tree.
Maybe
parts
of
it
and
all
of
it
kind
of
whatever
the
community
wants.
J
So
yeah
I
think
that's
pretty
much.
The
last
slide.
I'll
leave
I'll
go
back
to
that
slide
because
there's
a
ton
of
words,
but
we
have
some
short-term
matching
items
number
one
being
like
go
read
the
cap.
It
has
way
more
details,
go
look
at
the
code
and
try
it
out,
but
yeah.
So
now,
I
just
really
want
to
open
a
discussion
on
like
questions
and
how
we
see
kpng
aligning
with
Sig
Network
in
the
future.
F
I,
have
one
question
is
why
why
don't
you
start
without
the
feedback
talking
with
projects
like
do
Batman
or
but
still
the
one
that
you
sensible?
Well,
this
this
is
started
cops
and
all
these
projects
to
start
people
using
the
the
project
as
a
circle
can
because,
as
you
say,
the
the
other
thing
is
your
law.
I
thought
you
kind
of
three
something.
If
we
don't
know
how
it
is
running
in
at
scale
or
with
stress,
Q
proxy
is
very
battle
test.
G
G
That's
done,
but
we
realize
that
still
there
may
be
some
concerns
to
like.
Maybe
it's
better
to
start
with
it
just
being
like
adding
cops
to
that.
To
that
other
thing,
it's
like
having
a
dangling
option
and
cops
have
a
dangling
option
in
cluster
API.
F
G
F
Well,
you
have
to
do
it
anyway.
Okay,
I
mean
how
do
you
you
have
something
now
that
runs
I,
don't
know
what
city
scalability
is
running,
but
it
runs
I
think
that
they
have
one
that
creates
a
lot
of
importance
and
in
one
thousand
nodes
you
need
to
prove
that
you
are
able
to
run
that
test.
Enterprise
yeah.
G
F
F
Before
you
do
anything
right
now,
because
the
problem
that
you
have
is,
if
is
you,
do
not
start
to
install
it?
People
start
doing
story
and
it
worked
well
in
20,
100
points
whatever,
and
then
people
start
to
to
build
on
that.
And
then
people
want
to
receive
1000
not,
and
you
detect
that
you
are
algorithm
for
processions.
G
G
J
J
D
H
H
There
is
just
a
ton
of
things
written
today
that
babies
said
copernic.
Babies
at
proxy
baby
said
what
proxy
does
checks
and
points
checks.
There
is
a
huge
investment
done
by
the
community
around
proxy
and
that
that
investment
is
not
code.
It's
just
an
operational
tool
chains,
all
right
people,
just
let's
face
it.
Q
proxy
is
not
exactly
the
greatest
ever,
but
people
learned
how
to
level
it
right
now.
If
we
come
and
say
we
have
this.
The
second
next
break
build
like
the
greatest
things
and
slice
for
a
slice,
bread.
H
H
Don't
think
this
is
a
function
of
kubernetes
per
se,
but
it's
a
function
of
going
to
cube,
EDM
or
cops
or
even
kind
to
go
and
say:
let's
provide
this
an
option
as
an
option
and
keep
it
as
a
second
second
replacement
for
for
Q
proxy.
For
as
long
as
it
takes
all
right
and
then
we
can
start
then
from
there
we
can
start
saying
we're
going
to
build
it
as
part
of
the
release,
cuts
and
all
of
that
stuff
and
provide
it.
H
J
And
that's
why
I
think
with
this
second
option,
it's
like
why
can't
we
move
some
of
the
shared
functionality
that
people
really
want,
which
is
like
you
know
at
the
very
beginning
of
this
it
was
like.
Do
we
provide
a
library
in
core
Cube
to
make
this
simple,
or
do
we
provide
kpng
and
at
the
time
we
went
and
Macau
made
kpng
and
it's
totally
separate
but
like
there
is
a
world
where
we
start
with.
J
Just
like
I
said
here:
diff
store
and
server
and
diff
store
is
basically
Q
proxy
service
and
endpoints
tracker
and
then
so
you
move
like
little
bits
that
are
shared
between
KP
and
G
and
cooperoxy
to
start
and
then
in
the
future
you
can
decide
if
you
need
flexible
deployments,
go
use
kpng.
If
you
don't
care
at
all
about
the
deployment,
because
you're
not
going
to
hit
those
scale.
Problems
use
the
existing
thing
we
have,
but
there
is
still
some
shared
bits
between
the
two
right:
it's
not
as
dramatic
of
a
transition.
H
So
can
you
go
back
to
the
the
slide
that
has
the
diagram
on
it
sure
absolutely
for
Larson,
Bowie
I
just
hijacked
that
discussion
for
a
bit,
so
the
kpng
in
the
middle.
Those
are
new
components.
Those
are
new
control,
train
components,
right,
yeah,
sort
of
store
on
the
kpng.
So
we
cannot
even
say
oh
like
here.
Is
those
components
are
running
independently
from
the
existing
controlling
components
right,
they're,
not
part
of,
let's
say
a
scheduler
or
control
brand
manager,
API
server?
They
are
just
Standalone
executables.
H
J
G
Yeah
we
just
rigged
it
in
there
so
that
it
was
stable.
So
because
one
of
the
concerns
right
was
that
well,
if
we
have
some
new
IP
tables
implementation,
who's
gonna
ever
use
it
so
for
for
IP
tables.
We
literally
just
took
the
exact
implementation.
It
still
uses
the
caches
and
everything
just
because
you
know
you
know
yeah.
My.
H
Point
is
if
let's
say
we
had
a
feature
like
in
kubernetes
that
either
keep
proxy
of
KPMG,
just
assume
that
this
is
the
future
we're
looking
at
from
a
core
perspective.
It's
it's
a
bit
of
work,
but
it's
a
lot
of
work
from
the
operational
perspective,
because
people
used
to
think
of
kubernetes
as
control
plane
as
casual
controller
manager,
API
server
and
HD.
Now
we're
telling
them.
Oh
no.
H
You
need
all
of
the
stuff
that
you're
used
to,
in
addition
to
two
more
services,
which
is,
might
not
be
a
lot
of
work,
but
don't
just
operationally
people
don't
like
to
be
surprised.
That's
for
sure
right,
that's
something
that
I
know
and
feature
flags
for
these
things.
It's
really
hard
because
you're
running
either
this
or
that.
So
it's
it's
it's
it's.
It's
probably
not
a
good
path
for
the
future.
I
I
don't
have
a
clean
solution.
I.
G
J
That
yeah
we're
saying
we
have
a
ton
of
code
and
we
know
that
it
makes
no
sense
for
all
that
code
to
go
in
tree,
but
that
maybe
it
makes
sense
to
incrementally
incrementally
pull
new
bits.
We've
done
in
kpng
and
put
some
of
an
entry
and
that
some
of
it
can
be
shared
at
first
between
the
existing
qproxy
and
kpng.
A
G
G
We
would
need
some
kind
of
a
you
know
the
word
before
like
we
need
some
kind
of
an
agreement
in
terms
of
what
the
direction
was
before
we
Jam
that
code
into
kubadium,
which
is
why
it
goes
back
to
the
whole
like
do
we
want
to
replace
the
coup
proxy
or
do
we
maybe
want
this
to
live
as
a
separate
thing
and
either
way
we
could
do
those
options,
but
we
need
to
be
able
to
tell
them.
What's
the
of
those
two
bullets
which
direction
do
we
want
to
go
in?
J
J
J
H
D
K
K
No
problem
I
would
say
that
I
have
from
the
start
reviewed
Kipping.
Yes,
a
way
of
extending
the
network
functionality
in
kubernetes,
because
I
believe
Q
proxy
is
never
going
to
change,
so
no
no
new
features
will
will
be
accepted.
It's
totally
super
stable
and
everybody
who
needs
just
the
things
that
are
present
do
not
want
to
change,
but
I
believe
that
campaign
can
offer
things
that
people
want.
So
it
will
like
promote
itself
over
time.
So,
for
instance,
this
feature
of
having
an
all-ip.
K
Target,
so
everything
to
a
certain
address
goes
to
one
pod.
That
is
something
I
believe
the
gaming
industry
and
such
wants,
and
that
was
basically
blocked
in
in
Cube
proxy,
but
it
can
super
easily
be
done
in
keeping
and
those
people
would
start
to
have
coping
as
a
specialized
proxier.
But
then
it
becomes
more
and
more
of
the
specialized
brokes
here
and
then
they
will
say
why
don't
we
take
keeping
as
a
the
main
proxy
and
have
like
10
back
ends
for
it,
so
I
believe
in
time.
It
will
promote
itself.
I
So
I
think
there's
two
things.
One
of
them
is
that
this
has
happened
before,
but
I
think
the
situation
is
different.
So
what
happens?
Is
there's
kubernet
Cube,
DNS
and
cordiness
and
coordinates
basically
replace
Cube
DNS
the
where
it's
different
is
I,
think
Q
proxy
and
basically,
whatever
the
places
key
product
functionality
has
a
tighter
coupling
potentially
to
kubernetes
than
Cube
DNS
does.
Although
we
can
see
like
how
good
is
the
conformance
test,
how
good
are
the
sort
of
Behavioral
Gates
that
we
have
so
that
we
can
figure
out
if
it
is
a
drop-in
replacement?
I
The
other
thing
is,
as
with
most
things,
a
lot
of
the
difficulties
will
be
around
defining
what
the
release
cycle
will
be,
how
to
package
it,
how
to
test
that
the
basically
core
is
not
broken,
because,
right
now,
it's
very
clear
since
it's
part
of
the
monolithic
repo
right,
like
you
can't
get
out
of
sync,
you
can't
do
a
release.
That's
out
of
sync
you!
I
You
can't
introduce
a
feature
and
then
have
like
kind
of
unexpected
Behavior.
So,
in
my
mind
like
really
which
path
we
go
really
needs
to
First.
Consider
like
what
are
the
gates
that
we
have
to
demonstrate
to
be
confident
that
and
just
write
them
down
like.
If
we
pass
this
gate,
then
we
know
that
a
Visa
can
be
a
replacement
in
qadm.
J
F
I
Yeah,
so
there's
two
things:
one
is
that
the
to
keep
DNS?
Yes,
so
California
is
very
interesting
and
that
Court
DNS
is
a
task
that
runs
in
your
cluster
and
Cube
DNS.
Is
this
also?
So
it's
like
it's
a
much
better
analog.
Of
course,
this
one
seems
to
have
more
moving
pieces.
One
thing
I'm
wondering
is
that
are
those
moving
pieces
necessarily
required,
or
it's
more
like
a
desire
to
move
in
that
direction,
architecturally
for
the
proxy
base
like?
J
H
So
the
the
API
server
Machinery
API
Machinery
folks
developed
a
new
component,
the
proxy.
It
has
been
there
for
a
few
releases
now
and
it's
quite
stable
and
is
used
to
buy
a
lot
of
service
providers
and
I
think
they
figured
out
the
recipe
of
introducing
a
new.
So
they
have
half
of
that
half
of
they
sold
half
of
the
problem.
We
have
adding
a
new
control
plane
component.
So
why
don't
you
just
go
and
ask
them
how
that
happened
and
like?
H
Yeah,
but
people
still
get
the
release
for
it
to
stay,
deployed
still
very
comfortable
using
it.
So
we
need
to
know
the
gates,
they
I
think
bow
it
right.
What
were
the
gates
that?
What
are
the
gates
that
we
need
to
go
through
beyond
the
obvious
one-scale
person,
and
so
on?
So
in
order
to
include
this
as
part
of
the
release.
D
F
I
I,
don't
understand
what
you
mean
it's.
This
is
not
part
of
the
release,
so
what
capping
G
has
now
is
the
same
that
the
connectivity
proxy
has
now
has
a
separate
repo
in
a
in
a
domain
in
a
kubernetes
domain,
but
those
bits
are
not
parts
of
the
release,
other
things
that
is
being
used
in
the
CI
because
they
just
use.
That
is
another
component,
it's
the
same
as
core.
So
all
the
examples
that
we
are
providing
here
is
the
same,
is
just
develop
in
a
in
a
external
component
and
make
the
people
use.
H
A
People
off
here,
because
we
still
got,
we
got
seven
minutes
left
and
still
have
some
more
agenda,
so
I
know
Bridget.
You
just
struck
out
your
item,
but
I
think
we
have
time
for
it.
So
if
you
want
to
do
a
quick
plug,
go
for
it.
F
Yeah,
this
is
the
fact
that
I
was
able
to
produce
so
the
the
problem
is
when
you
have
two
proxy
running
as
a
static
pod
or
as
a
standalone
pod,
it
can
race
in
different
conditions,
but
commonly
Q
proxy
fetches,
the
Pod,
cider
and
I.
Don't
remember
which
the
node
IP.
So
if
they
know
response-
and
it
happens
that
Q
proxy
is
faster
than
the
equivalent
is
going
to
fetch
the
all
node
component.
F
A
Okay,
thanks
and
last
item
on
the
agenda,
we
have
feedback
on
that
poll.
A
volts
you're.
L
Up
hi
I'm
Andy
hi
I
sent
this
PR,
but
I
marked
it
as
work
in
progress
It's.
Just
it's
an
additional
series
of
end-to-end
tests,
which
sort
of
tests,
combinations
of
topology
hints
internal
traffic
policy
and
external
traffic
policy,
I'm
I.
Guess
all
I'm
wondering
I
I
think
there's
I
worked
a
little
bit
with
Andrew
psychim
and
the
other
Jam
Dan
Winship
Dan
Winship,
sort
of
advised
that
this
might
be
a
useful
series
to
test.
L
But
what
I'm
wondering
is
like
I
I,
don't
know
how
the
this
is.
My
first
test
in
kubernetes,
so
I
just
don't
know
how
the
test
infrastructure
expects
end-to-end
tests
to
be
configured
or
which
tests
are
run
by
default,
if
maybe
I
needed
to
ramp
up
in
a
dock
or
something.
But
it's
these
tests
require
multi-zone
and
I
tested
the
move
kind,
but
I'm
just
kind
of
looking
for
information
on.
F
E
Yeah
we
do,
we
do
have
that
trick.
I,
don't
think
it
runs
regularly,
though
well
I
think
it
runs.
It
doesn't
run
as
a
pre-submit
and
we
may
need
to
start
moving
it
to
a
pre-submit
it
as
we're
getting
more
tests,
multi-zone
tests,
but
yeah
I
agree.
We
do
already
have
a
multi-zone
setup.
It
is
very,
very
specific.
It's
exactly
three
zones
with
one
note
in
each
Zone,
if
I'm
remembering
correctly,
so
it
may
not
work
for
everything,
but
it
does
help
with
these
kind
of
tests.
L
Yeah
in
in
the
test,
I
think
Rob
you're
on
this
PR
I
know
I
just
filed
it,
so
I
wasn't
expecting
any
like
feedback
yet,
but
I
just
kind
of
wanted
to
reach
out
about
the
approach,
because
some
of
the
strategy
I
used
was
in
order
to
verify
that
traffic
was
balanced
across
multiple
nodes
within
the
same
Zone,
when
topology
hints
were
used,
I
wanted
there
to
be
at
least
one
zone
with
two
nodes,
so
like
the
cluster
config.
That
I
was
requiring
was
at
least
two
nodes
in
one
of
the
multi-zones.
L
L
Is
it
somewhat
rips
off
the
topology
hints
test
that
you
wrote
Rob
in
there
and
just
sort
of
configures,
ITP
and
ETP
alongside
it,
and
checks
host
names
based
on
curls
from
a
series
of
curls
from
a
client
which
I
place
in
an
intentional
Zone?
L
So
I
guess
I'm.
Just
the
the
motivation
for
adding
this
test
is
to
try
to
assist
internal
traffic
policy
being
GA
and
it
looks
like
topology.
Hence,
cap
has
called
out
a
need
for
some
of
these
kind
of
tests,
so
it
just
seemed
like
a
useful
test
for
a
couple
of
cuts.
L
L
E
This
is
very,
very
useful.
Your
name
looked
familiar,
and
this
is
exactly
like
what
I
would
need
to
do
too.
So,
thank
you
for
getting
ahead
of
that
I
I
appreciate
that
I
am
looking
for
advice,
because
I've
been
struggling
with
this
too,
like
topology
hints
to
test
it
appropriately.
You'd
need
lots
of
different
cluster
configurations
like
you're,
alluding
to
you
need
a
cluster
that
has
multiple
nodes
in
one
zone
or
you
need
some
kind
of
random
cluster
setup,
and
we
just
don't
have
that
right
now
and
I.
F
You
can
play
with
stop
your
nose
or
just
you
know,
notes
I'm,
just
starting
off.
E
L
Thanks
I'll
catch
y'all
later
thanks
for
looking.
A
F
G
F
G
H
H
Don't
you
just
create
add
kind
as
one
of
the
things
that
we
only
need
a
single
note
from
the
clouds,
in
this
case
just
a
VM,
then
we
can
create
a
cluster
the
way
we
won't
test
it
and
then
throw
it
away,
create
another
cluster
tested,
and
that
becomes
some
tooling
for
people
who
want
to
test
this
I'm
guessing
other
people
would
want.
Zoning
like
I
know
that
BBC
depends
on
zoning
and
so
on.
So.
F
Anyway,
that's
in
integration,
I
I,
don't
like
the
idea
of
mocking
you
know
everything
that
you
test
in
network
with
a
single
node
always
pass,
then
do
the
pro
in
production
and
you
have
rear
bags,
I
mean
it
has
to
be
Italy
and,
and
the
package
has
to
flow
from
one
place
to
another.
Also
kindness
is
not
really
tweet,
but
I
mean
it
was
serving
as
well,
but
I
understand
what
you're
saying
but
and
I
think
that
it's
very
useful
for
doing
all
these
metrics
of
topologies,
but
I.
F
F
G
D
G
G
G
G
G
A
Thing
if
everybody
has
about
a
minute
or
two
before
you
leave
Sig
Network
lunch
at
kubecon
in
Detroit,
if
you're
going
to
be
there
Bridget
suggests
earlier
in
the
week,
or
we
can
do
it
during
the
conference.
Does
anybody
have
dates
that
don't
work
foreign.
D
F
A
A
A
Okay,
we'll
figure
it
out:
let's
coordinate
lunch
and
other
stuff
on
slack,
then
I
guess
all
right.
Thanks
everybody
all
right.