►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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 Directions - Tim Hockin & Bowei Du, Google
Speakers: Tim Hockin, Bowei Du
We will be presenting what has been going on in the Network SIG for the past few releases. The session will cover new and upcoming topics, including recent features and new APIs that are under development. Topics include: IPv6, Gateway API, Network Policy improvments, other improvements, as well as future directions for the rea. This session is mostly aimed at people who are already using Kubernetes, although new users are definitely welcome. Significant time will be allotted for Q&A, so bring your questions!
A
Welcome
to
the
sig
network,
update
and
directions.
We
will
be
going
over
major
things
that
have
changed
in
sig
network
from
the
last
kubecon.
The
sig
network
special
interest
group
is
responsible
for
kubernetes
network
components.
This
includes
things
such
as
pod,
networking
within
and
between
nodes
such
as
cni
and
ipam
ingress
and
egress
traffic
service
abstractions.
A
This
includes
service
discovery,
load,
balancing,
l4
and
l7
network
policies
and
access
control,
which
is
basically
network
security
within
a
cluster
and
all
of
the
apis
associated
with
these
functions,
which
includes
pod,
node,
endpoint
and
point
slice,
service,
ingress
gateway,
network
policy,
to
name
a
few.
We
have
a
zoom
meeting
every
other
thursday,
as
well
as
a
very
active
slack
channel
in
our
community.
Page
link
is
shown
below.
A
A
A
A
A
The
new
topology
hints
is
more
flexible
than
the
previous
iteration
and
allows
for
implementations
to
have
more
leeway
in
determining
traffic
routing
when
the
user
specifies
that
they
want
their
traffic
to
be
topology
aware.
The
key
thing
here
is
to
note
that
the
topology
keys
field
is
now
completely
deprecated
and
renamed
dns
config
now
lets
you
specify
more
than
five
entries
matching
the
behavior
of
modern
libsy
implementations.
A
A
Also
in
alpha
is
the
ability
for
the
node
ipm
controller
to
allocate
ips
from
multiple
non-contiguous
sider
ranges.
This
allows
the
cluster
admin
to
dynamically,
manage
ip
ranges
using
the
api,
adding
and
removing
valid
ranges
from
the
cluster.
This
is
especially
pertinent
to
people
who
use
the
built-in
ipam
versus
getting
ips
from
their
cni
provider.
A
A
A
The
mitigation
for
this
issue
is
to
treat
the
ability
to
create,
modify,
endpoint
and
endpoint
slices
as
a
privileged
operation
and
remove
this
capability
from
the
ordinary
users
of
your
cluster
about
the
major
projects
ongoing
in
the
sig.
First,
we're
happy
to
announce
that
the
wait
is
over
ipv4
v6.
Dual
stack
is
going
to
be
ga
and
123..
A
A
Dual
stack
is
also
possible
with
load
balancing
and
services,
and
this
supports
any
combination
of
the
stats
previous
ipv6
before
semantics
remain
unchanged
with
the
support,
namely
the
behavior
egress
policy
and
as
well
as
having
a
single
ipv4
ipv6
address
on
a
pod
eg.
There
is
no
multiple
ips
per
pods
within
the
same
family
as
part
of
the
dual
stack
effort.
We
are
now
also
making
the
api
server
service
a
dual
stack,
enabled
service.
There
are
some
subtleties
to
take
care
of,
which
is
which
of
the
features
need
to
be
enabled
without
breaking
legacy.
A
A
The
gateway
api
has
also
made
significant
progress
during
the
122-123
time
period.
Gateway
api
is
the
next
version
of
the
kubernetes
apis
describing
l4
and
l7
services
in
the
cluster.
It
aims
to
be
role,
oriented
and
extensible,
allowing
users
to
configure
services
with
modern
functionality
split
across
ownership
boundaries.
We
have
been
making
steady
progress
towards
v1
alpha
2..
A
A
A
Second,
one
of
the
major
changes
was
the
simplification
of
the
way
gateways
and
routes
bind
to
each
other
in
v1.
Alpha
2
gateways
can
select
routes
by
kind
in
namespace,
with
the
default
being
routes
in
the
same
namespace
as
the
gateway.
This
enables
ease
of
use
for
simple
deployments,
while
giving
flexibility
for
more
complex
cross
namespace
relationships,
routes
directly
reference,
the
gateways
they
attach
to.
We
previously
had
a
more
complex
label
selection
mechanism,
but
this
turned
out
to
be
more
complicated
to
understand
and
support.
A
The
third
improvement
we
have
made
is
a
separate
resource
called
reference
policy
that
governs
whether
or
not
a
given
resource
is
allowed
to
be
referenced
from
another
namespace.
This
makes
cross
namespace
resource
sharing
safe
and
we
are
seeing
other
areas
in
the
api,
not
just
within
networking.
Look
to
this
api
pattern.
We
have
come
up
with
a
common
design
pattern
for
policy
attachment
inheritance
in
the
gateway,
gateway,
class
and
route
resource
graph.
A
Because
of
this,
the
back-end
policy
resource
is
now
removed
in
favor
of
the
more
generic
policy
attachment
scheme.
Finally,
routes
no
longer
contain
certificates
or
tls
information,
while
working
through
the
edge
cases.
We
found
that
this
is
too
many
edge
cases
and
is
probably
handled
better
by
an
epa
outside
the
system.
A
A
A
First
is
the
added
feature
of
port
ranges:
the
network
policy
api.
This
lets
you
specify
an
entire
range
of
ports
rather
than
one
port
at
a
time.
The
second
is
the
availability
of
a
default
namespace
label
that
has
the
value
of
a
namespace
name,
which
enables
the
common
case
of
policy
selection
by
name.
One
of
the
biggest
changes
being
proposed
in
network
policy
is
that
of
cluster
network
policy,
which
allows
operators
of
a
cluster
to
create
safe
by
default
and
guardrail
policies.
A
One
of
the
biggest
hurdles
that
we
are
currently
looking
at
is
whether
or
not
there
is
some
inherent
complexity
which
makes
the
most
generic
answer
giving
network
policies
priorities
make
the
most
sense
below.
We
have
a
couple
of
choices
in
the
proposals.
One
is
to
first
set
of
rules
to
empower
users
and
then
a
fixed,
deny
and
then
an
allow
rule
to
punch
holes
in
the
deny
and
then
apply
existing
network
policy
rules.
A
The
second
is
to
reverse
the
order
between
allows
and
denies
and
existing
rules,
and
we
see
that
these
two
choices,
a
and
b,
are
in
tension
with
each
other
choice.
C,
where
we
can
use
priorities
can
actually
express
both
a
and
b,
but
up
to
now
it
seems
that
we
have
been
trying
to
avoid
adding
in
priorities
because
of
the
complexity,
but
this
may
be
inherent
in
trying
to
write
policies
that
work
for
all
situations.
A
A
Another
large
group
is
looking
at
rebooting.
The
community
around
ingress
engine
x,
ingress
engine
x
is
one
of
the
largest
and
most
commonly
used
ingress
implementations
and
now,
with
a
new
set
of
community
maintainers,
we're
hoping
to
carry
forward
some
of
the
feature,
work
and
support
for
the
nginx
ingress
implementation.