►
From YouTube: Istio 1.6 Locality Aware Load Balancing and Failover
Description
A quick video on locality aware routing / load balancing/ failover using Istio within a single cluster running in multiple availability zones.
Learn more
About Service Mesh Hub https://solo.io/products/service-mesh-hub/
About Istio https://istio.io
Community https://slack.solo.io
A
Now
this
is
a
feature
that
is
available
in
istio
and
has
been
for
some
time.
There
have
been
some
improvements
to
it
recently
and
what
I
want
to
show
is
how
you
can
keep
traffic
constrained
to
its
cur
current
locality,
or
you
know
that
the
source
of
the
traffic
will
stay
in
the
same
locality
as
the
destination,
but
then,
when
things
start
to
go
wrong,
then
you
can
start
to
expect
you
know
over
and
and
failover
and
so
forth.
So
let's
jump
right
into
it.
A
A
A
A
Nick
jackson
actually
wrote
this
a
buddy
of
mine
works
at
hashicorp,
and
what
this
does
is
allow
us
to
simulate
behaviors
in
a
service
whether
responding
with
a
message,
whether
erroring,
out
being
rate
limited,
consuming,
cpus
and
so
forth,
a
great
great
little
tool
for
testing
this
out
and
we'll
use
that
here
in
this
demo.
A
So
the
first
thing
that
we
want
to
do
is
take
a
look
at
what
that
fake
service
response
looks
like
we
see.
If
we
go
into
the
sleep
pod
and
call
our
fake
service,
we
get
a
response,
a
json
response
that
looks
like
this.
We
can
see
the
ip
address
of
the
host
that
returned
it.
So
if
I
can
actually
back
here
and
call
it
again,
we
see
3.30,
we
got
3.35
31.
A
A
If
we
end
up
calling
that
a
handful
of
times
like
we
just
did,
we
see
that
it,
it
tends
to
load
balance
across
all
of
the
endpoints
that
that
istio
knows
about,
and
that
reflects
these
different
parts.
These
different
services
that
are
running.
We
can
see
these
ip
addresses
here
now.
These
are
actually
running
across
the
different
nodes
that
we
have
in
our
kubernetes
cluster,
which
means
it's
going
across.
The
traffic
is
going
across
all
these
different
availability
zones.
A
Now
you
might
have
reasons
for
wanting
to
constrain
the
traffic
locally
so
that
if
traffic
originates
in
zone
west
1c
that
it
stays
in
1c
right.
So
let's
take
a
look
at
istio's
capability
to
automatically
do
that.
For
us,
it's
actually
built
into
envoy.
That
is
still
proxy
that,
like
it's
used
under
the
covers
here
as
the
sidecar.
A
A
We
got
to
know
which
endpoints
are
healthy
and
make
up
our
priority
based
on
their
locality
and
then,
if
they
become
unhealthy,
slowly
start
to
spill
over
and
actually,
if
you
come
to
the
envoy
documentation
and
look
at
the
priority
page,
you
can
see
exactly
you
know.
Prior
zero
is
the
highest
p1
and
so
forth,
and
what
are
the
the
levels
that
and
and
the
percentage
of
healthy
endpoints
and
the
provisioning
factors
and
so
forth
over
provisioning
factor
and
so
forth
that
gets
used?
It
gets
nicely
explained
there
now.
A
One
thing
I
do
want
to
point
out
and
I've
seen
this
come
up
and
there's
a
little
bit
confusing
envoy,
does
zone
aware
routing
or
can
do
zone
aware
routing
where
the
proxy
itself
can
pick
which
endpoints
in
a
upstream
to
route
to.
But
that's
not
what
gets
used
in
istio
istio.
Does
the
locality
weighted
load
balancing?
So
that's
that's.
A
What
we're
talking
about
where
the
control
plane
knows
where
the
different
endpoints
live
and
annotates
them
and
weights
them
according
to
priority
that
the
control
plane
knows
about
not
that
the
proxy
gets
to
decide.
So,
let's,
let's
continue
to
enable
the
priority
weighting.
A
We
need
to
give
it
some
health
checking
information
in
this
case
we'll
do
a
passive
health
checking
with
out
the
outlier
detection
capability
in
an
envoy
and
exposed
through
istio.
In
this
case
it
says
for
the
endpoints
that
live
in
the
load,
balancing
pool.
A
So
let's
add
this
outlier
detection,
config
or
the
destination
rule
to
istio,
and
now,
if
we
check
our
priority
groups,
or
rather
our
endpoints
again,
we
should
see
priority
attached
to
the
endpoint
yeah
and
we
do
right.
We
see
priority
one
for
west
one
a
now.
This
is
doing
the
priority
based
on
where
this
particular
service
is
running.
So
this
is
the
sleep
service.
A
A
A
West
one
a
is
not
where
sleep
pod
is
running
and
we
see
a
priority
of
one
remember
from
the
envoy
documentation
priority
zero
is
the
highest.
We
see
again
west
one
a
priority
of
one,
let's
find
another
one
again
west
one
b,
this
one's
priority,
one
also
west
one
b,
where's
west
one
c.
Here
we
go
last
one
c
and
we
don't
have
a
priority
waiting
by
default.
A
The
priority
will
be
zero
if
it's
not
specified
and
we'll
verify
that
in
a
second
now,
if
we
call
the
endpoints
or
call
our
fake
service
again,
we
should
see
that
it
gets
constrained
to
just
the
end
points
that
are
running
in
that
locality.
In
this
case,
we
can
see
it's
not
load
balancing
across
all
seven
endpoints.
It's
doing
it
across
looks
like
three
different
ones:
331,
341
and
3
30..
A
Does
that
match
up
here
we
see
the
good
service
but
fake
services,
30,
41,
30
and
31
all
living
on
the
same
node
as
the
sleep
service.
So
we're
good
now
we're
starting
to
get
that
locality-based
routing
so
that
we
prefer
the
services
in
our
same
locale
before
we
start
to
spill
out
to
any
others
in
the
in
the
load,
balancing
pool.
A
A
A
A
clusters?
So
we
see
all
the
clusters
that
are
running
in
the
envoy
proxy
in
the
sleep
pod.
If
we
go
to
fix
service,
we
can
see
our
configuration.
We
can
also
see
which
endpoints
are
currently
in
the
load
balancing
pool,
and
we
can
see
that
the
ones
that
run
in
us
west
one
have
a
priority
of
zero.
Remember
we
said
we'll
verify
that,
and
indeed
it
is
zero.
We
see
prior
to
zero
again
here.
A
So,
instead
of
returning
200,
it's
going
to
return
a
500
and
that's
well
we'll
see
it
here
in
canines,
the
bad
fake
service
start
to
update
itself.
A
So
now
we
have
the
bad
fake
service
and
the
good
fake
service,
some
of
them
running
in
the
same
locale
as
sleep
pod.
A
If
we
come
back
here
to
the
stats
refresh
fake
service,
we
see
healthy
in
west
c,
healthy
west,
one
c
same
thing:
here,
that's
three
and
four
and
you
see
a
priority
of
zero
for
those
ones.
So
that's
all
good.
A
Now,
let's
start
calling
the
the
service
and
all
right
now
we
just
called
it
down
here
fake
service.
We
got
a
500
from
3.42,
so,
let's
refresh
for
3.42,
now
we're
seeing
a
it's
been
marked.
As
has
failed,
we've
kicked
it
out
of
the
load,
balancing
pool
and
3.42,
we'll
kick
it
out
for
30
seconds.
So
if
we
call
it
again
a
couple
times
that
one
looks
good,
that
looks
good,
30
and
31.
Look
good
43
does
not
look
good
42,
we
saw
did
not
look
as
we
refresh
now.
A
A
3.31
was
good,
30
is
good
and-
and
we
start
to
see
that
we're
able
to
load
balance
to
staying
constrained
locally,
but
the
the
bad
ones
have
been
kicked
out.
We're
not
calling
those
we're
just
using
basic
outlier
detection,
and
we,
if
we
call
it
a
couple
more
times,
we
might
see
that
eventually
we'll
see
it
again,
but
it'll
be
kicked
out
again
this
time
even
longer
right
and
if
it
happens
that
all
of
them
get
start
to
get
kicked
out
or
too
many
of
them
start
to
get
kicked
out.
A
Then
we'll
fail
over
to
the
service,
the
fake
service
workloads
that
are
running
in
the
different
localities.
The
different
availability
zones
in
this
case
automatically
now
this
is
all
applicable
for
a
single
istio
service
mesh
right
where
the
control
plane
knows
about
the
locality
of
these
different
workloads.
So
this
will
work
for
a
single
cluster
it'll
work
for
multiple
clusters.
If
you,
if
you
use
a
single
control
plane
in
istio,
now,
there's
there's
reasons
why
you
might
not
want
to
do
that,
including
failure,
isolation
and
and
so
forth.
A
It's
probably
better
to
do
multiple
control
planes
of
istio,
but
in
that
case,
this
locality
information
is
only
specific
to
one
cluster,
so
routing
across
clusters.
This
doesn't
work
very
well
or
you
don't
get
that
locality,
aware
routing
across
clusters,
but
that's
where
an
open
source
project
that
we're
working
on
at
solo,
called
service
mesh
hub
fits
into
the
picture
service
mesh
hub
is
a
management
plane
for
multiple
installations
of
a
service
mesh
or
including
istio,
and
we
css
in
the
latest
version
of
service
mesh
hub.
A
We
do
have
this
ability
to
define
failover
and
locality
between
multiple
multiple
deployments
of
istio,
multiple
istio
control
planes
across
multiple
clusters,
so
that
will
that
that's
that'll
be
coming
in
in
a
release
and
I'll
have
some
more
details
and
more
videos
about
that.
But
until
then
check
out
istio
and
the
locality
aware,
load,
balancing
and
and
weighted
routing
that
comes
out
of
the
box.