►
From YouTube: Multi-Cluster & Multi-Cloud Service Mesh with CNCF’s Kuma and Envoy - Marco Palladino, Kong
Description
Multi-Cluster & Multi-Cloud Service Mesh with CNCF’s Kuma and Envoy - Marco Palladino, Kong
Learn how to run a distributed Envoy-based service mesh on multiple Kubernetes clusters and multiple clouds in just a few steps with Kuma, a CNCF project. In this session, we'll be firing up Kubernetes clusters in multiple regions to demonstrate how we can secure, route, connect and observe service connectivity in a distributed service mesh. In this session, we will learn to: - Use Kuma’s multi-zone deployment to spin up a multi-cluster and multi-region service mesh. - Leverage the global/remote control separation to scale reliability with HA. - Use the built-in service discovery and ingress capability for out of the box service connectivity across multiple zones, clusters and regions. - Use Kuma’s policy to determine the behavior of traffic across different clusters, like Traffic Route, mTLS, Traffic Permission and so on.
A
Welcome
everybody
to
this
live
demonstration
of
cuba.
Today,
I'm
very
excited
to
be
presenting
to
you
this
session,
because
we're
going
to
be
seeing
the
results
of
many
months
of
work
with
the
community
and
with
our
users
into
building
the
best
multi-cluster
and
multi-cloud
support
that
any
service
mesh
has
ever
seen.
A
When
we
first
looked
at
creating
a
service
mesh
integration
for
our
enterprise
customers
at
cong,
we
didn't
want
to
build
queue.
We
really
wanted
to
leverage
existing
service
meshes
out
there
that
were
available
in
the
industry
so
that
we
could
package
those
service
meshes
into
a
solution
that
we
could
ship
to
our
users
and
and
none
of
the
service
meshes
out.
There
worked
for
us
and
let
me
tell
you
why
we
wanted
something
that
was
easy
to
use.
A
That
was
simple
to
deploy
simple
to
scale,
but
for
many
users,
service
mesh
has
been
a
very
complicated
technology
to
deploy
and
to
use
at
scale
in
production.
We
needed
something
that
would
support
not
just
kubernetes
deployments,
but
could
also
support
virtual
machines
or
support
other
containerized
environments
that
were
not
kubernetes,
for
example,
aws,
fargate
or
ecs,
and
and
none
of
the
service
meshes
out
there
allowed
us
to
do
that.
We
needed
something
that
would
allow
us
to
support
multiple
zones
in
a
distributed
service
mesh
across
multiple
clouds.
A
Multiple
clusters,
across
a
hybrid
of
vms
and
kubernetes,
and
no
service
mesh,
was
allowing
us
to
do
that.
So
we
decided
to
build
cuba,
we
built
kuma
and
we
have
donated
kuma,
making
it
the
first
based
service
mesh
to
ever
be
donated
and
accepted
into
into
the
foundation
cuma.
It
is
built
on
top
of
envoy
we're
strong
believers
of
envoy
as
a
networking
technology
for
our
data
plane
proxies
and
because
of
the
very
unique
set
of
features
that
qm
has
built
over
the
past
years.
A
We
are
looking
at
an
incredible
growth
in
the
community
when
it
comes
to
community
adoption,
as
well
as
mission
critical
enterprise
adoption
in
mission
critical
use
cases
where
kuma
it
is
being
used
today
to
support
a
service
mesh
for
the
entire
organization
kuma.
It
is
something
that
has
been
designed
for
the
enterprise
architect.
We
want
to
make
sure
that,
as
the
application
teams
are
building
more
and
more
services,
more
and
more
applications,
they
do
not
manage
the
network
that
comes
as
part
of
the
infrastructure,
and
so
today
kuma.
It
is
being
used
by
central
teams.
A
Architecture
teams
to
provide,
under
the
under
the
hood
connectivity
via
a
service
mesh
across
any
environment,
any
cloud,
any
architecture
that
the
application
teams
are
using
for
their
applications,
so
qma
primarily
has
been
used
for
you
know
for
many
different
use
cases,
but
we
can
sum
them
up
in
the
following
ones.
So
has
been
used
to
enable
service
connectivity
across
all
the
services
that
we're
building
to
discover
the
services
and
make
sure
that
the
traffic
among
them
is
reliable.
It
has
been
used
for
one
click:
zero
trust
security
model
enablement.
A
The
bigger
is
the
requirement
for
strong
observability
and
so
is
being
used
today
to
capture
those
traces,
those
logs,
those
metrics
and
and
either
visualize
them
on
zipkin
or
jager,
or
splunk
or
logstash,
or
via
the
out
of
the
box
dashboards
on
grafana
that
the
project
provides
and
from
a
ten
thousand
feet.
Standpoint.
Kuma
is
a
control
plane
that
implements
the
xds
api.
It
can
run
on
kubernetes
and
vms.
It
can
run
in
a
single
and
multi-zone
capacity.
A
Kuma
provides
a
very
unique
set
of
features
that
we've
built
because
we
couldn't
find
them
elsewhere
and
so
qma
supports
a
multiple,
multiple
virtual
meshes
multi-tenancy
for
each
team
or
each
application
that
we
want
to
support
in
order
to
reduce
the
team
coordination
as
well
as
improve
the
compartmentalization
of
our
service
mentions.
So
we
can
deploy
comma
once
and
create
as
many
meshes
as
we
want,
as
opposed
as
opposed
to
creating
one
service
mesh
per
application
or
per
team.
It
is
universal.
It
runs
on
kubernetes
in
the
ends.
A
As
well
as
it's
built
on
top
of
envoy-
and
we
are
strong
believers
of
envoy
like
I
said,
we
can
leverage
all
the
envoy
functionality
inside
of
human,
we
can
implement
zero
trust
security
in
one
click
by
using
the
mutual
tls
and
traffic
permission
policies
that
kuma
offers
out
of
the
box
as
well
as,
like,
I
said
we
can
integrate
cuma
with
any
sorts
of
observability
tooling.
We
may
be
using
today,
as
well
as
using
what
cuba
provides
out
of
the
box.
A
Now,
of
course,
as
one
of
the
biggest
reasons
for
using
a
service
mesh.
It's
also
to
make
sure
we
can
implement
the
blue
green
deployments
and
canary
releases,
and
you
know,
traffic
shifting
across
different
data,
centers
and
qma
can
do
it
can
do
all
of
it
with
the
routing
capabilities
that
it
provides
and
in
the
demo
today
we're
going
to
be
seeing.
It
live
across
multiple
clouds,
multiple
regions
across
vms
and
containers.
Simultaneously.
A
When
it
comes
to
deploying
qma,
there
is
two
different
ways
we
can
run
the
project,
we
can
run
it
in
a
single
zone
or
standalone
mode,
or
we
can
run
it
in
a
multi-zone
mode.
Multi-Zone,
really,
it
is
what
makes
qma
very
interesting
in
in
an
enterprise
organization.
So
when
running
a
service
mesh
across
multiple
zones,
multiple
platforms,
multiple
clouds,
multiple
clusters,
there's
two
main
challenges.
A
Even
if
one
zone
is
vms
and
another
zone
is
kubernetes
or
one
zone
is
in
one
cloud.
One
region
and
another
zone
is
a
physical
data.
Center
kuma
makes
no
assumptions
as
to
where
we're
running
the
service
mesh
with
the
goal
of
supporting
every
workload
in
the
organization
and,
of
course
it
provides
a
gui
out
of
the
box.
A
You
can
see
gateway
data
planes
that
can
be
assigned
in
order
to
either
support
edge
requirements
with
an
ecosystem
of
partners
or
mobile
apps,
as
well
as
inside
of
the
organization
to
enable
different
teams
to
talk
to
each
other
via
an
abstraction
layer
provided
by
a
gateway.
So
let's
not
spend
any
more
time
talking
about
all
the
things
that
kuma
can
do.
Let's
watch
them
live
in
production.
A
So
I'm
going
to
be
pulling
up
my
infrastructure
right
now,
so
I
can
show
you
what
what
kuma
can
do
so,
first
and
foremost,
I
am
running
kuma
right
now
in
a
multi-zone
deployment
that
spans
across
both
ec2
and
virtual
machines,
as
well
as
kubernetes
clusters
on
gcp
on
gk.
So
we're
going
to
be
seeing
here
that
on
gke
we
have
cuba
east
kuma
west.
A
Now,
in
order
to
show
you
this
demo,
I
have
built
a
very
simple
application
that
basically
integrates
shows
a
front
end
that
allows
us
to
increment
a
counter
on
ratings,
and
so
I
was
loading
my
applications
from
ec2
and,
as
you
can
see,
if
I
press
the
increment
button,
it
will
increment
the
counter
in
in
a
specific
zone.
And
so
this
is
the
zone
where
redis
lives
and
so
different
radis
instances
in
different
zones
may
end
up
having
different
counters.
A
Depending
on
how
often
we
increment
that
counter,
you
know
I
can
generate
some
traffic
here
if
I
want,
but,
most
importantly,
let's
go
to
the
global
control
plane
and
see
what
we
have
running
live
into
our
mesh.
So,
first
and
foremost,
if
we
explore
the
namespaces
that
we
have
running,
we
see
that
there
is
akuma
system
namespace
and
if
I
look
into
the
into
the
pods
of
this
kuma
system
namespace,
we
see
that
there
is
one
common
control,
plane,
pod
and
a
service
really
that
we
can
then
access.
A
So
I'm
going
to
be
port
forwarding
the
kuma
control
plane
service
from
the
qma
system
namespace.
So
we
can
access
it
now,
the
gui
that
I'm
going
to
be
showing
you
it
is
built
on
top
of
the
same
restful
api
that
you
can
integrate
with
your
own
automation.
So
this
is
this
is
the
restful
api?
You
know.
If
I
go
on
slash
meshes,
I
can
explore
the
meshes
and
I
can
see
the
resources
of
the
mesh.
A
A
It's
on
kubernetes
east,
another
one
it's
on
kubernetes
west,
and
then
we
have
a
series
of
data
planes
that
we
have
running
where
we
can
see
that
there
is
a
radius
running
on
aws,
the
one
that
I've
just
showed
you
as
well.
There
is
a
demo
app
running
on
nws
on
virtual
machines,
but
we
also
have
the
demo
app
running
on
gke
east
and
we
have
red,
is
running
on
gk,
east
and
west
and
so
on.
A
We
also
have
the
three
ingresses
that
allow
us
to
enable
cross
zone
communication
out
of
the
box,
and
we
have
one
for
each
zone
for
aws,
for
gke,
st
and
for
gke
west.
You
know
when
it
comes
to
queue
itself,
we
can
go
on
cumulative,
we
can
go
on
slash
install
and
we
can
see
all
the
different
installation
methods
that
we're
supporting.
We
are
about
to
release
qmo
1.0
and
we're
also
going
to
be
introducing
support
for
windows,
which
is
now
being
released
in
an
alpha
version
in
android
proxy
all
right.
A
So
let's
go
ahead
and
and
start
using
the
mesh
so
right
now
the
mesh
is
not
really
doing
anything.
Besides
having
one
virtual
mesh
called
the
default,
everything
is
being
disabled.
There
is
no
resources.
All
I
have
is
the
data
planes
being
registered
to
it,
but
there
is
nothing
really
going
on
here.
So
let's
go
ahead
and
make
this
service
mesh
a
little
bit
more
interesting.
So
let's,
for
example,
enable
zero
trust
security
by
implementing
the
enabling
the
mutual
kls
policy.
A
When
it
comes
to
mutual
teles,
there
is
different
certificate
authorities
that
we
can
choose.
We
can
choose
the
built-in
certificate
authority
that
will
automatically
generate
a
ca
for
us.
We
can
provide
our
own
root
certificate
and
key
in
order
to
apply
these
resources.
It
is
very
simple
we
can
use
on
kubernetes.
We
can
use
cube
cattle
to
effectively
update
our
default
mesh
to
enable
mutual
tls
with
a
a
built-in
backend
that
does
a
certificate
rotation
for
our
data.
A
Plane
proxies
every
day,
but
if
you
were
to
be
running
these
on
virtual
machines,
we
could
use
a
very
similar
yaml,
declarative
config,
but
instead
of
cube
cattle,
we
would
be
using
cumacado.
So
this
is
truly
a
universal
service
mesh
that
can
support
all
kinds
of
environments,
but
because
we're
running
on
kubernetes,
I'm
going
to
be
using
this
policy
to
change
the
state
of
my
mesh.
A
A
So
if
I
go
here
and
I
open
a
new
terminal
and
I
apply,
I
apply
my
resource
on
kubernetes
on
the
global
control
plane.
We
can
see
that
the
traffic
will
stop
working,
and
that
is
because
we
have
enabled
zero
trust
security
and
we
must
have
an
explicit
traffic
permission
to
determine
what
services
can
consume
other
services,
and
so
the
traffic
permission
is
a
another
resource
that
kuma
provides
and
it
allows
us
to
determine
what
source
of
traffic
you
can
consume
what
destination.
A
A
Whenever
we
re-enable
this
traffic,
the
traffic
will
go
and
flow
across
every
zone
that
we
support,
which
means
the
kubernetes
zones
as
well
as
the
amazon
zone.
We
can
limit
that
and
change
that
behavior
by
using
a
traffic
routing
rule.
But
if
I
do
this
now,
we
can
see
that
not
only
the
traffic
is
being
resumed,
but
the
traffic
is
also
going
to
be
flowing
from
one
zone
to
another.
What
you're!
Looking
at
right!
A
Now,
it's
a
multi-zone
deployment
running
on
multiple
kubernetes
clusters,
running
on
virtual
machines,
on
different
clouds
in
different
world
regions,
with
zero
trust
security,
enabled
with
traffic
permission,
acl
enabled
and
the
traffic
is
flowing
from
one
zone
to
another
out
of
the
box,
automatically
discovered
automatically
secured.
Of
course,
the
counter
is
going
to
be
different,
depending
on
what
radius
instance
in
what
in
in
you
know
where
we're
hitting
in
in
the
specific
zone-
that's
being
visualized
down
here.
A
But
now.
Let's
say
that
we
want
to
change
this.
We
want
to
force
traffic
to
go
to
specific
zones.
That
would
be
very
easy
to
do
by
using
the
traffic
routing
policy
which
allows
us
to
determine
how
we
want
the
traffic
to
flow
from
from
one
zone
to
another,
and
so
I'm
going
to
be
pulling
up
my
editor
again
and
we
can
determine,
for
example,
that
we
can
use
the
attributes
again.
So
we
can
say
that
I
want
all
traffic
from
this
service
generated
by
this
service
going
to
this
other
service.
A
A
We
can
apply
it
on
kubernetes,
but
I'm
going
to
be
doing
this
next
to
my
app.
So
we
can
see
what
happens.
I'm
now
applying
like
I've
done
before
I'm
applying
this
resource
on
the
global
control
plane.
The
global
control
plane
is
now
automatically
synchronizing
this
resource
across
all
the
remotes,
so
that
we
can
put
this
new
effect
new
new
change
into
effect,
and
so,
if
I
do
this,
we
can
see
how
the
traffic
is
now
gonna
be
forced
into
gk
east.
A
But
let's
say
that
I
want
a
little
bit
of
amazon
a
little
bit
of
gcp,
that's
great!
I
can.
I
can
go
back
to
my.
I
can
go
back
to
my
configuration,
I
can
add
another.
I
can
split
the
weight
in
the
following
way
and
I
can
say
that
a
little
bit
of
traffic
goes
on
aws
and
a
little
bit
of
traffic
goes
on
gcp.
So
right
now
we
can
see
that
approximately
half
of
it
will
go
in
aws
and
half
of
it
will
go
on
gk
east.
A
I
can
update
my
resource.
We
can
pull
up
our
application
again
and
if
I
do
this,
we're
going
to
be
seeing
the
traffic
going
a
little
bit
on
the
amps
a
little
bit
on
containers
a
little
bit
on
one
cloud,
a
little
bit
on
another
cloud.
It's
that
easy
to
run
a
distributed,
multi-cloud
multi-cluster
service
mesh
with
cuma.
A
Now
you
know.
Obviously
this
is
a
very
simple
demo
that
demonstrates
zero
trial
security
demonstrates
our
traffic
permissions,
but
there's
a
lot
more
to
it
and
you
can
explore
the
policies
that
we
have
here
as
well
as
you
can
use
any
filter
that
amway
provides
with
the
proxy
template
policy
as
well
as
you
can
see
the
metrics,
the
traces
and
so
on
and
so
forth.
A
Now
this
is
how
easy
it
is
to
use
the
project
as
as
one
of
the
most
important
announcements
that
I
would
like
to
make.
We
have
release.
We
have
released
quinoa
1.0,
which
brings
so
much
more
in
performance
improvements
and
improvements
in
this
multi-zone
deployment
to
to
the
project,
and
this
is
available
on
the
website
today
on
you
can
download
and
use
it
and
push
it
in
production
live,
so
we
have
seen
today
what
qma
is
what
kuma
can
do?
Why
is
very
different
from
other
service
meshes?