►
From YouTube: Intro to Service Mesh & Istio
Description
SoloCon 2022:
Intro to Service Mesh and Istio
Speakers:
Kamesh Sampath
Field Engineer- APAC, Solo.io
Rinor Maloku
Field Engineer- EMEA, Solo.io
Session Abstract:
The next generation of microservices leverage the service mesh pattern to resolve cross-cutting concerns such as: observability, traffic management, and security. In this session, we will show Istio an implementation of a service mesh and how it benefits developers, service operators, and security engineers. We will show how Istio utilizes the capabilities of the Envoy proxy to dynamically configure it according to the desired mesh behavior.
Service Mesh alleviates most common distributed computing pain points like smart routing, traffic splitting, smart canaries etc., In this session, we will explore on how to download, setup Istio on your local laptop, deploy few services as part of the Istio Service Mesh. By virtue of adding a sidecar, the applications will be spiced with ability in splitting traffic between various version of services, smart layer 7 routing, access control etc., “ALL THESE WITHOUT CODE REDEPLOYS”
Track:
Community and Open Source
A
A
B
Hello:
everyone
myself
kamish,
I'm
a
field
engineer
at
solo,
playstation
of
bangalore,
india,
I'm
a
long
time,
open
source
contributor
contributed
to
many
projects
like
tektron
k,
native
mini
cube
and
all
I'm
author
of
gay
native
cookbook
that
I
did
a
year
ago
and
happy
to
share
the
session
with
zuna.
Today,
back
to
you.
A
Tonight,
thanks
so
istio
provides
exciting
capabilities
to
your
apps,
and
it
is
for
this
reason
that
most
presentations
spend
all
of
the
time
in
the
technical
details
which
is
good,
but
in
the
process
we
lose
focus
on
what
really
matters,
and
it
is
the
people
that
benefit
from
the
service
mesh.
That
matter.
This
presentation
brings
the
people
at
the
foreground
and
shows
what
each
role
or
persona
within
a
team
can
gain
out
of
the
service
mesh.
But
to
answer
this,
we
need
to
initially
know
how
we
got
to
service
meshes
camish.
B
Oh
yeah,
so
let's
go
a
bit
behind
right
way
back
to
the
big
name
and
start
with
the
big
bang
theory.
You
know
this
is
not
the
big
bang
that
you
usually
know
about.
This
is
a
big
bang
that
we
went
from
monolithic
to
micro
services.
So
how
do
we
start
breaking
the
applications
into
smaller
pieces?
So
what
gave
with
that
is
that
we
got
a
lot
of
benefits
when
we
actually
moved
from
monolith
to
microservice.
There
were
strong
module
boundaries,
which
means
that
applications
could
be
built
independently
and
deployed
independently.
B
But
the
burn
of
microservice
is
not
all
about
sunshine
and
rainbows
teams
will
quickly
discover
there
are
issues
and
get
confused
with
such
as
where
is
my
service,
failing
which
node
in
the
cloud
myself
is
failing
and
much
even
my
system
is
secure,
etc,
etc.
Renault,
can
you
explain
how
teams
can
handle
this.
A
Oh
yeah,
so
initially
the
team
should
be
aware
that
there
are
trade-offs
when
adopting
microservices,
because
every
strength
has
a
weakness,
and
it
is
no
difference
here.
Henry
james
made
this
lovely
observation
that
applies
about
individuals,
but
it
works
just
as
well
to
systems.
The
observation
is
that
every
strength
that
an
individual
has
in
our
case,
a
system
has
necessarily
brings
with
it
weaknesses
of
which
it
is
an
inherent
part
of
in
the
case
of
microservices
stores.
Inherent
weaknesses
are
operational
complexity
and
the
distributed
computing
nature
of
microservices.
A
Having
many
smaller
services
requires
automation
for
the
operations
of
all
of
those
which
becomes
rather
complex.
The
distributed
nature
of
microservices
brings
with
it
a
host
of
other
issues,
such
as
the
network
not
being
reliable
and
having
observability
over
all
the
services
really
difficult.
Finally,
all
of
the
service
to
service
communication
needs
to
be
secured,
and
that
is
as
well
a
challenge.
The
good
news
is
that
all
of
those
have
solutions-
let's
see
those
so
initially
operational
complexity,
is
more
or
less
a
solved
problem.
A
Docker
makes
it
really
simple
to
package
the
application
and
its
dependencies
into
a
shippable
container.
Then
kubernetes
can
run
this
container
in
any
of
the
nodes
that
are
part
of
the
cluster.
It
manages
as
a
service
operator.
You
don't
have
to
think
about
what
nodes
the
services
are
running
if
those
are
healthy,
if
the
services
are
healthy
kubernetes
does
it
all
for
you.
A
Meanwhile,
the
other
issues
that
crop
up
because
of
the
distributed
nature
of
microservices,
such
as
network
not
being
reliable
and
then
having
latency
and
so
on.
All
of
those
can
be
resolved
with
additional
code,
and,
understandably,
you
need
to
configure
it
as
well
when
a
failure
bubbles
up
to
the
client,
as
indicated
by
the
red
arrow,
it
is
rather
difficult
to
localize,
which
service
calls
the
failure.
A
Security
is
a
rather
difficult
problem
to
solve
static
ips,
which
previously
could
be
used
as
a
means
to
authenticate
that
client
are
not
the
source
of
truth
anymore.
Considering
the
effort
nature
of
workloads
running
in
kubernetes,
many
enterprises
feel
secure
by
simply
allowing
clear
tax
traffic
between
services
and
only
securing
ingress
and
egress
traffic,
but
that
couldn't
be
farther
from
the
truth.
It
is
a
false
sense
of
security,
because
traffic
leaving
one
workload
and
going
to
another
will
go
across
nodes
and
in
between
there
will
be
many
networking
devices
and
all
of
those
represent.
A
A
So,
as
we
see
what
happens
gradually
is
that
by
solving
all
of
these
weaknesses
of
microservice
architectures,
our
services
become
bloated
with
code
that
is
entirely
not
related
to
our
business.
This
makes
our
team
less
productive.
Instead
of
focusing
on
adding
business
differentiating
features,
they
have
to
develop,
maintain
and
configure
all
of
those
libraries
just
to
contain
the
issues
that
crop
up
when
we
adopt
microservices
those
deadlines
are
missed
and
the
project
manager
is
sad
as
well
and
we
quickly
go
from
the
happy
team
to
a
set
team.
A
So
you
all
be
thinking
that
there
must
be
an
effective
solution
to
this
problem,
and
that
is
a
service
mesh.
The
service
mesh
pattern
suggests
that,
instead
of
adding
all
the
code
to
the
services,
what
we
can
do
is
we
can
have
a
sidebar
and
then
just
redirect
all
of
the
traffic
to
the
site
bar
and
let
the
siteboard
handle
that.
A
Understandably,
the
sitecore
must
be
configurable
to
meet
the
needs
of
all
services,
and
for
that
we
have
the
following
split:
we
have
to
split
up
between
the
data
plane
and
the
control
plane.
The
data
plane
is
comprised
of
all
the
services
and
the
sidebars
and
the
control
plane
is
what
reads
the
kubernetes
api
and
learns
about.
The
services
running
in
the
cluster
then
generates
configuration
and
pushes
this
to
the
site
or
process,
and
this
way
we
manage
how
a
service
to
service
communicates.
A
Additionally,
and
what's
what
is
even
more
important,
our
engineers
can
customize
the
configuration
by
using
yaml
resources
and
applying
those
to
the
api
server.
The
event
of
the
resource
that
gets
applied
is
picked
up
by
histod
and
it
is
pushed
to
the
side
course
to
take
a
concrete
example.
The
security
engineer
can
define
a
policy
that
configures
service
b
to
accept
traffic
only
from
service
aid
and
requests
from
any
other
service
are
rejected.
B
B
I
already
have
the
tool
downloaded
onto
my
system
and
let
me
go
check
the
version
of
what
I
have.
I
have
1.12.2
on
my
system
and
as
the
version
command
reports,
I
don't
have
any
sto
parts
running
on
my
kubernetes
cluster.
That's
exactly
what
we
are
going
to
do
next
to
install
istio,
we
need
to
run
istio
ctl
install
command,
I'm
just
going
to
copy
paste
the
command
from
a
clipboard,
and
it
says
istio
install
a
profile,
caller's
demo.
There
are
multiple
profiles
available.
B
You
can
use
them
based
on
your
context
and
I'm
going
to
set
one
value
called
as
global
proxy
privilege
equal
to
true.
Let's
not
worry
about
this
value
for
now
I'll
come
back
to
that
at
later
point
of
the
demo
and
then
once
I
have
this,
so
this
is
going
to
install
it's
going
to
take
few
seconds
for
us
to
get
istio
installed
onto
our
system.
B
And
there
we
go,
our
istio
is
installed
on
our
cluster
and
we
are
good
to
get
our
services
onto
the
mesh.
So
let's
go
and
check.
Let's
start
a
watch
of
my
thing:
I'm
going
to
go
kg
po,
all
my
cluster.
Let
me
see
this
so
right
now
my
services
doesn't
have
a
side
car.
So
one
of
the
things
what
you're
going
to
do
next
is
to
bring
our
services
into
the
service
to
your
service
mesh.
I
have
to
basically
label
the
name
space
with
the
label
called
istio
injection
enabled
equal
to
true.
A
B
Label
the
namespace-
this
is
a
very
basic
thing
that
is
required
to
get
your
services
into
the
service
mesh.
Now,
what
basically,
this
command
will
do
is
like
any
name
space
that
have
this
label.
These
two
will,
by
default,
go
ahead
and
inject
the
estio
site
card
proxy
into
all
the
service
ports
that
is
running
on
that
particular
namespace.
B
So
let's
go
ahead
and
do
the
restart
of
the
apps
so
that
it
picks
up
these
things
and,
as
you
see
right
now,
the
services
which
we're
running
with
one
of
one
are
right
now
going
to
the
state
of
zero,
slash
two,
which
means
there's
one
pod,
which
is
the
easter
proxy
pod
that
gets
injected
into
all
these
service
parts.
In
few
seconds,
you
see
that
our
service
parts
has
caught
the
htr
proxy
injected
into
them.
B
B
If
you
remember
earlier,
we
used
cube
cuddle
port
forward
to
get
to
our
services,
but
to
leverage
the
power
of
service
mesh.
We
need
to
create
two
istio
custom
resources,
one
a
gateway
that
configures
a
work,
that's
an
istio
custom
resource
workload
that
admits
the
traffic
into
the
kubernetes
cluster
by
other
service
mesh
and
a
route.
Also,
we
call
as
a
virtual
service
that
decides
what
to
do
once
a
traffic
is
admitted
by
the
gateway
and
where
should
I
route
it?
B
So
as
part
of
the
hdr
installation
we
did
earlier,
there
was
a
service
which
got
created,
which
is
called
as
an
english
gateway.
So
let's
go
and
check
the
service
just
going
to
copy
paste
the
command
here
and
we
got
an
instant
ingress
gateway
service.
That
is,
that
has
an
ip
address
and
listening
here.
In
fact,
we
should
also
have
a
corresponding
pod
called
as
an
easter
english
gateway
pod
that
that
handles
the
this
particular
custom
resource
related
things
that
has
to
be
done
once
the
traffic
is
admitted
right.
B
So
to
use
this
particular
custom
resource.
What
you
have
to
do
is
like
we
have
to
go,
create
a
gateway
resource
which
is
another
easter
custom
resource,
as
discussed
earlier,
and
the
custom
resource
has
to
go
through
the
istio
ingress
gateway.
Okay,
if
you
remember
that
we
use
the
same
label
here
and
we're
using
the
same
label
here
as
well-
and
we
said
listen
on
port
80
and
allow
all
host.
B
In
fact,
we
can
also
be
defined
specific
host
to
allow,
but
in
this
case,
I'm
giving
hall
host
for
the
simplicity
of
the
demo
as
we
discussed
earlier,
I
should
also
have
a
virtual
service
that
should
basically
leverage
this
gateway.
This
particular
service
a
gateway
and
route,
the
traffic
once
the
traffic
is
admitted
into
this
gateway.
B
This
virtual
service
decides
where
to
route
the
traffic
to,
in
this
case,
I'm
going
to
route
the
traffic
to
my
destination,
which
is
called
a
service
save
which
is
nothing
but
the
service
which
we
already
deployed
and
we're
using
earlier
all
right.
Let's
go
ahead
and
create
these
resources
to
start
routing
the
traffic
into
the
cluster.
B
There
we
go.
We
got
the
resource
available
for
us
to
do
this
in
order
to
use
this
gateway.
We
have
to
use
the
easter
english
gateway
ip
address
to
route
the
traffic
to
so
to
do
that
for
the
convenience
saying
I'm
just
going
to
store
that
particular
value
in
an
english
in
an
environment
variable
called
as
istio
ingress
gateway
ip
address
right
once
I
have
this,
I'm
going
to
start
sending
traffic
into
the
cluster
so
for
the
later
use,
I'm
just
going
to
start
setting
the
traffic
multiple
times
in
fact
start
sending.
B
Then
you
should
see
the
response
coming
here
and
it's
going
to
send
a
lot
of
requests
continuously,
because
we
need
to
observe
few
things
at
the
later
part
of
the
demo,
so
I'll
just
keep
sending
some
load
so
that
the
load
gets
piled
up
into
the
easter
system,
all
right.
So
now
we
are
good
that
we
have
got
the
traffic
into
the
cluster.
B
B
Istio
does
provide
us
with
a
set
of
tools
that
will
allow
us
to
observe
our
service
mesh
that
is
technically
observing
the
services
that
were
deployed
as
part
of
the
service
mesh
out
of
the
box.
Istio
generates
access
logs
and
metrics
that
could
be
used
by
tools
like
grafana,
elk
and
datadog
to
generate
and
visualize
the
data.
B
So
let's
go
and
inspect
one
such
log
from
our
proxy
site
car
of
service
a
to
see
if
it
gets
a
clue
on.
What's
going
wrong
with
our
failures
and
there
we
go,
we
see
a
bunch
of
500
errors
that
are
coming
out
of
this
right.
If
you
observe
this
one,
such
error,
that's
going
outbound
here.
It
goes
to
service
c
so
which
giving
us
a
clue
that
there
is
some
problem
with
the
service
c
right.
B
It's
going
from
service
a
to
service
c,
and
now
we
see
there's
a
problem
with
service
c,
which
is
giving
find
it
back
to
me.
But
you
also
need
some
additional
data
or
metrics.
That
requires
us
to
validate
this
particular
clue
that
we
got
and
see
how
many
requests
are
failing
and
how
many
requests
are
succeeding
to
do
that,
we
can
leverage
on
the
prometheus
data
metrics
that
istio
by
default,
generates
for
you.
Let's
go
and
run
a
query
to
get
our
prometheus
data
copy
the
command
and
paste
it
here.
B
There
we
go
so
I'm
just
running.
I
just
run
the
command.
That
gets
me
the
number
of
requests
that
were
successful.
In
this
case
there
were
500
requests
which
failed
and
there
were
336
requests
which
were
successful
but
hold
on.
So
this
is
okay.
If
I
do
a
small
demo
like
what
I'm
showing
to
you
people
right
now,
but
if
you
have
a
large
cluster,
you
need
some
kind
of
a
mechanism
where
you
can
monitor
and
observe
these
data
and
raise
alarms.
B
Of
course,
easter
does
provide
you
with
a
set
of
add-ons
that
could
be
integrated
with
it.
So
let's
go
ahead
and
install
those
add-ons
and
see
what
it
can
do
for
us,
so
there's
a
bunch
of
parts
that
needs
to
be
run
right
now.
So,
let's
wait
for
the
parts
to
be
coming
up
on
this
name
space
and
let's
go
and
open
the
dashboard
later,
so
I'm
just
going
to
open
the
griffana
dashboard.
So
let
me
go
copy
the
command!
B
Let's
go
and
open
the
grafana
dashboard
and
we
should
go
to
the
workload,
dashboard
and
outbound
services,
and
you
should
see
a
lot
of
errors
here
right.
As
you
see
on
my
screen,
you
should
see
a
lot
of
success.
Non-Phi
xx
responses,
so
I
was
going
success
rate
and
then
we
should
also
see
a
bunch
of
services.
Failing
right
is
giving
500
for
us.
B
So
this
gives
us
kind
of
a
real-time
monitoring
on
our
service
mesh
to
see
what
is
going
right
and
what
is
going
wrong
so,
but
we
also
have
another
tool
called
skiali,
so
that
helps
us
to
observe
the
entire
service
mesh
from
one
shot.
Okay,
let's
go
and
open
that
also
istio
ctl
dashboard,
and
then
I'm
going
to
open
kiyali.
B
And
there
we
go,
kali
is
open
for
us
and
then,
if
I
go
to
the
namespace,
let
me
go
and
find
out
the
graph
and
let
me
go
and
add
few
things
here.
So
as
the
default
name
space
is
there,
the
eastern
standard
namespace
is
there
and
let's
do
a
few
little
things
right?
I'm
just
going
to
add
these
things
ready
so
that
for
the
observation.
Now,
if
you
see
this
dashboard
here
and
then
you
see
the
service
going
here,
so
we
say,
and
then
service
c
is
failing
here
and
technically.
B
It
also
gives
you
data
that
version
two
of
the
services
failure,
whereas
the
version
one
is
successful.
That's
precisely
the
reason
why
we
get
50
success
rate
here
and
the
rest
are
all
failing
for
us
right,
and
this
makes
our
service
operator
happy
because
he
was
able
to
find
out
where
exactly
the
problem
is
and
how
we
can
tell
the
respective
teams
to
go
and
fix
the
problem.
But
our
developer
is
still
not
happy
because
we
are
not
the
founder
way
by
which
I
can
now.
B
B
Since
most
of
the
time,
it
is
difficult
to
fix
the
service
on
the
fly,
but
at
least
we
should
prevent
the
request
from
reaching
the
erroneous
service,
in
this
case
version
2
of
service
c.
To
do
that,
we
leverage
on
istio's
traffic
management
capabilities
to
route
all
the
traffic
to
version
1
of
service
c.
B
B
Now
all
the
traffic
gets
routed
to
version
v1
once
we
apply
this,
let's
go
and
apply
this
I'm
going
to
go
copy,
create
the
destination
rule
and
then
I'm
just
going
to
go
ahead
and
create
the
route
as
well
and
then
start
setting
some
request
so
that
we'll
go
to
our
kali
dashboards
to
see
what's
happening
right.
Let's
refresh
this
one,
let's
see
what's
happening,
it's
loading
the
graph.
It
gets
some
time
to
get
the
traffic
into
it.
B
While
we
do
that,
let's
go
and
refresh
the
our
ui
and
you
should
see
no
longer
failing
services
coming
up
as
part
of
the
ui.
Now
the
end
user
is
happy
because
he
no
longer
gets
errors,
so
our
developers
as
well,
because
we
are
not
sending
erroneous
response
to
the
end
users
and
now,
let's
go
to
kali
and
then
refresh
again
now
you
should
see
the
success
rate
bumped
from
50
to
100
in
this
case
right,
but
still
we
have
one
more
problem
to
solve.
B
Now
we
have
got
all
the
hundred
percent
of
the
traffic
going
to
version
one
of
service
c,
thereby
preventing
the
end
users
accidentally
getting
router
to
their
own
yes
service,
but
we
still
need
the
traffic
to
go
to
version
two
of
the
service
seal
so
that
our
developers
can
find
out
what's
going
wrong
and
build
a
fix
for
it
to
do
that.
We
leverage
on
another
traffic
management
capability
of
istio,
called
as
traffic
mirroring
with
traffic
mirroring
we
route
all
the
traffic
arriving
at
one
destination
to
another
destination
defined
by
a
percentage.
B
By
doing
this,
we'll
be
able
to
find
out
what's
going
wrong
with
our
server
c
version,
2
as
well.
Let's
go
and
apply
this
one,
and
once
we
apply
this,
if
we
go
back
to
our
kiali
console,
we
should
still
see
the
traffic
getting
routed
to
both
and
our
success
rate
is
almost
hundred
now.
Our
developers
is
also
happy
because
he's
successfully
gathered
the
end
user
from
getting
an
erroneous
response,
as,
alas,
he
knows
what's
going
wrong
to
work
on
a
fix
for
it.
B
A
B
In
order
to
fix
this,
we
are
going
to
leverage
on
another
istio
custom
resource
called
sphere
authentication
with
peer
authentication.
We
are
going
to
enable
mutual
tls
within
the
service
mesh,
which
means
any
client
who
is
trying
to
call
a
service
within
the
mesh
has
to
authenticate
themselves
in
order
to
get
the
response.
B
B
Cool,
we
now
fix
one
of
the
findings
of
our
security
audit,
but
we
still
have
one
more
thing
to
fix:
that
is
the
open
access
policy.
What
is
this
open
access
policy
is
all
about.
So
let
me
explain
that
with
an
example,
let's
assume
that
I'm
going
to
give
a
call
from
service
p,
when
I
do
this
call
as
expected,
I'm
going
to
call
service
a
from
service
b,
and
this
is
going
to
go
through.
B
Obviously,
and
again,
I'm
going
to
give
another
call
to
service
cv,
one
from
service
b,
because
I
will
see
v1
calling
service
b
either
way,
and
now
this
should
also
go
through
right,
but
as
per
our
architecture,
I
want
only
service
a
to
be
the
path
to
service
c
and
service
b
and
again
a
question.
What
could
be
wrong
with
this
approach
with
open
access
policy,
you're
opening
up
a
security
thread
where
someone
can
assume
or
impersonate
the
identity
of
the
service
to
gain
access?
B
In
order
to
do
that,
we're
going
to
leverage
another
istio
custom
resource
called
as
authorization
policy
what
are
defined
in
this
authority.
We
are
going
to
define
three
authorization
policies
for
the
first
one
where
I
say
we
defined
for
service
say,
and
we
say
that
the
service
a
could
be
accessible
only
by
istio,
ingress
gateway
service
account
that
is
bar
that
is
residing
in
is
your
system
namespace.
B
In
short,
I'm
going
to
allow
the
access
to
service
say
only
via
istio
english
gateway
and
then
I'm
going
to
define
one
for
service
b,
which
says
that
the
service
b
could
only
be
accessed
using
via
service,
save
the
service
accounts,
I
will
say-
and
lastly,
I'm
also
going
to
say
that
service
c
again
is
also
accessible.
Only
by
a
service
account
called
service
save.
In
this
way,
I'm
kind
of
opening
up
the
access
to
my
services
on
need
basis.
Let's
go
and
apply
these
things
and
see
what
happens
so.
B
B
B
And
hopefully,
this
should
also
give
you
the
same
old
error.
Let's
wait
and
see,
and
there
we
go.
We
got
the
similar
error
for
this
as
forbidden,
because
service
b,
a
service
c,
is
not
allowed
to
call
service
b.
But
when
you
go
back
to
the
browser
thing
should
work
as
expected
as
earlier
right,
because
there's
nothing
change
to
the
outside
world,
because
the
outside
world,
the
service,
a,
is
the
only
route
to
service
b
and
service
c
and
service,
a
is
being
called
by
our
ingress
gateway.