►
From YouTube: Kubernetes SIG-Network: Intro and Deep-Dive - Tim Hockin & Bowei Du, Google & Rich Renner
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Kubernetes SIG-Network: Intro and Deep-Dive - Tim Hockin & Bowei Du, Google & Rich Renner, Sunder Networks
This session will be an introductory session to various Kubernetes networking topics (mostly aimed at relative newcomers to Kubernetes). This will include fundamental topics like pod networking, Services, and Ingress. Attendees will get a glimpse of what is happening under the covers. This introduction will be followed by a deep-dive on several new and upcoming topics, including recent features and new APIs that are under development (mostly aimed at people who are already using Kubernetes). Significant time will be allotted for Q&A.
https://sched.co/ekHt
A
Hello
welcome
to
sign
network
intro
and
deep
dive.
My
name
is
rich
runner.
I
work
for
sunder
networks
and
I've
been
a
kubernetes
user
for
around
three
years.
I'll
start
off
with
the
introduction
and
later
we'll
hear
from
bowie
do
works
at
google
about
the
deep
dive
and
ongoing
efforts
within
sig
network.
A
First
off
what
is
sig
network?
This
is
a
special
interest
group,
which
is
a
subset
of
the
broader
kubernetes
community,
focused
on
a
particular
area.
In
this
case,
it's
networking
we're
charged
with
pod
networking,
either
between
nodes
or
between
pods,
the
service
attraction,
ingress
and
egress
flows,
as
well
as
the
network
policies
and
access
control
that
a
user
may
want
to
apply
to
those
flows.
A
A
There's
many
apis
in
the
kubernetes
domain.
Some
I'd
like
to
call
out
in
particular,
which
cignet
owns,
are
service,
endpoint
and
endpoint
slice.
This
is
everything
regarding
either
the
service,
registration
or
publishing
and
from
the
client
side
the
discovery
when
you
go
up
a
layer
from
just
the
networking
and
start
talking
about
the
application,
l7
http
routing
that
would
fall
under
the
ingress
api
and
feedback
from
the
community,
as
well
as
some
challenges
that
have
been
seen
in
the.
B
A
A
A
A
It's
important
to
note
that,
while
the
networking
model
dictates
all
pods
can
reach
all
other
pods
across
nodes
in
any
location
in
the
cluster,
there
is
no
special
meaning
necessarily
for
a
pod's
ip.
It's
just
like
anything
else,
so
whether
it
be
a
vm
or
a
container
on
in
the
inside
of
a
node
depending
on
your
provider.
Networking
you
have
many
options.
A
few
of
them
are
listed
here
like
flat
or
overlays,
or,
if
you're
looking
to
scale
and
get
that
routing
update.
A
A
And
you
know
there's
a
lot
of
my
new
issues
that
come
up
from
clients
that
have
to
either
reconnect
they
might
have
to
reconfigure
the
ip
of
the
server
or
other
challenges
that
we
look
to
solve
by
abstracting
this
this
problem.
So
that
is
the
service.
Hopefully,
everyone
has
heard
of
the
service
object
and
it's
logically
placed
in
between
the
client
and
these
back-end
servers
again,
so
that
we
can
connect
to
the
same
service
without
having
to
worry
about
whether
the
servers
in
the
back
end
are
going
up
or
down.
A
So
service
it
exposes
a
group
of
pods
has
a
durable
vip.
There
are
cases
where
you
don't
have
to
take
this
option.
If
you
have
smarter
clients
that
can
handle
dns
changes,
but
in
most
cases
clients
like
to
have
that
more
durable
ip,
and
that
is
the
benefit
that
you
get
from
using
a
service
to
connect
to,
as
opposed
to
direct
pod.
A
A
Now
the
dns
pod
is
actually
a
service
itself,
but
to
avoid
getting
too
wrapped
up
with
our
explanation,
we'll
we'll
ignore
that
fact
for
now
and
just
imagine
that
we
can
resolve
a
service
that
we're
concerned
with
pod
server.
In
this
case,
we
query
the
dns
service,
it
returns,
the
vip
that
we
were
talking
about.
A
A
A
A
A
You
have
to
supply
a
port
as
well
as
a
target
port,
the
port
being
the
front
end
tcp
udp,
depending
protocol
port,
that
you
would
contact
and
the
target
port
is
the
backend
server
so
actually
having
this
layer
of
port
abstraction
turns
out
to
make
styles
of
development
a
lot
easier.
So
not
only
do
you
get
that
benefit
of
the
durability
of
the
client,
ip
address
that
you're
connecting
to
or
dns
service.
B
A
The
controller
will
see
this
new
object
that
you've
created
and
fill
out
some
of
the
fields.
If
you
chose
to
not
specify
them
as
a
user,
namely
in
the
ports
section.
We
see
that
we
actually
have
the
protocol
tcp
now,
which
is
the
default,
but
there
are
other
protocols
such
as
udp
that
you
can
use
as
well.
A
B
B
Now,
let's
talk
about
endpoints
a
service
is
virtual,
so
how
does
the
proxy
know
what
pods
to
send
traffic
to
like
most
things
in
kubernetes?
It's
going
to
be
a
controller
that
helps
facilitate
this:
the
endpoints
controller,
converts
n
pods
into
a
smaller
set
of
endpoints
and
inside
the
endpoints
resource.
B
This
represents
a
list
of
ips
that
are
behind
the
service.
Now
this
is
usually
pods,
but
it's
not
always.
You
can
manually
populate
an
endpoint
resource
as
well
now
recall
that
service
had
a
port
and
target
port
fields,
so
an
endpoints
resource
can
also
remap
ports.
You
may
have
a
port
coming
in
that
remaps
to
an
actual
port
on
the
container
and
generally
endpoints
are
managed
by
the
system.
The
controller
we
alluded
to
earlier
but,
as
I
said
before,
they
can
always
be
manually
managed
in
some
cases.
B
B
So
these
are
a
bunch
of
pause
that
are
floating
around
and
they
have
app
foo.
Some
of
them
have
app
bar
some
of
the
app
quoks.
The
service
will
only
select
the
pods
that
have
apfu
now.
What
happens
is
that
the
endpoints
controller
will
then
take
the
pods
that
match
the
service
and
put
them
in
the
endpoints
object.
Now
the
endpoints
object
doesn't
contain
all
the
information
about
the
pods.
B
Currently,
the
default
implementation
is
core
dns,
which
lots
of
people
run
as
a
service
inside
their
cluster,
but
you
could
imagine
any
such
implementation
that
matches
that
specification
could
also
be
a
provider
for
dns
for
kubernetes.
Now,
let's
look
into
details
about
how
dns
and
kubernetes
works.
So
here
is
sort
of
the
most
typical
record
that
you
will
use
it's
a
record,
a
dns
record
for
a
service
and
you'll
see
that
it's
composed
of
four
pieces.
B
B
B
B
What
q
proxy
does
in
its
implementation
is.
It
uses
the
node
as
a
proxy
for
traffic
from
pods
on
that
node
to
the
back
ends
of
the
service,
and
there
are
actually
many
different
ways
to
do
this.
We
can
use
iptables
ipvs
on
windows.
You
can
use
the
windows
kernel
or
there's
even
a
user
space
option.
In
fact,
that
was
the
original
implementation
on
linux.
Iptables
and
ipvs
are
the
best
choice,
they're
in
kernel
and
they're,
very
high
performance.
B
The
key
to
q
proxy
is
that
it's
transparent
to
the
consumers.
Anyone
accessing
the
service
vip
virtual
ip
won't
actually
have
to
be
aware
of
the
fact
that
there's
this
q
proxy
in
between
now,
what
does
q
proxy
do
on
the
control
path?
Well,
it
mainly
watches
services
and
endpoints
as
part
of
this
watch.
It
applies
some
filters,
for
example,
it
ignores
headless
surfaces
and
then
it
links
the
endpoints
which
are
the
back
ends
the
pods
that
are
selected,
which
services
which
are
the
front
ends,
and
basically
by
service
we
mean
the
virtual
eyepiece.
B
It
accumulates
changes
to
both
and
then
updates
the
kernel
state,
which
is
the
node
level
proxy
on
the
node
itself.
What
does
q
proxy
do
on
the
data
path?
Well,
on
the
data
path,
it
has
to
recognize
that
service
traffic
exists.
For
example,
your
pod
is
sending
traffic
to
a
particular
destination
virtual
ip
and
port.
B
Then
it
has
to
apply
some
kind
of
round
robin
load
balancing
technique.
Actually,
it's
random.
It
chooses
a
back
end
and
also
implements
some
of
the
service
attributes,
such
as
client
affinity
on
this
path.
Then,
finally,
it
uses
network
address
translation,
to
rewrite
packets,
to
go
to
a
new
destination
and,
of
course,
any
kind
of
load.
Balancing
with
network
address
translation.
You
have
to
undo
the
address
translation
on
the
response,
a
couple
of
common
questions
that
come
up.
B
Why
not
just
use
dns
to
do
load
balancing?
Well,
people
have
done
this
in
the
past,
but
what
we
have
found
is
that
typically
dns
clients
are
somewhat
historically
broken.
I
think
one
of
the
common
offenders
was
java
way
back
in
the
day
and
they
don't
handle
changes
to
dns
records
very
well.
You
know,
if
you
think
about
it,
dns.
B
Typically,
you
do
a
single
lookup
and
then
you
kind
of
forget
about
the
fact
that
that
record
could
change
out
from
under
you.
The
next
question
would
be
well
my
clients
already
can
do
this
kind
of
you
know
load
balancing
inside
the
client
itself.
Common
examples
are
thick
clients
like
the
redis,
client
library
or,
for
example,
grpc.
Can
I
opt
out?
The
answer
is
yes,
so
the
way
you
opt
out
is
you
can
have
a
headless
service
which
basically
gets
a
dns
name.
B
B
Kubernetes
defines
this
api,
but
implementations
are
third
party,
so
actually
there's
many
many
many
implementations
of
the
ingress
api
out
there
and
we
find
that
there
is
basically
integration
with
almost
every
cloud
and
with
every
popular
software
lb.
Here's
an
example
of
an
ingress
configuration
on
the
left,
the
yellow.
We
have
the
ingress
with
the
host
name
and
the
number
of
pads.
B
Now
since
ingress
is
a
l7
concept,
it
typically
stitches
together
multiple
services
to
serve
a
given,
for
example,
website.
So
in
this
case
we
have
a
website
that
has
a
foo
service
and
a
bar
service
and
they're
mapped
to
these
http
paths,
foo,
slash,
foo
and
slash
bar
and
they
point
to
a
service
which
is
foo
service
in
the
service,
which
is
bar
service,
which
points
to
the
actual
back
ends
of
the
pods
that
serve
that
service.
B
So
common
questions
that
people
ask
about
ingress
one
question:
how
is
this
different
from
service
load,
balancer,
so
surface
load?
Balancer,
basically
is
somewhat
of
a
l4
ish
concept,
talking
about
virtual
ips
ports
and
protocol
like
tcp
udp
now
sdtp,
whereas
the
ingress
talks
about
an
l7
protocol
and
actually
stitches
together,
potentially
multiple
services
into
one
l7
service.
B
Next
question
is:
why
isn't
there
a
controller
in
the
box?
So
what
is
interesting
about
at
least
the
ingress
space
is
that
there
were.
You
know:
http
proxying
has
been
around
forever
basically,
and
we
didn't
want
to
pick
any
winners.
There
were
just
so
many
implementations
out
there
that
were
very,
very
mature
now.
Looking
back,
this
might
have
been
a
mistake,
but,
given
the
just
the
number
of
implementations,
I
would
say
that
the
api
is
fairly
successful.
B
Even
despite
this
network
policy,
network
policy
is
a
way
for
kubernetes
users
to
describe
how
pods
can
talk
to
each
other
and
how
pods
actually
can't
talk
to
each
other.
It
basically
describes
the
allowed
call
graph
for
communications.
For
example,
a
back
end
can
talk
to
a
front
end.
A
front
end
can
talk
to
a
back
end
and
backend
can
talk
to
a
db,
but
the
front
end
can
never
talk
directly
to
db.
B
Network
policy
is
a
very
simple
api,
so
it
has
very
simple
rules
and
has
been
designed
focused
on
app
owners
rather
than
cluster
or
network
admins.
So
this
is
something
that
is
currently
evolving
in
the
sig
and
we
may
need
a
related
but
different
api
for
the
cluster
operators.
Here's
an
example
of
how
network
policy
works.
We
have
a
bunch
of
front
ends
on
the
left.
B
But,
as
you
see
here,
those
red
lines
are
front-end
talking
to
a
database
or
front-end
talking
to
another
front.
End
are
disallowed
and
if
the
front
end
tries
to
send
traffic
in
this
way,
the
packets
will
just
get
dropped.
Let's
get
into
part
two,
which
is
a
deep
dive
into
new
work.
That's
going
on
in
the
sig
okay,
so
in
part,
two
of
the
deep
dive
we're
going
to
talk
about
ongoing
work
in
the
sig.
Some
of
these
things
have
reached
ga
stage.
B
Some
are
in
alpha
and
some
are
in
beta
topics
that
we
want
to
highlight
today
in
this
session
are
work
on
improving
dns
scalability,
improving
endpoint
api
scalability,
improving
services,
expressibility
orthogonality
and
you
know,
being
able
to
map
services
and
to
express
a
more
complicated
role-based
delegation
of
responsibilities
for
services
and,
finally,
ipv6
dual
stack:
let's
talk
about
node
local
dns,
so
this
has
been
a
perennial
topic.
Kubernetes,
I
think,
there's
been
probably
more
than
five
talks
at
kubecon
about
how
to
deal
with
dns,
but
the
truth
be
told.
B
Kubernite's
dns
resource
cost
is
high.
So
first
we
have
expansions
of
dns
queries
due
to
alias
names.
Alias
names
are
great
because
you
can
create
applications
that
look
up
names
that
are
sort
of
independent
of
which
namespace
it's
living
in
which
cluster
it's
living
in.
But
you
know
implementing
these
aliases
is
pretty
expensive
because
it
requires
this
expansion.
B
The
other
interesting
thing
is
that
we
notice
that
kubernetes
also
has
high
dns
requests
because
of
application
latency.
So
if
you
have
a
bunch
of
microservices
now,
instead
of
your
vm
having
a
single
application,
you'll
actually
pack
it
quite
full
with
different
applications,
then
they
all
are
doing
the
same
amount
of
dns.
B
B
As
with
most
systems
problems,
you
know,
there's
the
two
things
you
go
to
cache
level
of
indirection.
While
the
solution
in
this
case
is
to
run
a
cache
on
every
node
and
add
a
level
of
indirection
to
the
cube
dns
service,
so
we
have
to
be
careful
about
this
because,
as
soon
as
you
talk
about
running
something
on
every
node,
now
you
have
increased
the
per
node
overhead
and
this
can
become
easily
dominate
in
large
clusters.
B
Let's
take
a
look
in
detail
about
how
node
local
dns
works.
So
here
we
have
the
current
way
cube.
Dns
operates,
cube
dns
in
yellow
on
the
right
are
a
set
of
back
ends
that
are
part
of
a
service
qdns
service
that
has
a
virtual
ip
and
that
virtual
ip
is
used
by
cubelet
to
populate
the
upstream
dns
server
for
the
pods.
B
B
Your
pod
will
then
have
its
dns
tracker
traffic
not
captured
by
the
dummy
interface.
In
fact,
it
will
go
through
q
proxy
and
it
will
go
back
up
to
the
upstream.
So
in
this
way
no
local
dns
is
able
to
transparently
insert
itself
and
remove
itself
from
your
node
without
actually
disrupting
the
dns.
For
your
pod-
and
this
is
super
important,
because
many
applications
if
dns
starts
acting
up
bad
things
can
happen.
B
B
B
So
here
we
have
a
simple
calculation
5000
nodes.
Endpoints
are
one
megabyte,
you'll,
basically
transfer
five
gigabytes
of
data,
which
is
basically
a
dvd,
and
then
you
know
if
you
do
a
rolling
update
on
the
deployment
of
a
10,
000
pod
service
and
each
one
results
in
an
endpoints
update.
You
might
end
up
transferring
up
to
25
terabytes,
which
is
a
lot
and
all
it's
doing
is
trying
to
tell
every
q
proxy
what
the
list
of
endpoints
are.
So
what's
the
endpoint
slice
solution.
B
So
here
we
have
that's
the
ep
and
endpoint.
We
have
a
single
update
to
one
of
the
entries
in
the
endpoint
and
we
end
up
sending
the
whole
thing
to
every
single
cube
proxy.
Now,
with
endpoint
slice.
What
we
have
done
is
we
have
sliced
up
the
endpoint.
We
have
multiple
slices
sliced
objects
that
represent
a
single
endpoint
here.
If
given
a
single
update
to
one
of
the
slices,
we
only
need
to
send
the
slice
now.
Clearly.
B
B
B
Now,
one
of
the
challenges
of
slicing
is
that
you
don't
have
this
one-to-one
correspondence
between
a
service
and,
for
example,
his
endpoints
object.
Instead,
we
have
this
label,
which
is
a
service
name,
that
maps
between
a
bunch
of
slices
and
the
service
that
it
represents.
So
I
said
before
that
an
endpoint
slice
is
a
trade-off
between
how
many
slices
you
make
how
small
they
are,
and
also
how
do
you
update
them
such
that
you
don't
end
up
in
the
same
situation
as
before.
B
You
kind
of
want
to
do
three
things
you
want
to
keep
the
number
of
slices
low.
You
want
to
minimize
the
changes
of
slices
per
update
and
you
want
to
keep
the
amount
of
data
sent
low,
so
we've
settled
on.
Basically,
a
fairly
simple
algorithm
for
now
seems
to
work.
Okay,
but
really
we
need
information
in
practice
to
see
how
this
behaves,
but
the
current
algorithm
does
the
following.
B
B
Next,
it
will
fill
in
new
endpoints
into
the
free
space
left
over
from
the
stale
endpoints
and
finally,
it
will
create
new
slices
only
if
there's
no
more
room.
What
this
is
trying
to
do
is
basically
try
to
reuse
the
existing
slice
objects
without
having
to
create
new
ones.
Now.
The
thing
that's
not
currently
happening
here
is
that
there's
no
active
rebalancing.
For
example,
if
you
had
a
bunch
of
slices
and
they
basically
had
a
bun,
all
the
stale
end
points
go
down,
except
for
one
of
them.
B
B
Let's
talk
about
services
across
clusters,
so,
as
kubernetes
installations
get
bigger,
multiple
clusters
is
becoming
the
norm,
and
this
is
especially
true
on,
for
example,
cloud
providers,
where
the
cost
of
creating
a
cluster
is
to
just
spin
up
a
bunch
of
vms
lots
of
reasons
to
have
multiple
clusters.
You
could
have
multiple
clusters
in
different
regions,
blast
radius
of
configuration
changes.
So
if
you
do
a
sort
of
cluster
scope
configuration
change,
you
can
only
blow
up
a
small
cluster
rather
than
a
large
cluster
geography,
latency
and
so
forth.
B
Services
is
one
of
these
things.
Surfaces
have
always
been
a
cluster-centric
abstraction
and
now
in
sig
network
and
actually
sig
multi-cluster
we're
starting
to
look
at
how
to
basically
extend
the
service
abstraction
and
these
sets
of
resources
to
work
across
clusters.
So
how
does
this
work?
Given
a
setup
like
this?
How
do
clients
in
the
front
end
talk
to
back
ends?
There
are
always
ways
existing
right
now,
such
as
talking
through
load
bouncer,
and
it
feels
like
it
should
be
easier
than
this.
B
So
what
we're
looking
at
with
the
multi-cluster
service
is
something
like
this:
that
first,
you
define
a
service
just
a
plain
old
kubernetes
service,
but
you
also
say
that
the
service
is
exported,
but
what
does
that
mean?
So
what
it
means
is
that
the
service
is
exported
to
some
group.
So
we
assume
that
there
is
some
manner
of
grouping
and
in
the
sig
multi-cluster,
this
grouping
is
called
a
cluster
set.
So
it's
a
set
of
clusters
that
are
sort
of
cooperating
in
the
same
administrative
domain.
B
We
don't
make
very
strong
requirements
on
this
grouping,
but
only
that
such
a
grouping
exists.
Now.
This
leaves
room
for
interesting
implementations
by
not
imposing
such
a
strict
requirement,
but
within
that
grouping
there
has
to
be
some
sort
of
semantics,
and
one
of
the
semantics
that
we
are
asserting
in
this
group
is
that
namespaces
between
different
clusters
mean
the
same
thing.
B
If
you
have
a
prod
namespace
in
this
group
of
clusters
in
the
cluster
set
that
that
prod
namespace
will
sort
of
have
the
same
ownership
and
admin
model
across
the
clusters,
we
can
build
controllers
that
operate
across
these
clusters
and
sort
of
operate
across
these
name
spaces
that
are
spanning
cluster.
What
service
export
does?
Is
it
triggers
the
multi-cluster
service
controller
to
publish
this
backend
service
when
you
have
exported
it?
What
this
means
is
that
it
will
create
a
service
import.
B
It
also
creates
endpoint
slices
to
represent
the
union
of
all
endpoints
across
all
exported
services.
In
this
case,
it's
just
one
that
is
exporting
now
clients
in
the
front
end
namespace
can
talk
to
the
backend
namespace,
even
though
it
exists
in
a
different
cluster.
Now,
with
services
comes
dns
records.
Multi-Cluster
service
also
defines
dns
records
as
well
just
like
before
we
have
the
name
of
your
service,
the
namespace
it
lives
in,
and
a
multi-cluster
dns
zone.
A
couple
of
interesting
things
you
may
think
of
is
one.
This
is
supercluster.local.
B
The
other
thing
is:
do
cluster
sets
have
their
own
domains,
and
these
are
things
that
we
are
currently
working
with,
say,
multi-cluster,
to
kind
of
figure
out
what
are
the
use
cases
and
where
this
should
go
kind
of
as
a
more
advanced
example.
You
know
that
the
backend
service
actually
might
exist
across
multiple
clusters,
so
you
might
have
a
service
export
and
import
that
actually
aggregates
the
service
back
ends
from
both
cluster
a
and
cluster
b,
and
if
you
access
the
cluster
set
ip
or
the
super
cluster
ip
you
will.
B
Access
back-ends
from
all
of
these
services
across
clusters
is
mostly
kepware
right
now,
but
people
are
very
busy
hammering
out
the
implementation
and
the
api
and
the
names
and
we're
still
working
on
some
of
the
semantics.
But
one
of
the
big
challenges
of
kubernetes
or
multi-cluster
is
that
it's
okay,
if
the
things
that
you're
defining
in
the
api
don't
conflict.
But
what,
if
you
have
a
bunch
of
services
that
are
linked
together
by
surface
export,
but
you
put
some
config
on
one
cluster,
that's
conflicting
with
another
cluster.
Those
things
have
to
be
resolved.
B
Now,
let's
talk
about
ipv6
ipv4,
dual
stack,
ipv6
is
something
that's
been
rolling
out
for
ages
and
kubernetes
is
no
exception
and
some
users
will
need
to
run
network
services
and
pods
in
both
ipv4
and
ipv6.
At
the
same
time,
currently
kubernetes
only
supports
one
pod
ip
and
this
ip
has
to
be
either
ipv4
or
ipv6.
It
cannot
be
both.
B
B
B
The
answer
is
yes,
but
we
found
a
couple
of
problems
and
this
actually
needed
a
major
reboot.
What
does
supporting
dual
stack
mean
for
resources?
In
fact,
it
affects
almost
every
resource
that
refers
to
ip
addresses
so
for
pod.
In
the
status
we
have
a
pod
ip
right
now
it
has
to
be
either
ipv4
or
ipv6.
B
B
B
There's
an
interesting
subtlety
here,
which
one
do
we
give
depending
on
the
user's
preference?
Should
we
always
give
ipv4?
Should
we
give
an
ipv6
address?
Should
one
of
them
be
the
default,
and
that
is
kind
of
the
crux
of
the
reboot?
It
turns
out
that
we
can't
make
very
strong
assumptions
about
which
family
is
returned
in
the
cluster
ip.
B
B
If
the
cloud
provider
supports
basically
dual
stack
lbs
and
we're
shooting
for
a
second
alpha
in
a
120,
it's
like
a
very
big
pr,
but
it
looks
like
it's
on
its
way
there.
So
this
is
great.
Let's
talk
about
services
and
the
sort
of
next
iteration
in
how
we're
thinking
about
the
api.
So
looking
at
the
current
service
api,
it's
a
resource
that
describes
many
things.
It's
a
method
of
exposure,
cluster,
ip
node
port
load,
balancer,
it's
a
way
to
group
pods.
So
it's
like
a
selector,
as
we
saw
in
the
endpoints
discussion.
B
It
also
contains
a
bunch
of
attributes
such
as
external
traffic
policy,
session
affinity
and
so
forth.
It
turns
out
that
sort
of
evolving
extending
the
resource
has
become
quite
hard
to
the
fact
that
all
of
these
fields
interact
with
each
other,
and
the
other
thing
that
makes
this
complicated
is
that
this,
as
you
see
on
the
right
hand,
side
there's
actually
a
hierarchy.
B
One
of
the
ideas
is
to
decouple
some
of
these
service
concepts
and
features
along
roll
axes.
Now,
whenever
you
do
a
role-based
design,
you
have
to
first
think
about
the
personas
that
you
want
to
kind
of
address,
and
we
kind
of
split
up
the
roles
into
the
following
sets:
there's
that
of
a
cluster
provider,
an
infrastructure
provider.
B
Now
the
concepts
we
talked
about
in
the
previous
slide,
we
also
have
split
up
in
into
different
axes,
so
grouping
and
selection
will
remain
the
domain
of
the
kubernetes
service,
routing
and
protocol
specific
attributes
will
be
put
into
a
protocol,
specific
routing
resource
and,
finally,
exposure
and
access
is
basically
the
virtual
ip.
The
endpoint
that
the
clients
will
be
contacting
will
be
part
of
gateway,
and
finally,
at
the
top
of
this
is
gateway
class.
B
Let's
go
through
each
of
these
roles
and
kind
of
see
get
a
taste
of
like
what
the
api
looks
like.
So
the
infrastructure
provider
will
basically
create
a
bunch
of
gateway
classes
that
then
are
backed
by
controllers
that
implement
gateway
class.
So
these
define
a
type
of
service
access
for
the
clusters.
For
example,
you
can
give
your
consumers
of
the
gateway
classes,
a
generic
name
such
as
internal
proxy
internet
lb
and
kind
of
abstract
them
from
how
these
things
are
implemented.
B
The
second
persona
that
we're
looking
at
is
the
cluster
operator
netops,
and
this
person
we
find
is
typically
determining
how
services
are
accessed
by
the
user.
You
know
what
port
protocol
addresses
tls
certificates,
whether
or
not
it's
on
the
internet,
whether
or
not
it's
internal.
What
resources?
You
know!
Maybe
it's
expensive,
gold,
low,
bouncing
or
maybe
a
cheaper
infrastructure,
and
really
the
cluster
operator
we
feel,
will
control
the
gateway
resource.
This
is
a
keystone
resource.
That's
one-to-one
with
active
configuration
of
some
part
of
the
infrastructure.
B
Creating
a
gateway
resource
will
spawn,
for
example,
a
software
lb.
It
may
add
a
configuration
stanza
to
an
existing
lb
may
program,
the
sdn,
so
the
gateway
will
sort
of
describe
how
the
whole
service
will
be
accessed,
and
we
also
note
that
this
gateway
resource
may
be
underspecified,
so
you
can
kind
of
use
it
to
request
a
particular
kind
of
gateway,
but
the
system
and
the
implementation
can
kind
of
fill
in
the
details.
B
So
here's
a
sort
of
a
sketch
of
the
gateway
resource
and
you'll
see
that
it's
under
specified,
because
all
we're
doing
is
asking
for
a
port
and
route
selector
to
show
you
how
which
routes
are
linked
to
this
gateway.
But
we
don't
really
talk
about,
for
example,
which
address
it's
going
to
get
and
those
will
be
dependent
on
and
filled
in
by
the
gateway
class.
B
B
You
know
which
services
is
going
to
route
to
and
kind
of
the
protocol,
specific
matching
and
filtering
that's
how
they
implement
their
application.
One
interesting
thing
is
that
we
have
done
here
is
in
modeling
this.
We
have
actually
split
out
each
of
these
routes
into
their
own
protocol,
specific
resources,
so
we
have
a
http
route,
tcp
route
and
so
forth,
and
this
allows
us
to
one
make
a
resource,
that's
specific
to
that
protocol.
So
it's
much
easier
to
understand
and
two
because
they're
actually
separate
resources
that
can
all
linked
into
gateway.
B
It
actually
creates
a
bit
of
extensibility,
for
example,
if
your
gateway
class
provider
can
handle
like
a
new
protocol,
for
example,
let's
say
you
do
redis
load
balancing.
You
can
have
a
redis
route
that
can
talk
about
redis
protocol,
specific
details
and
actually
add
that
to
the
system
without
having
to
say,
modify
the
entire
standard
or
send
it
upstream.
B
B
So
here's
an
example
kind
of
broken
out,
so
we
have
a
gateway
class,
that's
referred
to
by
the
gateway
and
the
gateway
class
defines
sort
of
how
the
implementation
will
be
wiring
up
the
rest
of
it.
For
example,
internet
lb,
that's
implemented
by
a
cloud
provider
that
way
but
particular
gateway
class.
B
So
the
initial
v1
alpha
one
it
will
cover
basic
applications
and
data
types
gateway
class
for
inter
operation
between
different
controllers,
a
gateway
and
route.
So
http
tcp,
https
server
secrets
and
we
actually
have
a
whole
bunch
of
implementers
who
are
going
to
participate
in
this
alpha
and
we're
looking
at
both
merging
style
implementers,
which
is
sort
of
multiple
gateways
that
are
hosted
on
a
single
proxy
infrastructure.
For
example,
you
run
ingress
nginx,
that's
like
a
merging
style
gateway.
B
B
B
The
best
way
to
kind
of
get
your
cap
moving
is
to
show
up
at
sig
network
and
discuss
what
you're
proposing.
Probably
in
that
discussion
it
will
spill
onto
the
mailing
list
or
maybe
a
shared
document,
and
then,
after
we
have
kind
of
consensus,
it
will
become
a
cap.
So
if
you
want
to
get
involved,
there's
our
community
page,
we
have
a
zoom
meeting,
which
is
every
other
thursday.