►
Description
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 hands-on webinar, Marco Palladino - Kong’s CTO and Kuma maintainer - will 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.
With native Envoy support, Kuma provides a unique set of features in the service mesh landscape to reliably - yet easily - create a multi-mesh deployment across a complex network topology to address mission-critical production use cases on both containerized and VM-based workloads.
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
Presenter:
Marco Palladino, CTO & Co-Founder @Kong
A
Okay,
let's
get
started
would
like
to
thank
everyone
for
joining
us
for
today's
cncf
webinar
multi-cluster
and
multi-cloud
service
mesh
with
cncs,
kuma
and
envoy,
I'm
jerry
fallon,
and
I
will
be
moderating
today's
webinar.
We
would
like
to
welcome
our
presenter
today,
marco
palladino
cto
and
co-founder
of
kong,
just
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee.
A
A
B
Thank
you
so
much.
My
name
is
marco,
I'm
the
cto
and
co-founder
of
kong
and
and
today
I'm
excited
to
be
showing
you
the
result
of
many
weeks
and
many
months
of
work
that
we
have
done
with
the
community
and
the
users
around
cuma
when
it
comes
to
the
multi-cloud
and
multi-cluster
deployment
of
a
service
mesh.
B
So
when
we
look
at
service
mesh
deployments,
multi-cluster
multi-cloud,
including
a
hybrid
of
containers
and
virtual
machines
in
the
same
service
mesh,
this
is
probably
one
of
the
most
complex
service
mesh
deployments
that
anybody
or
any
product
can
address
when
it
comes
to
when
it
comes
to
service
mesh.
Like
I
said,
my
name
is
marco.
I'm
the
cto
and
co-founder
at
kong.
B
Kuma
was
initially
built
at
kong
and
then
donated
to
the
cncf
foundation
as
a
sandbox
project,
making
it
the
first
envoy
based
service
mesh
to
ever
the
first
onway-based
service
mesh
to
be
donated
and
accepted
in
in
the
foundation.
So
today
I'm
going
to
be
presenting
an
overview
on
cuma
what
it
is
why
we
built
it,
what
problems
it
solves
and
then
we're
going
to
be
firing
up
the
terminal.
B
So
I
want
the
majority
of
this
presentation
to
really
be
a
live
demo,
where
you
can
see
how
kuma
can
run
in
a
multi-cloud
and
multi-cluster
deployment,
and
then
on
top
of
that,
we're
going
to
be
doing
a
few
things
like,
for
example,
enabling
zero
trust
security,
enabling
traffic
permission,
acl
traffic
routing
across
different
zones.
So,
let's
not
waste
any
time,
let's
dive
into
it.
B
And
so,
as
part
of
that
part
of
that
work,
we
started
working
on
actually
using
service.
Meshes
that
were
available
out
there
and
integrate
them
within
our
offering,
and
we
quickly
realized
that
those
existing
service
measures
were
not
going
to
be
a
good
fit
for
us.
For
a
couple
of
reasons.
First,
service,
mesh
and
service
mesh
projects
out
there
for
a
long
time
have
been
very,
very
hard
to
use
very
hard
to
scale
very
hard
to
consume.
B
Long
story
short,
none
of
the
projects
out
there
were
working
for
us,
and
this
is
why
we
decided
to
build
queue.
Then,
after
building
kuma,
we
donated
kuma
and
kuma
today
provides
a
very
unique
set
of
features
that
we
are
not
going
to
be
finding
in
any
other
service
mesh
available
in
the
landscape
and
in
in
the
in
the
market,
and
thanks
to
that
very
unique
set
of
features.
Today,
we're
seeing
lots
of
adoption
when
it
comes
to
when
it
comes
to.
B
You
know
users
adopting
skew
map
to
build
their
own
service,
meshes
in
either
a
single
zone
or
multi-zone
capacity,
as
well
as
enterprise
organizations
that
are
using
cuma
to
create
a
service
mesh
that
the
enterprise
architects
can
then
utilize
to
provision
connectivity
across
each
application
in
each
team
that
the
application
teams
are
building
and
the
thing
about
service
mesh.
It
really
is
that
the
the
features
that
service
mesh
provides
all
the
zero
trust
security,
all
the
observability,
all
the
traffic
routing
and
traffic
reliability.
B
Now,
before
I
jump
into
why
qma
is
unique,
let's
look
at
why
we
actually
need
a
service
mesh
and-
and
usually
there
is.
There
is
many
different
use
cases,
but
we
can
sum
them
up
in
these
three
main
scenarios.
We
need
to
have
a
service
mesh
because
the
more
applications
we
build
and
the
more
connectivity
we
create
and
connectivity.
It
is
at
the
backbone
of
every
modern
application.
B
If
our
connections
are
not
reliable,
they're
not
secure,
then
our
applications
are
not
reliable
as
well
they're
down,
and
if
our
applications
are
down,
then
our
business
is
going
to
suffer
from
it.
So
it's
important
that
as
we
build
more
applications
and
inevitably
we
introduce
more
connectivity
as
we
transition
to
microservices
as
we
create
more
and
more
of
that
connectivity.
B
We
can
connect
the
services
together
in
a
reliable
way
in
a
secure
way,
and
we
can
then
observe
all
that's
happening
among
these
more
complex
networking,
topology
and
so
service
mesh
has
been
used
to
do
that,
to
discover
the
services
to
connect
them
to
enable
that
reliable
connections
so
that
the
teams
don't
have
to
build
that
by
themselves
in
a
fragmented
way.
But
we
can
provide
that
as
as
part
of
the
underlying
infrastructure
provisioning
that
the
architects
are
are
provisioning
to
the
application
teams.
B
Whenever
the
the
teams
want
to
create
something,
as
well
as
we
can
enable
zero
trust
security
models
to
assign
a
certificate
and
an
identity
really
to
every
service.
That's
running
within
our
mesh,
as
well
as
encrypting
the
traffic
from
one
service
to
another
and
then
finally
understanding
what
are
the
traces?
What
are
the
metrics?
What
are
the
logs
among
all
the
services
that
we
are
running
and
in
kuma
by
the
way?
B
It
is
not
something
that
we
can
use
only
for
traditional
apis
or
api
protocols
like
http
or
jrpc,
but
we
can
use
scuma
in
front
of
anything
that
makes
or
receives
a
request
over
tcp,
which
means
that
we
can
use
a
service
mesh
not
just
for
the
apis
and
the
services
that
we
create,
but
also
for
services
that
we
adopt,
for
example,
a
database,
for
example,
an
event
collector
like
kafka.
So
anything
that
makes
a
request
or
receives
a
request.
B
Is
a
service
for
service
mesh
and
kuma
supports
that,
and
and
if
you
look
at
kuma
from
a
high
level
overview.
Qma
is
a
control
plane
that
implements
the
xds
api
that
the
tamboy
supports,
and
so
we
bundle
envoy
as
our
data
plane
proxy
technology
in
kuma
in
such
a
way
that,
in
order
to
use
schema,
we
do
not
need
to
have
any
prior
experience
or
knowledge
of
envoy.
B
With
that
said,
there
is
still
a
chance
for
power
users
to
go
deeper
and
change.
The
underlying
proxy
configuration
that
amway
supports
by
using
what
we
call
the
proxy
template
so
long
story
short
qm
is
a
control
plane
that
supports
soundboy,
where
we
support
the
sidecar
model
of
amboy.
We
automatically
inject
a
sidecar
next
to
our
services
next
to
our
workloads,
and
we
can
run
this
service
mesh
on
both
kubernetes
and
virtual
machines
on
both
single
zone
deployments
or
multi-zone.
B
A
zone
can
be
a
kubernetes
cluster.
It
can
be
a
platform
can
be
a
cloud,
it
can
be
a
vpc.
We
can
slice
and
dice
it.
However,
we
want,
and
we
can
connect
the
service
mesh
across
both
of
these
environments.
It
is
built
for
the
enterprise,
architects
that
deploys
the
service
mesh
once
across
all
the
zones
that
they
want
to
support,
and
then
they
can
create
virtual
meshes
for
each
application.
Each
team-
you
know
from
from
one
installation
of
the
service
mesh.
It
is
easy
to
install
easy
to
use
easy
to
scale.
B
Simplicity
really
has
been
a
big
focus
when
it
came
to
cuma.
We
wanted
to
simplify
how
kuma
could
be
adopted
in
the
in
the
community
and
among
the
user
base,
and
by
doing-
and
we
really
spent
lots
of
time
to
think
of
of
simplicity
really
as
almost
as
a
feature
we
wanted
this
to
be
to
be
simple
to
use
and
because
it
is
part
of
cncf,
it
is
built
with
the
same
governance,
the
same
neutrality,
the
same
openness
as
any
other
cncf
project
like,
for
example,
envoy,
which
we
support
natively.
B
We
wanted
to
create
one
deployment
that
could
virtualize
all
of
these
different
measures
in
each
mesh.
It
is
going
to
be
powered
by
its
own
certificate
authority
back-end,
which
means
that
there
is.
There
is
isolation
built
in
among
these
different
meshes.
By
doing
so,
we
deploy
chemo
once
and
then
we
can
run
it
as
many
meshes
as
we
want.
It
is
universal
because
it
runs
everywhere.
It
runs
on
kubernetes,
it
runs
on
open
shift,
it
runs
on
virtual
machine
based
workloads
and
we
can
also
mix
and
match
those
workloads.
B
Kuma
creates
an
overlay
across
our
kubernetes
clusters,
across
our
virtual
machine
based
workloads,
and
on
top
of
that
overlay,
we
can
then
apply
service
mesh
policies
like
neutral
tls,
like
observability,
like
circuit
breakers,
like
health
checks
like
tracing
in
order
to
govern
how
the
traffic
and
the
connectivity
among
all
of
these
different
environments,
it
is
going
to
be
working,
and
we
can
do
that
in
a
quite
flexible
way.
Every
new
service
or
any
new
environment.
B
If
you're
familiar
with
service
match-
which
which
I
assume
you
are,
you
know
that
this
has
two
benefits-
first
and
foremost,
the
application
teams,
they
stop
managing
the
network,
they
become
consumers
of
connectivity.
Likewise
we're
using
kubernetes
to
abstract
away
data
center
operations,
we're
going
to
be
using
something
like
huma
to
abstract,
away
connectivity
across
any
applications
that
the
developers
are
building
before
service
mesh.
The
developers
were
also
building
that
connectivity.
They
were
managing
it,
they
were
securing
it.
B
They
were
observing
it
in
different
programming
languages,
with
lots
of
fragmentation,
and
so
they
become
consumers
now
of
that
connectivity,
as
opposed
as
opposed
to
being
the
builders
of
that
connectivity,
and
this
in
turn
makes
them
more
productive
and
the
architects
who
are
provisioning.
This
infrastructure
get
control
on
the
most
important
thing
that
any
modern
application
must
do
right,
and
that
is
connectivity.
B
It
is
built
on
top
of
envoy.
We
really
like
envoy.
As
a
networking
primitive.
We
didn't
think
we
needed
to
build
another
networking
stack
for
managing
the
the
data
plane
proxy
communication,
so
we're
effectively
leveraging
the
the
envoy
runtime
to
do
all
of
that
which,
as
you
know,
it
is
very
stable
and
there
is
you
know
the
entire
industry
is
rallying
around
it.
B
So
humble
was
definitely
the
best
choice
for
us
when
it
came
to
when
it
came
to
supporting
a
data
plane
technology
and-
and
we
made
sure
that
we
could
do
things
in
a
very
simple
way,
and
so,
for
example,
we're
going
to
be
seeing
in
the
demo
enabling
neutral
tls
with
automatic
ca
creation
and
automatic
certificate
issuance
and
rotation.
It
is
a
one-click
process
with
human
one
click
we
deploy
it.
We
run
the
mutual
telus
policy
and
everything
else
has
been
taken
care
of
by
human
as
well
as
we
provide
you
know.
B
Kuma
provides
some
provides,
some
integrations
with
prometheus
with
grafana
with
with
tracing
providers,
and
we
also
have
you
know,
chips
with
grafana
dashboards
out
of
the
box.
So
if
you
want
to
get
some
charts
real,
quick,
we
we
don't
have
to
build
them
from
scratch.
They
are
coming
with.
With
queue
itself
bundled
into
the
project,
and
so
this
is,
this
is
again
in
the
context
of
making
sure
that
everybody
could
get
could
get
up
and
running
very
quickly.
B
Of
course,
there
is
then
traffic
routing
policies
that
allow
us
to
do
blue
green
deployments
allows
us
to
do
canary
releases
in
a
standardized
way
across
every
environment,
and
if
you
look
at
the
multi-zone
support
that
cuba
provides.
This
is
really
where,
where
kuma
excels,
into
into
deploying
into
support
in
complex
networking
environments,
so,
first
and
foremost,
when
running
a
service
mesh
in
a
distributed
way,
there
is
going
to
be
two
different
challenges.
B
First,
how
do
we
propagate
the
service
mesh
policies
across
each
one
of
the
zones,
the
regions,
the
clusters
that
we
want
to
support?
And,
second,
how
do
we
enable
cross
zone
connectivity
from
one
region
to
another
and
kuma
does
that
by
supporting
this
global
remote
control
plan
separation,
which
automatically
takes
care
of
all
of
this
for
us?
So
we're
going
to
be
having
a
global
control
plane
that
we're
going
to
be
using
for
changing
the
state
of
the
service
mesh
across
every
zone.
So
the
global
is
the
primary.
B
Therefore,
we're
going
to
be
using
jrpc
and
http
2
all
the
way
from
the
data
planes
to
the
remote
and
from
the
remote
to
the
global
control
plane.
So
this
has
been
created
with
the
goal
of
keeping
things
quite
simple
when
it
comes
to
this
distributed
communication
now.
The
second
problem
is
enabling
the
cross
zone
connectivity
across
these
different
zones,
and
to
do
that,
we
have
enabled
a
different
mode
for
the
data
plane.
B
So
you
can
have
a
data
plane
in
standard
mode,
which
is
a
proxy
effectively
and
you
can
have
a
data
plane
in
ingress
mode
and
when
you
deploy
the
data
playing
the
cuba
data
plane
in
ingress
mode,
then
that
can
be
used
as
the
ingress
to
accept
traffic
from
another
zone
into
into
the
zone
with
ingress
is
being
deployed.
So
the
ingress
will
effectively
is
effectively
the
component.
B
All
of
these
it's
much
harder
to
explain
than
to
than
to
watch
and
see
live,
and
so
I
want
to
pull
up
my
terminal,
real,
quick
and
then
show
you
how
these
works
works
with
with
live
with
a
live
application
live
demo.
Now
the
zones
by
the
way
can
be
like,
I
said,
different
kubernetes
clusters.
They
can
be
container
based,
but
our
zones
can
also
be
virtual
machine
based
zones,
and
so,
for
example,
we
can
run
this
on
aws.
B
B
Kuma
comes
with
a
gui
out
of
the
box.
We're
going
to
be
using
these
quite
extensively
to
look
at
the
state
of
our
resources.
It
comes
with
native
kubernetes
crds.
If
we
run
on
kubernetes
it
comes
with
universal
clis
and
http
api,
we
can
effectively
integrate
cuma
with
any
automation
we
have
built
inside
of
our
environments.
B
It
comes
with
policies,
policies
that
implement
security,
traffic
control
observability,
and
we
can
also
leverage
all
the
underlying
policies
and
filters
that
envoy
supports
by
using
the
proxy
template
template
policy
that
kuma
that
kuma
offers
and
so
effectively
we
have
available
to
us
all
the
cuma
policies,
as
well
as
the
entire
envoy,
proxy
ecosystem
and
filters.
If
we
want
to
go
a
little
bit
lower
level
and
and
one
of
the
things
that's
quite
interesting,
you
know
when
working
with
the
users
and
and
the
organizations
that
are
using
tumor
today.
B
One
of
the
things
that
we've
realized
is
that
kuma
is
being
used
for
a
couple
of
reasons.
So,
besides
implementing
a
mesh
is
also
being
used
to
accelerate
the
transition
to
kubernetes.
Kubernetes
is
for
many
users
a
journey.
It's
not
an
end
state,
so
they're
moving
to
kubernetes
they're,
slowly,
shifting
and
transitioning
their
applications
to
kubernetes,
and
what
we
found
out
was
that
supporting
virtual
machine
based
workloads
in
combination
with
container-based
workloads
allows
for
a
more
gradual
transition
to
kubernetes.
B
Therefore,
making
it
easier
and
simpler
for
anybody
to
adopt
kubernetes,
more
and
more
and
and
then
another
thing
that
we've
noticed
is
that
service
mesh
help
some
of
our
users
reduce
cost
in
a
significant
way
when
it
comes
to
when
it
comes
to
adopting
adopting
a
service
mesh.
A
service
mesh
implements
a
client-side
load,
balancing
pattern,
for
example,
and
by
using
a
service
mesh,
we
can
remove
the
enterprise
load
balancers
that
we're
using
today
in
front
of
every
service.
B
Therefore,
saving
significant,
a
significant
amount
of
money
for
some
of
the
users
that
that
have
been
using
human
who
are
talking
about
a
seven
figure.
Eight
figure
cost
saving
into
removing
away
all
those
enterprise
contracts
for
load
balancers,
and
you
know,
enterprise
load,
balancers
and
so
on
by
using
a
service
mesh
and
because
we
don't
have
that
extra
hop
in
the
network.
B
The
service
mesh,
even
though
it
implements
a
cycle,
practice
proxy
pattern,
it
implements
it.
It
improves
the
overall
performance
of
our
systems,
because
if
there
is
no
load
balancer,
there
is
no
extra
hop
in
the
network.
Therefore,
we
can
get
rid
of
extra
network
latency,
so
we
can
accelerate
to
kubernetes.
B
There
is
another
mode
that
qma
supports
for
the
proxy
data
planes.
There
is
the
standard
one.
Then
there
is
the
ingress
which
I've
explained,
and
then
there
is
another
mode
and
this
mode
is
called
the
gateway
mode.
You
know
service
mesh
for
certain
use
cases.
It's
not
applicable.
Let's
say
that
we
want
to
expose
apis
to
an
ecosystem
of
partners.
B
Well,
in
these
kind
of
examples,
we
cannot
support
a
service
mesh
because
we
cannot
force
a
third-party
developer
to
install
a
sidecar
next
to
their
applications,
even
assuming
that
that's
even
possible
and
and
then
we
don't
want
their
sidecar,
which
runs
outside
of
the
organization
to
connect
to
our
control
plane,
which
runs
inside
of
the
organization.
The
sidecar
obviously
requires
connections
to
the
control
plane
to
provision
the
certificates
and
the
policies,
and
so
on.
So
there
is,
for
example,
at
the
edge
you
know.
B
Service
mesh
cannot
be
used
as
a
pattern
in
a
practical
way,
and
so
what
we're
seeing
is
more
and
more
users
more
and
more
customers
trying
to
do
this
in
combination
with
an
api
gateway.
Now,
to
do
that,
kuma
supports
a
gateway
mode
in
our
data
planes,
so
you
can
use
any
gateway
out
there
to
work
with
qma
in
order
to
apply
any
user
governance
or
onboarding
flows.
You
may
have
on
the
gateway
itself
and
then
enter
the
mesh.
You
know
as
effectively
making
the
gateway
an
ingress
to
the
mesh
and,
of
course,
kong.
B
I
think
that
it's
time
for
the
demo,
so
we
can
see
we
can
see
how
how
humor
runs
and
so
right
now
I
have
deployed
kuma
on
on
a
quite
quite
complex
environment,
so
I'm
running
qma
on
aws
and
I'm
running
qma
on
gcp.
It's
a
multi-zone
deployment.
That
is
also
multi-cloud,
but
the
thing
is
on
aws
I'm
running
on
ec2,
whereas
on
gcp
I'm
running
on
gke.
B
So
this
is
a
multi-cloud
multi-region,
hybrid
containers
and
virtual
machine
service
mesh,
and
now
we're
going
to
be
seeing
how
all
of
this
works
together,
so
that
we
can
enable
connections
from
ec
from
the
virtual
machines
to
different
regions
and
different
zones,
and
vice
versa.
So,
first
and
foremost,
you
can
see
that
there
is
a
kuma
global
containing
a
cluster
being
deployed
on
gke,
and
this
is
where
I
have
my
control
plane
running
in
global
mode:
the
global
control
plane.
B
B
So
if
you
remember,
if
you
remember
the
diagram,
the
architecture
there's
going
to
be
one
global
and
then
one
remote
for
each
zone,
we
want
to
support,
and
so
there
is
this
zone
here
with
a
remote
and
then
there
is
going
to
be
these
different
zones
here,
east
and
west,
each
one
with
their
own
remote
as
well,
and
this
is
running
on
containers
ec2
and
this
is
running
on
kubernetes.
So,
let's
connect.
B
B
So
if
I
do
this
and
I
open
a
new,
a
new
browser
by
the
way,
the
gui
it's
running,
on
top
of
of
the
api
that
that
kuma
provides
and
so
for
example,
if
we
go
on
slash
meshes,
we
can
see
all
the
meshes
that
we
have.
There
is
three
different
meshes
right
now,
but
if
I
go
on
slash
gui,
we
can
see
the
gui,
the
gui
it's
built
on
top
of
the
same
restful
api
that
you
can
integrate
with
anything
else.
B
So
there's
nothing
that
the
gui
does
that
you
cannot
automate
there's
going
to
be
three
different
zones.
There
is
a
zone
on
aws.
There
is
a
zone
on
gcpg
east
and
then
there
is
a
zone
on
gcp
gke
west
and
I
have
deployed
a
very
simple
demo
application
for
each
one
of
these
of
these
different
zones.
The
demo
app
is
quite
simple:
it's
a
demo
application
backend
that
provides
a
front-end.
We
can
consume
with
the
browser
that
allows
us
to
increment
a
counter
on
redis.
B
I'm
going
to
be
showing
you
the
demo
app
in
a
second,
it's
quite
simple,
so
there's
going
to
be
two
services
redis
and
demo
app
on
aws,
as
you
can
see
here.
So
these
are
the
attributes
that
kuma
automatically
creates,
but
we
can
also
create
our
own
and
then
there
is
going
to
be
our
demo
app
and
our
redis
being
deployed
on
gcp,
gke,
east
and
we're
going
to
be
having
the
same
thing.
Demo,
app
and
red
is
being
deployed
on
gke
west.
So
basically,
each
zone
has
the
same
demo.
B
App
and
red
is
being
deployed
all
over
and
of
course,
that
is
not
a
requirement
we
could
have.
You
know
demo
app
been
deployed
on
only
on
one
region
and
red
is
on
another.
You
know
we
can
really
mix
and
match
our
workloads.
However,
we
want
and
we're
going
to
be,
having
three
different
ingresses
data
planes,
one
for
each
zone,
aws
gke,
east
and
gk
west-
to
enable
this
cross
zone
communication.
As
you
can
see
here,
I
have
three
meshes
so
right
now.
B
If
I
go
on
my
default
mesh,
I
see
all
my
data
planes,
but
let's
say
that
we
want
to
create
a
mesh
for
another
team.
These
are
empty.
It's
an
empty
virtual
service
mesh
on
top
of
this
deployment
of
tumor.
So
this
is
really
one
control
plane
to
support
the
entire
org.
So
let's
go
ahead
and
consume
the
application,
so
I
can
show
you
what
it
does.
If
I
go
on
my
on
on
ec2,
so
right
now,
I'm
consuming
I'm
consuming
the
demo
app
that's
running
on
virtual
machines.
B
I
can
see
that
the
demo
app
allows
me
to
increment
a
counter
on
on
redis
and
redis
right
now.
It's
also
running
on
the
same
zone
as
the
demo
app.
So
this
is
this
is
telling
us
what
is
the
counter
value
for
the
radius
instance
that
we're
hitting
and
what
is
the
zone
that
we're
consuming
now,
because
we,
I
don't
have
mutual
tls,
enabled
right
now
cross
zone
connectivity.
It
is
not
going
to
be
working.
B
So
let's
do
that
by
exploring
all
the
policies
that
kuma
provides
we're,
adding
more
and
more
policies.
You
know
every
on
every
release,
so
we're
we're
very
quick
into
introducing
more
and
more
capability,
but
you
can
find
here
what
you
would
expect
from
a
service
mesh.
So
let's
apply
mutual
tls.
There
is
different
backend
providers
that
you
can
support.
We
can
create
our
own
certificate
authority
automatically
if
you
use
built-in
or
you
can
provide
your
own
certificate
and
key
so
for
each
example.
B
There
is
a
kubernetes
example
that
we
can
apply
with
cube
cattle
and
then
there
is
a
universal
example
for
control
planes
that
are
running
on
virtual
machines
that
we
can
apply
with
qmacado,
which
is
our
own
cli.
So
this
is
for
teams
that
are
not
familiar
with
kubernetes
yet,
but
the
resource
is
quite
similar
to
the
kubernetes
one.
B
So,
in
order
to
enable
mutual
tls
we're
going
to
be
updating
our
default
mesh
object
with
a
mutual
telus
property
that
enables
the
following
mutual
test
back-end,
and
this
back-end
is
a
built-in
backend,
which
means
we
are
generating
automatically
the
certificate
authority,
root
certificate
and
key
and
automatically
we're
going
to
be
rotating
the
proxy.
The
data
plane
proxy
certificates
every
day,
so
it
doesn't
matter
how
many
zones
we
support.
How
many
meshes
we
have,
how
many,
how
many
proxies
we're
running
and
connecting
to
the
mesh?
B
We
may
have
a
hundred
thousand
data
plane
proxies
running
cuba
will
take
care
of
rotating
those
certificates
for
us
within
all
of
these
different
proxies
with
with
one
resource,
and
this
is
the
resource
we're
going
to
be
applying.
So,
let's
go
ahead
and
update
update
my
mesh
so
that
it
provides
it
enables
mutual
talents.
Now,
one
of
the
things
that
you
will
notice
is
that,
as
soon
as
I
enable
mutual
tls,
the
traffic
will
stop
working
if
we
do
not
have
a
traffic
permission
policy.
B
So
let
me
show
you
this
live,
so
I'm
going
to
be
auto,
incrementing,
auto
incrementing
radius
and
then
pulling
up
the
terminal
and
from
the
terminal
I
am
going
to
be.
I
am
going
to
be
applying
this
resource
that
we
have
just
the
mutual
telus
resource
for
the
default
mesh.
So
as
soon
as
I
apply
this
and
I
press
enter
we'll
see
that
the
traffic
will
stop
working
and
that
is
by
design
now
that
every
service
has
an
identity.
B
We
need
to
enable
traffic
permission
to
determine
what
service
can
consume,
what
other
service,
and
we
can
do
that
by
specifying
what
source
can
consume
what
destination,
and
so
we
can
use
any
tumor
tag
in
this
case.
I'm
using
the
human
io
service
tag.
You
know
you
can
find
all
the
tags
from
the
gui.
For
example,
I'm
using
the
the
cumulative
service
tag
to
determine
that
every
service
must
be
able
to
consume
every
other
service,
and
so
I'm
gonna
go
here
and
create
the
echo
command.
B
So
if
I
enter
this,
we
create
a
traffic
permission
and
now,
depending
on
depending
on
the
load,
balancing
routing
policies
we
have
by
now.
For
now,
I'm
just
using
the
default
one.
We
see
how
our
virtual
machine
demo
application
is
consuming
different
radis
instances,
one
for
each
zone,
that
we
support
automatically
out
of
the
box
across
multiple
clouds
across
multiple
regions,
effectively
creating
a
hybrid
mesh
that
is
also
containers
and
virtual
machines.
B
At
the
same
time,
the
counters
are
going
to
be
different
depending
on
what
zone,
what
radis
I'm
going
to
be
hitting
when
it
comes
to
the
increment,
and
so
we're
going
to
be
seeing
that,
depending
on
the
zone,
this
is
going
to
different
regions.
This
happens
out
of
the
box
right
now,
once
we
install
the
global,
we
installed
the
remote.
All
of
this
happens
out
of
the
box.
We
created
this
network
overlay.
That
really
simplifies
simplifies
how
we
manage
connectivity
across
complex
networking
topologies.
B
Now,
let's
say
that,
for
example,
we
want
to
redirect
our
traffic
to
one
specific
zone,
so
we
don't
want
this
round-robin
across
multiple
zones,
but
we
want
to
only
target
specific
zones,
it's
very
simple:
to
do
with
kuma
with
kuma
we
can
go
and
apply
the
traffic
route
policy
which
allows
us
to
determine
how
we
want
routing
to
work
across
our
services
and
across
our
zones.
So
let's
go
ahead
and
create
a
traffic
routing
policy.
B
Let
me
make
this
a
little
bit
smaller.
So
let's
create
a
traffic
routing
policy
that
for
these
traffic
path,
it
is
going
to
be
load
balancing
the
request
in
this
way
that
we're
going
to
be
specifying
so
let's
go
ahead
and
fetch
the
service
name
for
our
demo
app.
So
basically,
I'm
saying
I
want
all
sorts
of
traffic
that's
being
originated
by
our
demo,
app
that
consumes
redis.
The
right
is
service.
B
I
want
100
of
the
traffic
to
consume
redis
to
consume
redis
on
just
one
zone,
so
I
want.
I
want
to
consume
redis
on,
let's
say
on
gke
east,
so
I
can
do
this
and
then
I
can
echo
these
instead
of
cube
cattle
in
order
to
apply
the
resource
on
my
global
control
plane.
If
you
notice
here,
the
global
control
plane
is
automatically
propagating
these
policies
across
all
the
remotes.
All
of
that
happens
out
of
the
box.
We
don't
have
to
build
it
ourselves.
B
So
if
I
enter
this
traffic
route
after
this
traffic
route
has
been
propagated
automatically,
we
should
be
seeing
our
demo
app
only
consuming
this
zone,
the
gke
east
zone.
So
let's
go
ahead
and
create
the
traffic
route
and,
as
you
can
see,
eventually
it
will
be
propagated
and
now
we're
hitting
only
one
specific
zone.
Let's
say
that
we
want
to
go
50
percent
on
aws
50
on
gk.
B
And
if
I
update
my,
if
I
update
my
traffic
route
policy
and
I
enter
this,
we
should
be
seeing
aws
coming
up
half
of
the
times.
This
is
how
simple
it
is
to
route
across
different
zones,
different
environments
or
perhaps
even
do
data
center
traffic.
Shifting
in
case
we
do
have
problems
with
one
data
center
and
we
want
to
keep
the
uptime
of
our
application
running
right.
So
so
far,
we've
seen
the
multi-zone
deployment
with
multi-cloud.
There
is
much
more
that
we
can
see
when
it
comes
to
kuma.
B
As
a
matter
of
fact,
I
also
did
a
presentation
at
service
mesh
con
at
kubecon
this
year.
So
I
suggest
you
look
at
that
recording
as
well
to
see
how
we
can
enable
observability
metrics
as
well
on
top
of
all
of
this,
and
then,
of
course,
you
can
go
ahead
and
apply
any
policy
that
qma
offers
to
enable
this
behavior.
B
This
is
the
service
mesh
that
we
have
created
to
support
these
complex
networking
environments
and
now,
let's
say
that
there
is
another
team
wanting
to
have
its
own
mesh
their
own
mesh
because
they
are
working
on
another
project
or
another
application.
Let's
say
that
they're
working
on
their
mobile
app,
we
can
easily
create
a
new
mesh
policy.
B
So
to
recap,
we
are
running
huma
on
top
of
multiple
clouds,
multiple
regions,
kubernetes
and
virtual
machines.
On
aws
and
gcp,
with
the
term
we
we
have
provisioned
some
applications
on
both
environments.
With
that
we
we
have
seen
the
zero
trust
security
model
with
neutral
has
automatically
been
provisioned
we've
seen
the
traffic
permissions
we
can
also
explore.
B
We
can
also
explore
the
gui
to
to
determine
to
determine
our
our
policies
and
our
routing
rules
by
the
way
or
the
cli
we've
seen
the
traffic
permissions
acl
we've
seen
traffic
routing
for
data
for
zone
shifting
across
vms
and
containers,
and
we
took
a
look
at
the
gui
that
kuma
provides
when
it
comes
to
understanding
what
is
going
on
when
it
comes
to
our
resources.
So,
thank
you
so
much
and
if
you
have
any
questions,
I
believe
that
now
we're
starting
our
q
a
session.
A
B
I
forgot
sorry.
Sorry,
sorry,
sorry,
I
forgot
I'm
so
sorry
about
this.
I
forgot
about
one
thing.
Starting
from
tomorrow,
we
have
our
kong
summit.
It's
a
digital
and
free
event
where
we're
going
to
be
exploring
more
and
more,
how
you
know,
technologies
like
huma
that
are
vendor
neutral
part
of
cncf
are
going
to
be
working
with,
for
example,
the
con
gateway
and
we're
going
to
be
seeing
the
full
stack
on
how
that
you
know
works
together
when
it
comes
to
even
more
complex
networking,
networking
topologies.
A
B
So
there
is.
There
is
a
lot
that
goes
into
this,
but
the
logs
they
they
provide.
You
know
we
also
provide
examples
on
on
on
how
to
visualize
these
logs
using
logstash,
but
basically
the
logs
are,
are
going
to
be
creating
a
new
line
for
each
request
that
is
being
either
sent
or
received
from
inside
the
mesh,
and
usually
logs
are
going
to
be
applied
in
combination
to
traffic,
metrics
and
traffic
traces
to
have
a
better
context
of
of
the
observability
within
the
service
mesh.
B
So
there
is
a
lot
of
work
that
has
been
done
when
it
comes
to
observability
and
logs
metrics
and
traces
are
basically
usually
typically
being
used
together
to
provide
the
full
picture
of
our
traffic,
and
this
is
l4,
so
it
is
working
for
any
system.
That's
part
of
the
mesh,
including
databases,
including
log
collectors,
anything
that
anything
that
listens
or
makes
requests
over
tcp.
A
B
We
are
making
sure
that
the
overheads
are
quite
small,
because
we,
you
know,
even
with
kong,
we
we
understood
that
being
able
to
support
smaller
instances
for
our
cloud
vendors.
It
is
going
to
be
a
big,
a
big.
You
know,
component
in
the
overall
roi
of
using
a
service
mesh.
I
know
that
your
boss
is
looking
at
the
overall
expense
when
it
comes
to
deploying
a
mesh,
and
so
we
built
this
in
such
a
way
that
it
could
run
on
smaller
machines
and
could
be
very
optimized
for
the
global.
B
The
only
thing
that
we
need
is
a
cluster
of
kubernetes
or
virtual
machine
that
is
going
to
be
accepting
the
resources
into
the
global
control
plane.
You
can
run
the
global
control
plane
in
a
highly
available
way
and
the
remote
control
planes
and
the
global
control
planes
can
be
scaled
independently,
which
means
that
if
you
have
some
zones
that
have
more
data
planes
than
others,
you
can
scale
them
independently.
You
do
not
have
to
scale
them
all
at
once
the
same
way.
B
So
if
anything,
it
gives
us
a
little
bit
more
flexibility
when
it
comes
to
running
a
distributed
service.
Mesh
across
multiple
clouds
and
across
multiple
zones,
so
the
drawbacks.
If
I
have
to
find
one,
it
is
that
we
have
to
find
a
place
to
deploy
the
global,
so
the
global
would
be
yet
another
component
that
needs
to
run,
but
it's
inevitable.
If
we
want
that
automatic
synchronization
across
different
remote
zones,
other
service
meshes,
for
example,
they
do
not
provide
that
automatic
synchronization,
which
means
that
you're
on
the
hook
for
building
it
with
kuma.
B
B
Yeah,
so
in
my
demo,
the
global
control
plane
cluster
was
not
processing
any
data
whatsoever
so
that
we
were
using
the
global
to
apply
our
mesh
policies
like
mutual
tls,
like
routing
like
traffic
permission,
but
the
global
per
se
was
never
on
the
execution
path
of
our
requests.
The
requests
were
going
directly
from
one
zone
to
another
without
going
to
the
global,
and
so
we
we
we
are
keeping
that
outside
of
the
the
global
control
plane
it
is.
B
A
B
Yeah,
so
I
think
I
did
actually
answer
the
question
so
yeah,
so
the
the
the
data
never
ever
reaches
the
global
control
plane.
The
global
control
plane
only
communicates
with
the
remote
ones.
The
remote
control
planes
are
the
ones
that
are
in
charge
of
the
run
zone
and
the
proxy
in
the
requests
are
actually
never
even
hitting
the
remote
control
planes
in
the
first
place,
they're
going
directly
from
one
data
plane
to
another,
the
remote
control
planes.
A
B
If
the
global
control
plane
goes
down,
the
remote
control
planes
are
going
to
be
having
the
latest
snapshot
of
the
service
mesh
resources
that
that
we
have
applied.
So
if
the
global
control
plane
goes
down,
nothing
will
happen
on
our
remote
zones,
and
that
is
one
of
the
reasons
why,
having
global
and
remote,
it
actually
comes
in
quite
handy
for
a
couple
of
reasons.
B
Yes,
we
get
that
automatic
synchronization,
but
then
also
we
get
a
little
bit
more
high
availability,
because
each
remote
control
plane
is
fully
responsible
of
the
run
zone
and
if
the
global
goes
down,
it's
not
affecting
and
if
a
remote
goes
down
as
well,
it's
not
affecting
other
zones
so
effectively,
it's
as
if
each
zone
is,
is
living
independently
from
each
other.
But
when
the
global
control
plane
goes
back
online,
then,
if
you're,
applying
new
service
mesh
resources,
we're
going
to
be
we're
going
to
be
propagating
those
as
soon
as
it
comes
back
online.
B
So
the
only
problem
you
would
have
is
not
being
able
to
change
the
state
of
your
mesh
resources
because
we
need
the
global
for
that.
But
again,
the
global
can
also
be
configured
in
a
highly
available
way,
and
so
we
can
determine
we
can
deploy
in
such
a
way
that
we
can
tolerate
those
kind
of
failures
by
distributing
the
global
control
plane
as
well.
A
B
If
you
want
to
run
the
demo,
I
just
ran,
you
can
go
on
comma.your,
slash,
install.
It
provides
installation
for
pretty
much
different
different
environments
like
I
said
it's
not
just
kubernetes,
but
it's
also
virtual
machines.
Of
course
it's
helm,
open
shift
and
so
on
and
if
you
go
on
documentation
and
you
go
on
multi-zone
mode
under
deployments,
we
we
show
the
instructions
that
you
can
run
to
install
the
global
control
plane
to
install
the
remote
control
plane
and
then
to
activate
the
remote
control
planes.
A
B
Today,
we've
seen
a
very
complex
deployment
of
service
mesh.
Of
course,
this
can
also
be
used
in
a
standalone
mode
which
have
not
been
showing,
which
is
the
more
traditional
service
mesh
deployment
in
one
zone.
One
cluster
there's
only
one
control
plane,
there's
no
global,
no
remote,
there's
only
one
control
plane
and
then
you
have
data
planes
connecting
to
it.
B
B
A
B
Basically,
you
can
you
can
type
this
one
line
of
one
you
can
use
our
cli,
you
can
use
the
helm
charts,
but
basically,
if
you
want
to
install
qma
in
one
control
plane,
it's
schema
calorie,
install
control,
plane
you
pipe
these
inside
of
kubernetes
cube
cattle,
and
that's
it
there
is.
There
is
going
to
be
a
standalone
deployment
of
qma
within
that
one
specific
zone.
Now
the
thing
the
difference
between
standalone
mode
and
multi-zone
mode
is
that
in
multi-zone
you
can
add
more
remote
zones.
B
You
can
add
more,
you
know
you
can
distribute
the
mesh,
whereas
in
standalone
you
only
have
one
control
plane
inside
inside
of
the
cluster.
You
can
scale
it
you
can.
You
know,
run
it
within
the
context
of
that
cluster,
but
unless
you
have
a
flat
networking,
topology
you're
not
going
to
be
able
to
support
other
other
zones
unless,
like
I
said
you
have
a
flat
network
topology,
so
you
have
class,
you
have
data
planes
running
outside
of
that
specific
cluster
that
can
directly
communicate
with
the
control
plane.
B
B
B
B
B
Let's
see
this
time,
it
should
work
there
we
go
so
now
we
have
kuma
running
in
stand-alone
mode
inside
of
my
mini
cube,
and
this
will
create
a
human
system
namespace
and
inside
of
the
schema
system.
Namespace
we're
going
to
be
having
the
control
plane,
which
is
now
getting
downloaded
and
going
up
and
running,
and
so,
if
I
do,
if
I
do
deploy,
if
I
do
port
forward
this
local
control
plane
this
local
control
plane
from
my
mini
cube,
we
will
see.
B
Control
plane,
we
will
see
my
standalone
control
plane
up
and
running.
I
know
that
it's
standalone,
because
if
I
go
to
the
gui,
it
says
standalone
up
here
in
the
top
right
corner.
So
this
is
a
standalone.
It's
a
standalone
kubernetes
that
only
has
one
zone,
we
cannot
add
any
more
zones,
and
so
we
can
deploy.
We
can
deploy
the
demo
application
and
automatically
will
be
injecting
the
car
and-
and
this
would
be-
and
this
would
be
the
the
you
know-
the
standalone
mode
of
of
running
or
running
the
service
mesh.
B
B
We
enabled
security
across
the
across
multiple
zones
and
kuma
at
that
point
enabled
automatically
cross
zone
communication.
Of
course,
you
can
enable
or
disable
this
behavior
by
then
applying
a
traffic
routing
rule
that
determines
you
know.
If
you
really
want
that
traffic
to
be,
you
know
to
be
happening
across
multiple
zones,
and
if
you
want
that
traffic
to
stay
within
a
zone
and
by
the
way
here,
we
automatically
injected
the
control
plane
in
standalone
mode,
and
we
can
see
that
the
demo
application
is
up
and
running
and
the
data
planes
are
online.
B
A
B
That
this
is
a
very
good
question
and
that
it
will
be,
but
not
now
now,
if,
if
we
in
order
to
change
to
change
from
standalone
to
multi-zone,
we
effectively
have
to
start
a
new
deployment
of
the
mesh
and
then
make
those
workloads
part
of
of
the
new
deployment
of
the
service
mesh.
So
we
cannot
so
far.
We
cannot
transition
a
standalone
control
plane
to
a
multi-zone
control
plane.
Just
like
that,
but
good
news.
It
is
something
that
has
been
requested
before
and
it's
obviously
something
that
we
want
to.
B
We
want
to
change
in
order
to
enable
a
more
easier
consumption
of
cuma
for
those
environments
that
over
time
may
be
growing
across
multiple
zones.
So
there
is
a
there
is
a
so
that's
one
answer,
and
the
second
answer
is:
if
you
know
that
you're
running
kuma
in
something
that
is
going
to
become
multi-zone,
then
I
suggest
deploying
it
as
a
multi-zone
since
day
one
if
we
think
that
that
could
be
an
option,
but
we're
working
on
on
this
to
make
it
simple
to
to
upgrade
a
standalone
control
plane
into
a
global
control,
plane.
A
Okay,
well,
that
just
about
does
it
for
all
the
time
that
we
have
today,
I'd
like
to
thank
marco
again
for
a
wonderful
presentation
and
demo,
and
thank
you
to
everyone
for
taking
time
out
of
their
day
for
joining
us
today.
As
I
said
before,
today's
webinar
and
present
and
slides
will
be
on
the
cncf
website
at
cncf,
dot,
io,
slash
webinars.