►
From YouTube: Keynote: Deploying an Envoy-Based Service Mesh in Minutes Across Kubernetes and VMs- Marco Palladino
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Keynote: Deploying an Envoy-Based Service Mesh in Minutes Across Kubernetes and VMs- Marco Palladino, Co-Founder & CTO, Kong
Deploying a service mesh has traditionally been a complex task, and distributed environments across multiple clusters and clouds can make things even more challenging. But, it doesn’t have to be that way!
In this session, we are going to fire up the terminal and install CNCF’s Kuma across multiple Kubernetes clusters and virtual machines. In just 10 minutes, we will be up and running with a modern Envoy-based service mesh to power both modern and legacy applications for our teams.
A
A
A
In
my
role
at
kong,
I
spend
lots
of
time
trying
to
educate
organizations
into
what
service
mesh
is
and
why
they
need
it.
I
think
that
the
educational
component-
it's
something
that
has
been
missing
generally
speaking
and
some
folks,
are
really
not
understanding
why
we
need
a
service
mesh
reality
is
service.
Mesh
is
inevitable.
A
Whenever
an
application
team
does
anything,
that's
decoupled
and
decentralized,
and
it
goes
over
the
network-
well,
the
network,
by
default,
it's
not
secure,
it's
not
reliable,
it's
not
observable,
and
we
have
to
build
something
that
allows
us
to
get
all
of
these
features
on
top
of
the
network.
So
there's
only
two
options:
either
we
build
it
in
every
single
service
that
the
teams
are
creating,
or
we
provide
all
of
these
capabilities
in
the
infrastructure
level.
A
The
question
is
how
we
build
it,
but
there
is
no
question
about
having
to
build
it
right,
and
this
is
one
of
the
biggest
things
that
I'm
trying
to
explain
to
leaders
and
technology
leaders
in
the
organizations
that
I
work
with.
It
has
to
be
built,
no
matter
what
and
the
fun
part
about
service
mention
the
fun
part
about
our
decentralization
journey.
A
A
This
is
the
time
for
us
to
think
about
what
service
mesh
technologies
we
want
to
adopt
to
rethink
the
decisions
we
made
before
to
make
sure
that
we
have
the
right
infrastructure
in
place
to
support
our
teams,
no
matter
if
they're
working
on
containers,
kubernetes
or
virtual
machines
or
this
cloud
or
that
cloud.
This
infrastructural
component
has
to
be
ubiquitous
across
all
the
platforms
that
our
teams
are
using.
A
So,
in
order
to
understand
the
work
that
we've
been
doing
with
cuma,
we
really
have
to
take
a
step
back
and
look
at
the
evolution
of
service
mesh
throughout
the
years
service
mesh.
It's
a
new
pattern
came
out
in
2017,
first
service
mesh
projects
back
in
those
days,
they
were
quite
experimental.
You
know
some
of
them
were
jvm
based.
Some
of
them
had
architectural
decisions
that
made
the
product
very
hard
to
deploy
to
scale
to
upgrade.
It
was
the
early
days
as
we
know,
of
service
mesh,
but
then
service
meshes
got
very
well.
A
We
want
to
make
sure
that
we
can
accelerate
the
efficiency,
the
performance
of
the
application
teams
by
providing
a
service
mesh
to
them
on
demand.
Whenever
they
need
it-
and
this
is
why
the
evolution
of
service
mesh
really
goes
above
and
beyond
the
single
application
and
really
spans
across
all
the
applications
that
the
teams
are
creating
and
some
of
these
applications
are
going
to
be
created
on
kubernetes.
A
And-
and
this
really
is
the
reason
why
we
created
huma
kuma-
is
a
service
mesh
that
it's
a
cncf
sandbox
project,
we're
going
to
be
starting
the
incubation
process
quite
soon,
it's
built
on
top
of
envoy
proxy
envoy.
It's
the
data
plane
proxy
technology
that,
at
the
end
of
the
day,
it
is
going
to
be
managing
all
the
requests
across
all
the
services
that
we
have.
But
then,
on
top
of
this,
we've
built
our
global
and
zone
control.
A
Plane
separation,
which
allows
us
to
essentially
deploy
a
global
primary
control
plane
and
a
secondary
zone
control
plane
for
each
cluster.
Each
cloud
each
environment
can
be
containers
can
be
vms.
It
can
be
a
mix
and
match
of
both
across
the
organization
whenever
there
is
a
new
change
within
the
system.
That
change
goes
through
the
primary
global
control
plane
and
the
control
plane
automatically
synchronizes
and
propagates
that
configuration
across
the
board.
A
By
doing
so,
we
have
access
to
cross
zone
discovery,
cross
zone
connectivity.
As
a
matter
of
fact,
we
can
also
connect
virtual
machines
and
container
based
applications
and
services
transparently
by
creating
this
abstraction
layer
that
can
span
across
multiple
clusters
and
multiple
zones.
This
is
native
into
the
product.
It's
not
an
afterthought.
The
product
has
been
built
in
such
a
way
that
it
can
be
deployed
across
multiple
zones.
A
On
top
of
that,
we
have
added
one
of
the
lessons
that
we
learned
with
kong
gateway.
The
concept
of
konge2
is
the
concept
of
plugins
and
kuma
has
the
concept
of
policies.
We
want
to
make
sure
that
we
can
deploy
the
service
mesh,
but
then
we
also
want
to
provide
an
easy
way
for
the
teams
to
wrap
their
head
around
all
the
features
and
functions
that
they
want
to
apply
in
a
service
mesh
things
like
circuit
breakers
or
traffic,
routing
or
observability
and
metrics
and
tracing,
and
so
we
created
this
concept.
A
Finally,
this
system
is
built
with
an
abstraction
that
supports
natively,
virtual
machines
and
containers.
As
a
matter
of
fact,
it's
not
only
kubernetes,
it's
any
containerized
based
system.
It
can
be
a
ws,
far
gate,
it
can
be
ecs
virtual
machines
are,
and
the
support
for
virtual
machines
really
is
a
first
class
citizen
support.
As
a
matter
of
fact,
there
is
organizations
that
are
deploying
this
on
virtual
machines
only
with
no
kubernetes
whatsoever.
A
As
a
matter
of
fact,
we
made
more
than
40
plus
releases
in
the
last
12
months
of
cuma,
the
momentum
of
the
project.
It
is
quite
active
and
that's
the
way
we
want
to
do
it.
We
want
to
keep
shipping
new
features,
new
releases
performance
improvements.
Every
time
we
have
them,
I'm
a
big
believer
that
building
something
and
not
shipping
it.
It's
essentially
holding
back
value
to
the
community,
and
so,
whenever
we
think
timing
is
right,
we'll
make
a
release
and
across
the
board
in
the
past
12
months.
A
Things
like
fips
encryption
things
like
policies
for
health
checks
and
circuit,
breaking,
and
traffic
routing,
and
monitoring,
there's
15,
15,
plus
policies
that
are
available
to
the
teams
to
get
up
and
running
today
with
service
mesh,
as
well
as
automatic
propagation
and
synchronization
of
tls
identities
across
multiple
zones,
including
a
hybrid
of
vms
and
container
zones.
Again,
the
goal
for
this
project:
it
is
to
support
the
entire
org,
which
means
containerized,
kubernetes
workloads,
as
well
as
virtual
machines.
A
Why
not
service
map
out
of
the
box
which
ships,
in
addition
to
the
70
plus
charts
that
qmap
provides
out
of
the
box
on
top
of
prometheus
and
grafana,
as
well
as
improvements
in
the
performance
of
the
system?
So
we
shipped
just
last
month
performance
improvements
that
double
essentially
this.
The
number
of
data
plane
proxies
that
can
connect
to
the
control
plane
in
an
efficient
manner
performance.
Obviously
matters
in
my
role
as
the
city
of
cong.
A
I
spend
lots
of
time
not
only
talking
about
the
technology
itself,
but
trying
to
provide
the
right
guidelines
and
materials
for
the
decision
makers
in
the
organization
to
understand
the
value
of
a
service
mesh
and
nothing
better
than
looking
at
the
use.
Cases
of
service
mesh
can
explain
that
with
a
service
mesh,
we
can
implement
zero
trust
security
without
having
to
ask
the
teams
to
build
it,
of
course,
and
everything
is
being
automatically
propagated
and
issued
by
the
service
mesh
itself.
The
entire
life
cycle
of
issuing
identities,
rotating
those
certificates
decommissioning.
A
Those
certificates,
all
of
that
it's
fully
automated
the
teams,
don't
have
to
build
it
as
well
as,
of
course,
observability
being
able
to
understand
out
of
the
box,
and
this
is
something
that
teams
love,
because
they
can
get
immediate
value
out
of
everything
that
they're
building
80
70,
plus
charts,
plus
a
service
map
to
determine
what
is
the
performance
of
their
services,
how
they
are
related
to
each
other.
What
service
consumes
what
other
service,
and
so
they
can
understand
the
topology
as
well
as
load
balancing.
Actually,
this
is
an
interesting
one.
A
This
is
something
that
it
wasn't
obvious
at
first,
but
it
creates
an
immense
value
in
the
organization.
What
we
think
of
load,
balancing
load,
balancing
for
the
most
part
hasn't
changed,
centralized
load
balancing
is
a
remnant
of
legacy,
monolithic,
architectures
and
way
of
doing
things
that
doesn't
have
a
place
in
a
decentralized
containerized
environment
organizations
are
using
centralized
load,
balancers
or
elastic
load
balancers
in
the
cloud
in
front
of
every
service
that
they
are
shipping
that
the
teams
are
creating,
but
centralized
load,
balancers,
guess
what
it's
an
extra
hop
in
the
network,
they
add
latency.
A
They
are
not
efficient,
they're,
slow
and
they're,
not
portable,
especially
when
running
in
a
multi-cloud
environment.
So
service
mesh
can
be
used
to
implement
client-side
load
balancing
in
such
a
way
that
we
can
get
rid
of
those
either
enterprise
load,
balancers
or
cloud
load
balancers.
As
a
matter
of
fact,
I
was
speaking
with
a
cto
customer
of
cong.
They
were
able
to
get
rid
of
the
16
000
elastic
load,
balancers
on
aws
in
front
of
every
service,
while
at
the
same
time
being
able
to
save
seven
figures
on
those
load.
A
And
so
we're
working
towards
schema
2.0.
We
welcome
the
community
to
contribute
in
our
community
channels
into
the
definition
of
what
cuba
2.0
really
is.
One
of
the
things
that
we're
working
on
is
a
new
spec
for
selecting
policies
and
sources
and
destinations
across
our
services.
So,
if
you're
familiar
with
you
know,
this
is
the
chance
to
give
your
input
into
defining
what
comma
2.0
really
is
on
queue,
moderator
community
but
then,
and
I'm
going
to
wrap
this
up.
A
The
last
thing
I
want
to
talk
about
is
being
able
to
expose
the
services
from
a
service
mesh,
exposing
a
service
from
a
service
mesh.
It's
not
only
a
load,
balancer
concern.
It's
not
only
an
identity
concern.
We
want
to
apply
governance
on
how
we
want
to
expose
our
services
to
the
outside
world
and
to
do
that,
we
want
to
make
sure
that
we
have
an
api
gateway
that
allows
us
to
manage
the
consumers,
the
clients,
the
applications
and
being
able
to
govern
each
one
of
them
in
a
different
way.