►
From YouTube: CNCF SIG Network Intro & Deep-Dive - Lee Calcote, Layer5
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
CNCF SIG Network Intro & Deep-Dive - Lee Calcote, Layer5
“It’s the network!” is the cry of every system administrator, every developer. With the increased prevalence of microservice-based distributed systems, it’s true - networking as a discipline has never been more critical in the efficient operation of cloud native deployments. Networking primitives, including load balancing, observability, authentication, authorization, policy, rate limiting, QoS, mesh networks, legacy infrastructure bridging, and so on are now receiving substantial development and investment throughout the industry and are the subject of focus of the CNCF Network SIG. Join this talk for an intro to the SIG, its charter and a deeper discussion of current cloud native networking topics being advanced in this SIG. Current CNCF projects in-scope: CNI, CoreDNS, Envoy, gRPC, Linkerd, NATS, Network Service Mesh.
https://sched.co/alkB
A
A
We
do
that
by
trying
to
help
projects,
collaborate
and
interrelate
to
one
another.
By
seeking
to
clarify
and
inform
in
general,
we
aim
to
assist
our
existing
projects
and
attract
new
ones,
provide
people
a
venue
for
vendor
neutral
discussion
and
kind
of
advancing
of
of
thought
in
the
space
of
capabilities
in
the
space.
A
At
the
time
we,
you
know,
represented
cni
core
dns
envoy,
grpc,
linker
d,
nats
network
service
mesh,
which
was
a
fairly
recent
addition
at
the
time.
And
since
then,
we've
been
fortunate
enough
to
bring
in
five
more
projects,
four
of
which
are
at
a
sandbox
level
and
one
of
which
is
an
incubation
level.
So
bfe,
cni
genie
contour,
is
at
an
incubation
level,
kuma
and
service
mesh
interface.
A
A
Now,
outside
of
projects
that
call
the
sig
network
their
homeroom,
if
you
will,
the
netsig
network
also
facilitates
working
groups,
the
udpa
working
group
or
the
universal
data
plane
api
working
group,
the
service
smash
working
group.
We
also
are
well
actively
considering
trying
to
help
inform
in
general
and
might
do
so
through
some
white
papers.
There's
one
that's
been
written
and
is
referred
to
as
the
cloud
native
networking
principles.
A
There
are
also
any
number
of
patterns
and
reference
architectures
that
are
likely
to
come
out
of
some
work,
that's
being
done
inside
of
the
service
mesh
working
group,
the
sig
network
also
entertains
presentations
in
general
that
are
relevant
to
the
space
and
have
received
one
or
two
of
those.
There
was
an
interesting
one
given
not
too
long
ago
that
you
see
linked
here.
You'll
find
those
and
each
of
these
links
inside
of
what
is
it?
Github.Com
cncf,
slash,
sig
network.
A
So
there's
a
lot
that
gets
done
inside
of
this
group
and
more
that
we're
hoping
to
get
done
and
actually
some
of
what
we've
got
planned
for
between
now
and
next.
Cubecon
we'd,
really
like
your
input
on
not
just
your
input,
but
your
participation
like
for
you
to
bring
up
topics
and
meaningfully
impact
our
focus.
A
The
calls
that
we
have
are
twice
a
month
all
are
welcome
whether
you're,
you
know
your
organization
or
you
specifically,
are
a
member
of
the
cncf,
but
just
so
long
as
you've
got
interest
in
the
space.
Please
join
read
through
the
meeting
minutes
that
we
have
public
right
now
and
determine
whether
or
not
the
topics
that
we
have
currently
are
of
interest.
If
they're
not,
please
suggest
new
ones.
A
So
I
want
to
take
the
rest
of
the
time
that
we
have
together
to
review
some
of
the
initiatives
we
have
any
number
of
those
those
five
new
projects
which
are
all
unto
their
own
exciting.
We
also
have
the
service
mesh
working
group
that
is
advancing
a
few
different
initiatives
that
I'd
like
to
highlight
and
introduce
to
you
if
you're
unfamiliar
with
these.
A
The
part
of
the
common
goals
across
the
initiatives
that
I'm
about
to
describe
are
that
we
would
publish
some
results
from
these
studies
and
do
so
in
an
ongoing
fashion,
now
to
provide
a
little
bit
of
more
context
for
the
initiatives
that
are
going
forth
is
to
say
that
we
live
in
a
multi-mesh
world
and
so
the
initiatives
again
that
we're
talking
about
here
are
you
know,
executed
in
the
service
mesh
working
group,
and
so
hence
a
very
service
smash.
Centric
focus.
A
These
abstractions
have
arisen
because
it
is
a
multi-mesh
world
that
we
live
in
today
and
that
we
see
users
and
organizations
deploying
a
variety
of
meshes,
for
you
know
similar,
but
different
use
cases.
You
have
different
tools
for
different
jobs
and
so
different
service
meshes
for
different
jobs.
Because
of
that
we've
we
see
some
abstractions
some
apis,
that
work
across
service
meshes
and
and
help
them
either
interoperate
or
just
help
abstract
away.
A
A
A
A
In
order
to
validate
conformance
and
in
order
to
you
know,
do
so
and
well
in
order
to
do
so,
a
service
mesh
needs
to
be
deployed,
a
workload
needs
to
be
deployed,
a
sample
workload
onto
the
mesh
and
then
its
interfaces,
the
smi
interfaces
need
to
be
exercised,
and
so
the
tool
performs
those
things.
In
this
case
this
is
measury.
The
service
mesh
management
plane
is
working
in
conjunction
with
smi
and
its
specifications
deploying
a
sample
app
called
learn:
layer
5,
which
really
works
as
two
different
things.
A
A
Weeks
next
specification
is
the
service
mesh
performance
specification
or
smps.
It's
a
vendor-neutral
performance
standard
for
measuring
how
well
a
given
mesh's
implementation
is,
is
running
and
actually
answering
that
and
capturing
that
and
kind
of
describing
it
accurately
and
complete
holistically
it's
fairly
challenging.
There
are
a
myriad
number
of
variables
included
in
you
know
in
ascertaining
what
the
performance
of
a
given
mesh
is.
A
That's
highly
dependent
upon
what
the
environment
is
like
that
it's
deployed
in
how
many
nodes
there
are
how
many
clusters,
what
the
size
of
them
are,
what
resources
they
have
available.
What
very
what
mesh
you've
deployed?
What
version
of
the
mesh
you've
deployed?
What
workloads
are
running
on
the
mesh?
A
What
the
mesh
is
configured
to
do,
the
more
that
is
asked
of
it,
the
more
it
costs
to
run
it
costs
kind
of
with
quotes
this
particular
specification
and
describes
a
standard
way
of
capturing
those
all
of
those
details
that
we
just
mentioned,
and
also
providing
a
standard
way
of
reporting
a
statistical
analysis
of
load
that
has
been
generated
against
the
services
running
on
a
mesh
and
and
the
reporting
of
those
stats.
So,
there's
a
well
sort
of
there's
a
fair
bit
to
this.
A
It
does
directly
do
the
things
that
we
just
mentioned,
and
is
you
know
a
standard
way
of
of
doing
that?
It
does,
then
you
know
kind
of
on
top
of
this.
Spec
facilitates
a
few
different
things.
You
know.
Arguably,
most
importantly,
it
facilitates
end
users
having
a
common
way
to
baseline
their
environment,
benchmark
the
performance
of
their
mesh
as
they've
initially
deployed
it
as
it's
running
in
a
particular,
you
know
setup
and
then
over
time
as
that
environment
changes
as
their
configuration
of
the
mesh
changes
as
their
workloads
change.
A
That
they're
able
to
you
know,
use
this
standard
format
as
standard
spec
to
measure
surface
mesh
performance
again
and
again
it
facilitates
then
potentially,
comparing
you
know,
one
deployment
to
the
next
and
having
you
know,
it
facilitates
also
having
a
performance
index,
a
measurement,
a
unit
of
measure,
to
say
to
identify
how
well
you
know
how
well
a
given
service
mesh
is
performing.
So
I
guess
to
give
a
further
example
of
that
this
isn't
included
in
the
spec,
but
is
the
the
performance
index
that
I
was
just
mentioning?
A
There
is
one
that's
coming
around.
It's
called
mesh
mark
it
that
simple
index
that
I
was
just
referring
to.
So
it's
a
very
simple
way
of
quickly
articulating
the
performance
of
a
service
mesh
and
the
value
in
context
of
the
value
that
it's
providing.
If
you're
asking
the
mesh
to
do
a
lot
invoke.
A
number
of
you
know:
traffic
management
rules
if
you're
asking
it
to
you
know
encrypt
things,
traffic,
east
and
west.
A
Well,
that
affects
the
performance
of
the
mesh.
The
more
that
you
ask
it
to
do
the
you
know
generally-
and
this
isn't
always
the
case,
but
but
it
depends
on
your
deployment
and
and
and
your
environment
generally.
You
would
expect
that
you
have
to
you
know,
quote
unquote,
pay
more
for
that,
and
so
meshmark
is
an
easy
way
of
it's
a
way
of
providing
a
unit
of
value
so
that
you
can
speak
to
how
well
a
mesh
is
running.
Maybe
yours
is
running
a
mesh
mark
of
90.,
maybe
there's
a
similar
deployment.
A
A
The
unit
of
scale
is
still
to
be
hardened
and
and
completely
defined,
but
the
point
is
maybe,
between
these
two
different
environments:
you've
got
really
the
same
service
mesh
same
environment
in
terms
of
nodes
and
their
resources.
Maybe
you're
asking
one
to
do
more
than
the
next,
and
many
of
us
that
are
running
service
meshes.
Don't
necessarily
have
an
easy
way
to
gauge
whether
or
not
we're
we're
deriving.
A
You
know
the
value
that
we're
paying
for
that.
The
overhead
of
the
mesh
is
in
fact
worth
the
what
we're
getting
out
of
it
generally
it
most.
Certainly
is
that
case,
but
it's
really
hard
to
articulate
and
compare
and
understand
and
reason
over
whether
or
not
you've
got
your
service
mesh
tuned
in
the
right
way.
A
This
one
has
to
do
with
really
a
recognition
of
the
fact
that
we
are
well.
Many
of
us
are
running.
You
know
essentially
distributed
systems,
we're
running
microservices
and
you
know
potentially
plenty
of
them
and
the
analysis
that
you'll
often
see
about
understanding
the
performance
and
kind
of
the
yeah.
The
behavioral
characteristics
in
terms
of
performance
of
a
given
set
of
microservices
is
usually
done
from
sort
of
a
single
instance
of
a
load.
Balancer.
A
A
load
generator
excuse
me,
so
you
might
generate
load
against
in
one
one
load:
generator
oftentimes
a
closed
loop
load
generator
might
be
creating
a
bunch
of
http
traffic
pointed
at
a
particular
endpoint
pointed
at
a
particular
service
and
that's
provide,
and
you
can
analyze
the
behavior
of
those
services.
You
can
analyze
their
response
time,
their
latency.
You
know
the
throughput
that
they
receive,
but
that's
maybe
missing
part
of
the
point
of
the
fact
that
we
are
running.
A
You
know
we
collectively
running
distributed
systems
and
so
shouldn't
our
performance
analysis
also
be
distributed
shouldn't.
We
also
have
multiple
instances
of
load
generators
hitting
various
endpoints
of
your
different
microservices,
you're,
well,
micro
or
not,
but
hitting
different.
You
know
endpoints
of
your
services
and
then
doing
analysis
of
each
of
those
loads
that
were
generated
how
they
responded
coalescing
those
results
so
there's
an
ongoing
project.
A
Now,
that's
working
with
the
nighthawk
load
generator
of
the
envoy
project
and
pulling
that
and
then
doing,
using
that
its
capabilities,
enhancing
its
capabilities
in
context
with
the
service
mesh
management,
plane
meshery,
which
already
supports
two
other
types
of
load:
generators,
wrk2
and
fortio,
and
and
also
supports
nighthawk
now,
but
will
support
it
in
a
distributed
fashion.
So
an
interesting
project
we're
expecting
some
some
novel
results
so.
A
With
that
I'll
make
another
call
for
participation
and
say
these
are
open
projects.
If,
if
you
find
that
those
are
of
interest,
those
are
a
sampling
of
initiatives
that
are
taking
place
in
context
of
the
service
mesh
working
group
inside
of
sig
network
sig
network
itself
is
much
bigger
in
scope
than
those
four
projects.