►
From YouTube: Kuma Community Call - May 12, 2021
Description
Kuma hosts official monthly community calls where users and contributors can discuss about any topic and demonstrate use-cases. Interested? You can register for the next Community Call: https://bit.ly/3A46EdD
A
B
A
A
A
Okay,
is
there?
Is
there
anything
else
that
you
are?
You
are
interested
because
you
are,
I
would
say,
the
only
one,
at
least
from
what
I
can
see
from
the
community
here.
Is
there
any
any
other
topic
feature
or
whatever
we
are
doing
that
you
you
wanted
to
bring
up
and,
if
not
directly
related
with
your
current
work
with
us,
but
something
that
is
in
the
future,
etc.
Something
that
you
think
is
worth
discussing
here.
B
No
not
not
right
now,
we've
been
playing
around
with
or
experimenting
with,
if
we
can
add
kuma
to
our
to
our
platform.
Basically,
we've
got
a
requirement
that
we
need
to
basically
doing
ingestion-based
pricing
so
trying
to
figure
out
the
the
number
of
incoming
bytes
and
proxying
that
with
something
like
kuma
is
kind
of
a
natural
fit.
If
we
can
do
that,
but
yeah,
nothing
really
yet,
hopefully
I'll
be
able
to
use
come
at
my
current
job.
I've
been
trying
to
push
it
in
slowly.
C
C
So
I
joined
kong
a
couple
months
ago,
so
technically
my
my
job,
titles,
tech
marketing,
are
engineer.
So,
like
I
build,
I
build
content
on
how
to
do
cool
stuff
with
the
tech
and
show
it
off
and
build
cool
demos
and
stuff.
But
it's
kind
of
like
a
bleed
over
between,
like
interacting
with
the
engineering
team,
product
management,
marco
and
like.
D
C
C
B
A
C
B
No
apache
flank
it's
a
data
processing,
unified
stream
in
batch
engine.
We've
been
doing
a
lot
of
things
with
sql
recently,
because
that's
hot
again
yeah,
but
all
based
on
top
of
kubernetes
right
now.
Yeah
there's
also
an
interesting
product
that
came
out
of
the
same
apache
flank.
Project
called
state
function,
state
fund,
which
is
kind
of
abstracting
out
the
the
persistence
layer
similar
to
what
kuma
does
and
service
mesh
does
for
the
network
layer.
So
basically
yeah
it's
cool.
C
You
know
I
always
I
always
think
about
like
the
cool
thing
about
like
the
interesting
thing
about
service
mesh
is
like
creating
like
this
consistency.
Layer
right,
like
you
use,
persistence
like
this
way
of
creating
like
the
networking
of
envoy,
is
the
same
between
anything.
That's
really
joining
up
to
the
control
plane
right.
C
B
No
exactly
it's
like
the
same
same
concept
of
everything
in
in
envoy
layer
communicates
the
same
way.
It's
basically
everything
in
a
stateful
function.
Cluster
persists
its
data
in
the
same
way,
so,
instead
of
kind
of
the
app
being
in
control
and
writing
to
a
database,
it's
basically
the
database,
acting
as
like
the
messaging
layer
for
all
of
your
your
business
logic.
C
A
Cool
cool
I'll
check
that
out.
Thank
you,
yeah,
okay,
can
we
can
you
please
I
added
here
in
the
agenda,
just
as
a
reference
link
yeah,
someone
is
interested,
okay
and
watches
the
video
and
okay
good.
So
I
I
mean
I'm,
I'm
always
interested
into
seeing
like
experimenting
the
boundaries
of
what
the
service
mesh
can
do,
because
the
typical
like
when
you're
going
last
week
was
the
kubecon.
A
Everyone
comes
with
their
own
use
case
and
all
the
ideas
of
what
they
want
to
use
the
service
mesh.
For
so
last
time
we
get
the
nice
people
from
upland
which
were
doing
something
else.
Today
I
was
talking
to
someone
about.
I
mean
they
were
trying
to
put
tomcat
applications,
which
already
apparently
have
you
know
tls
enabled
by
default,
and
this
kind
of
creates
some
other
issues.
We
had
people
doing
ilya.
Do
you
remember
this
lady?
That
was
trying
to
do
what
was
it
like
the
distributed.
A
Yeah,
so
I
mean
when
the
the
real
world
use
cases
to
me
are
much
more
interested
because
you
know
talking
about
microservices
is
probably
getting
boring
like
oh
yeah,
okay,
so
you
have
these
rest
apis
here.
Talking
to
this
other,
you
know
services
and
like
okay,
yeah,
you
know
yeah,
so
that's
cool!
That's
why
yeah,
okay.
B
C
You
know
so
something
like
I'll
just
share,
since
we
don't
have
a
ton
of
stuff
on
the
agenda
but
like
similar
to
this,
I
I
can
share.
We
did
a
survey
at
cubecon
on.
Do
you
want
to
share
yeah
yeah?
You
know
I'll.
Do
it
right
now,
but
it's
interesting
so
like
something
I
talked
a
lot
about
at
hashicorp
and
I
used
to
talk
with
like
armon
and
mitchell
about
this.
C
But
I
wonder
how
long
service
mesh
is
going
to
be
like
the
best
way
to
do
like
that?
Zero
trust
security
story.
I
just
the
blunt
way
of
saying
is-
I
don't
think
it's
gonna,
be
that
long
and
I've
always
said
I
think
the
future
of
service
meshes
and
traffic
management
and
observability
and,
like
I
think,
observability's
got
a
little
ways
to
go
like.
C
I
think
it
does
really
great
stuff
now,
but
I
think
that's
going
to
evolve
and
change
quite
a
bit
and
same
thing
goes
for
traffic
management,
but
the
survey
results
were
super
interesting
because,
like
we
had,
we
didn't
get
a
ton
of
people
got
65
people
66
people
that
submitted
the
survey,
but
the
weight
is
just
super
heavy,
not
on
zero
trusted
security.
I
bring
it
up
right
now,
just
to
I
have
to
dig
up
the
the
email
so.
C
So
because
of
like
the
nature
of
cubecon
and
it
being
kind
of
a
a
more
regulated
thing,
we
only
were
allowed
to
ask
like.
I
think
it
was
like
four
or
five
questions,
so
it
was
a
very.
It
was
a
very
short
survey,
all
things
all
things
considered,
but
the
two
like
the
three
kind
of
money
questions
were:
what's
the
most
important
capability
inside
of
surface
mesh.
What's
your
workload
footprint
trying
to
understand
what
size
people
are
looking
to
go
at
the
reason,
the
the
background
on
this
question
is
historically
I've
gotten.
C
There's
this
interesting
debate
around
how
you
make
service
mesh
more
adoptable.
Do
you
make
it
more
adoptable
by
catering
to
huge
environments?
So
you
get
like
you
know
a
jp
morgan
who's
willing
to
do
service
mesh
and
bring
you
know
20
000
workloads
in
or
do
you
start
to
appeal
to
developer
teams
and
say
hey?
C
We
can
make
your
individual
application
deployments
very
agile
and,
ultimately,
I
think
the
real
answer
is
it's
going
to
be
a
mishmash
of
both,
but
the
idea
behind
this
question
was
like
trying
to
understand
what
the
expected
footprint
from
a
service
mesh
was,
and
it
really
ends
up
being
kind
of
a
blend
of
all
right,
like
it's,
people
want
to
put
workloads
in
the
size,
is
kind
of
irrelevant
and
then
characteristics
being
like.
What
do
you
want?
A
service
mesh?
C
That's
that's
extendable
and
this
jacob,
like
there's
an
interesting
one,
to
hear
this
about
the
the
event
driven
thing
that
we
were
on
like
the
thread
about
like
what
do
people
want
out
of
the
search
first,
do
they
want
an
extensible
platform
that
they
can
integrate
with
and
have
like?
Do
they
want
that
function?
Experience
where,
when
it
fires
off
an
event,
you
can
trigger
something
off
of
it.
Do
people
actually
want
that
or
do
they
really
want
some
other
aspect
of
it?
C
So
that
was
like
the
baseline
of
the
final
question
there
talking
through
these,
though
it's
interesting
to
see
that
50
of
the
responders
want
like
that
believe
that
traffic
routing
is
the
thing
that
matters
like
traffic
control
features
and
the
functionality
of
managing
traffic.
And
I
think
that
when
you
look
at
the
most
popular
talk
I
ever
gave
at
in
console
land
was
one
on
progressive
delivery.
C
It
was
how
how
we
cycle
out
the
running
state
of
an
application,
how
we
gradually
move
the
percentage
of
a
new
service
to
be
like
to
become
a
new
service.
How
do
we
gradually
roll
out
the
roll
out
like
deployments
and
a
new
version
of
the
api?
Our
new
version
of
the
front
end,
so
it's
kind
of
cool
to
see
that
end
up
being
kind
of
what
led
the
led
to
charge
and
then
observability
and
zero
trust
just
got
slaughtered
in
the
mix
which
I
messaged
marco
and
said.
C
I'm
secretly
really
happy
about
that,
because
I
just
think
that
I
think
that
problem
is
handled
better,
better
elsewhere.
I'd
never
like
jump
on
stage
and
and
say
that
to
the
world
and
tell
everyone
I,
I
think
it's
a
waste
of
time
here.
I
just,
I
think,
there's
more
elegant
solutions
for
the
the
security
aspect,
no
big
takeaway
from
the
size
here,
like
I
said
before,
just
it's
all
over
the
board
and
then
the
user
experience
thing
was
kind
of
a
it.
You
know
it's
a
very
validating,
validating
thing.
C
I
think,
and
that's
why
I
think
kuma
does
really
well.
I
think
kuma
has
nailed
the
user
experience
side
of
mesh.
I
think
there's
there's
there's
ways
to
go
and
there's
ways
to
make
it
better,
but
I
think
that
out
of
all
the
meshes
I've
worked
with
the
most
adoptable
and
easiest
to
do
complex
things
with
really
is
kuma.
C
It's
you
know,
hotshoe
corporate
talk
a
lot
about
console
being
very
easy
to
use
it.
Really,
it's
really
not
so
actually
there's
some
it's
really
powerful,
but
it's
a
it's.
A
tough
tool
to
actually
do
anything
outside
of
the
helm
chart
in
is
really
actually
actually
challenging
to
do
in
console
land.
I
found
it
interesting
that
extensibility
was
by
far
the
smallest
on
on
service
mesh,
which
kind
of
bummed
me
out,
because
I
I
thought
that
I
really
thought
that
extensibility
would
have.
C
It
would
have
been
a
bigger
story
like
how
do
we
integrate
surface
mesh
with
other
types
of
workloads,
but
it's
still
good
data
to
have
multi-zone
scored,
obviously
well
and
runtime
scored
pretty
well.
It's
not
surprising
that
this
grew
just
because
you're
seeing
more
people
go
to
go
to
kubecon
now,
who
are
from
kind
of
the
vm
space
and
starting
to
grow
on
that,
so
naturally
they're
going
to
care
about
like
the
relationship
between
between
those
things.
So
any
questions
comments.
What
do
you
guys
think.
D
D
A
But
I
I
somehow
also
feel
like
from
the
very
early
days
like
for
the
first
time
when
I
read
about
service
mesh
and
etc,
and
me
being
a
networking
guy.
I
was
I
I
always
looked
at
the
service
machine,
a
very
critical
way
like
why
why
this
thing
makes
sense?
Why
it's
made
like
this?
Why?
Why
why?
Why
and
the
promises
of
this
is
like
it's
the
I
don't
know,
what's
the
the
proper
english
expression,
but
it's
like
you
know,
rainbows
and
uni
and
unicorns.
A
Maybe
it's
this
like
it's
also
the
problem,
in
other
words
like
you,
just
have
to
get
service
mesh
and
bang,
and
people
are
like
expecting
that.
It's
something
that
you
just
deploy,
you
don't
see
it.
It
just
works
for
you
and
to
me.
The
truth
is
that
the
service
mesh
is
a
tool
and
you
have
to
design
for
it.
You
have
to
work
with
it
and
you
know
you
should
know
that
it
exists.
A
So
this
conversation
that
we
had
today
with
this
person
about
tomcat
and
it's
https
workload
and
the
person
is
like,
oh,
but
I
expect
that
my
https
will
pass
through
the
service
mesh
and
I
will
be
able
to
apply
http
rules
on
top
of
it.
This
is
the
level
of
like
what
kind
of
expectations
the
service
mesh
has
been
set
with
the
with
the
users
like
it's
it's
magic
and
it's
not
that's
the
reality.
So.
C
My
favorite
conversation
I
ever
had
same
same
concept.
I
was
talking
to
a
customer
back
back
at
hashgraph
days
and
they're
like
well.
I
don't
understand
why
I
need
to
why
we
need
to
involve
the
network
team
for
firewall
rules
when
we're
using
service
mesh
yeah,
and
I'm
like
guys.
It's
still
routing
like
like
just
because
it's
envoy
doesn't
mean
that
it
magically
teleports
packets
from
from
one
destination
to
the
other,
like
you
still
have,
the
problems
still
exists
like
we're.
C
Just
we're
just
implementing
a
better
way
to
interact
with
it
and
giving
you
a
programmable
interface
to
do
aspects
of
it
in
a
better
way,
but,
like
you
still
have
to
architect
for
this,
you
still
have
to
design
an
environment.
If
you
want
to
do
cross
cross
zone,
you
want.
You
want
to
stretch
a
service
measure
between
data
center,
a
and
b,
more
power
to
you.
That's
great.
You
still
have
to
have
some
form
of
like
steady
connection
between
those
environments
like
these
are
still
problems
that
exist.
A
E
E
Now
on
that
particular
network
namespace,
you
have
a,
we
have
application
and
you
have
kuma
dp
running
so
they
can
communicate
to
each
other.
Now
the
problem
is
the
moment.
I
define
the
the
data
plane
it
and
I
give
an
ip
address
for
the
vm
ip,
because
I
have
to
give
an
address.
So
I
give
the
vm
ip
address.
It
cannot
bind
to
that
and
if
it
cannot
bind
to
that,
then
that
particular
address
will
not
be
registered
in
the
control
plane.
A
No
there's,
no,
I
mean,
like
our
assumption.
All
the
times,
even
for
for
multi-zone
is
that
there
is
direct
reachability.
So
if
certain
data
plane
wants
to
talk
to
a
another
like
ingress
mesh
ingress
in
another
zone,
there
should
be
direct
type
reachability.
So
it
has
never
been
designed
in
a
way
that
this
that
this
can
work.
You
know
knotted,
like
hidden
behind
the
nut
network.
A
I
mean
this.
This
counts
more
or
less
from
the
you
know.
Like
way,
the
whole
service
mesh
concept
started
in
kubernetes
in
kubernetes.
You
know
everyone
sees
everyone,
so
you
can
kind
of
you
know
figure
out
why
why
we,
we
ended
up
here
now,
of
course,
in
the
virtual
machine
land,
and
you
know
bare
metals
and
everything
there.
You
can
have:
okay,
all
the
combinations
of
networking,
and
they
just
said
name,
spaces,
dockers
or
whatever.
So
it's
it's
much
much
much
more
complex,
so
we
are
kind
of
learning
and
evolving
around
this.
E
A
I
understand
what
you
want.
I
think
we
can
add
that
I
don't
think
that
there's
going
to
be
any
implications
to
anyone,
that's
not
interested
in
into
that
feature.
It's
just
like
you
know
another
field
in
the
data
plane
which
is
taken
into
account
when
service
is
being
registered.
Jacobila.
Do
you
see
anyone
anything
that.
E
Additionally,
what
I
see
is
like
in
your
control
plane,
you
don't
maintain
any
services
service
versus
ip
address,
mapping
right,
there's,
there's
nothing
that
you
maintain
a
registry
of
all
the
ip
addresses
you,
you
basically
compute
that
on
the
fly
and
then
you
push
it
down
to
on
y.
Isn't
it
there
is
absolutely
no
registry
that
you
maintain
of
all
the
data
place
that
you
have
discovered.
Have
you.
D
D
E
D
A
A
Maybe
that
that's
that's
also
another
design
that
you
can
do
if
you
have
particular
host
with
many
namespaces.
Maybe
you
can
kind
of
dub
this
as
a
this
is
a
zone
on
its
own?
You
have
your
local
control,
plane,
sitting
there
and
just
an
ingress
in
the
same
virtual
machine
and
then
expose
it
like
all
the
internal
services,
just
explode
them
as
another
service.
A
E
E
E
Kind
of
issues
that
we
are
we
are
trying
to
solve
once
your
feature
will
be
out
so
on
your
gateway
like
once,
the
feature
will
be
out.
We
can
actually
receive
all
the
traffic
and
then,
depending
on
on
the
http
path,
we
can
route
it
to
the
backends
that
we
want
to
send
it
to,
but
because
it's
all
tcp
based
now
so,
which
is
which
is
not
very
helpful
for
for
http
canada,
for
traffic.