►
From YouTube: Container Networking Untangling Services Meshes and SDNs - Gregory Elkinbard, GSE Software
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Container Networking Untangling Services Meshes and SDNs - Gregory Elkinbard, GSE Software
Horizontally scalable applications need reliable and scalable networking, traffic routing to the correct instance and security policy enforcement. Traditionally SDNs have delivered these functions. However recently Service Meshes began to encroach on the tranditional SDN space. This presentation will compare 3 services meshes Istio, Linkerd and Conduit vs a more traditional SDN such as OpenContrail in the Kubernetes cluster environment. We will go over the features of each one of these products and compare their Kubernetes integrations against each other.
To learn more click here: https://sched.co/FuKa
A
All
right
folks,
I
know
people
are
trickling
in,
but
in
the
interest
of
time
let's
go
ahead
and
get
started,
so
the
today's
talk
is
going
to
cover
container
networking,
especially
the
service
mesh
in
SDM
area.
Oh
the
agenda
for
today
is
I'm
going
to
introduce
what
a
service
mission
Sdn
is.
A
lot
of
you
probably
already
know
what
it
is,
but
just
in
case
some
of
you
don't
to
get
us
all
on
the
level
playing
field.
A
I'm
going
to
provide
an
overview
of
a
couple
of
service
meshes
specifically,
is
show
and
linker
D
special
link
of
D
2.0.
There
was
no
point
in
looking
at
the
old
linker
D
since
the
project's
have
merged
the
Sdn
overview.
I'll
focus
on
some
fabric,
mostly
because
I'm
familiar
was
that
one.
But
what
I
tell
you
about
some?
Some
fabric
is
transportable
to
most
soft
overlay
as
the
ends,
including
nsx
and
nuage.
Okay,
and
then
we'll
talk
about
the
coexistence
between
service
meshes
and
as
the
ends
and
wrap
up.
The
presentation
was
few
conclusions.
A
I
drew
all
right.
So
what
is
a
service
mesh
service?
Mash
is
an
infrastructure
layer.
That's
responsible
for
handling
service
to
service
communications.
It
operates
in
a
very
abstract
and
complex
environment
where
there
could
be
multiple
infrastructure
providers
and
its
goal
to
provide
an
end-to-end
communication
for
all
of
them.
It
must
deliver
a
reliable
requests
across
a
very
complex
topology,
possibly
multi
data
center
multi
cloud,
hybrid
clouds
and
everything
else.
A
A
When
somebody
mentions
service
mesh,
it
is
scalable
very
feature-rich
and
it's
best
based
on
an
Android
proxy
and
a
control
plane
for
the
invoice
written
by
pallet
and
mixer
and
voice
and
production
and
number
environments,
and
it
shares
commercially
supported
by
a
number
of
vendors
I
believe
including
a
5
wrench
or
a
few
others.
So
conduit
and
linker
D,
so
linker
D
was
one
of
the
original
production
service
meshes
for
the
kubernetes
environment.
But
it
looks
like
the
sponsor
of
the
project
developed.
A
new
shiny,
new
toy
called
conduit
merged.
A
It
turned
it
into
linker,
D
2.0.
So
now
you
have
a
very
low
footprint
very
fast,
but
a
significantly
newer
and
far
less
proven
environment
with
linker
D
2.0
I'm
gonna,
throw
in
console
Baja,
Shi
Corp,
which
started
this
whole
service
mesh
thing
way
before
kubernetes
was
even
on
horizon,
so
the
conduit
sorry
console
was
designed
as
a
global
service
mesh.
It
was
designed
to
run
completely
independent
of
the
underlying
infrastructure
and
can
support
absolutely
anything.
A
Multi
datacenter,
hybrid
clouds
and
everything
you
have
so
it
still
is
in
existence,
is
still
supported
by
hasha
Corp
hasha
recently
provided
kubernetes
adapter,
so
now
works
with
kubernetes
environments
as
well.
Alright.
So
now,
let's
jump
into
the
SDS
Sdn.
Well,
the
definition.
It's
a
it's:
a
separation
between
a
control
plane
and
a
forwarding
plane
by
the
way
these
slides
are
on
the
web.
A
So
you
probably
don't
have
to
take
a
picture
of
every
single
one
of
them,
although,
if
you
want
to
you,
can
ok
I
did
upload
the
slides,
so
these
slides
are
available.
Ok,
so,
but
as
the
ins
involved,
it's
original
definition
and
they
evolved
thus
clouds
and
virtualization
so,
which
means
that
nowadays,
as
the
ends
are
responsible
primarily
for
virtual
network
creation
and
virtualization
of
the
network
infrastructure,
some
of
the
SDNS
do
still
control
physical
infrastructure.
Although
those
are
a
little
bit
more
rare
than
simply
virtual
network
providers.
A
The
primary
job
of
the
Sdn
is
to
provide
the
on
a
node
and
on
the
wire
segregation
of
traffic
in
a
multi-tenant
environment,
up
in
the
virtualization
and
container
based
environments,
although
some
of
the
SDNS
nowadays
breach
into
the
bare
metal
support
underlying
infrastructure,
programming
and
everything
else,
so
most
of
us
DMS,
because
they
are
commercial
they're,
designed
to
deliver
more
than
just
basic
packet,
forwarding
as
you'll
see
in
the
tunnel
fabrics
use
case,
it's
relatively
few
each.
So
in
the
kubernetes
context,
Sdn
is
a
CNI
provider.
A
So
if
you're
familiar
with
CNI,
you
just
deploy
the
cni
plugin
and
it
links
you
to
the
appropriate
SDM.
All
right.
Let's
go
through
some
of
the
examples
of
the
SDNS
we
have
calico
and
together.
This
is
open
source
and
commercially
supported,
l3
Sdn
and
it
is
l3
only.
It
has
very
little
support
for
tunneling.
It
can
tunnel
selectively,
but
most
people
simply
use
it
as
an
l-3
forward,
which
means
that
there
is
no
l2
emulation
built
in
it
works
great
with
cloud
native
applications.
A
If
you
have
more
legacy,
applications
that
require
virtual
l2
support
and
you
probably
better
off
looking
at
a
different
SDM.
It's
essentially
it's
a
bgp
packet
forwarder,
whereas
the
local
linux,
firewall
enforcement
security
and
a
control
plane
that
distributes
the
security
rules
across
the
network,
it's
nothing
more
than
that.
It
works,
works
relatively
well
scales
to
about
thousand
notes,
deployed
a
number
of
environments,
so
the
next
one
is
tensile
fabric
tensile
fabric
is
the
project
name,
Cantrell
is
the
product
name.
So
Cantrell
is
the
open
source
and
commercially
supported.
A
L2
and
l3
SD
n,
which
means
Cantrell,
is
capable
of
creating
virtual
l2
networks.
Support
for
broadcast
multicast
unknown
packets,
everything
that
you
would
expect
in
an
l2
environment,
its
feature-rich.
It
has
extensive
security
policy
mechanism,
it
has
service
function,
chaining,
several
types
of
built-in
load
balancing,
including
ECM,
P
and
H;
a
proxy
based
service
load
balancing
and
includes
IPM,
a
bunch
of
other
services.
It
supports
virtualized,
bare
metal
environments
and
containerized
environments
supports
hybrid
public.
A
Private
clouds,
wherever
wherever
you
want
to
its
goal,
is
to
be
a
single,
consistent,
Sdn
platform
delivering
as
DNN
security
and
it's
in
version
5.
It
has
a
large
number
of
commercial
deployments,
lots
of
them
on
a
telco
sectors.
Enterprise
gaming
sectors,
in
other
words
folks,
who
run
at
significant
scale
and
have
significant
performance
needs.
Next
one
is
nsx:
nsx
is
a
sold
by
vmware.
It
is
commercial,
only
Sdn,
it's
primarily
designed
as
an
virtual
l2
Sdn,
so
it
will
always
tunnel.
So
it
is
feature-rich.
A
A
It
does
support
a
virtualized
bare
metal
and
containerized
environments
nowadays
in
a
sexist,
primarily
associated
either
with
VMware
centric
environments
or
hybrid
environments
that
involve
VMware.
It
works
on
VMware,
very,
very
well.
Oh
VMware
sometimes
does
make
an
effort
to
make
it
a
more
cross
up
across
environment
Sdn
such
as
the
latest
ones,
NSX
transformers.
Sometimes
it
was
drawers
that
support
so
be
as
it
may.
Nuage
is
probably
the
closest
as
the
end
to
Johnston
fabric
and
contrail.
It's
another
overlay.
As
the
end.
A
It
does
only
do
virtual
l2
only
and
its
feature,
which
it
has
security
policy
service
function,
chaining
load,
balancing
everything
you
would
ever
thing
that
you
would
expect
from
and
as
the
end
that
needs
to
support
telco
great
environments,
it's
primarily
different
primary
differentiation.
It
actually
runs
a
bgp
router
on
every
single
node,
so
it
has
a
little
bit
heavier
footprint
on
a
node
than
some
some
fabric.
It
also
uses
a
commercial
version
of
OBS
for
its
fast
data
plane,
while
tungsten
fabric
provides
its
own
custom
written,
be
router
data
plane.
A
There's
a
lot
of
other
SD
ends
out
there.
If
I
had
to
give
you
guys,
of
course,
and
Sdn
will
probably
take
a
rest
of
the
week,
there
is
a
CI
from
Cisco
weave,
which
works
relatively
well
with
kubernetes
ODL,
which
is
one
of
the
biggest
open-source
projects
out
there,
supported
by
a
large
number
of
commercial
vendors
as
well.
So
this
list
is
by
no
means
exclusive.
It's
a
very
it's
a
very
competitive
space.
There
is
lots
and
lots
of
folks
who
want
to
play
there.
A
Okay,
so
let's
dive
into
sto
so
and
go
through
its
core
features.
So
SEO,
like
I
mentioned
before,
is
very
feature-rich.
It
supports
traffic
management,
was
extensive,
routing
and
load
balancing.
It
has
load
balancing
policies
right
now.
It
I
believe
it
has
three
load
load
balancing
policies,
it
supports
circuit
breakers,
timeouts
retries,
in
other
words,
everything
that
you
would
expect
from
a
layer,
seven
load
balancer,
because
ultimately
it
is
designed
around
a
proxy
based
service
which
is
a
in
the
old
parlance
layer,
seven
load
balancer.
A
It
has
security
with
encryption,
authentication
and
authorization.
It
will
support
transparent
on
the
wire
encryption.
So
your
application
does
not
need
to
worry
about
encrypting
packets
on
the
wire
is
designed
to
run
on
untrusted
networks.
It
supports
machine
to
machine
authentication
where
certificates
it
supports
to
person
to
machine
authentication
and
authorization.
The
policies
that
supports
our
pluggable
and
very
extensive.
A
The
next
component
is
responsible.
So
up
for
observability
with
tracing
monitoring
and
logging,
there
is
a
boatload
of
plugins.
If
you
have
your
favorite
logging
and
monitoring
back-end
chances
are
mix
already
supports
it.
If
not
it's
relatively
trivial,
for
you
to
create
a
back-end.
So
we'll
cover
mixer
in
a
little
bit
more
detail
later
on.
So
this
is
a
multi-platform
environment.
Although
it's
associated
with
kubernetes,
it
will
work
with
mezzos.
It
will
work
with
VMs
it'll
work
with
many
different
environments
just
with
kubernetes.
It
works
a
lot
nicer
because
it
can
discover
the
kubernetes
environment.
A
A
So
now
it
is
configurable.
Well,
it's
a
evolved
with
envoy
proxy.
You
can
add
an
arbitrary
proxy
in
front
of
it.
So
right
now,
envoi
is
running
very
nicely
very
scalable
and
lots
of
production
environments,
so
folks
do
not
see
a
need,
but
if
you
have
your
favorite
proxy
chances
are
you
can
plug
it
in
the
mixer
supports
extensive
plugin
interface
and
then
the
authorization
of
indication
engines
support
plugins
as
well.
So
you
can
customize
your
SEO
environment
to
whatever
level
you
want,
you,
okay,
why
am
I
okay
architecture
all
right?
A
So,
let's
quickly
go
through
the
architecture
of
this,
and,
as
I
mentioned
before
written
around
in
my
proxy,
the
control
plane
is
called
pilot.
The
telemetry
integration
is
mixer,
Citadel
is
the
secrets
keeper.
It
provides
authentication
and
authorization.
There
is
a
relatively
new
project
called
galley
which
keeps
the
configuration
so
pilot
an
invoice.
So
this
is
the
Kaurava
CEO
invoice
written
as
a
very
fast
proxy.
It's
written
in
C++
right
now.
A
We
benchmarked
it
around
3k
packets
per
3k
requests,
I
should
say
per
second
3
3k
transactions
per
second,
not
packets,
and
then
obviously
depends
on
the
hardware
environment.
So
your
mileage
may
vary.
It's
roughly.
This
end
to
end
service
on
envoi,
which
does
go
through
2
proxies
because
it's
deployed
as
a
sidecar
on
all
of
your
pods
is
about
10
milliseconds.
So
if
you're
running
a
voice
grade
or
a
talker
grade
application,
you
probably
need
to
consider
this
for
control
plane
only
as
opposed
to
data
plane.
A
It's
deployed
the
site
are
on
every
single
part
and
it
does
provide
an
ingress
egress
controller.
So
it's
a
very
complete
solution.
The
control
plane
is
called
pilot.
It's
job
is
keep
state
and
configure
and
boy.
It
does
support
service
auto-discovery.
We
are
plugins
primarily
into
the
kubernetes
environment,
so,
as
I
mentioned
before,
is
still
designed
to
run
in
an
untrusted
environment
or
across
trusted
and
untrusted
environments
with
relative
degree
of
complexity.
So
it
has
lots
of
pluggable
authentication
schemes.
So
what?
A
If
you're
running
into
the
public
cloud,
you'll
support,
Google
and
AWS
authentication
if
you're
running
kubernetes,
you
will
integrate
with
kubernetes
based
off
its
ok?
Its
certificate
infrastructure
is
based
on
spiky,
I'm,
probably
mispronouncing,
that
relatively
badly.
But
you
have
the
acronym
there.
It's
not
quite
compatible
with
other
open
spiky
environments,
so
it
uses
PI
fee
based
certificates,
but
most
common
implementation
of
spie
fee
is
not
quite
compatible
with
what
SEO
did
on
its
own
mutual
TLS,
including
on
the
wire
encryption.
A
That's
configurable,
you
can
just
put
it
into
your
into
your
config
file
and
all
of
a
sudden
you
can
just
dynamically
encrypt
packets
on
the
wire.
The
policies
for
Arthur,
ization
and
dedication
are
very
extensive
right.
You
can
write
them
at
multiple
levels
and
confuse
yourself
to
the
world
no
end,
but
my
suggestion
is:
keep
it
simple
to
start?
Okay,
so
mixer,
it's
an
interesting
component.
Is
it
actually
works
as
both
a
distributed,
cache
that
on
your
pods
and
a
centralized
control
plate
that
carries
out
all
of
your
telemetry
to
the
telemetry
backends?
A
So,
unlike
conduit,
sto
is
designed
to
integrate
into
your
existing
market.
Environments
are
supposed
to
introduce
a
new
one,
so
it
has
lots
of
back-end,
as
you
can
see.
Well,
the
list
actually
goes
on
to
about
30
different
backends
didn't
fit
on
the
slide,
so
I
picked
the
most
popular
ones:
data
dog,
Prometheus,
fluency,
stats,
the
cloud
watch.
The
list
goes
on
for
about
two
pages
and
it's
relatively
easy
to
provide
your
own.
A
So
the
interesting
thing
is:
it
does
policy
caching,
which
means
80%
of
your
decisions.
Intelligent
decisions
are
going
to
be
made
on
the
part
itself
without
ever
going
to
the
centralized
control
plane,
and
then
it
has
a
fast
and
scalable
control
plane
that
can
render
policy
decisions
relatively
fast.
It
will
buffer
requests,
so
it
reduces
the
amount
of
traffic
to
the
backend
right.
So
you
can
batch
transactions.
A
Okay,
so
next,
let's
quickly
go
through
linker
D
2.0,
which
is
conduit,
so
it's
written
as
an
integrated
product
from
scratch.
It
provides
everything
you
need
to
proxy
control,
plain
UI,
monitoring
and
dashboarding.
It
was
written
to
overcome
some
of
the
problems
of
the
old
linker
D,
especially
in
being
very
low
memory
and
very
fast.
A
So
it's
designed
to
be
very
easy
to
deploy
in
essentially
other
configures
itself,
which
means
that
has
a
lot
of
a
lot
less
knobs
that
you
can
tweak
then
SEO.
At
the
same
time,
it's
easier
to
get
started.
Okay,
security
and
everything
else.
Unfortunately,
still
work
in
progress.
Tls
is
only
in
the
experimental
phase.
Okay,
it
is
less
as
I
mentioned,
it
is
less
configurable.
A
lot
of
security
is
still
work
in
progress.
A
A
Okay,
so
it's
architecture,
so
you
have
a
fast
compact
compact
data,
plane,
proxy
written
and
rust.
Sorry
I'm
not
rust,
programmer
supposed
to
be
this
great
language
that
prevents
Stack
Overflow
and
it's
really
fast
never
used
it,
but
the
results
is
a
proxy
that
can
do
a
sub
millisecond
transaction.
Now
this
is
measured
slightly
differently.
This
is
request
flow
through
a
single
proxy,
as
opposed
to
end-to-end
test
right.
So
it's
not
quite
an
order
of
magnitude
faster
than
envoi,
it's
probably
about
to
3x
faster
than
Android.
A
So
the
control
elements
are
written
in,
go
as
with
a
lot
of
kubernetes
stuff.
It
does
provide
a
web
dashboard
api
service.
It
has
an
integrated
monitoring
engine,
it
uses
Prometheus
from
CN
CF
as
its
monitoring,
and
it
does
provide
an
extensive
dashboarding,
the
fauna.
It
comes
with
lots
of
dashboards,
be
configured
in
addition
to
that.
Yet.
A
A
Let's
use
some
synthetic
as
the
example
as
I
mentioned
before.
Jocelyn
fabric
is
very
feature-rich.
It
has
support
for
routing
and
switching
a
virtual
router
in
virtual,
switching
obviously
at
ipv4
and
ipv6.
It
provides
extensive
network
services,
IBM
DNS
DHCP,
esnatt,
QoS
bgp
as
a
service.
The
list
goes
on.
A
There
is
two
types
of
load:
balancers,
there's
an
e
CMP
load,
balancing
for
vnf
style
workloads,
which
will
use
BGP
to
send
traffic
in
whatever
rules
that
you
want
to
encode
in
BGP
to
a
set
of
transparent
network
services,
there's
also
built
in
distributed
H
a
proxy
it's
fully
distributed.
So
the
it's
not
relying
on
scaling,
one
single
instance
of
a
she
a
proxy
or
a
cluster.
There's
a
version
there's
an
instance
of
H,
a
proxy
Runyan,
every
single
node
with
a
very
fine
distribution
of
the
responsibility.
So
it's
truly
distributed
load
balancing.
A
It
has
very
extensive
security
policies
that,
unfortunately,
I
won't
be
able
to
get
to
in
this
slide
deck,
but
take
a
look.
There
intend
based
policies,
really
cool.
They
simplify
configuring
up
security
across
high
hybrid
and
complex
cloud
environments,
so
performance
scalability,
yes,
is
designed
as
a
taco
grade
as
DM,
so
sub-millisecond
packet
forwarding
everything
that
you
could
possibly
want.
A
Dpd
case
support,
directed
CeraVe
support,
smart
NIC
support
and
it
does
scale
a
couple
thousand
nodes
out
of
the
box,
probably
five
to
eight
thousand
nodes.
If
you're
careful
and
use
the
commercial
Jennifer
version,
it
provides
extensive
gateway
services,
l2
ll3,
both
software
and
hardware,
is
supported.
You
can
use
routers
or
switches
anything
that
can
support
a
VPN
in
the
latest
version
can
be
used
as
its
outbound
l2
and
l3
gateway.
A
It
has
rich
analytics
of
its
own,
it
does
have
its
own
analytics
collection
and
analysis
engine,
so
it
perhaps
is
a
little
bit
more
complex
to
integrate
it
into
your
existing
environments
such
as
Prometheus.
Although
I
believe
some
people
have
started
to
look
into
how
to
do
that,
it
has
service
function,
changing
so
transparent
service
function.
Changing
that
allows
you
to
redirect
traffic
between
any
two
VMs
or
containers
to
a
third-party
endpoint
to
do
in-line
security
analysis
thread,
detection
load,
balancing
whatever
have
you?
Okay,
it's
fully
a
chaise
supports.
A
Upgrades
supports
API
works
with
many
different
orchestrators.
The
list
of
features
goes
on
and
on
basic
or
basic
architecture.
There
is
an
orchestration
layer
and
that
talks
to
the
controller,
the
controller
runs.
All
of
the
configuration
provides
control
points
that
program
the
individual,
the
router
endpoints,
and
it
provides
an
analytic
sync.
Cassandra
is
used
as
a
distributed
database
for
configuration
and
analytics
there's
actually
two
different
instances
of
Cassandra
just
for
the
reliability
sake,
one
for
the
config
one
for
the
analytics.
A
If
its
base
level,
it
is
an
overlay
Sdn,
it
supports
the
X,
LAN
and
MPLS
over
UDP
and
GRE,
although,
since
version
5,
we
introduced
a
new
mode.
If
you
don't
want
to
take
the
penalty
of
an
overlay,
there
isn't
that
much
penalty,
but
some
people
just
have
a
concern.
You
can
just
dump
the
packets
onto
the
wire,
in
which
case
you
lose
multicast
broadcasts
capabilities,
but
the
packets
are
directly
accessible
on
your
local
network
without
any
telling
protocol
and
always
on
any
tunneling
overhead.
A
So
we
did
write
BNE
router
as
the
data
engine.
It
is
a
true
router,
unlike
OBS,
so
it
does
make
routing
decisions.
It
operates
on
l3
set
of
rules.
Although
the
rules
are
distributed
to
it.
We
are
XMPP
just
to
be
a
little
bit
more
compact,
as
opposed
to
BGP.
The
control
plane
is
the
bgp
peering
endpoint,
okay.
So
now,
let's
cover
service
meshes
and
as
DNS
okay
and
where
it
makes
sense
to
integrate
them.
So
you
notice
that
one
thing
was
missing
from
the
linker
D
presentation:
that's
the
ingress
controller.
A
It
doesn't
have
one,
it
relies
on
the
built-in
one.
So
there
you
can
have
things
like
just
a
fabric
or
nuage
provide
a
scalable
ingress
controller
so
for
sto,
we're
very
nicely
using
ecmp
can
scale
out
the
issue
of
ingress
controller.
So,
instead
of
3,000
requests
per
second
on
your
inbound
and
web
proxy,
you
can
run
a
bank
of
android
proxies
and
scale
n
to
whatever
you
want
to
for
things
that
do
not
have
a
built-in
ingress
controller
provides
an
HT
proxy
it
and
distributed
HT
proxy
at
that.
So
it
was
virtually
no
bottlenecks.
A
So
it's
a
traffic
engine
it
goes
typically
beyond.
Iptables
was
an
interesting
set
of
forwarding
and
programmable
security
rules.
There
is
many
different
implementations
of
the
traffic
engines.
The
router,
photons
and
fabric
is
one
of
them.
I
advisor
exists
and
it's
relatively
nice.
Bnf
parser
and
OBS
is
one
of
the
biggest
open
source
projects
for
data
plane
out
there,
but
there
is
other
things
like
swap
switch
and
other
programmable
traffic
movers.
Thank
you,
okay.
So
as
you
integrate.
A
Service
meshes
and
Sdn
s--,
you
notice
that
they
address
security
from
slightly
different
endpoints.
So
it's
the
addresses
security
as
authentication
and
authorization
at
the
service
level,
while
the
SD
ins
can
be
used
as
you're,
essentially
elf
or
firewall,
on
a
node
to
protect
internal.
So
you
gain
security
and
depth
by
deploying
an
SDN
and
service
mesh
together,
and
then
you
get
so
essentially
get
a
micro
segmentation
based
firewall
on
the
node,
protecting
you
and
trying
out
all
of
the
environments,
not
just
one
specific
service.
A
It
makes
it
a
little
bit
more
challenging
to
hack
into
individual
nodes.
Not
everything
is
a
web
service
right.
So
not
everything
is
written
to
operate
in
HTTP
or
TCP.
So
you
may
be
running
some
cell
complications
which
may
want
to
run
arbitrary
traffic,
including
even
UDP,
and
sometimes
you
do
need
voice
grade
traffic
or
video
grade
traffic
with
some
microsecond
latency,
and
for
that,
as
the
ends
work
a
lot
better
than
service
meshes.
A
There's
lots
of
alternative
approaches,
so
this
is
a
reference
to
the
Intel
motifs
there's
also
network
service
mesh
project
was
in
kubernetes
itself,
which
is
the
second
reference.
I.
Do
encourage
you
to
go
look
at
both
of
those
okay,
so
pain
points,
obviously,
as
the
ends
bring
in
additional
control,
plane,
complexity
and
because
the
policy
engines
are
disconnected,
you
do
have
several
policy
points
to
manage,
and
then
you
have
a
logging
monitoring
integration
challenge,
because
a
lot
of
them
came
come
with
their
own
monitoring
solutions.
A
So
conclusions
you
will
you
will
need
something
you
will
need
a
CNI
provider.
So
what
you
need
to
do
is
you
need
to
pick
a
CNI
provider
that
offers
minimum
complexity
for
the
type
of
problem
that
you
need
to
solve?
In
other
words,
if
all
of
your
traffic
is
going
to
be
HTTP
services,
then
you
possibly
don't
need
and,
as
the
end
up
provides
service
function
chaining
and
you
have
to
look
at
your
traffic
management
policies.
A
A
B
A
They
are
and,
and
the
console
is
competing
against
them-
yes,
one
or
the
other.
So
if
fast,
New
Kids
on
the
Block
link
ad
2.0
or
something
that
has
a
lot
of
mass
behind
it,
which
end
is
very
advanced,
feature
set
very
programmable,
which
is
SEO,
so
Google
supports
SEO.
So
that
gives
it
a
lot
more
weight
than
potential
options.
B
A
Okay,
so
both
nuage
and
tungsten
fabric
essentially
run
their
own
namespace
and
then,
when
you
create
the
virtual
network,
they
will
do
all
of
the
management
for
you.
You
do
need
to
set
up
peering
with
the
rest
of
your
with
the
rest
of
your
networking
environment,
so
at
the
termination
endpoints
you
do
need
to
set
up
forwarding.
The
instructions
are
provided
for
both
of
these.
So
yes,
you
do
need
to
specify
the
appropriate,
namespaces
and
other
things.
A
So
the
bgp
instructions
are
a
little
bit
beyond
the
30
seconds
we
have
left,
but
they
are
provided
in
the
integration.
But
typically
the
creation
of
the
virtual
network
requires
nothing.
They
both
operate
on
a
dumb,
underlay
mode
right,
you
create
a
static
underlay
and
then
the
SD
ends
will
manage
the
entire
overlay
and
I
think
I'm
being
kicked
off
the
stage.
So
that
was
the
last
question.
Thank
you.
So
much.