►
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.
Panel Discussion: Cloud Native Networking State of the Union - Raghavan Srinivas, InfoQ; Lin Sun & Christian Posta, Solo.io; Alyssa Wilk & Tim Hockin, Google
Note: LIVE panel. The Cloud Native networking landscape is particularly frightening. With the advent of service mesh and containers being deployed in the tens of thousands, L4/L7 load balancing, plus networking implementations for each public cloud being different, it's important for application developers and devops audiences to understand the nuances of Cloud Native networking.
The panelists, all cloud native networking experts including the Kubernetes Networking SIG chair, etc. will go into some of the fundamental design challenges and address some advanced scalability issues. We will include select questions from the audience as well.
This panel, intended for application developers and devops audience will look at the Cloud Native networking ecosystem, past present and future. Attendees will walk away with a better understanding of the challenges of some of the tools for the trade and how to best implement Cloud Native networking best practices.
A
Hello,
everyone
good
morning,
good
afternoon
or
good
evening
wherever
you
are,
this
is
the
cloud
native
networking
state
of
the
union
a
panel
discussion.
My
name
is
raghavan
srinivas
and
I'm
going
to
be
the
moderator
for
the
panel.
I
really
appreciate
you
know
the
rest
of
the
panelists
who
are
up
at
you
know
different
times
of
the
day,
but
but
we
really
wanted
to
do
this
as
a
live
panel,
and
hopefully
the
next
conference
we
can.
We
can
all
be
face
to
face.
A
A
C
B
That's
fine
yeah
yeah,
thank
you
all
for
joining
or
joining
live
and
watching
this
and,
of
course,
for
panelists.
But
I'm
I'm
christian.
I
work
at
solo.
My
interests
are
on
the
kubernetes
level
and
application
level
and
then
up
from
there.
So
how
application
networking,
how
service
mesh?
How
these
types
of
things
improve
one's
platform.
D
Hi
everyone
hi
everyone
thanks
for
joining
us,
I
am
very
new
to
solo.
I
joined
solo
about
two
months
ago,
I'm
currently
the
director
of
open
source
solo
prior
to
doing
solo.
I
work
for
ibm
for
a
long
time,
contributor
and
speaker
to
cubecar
I've
been
contributing
to
istio
project
for
a
long
time.
My
primary
interest
is
istio
service
mesh
and
help
our
user
adopting
service
mesh.
I'm
currently
a
maintainer
on
the
project.
Also
a
tsc
member.
E
My
name
is,
I
am
also
at
google,
where
I've
been
working
on
front-end
proxying
for
about
14
years
on
the
gfe
team,
I
launched
http2
and
htv3
at
google
so
worldwide,
and
then
I
switched
over
to
working
on
envoy,
where
I'm
now
a
senior
maintainer,
so
I'm
very
focused
on
the
envoy
project,
both
as
a
server
and
as
a
client.
Now
envoy,
mobile
and
kind
of
network
scalability
in
general.
A
So
feel,
free
again,
you
know
as
participating
audience.
You
know
thanks
for
watching
and
you
know
feel
free
to
start
some
questions.
I
already
see
a
few,
you
know
in
the
q
a
but,
but
let
me
start
with
some
questions
that
I
kind
of
lined
up
so
one
question
this
is
this:
is
the
you
know
for
everyone
on
the
panel
and
we
can
we
can
just
go.
You
know
christian
plus,
then
tim
then
lin
and
then
alyssa.
A
If
you
don't
mind,
was
the
original
requirements
or
assumptions
for
network
design
for
kubernetes
really
too
simplistic,
and
it's
becoming
increasingly
hard
for
kubernetes
clusters
to
scale
to
you
know.
Hundreds
of
thousands
is
that
you
know
what
do
you
have
to
say
about
that?
So,
let's,
let's
go.
You
know
with
christian
fast.
B
Yeah
sure
so
I
guess
I'm
I'm
going
to
have
a
frame
of
reference
that
might
might
might
not
appreciate
the
assumptions
in
that
question,
but
so
I,
first
of
all,
I
do
think
that
the
the
kubernetes
did
a
an
amazing
job
at
two
things.
One
staying
trying
trying
to
be
a
simple.
You
know
up
front
so
that
you
know
you
can
bring
your
applications
to
kubernetes
they're,
not
going
to
be
a
lot
of
complexity
and
hoops
to
jump
through
to
get
it
to
kubernetes.
B
B
I
I
guess
I'm
of
the
opinion
or
I'm
working
with
organizations
in
an
enterprise
where
some
of
them
have
deployed,
maybe
not
hundreds
of
thousands
but
thousands
and
thousands
of
nodes,
and
they
are,
you
know,
we're
almost
trying
to
redesign
that
and
go
toward
maybe
smaller,
smaller
kubernetes
clusters.
But
that's
that's
that's
my
point
of
view
here.
C
So
as
someone
whose
fingerprints
are
on
some
of
those
early
design
decisions,
I
thank
you
for
for
calling
out
the
main
goal,
which
was
to
keep
it
simple.
The
you
know
the
assumption
at
the
beginning
of
the
whole
kubernetes
experience
was
to
make
it
not
really
surprising
for
people
who
are
coming
to
it
from
a
vmish
world,
and
so
I
wanted
to
feel
sort
of
the
same
but
be
different.
C
You
know
here
we
are
now
six
seven
years
later
and
we've
got
a
lot
of
new
workloads
that
we're
trying
to
bring
into
kubernetes
and
honestly.
If
you
told
me
seven
years
ago
that
we'd
be
talking
about
the
things
we're
talking
about
now,
I
would
not
have
believed
you,
so
the
requirements
have
shifted.
I
do
think
that
kubernetes
is
struggling
a
little
bit
to
provide
the
primitives
that
we
need
for
some
of
the
higher
level
primitives
that
we
want
to
build.
D
D
You
know
I
have
multiple
services
as
I'm
moving
from
my
monolithic
to
multiple
micro
services,
how
am
I
going
to
you
know,
handle
my
service
connectivities
as
my
services
going
to
be
distributed
to
multiple
nodes
in
kubernetes
and
maybe
multiple
zones
and
regions,
so
the
network
is
not
always
reliable
as
monolithic
from
their
perspective,
so
what
does
kubernetes
do
for
them?
In
that
perspective,
I
I
think
today
it's
it's
not
clear.
D
E
Okay,
yeah,
I'm
I'm
a
big
fan
of
launch
and
iterate.
So
to
me
the
fact
that
we're
hitting
these
scaling
boundaries
is
a
sign
of
kubernetes
success.
You
know,
there's
the
iconic,
you
know
640k
ought
to
be
enough
for
anyone.
I
don't
think
that
scaling
up
in
that
particular
direction
was
expected.
You
know
it
was
like
trying
to
create
a
successful
ecosystem,
and
then
you
never
know
what
you
know.
What
payloads
and
what
you
know
infrastructure
people
are
going
to
be
using
it
for
in
years.
A
Absolutely
okay,
so
I
know
questions
are
starting
to
trickle
in
you
know,
feel
free
to
add
questions,
and
you
know
we
are
here,
live
to
answer
those
questions
that
you
have.
So,
let's
start
with
the
top
one,
is
the
status
of
ipo
v6,
only
now
mature
in
kubernetes,
and
what
about
direct
connectivity
compods
and
our
containers
in
pods
instead
of
connecting
through
the
ip
address
of
the
host?
This
is
from
jan
hugo
jan
thanks
for
asking
the
question:
where
do
we
want
to
start?
C
I
have
a
lot
of
context.
I
I
can
speak
to
the
state
of
kubernetes
it.
It
might
even
still
be
premature
to
say
that
ipv6
support
is
mature.
Dual
stack
support
is
beta
now,
so
it's
more
mature
than
it
has
been
in
the
past.
It's
not
going
ga
in
the
next
release,
but
hopefully
the
release.
After
that,
the
to
the
rest
of
the
question
you
know,
direct
connectivity
kubernetes
was
actually
built
to
assume
direct
connectivity.
C
C
That's
not
always
practical,
not
for
all
customers
and
not
all
environments.
So
you
know
we
do
allow
other
models,
I'm
hoping
that
the
rise
of
ipv6
20
years
later,
the
rise
of
ipv6,
will
enable
more
people
to
embrace
that
model.
The
ipv4,
you
know
ip
address
limitations
have
been
have
been
a
real
problem
for
people.
A
A
Can
you
address
the
continued
fast
pace
of
change
and
where
you
see
communities,
networking
going
and-
and
I
think
this
is
a
classic-
you
know
too
much
happening
versus.
You
know
too
little
happening
right.
You
know.
Where
is
the
happy
medium?
I
guess
right
so
who
wants
to
take
this
question?
I
know
that
you
know
many
of
you
are
kind
of
part
of
the
network
right
so
should
we
start
with
somebody
else
other
than
tim.
B
I
I
can
take
an
initial
crack
all
right,
so
so,
first
of
all,
I
do
think
it's.
There
are
a
lot
of
networking
initiatives
going
on
a
lot
of
things
happening
in
the
networking
working
group,
but
I
think
that's
good.
You
know,
there's
a
lot
of
iteration
and
a
lot
of
innovation
happening
in
those
spaces
and,
like
like
alyssa,
said
when
you
get
to
those
points
where
you
hit
bottlenecks,
you
hit
scalability
issues
and
so
on
things
become
really
interesting.
B
D
Yeah,
I
guess
I
would
add
that
you
know
there
are
interesting
things
in
addition
to
the
gateway
api.
It's
like
the
multi-cluster
service
api.
You
know
the
issue
community
is
looking
at
implement
that
we
know
there
are
challenges
with
running
services
in
multi-cluster,
where
we
want
to
have
ability
for
mesh
admin
or
the
service
owner
to
be
able
to
control
what
other
services
they
want
to
expose
outside
of
their
cluster,
whatever
services
they
want
to
import
into
their
cluster.
So
that's
really
interesting
and
I
know
tim.
D
You
are
also
driving
an
effort
to
replace
the
sidecar
cap,
which
we
had
a
huge
interest
from
the
istio
community
perspective,
because
there
are
a
lot
of
user
wants
to
be
able
to
precisely
control
the
proxy
start
sequence,
the
cycle
proxy,
corresponding
to
their
application
container
in
the
service
mesh
environment.
So
that's
super
interesting
to
us.
From
our
perspective,
you
know
been
working
on
istio
for
a
long
time.
D
We
realized.
Certainly
an
item
on
the
roadmap,
for
a
particular
release,
sometimes
doesn't
mean
it's
actually
committed
to
the
release.
It
actually
means
you
know,
making
enough
progress
and
hopefully
reach
some
stage
for
that
release.
But
not
necessarily
you
know
it's
a
hard
thing.
You
know
the
release
is
not
going
to
hold
up
for
the
completion,
so
I'm
actually
really
curious
to
hear
from
tim
on
this
too.
C
Talk
sure
I'll
be
quick
on
on
this.
One
sig
network
has
been
super
super
active,
the
last
three
or
four
cycles,
which
is
great
there's
a
lot
of
caps
listed
in,
say
this
next
release.
Some
of
them
are
huge,
like
dual
stack.
Actually,
dual
stack
isn't
fundamentally
changing
in
the
next
release,
but
some
of
the
some
of
the
in-progress
work
is
huge
right.
Dual
stack
touches
every
part
of
kubernetes
and
therefore
it's
taken
a
very
long
time
for
us
to
build
our
confidence
in
both
the
api
and
the
implementation.
C
Many
of
these
caps,
though,
are
much
smaller
in
scope,
right,
they're,
adding
a
field
to
the
api
which
allows
load
balancer
control
from
the
cloud
provider
in
a
in
a
very
nuanced
way,
so
I
wouldn't
be
overwhelmed
by
the
sheer
number
of
them.
You
know,
but
we're
we're
tackling
a
bunch
of
different
issues,
sort
of
all
at
the
same
time
and
in
different
places
that
includes
things
like
topology
and
topology,
aware
routing
of
traffic.
C
I
saw
another
question
in
the
in
the
q
a
sort
of
about
that,
so
we're
adding
more
capabilities
there
and
that'll
become
default.
Eventually,
things
like
gateway,
I
think,
is
a
huge
effort,
but
actually
kind
of
outside
the
core
of
kubernetes
right.
It's
all
happening
as
as
custom
resources,
so
that's
sort
of
an
interesting
proof
of
the
of
the
viability
of
custom
resources.
Honestly
we're
also
looking
at
things
like
major
ipam
overhauls
so
that
we
can
be
more
functional
in
restricted
environments
like
on-premises.
C
C
Somebody
took
the
idea
that
we
wrote
and
started
writing
a
kept
for
it.
I'm
a
little
wary
because
we
don't
have
sort
of
alternate
ideas
explored
yet,
but
I
definitely
want
to
see
the
sidecar
life
cycle
problem
tackled
in
a
holistic
way.
So
there's
there's
a
lot
going
on,
but
don't
just
look
at
the
numbers.
Also,
you
know
spend
a
little
time
to
understand
the
scope
of
each
because
they're,
not
that
big.
A
E
You
one
pass
on
that.
I'm
gonna
go
with
good
and
scary.
You
know
when
you're,
adding
something
like
this.
It's
it's
really
hard
to
get
it
right,
especially
get
it
right
at
first
pass
to
make
sure
that
you're
not
setting
up
your
filters
wrong
or
you're,
not
allowing
the
permissions
to
get
screwed
up
and
trafficking
code
at
the
wrong
place.
E
But
again
you
know
in
a
prior
life
I
was
you
know,
tl
of
google's
http
3
effort
or
quick,
as
it
was
at
the
time
and
we're
getting
quick
support
and
envoy
hopefully
later
today,
and
you
don't
want
to
use
htv3
without
epf.
It's
just
that
the
kernel
doesn't
doesn't
throw
packets
around
fast
enough.
So
I'm
hoping
that
that
soon
this
will
spread
out
to
the
entire
kubernetes
ecosystem
and
you're
gonna
want
bpf
to
get
it
right
and
really
have
kind
of
the
next
generation
of
high-speed
networking.
D
To
me
as
well,
when
I
first
looked
at
the
question,
I
was
like
okay,
it's
great.
I
love
you
know
all
the
momentum
behind
the
ebpf
and
all
the
powerful
things
they
provide,
but
it's
really
scary,
you
know
as
individual
developer.
I
don't
think
I
want
to
touch
ebpf
right.
I
really
would
rather
have
a
you
know,
a
trustworthy
vendor
to
provide
solution
for
ebpf
and
then
for
average
developer
to
consume,
because
it's
hard
of
messing
up
the
kernel.
You
know
it's
going
to
be
super
hard
to
do
debug.
D
B
C
I
you
know
it's
it's
funny
to
call
ebpf
young,
because
it's
been
around
for
years
and
years,
but
in
the
sort
of
overall
adoption
curve
of
these
sorts
of
things,
it
is
pretty
young
still,
I'm
super
excited
about
ebpf,
not
from
an
end
user
point
of
view.
I
don't
think
end.
Users
should
ever
see
or
know
about
it,
I'm
more
excited
in
the
opportunities
that
it
opens
sort
of
the
the
the
adjacency
of
the
possible
right.
A
Okay,
the
next
question
is
from
ricardo.
How
do
you
see
the
current
multi-cluster
or
hybrid
cluster
options,
and
do
you
think
there
should
be
more
support
for
this
use
case
directly
in
kubernetes?
Obviously,
I
think
he's
referring
to
the
networking
aspects
of
this
right,
so
I
have
a
multi-cluster
or
a
hybrid
hybrid
cluster
and
and
what
should
humanity's
networking
or
how?
How
does
it
need
to
be
enhanced
if,
if
it
should
be,
is
my
reading
of
the
question
is
that
is
that
accurate.
C
So
I'll
start,
but
then
I'll
hand
off
quickly,
because
I'm
actually
really
curious
to
hear
everybody
else's
thoughts.
Kubernetes
is
a
cluster
oriented
solution.
It
is
the
scope
of
the
the
boundaries
are
growing
a
little
bit.
I
I
do
think
that
some
of
the
capabilities
to
enable
multi-cluster
are
going
to
be
or
are
starting
to
be
ingested
into
the
sort
of
scope
of
kubernetes.
C
We
have
service
imports
and
service
exports
now,
which
is
a
way
to
publish
services
across
clusters,
but
it's
explicitly
an
api
and
not
an
implementation,
because
the
the
variety
of
sorts
of
ways
to
make
this
happen
are
so
broad,
and
I
think
gateway
also
plays
to
this.
It's
a
more
neutral
way
to
describe
the
sort
of
doors
between
services,
and
so
I
I
do
think
that
multi-cluster
is
sort
of
going
to
become
the
norm.
C
I
want
to
be
careful
that
kubernetes
doesn't
try
to
be
everything
to
everyone
and
try
to
absorb
every
single
api
out
there.
So
service
import
service
export
was
a
very
tactical
small
step
to
cover
one
use
case
that
just
kept
coming
up
over
and
over
and
over
again
the
rest
we're
going
to
be
super
careful
about
this
is
where
I
think
service
mesh
becomes
a
really
interesting
way
to
explore
it,
because
you
have
a
lot
more
freedom
as
you
move
up
the
stack.
This
is
where
I
want
to
hear
everybody
else.
A
I
think
there's
another
question
by
gary,
which
kind
of
feeds
into
the
same
thing
as
well,
which
is
kind
of
like
many
cloud
providers,
offer
multi-zone
deployment
within
a
region,
and
you
know
some
offer
multi-cluster
networking
for
clusters
deployed
across
regions.
Is
there
something
from
a
networking
perspective
again
which
stops
people
from
doing
that?.
B
Yeah,
if
I
could
just
build
a
little
bit
on
what
tim
said,
at
least
we've
been
looking
at
it
from
the
application
level,
how
do
applications
communicate
with
each
other
that
might
be
deployed
across
different
clusters?
For
various
you
know,
regulatory
compliance
type
reasons,
or
you
know
scaling
reasons
and
isolation,
reasons,
and
so
on.
B
They
can
be
deployed
on-prem
that
can
be
deployed
in
public
cloud
and
the
way
we
try
to
solve
that
is
at
an
abstraction.
So
what
is
multi-cluster?
What
is
multi
infrastructure?
What
is
what
does
that
networking
look
like?
Well,
the
applications
need
to
be
able
to
exchange
messages
with
each
other,
and
so
what
are
the
solutions
that
support
that
service
mesh
is
one
and
and
there's
others,
but.
D
Yeah
just
to
add
on
to
that
certainly
multi-cluster
service
api.
I
think
it's
super
interesting
for
service
mesh
because
I
don't
believe
you
would
using
kubernetes,
along
with
implementation
of
multi-cluster
service
api
without
service
mesh.
The
reason
is,
you
could
use
that
assuming
there's
an
implementation
out
there,
but
the
problem
is
you
have
to
solve
all
that
problem
that
service
mesh
is
going
to
solve?
For
you
I
mean
when
you
talk
about
connectivities
service
connectivity
among
multi-cluster.
D
How
are
you
going
to
secure?
You
know
the
communication?
How
are
you
going
to
you
know,
do
like
load
balancer
fade
over.
You
know,
prefer
local
and
fail
what
you
remote.
How
are
you
doing
traffic
shifting,
so
a
set
of
challenges
is
going
to
come
to
you
as
a
service
owner
and
then
it
makes
sense
just
to
build
on
top
of
what
service
mesh
already
provides
so
team.
To
your
point,
I
I
almost
feel
you
know
that
api
is
really
designed
with
service
mesh
in
mind.
E
A
Great,
I
was
going
to
bubble
this
question
up
anyway,
because
this
is
a
little
bit
more
tactical,
but
but
seems
like
it's
getting
more
rewards,
which
is
with
power,
security
policy,
psp
being
deprecated
in
communities.
1.2.1
there
seems
like
there
are
some
security
gaps
with
kubernetes
networking.
Are
we
seeing
more
clients
adopt.
C
Sorry,
I
I
can't
stand
a
void.
I
I
personally
I've
seen
a
ton
more
uptake
of
oppa
and
using
that
for
much
more
sophisticated
policies.
In
the
last
year,
it's
been
a
very
noticeable
uptake
from
what
I've
seen
there
are.
I
mean
security
is
such
a
complicated
and
broad
problem.
It's
hard
to
to
talk
about
what
even
network
security
means.
A
D
Well,
I
would
say:
gosh
yeah,
I
would
say
the
ingress
is
kind
of
becoming
identity
or
well,
at
least
within
the
service
mesh
environment.
Right,
because
we're
seeing
service
mesh
environment,
we
actually
give
the
identity
to
the
ingress
gateway
from
like
we,
the
control
plane
of
the
service
mesh
provisions,
the
identity
for
all
the
services
within
the
mesh
and
the
gateway,
at
least
the
inner,
I
would
say
the
inner
portion
of
the
gateway.
You
know
it
has
this
identity,
whereas
it's
interact
with
the
rest
of
the
services
in
the
mesh.
B
And
I
guess
I'll
just
add
that
I,
when
I
thought
about
identity
I
thought
about.
I
guess
I
immediately
thought
end
user,
like
the
requests
are
coming
in
to
to
to
the
gateway
in
an
ingress
setting,
and
I
what
I
would
expect
is
that
those
things
those
types
of
things
would
be
delegated
to
you
know
I
am,
and
I
I
identity
provider
solutions
that,
but
that
it
would
be
able
to
provide
identity
for.
For
those
end,
users.
C
Else,
it's
very
yeah,
it's
very
difficult,
because
kubernetes
is
so
broad
and
it
is
on
so
many
platforms,
it's
difficult
to
make
assumptions
about
identity
and
what's
carried
on
the
wire
and
what
isn't
which
it
makes
it
sort
of
a
limiting
factor
for
apis
like
ingress
which
try
to
be
very
compatible
and
identity.
Doesn't
map
very
well
in
there.
I
do
hope
that
we
can
make
it
better
and
make
it
more
identity
aware
this
comes
back
to
something
like
bpf,
where
you
know.
C
C
A
Perfect,
I
know
that
we
are
coming
up
to
less
than
four
minutes.
I
really
want
to
bring
up
this
last
question,
which
is
kind
of
a
little
bit
forward.
Thinking
and
basically,
what
it
is
is
you
know
again
going
back
to
the
original
simplistic
design
humanities
handles
simple
networking
things
pretty
well,
but
is
it
keeping
up
with
the
capabilities
people
need
in
the
2020s?
A
E
So
so
of
how
close
we
are
to
to
done,
I
I
will
say
I
I
don't
think
it's
ever
going
to
be
done
right.
I
think
that
there's
always
going
to
be
some
evolution
of.
Oh
and
now
we
have
this
new
type
of
deployment,
and
we
have
this
new
setup
and
and
such
so.
I
think
that
that's
going
to
continue
to
evolve
and
I
think
you
know
for
for
what's
added
next,
I
think
it's
just
going
to
be
based
on
demand,
largely
especially
with
open
source
projects
like
this.
E
I
don't
there
isn't
always
an
easy
roadmap
right.
It's
based
on
on
what
people
use
as
deployments
and
what
innovation
there
is
in
the
entire
space,
not
just
the
project,
so
I
feel
like
there's,
maybe
like
a
feel
for
a
roadmap
for
like
a
year
or
so
out.
But
beyond
that,
I
I
don't
know,
I
don't
know
if
other
people
have
a
sense
for
that.
B
Yeah
I'll
just
say,
one
thing
I
absolutely
love
about
kubernetes
is
that
they
the
the
community,
the
project
they
they
drew
a
line,
and
they
said
this
is
this
is
where
we're
going
to
live
and
we're
going
to
allow
other
things
to
sprout
off
or
extend
in,
and
you
know,
with
the
apis
custom
resources
all
that
stuff.
I
think,
we'll
probably
see
more
optimizations
in
kubernetes
to
continue
to
support
that
model.
D
Well,
I
would
say
you
know
the
some
of
the
challenges
with
the
service
owner
running
their
services
in
kubernetes,
really
open
up
the
doors
for
other
solutions
like
service
mesh
to
shine
in
this
space
right.
So
it's
actually
really
nice,
like
christian,
said,
kubernetes
are
not
going
after
those
set
of
problems
and
leave
to
another
solution
or
architecture
to
solve
that
problem.
So
I
think
that's
really
nice
and
you
know
we
have
so
many
vendors
in
service
mesh
community
these
days
trying
to
compete
in
that
space.
D
So
that's
really
interesting
what
I
would
really
love
to
see.
You
know
I
actually
really
love
kubernetes.
It's
become
so
boring
that
people
really
view
kubernetes
as
infrastructure
now,
but
it's
not
filling
the
gap.
Well,
the
service
on
their
knees,
which
is
on
the
layer,
seven
on
the
service
level
of
connecting
services.
So
I'm
I
really
love
you
know.
Service
measure
would
get
there
one
day
becoming
so
boring
as
kubernetes.
D
C
C
It's
much
more
complicated
api
than
ingress
was
because
it
tackles
a
lot
bigger
problem,
but
it's
designed
to
be
extended
because
we
want
these
implementations
of
of
things
like
service
mesh
to
be
able
to
plug
in
at
various
points
and
say
you
know,
if
I'm
a
user,
and
I
need
to
pop
out
to
implementation
specific
capabilities.
Here's
where
I
can
do
it
here
here
here
and
here,
and
I
think
it's
really
important,
because
otherwise
the
abstraction
isn't
useful
right.
C
Initially,
you
know
we
put
our
fingers
in
our
ears
and
hum
because
we
didn't
want
to
deal
with
those
use
cases,
because
they're
really
hard
well
kubernetes
is
pretty
successful
now,
and
we
have
to
hear
those
users
and
those
use
cases
that
they're
bringing
to
us
community
came
up
with
some
solutions.
I
think
we
need
to
normalize
those
and
make
them
a
regular
sort
of
capability,
and
I
also
think
we
need
to
look
at
things
like
virtual
network
functions
and
you
know
bump
in
the
wire
packet
processing,
even
within
a
cluster.
A
What's
about
you
know
time
to
wrap
up,
I
really
want
to
thank
all
the
panelists,
but
but
really
want
to
thank
the
audience
for
such
insightful
questions.
There
are
so
many
more
I
wish
we
had
like.
You
know
much
more
time
to
talk
about,
but
that's
kind
of
the
lead
into.
Please
come
to
the
slack
channel
where
you
know
the
channel
is
number
two
dash
q,
a
number
as
a
number
two
dash
cube
con
networking.
A
So
you
know
I
urge
the
panelists
also
to
please
join.
You
know
it's
gonna
be
chaotic,
but
you
know
that's
fun
right.
I
mean
this
is
the
hallway
conversation
that
we're
gonna
have
closest
to
the
hallway
conversation,
so
one
want
to
thank
again
all
the
panelists
and
really
want
to
thank
the
audience
for
the
questions
again
and
hope
to
see
you
all
in
person
in
north
america.
Thank
you
very
much.