►
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
Service mesh is a new pattern to build reliable distributed and decoupled applications, but often too complicated to implement with 1st generation control planes. Kuma takes a new approach to service mesh in order to build modern architectures across a large variety of platforms, including Kubernetes and VMs.
In this webinar, we’ll walk you through Kuma, a new open source control plane for service mesh. Built on top of Envoy, Kuma can instrument any L4/L7 traffic to secure, observe, route and enhance connectivity between any service or database. It can be used natively in Kubernetes via CRDs or via a RESTful API across other environments, and it doesn't require a change to your application's code in order to be used.
A
All
right
we're
going
to
go
ahead
and
get
started.
I'd
like
to
thank
everyone
who
is
joining
us
today.
I
welcome
today's
webinar
kuma
build
secure
and
observe
your
modern
service.
Mesh
I'm
Taylor
Wagoner
from
the
CNCs
and
I'll
be
moderating.
Today's
webinar
we'd
like
to
welcome
our
presenters
today,
Marko
Palladino
CTO
and
co-founder
at
Kong
and
Kevin
Chen
developer
advocate
comm.
A
Before
we
get
started
and
there's
a
few
housekeeping
items
to
go
over
during
the
webinar
you're
not
able
to
talk
as
an
attendee,
there
is
a
Q&A
box
located
at
the
bottom
of
your
zoom
screen.
Please
feel
free
to
drop
your
questions
in
there
rather
than
the
chat
window
and
we'll
get
to
as
many
as
we
can
at
the
end
or
throughout
the
call.
Also,
this
is
an
official
webinar
of
the
CNCs
and,
as
such,
it's
subject
to
the
CNC
F
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
the
Q&A.
A
B
Thank
you
so
much,
and
thanks
for
having
the
opportunity
of
being
here,
it's
amazing
to
be
able
to
target
the
CN
CF
audience
and
tell
them
what
we've
been
working
on
at
Cog.
So
I'm
here
with
the
with
Kevin
Tran
developer,
advocate
at
Kong.
I
will
start
by
giving
you
know
the
following
agenda:
by
introducing
service
management
kuma
that
were
going
to
be
seeing
a
live
demo
of
kuma.
B
So
we're
going
to
be
firing
up
the
terminal
and
see
kuma
in
action
and
then,
of
course,
there's
going
to
be
some
time
for
question
and
answers
at
the
end.
But
you
can
ask
questions
in
the
meanwhile
via
the
Q&A
function
of
zoom.
If
you
wish
and
then
at
the
end,
we're
going
to
be
accepting
new
questions
and
answering
the
existing
questions.
B
So
there
is
something
happening
in
the
world
and
we're
seeing
it
every
day
around
us.
Every
product
in
the
world
is
becoming
a
digital
product
and
once
they
become
digital,
they
become
cognitive.
We
focus
a
lot
on
technology
and
platforms,
but
really
what's
driving
all
of
this.
What
we
are
really
trying
to
do
is
growing
our
business
and
growing.
The
business
is
the
main
driver
to
every
transformation.
B
B
The
application
teams
that
are
focusing
on
building
the
best
products
rely
on
us,
the
architects
to
provide
the
best
infrastructure
for
their
applications
to
use
and
I
like
to
say
that
running.
A
modern
infrastructure
is
like
running
a
city.
The
architects
build
the
underlying
infrastructure,
the
roads,
the
bridges
that
the
teams
can
now
use.
And
then,
when
everything
is
in
place,
the
teams
can
finally
focus
on
building
their
products.
They
can
focus
on
the
things
that
matter,
the
users
and
the
customers
effectively.
B
The
architecture
that
we're
building
for
them
is
a
partner
to
their
success,
but,
like
running
a
city,
we
need
to
connect
the
different
places
together.
We
need
to
enable
the
flow
of
information
from
one
building
to
another.
We
need
to
enable
that
traffic.
We
need
electricity,
we
need
security,
we
need
police
departments,
we
need
routing,
we
need
street
lights,
street
signs
and
the
more
buildings
we
built,
the
more
people
we
have
in
motion
and
the
more
infrastructure
we
need
to
make.
B
B
They're
going
to
be
creating
fragmentation,
they're
going
to
be
creating
bits
of
architecture
within
their
applications,
which,
in
turn
will
make
them
less
productive
over
the
long
term.
Sometimes
some
teams
they
are
not
even
whirring
up
they're,
not
doing
anything
at
all
and
that
will
hurt
the
business.
A
real
functioning
city
has
to
be
built
by
somebody
in
order
to
grow
the
business
in
an
effective
way,
but
this
can
also
be
very
challenging.
Sometimes
different
teams
are
running
on
different
platforms.
B
It's
all
about
connectivity
as
we're
decoupling
and
distributing
our
applications.
We
are
replacing
the
reliability
of
the
CPU
with
the
unreliability
of
the
network.
This
is
a
key
point.
The
reliability
of
the
CPU
the
function
calls
within
our
applications,
it's
being
replaced
with
the
unreliability
of
the
network,
but
likewise
with
our
data
centers,
we
don't
want
to
build
our
own
data
centers.
We
want
to
leverage
the
cloud.
Likewise,
we
don't
want
to
be
building
our
own
network
management.
B
We
want
to
be
leveraging
something
that
can
do
that
for
us
and
that's
why
there
are
patterns
that
can
help
us
with
that.
Introducing
service
mesh
service
mesh
fundamentally
improves
connectivity
among
different
services
within
our
architecture,
and
the
world
service
mesh
implies
having
a
mesh
of
services,
which
is
certainly
the
case
more
often
than
not,
but
really
the
benefits
of
service
mesh,
the
benefits
of
having
an
improved
connectivity
and
improved
observability
and
improved
security
among
all
of
these
different
services.
It's
something
that
we
can
benefit
regarless
of
how
many
services
we're
running
in
our
systems.
B
It
can
be
a
thousand
or
can
be
a
model
it
talking
to
a
database.
Even
in
that
scenario,
we
still
want
connectivity
to
be
working
and
we
don't
want
the
teams
to
be
doing
that
for
us
service
mesh
until
now
as
being
very
hard
to
implement.
You
know
we
work
with
of
practitioners,
lots
of
operators
and
they're
all
very
confused
when
it
comes
to
implementing
service
mesh
and
into
looking
at
the
solutions
that
are
out
there.
B
So
it's
for
both
and
we
did
a
significant
effort
to
make
sure
that
we
could
build
an
abstraction
layer
that
can
work
simultaneously
on
traditional
infrastructure,
virtual
machine
bare
metal
as
well
as
very
easily
run
on
kubernetes
and
modern
architectures
kuma
effective.
It's
a
control
plane
for
service
mesh.
It
relies
on
it's
built
on
top
of
envoy
and
it
relies
on
envoy
for
the
cycler
proxy
functionality.
B
For
those
of
you
who
are
not
familiar
with
service
mesh,
the
concept,
it's
very
simple,
it
doesn't
have
to
be
hard
every
time
we
make
a
request
from
a
service
to
another
service.
That
request,
because
of
the
network
can
fail.
That
request
is
by
default,
unsecure
unless
we
protected.
That
request
needs
to
be
monitored,
needs
to
be
logged
needs
to
be
traced
so
that,
if
it
fails,
we
know
what
happened
and
we
can
improve
it
now.
B
Traditionally,
the
way
developers
have
dealt
with
these
issues
are
twofold:
either
they
build
more
code,
they
write
more
code
in
their
applications
so
that
they
can
create
smart
clients
if
you
wish
that
can
make
those
requests
to
the
outer
world.
But
that
means
more
code
that
means
being
able
to
maintain
and
update
the
code.
That
means
technical
depth.
That
means
replicating
those
smart
clients
in
two
different
languages.
If
we
do
adopt
more
than
one
framework
or
language
within
our
system,
or
even
worse
than
that,
developers
were
not
bothering
to
create
anything
like
that.
B
So
the
connection
fails,
the
application
fails
and
we
lose
business
either
we
built
something
ourselves
or
we
don't
and
we
hurt
the
business
and
so
because
we
don't
want
to
write
code
right
the
more
code.
We
write
the
more
technical
depth
we
create.
We
want
to
be
able
to
outsource
that
functionality
to
something
else,
and
this
is
where
service
mesh
comes
into
play
with
service
mesh.
We
can
deploy
and
out
of
process
proxy
that
can
run
alongside
our
services
and
the
proxy
will
intercept
every
outgoing
request
that
the
service
makes
and
from
then
on.
B
It
will
take
care
of
that
request.
That
means
that,
from
a
developer
standpoint,
if
I'm
building
an
app
I
can
make
a
request
and
make
an
assumption,
the
assumption
is
that
that
request
will
work
everything
else.
It's
taken
care
of
by
this
cycler
proxy.
So,
as
a
team
developer,
I
can
focus
on
building
the
actual
product.
B
I,
don't
have
to
worry
about
making
sure
that
all
of
those
requests
are
going
to
be
working
and
the
more
decoupled
the
more
distributed
we
become,
the
more
requests
we're
going
to
be
making
on
the
other
end,
when
we
receive
a
request,
we'll
have
another
proxy
that
receives
that
request
and
terminates,
for
example,
mutual
TLS
or
logs
the
the
request
to
a
third
party
business
intelligence
tool
or
enforces
traffic
permissions
on
the
receiving
end.
We
receive
the
request
in
the
application
and
as
a
developer.
B
Building
the
app
all
I
need
to
know
is
that
at
one
point,
I
will
receive
a
request
and
that
request
will
be
taken
care
of
so
that
when
we
talk
about
connectivity
either
making
outbound
requests
or
receiving
email
requests
as
an
application
developer.
I
don't
have
to
worry
about
that.
This
is
what
service
mesh
tries
to
fix,
and
really
this
is
the
benefit
that
we
can
get
on
any
platform
now
Tanner's
kubernetes,
as
well
as
virtual
machines,
and
this
is
a
benefit
that
we
can
get
no
matter
how
many
services
were
running
in
our
system.
B
This
is
all
l4,
which
means
that
any
traffic
to
any
database,
any
caching
system
to
any
other
service
using
any
protocol
can
get
benefits
out
of
this
pattern,
but
the
more
sidecar
practices
we
have
and
the
harder
it
is
to
configure
them
all
we
don't
want
to
manually.
We
deploy
your
restart
to
reconfigure
the
cycle
proxies.
We
want
to
be
able
to
do
that
from
a
centralized
location
and
then
push
that
configuration
to
the
cycler
proxies
or
allow
the
cycler
proxies
to
retrieve
it,
and
that
is
really
the
role
of
the
control
plane.
B
The
control
plane
is
the
source
of
truth
for
all
the
configuration
that
the
cycler
proxy
will
have
to
dynamically
fetch
or
receive
or
ask
in
order
to
be
able
to
enforce
all
the
features
we
want
to
enforce.
Think
of
the
control
plane
really
has
that
source
of
truth
for
all
the
configurations,
so
we
use
the
control
plane
to
push
this
configuration
and
then
eventually,
in
a
consistent
in
eventually
consistent
way,
that
configurations
will
be
applied
to
the
cycle
proxies
it's
a
very
similar
concept
to
you
know:
control
planes
and
data
planes.
B
They
come
from
the
networking
space.
You
know
back
in
the
days
in
our
physical
data
centers
we
used
to
have
many
racks,
each
Rack
had
hundreds
of
switches
and
then
the
switches
in
order
to
be
configured
relied
on
a
control
plane
to
make
that
configuration
applicable
to
that
same
thing,
but
applied
it
to
software.
So
what
Kumar
really
is
it's
a
universal
control?
B
Plane
lots
of
organizations
are
building
their
own
control
planes
because
existing
control
planes
have
have
a
few
problems
either
they're,
focusing
on
one
platform
only,
but
in
an
enterprise
organization
we
know
that
we
don't
run
only
on
one
platform
or
they
are
a
little
bit
too
hard
to
use
and
they
have
a
very
high
operational
costs.
Lots
of
moving
parts.
So
we
built
Kumar
with
simplicity
in
mind.
B
We
built
kuma
to
be
able
to
run
everywhere
and
we
built
kuma
to
be
able
to
be
simple
to
use,
and
we
can
see
that
in
the
demo
later
today,
so
the
control
plane
Kumaon
will
talk
to
the
sidecar
invoice
and
all
of
these
happens
in
our
integrated
experience.
You
are
not
left
wondering.
Okay,
so
I
need
to
get
amboy
separately
and
then
I
need
to
start
kuma
separatory.
All
of
these
is
being
provided
with
a
nice
experience.
B
Kumba
can
run
on
top
of
any
platform.
It
runs
in
containers.
It
can
run
on
kubernetes
as
well
as
running
on
Universal.
That's
why
we
call
it
Universal.
It
can
run
on
top
of
any
other
platform
like
real
pro
machines
or
bare
metal.
So
you
can
deploy
these
on
RedHat.
You
can
deploy
your
on
AWS
ec2
instance,
for
example,
and
have
the
same
benefits
of
service
match
across
the
entire
organization.
Different
teams
are
going
at
different
speeds.
Different
teams
are
going
to
be
using
different
platforms,
but
the
service
mesh.
B
B
If
you're
not
familiar
with
what
Kong
King
does
we
are
the
makers
of,
among
other
things,
of
Kong
gateway,
which
is
a
one
of
the
most
popular
open
source,
API
gateways
today,
and
we
built
cumin
as
a
comp
as
another
open
source
project
that
is
going
to
be
joining
the
family
of
our
open
source
projects
like
Kong
like
insomnia,
in
order
to
be
able
to
tackle
the
connectivity
problem
and
when
we
spoke
with
our
customers
and
with
our
users
really.
The
most
important
feedback
we
have
received
was
existing
service
meshes
are
too
hard
to
operate.
B
We
don't
want
to
start
a
new
cluster
for
each
team,
but
we
want
to
be
able
to
start
one
control
claim
and
from
that
one
control
plane.
We
want
them
to
provision
different
meshes
for
each
team.
This
mix
makes
it
easy
to
do
a
couple
of
things
number
one.
It
makes
it
easier
to
run
kuma
in
a
enterprise
environment,
so
you
only
have
one
thing
running
as
opposed
to
having
multiple
clusters.
B
B
It's
very
simple
to
use
we're
going
to
be
seeing
this
with
Kevin
later
today,
but
you
can
install
Chrome
add-on
kubernetes
route,
one
command,
it's
very
easy
to
start
on
any
other
platform
as
well.
Cubot
provides,
among
other
things,
provides
identity
to
your
workloads
out-of-the-box.
It
allows
us
to
implement
traffic
permissions
so
that
we
can
determine
what
services
can
consume
other
services.
You
know
we
can
implement
security
when
it
comes
to
that
as
well
as
it
implements
traffic
logging
so
that
we
can
extract
observability
and
metrics
out
of
our
infrastructure
out
of
the
box.
B
We
can
then
decide
to
push
this
matrix
into
any
existing
business
intelligence
tool.
We
might
be
using
think
of
spelunk,
think
of
log
stash
and
so
on.
So
we
can
push
this
to
any
third
party.
Tcp
server,
as
well
as
it
provides
integration
with
conjugate,
waken
gateway,
operates
in
a
north-south
ingress
capacity
and
by
using
the
open
source
conjugate
way
with
open
source
command.
B
We're
now
able
to
take
care
of
the
full
lifecycle
of
the
requests
were
able
to
protect
in
secure
connectivity
within
the
data
center
and
then
we're
able
to
expose
those
services
to
other
teams
or
other
data
centers
in
the
organization,
and
that
goes
through
the
conch
ingress,
and
you
know
it
really
much
more.
You
know,
kuma
is
a
is
a
modern
project
that
is
really
breathing
and
living
thanks
to
the
community
and
community
contributions.
So
I
encourage
everybody
to
go
check
the
github
repository
and
give
it
a
try.
B
Long
story
short
all
the
work.
The
teams
have
been
doing
to
fix
that
connectivity
to
secure
that
connectivity
to
make
sure
that
they're
those
requests
never
fail,
can
now
be
removed
from
the
applications
and
can
be
delegated
to
kuma
and
envoy.
So
it
really
makes
makes
it
easier
to
think
about
improving
connectivity
and
connectivity
by
the
way
is
a
problem
that
will
increase
over
time
the
more
teams
we
are
bored,
the
more
products
we
create,
the
more
platforms
we
decide
to
support
right.
B
Kuma,
like
I
mentioned,
can
run
on
two
different
platforms
in
two
different
modes.
If
you
wish
it
can
run
natively
on
kubernetes.
So
when
Combe
is
being
deployed
on
kubernetes,
it
automatically
injects
the
sidecar
into
your
applications
without
having
to
change
them
into
your
pods
without
having
to
change
them.
It
automatically
detects
all
the
data
planes
and
really
is
a
1:1
command
to
install
install
cumin
in
run
kuma
because
cumin,
because
we
took
that
feedback
from
our
users
and
customers
to
make
cumin
easier
to
operate.
B
B
In
order
to
be
able
to
store
all
the
configuration
that
you
are
applying
on
kubernetes,
you
can
configure
kuma
a
hundred
percent
by
using
kubernetes
CR
these,
and
that's
really
the
only
way
you
can
configure
common
kubernetes,
whereas
on
Universal
you
can
configure
kuma
either
by
using
the
API
the
HTTP
API.
Didn't
we
provide,
as
well
as
the
CLI
client
that
can
be
integrated
with
your
CI
CD
workflow,
the
CLI
client,
effectively
it
consumes
the
HTTP
API
to
perform
all
the
functions,
so
you
can
version.
B
B
This
is
lots
of
information,
hopefully
with
the
demo
that
Kevin
will
provide
we're
going
to
be
seeing
this
live
running
live
it's
very
simple.
We
put
lots
of
focus
in
making
things
simple,
without
excluding
the
possibility
of
going
deeper
in
those
more
complex
use.
Cases
where
perhaps
you
want
to
manually
configure
the
underlying
Envoy,
so
kuma
will
provide
that
nice
abstraction
those
nice
primitives
to
do
pretty
much
all
the
things
edit.
B
What
80%
of
the
architects
wanted
to
implement
and
then,
if
we
wanted
to
go
deeper,
there
is
a
way
to
do
that
as
well
right.
So
kuma
wants
to
be
simple
and
easy
to
use
without
removing
that
powerful
capabilities
that
the
underlying
technology
is
providing
a
more.
In
fact,
we
are
contributing
to
envoy
as
well,
so
we
are
contributing
to
the
AMA
we're
part
of
the
Envoy
ecosystem
as
well
as
we
are
building
common.
B
So
with
that
said,
I
spoke
from
way
too
long
now,
I
want
to
leave
I
want
to
leave
the
I'll
leave
the
screen
share
to
to
Kevin,
so
that
Kevin
can
can
show
you
how
kuma
works
live
and
again.
If
you
have
any
questions
about
everything
that
I've
said
or
anything,
that
Kevin
is
going
to
be
saying,
please
ask
those
questions
using
the
Q&A
tool
from
zoom
and
we're
going
to
be
answering
all
of
those
questions
at
the
end
of
this
presentation.
A
C
I'm
going
to
be
giving
a
demo
on
how
kuma
works
alongside
a
sample
application
that
we
built.
So
what
we
have
here
is
a
sample
marketplace,
application
that
will
be
built
out.
You
see
on
the
Left,
we
have
our
browser,
which
is
just
a
front-end
UI.
They
can
access
the
application
and
what
the
browser
access
is
the
API
service.
The
API
service
is
a
node
application
that
makes
it
requested
to
other
services
within
your
app
within
your
infrastructure.
A
C
First,
we
have
a
elasticsearch
which
stores
all
the
items
that
you
might
be
selling
within
your
marketplace
and
the
second
one
is
the
Redis,
so
the
Redis
is
isn't
trying
to
store
all
the
reviews
that
pertain
to
the
items
that
you
are
selling
just
like
how,
if
you
shop
on
amazon.com,
you
can
look
at
the
reviews
for
each
item.
Kuma
marketplace
also
supports
allowing
people
to
understand
what
they
are
buying.
So
if
we
jump
back
to
the
front-
and
you
are
here-
I
have
the
application
up
and
running.
This
is
without
kuma
alongside
it.
C
C
So
this
is
a
very
basic
application
with
if
we
go
back
to
the
diagram
with
three
services
and
it
with
three
services.
Even
with
such
simplicity,
you
still
have
to
implement
the
log.
You
know
the
traffic
logging,
the
identity
management,
the
traffic
permission
logic
within
each
one
of
the
services
and
what
we
want
to
do
with
kuma
is
abstract
that
kind
of
redundancy
of
code
and
time
and
allow
it
and
find
a
simpler
way
to
deploy
that
logic
and
enabled
you
to
move
faster
and
and
secured
your
your
your
application.
C
So
let's
go
ahead
and
dive
right
into.
How
would
you
install
kuma
and
Marco
gave
you
a
glimpse
earlier,
but
it
really
is
as
simple
as
using
the
kuma
CTL
command
right
now,
I
already
have
it
all
installed,
so
you
can
and
you
can
download
kuma
at
kuma.
The
IO
I
already
have
a
download
and
installed
so
I
can
go
into
the
bin.
Folder
you'll
see
that
I
have
kuma
CTO
here.
So
with
kuma
CTO
you'll
see
you
can
check
the
available
command.
C
A
C
So
with
that,
you'll
see
that
I'll
install
kuma
with
alter
necessary,
CRD
part
services
deployment
necessary
within
one
step
so
that,
as
Marco
said
earlier,
it's
fairly
straightforward
for
you
to
get
started.
If
you
wanted
to
play
kumar
kubernetes
and
with
that
well,
we're
deploying
it.
Let's
take
a
look
at
our
pods
within
the
namespace
of
kuma
system,
which
is
where
everything
will
sit
and
you'll
see.
Everything
is
already
up
and
running.
We
have
the
control
plane
itself,
which
will
be
in
charge
of
when
we
increase
the
font,
a
little
so
maybe
easier
see.
C
Okay,
so
right
now
we
have
our
application
running
up
here.
This
is
what
we
previously
saw
and
important
for
in
the
application.
But
you
see
everything
only
still
has
one
container
running
outside
it,
or
this
one
has
two
because
there's
a
front
and
a
back
end
service.
But
it's
missing
that
sidecar
Posse.
So
in
order
to
have
for
the
kuma
injector
to
take
to
inject
those
cycler
proxies,
we're
gonna
have
to
delete
these
existing
pods
and
let
it
be
deploy.
C
C
So
let's
take
a
look
at
our
pods
in
the
demo,
so
everything
is
up
and
running
again,
but
now
you
can
see
immediately
that
all
of
them
have
an
extra
container
running
alongside
them,
and
that
is
because
the
site,
the
kuma
injector,
is
able
to
recognize
that
these
services
need
to
have
a
sidecar
proxy
so
injects
that
additional
container
alongside
it.
So
if
we
go
back
to
the
diagram.
C
Essentially,
what
we
did
within
one
step:
one
CLI
command:
we
installed
kuma
and
it
it
deploys
the
additional
sidecar
proxy
necessary.
So
now,
whenever
you
want
to
configure
those
envoy
sidecar
proxies,
you
simply
have
to
talk
to
the
kuma
control
plane
that
sits
in
the
middle
of
them
and
it
will
handle
all
the
additional
steps
and
configurations
for
you.
So
your
envoy
proxies
awesome.
C
So
before
we
add
neutral
TLS,
let's
actually
take
one
more
step
and
let's
explore
kuma
CTO
little
more
a
little
more
because
that
tool
can
offer
you
a
lot
more
control
over
your
control
plank.
But
right
now
our
kuma
control
plan
use,
you
can
see,
is
sitting
within
a
kubernetes
cluster.
So
we
kind
of
we
have
the
port
for
it
to
allow
kuma
CTO
access
to
it.
C
So,
let's
port
forward
our
our
control
point,
so
we're
just
going
to
do
a
cumulus
ETL
port
for
the
control
plane,
pod
name
on
the
top
right
here
in
the
main
space
of
kuma
system
and
the
port
we
want
to
expose
is
5
6,
8
1.
So
once
we
configure
the
port
for
that,
we
can
now
configure
kuma
CTL
to
fetch
that
address
at
this
control
point.
C
So
let
me
go
grab
that
command
you'll.
This
is
going
to
be
within
the
kuma
repository,
so
you
can
find
it,
but
this
is
what
I'm
going
to
do.
Is
you
can
use
kuma,
CTL,
confident
roll
points,
and
you
can
add
that
control
point
address
so
right
now,
I'm
exposing
it
to
localhost
5
6
8
1,
but
you
can,
you
can
could
use
kuma
CTL
to
control
any
comfortable
point.
That's
it
anywhere
as
long
as
you
have
access
to
that
address,
so
I'm
going
to
add
a
new
name
to
it.
C
We're
gonna
call
kubernetes
you'll,
see
that
it
automatically
adds
a
control
plane
of
mini,
cube,
kubernetes
and
switches
to
that
as
the
active
control
plane.
So
now
we
do
kuma
CTL
get
meshes
awesome.
We
can
see
the
default
mesh
that
is
enabled
when
we
deployed
Kula
and
we
take
it
one
more
one
step
further
and
let's
look
at
the
data
planes
right.
If
we,
if
we
look
at
the
diagram
we
have
here,
we
have
three
data
points
and
that
should
be
detachable.
That
should
be
shown
with
a
kuma
CTL
man.
C
C
So
now
everything
is
working.
Fine,
the
application
itself
is
still
working.
Fine
right,
nothing,
nothing
has.
Oh
I
need
a
port
for
it,
I'm
sorry,
so,
let's
port
for
our
application.
After
we
redeployed
it
and
nothing
has
changed
except
traffic
is
being
routed
through
Envoy
the
side
card
proxy
and
we
have
an
enabled
mutual
TLS.
We
don't
have
to
configure
any
traffic
permission
yet
so
soul
work,
as
is
right,
the
review
still
work
and
then
the
elastic
search
services
endpoint
still
works
as
well.
So
now
let's
go
ahead
and
add
mutual
TLS.
C
So
to
add.
Mutual
TLS
is
a
very
important
capability
and
that
is
kind
of
one
of
the
core
features
of
server
smash:
its
ability
to
encrypt
all
your
traffic
among
services
for
a
service
to
service.
So
we
are
going
to
go
ahead
and
use
this
deployment,
and
here
you'll
see
that
I'm
simply
just
saying
for
the
mesh
resource,
which
we
already
know
exists.
The
default
mass
resource,
I'm,
gonna,
say
mutual
CLS
is
enabled
to
true
and
with.
B
C
Properly
so
you'll
see
that
I'm
configuring,
the
traffic
permission
crd
with
I'm,
giving
a
name
of
everything
so
I'm,
basically
saying
for
the
rules,
I
wanted
any
source
to
match
any
destination.
So
essentially
any
service
can
talk
to
any
other
service.
With
that
CRD
in
place,
that's
we
can
use
kuma
CTL
to
check
that
traffic
permissions.
C
We
can
see
that
China
promotion
is
indeed
applied
to
the
control
plane.
The
control
plane
would
now
enforce
it
and
apply
that
to
all
the
data
planes
out
there.
So
going
back
to
our
our
front-end
application,
our
application
works
again
and
that's
how
easily
you
can
enable
mutual
TOS
cross
all
your
services.
C
We
can
check
our
reviews.
Endpoint
reviews
work
as
well
awesome.
So
up
to
this
point,
it
really
doesn't
take
a
lot
of
effort
in
order
for
you
to
secure
your
service
of
service
traffic
with
kuma
right
now.
All
the
traffic
that
runs
between
API
service
and
elasticsearch
is
encrypted,
also
sort
of
all
the
traffic
running
between
your
API
servers
and
Redis.
A
C
So
right
now
we
have
actually,
if
we
take
a
look
at
cube,
CTO
get
namespace,
we
have
a
logging
service
running
and
that
essentially
sent
our
our
a
log
stash
to
a
hosted
log
log
stash
service
called
Mowgli.
So
with
that
up
and
running,
let's
configure
kuma
service
mesh
to
send
all
our
traffic
send
all
our
logs
traffic
logs
to
log
stash.
So
we
have
this
CR
key
right
here
once
again
to
kind
of
go
through
what's
happening.
C
We
are
configuring
the
mesh
CID
again,
but
now
this
time
with
a
long
side,
mutual
TLS
enable
we're
enable
logging
and
telling
logging
exactly
where
to
sent
all
the
logs.
But
on
top
of
that
we
also
have
to
define
you
know
exactly
what
logs
we
want
to
want
to
send.
So,
with
the
CI.
Do
traffic
log
you'll
see
that
it
looks
very
similar
to
traffic
permissions
where
you
have
rules
of
source
and
destination,
you'll
say
for
any
service
that
match
X.
You
want
to
send
that
talks
to
a
destination.
C
C
With
that,
everything
is
going
to
be
sent
to
kuma
demo
log
Lee,
so
let's
kind
of
just
generate
some
sample
activity
within
our
application.
Consent
check
some
dad
shirts
since
the
Dora's
awesome
and
let's
look
at
the
reviews.
Sometimes
it
takes
a
while
for
it
to
get
to
lovey.
So
that's
why
I
just
want
to
give
it
a
few
minutes.
C
So
it
takes
a
few
minutes
for
it
to
get
here.
It's
not
instantaneous
because
it's
a
hostess
service,
so
at
the
end
of
the
demo,
we'll
come
back
and
look
at
everything
that
happens
through
our
demo
and
we
all
leave
logging
for
that.
Well,
we'll
get
back
to
logging
again
and
the
next
step
after
logging
or
while
we
wait
for
logs
to
populate
with
it
lovely
is
securing
traffic
permissions.
C
So
we
showed
how
we
can
enable
traffic
Commission's
for
all
services
to
all
services,
and
it
was
very,
it
was
simply
defining
a
role
and
saying
for
source
to
destination.
I
want
to
match
all.
But
let's
say
hypothetically,
your
marketplace
is
being
bombarded
with
fake
reviews
right.
Maybe
your
competitor
doesn't
want
you
to
sell
any
items,
so
they
just
start
creating
some
lot
of
fake
reviews
and
giving
you
one
star
for
all
your
items.
So
you
want
to
quickly
shut
down
to
Redis
review
endpoint,
so
people
can
no
longer
access
it.
C
So
we're
gonna
go
ahead
and
reapply
another
traffic
permission,
and
this
time
you'll
see
it
looks
fairly
similar
to
the
first
one,
except
this
time
we're
defining
specific
service
source
and
service
destination.
We
are
going
to
say
for
that
traffic
version.
Everything
will
then
change
it,
so
the
source
of
API
Kumud,
my
API,
which
is
a
node
service,
can
only
match
the
destination
of
elasticsearch,
essentially
cutting
out
Redis
from
the
whole
flow
of
your
application.
C
Last
ten
minutes,
oh
just
just
kind
of
sink
back
on
the
logging.
You'll
see
that
logs
are
indeed
coming
in
as
we
make
requests
to
our
service,
so
logging
is
working.
Ok.
So
now
we
go
back
to
our
front-end
application,
so
elasticsearch,
which
populates
our
items
is
working
and
you
know
we
can
keep
searching
and
querying
form.
C
You
know
my
favorite
is
still
the
Hawaii
and
dad
shirts
and
the
fedoras,
but
if
we
were
to
make
the
same
request
to
reviews,
you
can
see
that
reviews
no
longer
works
now
right
because
you
defined
those
specific
traffic
permissions
to
disable.
The
review
end
point
the
review
service,
and
with
that
we
essentially
in
within
10
minutes,
I
would
say
we
were
able
to
enable
mutual
TLS
across
all
our
services.
We
enable
traffic
logging
and
we
enable
traffic
permissions,
and
that
is
the
end
of
the
demo.
C
We
are,
you
know,
really
proud
of
what
we've
built.
We
are
nearly
at
1,000
stars,
despite
only
being
like
one
month
old.
So
you
know
please
help
us
out,
go
to
our
github,
its
github
kong,
slash,
kuma,
so
check
out
repository
storage.
Follow
us,
you
know.
If
you
find
issues,
please
open
up
issues,
we
love
people
to
engage
with
us
and
you
know
help
us
improve
what
we
have
built,
and
we
also
you
know
if
you
want
to
get
updates
throughout.
You
know
about
Kumail.
C
And
if
you
want
to
learn
more,
we
will
be
at
UConn
and
a
so.
Please
join
us.
We
will.
We
also
have
a
co-located
event
the
day
before
you
can
register
now
it
will
focus
on
the
API
gateway
in
the
morning
and
kuma
in
the
afternoon,
or
you
can
always
just
swing
by
our
booth.
You
know
we'll
have
tennis
lag
and
I'll
have
engineers
and
a
demo
labs
that
you
can
play
with,
and
you
know
learn
about
how
to
utilize
come
on
for
your
for
your
architecture.
C
These
are
the
resources
we
have
so
kuma.
The
io
is
our
main
webpage.
You
can
get
quick
started.
You'll
find
the
link
there
as
well,
or
you
could
also
join
our
cyber
channel
that
I
mentioned
earlier.
It's
chat,
Kumud
I,
oh
I,
will
leave
it
for
a
second,
so
people
can
digest
the
links
and
write
them
down.
C
B
Sure
I've
been
answering
questions
all
over
your
presentation.
There
were
like
many
questions
on
the
quean,
a
quean,
a
tool
of
zoom
as
well
as
in
the
chat
I've
been
answering
to
both.
There
are
two
more
two
more
questions
that
are
haven't
gone
through
yet,
but
perhaps
somebody
else
from
the
koomer
team,
that's
online
can
answer
them.
So
one
of
the
question
is:
are
the
traffic
permissions
stateful,
so
you
allow
the
API
to
the
elasticsearch,
but
not
back
so
today.
B
Traffic
permissions
are
both
ways
so
when
when
we
do
allow,
when
we
do
allow
API
to
consume
elasticsearch,
that
means
that
API
can
initialize
a
request.
Elastic
search,
elastic
search,
of
course,
does
not
initialize
any
requests
to
the
API
server
it
receives
that
request
and
provides
a
response.
That's
why
we
did
not
have
to
create
a
traffic
permission
rule
that
would
allow
elastic
search
to
talk
to
the
API,
because
the
connection
is
not
initialized
by
the
my
elastic
search,
but
it's
initialized
by
the
API
service.
B
If
that
answers
those
questions,
if
I
understand
the
question
right
and
then
there
is
another
questions,
another
question
about
mutual
TLS
mutual
TLS
is
good,
but
who
provides
the
certificates?
Is
there
any
equivalent
of
Citadel
in
kuma?
The
answer
to
that
is
that
we
have
got
a
built
in
certificate
authority.
We
did
that
with
the
vision
of
really
removing
as
many
dependencies
as
possible
that
you
have
to
take
care
of
when
running
kuma.
B
So
cool
itself
provides
that
for
you
and
we're
going
to
be
enabling,
as
part
of
our
roadmap,
the
option
of
using
third-party
certificate
authorities
as
well.
You
know
the
project
has
been
released
a
month
and
a
half
ago,
so
there's
lots
of
things
we
want
to
build,
but
this
is
one
of
the
things
that
will
come
up
quite
soon
in
the
mutuality
last
feature,
so
I
hope
that
answers
your
question.
B
There
wasn't
other
questions
of
around
dependencies
that
I
really
want
to
make
it
clear.
I
mentioned
how
cumin
can
run
on
kubernetes
and
can
run
on
Universal.
So
when
it
runs
on
kubernetes,
there
are
no
dependencies
right.
There
is
no
Postgres
dependency
when
running
in
kubernetes.
Kuma
will
rely
on
the
underlying
kubernetes
api
server
to
store.
You
know
all
the
information,
which
means
that
there
is
no
progress
whatsoever.
Postgres
is
only
required
if
you're
running
cumin
in
a
virtual
machine
environment.
B
Why?
Because
we
do
not
have
the
ability
of
obviously
leveraging
the
underlying
kubernetes
server,
and
so
we
have
to
store
this
configuration
summer,
so
you
can
store
it
in
Postgres,
but
guess
what
I
mean?
You
can
also
start
an
AWS
RDS
instance,
for
example,
or
any
managed
Postgres
so
that
you
can
get
Postgres
out
of
sight
out
of
mind,
but
for
universal
there
must
be
a
place
for
storing
this
configuration.
B
We've
chosen
Postgres
for
the
simple
fact
that
it's
one
of
the
simplest
systems
to
run,
and
it's
it's
quite
a
good
Natta
base
as
well
and-
and
you
know,
we're
pretty
sure
that
in
universal
environments,
it's
going
to
be
straightforward
to
start
the
Postgres
instance
or
find
plenty
of
progress
as
a
service
services
that
you
can
use
for
kuma.
So
those
are
also
options.
There
have
been
some
questions
around
the
dashboard.
How
can
we
visualize
all
these
traffic
permissions
on
a
dashboard?
Or
is
there
like
any
dashboard
for
kuma?
This
is
a
very
good
question.
B
We
are
in
the
process
as
we
speak,
of
building
a
dashboard
for
kuma
that
will
show
up
in
the
next
major
version
of
kuma
0.3,
so
we're
going
to
be
you're
going
to
be
seeing
a
dashboard
available
for
kuma
via
your
browser,
starting
from
the
next
major
version-
and
you
know
that's
going
to
be
the
first
step
for
us
to
be
building
more
and
more
visualizations
on
top
of
all
the
things
that
are
happening
on
top
of
kuma.
In
fact,
I'm
quite
excited
about
some
of
the
things
that
we're
planning
to
build.
B
You
can,
like
Kevin,
mentioned,
also
sign
up
on
the
community
newsletter
for
kuma,
so
that
as
we
build
these
features
you
can
get
notified
and
then
you
can
get
access
to
them
as
soon
as
possible.
On
the
universal
mode,
you
can
configure
kuma
in
using
llamo.
Yes,
you
can
configure
kuma
with
kuma
caro.
Yes,
you
can
also
leverage
the
underlying
API,
so
kuma
cattle.
Think
of
it
as
a
glorified
HTTP
client
that
we
have
built
that
leverages.
The
underlying
HTTP
API.
That
kuma
provides.
B
You
can
also
use
coral
if
you
wish
to
make
that
happen,
or
you
can
integrate,
because
it's
an
API
you
can
integrate
the
kuma
api
with
pretty
much
any
system
out
there.
The
api
also
exists
when
running
cumin
in
kubernetes,
but
unlike
Universal,
the
API
when
running
on
kubernetes
is
a
read-only,
so
you
cannot
make
changes
via
the
API.
You
cannot
make
changes
with
Co
Mikado.
You
can
only
make
changes
by
leveraging
cube
cattle
and
that's
really
how
things
should
be
done
on
kubernetes
for
universal
there's,
no
cube
Caudill,
so
cou
Mikado
takes
that
role.
C
And
yeah,
as
you
start
to
explore,
Akuma
install
kuma
and
play
with
it.
Definitely
you
know
if
any
questions
arise,
then
you
can
join
our
slack
channel,
we're
always
on
there
and
we're
always
talking
to
our
community.
So
you
can
get
get
a
quick
answer
there
and
if
you
run
into
an
issue
or
a
bug,
just
open
up
issue
on
our
github
repository,
the
link
for
the
slack
is
up
on
the
slides
again
so
feel
free
to
join
us.
There.
C
B
You
see
if
there
is
any
question.
Let
me
see
if
there
is
any
question
on
the
chat.
I
think
I've
answered
those
again
something
a
question
that
was
very
important
was
about.
Is
there
a
mutation
controller
to
automatically
inject
the
sidecars?
And
the
answer
to
that
is:
yes,
everything
is
automated
on
kubernetes
the
sidecar
is
automatically
injected.
You
don't
have
to
worry
about
it.
B
Lickity
is
that
implements
its
own
data,
plane,
I,
believe
it's
built
in
rust
and
we
have
not
done
benchmarks
against
linker
D
yet,
but
you
know
for,
for
you
know,
when
building
kuma,
we
made
a
very
obvious
decision.
We
don't
want
to
be
reinventing
the
wheel
on
things
that
the
industry
had
already
has
already
contribute
to
the
world,
and
so
we
don't
want
to
rebuild
our
all
low
level
networking
capabilities,
but
we
want
to
be
able
to
leverage
the
de
facto
industry
standard
envoy
to
be
taking
care
of
that.
B
That
allows
us
to
put
more
focus
into
making
Kumud
the
best
control
plane
for
service
mesh,
while
leveraging
all
the
contribution
contributions
that
the
community
and
industry
has
been
doing
to
envoy
for
the
data
plane
technology.
So
that's
why
we
have
decided
to
use
envoy
as
opposed
to
building
our
own
data
plane
and
we're
going
to
be
contributing
back
to
envoy
for
any
improvement.
We
think
it's
necessary
to
be
merged
in
order
in
order
were
going
to
be
proposing
at
least
per
request
for
envoy.
B
C
I
think
we
are
good,
then
looks
like
everyone
has
it
like
likes
like
we
said.
If
you
have
any
questions,
you
can
always
follow
up,
follow
up
with
us
on
the
exist,
other
channels
that
we
have
open-
and
you
know
I
want
to
thank
everyone
for
joining
us
today
on
this
webinar
and
thank
you
cm/ecf
for
having
us.
We
are
cnc
of
goldmember,
so
we
always
try
to
you,
know
we'd
love
to
give
back
to
this
community
and
work
with
this
community
to
make
make
call,
and
also
the
the
CNC
F
ecosystem,
better.