►
From YouTube: Amazon EKS Anywhere & Istio with Solo
Description
Amazon EKS Anywhere (EKS-A) works better with Istio service meshes and Envoy Proxy API gateways to connect applications and microservices in hybrid Kubernetes (K8s) environments. Solo's Gloo Mesh and Gloo Edge can help!
Read more: https://www.solo.io/blog/amazon-eks-anywhere-and-solo-istio/
#EKSAnywhere #K8s #Kubernetes #Microservices #istio
A
Hi
leah
here
with
the
solo
team
today,
I
am
super
excited
to
show
you
a
demo
of
successfully
failover
services
running
in
eks
anywhere
to
services
running
eks
in
public
cloud.
Let's
get
started,
eks
anywhere
is
a
new
deployment
model
that
allows
you
to
easily
deploy
eks
in
your
corporate
data
center.
It
opens
up
a
bunch
of
new
scenarios,
such
as
workload,
migration,
application,
modernization
cloud
bursting
in
this
demo.
Today
I
have
three
clusters.
My
custom
y
is
running
on
the
corporate
data
center
in
eks
anywhere
in
this
cluster.
I
have
issue
running.
A
I
have
the
famous
booking
phone
application,
along
with
istio
ingles
gateway
for
the
review
service.
I
only
have
review
version
1
and
review
version
2..
I
also
have
two
clusters
running
aws
public
cloud,
cluster
2
running
on
istio
issue,
ingress
gateway.
I
have
review
version
3
and
the
rating
application
cluster
three,
which
is
the
glue
mesh
management
cluster.
A
We're
gonna,
do
also
to
make
it
interesting
to
trigger
a
failure
scenario
in
this
failed
scenario.
We're
going
to
put
reviews
one
and
two
in
the
first
cluster
to
sleep,
so
they're
not
available,
and
then
we're
going
to
use
istio
and
glue
mesh
to
successfully
fade
over
the
services
to
the
cluster
too.
A
A
A
To
do
that,
we're
going
to
put
the
reviews,
version,
1
and
version
2
in
the
first
cluster
to
sleep
20
hours.
Now,
what's
going
to
happen,
when
I
hit
the
refresh
button,
guess
there's
no
service
for
the
reviews
up
running
so
sorry,
let's
see
how
we
can
get
that
fixed
right.
This
is
not
what
you
want
to
see
in
your
production
environment
for
sure.
A
A
The
second
resource
we're
going
to
create
is
called
traffic
policy.
It
essentially
says
when
the
traffic
comes
from
the
product
page
on
the
first
cluster,
I
want
to
route
to
the
virtual
destination
I
just
created
so
regardless.
Well,
you
know
the
reviews
are
running
in
which
cluster
I
want
to
be
able
to
go
to
the
global
when
the
local
is
not
running.
A
A
If
you
highlight
the
link
from
product
page
to
review
version
3,
you
can
get
a
little
bit
more
detail
about
this
traffic.
What
we're
going
to
do
next
is
enable
the
review
version
1
and
version
2.
on
the
first
cluster
right.
So
what
do
you
think
is
going
to
happen
now
that
the
review
service
on
the
first
class
are
up
running
and
they
are
healthy
when
you
visit
the
book
info?
What's
going
to
happen
now?
A
If
we
do
visit
a
product
page
again
notice,
the
traffic
would
only
go
back
to
the
local
cluster
where
the
product
page
runs,
which
is
review
version
one
and
two.
The
reason
is,
we
have
tell
in
the
virtual
destination
configuration
we
prefer
local
for
low
latency
and
better
performance
when
local
is
not
available.
We
want
to
successfully
fail
over
to
the
remote
cluster.
As
you
can
see,
traffic
are
back.
If
you
find
this
demo
interesting
check
out
solo,
I
o
we
have
a
lot
of
resources
to
help
you
learning
istio,
envoy
and
guru
match.