►
From YouTube: From Gateway to Mesh: Embracing Full Stack Connectivity
Description
Learn how to:
- Deliver turnkey API Management and Service Mesh across all your clouds
- Manage services natively in Kubernetes and run across any protocol and architecture
- Manage all your services end-to-end from design to production, using declarative configuration for DevOps automation
- Integrate Kong Mesh into the Kong Enterprise platform to enable ingress and egress traffic for your service mesh
A
A
Let
me
talk
a
little
bit
about
an
analogy
that
I
found
very
useful
understanding
the
concept
and
also
present
that,
in
the
context
of
some
of
the
types
of
connectivity
challenges
that
we've
been
talking
about
throughout
this
summit,
so
this
building
is
very
familiar
to
congress
employees,
it's
the
headquarter
that
we
have
here
in
san
francisco
and
that
before
the
whole
kobe
time
we
all
used
to
go
to
the
ones.
You
know
one
of
us
who
were
in
the
city,
so
why
am
I
showing
you
the
building?
A
Well,
because
there
is
some
interesting
things
around
how
a
building
is
secured
and
entry
to
it
is
authenticated
and
authorized
and
logged
that
map
well
to
how
we
do
this
for
connectivity
as
well.
So
when
I
enter
the
building,
this
is
what
I
see
first,
and
this
is
where
visitors
are
authenticated,
authorized
and
logged
as
they
enter.
This
is
very
much
akin
to
a
gateway.
This
is
the
edge
type
of
connectivity
we're
entering
and
we
need
to
have
this
type
of
information
captured
for
us
so
that
the
building
is
secure.
A
Now,
if
you
go
to
the
kong
office,
you
will
see
a
another
gateway,
another
sorry,
another
front
desk.
That
is
where
you
get
again
authorized
logged
and
authenticated
to
enter
the
offices
within
that
building.
So
this
is
akin
to
the
interaction
between
applications
and
how
they
need
to
be
secured
right.
A
So
if
I
am
in
the
content
floor
and
I
go
to
another
floor,
I
need
to
be
getting
authenticated
again
by
that
other
company,
although
it's
within
the
context
of
the
building,
I've
already
gone
through
the
edge
gateway,
but
when
I'm
inside
the
building-
and
I
go
between
different
parts
of
the
building,
I
can
use
my
batch
and
I've
been
issued
this
badge
by
kong
and
I
don't
have
to
go
through
a
gateway
or
a
front
desk.
I
should
say
anymore
right.
A
The
card
allows
me
to
do
that,
and
this
is
kind
of
like
the
mtls
certificate,
that's
being
validated
by
the
service
mesh
and
the
internal
inside
the
app
service
to
service
type
of
connectivity
right.
So
we
have
really
three
types
of
connectivity
involved
in
this
interaction
edge,
which
is
the
end
gateway
cross
app,
which
is
between
floors.
A
In
my
analogy
and
in
app,
which
is
the
card
view,
and
then
there
is
different
types
of
architectures
involved
that
that
we
we
can
support
this
connectivity
on
and
what
really
and,
of
course,
there's
there's
all
the
different
platforms
that
we
support
and
what
we
believe
here
at
kong
is
that
you
just
need
the
right
type
of
connectivity
runtime
for
each
of
these
different
interactions.
So
you
need
gateways
at
the
edge
and
between
applications,
and
you
need
a
mesh
for
in-app
connectivity
and
they
really
can
exist
in
harmony.
A
So
without
further
ado,
let
me
pass
it
on
to
nikolai
to
show
some
of
how
this
interaction
happens
between
the
clone
gateway
and
the
cone
mesh
to
enable
this
type
of
connectivity
within
within
an
application
setting
or
a
multi-app
setting
leveraging
leveraging
those
two
runtimes
with
that.
Let
me
pass
it
on
to
nikolai
it's
all.
Yours.
B
B
This
whole
setup
can
be,
can
be
done
in
the
very
other
in
the
various
other
scenarios
that
cog
mesh
can
be
applied,
and
there
are
other
sessions
where
we
discuss
hybrid
deployments,
multi-cluster
deployments,
but
in
this
one
we
are
focusing
on
a
standalone,
kung
mesh
deployment
in
a
single
cluster.
So
what
we're
going
to
show
is
how
how
these
two
technologies
complement
each
other.
B
For
this
we're
going
to
use
a
simple
shopping
application
or
the
marketplace
application
that
we
have
as
as
part
of
our
development
process,
kong
mesh
is
based
on
and
we
call
this
application.
The
kuma
demo
it
effectively
is
a
four
services
application.
We
have
the
front
end
the
back
end
and
a
couple
of
databases
for
our
needs.
B
When
we
want
to
extend
the
capabilities
of
the
mesh
behind
the
basics
and
what
gave
it
analogy
like
the
mtls
or
inter
service,
encryption
and
authentication
kong
mesh,
as
this
is
typical
for
service
meshes,
is
providing
other
facilities
other
tools,
namely
tracing
and
metrics.
So
here
we
see
the
three
famous
logos,
jaeger,
prometheus
and
grafana.
So
this
is
the
these.
Are
the
tools
that
help
and
are
being
deployed
on
top
of
kong
mesh
in
a
way
that
that
that
they
give
this
visibility
and
observability
within
what's
happening
in
the
mesh.
B
So
for
this
demo
I
have
prepared
a
single
google
cloud
cluster
in
the
gke
on
and
also
I
have
a
number
of
steps
in
forms
of
scripts
that
I
have
prepared.
I'm
not
going
to
run
the
scripts
I'm
going
to
go
through
to
them
and
copy
and
execute
each
of
the
the
comments.
So
the
first
comment
and
all
these
are
effectively
taken
and
slightly
modified
from
the
official
docs
for
kung
mesh
and
conch
ingress.
B
B
B
B
Foreign,
so
that
we
secure
all
the
communications
in
the
mess
and
also
a
traffic
permission
which
will
ensure
that
all
the
services
can
communicate
between
each
other.
So
I'm
taking
out
this
and
posting
it
pasting
it
here
on
the
on
the
console
and
we
are
going
to
see
how
all
the
the
four
services
are
getting
deployed
within
the
mesh.
B
While
this
happens,
let's,
let's
look
at
what
are
the
next
steps,
so
the
next
steps
are
to
actually
deploy
conquingers.
So
this
phase
can
consist
of
two
two
sub
sub
phases
or
two
sub
steps.
The
first
one
is
to
actually
deploy
the
the
conkingers
command
again.
This
is
a
standard
command,
it's
available
in
the
docs
and
the
next
one
is
to
make
it
part
of
the
mesh.
B
So
if
I
have
to,
if
I
can
refer
back
to
this
architecture,
essentially
we
first
deploy
it,
and
then
we
deploy
the
site
card
container,
make
sure
that
the
sidecar
container
is
deployed
alongside
it.
So
for
this
I'm
going
to
start
the
deployment,
so
we
see
confirmation
demo
are
already
deployed
the
last
resource
here,
I'm
deploying
conc
ingress
now.
B
B
So
after
the
pot
finishing
it's
in
its
initialization,
we
are
going
to
have
of
the
full
featured
application
architecture
as
we
as
we
describe
it
now.
The
next
steps
are
effectively
configuring,
both
congression
conquingress,
to
do
whatever
we
we
want
to
do,
namely
to
expose
certain
endpoints
and
to
do
some
advanced
authentication
and
traffic
limiting,
etc.
B
So
the
first
thing
is
to
expose
to
to
increases,
so
these
are
standard,
kubernetes,
ingress
resources
that
are
going
to
be
picked
up
by
kong
and
are
going
to
result
in
exposing
certain
endpoints
so
effectively.
These
two
are
the
kong
mesh
gui
and
the
marketplace
application
front
end
itself.
So
when
I
apply
this.
B
And
see
what
is
the
external
ip
that
conc
ingress
is
exposing
in
in
a
normal
situation.
These
two,
this
will
end
up.
You
know
you
know
dns
record
in
your
dns
server,
because
I
don't
have
a
dns
server
prepared
for
this
demo.
I'm
going
to
use
my
local
hosts
file
to
actually
put
this
record
and
make
sure
that
all
these
names
where
I'm
going
to
access
my
services
are
resolvable.
B
B
B
The
next
thing
that
we
should
be
able
to
see
is
the
marketplace
application.
Here
it
is,
as
we
said,
it's
a
fairly
simple
application.
You
can
go
and
search.
For
example,
I
think
that
there
was
cap
shirt,
you
can
do
some
searches
or
you
can
go
browse,
etc.
So
this
is
this
is
the
the
first
phase.
So
now
now
we
have
a
basic
basic
service
explosion
through
conking
chrome
congress.
B
B
B
B
So
as
a
result
of
this,
when
I
try
to
login
I'm
going
to
get
a
login
window,
so
I
cannot,
I
cannot
access
it
anymore.
It's
it's
publicly
available
like
to
internet,
but
once
you
get
here,
you
have
to
actually
provide
your
credentials,
so
the
credentials
are
very
simple:
username,
username1
and
password1.
B
The
next
thing
that
we
want
to
do
is
enable
the
rate
limiter.
So
the
rate
emitter
is
is
fairly
simple,
again
plugin,
I'm
just
just
going
to
add
this
resource
here
and
in
order
to
demonstrate
the
rate
limiter
because
effectively
the
the
limiting
that
we
have
set
is
we
have
50
requests
per
minute,
meaning
that
if
I
refresh
each
and
every
second
I'm
going
to
be
able
to
pass
only
50
requests
and
10
are
going
to
be
dropped.
So
for
this
I
have
a
simple
plugin
here.
B
Obviously,
so
we
have
api
rate
limit
exceeded
and
once
the
minute
passes
it
is
going
to
retry
again,
then
there
are
two
two
more
steps
that
we
we
want
to
apply
as,
as
was
described
in
the
architecture
we
have
metrics
and
tracing.
These
are
a
little
bit
more
complex,
because
actually
you
can
first,
we
have
to
deploy
the
metrics
which
are
available
with
kung
mesh.
I'm
going
to
do
this
now
because
it
takes
some
time.
B
It
starts
creating
various
resources,
it's
going
to
start
spawning
services
soon,
and
we
also
have
to
enable
the
the
metrics
within
the
mesh
and
also
we
have
to
configure
a
conc
ingress,
because
what
we
want
to
do
is
we
want
to
be
able
to
see
metrics
from
both
the
conk
ingress
and
also
the
machine
we're
going
to
see
them
on.
On
the
same
on
the
same
dashboard
like
on
the
same
grafana
instance.
B
That's
that's
actually
the
beauty
of
it,
because
both
both
solutions
are
complementing
each
other
in
a
way
that
actually
they're,
exposing
both
the
metrics
and
the
tracing.
As
we'll
see
later,
everything
is
seen
in
in
the
unified,
the
dashboards
and
the
the
tooling
that
are
provided
within
kong
mesh.
B
B
B
B
B
B
B
We
have
the
standard,
comma
data
plane
dashboards.
Let's
just
do
the
last
one
hour
for
the
last
five
minutes:
15
minutes,
okay,
so
some
traffic
is
passing.
We
can
see
some
statistics.
This
is,
let's
see,
comment
them
up.
Okay,
what?
What?
Actually
we
can
do
we?
So
we
can
also
import-
and
I
think
it
was
7422.
B
B
You
know
some
value
here
because,
as
you
can
see
kongero
it
continues
to
retry
and
generate
traffic
for
us
so
that
we
can
see
statistics.
There
are
some
other
things
there
in
the
so
in
the
congo
official.
I
think
that
there
was
something
interesting.
Okay,
so
nginx
we
can
see
some
some
insights
about,
nginx,
total
connections,
handled
connections
etc,
and
last
thing
that
we
we
want
to
to
finalize
with
this
is
the
tracing.
So
tracing
is
in
form
of
a
jager
instance.
B
B
Okay,
create
a
traffic
trace,
a
resource
to
actually
allow
it
for,
for
each
and
every
service,
that's
available
out
there
and
then
again
the
more
complex
config
that
comes
with
it's
not
complex.
It's
it's!
It's
just
two
things.
We
are
exposing
the
tracing
host
so
that
we
can
access
it
from
outside
of
the
mesh,
and
there
is
also
the
conch
plugin
for
zipkin
that
we
are
going
to
use.
B
Okay,
so
we
already
see
that
we
see
all
the
traces
starting
from
conch
itself
through
conc
cong
proxy,
then
the
front
end
the
back
end
and
that's
where
it
ends.
If
we
click
here
on
the
system
architecture
we're
going
to
see,
so
this
is
kind
of
the
graph
of
the
services
if
we
click
on
a
particular
trace
here,
for
example,
so
this
one
this
one
has
failed.
This
probably
is
has
been
already,
but
these
are
non.
No,
not,
let's
find
some
some
more
traces.
B
A
Okay,
thank
you.
So
thank
you.
This
is
a
really
cool
demo
to
see
to
see
those
dot
run
times,
work
together
and
to
help
us
achieve
both
the
the
the
connectivity
at
the
edge,
as
well
as
within
the
app
now
all
this
comes
together
in
the
context
of
our
platform
connect
around
the
runtimes.
What
you
saw
there
was
conc
ingress
and
kong
mesh.
A
We
have
insomnia
integration
into
into
connect.
So
hopefully
you
find
you
found
today's
session
interactive,
nikolai!
Thank
you
very
much.
You
did
all
the
hard
work
here
so
really
appreciate
it,
and
I
want
to
make
sure
there's
time
for
questions
as
well.
So
if
there's
questions,
please
type
them
up
right
now
and
we
will
be
doing
our
best
to
answer
them.
Thank
you
very.