►
Description
In this call, we demo Kong’s newest open source project – Kuma, a modern, universal control plane for service mesh.
Service mesh is a new pattern to build reliable distributed and decoupled applications, but often too complicated to implement with 1st generation control planes. Kong takes a new approach to service mesh with Kuma in order to build modern architectures across a large variety of platforms, including Kubernetes and VMs. Kuma is a universal control plane that addresses limitations of 1st generation service mesh technologies by enabling seamless management of any service on the network.
We’ll walk you through easily setting up service mesh across multiple environments, and enabling security and observability – in any network – automatically. We will introduce new concepts and products along the way, and let developers and architects of any skillset being comfortable with service mesh.
Join our next Online Meetup: https://konghq.com/online-meetups/
A
B
B
So
today's
really
exciting
we
have
the
0.6
release
of
our
kubernetes
ingress
controller
coming
out.
So
this
release
includes
support
for
sto
as
well
as
the
emission
controller.
So
we
will
have
some
content
coming
out
later
today
around
that
and
then
just
a
reminder
to
join
us
at
Kong
summit.
We
are
going
to
be
having
a
lot
of
really
great
content
around
Kong,
as
well
as
some
free
workshops
on
kuma
as
well.
So
there
is
a
code
here
if
you're
interested
in
joining
us,
it's
happening
in
San,
Francisco,
October,
2nd
and
3rd.
B
C
Sounds
good
thanks,
Caitlin
and
thanks
everybody
for
being
here.
My
name
is
Marco
I'm,
the
CTO
of
Kong
and
I'm
here
with
some
other
folks
from
the
koomer
team,
including
drew
Jacob
and
Yaroslav
among
the
others.
I
want
to
go
over
with
you
with
the
getting
started
so
for
anybody
who's
new
to
kuma.
How
do
I
run
kuma?
How
do
I
start
the
product
and
how
do
I
get
really
up
and
running
with
with
some
basic
policies
like
mutual
neutral
Telus?
So
let
me
share
my
screen.
Real
quick.
C
Ok,
perfect,
so
when,
when
we
built
Kumar,
we
built
Kona
with
one
important
assumption.
This
must
be
a
product
that
does
not
just
run
on
modern
or
continuous
environments,
but
can
also
run
on
other
environments.
This
is
very
important
for
a
couple
of
reasons.
Number
one:
not
everybody
wants
to
use
containers
in
kubernetes
number.
Two:
some
organizations
are
planning
to
move
to
containers
and
kubernetes,
but
for
some
reason,
until
now,
service
mesh
and
the
implementation
of
service
mesh
was
contingent
to
a
successful
rollout
of
containerized
applications.
C
If
we
look
at
what's
available
today,
we're
looking
at
in
order
to
implement
service
mash
in
let's
say
kubernetes.
First
of
all,
we
have
to
move
to
kubernetes.
We
have
to
containerize
our
applications
and
then
once
that
is
in
place
only
then
we
can
start
using
service
mash.
That
really
makes
service
mash
the
last
step
of
modernization,
as
opposed
to
really
be
the
first
step
to
modernization.
We
don't
want
the
service
mash
to
be
the
last
thing
we
implement.
We
want
that
to
be
in
place
as
an
enabler
to
that
kubernetes
in
container
transition.
C
So
when
we
build
cumin,
we
build
cumin
with
that
in
mind
as
a
platform,
a
system
that
must
be
easy
to
use
first
and
foremost,
but
also
needs
to
be
able
to
run
everywhere
so
that
if
we
do
want
to
move
to
kubernetes,
we
can
use
cumin
today
on
virtual
machines
as
a
first
step
to
that
transition.
If
we
never
plan
to
move
to
kubernetes
fine,
we
can
implement
a
service
mash
across
pretty
much
every
other
platform
and
if
we
are
already
using
kubernetes
and
containers,
well
guess
what
Kumal
runs
natively
there.
C
So
we
can
easily
implement
user
IDs
to
implement
a
service
mash.
So
this
is
really
one
of
the
principles
behind
cumin,
besides
obviously
being
open
source.
Besides
our
billing
being
a
product
that
wants
to
be,
we
want
to
call
policies
so
once
we
stole
Cooma
the
control
plane
once
we
start
our
data
planes,
then
we
can
implement
and
apply
those
policies
on
top
of
our
systems,
and
today
this
is
the
first
version
of
command
we're
going
to
be.
C
We
provide
policies
from
neutral
class
for
traffic
permissions
and
so
on,
but
we
want
to
keep
extending
the
number
of
policies
that
we
provide
in
order
to
be
able
to
tackle
better
and
bigger
use
cases,
for
example,
routing.
So
this
is
something
that
I
were
working
on
right
now
and
it's
going
to
be
available
very
soon.
So
it's
the
open
one
right.
C
We
want
to
make
sure
that
we
are
running
on
a
good
foundation
and
this
is
going
to
be
the
foundation
we're
going
to
be
using
for
the
years
to
come,
so
we're
going
to
be
not
only
extending
and
improving
the
Cooma
team
over
time,
but
we're
also
going
to
be,
of
course,
creating
features
in
supporting
more
use
cases
for
pretty
much
any
service
match
that
runs
on
multiple
machines,
bare
metal
or
containers
and
kubernetes.
Now
it's
very
important,
though,
to
make
sure
that
you
guys
are
all
involved
into
this
project.
C
This
is
a
community
project
and
we
are
all
going
to
be
working
together
to
implement
these
features
and
to
chat
and
discuss
proposed
implementations
when
it
comes
to
the
project
itself.
It's
very
important
that
we
can
hear
your
voice
and
you
can
do
that
by
either
asking
questions
to
the
community
calls
which
we're
going
to
be
having
on
a
regular
cadence
or
by
opening
up
get
up
issues
or
by
chatting
with
us
and
with
the
rest
of
the
community
on
top
of
slack.
So
this
is
not
I'm.
C
Looking
forward
to
have
contributions
from
you
all
I.
Don't
want
this
to
be
just
a
project
that
we
had
can't
create
it.
Really,
it
really
wants
to
be
open
and
it
wants
to
enable
and
encourage
contributions
from
pretty
much
other
people
and
all
over
the
place.
So
if
you
have
any
questions
at
any
point
in
these
video
in
this
presentation
in
this
chat,
really
this
is
a
two-way
exchange.
Then
write
it
down
and
then,
after
my
demo,
we
can
jump
on
a
call
on
a
conversation,
discuss
those
features.
C
C
Alright,
so
for
those
of
you
who
do
not
know
or
have
not
started
cumin,
if
you
go
to
an
installation
page,
we
can
see
lots
of
different
versions
that
we
can
apply.
Kubernetes
is,
of
course,
powered
by
docker.
You
notice
here
there
is
no
darker
installation.
It's
coming
up
very
soon,
so
you
can
use
the
docker
containers
the
vanilla,
docker
containers
to
start
coming
up.
C
But,
for
example,
let
me
try
with
Mac
OS,
because
I'm
running
a
Mac
OS
right
now,
so
downloading
running
cumin,
it's
very
simple
kuma
by
the
way
it's
built
on
top
of
an
envoy
data
plane.
So
what
we
do
when
running
cumin
is
downloading
the
product,
and
then
this
bundle
for
each
version
of
kuma
will
include
a
few
different
binaries,
including
the
Envoy
binary,
which
is
going
to
be
used
by
the
kuma
DP
manually
in
order
to
provision
the
actual
data
point
and
the
bootstrap
configuration
for
Amber
itself.
So
let
me
go
ahead.
C
The
project-
and
we
see
that
in
we
have
two
main
folders
one-
is
the
bin
folder
one?
It's
the
count.
Folder
the
bin
folder
includes
all
the
binaries
we're
going
to
be
using
and
the
configuration
folder
wing
includes
for
now
only
one
configuration
file,
which
is
the
kuma
control
plane
configuration
file.
Now,
when
we
start
to
the
control
plane,
we
can
start
the
control
plane
in
a
few
different
modes.
C
We
can
store
all
of
the
information
for
the
control
plane
in
memory,
so
there
is
no
dependency
required
or
we
can
store
the
configuration
on
a
Postgres
database
on
kubernetes.
We
are
going
to
be
storing
all
the
configuration
on
the
underlying
kubernetes
api
server,
so
we're
running
kuma
on
kubernetes.
There
is
nothing
else
we
need
to
run
but
kuma
itself
when
running
kuma
outside
of
kubernetes.
So,
for
example,
on
my
mac
machine,
we
need
to
be
storing
the
information
somewhere
because
we
cannot
lever
it
leverage,
the
underlying
EDD
system
that
kubernetes
embeds
already
within
itself.
C
So
when
we
start
kuma
control
plane,
we
can
obviously
start
the
defaults,
which
will
load
an
in
memory
control
plane
or
we
can
start
an
instance
of
the
control
plane
that
runs
and
stores
the
information
on
top
of
Postgres.
If
we
look
at
the
configuration
here,
we
have
different
properties
that
could
that
we
can
use
to
determine
what
is
the
Postgres
database
we
want
to
use,
assuming
that
the
type
that
were
selecting
here
is
equals
pause
class
I'm
not
going
to
do
that.
C
Now
we're
going
to
be
using
type
memory,
which
is
the
default,
but
if
you
want
to
use
Postgres,
this
is
how
you
would
do
it.
So,
let's
go
ahead
and
start
to
the
control
plane.
You
can
just
follow
the
instructions
here,
so
I'm
gonna
be
running
run
in
these
will
start
the
control
plane.
The
control
plane
starts
and
opens
up
a
few
services,
including
the
API
server,
the
bootstrap
server,
the
diagnostic
server,
the
XDS
ER
PC
server
and
the
SDSU
RPC
server
as
well.
C
Therefore,
we
can
configure
the
data
planes
at
runtime.
We
are
streaming
jar,
PC
communication.
Every
time
a
new
data
plane
starts,
the
API
server
is
a
restful
api
server.
So,
for
example,
I
can
consume
this
server
on
on
my
computer
and
it
will
provide
it's
a
simple
restful
api
that
is,
it's
always
available
on
both
kubernetes
and
other
environments,
and
that
we
can
use
to
visualize
and
retrieve
information
for
our
cluster
on
kubernetes.
This
API
will
only
be
read-only.
C
We
can
only
retrieve
information
because
we
want
to
Cooper
Nettie's
to
apply
CR
these
to
change
the
state
of
coma.
We
don't
want
to
change
the
state,
but
using
the
API
directly,
but
on
other
environments
other
than
kubernetes.
We
can
use
the
API
to
change
the
state,
in
fact,
Coomer
ships
with
a
binary
called
kuma
carro,
which
you
can
run
on
pretty
much
any
environment
in
this
kuma
cattle
binary
under
the
hood.
What
it
really
does
is
configuring
it's
consuming
the
underlying
API
server
to
retrieve
the
information.
C
So
when
you're,
looking
when
you're
using
kuma
cattle
to
interact
with
the
kuma
cluster,
these
under
the
hood
makes
HTTP
requests
to
the
API
server
to
the
API
server
restful
api
that
I
just
visualized
here.
So,
for
example,
we
can
do
things
like
slash
map
meshes
to
retrieve
the
meshes
that
are
available
in
these
will
return.
The
default
mesh
kuma
starts
by
default
with
one
mesh:
that's
always
there.
We
can
create
more
meshes.
C
We
can,
even
if
you
want
to
remove
the
default
mesh-
and
this
is
the
default
one-
that's
going
to
be
available
as
soon
as
we
start
a
new
kuma
custom.
So
by
doing
slash,
slash
meshes,
we
can
of
course
start
inspecting
the
API.
This
means
we
can
also
integrate
this
with
pretty
much
anything
that
can
make
HTTP
requests.
So
kuma
carol
makes
takes
advantage
of
this
api
to
provide
the
information,
but
you
can
integrate
this
with
anything
really.
As
long
as
you
can
make
an
HTTP
request,
you
can
retrieve
information
from
kuma.
C
That's
pretty
cool
so
now
that
we
have
now
that
we
have
the
control
plane
running,
we
need
to
start
the
data
points,
but
before
we
start
the
data
points,
we
need
to
be
having
a
service
that
we
can
protect.
We
can
be
make
part
of
the
mesh,
so
the
battery
here,
ships
with
the
banner,
is
here
shipshape
with
a
tcp
echo,
a
tcp
echo
server
that
allows
to
allow
us
to
you
know
start
a
simple
demo
serve
service
of
of
kumar,
and
we
can
do
that
by
specifying
the
port
field
like
nine
thousand.
C
This
will
accept
simple
requests
and
echo
back
the
request,
we're
making
on
the
on
the
server
side
and
so,
for
example,
if
we
use
curl
and
we
make
a
get
request
to
localhost
9000
9000,
we
see
how
the
server
will
log
that
will
received
a
new
HTTP
connection
and
in
here
on
the
client
side,
it
will
echo
back
the
request
for
making.
So
this
is
a
simple
echoing
server.
We
can
also
use
netcat.
C
So,
for
example,
we
can
use
netcat
to
connect
to
port
9000
and
this
will
start
the
TCP
connection,
a
raw
TCP
connection.
So
if,
for
example,
we
write
hello,
we
see
that
it
echoes
back
what
we're
writing
as
well
as
the
text
is
as
being
a
TCP
connection
or
a
TCP
connection,
as
opposed
to
http.
So
it's
a
simple
a
code
server
that
we
can
use
for
this
demo
today,
moving
forward,
I'm,
looking
forward
to
create
our
own
demo
application,
it's
a
little
bit
more
advanced
and
nicer
to
use
than
the
TCP
echo.
C
You
know
how
you
know
we're
going
to
be
using
Cooma
in
the
context
of
a
real
application
that
it's
going
to
be
having
dependencies
is
going
to
be
having
you
know,
different
components
talking
talking
to
each
other.
What
I
would
like
to
do?
It's
providing
that
sample
app?
It
can
be,
for
example,
a
simple
marketplace
application,
so
imagine
super
super
stripped
down
version
of
amazon.com
right.
The
this
application
will
use
different
services
to
retrieve
the
items,
descriptions
to
make
a
search,
and
it
will
also
leverage
different
data
stores
to
storing
that
information.
C
So
I
want
to
provide
a
demo
application
that
includes
these
different
components
in
a
UI,
of
course,
so
that
we
can
use
that
moving
forward
for
every
example
that
we
want
to
apply
on
top
of
kuma
and
that
you
can
also
use
internally
or
in
your
organization
to
them
or
what
kuma
does,
and
you
know
the
feature
it
provides.
This
is
something
that's
coming
and
once
it
comes
most
likely,
they
covered
his
kuma
TCP
echo
sample
application.
C
C
There
are
different
ways
to
start
a
data
plane
depending
if
you
run
on
kubernetes
or
not.
If
we
do
not
run
on
kubernetes,
we
have
to
use
cout
Mikado
and
by
the
way,
let's
use
comma
cattle
now
to
inspect,
because
we
have
a
control
plane
running.
We
can
use
comma
cattle,
so
first
of
all,
kuma
cattle.
If
you
don't
specify
the
command,
it
will
return.
Our
nice
help
dialog.
C
That
tells
you
exactly
all
the
commands
that
are
available
and,
in
particular,
I
want
to
make
sure
that
if
I
config
the
control
planes
and
then
I
visualize
them,
okay,
so
list
kuma
cattle
config
control
planes
list.
This
will
list
the
control
planes
that
are
available
from
this
coma
cattle
environment.
This
configuration
it's
initialized
by
default
with
a
local
host
control
plane,
but
we
can
add
more
control
planes.
So,
for
example,
if
we
do
run
a
kuma
control
plane
cluster
somewhere
else,
it
can
be
in
the
cloud
or
can
be
in
another
machine.
C
We
can
add
that
control
plane
to
this
list
and
then
we
can
start
using
kuma
Carol
with
that
remote
control
plane.
In
fact,
I
can
use
cout
Mikado
to
add
as
many
control
planes
as
I
want
and
I
can
switch
between
them
by
using
the
switch
command
which
is
described
here
so
I
can
switch
the
ActiveX
control
plane
from
one
to
another.
C
If
I
retrieve
the
data
planes,
there
are
no
data
planes,
so
we
have
a
service.
Let's
start
the
data
plane
for
the
service
to
start
the
data
plane.
We
need
to
first
of
all,
do
a
couple
of
things
number
one.
We
need
to
tell
kuma
the
control
plane
that
do
is
going
to
be
a
new
data
plane
with
the
following
properties
that
it's
going
to
be
connecting
to
the
system
in
this
case.
C
In
this
example,
with
a
new
data
plane,
that's
going
to
belong
to
the
default
mesh,
that's
going
to
be
having
a
name
dpi
Co,
one
that
defines
the
following
networking
configuration
now.
The
networking
configuration
is
very
important
because
it
determines
how
the
data
plane
reacts
when
a
new
incoming
request
comes
in
or
a
new
outgoing
request
is
being
made
through
the
data
plan.
So
in
this
example,
the
data
plane
is
telling
the
control
plane
hey
I'm,
going
to
be
starting
on
port
10,000.
C
So
this
is
the
external
port,
and
every
request
on
port
10,000
would
be
proxied
to
port
9000
on
the
same
host.
Why
9,000?
Because
that's
the
same
port
as
our
service,
so
this
is
the
external
port
that
determines
what
port
we
have
to
consume
in
order
to
make
a
request
to
the
service
via
the
data
plane
in
port
9000
determines
where
that
requests
will
go
in
the
same
host
after
its
it
reaches
the
data
point
we
can
apply
a
series
of
tags
and
one
tag
is
mandatory
and
that's
the
service
tag.
C
Now
you
will
notice
that
in
version
0.14
cuma,
you
have
to
be
very
careful
when
you
write
this
configuration
because
you
know
we're
getting
better
with
the
validation.
So
you
know
if
if
this
is
not
formatted
the
right
way,
it
my
true,
throw
some
weird
errors.
So
we're
going
to
be
improving
that,
of
course,
as
the
gets
better,
but
just
pay
attention
to
make
sure
that
whatever
you're
writing
here
matches
the
data
plane
specification
documentation,
that's
documented
on
the
docs.
So
here
you
can
find
a
full
spec
of
how
to
create
this
document
on
kubernetes.
C
You
don't
have
to
do
any
of
this
on
kubernetes.
The
data
data
plane
will
be
automatically
injected
without
you
having
to
specify
any
data
plane
configuration
whatsoever,
so
it's
all
automatic
on
kubernetes.
This
only
applies
if
you're
not
using
kubernetes,
so
we
create
a
new
data
plane
type
and
then
we
apply
that
configuration
with
komak
arrow
I
can
just
execute
these
commands
and
it
should
be
working.
C
Perfect
so
now
I've
added
the
data
plane.
If
I
get
the
data
planes
I'm
going
to
be
seen,
then
there
is
one
data
plane
in
the
default
mesh
and
belongs
to
the
following
service,
and
it's
called
dpi
co1
we're
going
to
be
having
one
instance
of
the
data
plane
for
every
instance
of
our
service.
So
there
is
another
command,
that's
very
handy
called
inspect.
C
If
we
inspect
the
data
planes,
we
can
visualize
the
insights
for
every
data
plane
that
has
been
connected
to
the
our
control
plane,
and
so
we
are
noticing
that
the
DPI
Quan
data
plane
it's
being
configured
on
the
control
plane,
but
the
status
is
offline.
This
is
because
we
never
started
the
data
plane
yet
by
using
command
DP.
We
just
configured
it.
So
let's
go
ahead
and
start
the
data
plane
starting
the
data
plane
is
as
easy
as
running
the
kuma
DP
exact
tables
which
under
the
hood,
will
start
envoy.
C
So
if
we
start
this
command,
we
expect
a
few
properties
like.
Where
is
the
control
plane
going
to
be
located
at?
So
we
need
to
specify
this
so
that
the
data
plane
can
can
retrieve
the
bootstrap
configuration
from
the
control
plane,
as
well
as
what
mesh
and
what's
the
name
of
the
data
plane
we're
trying
to
start
so
this
information
have
to
match
whatever
we
have
defined
in
the
data
plane
type
up
here.
C
C
If
you're
gonna
come
a
car
again,
I
can,
of
course
we
through
the
meshes
meshes
I
can
also
retrieve
the
data
planes
like
I
did
before,
but,
most
importantly,
I
can
inspect
those
data
planes
and
see
that
now
the
data
plane
I
just
started
is
online,
which
means
that
we
have
successfully
added
a
new
data
plane
in
that
data.
Plane
is
successfully
communicating
with
the
control
plane.
We
can
see
a
few
diagnostic
information
here
like
when,
when
when
was
last
time
it
it
connected.
C
When
was
the
last
time
it
was
updated
and
so
on
now,
once
the
data
planes
are
running
and
they
are
running
and
talking
to
the
control
plane,
we
can
start
applying
policies
on
the
control
plane
in
order
to
change
the
behavior
of
this
data
plane.
So
we
never
have
to
configure
the
data
plane
directly,
we'll
go
to
the
control
plane
for
doing
pretty
much
everything
we
want
to
do
so.
C
Okay,
so
this
will
consume
the
service
directly,
but
we
don't
want
to
do
that.
We
want
to
go
through
the
data
point
for
some
poor
on
for
10,000.
If
you
do
that,
we're
going
to
be
seeing
the
same
answer,
so
this
is
a
request
made
directly
to
the
service
which
we'd
never
want
to
do
in
production,
and
this
is
a
request
made
through
the
data
plane.
The
data
plane
of
Newport
10,000
will
receive
the
configurator
the
request
and
then
it
will
proxy
it
on
the
same
host
on
port
9000
like
we've
configured
here.
C
C
We
do
support
today
only
one
only
one
certificate
authority
and
that's
the
one
that's
built
in
on
top
of
the
control
plane,
moving
forward.
We're
also
going
to
be
enabling
these
CA
to
be
external
to
coomer,
so
you
can
integrate
it
with
a
third-party
CA
Authority.
If
you
want
so
to
apply
mutual
cellists
via
policy,
we
must
create
the
policy,
so
we
can
update
our
default
mesh
by
enabling
neutral
colors
with
the
default
built
in
configuration.
So
if
I
do
this.
C
C
This
means
that
if
I
make
a
request
again
on
port
10000,
this
request
will
now
fail,
because
it
must
happen
over
HTTPS.
In
fact,
it's
not
going
to
be
working.
We
need
to
be.
We
need
to
be
making
these
requests
from
not
wrong.
This
will
work.
We
need
to
be
making
these
requests
on
top
of
HTTPS
in
order
to
to
make
it
work
if
we
consume.
In
fact,
by
of
course,
disease
self
signed
certificate,
so
Carol
does
not
recognize
the
client
certificate
that
we
have
set
in
order
to
consume
the
service.
C
We
need
to
be
able
to
provision
a
mutual
class
certificate
in
order
to
be
part
of
this
mesh
and
therefore
making
a
request
to
the
service,
but
the
service
itself
didn't
have
to
implement
any
change
whatsoever.
So
if
we
keep
making
a
request
on
9000
by
passing
the
data
point
whatsoever,
these
will
keep
working.
So
in
one
click
we
have
enabled
mutual
TLS
on
top
of
the
mesh,
and
now
the
service
is
being
protected
and
it
will
not
accept
any
connection
by
anything
outside
of
the
mesh
that
doesn't
provide
the
right
client
certificate.
C
A
A
C
C
If
we
look
at
what
we
have
running
a,
we
have
a
new
commodity
process
running
which,
under
the
hood,
will
start
a
non-void
process
right.
So
this
is
the
bootstrap
configuration
that
been
automatically
fetched
by
the
by
the
command
EPE
process,
and
we
can
see
it
here,
so
we
want
to
make
sure
that
effectively
commodity
always
is
up
and
running,
and
if
it's
not,
that
means
the
data
point
is
crashed
right.
So
we
do
that
by
making
requests
the
actual
service
visualize
and
make
sure
that
the
port's
Webber
open
are
indeed
reachable.
C
Starting
from
next
week,
I
want
to
be
providing
a
live
demo
application,
so
we're
working
on
a
few
mock-ups
here.
So
imagine
a
simple
simple
market
built
or
that
would
effectively
start
a
few
components
and
then
we're
going
to
be
using
this
for
the
official
damage
so
that
we
can
do
something.
That's
a
little
bit
more
meaningful
unless
low
level,
then,
having
this
TCP
echo
system
running
and
then
manual
requests
to
the
product,
I
think
it
would
be
agreed.
It
would
be
very
beneficial
for
the
community
and
for
the
project
itself.
A
Hey
Harry
Marco
in
your
example
there,
so
his
port
9000
is
what
their
underlying
services
running
on
and
then-
and
you
know,
you're
kinda,
hiding
that
behind
the
mesh
here
and
when
a
time
cards
are
gonna
call
them
for
10,000.
What
is
a
but
stop,
and
you
know
someone
call
net
service
directly
on
port
9000.
A
C
Only
via
the
ports
that
we
are
exposing
that
the
data
plane
right
so
it
is,
it
is
important
that
the
ports
of
our
services
are
only
going
to
be
accessible
from
the
data
plane,
that's
running
on
the
same
machine,
but
not
from
anywhere
else.
So,
for
example,
if
you're
running
on
ec2,
we
can
set
up
a
security
group
such
as
the
only
external
ports
that
are
available
are
the
ones
that
the
data
plane
exposed.
A
C
We
need
to
prevent
that.
We
need
to
exclude
that
from
being
exposed
in
the
network
in
the
first
place.
You
know
if
somebody
wants
to
buy
everything
that
the
service
mesh
provides,
it
can
be
executed,
it
can
be
provided
just
because
the
data
plane
is
executing
that
function,
the
mutual
TLS
it's
been
executed
by
the
data
plane.
The
traffic
permissions
are
being
executed
by
the
data
plane,
so
everybody
must
go
through
the
data
plane
in
order
to
be
able
to
enforce
that.
C
If
they
are
bypassing
the
data
plane,
then
the
whole
product
cannot
does
not
know
that
the
service
is
being
consumed
even
in
the
first
place.
So
it
is
important
that
we
can
lock
that
down
from
a
networking
standpoint,
mm-hmm
I
believe
that
maybe
maybe
there
is
a
way
in
I'm
asking
a
question
to
my
team.
Maybe
there
is
a
way
with
transparent
proxy
to
catch
every
incoming
request
and
automatically
block
it
if
it's
not
being
consumed.
C
A
I
can
try
to
answer
this
question
so,
first
of
all
back
to
your
original
question,
how
would
you
prevent
from
somebody
making
direct
request
application?
If
you
look
into
our
example,
you
will
notice
that
we
start
both
application
and
data
plane
and
we
bind
say
a
networking
address
to
localhost,
so
one
27001
so
and
as
long
as
your
application
distance
on
this
IP
address
it's
not
accessible
from
outside
of
this
machine.
So
the
first
solution
for
you.
If
you
around,
for
example,
scientists,
you
just
run
your
application.
A
So
this
is
like
is
it
lost
the
most
usable
approach
in
any
environment,
traditional
environment,
on
platforms
like
winches,
and
also
into
the
same
thing
he
wants
you,
you
can
also
make
use
of
IP
table
rules,
so
essentially
a
table
rule
allows
you
to
apply
redirections
to
both
incoming
and
outgoing
static.
So
you
can
define
rules
at
every
incoming
traffic
into
your
machine,
should
be
redirected
into
data
plane
and
that
data
plane
will
forward
this
traffic
to
just
original
application.
A
A
Well,
it's
also
easy
on
platforms
like
cruentus
or
if
you
have
full
control
or
we
get
so
that's
brilliant
guys
thanks
a
lot
for
that.
Yeah
I
was
thinking.
Maybe
the
product
might
do
that
on
top
of
the
product.
You
know
we
have
to
stay
and
unlock
that
online
service
down
through
just
just
much
of
configuration,
configure
Wi-Fi
tables
or
you
know,
narrowed
security
groups
or
you
know
sorry,
something
or
other,
but
you
know
even
on
localhost.
A
A
Yes,
something
about
security
inside
the
books,
so
it's
like
not
every
application
can
call
it
inside
the
box.
This,
where
Linux
networking
groups
come
come
in
other
clean
space.
So
if
you,
for
example,
run
this
insides
yeah,
like
both
data
plane
energy
implications
inside
one
metal
in
space,
then
it
also
makes
them
an
accessible
from
another
in
extent
of
in
space.
B
A
A
A
C
So
kuma
has
been
built
with
a
few
different
foundational
principles
in
mind,
as
opposed
to
systems
like
history.
Oh
issue
is
a
system
that
works
that
has
been
built
on
top
of
kubernetes
that
has
been
built
by
leveraging
intensively
the
kubernetes
primitives.
That
makes
it
very
hard
to
be
deployed
outside
of
kubernetes
now
kubernetes.
C
So
how
can
we
number
one
enable
those
workloads
to
transition
to
kubernetes,
and
how
can
we
support
them
if
they're
never
going
to
be
transitioned
ever
from
kubernetes
cuma
has
been
built
with
platform
agnostic
in
mind,
which
means
that
you
can
start
cuma
on
kubernetes
or
outside
of
kubernetes
very
easily
you're,
not
limited
by
using
kubernetes.
Only
that
is
a
big
difference.
Every
team
in
the
organization
can
use
Cooma
the
ones
that
are
using
kubernetes
and
the
ones
that
are
not.
The
second
thing
is
that
systems
I
kissed.
C
You
are
very
complex,
very
hard
to
use
hard
to
deploy,
there's
lots
of
moving
parts
that
goes
into
running
and
it
goes
into
running
the
the
Easter
service
with
kuma
we
wanted
to
get
rid
of.
All
of
that.
Kuma
is
a
golang
executable
that
on
kubernetes
by
the
way,
does
not
requiring
independency.
So
you
can
deploy
this
thing
in
one
command.
We
have
not.
C
We
have
not
watched
the
installation
kubernetes,
you
can
install
Puma
in
one
command
and
please
command
will
install
only
one
service,
and
that
is
the
the
kuma
CP
service,
as
well
as
the
sadqa'
injector
service,
and
that's
pretty
much
it.
The
only
thing
you
need
to
scale
is
adding
or
removing
replicas
of
this
one
service.
In
order
to
run
there
is
no
mixer
pilot
citadel,
and
none
of
that,
it's
very
simple
and
it's
built
for
simplicity,
needs
of
use
so
lower
operational
cost
and
simplicity
in
ease
of
use.
C
Third
thing:
we
wanted
to
support
multiple
teams.
At
the
same
time,
by
supporting
multi-tenancy
at
the
same
time,
we
heard
from
our
users
that
one
of
the
biggest
pain
with
existing
meshes
is
that
for
every
new
team
that
wants
their
own
mesh,
they
need
to
start
in
a
new
cluster
of
their
own
mesh.
So
with
cumin,
we
implement
the
multi-tenancy
since
they
want,
and
we
allow
on
the
same
control
plane
to
support
as
many
service
meshes
as
you
want,
which
means
that
running
one
mesh
is
as
hard
as
running
a
million
meshes
with
cumin.
C
There
is
no
difference,
it's
multi-tenant,
since
they
want,
and
last
but
not
least,
we're
going
to
be
implementing
an
API
which
would
allow
meshes
that
are
running
on
different
platforms
to
be
communicating
with
each
other,
which
means
that
you
can
have
a
mesh
that
can
span
across
multiple
kubernetes
clusters,
as
well
as
kubernetes
and
virtual
machines,
with
cumin
with
one
system
without
having
to
introduce
any
new
dependency
or
any
abstraction
layer
about
that.
So,
to
recap,
platform,
the
city,
so
that
every
team
in
the
organization
can
use
simplicity.
C
We
want
these
to
make
it
simple
to
deploy
simple,
to
install
simple
to
scale
and
simple
to
use.
This
is
at
0.1,
so
we're
gonna
get
take
it
from
here
and
make
kuma
the
simplest
service
mesh
in
the
world.
That's
the
whole
point
of
kuma
the
same
simplicity
that
we
that
Congress
provided
in
the
API
management
space
with
Kong
gateway,
that
same
simplicity.
We
want
to
replicate
in
the
service
mesh
world
service.
Mash
does
not
have
to
be
complicated.
C
C
It
would
allow
anybody
to
create
policies
on
top
of
kuma
the
same
way
you
can
go
ahead
and
create
a
plug-in
on
top
of
Kong,
so
we
want
these
to
be
open
to
be
running
everywhere,
to
be
simple
to
use,
and
that's
really,
it
goes
against
some
of
the
principles
that
existing
service
meshes
are
implementing.
Today
there
are
either
kubernetes
only.
They
are
very
hard
to
use
or
they
have
lots
of
moving
parts
and
they
don't
make
service
mesh
an
easy
pattern
to
be
adopted
within
the
organization,
which
is
what
kuma
really
wants
to
fix.
A
C
When
you
think
who
might
be
production
ready
we,
so
this
is
the
first
version
of
command
zero
point,
one
right.
We
are
building
kuma,
paying
lots
of
attention
on
on
the
stability
of
the
features
and
the
stability
of
the
product
itself.
But
of
course
it's
a
zero
point,
one
right,
so
we
it
can
only
get
better
from
here.
We
are
going
starting
from
zero
point.
C
Two
two
we're
going
to
be
exploring
and
running
kuma
in
production
on
our
own
services
as
well
so
start
I
would
I
would
wait
until
I
would
start
experimenting
with
kuma
today,
but
I
would
probably
wait
until
at
0.2
0.3
before
pushing
it
into
production.
But
there
is
no.
There
is
no
problem
in
to
running
it
in
a
staging
environment
and
the
mutual
TLS
has
been
tested
a
lot,
it
works
well.
The
features
that
we
provide
are
very
well
tested,
so
I
mean
unless
you
experiment
any
specific
problem.
You
experience
any
specific
problem.
C
You
can
give
it
a
try.
It
is
important
to
understand
that
kuma
does
not
reinvent
the
underlying
networking
functions
that
we
are
using
to
manage
and
crosses
those
requests.
We're
using
envoy,
which
means
that
for
kuma
it's
going
to
be
a
much
easier
and
how
can
I
say
a
much
more
solid
journey
into
production
just
because
we're
not
remain
ting
the
hard
stuff,
the
hard
stuff
with
our
billing.
C
The
networking
components
are
being
provided
by
Amboy,
which
has
been
running
in
production
for
a
while,
so
we're
leveraging
that
substa
bility,
who
are
leveraging
that
solidity
in
that
production,
experience
or
bamboo
itself
to
build
kuma
so
give
it
a
try
and
we
don't
think
there's
going
to
be
promised.
But
if
there
are
please
open
up
an
issue,
we're
going
to
be
very
responsive,
it's
at
0.1,
so
I
would
start
with
staging
first
and
take
it
from
there.
C
C
We
are
going
to
be
implementing
that
so,
basically
the
question
is:
can
you
implement
the
rule
based
access
control
so
that,
basically
you
can
restrict?
If
there
are
multiple
meshes,
you
can
restrict
what
the
team
scanned
or
cannot
do
on
top
of
those
meshes.
So
we're
going
to
be
implementing
a
role
based
access
control
and
that's
going
to
be
working
on
both
kubernetes
and
virtual
machine
deployments
and
for
kubernetes
were
going
to
be
exploring
leveraging.
The
kubernetes
are
back
in
order
to
be
implementing
some
of
these
features.
C
I'm
very
excited
about
cumin
I'm,
very
excited
about
the
work
work
we
you
know
the
community
has
been
doing
so.
The
next
community
call
will
be
even
more
exciting.
You
know
this
is
all
learning
experience
for
us
as
well.
We're
going
to
be
accepting
community
call
contributions
for
the
next
topics.
So
if
you
build
or
do
anything
very
that
you
want
to
showcase
with
cumin-
and
you
want
to
present
that
to
the
broader
community-
please
let
us
know
on
the
slack
chat
and
we
can
make
it
happen.
This
is
not
really.
This
is
our
project.
C
With
that
said,
I'm
looking
forward
to
see
you
all
in
mutual
and
the
next
community
call
we're
going
to
be
working
on
a
few
new
features,
one
of
them
being
a
new
traffic
logging
policy
which
would
allow
to
showcase
an
easier
way
to
integrate
Cooma
with
products
like
the
elk,
a
stag,
Cabana
or
Splunk,
for
example,
as
well
as
I'm
looking
forward
to
be
creating
a
nice
demo
application.
So,
the
next
time
it
there's
going
to
be
less
common
line
and
more
pointing
click
for
for
an
easier
explanation.
What
kuma
does.
C
A
Awesome,
if
that's
all
the
questions
that
we
have
you
guys,
if
you
guys
have
any
follow-up
questions,
you
can
always
ask
that
our
slack
channel
or
if
you
have
an
issue
with
coolant,
you
know
something
you
can't
can't
work
through.
You
can
always
open
up
an
issue
in
our
github
and
to
wrap
things
up.
Kaitlyn.
Do
you
want
to
take
over.