►
From YouTube: SIG-Network: Intro & Deep-Dive - Rob Scott & Bowei Du, Google; Surya Seetharaman & Andrew Stoycos
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
SIG-Network: Intro & Deep-Dive - Rob Scott & Bowei Du, Google; Surya Seetharaman & Andrew Stoycos, Red Hat
Speakers: Bowei Du, Rob Scott, Andrew Stoycos, Surya Seetharaman
Networking is hard! This talk will start with some background on Kubernetes networking. Attendees who are not already comfortable with the "hows and whys" of basic networking in Kubernetes can get a bit of a primer before we dive deep on a few of the more recent developments and efforts in the networking space.
A
B
A
C
And
I'm
Rob
and
I've
also
been
working
at
Google,
contributing
to
Sig
Network
for
a
few
years,
not
quite
as
long
and
I.
You
can
blame
or
thank
me
for
endpoint
slice,
Ingress
getting
to
GA
and
some
topology
stuff,
but
more
recently,
I've
been
doing
a
lot
of
Gateway
API
work.
So
I'm,
one
of
the
maintainers
of
the
Gateway
API
project.
D
Hey
everyone,
I'm
Surya
I
work
at
Red,
Hat
on
the
openshift
networking
team,
I'm
relatively
new
to
Sig,
Network
and
kubernet
is
not
the
Veterans
as
these
folks
here
are,
but
I
am
trying
to
get
involved
in
admin.
Network
policy
I
know
a
bit
of
keep
proxy,
so
yeah
hit
me
or
if
you
want
to
know
anything
about
these
things,
yeah.
C
Cool
well,
I
am
going
to
be
going
through
the
first
part
of
this
and
that's
going
to
be
an
overview
of
the
API.
So
we
have
not
much
time
I.
Think
we've
got
a
35
minute
slot
and
we're
going
to
try
and
do
both
an
intro
and
deep
dive,
which
means
we
really
can't
get
that
deep
in
any
one
area,
but
to
start
we're
going
to
go
through
an
overview
of
the
apis
that
networking,
Sig
Network
owns
and
to
start
with.
Let's
talk
about
service,
how
many
of
you
have
a
service
in
your
cluster?
C
Okay,
that
should
be
all
great
great
okay,
so
service
is
really
the
foundation.
I
think
the
central
thing
inside
Sig
network
resources
they
enable
you
know
basically
grouping
pods
together
behind
some
kind
of
network
concept,
and
you
can
see
here
that
that's
done
with
a
service
selector.
So
in
that
case,
pods
labeled,
app
equals
store
are
going
to
be
selected
by
this
service
services
are
usually
assigned
IP
addresses
that
they
can
be
reached
on,
and
request
of
those
addresses
will
be
routed
to
one
of
the
associated
pots.
C
Now
most
of
you
may
have
may
be
familiar
with
the
concept
of
a
service
type
and
there's
really
four
service
types
here,
and
three
of
them
are
very
closely
related.
You
know
if
you've
got
a
cluster
IP
service
type,
which
is
a
subset
of
a
node
Port
service
type,
which
is
a
subset
of
a
load,
balancer
service
type
and
then
way
over
here.
On
the
other
side,
you've
got
external
name,
which
is
just
it's
completely
out
of
thing.
It's
basically
a
c
name
that
does
some
DNS
resolution.
C
C
Now
we
also
have
a
DNS
specification
in
kubernetes
that
allows
you
to,
instead
of
knowing
the
IP
of
the
service,
just
know
the
server
the
name
of
that
service
and
make
a
curl
request
using
that
name
so
store
dot,
the
namespace
it's
in
and
then
service
cluster
local.
Now,
within
kubernetes
we
go
one
step
further
and
we
do
some
automatic
lookups
for
you.
C
So,
instead
of
typing
all
that
out,
if
you're
making
a
request
from
within
the
same
name
space,
you
can
just
curl
store
and
we'll
do
a
few
lookups
and
eventually
translate
that
to
store
prod
service
cluster
local
now
endpoints
and
endpoint
slices
are
really
how
this
works
behind
the
scenes.
So
remember
that
service
is
the
thing
that
selects
pods,
but
we
need
something
behind
the
scenes
to
actually
track
all
the
IPS
and
ports
associated
with
those
pods
and
make
them
make
sense.
C
So
the
endpoints
resources,
the
one
that's
existed
since
very
very
early
on
in
kubernetes,
and
it's
just
one
big
kubernetes
resource
that
tracks
all
the
IPS
and
ports
for
the
pods
in
your
service
with
endpoint
slices,
that's
a
newer
resource
and
that
basically
is
sharded
endpoints.
So
there
became
a
time
where
services
start
to
get
really
big.
We
saw
services
with,
say,
10,
000
endpoints
and
that
just
didn't
work
very
well
trying
to
shove
all
that
information
into
a
single
kubernetes
resource.
So
instead
to
try
and
address
that
kind
of
scale.
C
C
Okay,
that's
a
lot
great
okay.
So
the
Ingress
API
is
really
L7
load
balancing
configuration
inside
your
kubernetes
cluster.
It's
existed
for
nearly
five
years,
maybe
more
than
five
years,
that's
forever
in
kubernetes
Era,
at
least
from
my
perspective,
and
it
allows
you
to
forward
to
a
service
configure
path
matching
and
do
some
very,
very
basic
TLS
configuration.
C
It's
been
stable
for
a
long
time
and
it's
great,
but
it
has
a
very
small
feature
set
with
Gateway
API
we're
trying
to
do
the
Next
Generation
to
enable
you
know
much
more
expressive
and
portable
configuration
in
this
API
and
much
much
more
I.
Don't
there's
there's
been
several
talks
on
Gateway
API
here.
I
can't
go
into
everything
here,
but
really
Gateway
API
represents
the
next
generation
of
kubernetes
load,
balancing
and
routing
apis.
C
Now,
if
you
start
at
the
very
top
here,
you're
going
to
see
that
an
Ingress
class
name,
an
Ingress
meant
that
the
nginx
Ingress
should
Implement
that
Ingress
resource
in
HP
route,
it's
a
similar
concept,
but
we
have
a
parent
refs
field
and
that
points
up
to
a
Gateway
and
that
Gateway
says
that
I'm
going
to
attach
this
HP
route
to
the
Gateway
named
nginx
and
you
could
attach
to
any
number
of
gateways
and
they'd
all
implement
the
same
HTTP
route.
Both
of
these
do
exactly
the
same
thing.
C
They
do
a
prefix
match
on
slash
login
and
they
forward
traffic
to
the
auth
service
on
Port
8080..
There's
a
ton
of
work
going
in
get
going
on
in
Gateway
API.
It's
a
Sig
Network
sub
project,
I'm,
always
always
looking
for
more
people
to
get
involved.
We
have
so
many
things
going
on.
We
actually
have
two
meetings
every
week,
so
there
is
no
shortage
of
opportunities
to
get
involved
and
help
us
out
focus
areas
right
now.
C
This
API
is
right
now
most
stable
with
Ingress,
but
we're
taking
the
same
concept
and
applying
it
to
mesh.
We
have
lots
of
exciting
work
going
on
there.
There
was
a
talk
earlier
this
morning
showing
how
this
it's
called
gamma
the
sub
project
within
Gateway
API,
that's
focused
on
mesh
and
that's
really
moving
forward
quickly.
C
Just
this
week
week
we
introduced
a
new
tool
called
Ingress
to
Gateway
that
allows
you
to
take
Ingress
resources
in
your
cluster
and
convert
them
to
Gateway
API
resources,
lots
of
places
to
jump
in
and
help
out
if
you're
interested
and
as
always,
we
appreciate
contributors
from
all
backgrounds.
You
can
find
us
on
our
website.
That's
what
the
QR
code
goes
to
or
or
on
slack
or
on
GitHub.
B
D
So
next
up
we
have
Network
policies.
How
many
of
you
have
used
Network
policies
or
known
as
well?
Yeah,
that's
expected,
because
it's
been
around
for
a
really
long
time.
Five
years,
I
think
it's
a
stable
core
V1
policy
and
it's
a
powerful
API
that
actually
allows
app
owners
to
be
able
to
regulate
their
Network
traffic.
D
Communication
to
look
like
can
also
be
for
security
reasons,
can
also
be
for
different
infosing
different
levels
of
policies
on
your
apps,
so
it's
mainly
developed
for
app
owners
and,
as
you
can
see
at
the
example
over
here,
so
you
can
express
such
kinds
of
constructs
in
an
easy
way.
Using
the
network
policy
API
and
a
sample
yaml
for
or
a
network
policy
object
would
look
like
this
with
kind
Network
policy.
D
So
in
our
case
we
wanted
to
define
a
rule
that
says
my
backends
should
only
receive
traffic
from
my
front
ends
right,
so
you
can
express
that
saying.
Oh
I'm
going
to
apply
the
policy
on
my
back
end
and
if
the
Ingress
traffic
is
coming
from
my
front
end,
which
I've
expressed
using
match
labels
and
namespace
selectors
I
allow
it
looks
simple,
but
one
catch
here
is
that
they're
implicit,
the
API
is
quite
implicit
in
nature,
so
you
have
a
baseline
default
deny.
So
everything
works
until
you
create
that
policy
and
then
nothing
works
right.
D
You
have
that
default,
deny
rule
that
gets
created
and
the
allow
rule
that
you're
specifying
here
create
gets
created.
On
top
of
that,
so
it's
an
allow
list
mechanism
something
to
be
careful
about.
If
you're
using
network
policies
for
the
first
time
and
like
I
said
the
Ingress
and
egress
are
separate.
So
if
you
have
an
object
that
defines
only
Ingress
rules,
egress
is
unrestricted,
so
the
default
deny
only
applies
to
the
type
of
rules
that
you
have
in
your
object
over
here.
So
this
is
namespace
scope.
D
It's
defined
for
namespace
owners
app
owners,
so
you
might
be
wondering,
as
a
cluster
admin,
how
can
I
enforce
policies
on
a
more
cluster,
scoped
level
or
cluster-wide
level?
And
that's
where
admin
Network
policies
come
into
play?
It's
a
relatively
new
API,
that's
under
active
development,
and
this
is
defined
for
cluster
admins.
It's
on
a
cluster
scope,
so
you
might
have
use
cases
like
what
I've
shown
in
the
diagram.
Here
you
have
a
security,
sensitive
namespace.
D
You
want
to
be
able
to
express
that
all
other
name
spaces
in
the
cluster
should
not
be
able
to
talk
to
this
namespace
and
that
can
be
achieved
using
ANP.
Here's
how
a
typical
amp
object
would
look
like
kind
admin,
Network
policy
in
the
spec.
You
can
define
a
priority
field.
This
is
a
bit
different
from
Network
policy,
so
every
object
has
a
priority
and
all
the
rules
inside
the
object
will
get
the
same
priority.
You
can
have
more
than
one
role
in
the
object.
D
That's
similar
to
network
policies
and
a
subject
here
is
the
objects
on
which
you
want
to
apply
the
policy
on,
so
it
can
be
namespaces.
It
can
be
pods
and
they're
expressed
using
match
labels,
because
it's
the
same-
and
you
must
be
familiar
with
this
because
of
retro
policies-
what's
really
unique
here
when
compared
to
network
policies.
Is
that
they're
explicit
in
nature?
So
if
you
look
at
the
Ingress
rule,
we
are
defining
the
action
deny,
so
we
are
explicitly
saying
that
I
want
to
deny
or
drop
traffic.
D
That's
coming
from
namespaces
that
are
not
myself.
So
in
this
case
the
sensitive
NS
namespace
any
namespace,
that's
not
from
sensitive
namespace.
All
that
traffic
will
get
dropped
and
it's
not
any
implicit
thing.
That's
happening
behind
the
scene,
it's
more.
We
are
defining
it
in
the
actions.
So
it's
helpful
for
the
admins,
because
it's
like
a
traditional
firewall,
you
literally
get
what
you
are.
D
D
It's
a
work
in
progress
and
if
you
have
use
cases,
for
example,
you
want
all
the
namespaces
in
your
cluster
to
be
able
to
receive
traffic
coming
from
the
monitoring
namespace,
because
you
have
metric
parts
that
want
to
scrape
everything
right
and
you
don't
want
the
namespace
owners
in
the
cluster
to
be
able
to
override
these
rules.
That's
when
you
have
to
use
a
and
PS,
because
anps
are
the
top
in
the
chain
when
you
evaluate
them
and
none
of
the
namespace
owners
are
or
app
owners.
D
They
cannot
override
these
rules
or
you
want
to
do
tenant
isolation,
for
example,
or
maybe
you
want
to
just
be
an
admin
and
say
if
my
traffic
is
matching
a
specific
set
of
PODS
I,
don't
know
what
to
do
with
them.
So
in
that
case
I'm
going
to
just
pass
that
over
to
network
policy.
So
you
can
also
Express
that
in
ANP
it's
an
interesting
use
case,
so
ANP
interacts
with
NP
in
that
manner
you
can
just
delegate
the
power
to
the
to
the
app
owners
in
in
some
scenarios,
if
that's
what
you
like.
D
So
what
are
the
next
steps
here?
Implementations?
So
that's
where
we're
at
we
are
trying
to
get
some
initial
implementations
out
of
this
API.
That's
where
we
need
your
help.
We
have
a
Sig
Network
policy,
API
slack
Channel.
We
also
have
by
weekly
Community
meetings
happening,
so
please
join
them.
We
need
feedback
from
all
of
you.
So
if
that's
something
new
that
you'd
like
to
see
in
addition
to
what
we
already
have
or
there's
some
use
case,
that
we
have
not
considered
that
you
might
want
to
see.
D
What
so
this
effort
is
mainly
just
focused
on
trying
to
be
able
to
express
more
complex
networks
than
the
traditional
pod?
Networking
that
we
have
in
kubernetes,
like
you
might
want
to
be
able
to
express
things
like
I,
want
my
workloads
to
be
able
to
connect
to
isolated,
secondary
networks
through
performance.
Efficient
interfaces
like
sriov
or
you
might
want
to
say,
I
want
my
apps
to
be
able
to
talk
to
on-prem
networks.
So,
in
order
to
express
these,
we
are
trying
to
come
up
with
an
API.
It's
very
much
in
the
design
phase.
D
It's
a
completely
new
area,
so
I
have
a
QR
code
here
which
points
to
the
design
dock.
That
is
in
play
right
now,
and
we
also
have
a
Sig
Network
multi-network,
there's
a
lot
of
networks,
but
I
think
that's
the
goal
of
this
effort,
a
slack
channel,
so
please
go
join
there.
We
also
have
bi-weekly
community
community
meetings
here
so
yeah
welcome.
We
are,
we
would
love
to
have
contributions
from
all
fields,
I'll
hand
it
over
to
Andrew.
A
Sweet
thanks
Surya,
so
we've
talked
a
lot
about
apis
like
we
love
apis,
it's
a
lot
of
fun
to
develop
an
API,
but
it
can
get
a
little
bit
exhausting
for
developers
past
a
certain
point.
So
let's
talk
about
some
of
the
actual
networking
components
that
Sig
Network
owns
currently
so
the
first
one
is
Cube
proxy
who
here
uses
Cube
proxy
awesome
a
lot
of
people
so
we'd
like
to
see
so
most
folks
might
know
this.
A
But
Cube
proxy
is
basically
a
entry
controller
that
essentially
allows
us
to
take
the
services
and
endpoints
API
that
Rob
talked
about
earlier
and
convert
that
into
per
node
data
path.
Networking
rules,
so
it
is
a
per
node
agent
and
it
basically
allows
us
to
just
direct
traffic
on
a
node
basis.
It
is
pretty
stable,
it's
been
in
tree
for
a
long
time
and
we
have
a
pretty
dedicated
group
of
maintainers
who
make
sure
it
stays
up
and
running.
So
let's
talk
a
little
bit
more
about
it.
A
So,
like
I
said
before
it's
implemented
in
core
kubernetes
and
we
have
well,
we
had
three
different
modes.
We
had
IP
tables,
ipvs
and
user
space
user
space
has
been
deprecated
and
we
are
currently
only
maintaining
iptables
and
ipvs.
So
this
diagram
kind
of
shows
a
typical
workflow
that
Q
proxy
handles.
As
you
can
see,
a
user
comes
in
and
creates
a
service
awesome.
A
We
want
to
keep
it
that
way,
but
at
the
same
time
we
also
want
to
keep
an
eye
on
the
future,
and
so
we've
been
really
thinking
what's
next
right,
how
do
we
Implement
new
back
ends?
How
do
we
do
some
exciting
new
things
so
enter
kaping,
kpng,
Q
proxy
Next
Generation,
whatever
you
want
to
call
it?
We
like
a
ping
just
because
it
sounds
like
we're
pinging
off
something
it's
kind
of
where
we're
going
next.
A
So
basically,
kaping
provides
two
major
value
ads
today,
it's
very
early
in
its
iteration
cycle,
it's
being
done
outside
of
core
kubernetes
in
the
kubernetes
sigs
organization,
and
it
provides
a
fundamental
separation
between
the
kubernetes,
API
and
back-end
implementations.
So
this
allows
new
contributors
to
come
in
and
write
these
back
ends
really
easily
and
really
quickly,
which
is
really
exciting
and
I
know.
A
bunch
of
folks
have
wanted
to
do
that
for
a
while
today.
It
also
provides
an
extremely
flexible
deployment
model.
A
So,
as
you
can
see
in
this
diagram
in
this
specific
deployment
model,
rather
than
having
a
per
node
agent,
we
have
a
single
kpng
Daemon
that
basically
serves
an
API
that
the
back
backends
Implement
and
then
can
write
whatever
networking
networking
rules
they
want
to.
So,
as
I
said
before,
this
is
still
all
kind
of
out
of
tree,
so
development's
really
fast
pace
and
we're
still
having
figuring
out
exactly
what's
going
to
fit
back
entry
and
if
we
want
it
to
fit
back
in
tree.
A
So
these
are
some
of
the
current
backends
that
are
already
available.
Super
exciting
super
new.
As
I
said
before,
user
space
was
deprecated
from
the
entry
Cube
proxy,
but
we've
picked
it
up
here
and
coping
can
be
used
as
kind
of
an
A
Drop
in
replacement
like
we
have
no
inclination
that
we're
going
to
remove
Cube
proxy
anytime,
soon
or
ever
kind
of
like
endpoints
right,
but
we
want
to
allow
folks
to
kind
of
move
forward
as
well.
So
this
is
where
we've
come
to.
A
So
today
we
have
an
iptables
back
end
nft
ipvs
user
space,
as
I
mentioned
Windows
Sig
Windows
is
actually
helping
train
maintainers
to
maintain
the
windows
back
end
for
kaping.
At
the
moment,
I
also
have
a
really
basic
ebpf,
POC
kind
of
going
off
some
psyllium
principles,
so
huge
shout
out
to
psyllium
for
giving
us
some
ideas
there
and
way
more
to
come
from
everyone
here
right.
A
We
want
to
hear
what
kind
of
back
ends
y'all
are
looking
for,
and
we
want
to
see
what
you
think
is
going
to
happen
next,
that's
kind
of
the
goal.
Another
thing
I
really
want
to
talk
about
with
kaping.
That
has
been
really
fun.
For
me
personally,
is
it's
a
extremely
new
project,
so
contribution
is
not
weighed
down
by
a
ton
of
core
kubernetes
bureaucracy
and
stuff.
It's
moving
fast.
A
We
have
a
lot
of
contributors
who
maybe
have
never
pushed
any
code
before
and
they're
getting
to
kind
of
work
into
this
ecosystem
and
the
community
has
been
amazing.
So
please,
please,
please
get
involved.
Let's
hear
from
you,
these
slides
are
going
to
be
attached
to
our
sched
link,
so
you
can
definitely
find
these
links
there,
but
I
attached
three
just
to
get
started.
Dan
Winship
who's
in
the
crowd
wrote
a
really
good
document
on
service
proxy
in
general.
A
I
would
start
there,
it's
a
great
place
to
start,
and
then
you
can
also
get
involved
in
both
Cube
proxy,
which
is
a
little
more
stable.
So
there's
less
good
first
issues
but
dive
in
let's
get
involved.
We
can
all
work
there
together
and
then
kaping.
There
is
a
lot
of
good
first
issues
so
check
those
out
get
involved,
reach
out
and
yeah.
Let's
have
fun
and
build
together.
B
All
right,
okay,
now,
last
but
not
least,
we
have
some
features
that
have
been
in
development
and
are
reaching
either
the
beta
or
the
ga
stage.
So
first
we
have
topology,
aware
hints,
I,
think
everyone,
probably
if
you
are
on
a
cloud
provider,
has
experienced
this
problem
where
you
have
a
deployment
that
spans
multiple
zones
and
then,
when
you
create
a
service
from
them
all
of
those
endpoints
kind
of
get
swizzled
into
just
a
single
endpoint
or
a
bunch
of
endpoint
slices.
B
What
topology
aware
hints
does
is
actually
use
the
topology,
which
is
like
the
Zone
information
to
kind
of
separate
these,
so
you
can
control
where
your
traffic
is
going.
I
know
that
in
a
lot
of
cloud
providers,
there's
a
charge
when
you
send
traffic
across
zones.
So
this
feature
lets
you
keep
your
traffic
within
zones
as
much
as
possible.
B
One
thing
you
might
be
wondering
is:
why
is
it
called
hints?
It's
that
you
know
there
is
a
trade-off
between
reliability
and
sort
of
localizing,
your
traffic
and
in
in
some
ways
the
hints
gives
the
system
a
bit
of
flexibility
in
terms
of
how
to
make
that
trade-off.
For
you
and
Rob
what
is
the
status
it's
currently
beta,
but
GAA?
B
The
next
feature,
I
think,
is
like
a
pretty
critical
one.
So
originally
the
behavior
of
kubernetes
and
Cube
proxy
is
that
if
you
have
external
traffic
policy
local,
when
the
Pod
turns
into
a
terminating
State,
the
Q
proxy
will
basically
treat
the
Pod,
because
the
Pod
disappears
from
the
endpoint,
so
we'll
say:
hey
the
Pod
is
not
there
and
then
you
may
end
up
receiving
traffic
during
this
interval
before
the
Pod
actually
disappears
that
the
traffic
is
dropped.
B
We
notice
that
well,
if
the
pot
is
still
running
on
the
Node
it,
we
should
probably
still
send
it
traffic
if
we're
receiving
traffic
to
it.
So
we
should
add
an
extra
State
called
terminating
so
that
the
Pod
has
some
amount
of
time.
While
it's
still
running
to
serve
traffic,
you
might
as
well
give
it
to
the
Pod.
You
know
if
it
rejects
it,
then
it'll
be
dropped.
Anyways,
so
this
is
what
this
this
proposal
does.
B
It
adds
this
terminating
state,
which
means
that,
while
your
pods
are
shutting
down,
if
some
traffic
lands
on
the
Node,
we
will
deliver
it
instead
of
simply
just
dropping
it,
we
give
the
Pod
just
an
extra.
You
know
chance
to
kind
of
serve
the
traffic
before
dropping
it
and
I
think
a
lot
of
people
who
have
used
external
traffic
policy.
Local,
have
experienced
sort
of
this
black
hole
state,
for
example,
if
they
have
like
a
long
quiescence
time
between
the
Pod
going
away
and
the
endpoints
getting
updated.
B
Another
feature:
that's
coming
is
Network
policy
status,
so
Network
policy
up
until
recently
did
not
have
a
status
field,
and
what
we're
finding
is
that
as
we're
adding
features
to
network
policy
that
some
providers
may
not
actually
Implement
everything,
some
features
are
optional.
So
what
this
does
is
it
allows
you
to
indicate,
for
example,
your
implementation
to
indicate
that
hey
you're,
using
a
feature
that
I
may
not
necessarily
support
or
I,
can
give
you
more
information
about.
B
What's
going
on
with
your
network
policy,
I
think
the
primary
driver
of
this
with
the
port
range
feature
which
may
or
may
not
be
supported
right
now
with
all
the
implementations.
Unless
this
lets
you,
when
you,
you
know,
use
a
configuration
that
uses
poor
ranges
to
say,
hey
I
actually
don't
support
this
just
be
aware.
B
Finally,
the
last
feature
that
is
reaching
the
next
stage
of
graduation
is
internal
traffic
policy.
So
I
think
that's
a
very,
very
typical
use
case
where
you
have
a
Daemon
set
that
you
deployed
everywhere
and
you
want
it
to
receive
the
local
traffic
from
the
node
internal
traffic
policy.
Lets
you
basically
say
hey
for
this
service:
send
it
to
this
no
local
Daemon,
rather
than
spraying
it
across
your
cluster
I,
as
you
may
know,
if
you've
been
around
for
a
while
that
originally
this
was
covered
by
the
first
version
of
the
topology
API
proposal.
B
B
Finally,
I
think
this
is
the
end
of
our
presentation.
So,
thank
you
so
much
for
coming
and
I
think
if
you
take
away
one
thing
so
if,
if
all
the
slides
suddenly
disappear
in
your
mind,
we
we
really
really
appreciate
feedback
from
the
users
and
participation
in
the
Sig.
It
really
helps
us
kind
of
shape.
What
we're
looking
at
are
we
looking
at
the
right
thing?
B
E
G
Hi
so
I
have
a
question
about
topology,
aware
hints.
So
since
it
was
introduced,
it
replace
the
previous
feature,
but
right
now
it's
it's
really
in
a
completely
unusable
state
in
some
topologies
because
it
actually
decides
for
the
user.
What
an
imbalance
is
within
the
cluster
and
does
not
have
the
user
an
opportunity
to
say
whether
that's
okay
or
not
so,
let's
say,
for
example,
that
I
have
a
workload
in
my
cluster.
I
have
an
instance,
group
or
node
group.
That's
running
on
spot
and
I.
G
Don't
have
many
control
about
the
zones
where
it
runs,
but
I
don't
care
because
the
the
load
balance
the
services
that
I
want
to
load
balance
are
not
affected
by
those
asgs.
So
the
the
the
feature
will
simply
never
put
hints
on
my
services,
regardless
of
whether
they
are
running
there
or
not.
There
was
some
change
in
134
to
actually
exclude
the
control
plane
notes
by
placing
you
can
filter
on
the
label,
but
there's
no
way
that
I
can
configure
a
label
in
any
other
nodes
to
actually
exclude
it
from
from
that
as
well.
C
Yeah,
that's
a
that's
a
really
good
question.
We're
we've
had
lots
and
lots
of
conversations
about
topology
we've
gone
back
and
forth
with
a
few
different
approaches.
It's
really
hard
to
get
right
and
I
appreciate
your
feedback.
We're
we're
seeing
a
lot
that
the
the
current
approach
really
struggles
without
a
large
number
of
endpoints
like
like
you're,
showing
right
and
we've.
You
know
one
of
the
common
feature
requests
we've
had
is:
can
you
just
you
know,
prefer
the
same
Zone
if
there's
any
endpoints
in
that
same
Zone?
C
Can
you
route
it
there?
That
seems
to
work
for
a
number
of
use
cases,
but
the
reason
the
default
the
default
approach
doesn't
do.
That
is
because
it's
very
scary
right
the
the
idea
that
you
can
overload
traffic
to
a
specific
Zone.
You
know,
if
there's
you
know
all
your
traffic
is
originating
from
one
zone.
You
only
have
one
endpoint
there
and
your
other
zones
are
where
all
the
new
endpoints
are
getting
scheduled.
You
know
this
is.
C
G
So
just
a
a
quick
thing
to
add
that
the
defaults
are
are
perfectly
sensible,
so
it
makes
sense
all
the
decisions
they
can
actually
put
them
in
place.
I
think
the
only
thing
that's
lacking
is
that
it's
not
a
default.
It's
a
hard
requirement
because
there's
no
way
to
configure
it
or
to
change
the
behavior.
If
we
need
to
yeah.
C
No
you're
right:
it's
always
this
balance
of
trying
to
give
you
know
trying
to
do
what's
best
for
many
use
cases
and
not
give
too
many
knobs.
We
were
hoping.
Oh,
we
can
do
this
without
any
knobs
and
I
think
we
probably
need
some
but
trying
to
limit
the
number
we
provide.
You
know
we're
trying
to
make
this,
as
you
know,
as
need
as
minimal
configuration
as
possible,
while
still
working
for
most
use
cases.
That's
a
tough
balance,
but
understanding
those
use
cases
helps
a
lot
so.
B
H
I
J
That
implementation
specific
in
Q
proxy,
you
get
that
behavior.
So
the
traffic
shortcuts,
because
I
mean
is
when
a
part
in
a
cluster
want
to
reach
the
service
you
can
decide
or
I,
send
it
back
and
the
load
balances
send
it
again
to
the
cluster,
or
you
can
say,
I
know
that
the
service
is
in
the
cluster
and
I
send
it
directly.
The
problem
is
that
there
is
no
solution
to
fit,
or
you
know
there
are
some
load
balances
that
doesn't
work,
and
this
was
a
decision
for
people's
happy
table
right.
H
F
There
is
a
a
cap
or
something
that
was
open,
that
started
this
work
and
then
got
sort
of
abandoned
I
picked
it
up,
but
I've
been
a
little
busy
to
finish
it.
So
it
is
sort
of
something
in
progress
where
the
way
we've
described
it
is
IP
mode
for
load
balancers.
So
you
can
say
this:
IP
mode
is
a
virtual
IP,
which
means
you,
you
really
do
have
to
Short
Circuit
it,
or
this
mode
is
a
proxy
which
you
don't
want
to
Short
Circuit.
It
so
work
in
progress,
but
not
done.
E
With
the
network
policy,
stuff
I'm
really
excited
to
see
the
kind
of
like
cluster-wide
Network
policies,
because
this
has
been
a
real
pain
point
for
us,
I'm
kind
of
coming
from
a
more
network
security
background.
One
of
the
things
that
I've,
really
struggled
with
with
the
API
generally,
is
like
getting
a
complete
understanding
about
all
the
policies
that
apply
to
something
and
like
trying
to
understand
and
I
feel
like
that's
only
going
to
get
more
complicated.
E
Now
that
I've
got
different
tiers
of
policy,
and
you
were
talking
about
how,
like
the
cluster
ones,
rank
first,
which
I
guess
makes
sense.
But
then
you
need
like
exceptions
for
specific
things,
and
it's
going
to
become
a
mess.
So
like
do
you
guys
kind
of
expect
that
to
be
something
that,
like
external
tools
try
to
solve?
Is
that
something
that
you
guys
think
about
kind
of
like?
What's
your
thinking
about
that.
A
That's
a
really
really
great
question,
so
we
actually
did
a
talk
fully
on
admin,
Network
policy
as
part
of
the
contributor
Summit.
So
please
go
check
that
out.
It'll
answer
some
of
those
questions,
the
short
gist
of
it
is
yeah.
We're
making
it
really
complicated
right,
we're
going
to
have
less
users
with
the
these
admin
policies,
so
that'll
be
easier,
but
how
they
interact
with
existing
Network
policy
and
how
those
two
new
objects-
admin.
Our
policy
and
Baseline
Network
policy
interact
with
each
other
is
complicated.
A
So
as
part
of
our
cap
and
as
part
of
our
Charter
we've
put
in,
we
are
going
to
be
be
building
developer.
Tooling,
like
it
is
key.
We
are
going
to
be
building
conformance
testing
and
developer
tooling,
like
we,
don't
want
this
to
roll
out
and
just
be
confusing
for
everyone,
because
that
was
one
of
our
main
problems
with
network
policy.
In
the
first
place,
no
hate
it
was
an
amazing
API
for
developers,
but
admins
need
more.
So
it's
it's
definitely
on
the
roadmap.
Please
come
and
help.
We
need
help.
L
Hello
related
to
ANP.
Currently
we
have
some
applications
or
operators
which
are
cluster
scoped,
namespace,
scoped
right
cluster
scoped
can
listen
to
like
all
the
namespaces.
It
can
talk
to
all
the
namespaces
and
the
ANP
policies.
You
are
saying,
namespace
like
they
can
talk
to
each
other
right.
Are
we.
A
So
it'll
allow
you
it's
very
flexible,
so
adminar
policy
is
a
new
object
that
will
allow
you
to
select
everything
in
the
cluster
as
a
whole
or
pods
in
a
namespace,
and
you
also
be
still
be
able
to
use.
Network
policy,
like
you
always
have
you'll,
just
be
able
to
define
unique
levels
of
enforcement
right
so.
L
A
F
Just
just
to
be
clear:
it's
not
making
Network
policy
go
away.
It's
answering
a
different
question.
So
the
example
that
I
like
to
use
the
best
I
have
a
cluster
and
I
have
two
tenants.
There's
Coke
and
there's
Pepsi
right.
Coke
has
a
bunch
of
namespaces.
Pepsi
has
a
bunch
of
namespaces
admin,
Network
policy
lets
me
say
all
the
namespaces
for
tenant.
F
Coke
can
talk
to
themselves
and
all
the
namespaces
pretended
Pepsi
can
talk
to
themselves,
but
they
can
never
talk
to
each
other,
no
matter
what
the
user
does
and
then
within
those
namespaces
they
can
use
Network
policy
to
define
the
correct
behavior
of
their
applications.
So
there's
a
two
different
questions:
two
different
roles.
M
Hi
so
I
have
a
quick
question
on
Coupe,
proxy
and
Coupe
proxy
NG,
and
just
basically
about
the
improvements
that
come
with
it.
So
from
my
understanding
it
looks
really
promising
in
terms
of
you
know,
new
back
ends
that
can
happen,
but
what
about
existing
back-ends?
So,
let's
Samurai
and
kubrocs
see
with
iptables
I'm
happy
with
iptables.
Is
there
any
reason
for
me
to
run
kooproxy
NG
right
now
with
iptables.
A
It
provides
a
more
flexible
deployment
model
today.
If
you
want
so
acute
proxy,
is
a
Daemon
set
right,
there's
a
burnout
agent
and
in
compaying
today
you
can
run
it
and
not
like
that.
You
can
run
one
Central
ping
agent
that
talks
to
many
nodes,
so
it
allows
you
in
really
high
scale
scenarios
to
take
some
pressure
off
the
API
server.
That
would
be
the
main
selling
point.
I
would
say:
okay,.
N
A
I,
don't
think
that
kaping
architecture
necessarily
relates
to
like
a
new
type
of
network
policy.
That
is
another
thing.
If
you
want
to
work
on,
a
new
network
policy
come
talk
to
us
again.
We
need
help.
It's
more
about
making
back
ends
easier
to
write
so
one
day
it
could
apply
to
network
policy
back-ends,
maybe,
but
not
necessarily
about
like
new
policy
types.
Okay,
cool.
C
So
yeah
so
Gateway
for
L4
is
very
much
still
an
alpha
and
experimental,
but
by
by
definition
we
support
TCP
and
UDP.
Today,
one
of
the
key
things
with
this
API,
you
may
have
noticed
that
we
had
a
few
different
route
types
by
default,
but
anyone
can
plug
and
play
their
entirely
own
custom
protocol
as
a
different
route
type
using
the
same
pattern
in
the
rest
of
the
API
just
plugs
in
perfectly.
So,
if
you
want
entirely
new
route
types
and
protocols
that
would
work,
what
kind
of
L4
protocols
were
you
thinking
of.
P
B
Yeah
there
are
a
number
of
tunneling
protocols.
So
right
now
in
terms
of
the
Upstream
project,
we
have
TLS
UDP
and
TCP
on
The
L4
and
actually
we're
trying
hard
to
kind
of
get
experience
on
those.
So
we
can
graduate
them.
You
know
into
like
the
from
experimental
to
like
beta
and
then,
of
course,
HTTP
is
like
a
like
the
most
common
one.
So
that's
that's
the
one
we
know
the
most
about.
So
that's
the
one.
That's
kind
of
moved
the
furthest
along.