►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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: Updates and Future Directions - Bowei Du & Tim Hockin, Google
This session will be a deep-dive into recent changes in networking in Kubernetes. The talk will provide an overview of current and future projects, including APIs and interfaces (Service, Endpoint[Slice], DNS, Gateway, NetworkPolicy), infrastructure (kube-proxy, IPv4/6 dual-stack. Attendees to this session will come away with a good understanding of the areas covered by sig-network and what the future directions will be.
A
A
For
those
of
you
who
are
interested,
we
have
a
well-attended
zoom
meeting
every
other
thursday
and
a
busy
slack
channel
and
don't
worry.
We
will
put
this
information
back
up
at
the
end
of
this
presentation,
as
we
only
have
a
35-minute
slot,
and
there
are
many
excellent
intro
videos
here
are
some
previous
intros
and
deep
dives.
The
links
shown
here.
A
Okay,
so
what
has
been
happening
in
the
sig?
There
are
many
smaller
improvements
features
that
people
have
requested
and
apis
have
gone.
Ga
that
have
been
covered
in
detail
before
such
as
endpoint
slice
and
also
there
are
a
couple
of
big
items:
dual
stack,
which
is
support
for
ipv4
in
ipv6
gateway
api,
which
is
the
next
iteration
of
l4
l7
service,
apis,
rethinking
how
to
support
network
topology
in
network
routing
and
finally,
network
policy
working
group,
which
has
already
landed
some
features
and
are
looking
as
well
at
a
potential
version
two
of
the
api.
A
A
Basically,
before
this
improvement,
you
could
only
have
a
single
protocol
service
as
part
of
your
load.
Balancer
definition
with
the
new
changes
you
can
actually
have
multiple
protocols
supported
as
part
of
your
load
balancer
service,
for
example.
In
this
case,
you
see
a
mixed
protocol
service
that
actually
uses
both
udp
and
tcp
as
part
of
the
load
balancer
service.
A
It
is
the
case
that,
since
this
is
new,
support
actually
depends
on
your
particular
cloud
provider.
So
please
check
the
port
status
on
your
service
object
and
if
your
cloud
provider
currently
does
not
support
having
multiple
protocols
as
a
load
balancer
service,
you
will
see
this
error.
Low,
bouncer
mix
protocol
not
supported
the
next
improvement
that
has
been
added
to
kubernetes.
Networking
is
a
way
to
disable
different
types
of
lb
ports.
A
This
restricts
the
number
of
load
balancer
services
that
a
user
can
use
with
disable
lb
ports.
We
can
set
a
flag
on
allocate
load,
balancer,
node
ports,
and
if
this
is
set
to
false,
then
creation
of
a
load
bouncer
service
actually
does
not
also
allocate
a
node
port
load.
Balancer
and
pod
lifecycle
has
also
seen
improvements
in
this
past
year.
A
It
has
always
been
the
case
that,
for
a
service
with
external
traffic
policy
equals
local,
when
the
pods
in
the
service
on
a
specific
node
have
been
terminated,
there
may
be
a
period
in
time
when
the
external
lb
health
check
has
not
been
updated,
which
causes
traffic
to
be
black
hole.
During
this
time
interval,
the
pod
may
still
be
gracefully
shutting
down
but
will
not
receive
traffic.
A
We
can
see
this
illustrated
in
the
diagram
below
where
the
pods
are
terminated,
the
yellow,
lightning
bolt,
but
in
that
interim
time,
between
the
termination
and
the
health
check,
there
is
potential
for
a
black
hole
by
tracking
terminating
endpoints
in
a
separate
state.
In
an
endpoint
slice,
we
are
able
to
model
pods
in
the
graceful
shutdown
state.
A
While
in
this
state
the
traffic
steering
behavior
of
external
traffic
policy,
local
q
proxy
is
somewhat
changed.
First,
traffic
will
be
sent
to
ready
and
terminating
pods.
If
no
ready
pods
exist,
then
the
traffic
will
be
sent
to
not
ready
and
terminating
pods.
In
essence,
we
try
to
deliver
traffic
as
much
as
possible
to
endpoints
that
exist
as
opposed
to
black
holing.
The
traffic
prematurely
and
now
manuel
will
tell
us
about
endpoint
slice.
B
Another
big
addition,
the
sig
network
has
been
working
on
is
graduating.
Endpoint
slices
to
general
availability
in
kubernetes
121.
slices
were
introduced
as
a
beta
feature
to
kubernetes
and
117,
and
they
offer
a
more
simple
way
to
track.
Network
ends
points
within
kubernetes
at
scale.
Previously
the
endpoint
object
hold
all
endpoints
of
the
pots
correlating
to
the
given
surface
object
and
therefore
could
grow
quite
big
in
case
of
lots
of
pots
with
endpoint
slices.
B
Those
gigantic
endpoint
resources
would
be
splitted
into
more
granular
endpoint
slices,
where
the
endpoint
slices
only
hold
the
subpart
of
addresses
for
the
pots.
If
noah
pot
changes
its
endpoint,
only
this
endpoint
slices
needs
to
update
as
well,
resulting
in
way
less
and
way
less
consumption
of,
for
example,
memory
and
network.
Big
endpoint
object
previously
caused
issues
in
different
in
different
kubernetes
parts
such
as
the
api
or
etcd,
as
it
was
just
grown.
So
big
and
therefore
scaling
was
difficult.
With
this
new
feature,
this
becomes
finally
easy
again.
Endpoint
slices
support,
ipv4,
ipv6
and
fqdns.
A
Finally,
there
is
an
important
security
related
update
around
the
service
external
ips
feature.
Use
of
the
service
external
ips
feature
allows
users
to
specify
an
ip
directly
as
a
way
to
integrate
with
manually
configured
external
load
balancers.
Unfortunately,
it
is
impossible
for
kubernetes
to
determine
whether
or
not
the
ip
specified
actually
belongs
to
the
user,
or
is
an
internet
ip
that
they
might
be
spoofing.
A
This
can
cause
unwanted
traffic
capture
in
the
cluster,
as
external
ips
are
a
ga
feature
that
is
in
use.
The
recommendation
from
sig
network
is
to
disable
this
feature
by
default,
using
an
admission
controller.
Those
who
continue
to
use
the
feature
should
think
about
how
they
will
defend
against
this
attack
vector.
A
Let's
now
cover
some
of
the
big
changes
that
have
been
going
on
in
sig
network.
First,
exciting
news
is
that
dual
stack
support
is
progressing
to
beta.
So
what
is
dual
stack?
Support.
Dual
stack
allows
all
kubernetes
networking
components
that
is
pods
services
and
nodes
to
have
both
ipv4
and
ipv6
addresses.
A
It
basically
requires
kubernetes,
120
or
higher,
and
the
implementation
behavior
has
changed
from
previous
alpha
semantics.
You
will
need
to
enable
dual
stack
using
ipv6.
Dual
stack
equals
true
feature
gate
ipv4
ipv6
ranges
will,
of
course,
need
to
be
specified
at
cluster
creation.
Time
note
that,
when
converting
from
a
single
stack
to
a
dual
stack
cluster,
all
of
the
existing
services
will
automatically
inherit
single
stack
with
ipv4.
A
A
This
slide
shows
a
summary
of
the
changes
you
will
see
in
the
kubernetes.
Api
services
will
have
a
new
field.
Ipfamilypolicy,
this
allows
you
to
determine
what
kind
of
dual
stack
service
you
want.
Independent
of
how
the
cluster
is
configured
single
stack
means
that
you
are
explicitly
requesting
a
particular
stack
and
also
you
have
to
set
ip
families
to
choose
which
stack
is
to
be
used.
A
A
Some
common
roles
that
we
are
thinking
about
include
the
infrastructure
provider
who
manages
the
underlying
infrastructure
of
the
cluster
cluster
operators
who
deal
with
cluster
global
configuration
and
application
developers
who
deploy
their
apps
and
workloads.
The
gateway
api
has
three
main
goals
at
the
high
level.
A
A
A
The
cluster
operator
and
or
application
developer
will
create
gateway
objects
that
represent
specific
instances
of
load.
Balancers
and
the
ways
that
users
can
access
these
services.
Finally,
application
developers
will
write
routes
that
model
their
applications.
Note
that
routes
are
not
limited
to
hdp
and
l7,
but
can
also
be
l4.
A
So
we're
really
excited
to
announce
that
the
v1
alpha
1
version
has
been
cut,
and
now
there
are
at
least
six
different
implementations
in
the
works.
Please
visit
the
website
for
more
details.
V1
alpha
1
includes
features
such
as
l4
and
l7
load.
Balancing
advanced
tls
configuration
beyond
what
is
currently
possible
with
ingress
traffic,
splitting
traffic,
mirroring
header-based,
routing
and
modification,
and
a
lot
more
is
in
progress.
A
A
A
This
slide
gives
an
example
of
what
happens
when
using
the
topology
hints,
given
three
zones
with
an
equivalent
amount
of
node
capacity,
pod
endpoints
should
be
distributed
evenly
among
them.
In
this
example,
zone
a
has
one
more
endpoint
than
it
needs,
and
so
that
extra
endpoint
is
then
allocated
to
zone
c.
A
Network
policy
is
another
area
that
the
sig
is
working
on
of
the
most
voted.
Requests
has
been
of
a
port
range
api,
similar
to
what
many
cni
providers
already
have
to
this
effect.
We've
added
this
the
kubernetes
api.
Now
you
can
test
it
out
by
adding
an
end
port
field
to
your
network
policy
definition.
A
This
is
a
common
thing
that
we
have
heard,
which
is
how
to
select
a
namespace
when
I
don't
have
the
rbac
permissions
to
set
labels
thanks
to
our
friends
in
api
machinery,
for
collaborating
on
this,
the
sig
has
been
collaborating
on
cluster
network
policy
implementations.
This
will
allow
administrators
to
help
define
defaults
that
apply
across
multiple
namespaces.