►
From YouTube: Multicloud Vitess over Network Service Mesh - Tim Swanson, Cisco & John Watson, PlanetScale
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.
Multicloud Vitess over Network Service Mesh - Tim Swanson, Cisco & John Watson, PlanetScale
This talk will describe using Network Service Mesh to create a private L3 network between Kubernetes clusters in different cloud providers to seamlessly deploy multiple Vitess cells across them. We will describe a multicloud Vitess use case and walk through the deployment details, highlighting the networking requirements in the process. We will describe NSM’s inter-domain feature and multicloud capabilities and a network service which fulfills the Vitess multicloud networking requirements by dynamically forming a common private L3 routing domain to interconnect specific workloads hosted in multiple clouds.
https://sched.co/ZejK
A
A
So
today
we're
going
to
go
through
the
integration
of
the
test
with
network
service
mesh
and
virtual
layer
3
deployment.
So
we're
going
to
start
off
by
highlighting
the
pertinent
use
cases
for
why
you
would
want
to
integrate
with
these
two
comp
these
two
projects
and
then
we're
going
to
describe
the
tessa's
architecture.
B
The
tessa's
core
philosophy
is
to
facilitate
the
scaling
of
applications
by
managing
the
complexity
of
scaling
databases
with
little
to
no
interference
with
application
development.
For
example,
the
tess
multi-cloud
can
be
used
to
efficient
effortlessly,
provide
a
homogeneous
interface
to
your
database
in
any
cloud
provider,
thus
preventing
vendor
lock-in,
while
increasing
the
availability
and
durability
of
the
database
too.
B
B
B
B
B
B
The
test
relies
on
the
networking
provided
by
the
infrastructure
it's
deployed
on
in
the
case
of
crew
readies,
that's
the
cni
of
the
cloud
provider
and
it's
pod
for
multi-cloud
networking.
We
need
to
securely
connect
multiple
connectivity
bands
together,
unfortunately,
applying
an
organization's
networking
and
security
requirements
usually
entails
toil,
since
it
requires
using
a
cloud
specific
apis
and
per
kubernetes
cluster
network
policies
to
allow
access
to
only
specific
workloads.
A
A
So
this
brings
up
what
what
is
msm
really
so
nsm
in
a
nutshell,
is
managing
connections
between
clients
and
client,
workloads
and
network
services
that
are
provided
by
one
or
more
network
service.
Endpoints
and
network
service.
Endpoints
are
the
abstraction
in
the
nsm
world
for
different
types
of
network
functions.
So,
as
a
network
function
provider
you
can
perform
you
can
you
can
implement
a
network
service
endpoint
and
have
a
administrator
provide
that
as
a
network
service
to
any
of
the
client
workloads
in
in
their
domain,
their
nsm
deployment.
A
A
It
consults
a
network
service
registry
to
just
to
find
any
endpoints
that
are
registered
for
that
type
of
network
service
and
it
decides
which
network
service
endpoint
that
it
got
back
from
the
registry
to
to
to
connect
the
client
to,
and
then
it
it's
forwards.
The
request
to
the
network
service
endpoint
that
it
shows
and
if
every
and
then
it
negotiates
the
connection
parameters
and
does
the
actual
connection
set
up
to
the
client.
A
Does
the
the
actual
lookup
of
the
nses
for
that
network
service
chooses
which
nse
and
then
forwards
the
request
to
the
ns
manager?
That's
local!
To
that
nse
and
that
ns
manager
will
then
forward
the
request
to
the
actual
nsc,
so
there's
there's
kind
of
layers
of
connection
parameters
being
also
exchanged.
Here.
A
The
clients
are
saying
what
type
of
connection
that
they
would
would
be
able
to
handle,
and
the
ns
managers
are
saying
are
indicating.
What
kind
of
connections
that
can
go
between
the
nodes
and
like
a
vxlan
tunnel
or
in
the
actual
ns
manager
on
the
node
to
the
nsc
is
also
in
negotiating
their
side
of
the
connection.
So
there
there's
a
lot
of
connection
parameter
exchange
in
this
flow
and
that
that's
a
lot
of
that
provides
a
lot
of
power.
You
can
see,
there's
no
centralization
here.
A
A
So
it's
from
the
point
of
view
of
the
client
workload
pods
and
it's
connecting
to
the
the
pier
its
peer
nses,
so
the
other
types
of
the
other
vl3
nfcs
in
the
inter-domain
environment,
it's
connecting
to
those
via
nsm,
so
it's
using
nsm
to
find
the
other
ones
other
peers
and
it's
using
so
using
ns.
The
network
service
registry
for
for
that
purposes
and
then
using
nsm
inter-domain
connection
setup
to
connect
to
its
peers
and
exchange
l3
route,
information
and
ipam
information.
A
So
the
model
is,
is
pretty
in
this
picture
in
this
picture,
we're
trying
to
show
the
the
same
flow
but
with
the
l3
nse
as
the
specific
how
it
specifically
works.
So
in
the
in
the
case
of
the
vl3
and
nse,
we
have
a
annotation
the
same
model
where
we
apply
an
annotation
for
a
network
service.
The
dating
notation
corresponds
to
the
actual
connectivity
domain
network
server
of
the
network
service.
A
So
in
this
case
it's
the
connectivity
domain
called
green
and
that
that
nse,
that
it's
connecting
to
has
a
mapping
of
of
of
that
is
configured
to
connect
to
the
network
service
registry
for
that
connectivity
domain.
So
that
network
service
registry
knows
about
the
other
nses
in
the
connectivity
domain,
and
when
that
happens,
when
that
connection
happens
from
the
client,
the
nse
will
find
the
other
nfcs
that
are
in
that
connectivity
domain
and
trigger
connection
requests
to
form
the
actual
peering
between
the
other
nses.
A
So
connectivity
domains
are
a
totally
an
opt-in
approach
to
to
connect
to
joining
to
multi-cloud
connectivity
there.
Only
the
workloads
that
are
part
of
the
connected
activity
domain
are
a
part
of
that.
So
there's
no
need
for
extra
multi
inter-cluster
network
policy,
so
this
is
now
we're
going
to
transition
into
the
how
the
tess
and
nsm
are
integrated
with
the
virtual
layer,
3
nses,
so
like
in
the
previous
slide.
With
about
the
with
the
example
for
the
nfcs,
we
have
now
of
the
test
deployment.
A
That's
that's
in
the
connectivity
domain,
that
is
between
multiple
clusters
and
the
test.
Deployment
has
multiple
pods
and
there's
multiple
reasons
for
those
pods
to
be
able
to
communicate
with
the
other
clusters
instances
of
different
pods.
So
all
of
those
in
our
in
the
deployment
are
all
the
content
in.
In
these,
the
tests
deployments
are
a
part
of
the
connectivity
domain
and
then
the
connectivity
domain
also
has
some
additional
services
like
dns.
A
A
So
this
is
a
kind
of
a
breakout
of
which
the
pods
are
deployed.
Where,
in
in
this
example,
the
the
planet
scale
operator
deploys,
vtga
vt
tablet
in
in
both
clusters,
put
it
at
xcd
in
a
single
cluster
and
the
vt
gates
can
reach
either
any
vt
tablet
so
that
that
kind
of
fulfills
your
data
location,
use
case.
So
since
you
can
localize
shards
or
tables
according
to
your
regulations,
location
regulations
and
then
the
vt
tablets
can
reach
each
other
across
the
connectivity
domain,
and
that
would
solve
your
data.
A
A
A
So
the
details
of
this
demo
are
a
two
kubernetes
cluster
setup
with
nsm
installed
the
nse
control
services
that
I
showed
in
the
previous
slide,
where,
with
for
dns
and
ipam
and
and
the
registry,
are
in
a
third
cluster,
so
they're
not
going
to
be
shown
but
they're
they're
there
and
then
the
the
actual
demo
flow
we're
going
to
set
up
the
virtual
layer.
Three
network
service
endpoints
in
each
cluster
and
that's
gonna,
be
a
script.
That
does
that.
A
So
it's
gonna
be
hard
to
follow,
but
the
gist
is
that
it
it
installs
the
nses
and
it
has
them
registered
as
a
network
service
named
vitesse
and
and
they're
configured
to
be
a
part
of
the
connectivity
domain
with
the
same
name.
So
they're
going
to
be
configured
to
point
back
at
those
nse
services
that
are
in
the
control
of
the
other
third
cluster.
B
Then
we're
going
to
deploy
the
test
pause
to
both
clusters
as
virtual
l3
ns
clients
we're
going
to
be
using
the
the
test
operator
for
kubernetes
to
do
the
handle
the
test
deployment
because
it
not
only
automates
the
deployment
of
the
test.
It
will
automate
the
management
of
a
test
on
kubernetes
as
well.
B
Then
we
will
use
for
test
to
create
a
database
table
and
shard
config.
That
will
illustrate
the
connectivity
domains
and
then
we'll
show
the
shards
are
split
between
the
clusters
via
use
of
separate
the
test
cells,
and
then
we
will
show
replication
across
this
clusters
by
using
a
control.
A
planned
failover
has
a
way
of
illustrating
that
there's
inter-cluster
network
provided
through
the
virtual
l3
connectivity
domain.
B
B
This
will
take
a
few
seconds
and
then
wall
of
text,
but
no
it
comes
through
and
there
we
go.
We
now
have
nfc
running
in
both
clusters
and
next
up
we
are
going
to
install
the
test
in
the
americas
region.
This
will
be
our
primary
region,
so
we
are
going
to
put
our
topology
servers
running
on
ncd
and
in
the
americas
regions.
B
We
are
using
the
tess
kubernetes
operator
to
handle
all
of
this.
We
just
feed
it.
A
cluster
configuration
and
the
test,
and
the
operator
then
handles
bringing
up
each
of
the
cds,
the
tablets
and
the
control
plane
as
well,
and
then
follow
that
up
with
the
bt
gates,
which
provide
the
connectivity
to
not
only
this
local
cluster,
this
local
cell,
it
will
also
provide
connectivity
to
the
other
cell.
B
Here
we
go
with
europe,
we
told
the
operator
to
apply
the
nsm
connectivity
domain
annotation
to
all
pods
in
the
vites
cluster
and
since
the
operator
is
also
managing
the
tablets
with
just
a
couple
lines
of
code,
it
extends
the
annotation,
so
nsm
registers
a
service
for
each
tablet,
so
they
can
communicate
across
the
clouds
using
the
nsm
connectivity
domain
and
then
now
that
all
tablets
are
ready.
That
means
they
are
connected
and
they're.
B
B
Here's
our
test
control
panel.
We
have
two
shards
in
the
user
database,
hyphen
40,
where
we
have
the
americas
has
the
master
and
a
replica
in
europe,
as
well
as
a
second
chart
of
everything
greater
than
40
is
only
in
europe
because
we
will
map
all
european
all
non-america's
users
into
the
european
cluster.
B
B
B
However,
if
we
do
start
a
mysql
client
within
the
connectivity
domain,
then
it
will
be
able
to
use
the
connectivity
and
service
name
to
connect
and
we'll
be
able
to
disable
the
vt
gate
service
kubernetes
service
entirely,
so
that
only
connectivity
domain
pods
can
be
there.
So
now
we're
inserting
some
data
making
one
into
the
us
and
one
with
a
french,
a
french
national
and
you'll,
see
that
it
only
went.
The
us
citizen
went
to
the
america's
master.
The
french
citizen
went
into
the
european
master.
B
B
B
B
So
now
we
are
going
to
do
a
failover
of
the
america's
master
into
the
european
region,
say
if
you
wanted
to
do
some
maintenance
and
with
your
in
the
americas
region,
we
can
now
do
a
plan
repair,
which
is
a
planned
failover,
that
your
application
would
not
notice
at
all,
because
the
vt
gate
will
pause
the
query.
While
this
repair
occurs.
B
A
So
that
was
that's
our
talk
for
references,
the
nsm
there's
some
links
here
for
the
nsm
project
and
the
virtual
layer,
3
nse,
that
we've
worked
on
at
cisco
and
the
vitesse
project
and
their
planet
scale
operator
that
you
saw
live
in
the
demo.
That
was
what
was
orchestrating
the
whole
the
test
installation.
A
Some
of
these
have
happened,
but
they're
interesting
talks
that
you
may
want
to
check
out
recordings
of,
and
similarly
the
nsm
con
was
a
day,
zero
event
that
had
a
couple
of
talks
that
would
be
directly
useful
if
you're
interested
in
nsm,
interdomain
and
virtual
layer,
3.
and
the
keynote
was
on
the
previous
slide
would
have
discussed
it
a
little
bit
and
then
there's
a
talk
coming
up
on
thursday.