►
From YouTube: Getting Started with Service Mesh - Kong Builders
Description
Kong Builders is a new livestream series that takes a hands-on, practitioner-focused approach to exploring Kong's tools - namely Kuma and Kong Mesh. We'll build from the ground up - teaching how service mesh works from its foundations, and debugging/troubleshooting as we run into problems.
In this first episode, Cody De Arkland from Kong discusses some of the basics of service mesh and how to get set up on Kuma.
▬▬▬▬▬▬ TIMECODES ▬▬▬▬▬▬
0:00 - Intros
2:40 - What is Kuma?
6:25 - How to install Kuma?
10:20 - Difference between Kong Mesh and Kuma
19:00 - Install Kuma Control Plane
23:30 - Why do I use Service Mesh?
27:50 - Deploying applications
39:32 - Installing Kong Ingress Controller (KIC)
42:13 - API Gateway vs. Service Mesh?
46:24 - Configuring external access with Kong Proxy
49:26 - Live demo
56:40 - Configuring traffic permissions policies
59:07 - It's a wrap!
▬▬▬▬▬▬ LINKS ▬▬▬▬▬▬
❏ Data plane documentation: https://kuma.io/docs/1.1.6/documentation/dps-and-data-model/
❏ Demo app: https://github.com/codyde/mesh-demo-app
▬▬▬▬▬▬ CONTACT CODY ▬▬▬▬▬▬
🐦 https://twitter.com/codydearland
▬▬▬▬▬▬ ADDITIONAL RESOURCES ▬▬▬▬▬▬
•Getting Started With Kuma Service Mesh: https://bit.ly/3sLAn7R
• “Gateway Mode” in Kuma and Kong Mesh: https://bit.ly/3ixLeQQ
• Automate Service Mesh Observability With Kuma: https://bit.ly/3vMk3Vt
#ServiceMesh #Kuma
A
All
right,
I
think
we
are
live.
I'm
gonna,
I'm
gonna,
pretend
like
we're
live.
I
can't,
unfortunately
see
who's
out
there
with
me
hanging
out,
but
I
wanted
to
welcome
everyone
to
kong
builders.
So
those
who
don't
know
me
my
name
is
cody
d
arkland.
I
work
for
kong.
Obviously
it'd
be
super
weird
if
I
was
doing
a
doing
a
live
stream
for
kong,
but
not
working
here.
I've
got
a
couple
of
of
great
folks
helping
me
out
with
this
to
make
this
possible
today.
A
So
taren
with
our
developer
developer,
marketing
team
is
helping
run
the
show
and
then
michael
heap
mike
leap
recently
joined
kong.
He
leads
up
our
developer
relations
team,
so
he's
a
great
guy
you'll
see
a
lot
of
stuff
coming
out
from
his
team
in
the
near
future.
They
got
some
really
cool
plans
for
for
what
they're,
what
they're
gonna
be
doing.
We
work
pretty
closely
together.
A
So
let's
talk
about
why
we're
here?
Obviously
I'm
not
sharing
anything
on
the
screen
yet
and
in
a
few
minutes
my
look
will
go
from
here
to
here
and
we'll
and
we'll
jump
into
actually
building
some
things
yeah.
My
name
is
cody.
I
joined
kong
because
I
think
that
we
have
a
really
cool
way
of
connecting
applications
across
an
entire
environment.
A
I'm
an
application
guy
by
by
nature,
I'm
an
infrastructure
guy,
but
I
really
enjoy
the
way
we
connect
and
we
make
applications
run,
run
better
in
environment
and
something
I
really
wanted
to
do
was
do
a
live
stream
where
we
go
through
and
we
build
service
mesh
from
the
ground
up.
So
we
talk
about
service
dust,
a
lot
and
it
happens
in
the
industry.
So
I
try
to
make
this
as
a
non-vendor
specific
as
possible.
A
A
lot
of
us
talk
about
service
mesh,
but
we've
done
a
we've
had
a
hard
time,
getting
it
to
a
place
where
it's
adoptable
by
people
and
I'm
not
saying
installable
in
the
enterprise.
That's
a
whole
other
conversation,
but
where
people
understand
the
technology
in
a
way
that
they
can
use
it
and
do
things
with
it.
I
think
it's
a
technology,
that's
far
ahead
of
its
time
and
hopefully,
as
we
go
through
the
stream
you'll
start
to
figure
that
out
too
and
you'll
see
it
on
the
journey
as
well.
A
So
we're
going
to
jump
in
here
in
a
few
moments
and
we're
going
to
build
from
the
ground
up.
This
stream
is
going
to
be
a
little
bit
different
than
the
future
ones
and
the
future
ones
we're
going
to
start
building
applications
we're
going
to
be
in
and
out
of
vs
code,
like
actually
configuring
things
building
code
and
pushing
code
up
and
into
into
docker
running
containers
like
that
in
this
stream.
A
I
really
want
to
build
the
foundation
of
what
service
mesh
is
and
how
it
works
before
we
start
doing
complex
stuff
down
down
the
road
so
talking
a
little
bit
about
kuma
and
what
kuma
is
kuma
is
an
open
source
service
mesh
that
was
developed
by
kong
and
donated
to
the
cncf.
So
it's
the
only
service
mesh
in
the
cncf,
that's
envoy,
based,
so
we
use
envoy
as
a
sidecar.
This
is
a
an
important
term.
A
That's
going
to
come
up
later,
we'll
dive
into
it
and
show
some
visuals
around
it
as
we
get
through
to
help
but
understand,
but
you
could
think
of
a
sidecar
as
a
thing
that
sits
alongside
your
application
notice.
I
didn't
say,
container
side.
Cars
are
most
commonly
in
containers,
but
there
are
sidecar
processes
that
will
run
alongside
a
virtual
machine
as
an
example
and
these
side,
cars
in
the
case
of
a
service
mesh,
allow
communication
between
other
side
cars.
So
they
act
as
this
proxy
layer
that
allows
communication
to
happen.
A
Why
do
we
do
this
in
the
sidecar,
because
it
lets
us
bring
a
bunch
of
new
functionality
on
top
of
what
that
application's
already
doing
right.
So,
in
the
case
of
kuma
and
kong,
mesh
kong
mesh
is
the
enterprise
version
of
kuma.
We
get
to
bring
in
things
like
observability
out
of
the
box,
which
is
a
really
fancy
marketing
term,
but
what
that
means
is.
I
can
get
a
lot
of
good
metrics
around
what
the
application
is
doing.
We.
B
A
It
really
easy
to
get
grafana
prometheus
jaeger
up
and
running
we're
going
to
step
through
that
stuff.
In
a
later
stream
we
can
control
traffic
policy
a
lot
better,
so
we
can
do
is
something
my
favorite
service
mesh
demo
is
being
able
to
control
the
way
you
roll
out
a
new
application
and
split
traffic
between
the
old
version
and
the
new
version,
so
you're
gradually
rolling
this
out
james
governor
redmond
talks
about
this
and
the
concept
of
progressive
delivery.
A
It's
it's
kind
of
my
favorite
thing
about
service
mesh
is
that
we
make
the
ability
to
progressively
deliver
applications
so
much
easier.
So,
let's,
let's
table
all
that
for
a
second,
let's
get
in
and
start
playing
with,
some
playing
with
some
code.
Looking
at
the
docs
again,
I
want
this
to
be
interactive.
I've
got
a
great
team.
Helping
me
out.
I
introduced
them
already.
Fire
questions.
Ask
things
about
service
mesh.
Anything
you
want.
I
want
this
to
be
an
open
forum.
A
If
you
want
to
ask
questions
about
other
service
meshes,
you
can
do
that.
Anyone
who
knows
me
in
the
community
knows
that
I
don't
get.
I
don't
get
uber
competitive.
I
just
like
to
I
like
to
talk
about
technology.
I
like
to
teach
people
it's.
My
favorite
thing
in
the
whole
world
is
to
watch
people
figure
this
stuff
out
and
get
their
own
ideas
as
we
as
we
build
together.
So
if
you.
B
B
A
Now
we
read
this
website.
We
update
this
website
as
new
versions
come
out
pro
tip
in
the
about
in
a
week
from
now
we'll
be
doing
another
one
of
these
live
streams.
Actually,
next
wednesday
or
thursday
we'll
be
doing
a
live
stream
around
the
next
kuma
release,
so
we'll
be
releasing
a
new
version
of
kuma,
with
some
really
cool
new
features,
so
we'll
be
doing
another
kong
builders
session,
then,
where
we
dive
into
that
new
release
and
play
with
some
of
the
new
new
features
that
are
coming
out.
So
that's
pretty
exciting.
A
If
we
want
to
go
into
getting
started,
this
is
the
best
place
to
obviously
get
started.
It's
funny
enough.
When
you
look
back
at
when
I
look
back
at
how
I
ended
up
at
kong,
this
was
probably
one
of
the
biggest
things
that
brought
me
to
kong.
Was
this
page
because
when
I
went
in
and
started
looking
at
kuma
and
I
saw
all
of
the
different
platforms
that
we
support,
I
thought
that
was
a
pretty
cool
thing.
The
ability
to
run
this
across
a
number
of
environments-
we
could
run
this
on
virtual
machines.
A
A
I'll.
Take
a
look
at
that
here
in
a
few
as
well,
so
we'll
jump
in
first
to
the
kubernetes
deployment.
What
this
is
going
to
do
is
it's
going
to
give
us
the
most
updated
kuma
control,
binaries
akuma
control
is
our
kind
of
process,
or
it's
a
it's.
A
command
line,
binary
that
lets
you
do
things
inside
of
kuma,
so
we'll
go
ahead
and
grab
this
I'll
switch
back
into.
B
A
A
And
what
this
directory
actually
has
is
the
actual
application,
so
the
application
I'm
going
to
deploy
today
is
a
five-tier
application.
It's
got
a
web
front
end,
it's
got
a
post
and
a
user
service.
It's
got
a
database
here
and
it
also
runs
redis
because
you
can't
do
any
demo
without
a
redis
tier.
It's
kind
of
a
mandatory
thing
for
for
demos.
That's
a
joke!
I've
also
got
some
insomni
api
stuff
in
there.
A
If
we
go
in
and
take
a
look
at
the
actual
yaml
for
deploying
this,
we
can
see
kind
of
the
the
overall
topology
of
my
application.
I
won't
dive
too
far
into
the
ammo,
yet
we'll
get
into
this
soon
enough,
but
just
wanted
to
show
you.
This
is
an
actual
application.
It's
going
to
deploy.
You
can
see
this
in
the
repo.
I
think
the
repo
is
a
little
ways
behind
so
I'll
need
to
push
and
push
an
update
into
there.
A
Is
not
the
best
experience,
let's
go
ahead
and
get
started
with
the
binary
for
comma
control,
so
this
does.
Is
this
pulls
down
the
most
recent
package
when
we
read
to
the
new
version
of
kuma,
if
you
run
this
command
again,
it'll
pull
down
the
binary
again
for
the
new
version.
I
have
it
installed
on
my
system
already,
but
I
have
kong
mesh
installed
that
congress,
being
the
enterprise
version,
is
a
little
different.
A
A
That
gives
you
five
licenses
and
I
think
it's
either
30
or
60
days
to
run
inside
an
environment
before
it
before
the
license
goes
away,
and
then
you
can't
run
anything
so
in
the
short
term,
we'll
use
kuma
and
we'll
play
in
the
open
source.
One
there's
a
couple
of
features
that
are
missing
in
there
are
a
couple
features
that
are
missing
in
versus
the
enterprise
version,
a
couple
things
like
external
cert
authority.
A
All
right,
so,
let's
take
a
look
at
a
couple
of
things
that
are
in
this
directory.
Before
we
do
the
install
itself,
we've
got
core
dns
and
envoy
here.
These
are
kind
of
helpers
that
go
along
with
what
we're
doing
we
run
envoy.
Obviously,
as
our
sidecar
process,
we
use
envoy
because
it's
an
open
source
tool
that
has
a
ton
of
development
behind
it.
It
lets
us
focus
on
building
kind
of
the
best
darn
service
mesh.
We
can,
while
letting
the
envoy
team
focus
on
making
envoy
better.
A
We
commit
back
in
any
changes
or
any
needs
into
envoy.
We
have
a
really
good
relationship
with
with
matt
klein,
and
the
team
to
you
know,
live
in
that
open
source
community
and
help
build
against
against
envoy
as
needed.
So
we
include
that
in
in
the
package
or
in
our
kind
of
repository
as
part
of
as
part
of
the
package
coordinates.
B
A
As
a
part
of
kuma,
as
well
mostly
for
the
universal
deployment,
universal
deployment
is
on
virtual
machines
versus,
like
the
kubernetes
standard,
that
containerized
deployment,
so
puma
cp
is
our
control
plane
process.
So
for
running
this
on
a
virtual
machine,
you
run
kuma
cp
if
you're
going
to
run
a
virtual
machine
or
run
it
as
a
control
plane.
This
is
a
good
time
to
talk
about
control,
plane
versus
data
plane,
control
plane
is
the
management
tier
so
to
speak,
of
a
service
mesh.
A
So
when
you
work
with
api
or
you
push
policy,
that's
a
control,
plane
operation,
the
control,
plane
feeds
configuration
data
down
to
a
data
plane.
That's
what
that
kuma
dp
process
is
the
data
plane?
Is
that
sidecar?
I
talked
about
earlier,
so
a
data
plane
lives
alongside
your
application
data
planes
register
themselves
with
a
control
plane,
so
as
administrators
of
the
system.
When
we
go
and
build
a
service
mesh
for
our
for
our
customers.
For
our
people,
inside
of
an
environment,
we
are
standing
up
the
control
plane
when
developers
deploy
their
application
against
service
mesh.
A
They
are
deploying
their
application
and
getting
a
data
plane
alongside
it.
That
data
plane
communicates
back
and
forth
with
the
service
mesh
control
plane
to
receive
configuration
data
getting
a
little
deeper
that
happens
over
a
process
called
xds,
so
xds
pushes
those
configuration
changes
down
to
the
envoy
instances
and
environment
these
these
sidecars
or
data
planes
receive
configurations
across
the
entire
environment.
So
whenever
I
make
a
new
policy
change
that
pushes
down
to
the
sidecar,
the
sidecar
receives
that
this
is
an
important
distinction,
because
we
talk
a
lot
about
running
in
a
decentralized
way.
A
This
is
one
of
those
kind
of
buzzword-y
terms
that
pops
out
all
the
time
and
I'm
not
sure
that
anyone's
ever
really
taken
the
time
to
explain
what
that
really
means
in
the
context
of
service
mesh.
So
when
we
think
of
decentralized
the
control
plane
itself,
the
actual
functionality
is
a
centralized
control
plane.
But
what
it's
doing
is
it's
taking
its
configurations
and
the
things
that
you're
doing
and
pushing
into
it
and
sending
it
down
to
all
of
those
side.
A
A
Every
one
of
those
envoy
instances
knows
the
full
configuration
of
the
service
mesh,
so
they
can
receive.
They
can
act
on
their
policies
locally.
They
don't
have
to
go
back
and
check
in
for
like
a
traffic
permission.
For
example,
if
we're
saying
a
front
end
can
talk
to
a
back
end,
it
doesn't
have
to
say
the
front
end
doesn't
have
to
reach
out
to
the
control,
plane
and
say:
hey.
Am
I
allowed
to
make
this
communication?
Am
I
allowed
to
reach
out
to
the
back
end?
A
It
knows
it's
communication
protocol
and
its
permissions
locally
inside
inside
of
its
envoy
instance.
So
it's
running
decentralized.
This
becomes
really
powerful
when
we
start
to
talk
about
like
load
balancing
as
an
example.
So
I
came
from
the
enterprise
I'm
used
to
like
living
in
this
world,
where
I
have
these
massive
load.
A
Balancers
that
live
inside
of
my
environment
and
they
act
as
like
the
centralized
place
for
configuring
load,
balancer
information,
but
if,
like
the
load,
balancer
goes
down
somebody
trips
over
the
cord
in
the
data
center
that
load
bouncer's
offline,
all
the
vips,
the
virtual
ips
that
host
apps
those
are
down
too
no
one's
getting
to
the
applications.
Hopefully,
you've
set
up
in
some
way,
but
if
somebody
trips
over
the
whole
power
cord
for
the
whole
data
center,
your
load
bouncers
are
offline.
A
In
the
case
of
like
an
envoy
situation
where
we're
using
this
decentralized
approach
and
this
decentralized
load,
balancing
they're
able
to
evaluate
locally
hey
what
other
instances
are
nearby,
what's
the
address
for
those
instances,
how
can
I
reach
them
and
that
load
balancing
functionality
still
works?
There's
a
lot
more
to
that
concept.
That's
worth
unpacking
in
future
videos,
but
that
decentralized
approach
to
our
data
plane
is
one
of
the
things
that
makes
service
mesh
across
the
industry,
such
a
powerful
tool
and
such
a
powerful
functionality.
A
Kuma
prometheus
sd
is
a
is
a
tool
to
help
get
metrics
from
a
universal
deployment
into
prometheus.
So
it
lets
us
have
that
consistent
observability
experience,
consistent
metrics
experience
between
both
virtual
machines
and
kubernetes
clusters-
full
disclosure-
all
this
is
handled
for
you
in
the
kubernetes
environment.
That's
why
we're
using
it
today
we
will
get
to
doing
it
in
universal
down
the
road,
but
today
we're
going
to
get
up
and
running
in
kubernetes
very
quickly.
A
We've
spent
a
lot
of
time
talking
about
this
stuff,
so
it
sounds
very
like
a
long
process
to
get
to,
but
you're
going
to
see
that
getting
this
up
and
running
in
kubernetes
is
actually
quite
quite
quick
and
then
kuma
control.
Scuba
control
is
our
is
our
binary
that
lets
us
configure
aspects
of
kuma.
So
if
I
run
kuma
control.
A
This
is
to
me
one
of
my
favorite
things
about
the
approach
we've
taken
to
kuma
and
when
people
ask
me
what's
the
number,
if
I
had
to
pick
the
one
thing
that
I
think
kuma
does
better
than
the
other
meshes
in
the
market,
it's
the
user.
Experience
of
getting
it
running.
I
think
that
service
mesh
is
universally
powerful
in
the
industry,
but
what
we've
done
inside
of
kuma
is
make
it
very
usable
and
very
easy
to
get
started
with,
and
the
install
is
kuber
control,
install
control
plane.
A
What
I
want
to
bring
metrics
functionality
in
it's
kuman's
control,
install
metrics.
When
I
want
to
install
a
gateway,
it's
kuma
control,
install
gateway.
All
these
things
give
you
as
an
operator
a
very
quick
path
to
getting
things
done
in
an
environment.
So
I
have
a
lot
of
appreciation
for
the
for
the
use,
the
user
experience
side
of
things.
A
Install
control
plane
now
you'll
see
my
auto
complete
kicking
in
there
as
if
I'd
done
this
before,
but
first
I'm
going
to
run
it
without
that.
Oops
finish
that,
so
you
can
see
what
this
command
would
normally
do.
What
this
is
going
to
do
is
it's
going
to
output
the
configuration
yaml
for
deploying
out
kuma,
so
you
can
see
the
entire
process.
That's
going
to
go
into
actually
deploying
out
kuma
from
a
kubernetes
standpoint,
just
to
be
a
good
magician
and
show
my
environment.
A
B
A
A
A
bunch
of
stuff
is
happening
here
talking
through
it.
While
that
system
comes
online,
we've
created
a
namespace
for
kuma
system.
That's
namespace
is
where
the
kuma
control
plane
is
going
to
live
in.
Inside
of
kubernetes,
we've
created
a
service
account
for
the
control
plane
process
set
up
the
cert
set
up
a
config
map
for
all
of
the
configurations.
A
A
So
each
one
of
these
is
a
policy
or
a
component
or
an
interaction
point
inside
of
inside
of
kuma,
that's
very
relevant
to
the
environment,
so
we
create
a
series
of
crds
and
we
apply
these
configurations
moving
forward
against
our
moving
forward
against
the
environment.
This
gets
really
interesting
when
we
do
a
global,
a
global
deployment
of
kuma,
so
we
have
a
standalone
and
a
global.
A
standalone
is
just
I'm
running
this
as
a
single
mesh
in
a
single
environment
where
it's
a
single
virtual
machine,
environment
or
single
kubernetes
environment.
A
A
global
deployment
means
that
I'm
using
a
kuma
control
plane
to
interact
with
multiple
different
kuma
environments
or
kong
mesh
environments,
a
good
example.
This
would
be
running
that
global
control
plane
in
a
vsphere
environment
inside
your
data
center,
but
then
connecting
a
eks
environment,
an
azure
environment,
a
gke
environment,
a
linode,
a
linux
environment,
a
digital
ocean
environment
having
them
all
act
as
a
single
service
mesh
between
those
environments.
There
are
multiple
zones
so
that
each
one
of
those
environments
is
called
a
zone,
but
they
are
all
acting
as
one
mesh.
A
A
A
A
We're
running
in
standalone
mode,
so
we
only
have
the
one
zone
we
have
one
mesh
now
this
is
a
pretty
cool,
pretty
cool
feature
of
kuma.
That's
pretty
unique
in
how
we
approach
it
to
kind
of
address
what
this
is.
Let's
step
back
a
little
bit,
why
do
I
service
mesh?
Why
do
I
care
about
all
this?
What
does
this
actually
matter?
A
What
is
better
in
this
case,
I
think
that
by
default,
we're
used
to
writing
our
applications
to
connect
to
other
things
right
so
in
in
react,
my
you
know
my
favorite,
my
favorite
when
front
end
language
to
write
in
so
in
react.
I
use
the
fetch
the
fetch
api
to
reach
out
to
back
end
api,
so
I
might
fetch
something
like
slash
api
health
to
return
health
data.
A
Aside
from
your
application,
connectivity
yeah,
you
reach
your
back
end
and
life
is
good,
but
day
two
is
always
the
struggle.
You
know,
I
joke
a
lot
that,
like
day,
one
we're
all
kind
of
equal,
whether
it's
service
mesh
or
whether
it's,
whether
it's
regular
applications
but
day
two
is
something
none
of
us
ever
budget
for,
and
none
of
us
ever
think
about
because
day
two
is
when
all
the
complexity
comes
right.
So
when
I
want
to
scale
that
environment
and
now
suddenly,
I
want
to
bring
in
four
tiers
of
my
application.
A
That's
a
change
that
oftentimes
is
a
whole
new
ball
game
service
mesh
makes
it
simpler
to
create
one
more
dynamic
environment.
It
makes
it
simpler
to
bring
in
additional
functionality.
So
when
I
want
to
roll
out
api
v2,
maybe
the
user
service
goes
to
v2,
and
I
want
to
deploy
out
that
new
v2
service.
A
I
can
use
service
mesh
to
gradually
roll
that
out.
I
talked
about
that
earlier
in
the
concept
of
progressive
delivery.
I
can
also
use
traffic
routing
to
change
the
routing
of
services
between
that
service
mesh
environment.
This
is
a
task
that
typically
would
be
a
ticket
to
a
network
team
in
the
past
or
a
a
manual,
a
manual
process
of
some
sort
to
get
that
change
made.
A
These
are
all
things
that
can
be
self-served
inside
of
service
mesh,
because
what
we've
created
is
an
application
connectivity
platform.
It's
something
that's
built
for
self-service
from
the
ground
up,
it's
something
that's
built
to
be
used
in
ci
cd,
and
you
can
kind
of
see
here
the
kind
of
makings
of
that
self-service
environment.
I've
got
this
meshes
concept
that
lets
me
create
multiple
virtual
service
meshes
inside
of
this
infrastructure
environment.
I've
got
a
default
one
set
up
right
now,
maybe
I
could
create
another
one.
You
know
I
mentioned
earlier
that
michael's
hanging
out
with
me.
A
I
know
victor's
out
in
the
audience
helping
out
too
victor
works
for
works
for
michael
welcome
to
kong.
Victor
excited
to
have
you
here
dude,
maybe
I
want
michael
and
victor
to
have
their
own
service
meshes
inside
of
my
environment.
I
could
create
a
mesh
called
victor,
create
a
mesh
called
michael
and
I
could
have
them
be
able
to
access
those
environments.
So
when
they
apply
traffic
routing
policies,
they
only
apply
inside
of
their
environment.
A
So
if
michael
wants
to
have
front
end
talk
to
what,
when
front
end
talks
to
api,
he
wants
to
send
api
to
user
service.
He
can
apply
that
traffic
routing
policy
himself,
whereas
victor
can
maybe
have
the
front
end
talk
to
api,
but
have
it
go
to
users
instead
or
post
instead?
Rather,
they
can
apply
separate
policies
that
don't
impact
each
other,
but
they
can
have
them
be
part
of
the
same
global
service
mesh.
So
it's
a.
A
When
you
start
to
look
at
things
like
configuring,
independent
mtls
certificates
or
a
different
metrics
configuration
or
specific
load
balancing
configurations,
service
mesh
is
all
about
creating
a
platform
for
consumption.
How
do
we
consume
aspects
of
application
connectivity?
How
do
we
use
this
whole
policy
concept
to
drive
things
and
that
this
entire
kong
builder
series
is
about
uncovering
these
different
policies
and
how
to
use
them
in
a
practical
way?
So
how
do
we
write
an
application
and
actually
do
something
with
it
inside
of
service
mesh?
A
A
Let's
jump
back
into
our
our
yaml
real
quick
without
going
blind
from
all
of
it
and
talk
a
little
bit
about
what
this
is
going
to
do.
First,
I
deploy
out
a
config
map.
This
is
written
into
my
application.
This
is
not
a
kuma
thing,
but
this
is
all
of
the
configuration
information
form
for
my
application.
A
You
can
see
I'm
using
kuma
as
the
mesh
type
here
and
the
kuma
system
namespace
this
part's
very
important,
I'm
creating
a
namespace
called
kong
and
in
this
namespace
I'm
adding
an
annotation
to
that.
Namespace
annotations
in
kubernetes
are
basically
notes
on
a
field,
but
we
can
use
those
notes
and
many
vendors
do
this
use
these
notes
or
these
annotations
to
configure
aspects
of
that
environment
in
this
case
we're
adding
an
annotation
called
cooma
dot.
Io
sidecar
injection
enabled
what
this
says
is
any
app
any
pod.
A
That's
deployed
a
pod
being
the
lowest
atomic
value
in
kubernetes.
Anything
deployed
into
this
namespace
gets
a
sidecar.
This
means
I
don't
have
to
go
in
and
configure
every
one
of
those
deployments
to
have
one
anything
that
goes
in
here
is
automatically
going
to
get
one
that
sidecar
is
automatically
gonna
bolt
onto
that
application
and
then
reach
back
out
to
to
the
environment
or
to
the
control,
plane,
environment
and
I'll,
be
able
to
show
that
in
a
few
moments.
A
So
we
create
this
namespace
and
then
we
create
a
bunch
of
resources,
not
gonna
go
through
all
of
them,
but
we
have
a
front
end
and
I
really
wanted
to
show:
was
the
service
the
front
end
and
the
service?
This
service
is
one
of
the
key
components
of
of
kuma
in
this
case,
because
what
that
does
is
create
the
reference
to
kuma
to
understand
how
to
communicate
with
this
service,
so
that
is
pushed
back
into
the
control
plane
and
the
control
plane
distributes
this
out
to
my
environment.
A
A
B
B
A
A
There's
another
step
of
setting
up
kuma,
that's
important.
So
how
do
we
start
to
debug
this?
I
talked
about
how
we
wanted
this
to
be
a
builder
series
where
we
start
from
the
ground
up
when
we
debug
problems
as
they
come
up.
How
do
we
start
to
debug
this?
This
gets
beyond
kuma,
and
this
is
like
a
kubernetes
question.
How
do
I
start
to
look
at
why
this
isn't
working,
I
can
see
this
front
end
is:
is
flapping
right?
It's
coming
up
and
immediately
crashing
out,
so
it's
canceled
out
of
the
watch.
A
A
My
front
end
uses
nginx
to
host
the
actual
application
so
that
the
the
hanger
I'm
sorry
the
react
style
application.
Sorry
it's
hosted
in
nginx.
If
we
take
a
look
at
the
application
code
and
we
go
into
the
front
end
tier
we
can
see.
I
do
a
number
of
reverse
proxies
in
here
to
get
to
aspects
of
that
environment
and
I'm
always
using
this
at
this.mesh
address
by
default.
Kubernetes
doesn't
know
anything
about
a
dot
mesh
address.
A
That's
not
a
standard
kubernetes
thing,
so
what
we
need
to
do
is
we
need
to
have
kuma
be
able
to
understand.
What
do
I
do
with
the
met.mesh
address?
Uma
has
its
own
dns
provider
that
we
just
need
to
install
alongside
it.
So
we
installed
the
kuma
control
plane,
but
we
didn't
install
the
mesh.mesh
address
as
well.
This
functionality
is
changing
in
the
upcoming
release,
where
dot
mesh
should
be
included
as
part
of
that,
if
not
this
next
release
it'll
be
very
soon
after,
but
this
is
a
temporary,
a
temporary
thing.
A
A
Now,
what
I've
done
here
is
I've
deleted
the
pod,
but
I
didn't
delete
the
deployment
each
one
of
those
things
was
the
deployed
as
a
deployment.
So
pods
are
the
smallest
atomic
unit
in
kubernetes.
A
deployment
is
a
collection
of
pods
and
can
end
the
configurations
for
standardizing
that
pod
deployment,
so
we
can
do
replicas
inside
of
inside
of
the
deployment
and
say,
run
four
copies
of
my
servers
as
an
example.
In
this
case,
I
deleted
the
pod.
The
deployment
wants
to
ensure
that
that
pod
still
exists,
so
what
it
does
is
it
recreates?
A
A
So
I'm
not
gonna
break
down
this
entire
log
file
because
there's
a
lot
happening
here,
but
what
you're
seeing
here
is
the
communication
back
to
the
control
plane.
So
these
side
cars
have
registered
out
to
the
control
plane.
If
we
switch
back
to
the
ui
and
do
a
quick
refresh
on
this
environment,
we
can
see
these
have
all
registered
they're.
Getting
their
configurations
see
that
they're
receiving
updates
from
the
environment.
A
These
total
updates
are
the
equivalent
of
what
we're
seeing
in
this
log
file.
Here
again,
this
is
another
thing:
that's
consistent
amongst
the
service
meshes
if
you
run
another
service
messaging,
you
look
the
side,
car
logs
you're,
going
to
see
something
very
similar
here.
We've
done
some
optimizations
to
ours
and
there's
reasons
why
we
set
it
up
the
way
we
have
that
we
believe
to
be
the
right
path,
but
this
is
common
troubleshooting
stuff
across
across
the
surface
platforms.
A
Understanding
that
relationship
between
a
side,
car
and
the
control
plane
is
is
a
it's
an
important
thing
for
understanding
how
the
functionality
works,
but
it's
something
that
you
ultimately
consume.
It's
not
something
that
you
should
necessarily
need
to
interact
with
this
pod.
You
shouldn't
need
to
go
into
this
pod
and
do
any
other
sidecar
at
least,
and
do
anything
with
it.
It's
just
good
to
know
that
communication
pathway.
Ultimately,
this
sidecar
is
intercepting
inbound
and
outbound
communication
and
everything
that's
trying
to
reach
that
actual
pod.
That
you've
deployed
is
running
through
the
sidecar.
A
B
A
B
A
B
A
A
So
what
we're
going
to
do
is
we're
going
to
use
something
called
kong's,
ingress
gateway
or
I'm
sorry,
kong's
ingress
controller
rather
kik
is
an
ingress
controller
for
kubernetes
that
lets
you
reach
services.
It
gives
you
that
kong
gateway
experience
in
a
kubernetes
native
way.
I
believe
victor
is
doing
some
really
cool
content
on
congress
controller,
so
keep
an
eye
out
for
that
it's
I
saw
a
preview
of
it
today.
It's
amazing
victor's,
doing
great
work.
I'm
really
excited
to
see
how
that
video
turns
out.
A
So
this
becomes
effectively
another
application
running
inside
of
our
service
mesh
environment
in
the
next
version
of
of
kuma
you'll
be
able
to
install
the
gateway
from
the
command
line,
the
framework's
already
there
for
it.
So
if
I
went
in
and
going
back
to
earlier,
when
we
did
our
install
you
can
see.
A
If
I
do
that,
you
can
see,
there's
a
gateway
flag
there
we
have
the
we
have
the
framework
set
up
to
install
that
gateway
and
the
1.2
release
that's
coming
up
next
week,
you'll
be
able
to
actually
install
the
gateway
as
part
of
the
control
setup
process.
In
this
case
we're
just
going
to
apply
the
ammo
as
normal
folks.
A
A
Again
there
we
go
back
in
the
game,
so
let's
talk
about
a
little
little
terminology,
real,
quick,
there's,
a
couple
of
terms
that
we've
thrown
out
here
that
I
haven't
taken
the
time
to
step
back
and
define
yet.
We've
talked
about
gateways,
we've
talked
about
ingress
and
we've
obviously
covered
data
planes
control
planes.
I
feel
like
we
have
a
pretty
good
understanding
of
that.
A
If
not,
please
drop
a
comment
in
the
chat
so
that
I
can
stop
everything
and
we
can
go
back
and
talk
through
that,
because
it's
really
important
to
understand
control,
plane
and
data
plane
as
we
get
into
do.
Making
a
mesh
a
gateway
is
an
inbound
way
to
get
into
service
mesh.
Often
probably
the
most
popular
question
I
get
about
service
mesh
is:
do
I
need
to
spend
time
working
on
a
gateway
first
or
a
service
mesh
first.
The
truth
is
these
are
two
pages
of
of
the
same
story,
but
they
are
different
pages.
A
The
ingress
gateway
and
really
gateways
in
general.
Give
you
a
point
of
user
or
service
entrance
into
an
environment
in
the
kong
world.
Our
our
big
thing
is
the
plug-in
functionality
that
we
add
on
top
of
the
gateway,
so
we
have
this
rich
plug-in
market
space
and
all
of
these
different
plug-ins
that
let
you
change
the
way
that
inbound
traffic
happens.
So
we
add
on
things
like
opa
integration,
so
open
policy
agent.
So
if
you
want
to
control
a
little
bit
more
fine-grained
how
users
come
in,
we
have
rate
limiting
plugins.
A
We
have
oidc
plugins.
We
have
all
of
these
plugins
that
modify
the
way
user
traffic
comes
in
or
impact
it
in
some
way.
Service
mesh
is
all
about
service
to
service
communication.
How
do
I
make
my
services
communicate
with
each
other
in
the
most
optimal
way,
while
adding
the
most
functionality?
On
top
of
that
without
having
to
change
my
application
code,
because.
A
You
should
be
able
to
consume
a
service
mesh
without
ever
changing
your
app
code.
Your
app
code
should
be
able
to
just
be
loaded
into
a
mesh
and
have
that
communication
happen
and
you're
just
getting
better
things
out
of
it,
because
of
that
mesh,
the
gateway
gives
you
an
entry
into
the
mesh.
So
when
we
talk
about
service
mesh
specifically
and
in
kuma,
we
have
this
concept
of
a
gateway.
A
A
What
that
ends
up
doing
is
disabling
the
external
envoy
listener
because
remember
what
I
said
earlier
about
the
sidecar.
Is
it
intercepts
inbound
and
outbound
communication
that
sidecar
becomes
the
thing
that
handles
all
communication,
so
in
the
case
of
a
gateway
service,
it
said
envoy
on
the
edge,
allow
this
traffic
in
and
you
only
send
traffic
out
through
envoy.
Now
this
is
important
when
we
turn
on
mtls
later
on,
when
we
turn
on
encryption,
because
if
you
have
a
game,
no,
if
gateway
mode
is
not
present
and
you
try
to
access
a
service.
A
That
is
a
service
mesh
service.
You
won't
have
a
cert
in
front
of
it
and
it
won't.
Let
you
connect
kong's
ingress
controller
automatically.
Has
that
annotation
applied
so
by
default,
the
ingress
controller
is
registered
as
a
gateway
to
the
environment,
so
it's
able
to
be
accessed
externally
ingress.
On
the
other
hand,
inside
of
kuma-
and
this
is
where
things
get
a
little
bit
confusing
ingress
inside
of
kubernetes-
is
what
we're
used
to
applying
a
crd
and
getting
a
path
inbound.
A
So
an
ingress
resource
is
applied
to
an
ingress
controller
that
gives
you
that
access
inbound
in
kong
we
consider
ingress
as
a
point
of
getting
into
the
mesh.
So
when
we
deploy
a
multi-zone
kuma
environment,
we
can
deploy
ingresses
as
well.
Those
ingresses
live
alongside
that
mesh
environment
and
provide
an
entry
point
to
resources
that
live
inside
of
that
mesh
because
we're
not
multi-zone
we're
not
deploying
ingress.
So
we
don't
have
to
worry
about
it
in
this
case.
That'll
come
up
later,
but
you
can
see
we've
separated
out
gateways
as
being
a
different
thing.
A
Another
thing
I
want
to
highlight
real
quick
before
we
jump
back
into
the
application.
You
can
see
all
these
tags
are
applied.
We
use
tags
in
a
really
really
cool
way
inside
of
kuma.
That
lets
you
go
ahead
and
apply
policy
or
configuration
against
those
tags.
So
I
have
this
group
demo
app.
I
can
make
a
traffic
permission
down
here.
A
I
can
make
a
traffic
permission
that
says
anything
that
has
the
group
demo
app
tag
can
talk
to
each
other,
but
nothing
else
that
lets
me
start
to
apply
that
zero
trust
that
that
zero
trust
security
model
where
we
only
allow
services
we
define
to
talk
to
each
other,
so
tag
functionality
is
super
powerful.
It's
something
that
I
really
love
about
about.
Kuma
note
that
I
have
like
version
one
down
here
for
these
that's
for
when
I
want
to
start
applying
traffic
splitting
policy.
A
So
if
I
want
to
say,
75
percent
of
traffic
goes
to
service
or
version
one,
but
25
goes
to
version
two.
I
can
do
that
so
at
this
point,
I've
got
should
have
a
service
up
for
comp
proxy.
If
I
hit
this
it's
going
to
fail,
why
is
it
going
to
fail?
Because
I
haven't
loaded
any
ingress
resources
into
this?
Yet
so
it
doesn't
know
about
it,
so
we
will
switch
back
into
our
stuff.
Here,
I'm
going
to
go
into
my
camel's
folder.
I
have
this
yaml
file
called
an
entry
file.
A
What
this
does
is
create
the
service
inside
of
kubernetes
that
references,
the
dot
mesh
address.
What
I
why
I'm
doing
this
is,
I
want
to
send
inbound
traffic
into
the
service
mesh
and
by
using
the
dot
mesh
address.
It
will
send
that,
through
through
the
service
mesh
envoy
instance
and
land
it
inside
of
the
service
mesh.
So
I
want
that
kong,
proxy,
the
kong
ingress
controller
kong
gateway
to
send
that
traffic
into
my
service
mesh
and
consume
it
over
the
service
mesh.
A
Now,
if
I
do
get
services
again
we'll
see,
I
have
a
external
name
service
here.
That
is
pointed
at
the
front.
End
service
front,
end
being
the
service
name,
as
you
can
see
down
here,
kong
being
the
namespace
which
you
can
see
here,
svc
being
a
service
which
we
can
see
as
part
of
cube
control,
get
service
the
port
it's
running
on
and
dot
mesh.
So
we
know
it's
going
into
the
mesh
address.
A
Now,
when
I
run
this
again,
we
get
into
our
environment,
so
we're
getting
about
10
minutes
out
from
the
end
from
the
end
of
this
stream
and
we're
on
pretty
good
track
here.
What
I
want
to
do
is
guitar
under
michael.
If
you
can
grab
this
address,
I
will
drop
it
into
a
chat
somewhere.
What
I'll
do
is
I'll
make
this
really
confusing
and
jump
in
here.
B
A
All
right,
turner,
michael
that's
in
our
private
chat.
You
should
be
able
to
see
that
on
on
our
private
chat,
to
copy
in
drop
that
in
in
a
way
that
they
can
click
on
it
or
feel
free
to
even
share
it
on
twitter.
We
can,
we
can
have
people
accessing
the
service,
and
hopefully
they
don't
crash
in
the
next
few
minutes.
A
What
this
application
is
doing
right
now
is
it's
reaching
out
to
the
different
services
and
ensuring
they're
up.
That's
why
they're
green
and
I've
configured
this
application
to?
Let
me
have
visibility
into
envoy.
So
when
I
come
into
that
front-end
service-
and
I
look
at
the
envoy
clusters
view-
this
is
all
of
the
things
that
envoy
is
getting
that
tell
envoy
what
what
addresses
it
can
communicate
with
so
in
this
environment.
The
database
service
is
reachable
on
this
address
on
port
5432..
This
is
the
if
you
use
the
analogy
of
a
brain.
A
If
envoy's
the
brain,
these
are
the
neural
pathways
that
data
is
going
to
travel
to
to
get
to
a
thing.
So
we
can
see
the
database,
we
can
see
scrolling
down,
we
can
see
post
service
and
the
address
of
the
post
service
in
the
cluster.
We
can
see
the
front
end
service
and
we
can
see
the
user
service
and
redis
is
in
there
somewhere
as
well.
A
A
So
we
can
see
those
configurations.
We
can
see
the
circ
configurations
as
well,
so
those
are
the
configurations
for
communicating
this
environment.
So
let's
kick
this
into
gear
and
start
playing
a
little
bit
with
actually
making
some
requests
to
this
environment.
I
am
not
going
to
give
everybody
the
logon
password
to
this.
A
If
you
guessed
it,
it
would
be
really
fun.
If
you
went
on
twitter,
I
don't
think
it's
that
hard
to
guess
so
have
some
fun
with
it?
If
you
can,
we
can
come
in
here.
We
can
post
a
message
that
gets
submitted,
so
those
are
going
on
cool.
This
is
a
functional
application.
All
of
this
communication
that
message,
I'm
sending
everything-
is
happening
over
over
the
service
mesh
at
this
point.
So
if
I
dropped
in
a
every
time
this
request
goes
through.
It's
hitting
the
local
envoy.
A
An
envoy
is
saying:
hey,
what's
the
best
path
to
get
to
this,
I
can
start
to
modify
this
functionality
and
add
on
the
traffic
splitting.
So
if
I
had
another
another
another
version
of
the
api
layer
that
on
and
start
to
send
traffic
there
as
well,
but
right
now,
everything
is
going
through
that
that
actual
envoy
service.
A
So
if
I
go
into
insomnia
just
for
funds
and
grins
and
giggles
grab,
this
address
I'm
going
to
switch
back
to
insomnia.
This
is
a
set
of
apis
that
I've
written
for
that
actual
demo
application.
Oh
there's
the
password.
So
if
anybody
wants
to
go
and
have
fun,
you
can
bypass
the
whole
thing
and
actually
just
go
into
there
and
do
things
now
be
interesting
to
see
what
sort
of
messages
we
get
I
can
go
in?
I
can
create
a
user,
so
I'm
gonna
go
into
here.
I'm
gonna
change!
A
Now,
let's,
let's
as
our
as
we're
starting
to
wrap
up,
let's
do
something:
that's
going
to
break
part
of
the
environment
for
a
for
a
quick
second
here
and
start
to
see
kind
of
the
foundations
of
how
we
make
this
stuff
better.
So
this
is
right.
Now,
if
I
was
watching
the
stream,
my
response
would
be
well.
I
have
you
haven't
done
much
all
you've
shown
me
is
that
you
can
continue
to
connect
an
environment
together,
which
is
true.
A
B
A
A
A
A
Out
of
the
box
now
from
day
one
we
now
have
mtls
enabled
in
the
environment,
so
all
of
those
services
are
automatically
going
to
encrypt
the
traffic
between
them,
so
no
one
can
sniff
that
traffic.
Now
this
applies
to
multi-zone
as
well.
So
if
I
was
not
running
standalone,
if
I
had
this
stretching
like,
I
talked
about
earlier
between
a
vsphere
environment,
a
kubernete
or
a
gke
eks
and
aks
environment,
so
google,
amazon
and
azure,
I
think
I've
added
backwards.
A
All
of
that
traffic
would
be
encrypted
into
in
now,
because
I've
turned
on
mtls.
I've
also
turned
on
prometheus,
so
it's
sending
traffic
out
or
sending
metrics
into
into
prometheus,
or
it's
trying
to
right
now.
It
can't
because
I
haven't,
I
haven't,
deployed
out
the
metrics
install,
yet
it's
also
sending
jaeger
stuff,
but
it
can't
because
I
haven't
turned
that
on
either.
A
A
A
B
B
A
A
Because
I
deleted
the
other,
the
traffic
permission
before
I
accidentally
deleted
the
entire
crd,
so
I
just
need
to
bring
the
crd
back
on
the
next
stream
when
we
will
be
able
to
actually
apply
the
traffic
permission
policies
right
now.
There
is
no
traffic
commission
policies,
so
I
can't
apply
the
thing
to
allow
it
anymore.
So,
on
our
next
journey
together
we
will
start
to
re-unpack
bringing
that
back
in.
A
So
the
upstream
can't
communicate
right
now,
because
we've
deleted
the
traffic
permission
policy,
so
that
was
our
opening
stream
ending
at
india
at
12
o'clock.
In
this
stream
we
went
through
and
set
up
kuma
from
the
ground
up.
We
brought
in
our
application
to
it.
We
talked
about
side
cars.
What
they
are.
We
talked
about
control
plane
versus
data
plane.
A
We
talked
about
what
happens
when
you
deploy
an
application,
how
to
set
up
sidecar
injection.
We
showed
deleting
accidentally
the
entire
traffic
permission
policy,
but
we
showed
how
we
can
start
to
enable
xero
trust.
In
that
way
we
talked
about
gateways
and
how
gateways
work
inside
of
an
environment.
We
also
enabled
mtls.
So
we
got
encryption
out
of
the
box.
All
inside
of
really
about
half
an
hour
since
we
I
spent
about
30
minutes
of
it
of
it
rambling.
A
B
A
You
enjoyed
this.
This
was
a
ton
of
fun
for
me
in
the
future,
we'll
start
building
an
application
from
the
ground
up,
so
we'll
actually
spin
up
something
in
react:
spin
up
something
in
python,
probably
as
an
api,
we'll
connect
those
together
and
we'll
start
building
our
own
application
and
start
bringing
in
service
mesh
policies
as
we
build
that
out.
A
A
It's
going
to
be
a
really
cool
one.
There's
some
really
cool
functionality
that
we're
adding
in
1.2,
specifically
some
things
around
traffic
permissions,
the
gateway
stuff.
I'm
really
excited
to
show
that
we're
going
to
do
a
live
stream
showing
us
actually
using
that
stuff
in
it,
and
probably
this
application
as
well
so
tune
in
next
week.
Again,
thank
you
to
tara
and
michael
for
helping
me
out
thanks
for
victor
for
for
being
out
in
the
audience
as
well,
and
thanks
for
everybody
who
joined,
tell
your
friends
subscribe
on
youtube.