►
From YouTube: Kuma Community Call - March 17, 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
A
This
call
should
be
recorded.
I
believe
it
is
okay,
so
in
the
agenda
for
today
I
have
put
so
I
saw
that
last
time
I
was
not
able
to
to
attend,
but
the
upcoming
one
one
zero
was
was
discussed.
A
So
maybe
a
little
bit
we'll
chat
a
little
bit
about
one
one,
zero
one,
one
one
and
this
native
prometus
integration
was
something
that
austin
was
talking
about.
I
don't
know
where
this
went.
I
was
hoping
that
he
joined
and
we
can
actually
talk
about
this.
A
But
if
he's
not
here,
maybe
we'll
skip
it,
and
then
we
have
the
open
q
a
session
for
anything
that
we
want
to
discuss
okay
quickly
so
last
week,
we
I
think
on
monday
was
the
release
of
one
one:
zero,
which
saw
a
lot
of
adoption
and
a
lot
of
feedback
which
made
us
release
a
quick
patch
releasing
a
couple
of
days
later.
A
So
the
recent
the
most
recent
release
is
one
one,
one:
okay,
we
have
some
some
fixes
here
mainly,
I
think
that
yeah
okay,
so
this
was
the
zip
king
config
that
was
added
by
a
community
member
and.
A
So
jacob
I
don't,
I
don't
know
if
you,
if
you
discussed
the
other
day
like
last
time,
if
you
discussed
the
specifics
of
one
one
zero,
but
the
main
one,
as
we
said
so
many
times
already,
was
the
xds
v3
migration,
which
was
one
of
the
main
reasons
for
tagging.
That
release
also
a
bunch
of
other
improvements
here
version
bombs,
some
new
features
had
it.
A
I
think
that
the
main
breaking
change
was
was
this
one,
and
I
think
that
we
also
saw
some
some
problem
with
this
at
some
point
yeah.
Essentially,
it's
a
let's
say
how
to
call
it
a
release
that
just
carries
the
progress
of
the
development.
A
It's
not
think
like
groundbreaking
from
what
I
can
tell,
although
the
xds
v31
can
argue
that
it's
a
groundbreaking,
I
think-
and
it
obviously
took
us
a
lot
of
prs
to
get
here,
but
also
on
the
other
hand,
this
was.
This
was
something
that
we
needed
already.
A
One
of
the
things
that
I
like
to
say
about
this
is
that
we
learned
a
lot
of
about
how
we
do
this
these
upgrades
specifically,
and
how
how
to
actually
do
a
long
term
support
for
things.
So,
as
the
feature
says,
we
default
to
xds
v3,
but
we
also
have
a
backward
compatibility
with
v2,
which
will
keep
for
another
couple
of
versions
from
what
I
understand.
A
So
every
new
feature
that
we
add,
like
every
new
policy,
will
be
supported
in
both
v2
and
v3,
which
is
a
little
bit
of
a
burden,
but
at
least
for
now
they
are
like.
The
two
versions
are
close
enough
so
that
it's
mostly
copy
pasting-
and
there
are
some
difference
here.
There.
B
Yeah
everything
you
said
is
true,
so
yeah
yeah
and
I
know
that
envoy
maintainers
have
a
plan
to
get
rid
of
v2
in
the
next
major
release
or
oh,
which
is
one
eighty
right.
B
Yeah
yeah
they
they
had
a.
They
had
a
plan
to
get
rid
of
this
in
117,
but
you
can
still
use
it
with
some
extra
flag
with
the
cli
because
well
yeah.
My
migrations
are
not
that
easy
to
do
so.
I
guess
people
meet
a
little
bit
more
time.
A
Okay,
are
there
are
there
any
questions
regarding
this
release,
anything
that
people
would
like
to
chat
about
anything
specific
out
of
the
features
fixes.
A
I
know
that
we
have
the
q
a
actually
if
hosting
is
not
with
us.
I
don't.
I
don't
see
the
rest
of
the
participants,
let's
see.
A
C
D
So
I
actually
asked
it
in
slack.
Also,
I
want
to
use
kuma
and
what
we
want
to
do
is
to
basically
provide
a
sub
ca
or
individuals
here,
but
then,
when
I
look
into
the
documentation,
what
I
see
is
it
specifically
mentions
in
the
documentation
that
sub
ca
or
intermediate
cs
are
not
allowed
just
wanted
to
know
as
in.
Why
is
such
a
hard?
Why
such
a
hard
rule
as
in?
A
B
I
don't
remember
the
exact
details
about
this
one,
so
the
overall
conclusion
was
to
just
disable
and
have
a
validation
that
we
do
not
support
intermediate
ca,
but
you
know
it
was
a
year
ago,
maybe
even
more
than
that,
so
maybe
something
has
changed.
B
I
see
that
nikita
here
says
that
it
works
for
her,
which
is,
which
is
great.
I
would
like
to
see
and
to
end
test
with
we've
provided
ca
with
intermediate
ca
and
if
it
works
by
all
means,
let's
remove
this.
This
limitation.
D
Yeah
yeah,
that
makes
a
lot
of
sense.
D
Additionally,
I
mean
if
I
can
ask
more
questions,
so
if
we
give
this
subordinate
ca,
will
each
and
every
mesh
get
its
own
ca
or
our
the
subordinate
c
will
be
used
for
each
and
every
mesh
that
is
created.
B
You
configure
provided
ca
on
the
mesh
itself,
so
technically
you
could
just
reuse
provided
ca
for
every
every
mesh.
You
would
need
to
create
a
mesh
secret
with
the
ca
in
every
mesh,
but
you
can
then
reuse
this
in
in
every
match.
Right,
but
overall,
the
rule
is
that
you
like.
It
is
a
good
idea
to
have
separate
ca
for
each
mesh
to
have
this
isolation
right.
D
So
the
immediate
question
on
top
of
that
would
be
like
because
it
will
be
a
little
tougher
users
to
use
it.
The
reason
being,
let's
say
if,
if
coma
is
used
in
our
in
an
organization
and
if
they
want
to
like,
have
some
kind
of
control
on
the
certificate.
D
So
it
will
not
be
easy
for
end
user
to
to
create
a
sub
or
nca
or
rca
for
that
matter.
So
it
will
be
great
if
the
ca
can
be
managed
by
the
platform
engineer
and
and
the
end
user.
Just
says
that
I
want
to
encrypt
my
east-west
communication
with
with
whatever
subordinates
here,
which
is
programmed
that
will
really
ease
out
the
configuration
here.
B
Okay,
I'm
not
sure
I
fully
follow
you
here,
so
why
would
the
user
have
a
certificate
signed
by
the
intermediate
ca?
Is
it
about
entering
the
mesh
with
this
certificate
or
or
what
exactly.
D
B
D
You
create
a
mesh
and
when
you're
trying
to
enable
the
mdls
on
that
at
that
point
in
time
we
are
supposed
to
provide
a
name
of
the
secret
right
or.
D
So
let's
say:
if
there
are
like
100
users,
then
all
hundred
of
them
needs
to
know
what
is
the
exact
subordinate
ca
that
they
are
supposed
to
use,
or
so,
instead
of
doing
that,
what
we
can
do
is
we
can
remove
that
subordinate
c
or
make
make
that
as
an
optional
field.
So
if
a
user
is
trying
to
provide
their
own
subordinate
crca,
that
particular
mesh
can
be
protected
with
with
whatever
is
provided
by
the
user,
and
if
nothing
is
provided,
then
we
can
have
a
fallback
ca,
which
is
maintained
by
the
platform
platform.
B
D
B
Okay,
so
we
specifically
designed
the
secret
to
be
mesh
sculpt,
for
this
reason
that
you
know
you
have
like
full
separation
between
measures.
So
as
far
as
I
imagine
how
this
could
be
done
is
okay,
of
course,
it
depends
on
your
use
case
right,
because
how
many
meshes
like
how
does
the
mesh
separation
look
like
in
your
company?
D
Mean
yeah:
there
are
like
two
things
here
right,
so
every
team
has
their
separate
mesh,
but
they
don't
really
need
to
get
into
the
mesh
management
as
a
secret
management
or
certificate
management
for
a
team
to
use
it
should
be
just
a
click
or
maybe
a
default
configuration
that
they
can
fall
back
to
and
the
requirement
is
just
to
enable
their
espace
communication
that
is
secure
the
resource
communication.
That
is
all
the
requirement,
is
instead
of
getting
into.
B
Okay,
okay!
Well,
I
have
one
idea
how
we
could
how
we
could
implement
this.
B
Let's
see
nikolai,
can
I
quickly
share
a
screen,
so
let's
go
to
comado
taiyo
and
to
mutual
tls,
and
let's
see
the
provided,
the
provided
ca
right
so
provided
ca.
B
Has
this
config
when
you
have
cert
and
key,
and
you
can
provide
the
name
of
the
secret
right
under
the
hood.
This
structure
here
is
called
data
source,
so
you
can
use
free
things,
you
could
use
secret
or
you
could
use
inline
string
or
a
file
which
we
do
not
support
in
this
use
case,
but
yeah
technically,
because
recently
we
introduced
the
concept
of
global
secret,
which
is
a
secret
which
is
not
mesh
scoped,
but
like
global
scope,
right,
it's
it's
not
bound
to
a
mesh.
B
So
technically
we
could
other
support
for
this
data
source.
Sorry,
I
don't
have
a
go
and
running.
We
could
add
the
support
to
have
a
global
secret
right
instead
of
secret.
So
if
you
really
want
to
use
global
secret,
which
is
shared
between
meshes,
you
could
do
this.
So
that's
a
potential
implementation
that
we
could
use.
So
that
would
be
really
explicit
for
user
that,
okay,
you
are
using
the
global
secret,
which
is
served
between
the
meshes
right.
D
B
Yes,
yes,
that's
true,
but
then
then
again
right,
the
the
mesh
operator,
the
infrastructure
team
just
creates
one
global
secret
with
the
ca
and
then
the
team,
like
teams,
can
use
this
use.
This
thing
right
overall,
I
imagine
that
mesh
object
is
managed
by
the
infrastructure
team.
B
B
Right
correct
there
is,
there
is
a
secret
section
when
you
can
learn
how
to
manage
secret
on
universal
and
kubernetes,
and
there
are
also
global
secrets
which
are
not
bound
to
a
mesh.
So
if
we
were
to
add
this
support
for
provided
ca,
we
could
we
could
potentially
support
the
use
case
that
you
are
asking
about.
B
Well,
yeah,
wait!
What
do
you
mean?
I
mean
this
one
has
to
be
implemented
right
to
work.
That's
just
my
quick
proposal
here
right,
but
it
it.
It
wouldn't
be
that
hard
to
implement.
So,
if
you
maybe
have
a
bandwidth
to
do,
this
prs
are
welcome.
Just
like
nikolai
said
recently.
D
So
that
is
one
struggle
that
I'm
having
so
my
company,
I'm
fighting
with
with
the
teams,
basically
how
we
can
so
that
it's
becoming
a
legal
problem
also
but
yeah.
It's
a
separate
branch-
and
I
I
want
to
you
know
pr's
here,
but
there
is
something
which
is
stopping
us
at
this
point.
B
Okay
yeah,
unfortunately,
marco
is
not
here
so
nikoi.
Maybe
you
can
chime
in
what
like
how
we
could
help
here.
D
I
mean
at
least
let
me
raise
a
issue
so
that
if
somebody
wants
to
pick
it
up
and
then
provide
a
solution
to
this,
it
will
be
great.
A
D
So
I
I
have
some
more
if
I
can
go
on.
D
Question
I
can,
I
can
ask
you
more
okay,
so
I
I
saw
brad
your
reply
for
the
for
the
issue,
so
I
have
given
this
screenshot
to
marco,
I'm
not
sure
whether
he
has
shared
it
with
you.
D
So
I
the
screenshot
I
had
shared
with
marco
that
you're
looking
for,
because
when
we
see
it
in
our
in
our
chrome
browser
all
the
time
whenever
we
try
to
open
kuma
ui,
it
does
not
open,
whereas.
C
Is
kind
of
busy
right
now,
so
it
would
be
faster.
I
think
to
just
send
it
to
me
the
same
name
but
smith
lies
in
the
community
chat,
so
I
could
look
quicker.
I
think.
D
D
And
one
more
thing
that
I
want
to
talk
about
is
on
the.
C
D
Gtp
route
that
we
wanted
to
add
using
traffic
traffic
route
crd.
D
But
what
I
feel
is
like
http
routes
are
more
so
the
way
traffic
traffic
routers
is
is
designed
as
it
has
a
source
and
a
destination,
and
and
once
you
choose
a
source
and
a
destination
after
that,
you
can
do
weights
on
the
destination
that
you
want
to
that.
D
You
want
to
give,
whereas
if
you,
if
you
want
to
support
http,
you
might
want
to
have
a
new
cid
altogether,
because
the
fundamental
there
is
a
fundamental
difference
between
these
two,
as
in
http,
depending
on
the
path
you
may
have
different
services
that
you
want
to
choose,
which
may
not
be
possible
to
do
from
traffic
route.
Cid
that
you
have
presently
so.
My
proposal
was
to
basically
add
a
new
crd.
B
D
D
That
is
what
I
say
right
I
mean
in
http
in
and
traffic
route
crt,
the
initial
section,
the
spec
says,
source
and
your
destination,
and
once
you
choose
source
and
destination
after
that,
the
rest
of
the
section
is
only
to
just
to
weighted
load
balancing
between
between
all
the
destination
which
is
chosen
on
the
first
section,
whereas
in
case
of
http
the
requirements
are
little
different.
Wherein,
depending
on
the
path
I
mean,
you
have
a
source
and
the
destination
could
be
anything.
D
So
multiple
either
multiple
definition
destination
has
to
be
chosen
and
then
and
then
you
can
do
path
based
routing
between
those
destinations
or
you
can
have
a
different
crd
altogether
and
the
good
part
about
having
the
entire
crd
is
like
mostly
people
who
will
like
to
use
it
on
the
gateway
side.
So
so
maybe
we
can
actually
define
a
crd
called
gateway
and
have
the
http
routes
defined
on
that
and
and
then
maintain
it
separately
for
http
and
and
use
the
traffic
route
crd
for
tcp
based
workloads.
D
Okay,
so
how
do
we
merge?
Actually,
I
was
having
difficulty
merging
both
of
them,
because
should
we
should
we
remove
the
I
mean:
do
you
think
it
is?
It
will
make
sense
to
remove
the
destination
field
from
the
first
section
and
and
depending
on
the
weights
or
depending
on
the
parameters
in
the
in
the
second
half
of
the
traffic
round
section,
the
traffic
could
be
let
out.
D
D
That
you
can
use
so,
let's
say
your
path,
service,
one
path,
service,
two
path,
service,
three
path,
service,
four,
but
all
of
them
originating
from
the
same
source;.
C
D
Can
we
achieve
that
using
traffic
routes,
crd.
D
But
isn't
isn't
the
first
section
of
your
traffic
route?
I
mean
if
you
can
share
your
screen.
The
first
section
of
your
traffic
route
says
source
destination.
So
once
you
have
finalized
on
a
destination,
I'm
not
sure
if
you
can
actually
have
some
other
destination,
so
they
could
be
like
back
in.
C
D
B
Yeah,
I
believe
you
could
do
this
right
or
you
have
this
crg,
so
you
can
have
many
matches
for
different
services
right
and
for
this
one,
instead
of
split
you
probably.
B
B
Yeah,
but
here
okay,
of
course
it
depends
on
the
use
case,
because
with
traffic
route
and
http
you
could
use,
you
could
do
all
sorts
of
crazy
stuff
right.
B
But
but
you
could
do,
for
example,
web
to
anything
and
then
specify
the
routing
which
would
be
applied
when
you
are
trying
to
communicate
with
any
service
or
if
you
would
like
to
just
manage
the
traffic
between
web
and
backend.
You
put
web
here
back
and
here
and
then
in
http.
You
could
rewrite
the
traffic
to
completely
new
service.