►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Stretching the Mesh - John Joyce & Robert Li, Cisco Systems (Any Skill Level)
Multiple clouds are a must in today’s IT world to prevent vendor lock-in, provide redundancy, a migration path, and other benefits. Developer's and IT admins demand that applications, and the micro-services that comprise them, be capable of running in multiple environments. A service mesh, instantiated by Istio, provides a new paradigm for connecting, managing and securing microservices. With services running in multiple clouds, the service mesh has to be established across clouds. In this presentation, John and Robert will show how an application can be stretched between two disparate cloud environments--public cloud and on-prem private cloud. The demonstration will show how the service mesh is stretched to fully enable service mesh features for all services and endpoints in both cloud environments. The summary will discuss how the Istio community has addressed this problem.
About Robert
Robert is a technical lead engineer at Cisco. For the past several years, I have been contributing to cloud infrastructure software development, especially in OpenStack. My current focus is to contributing to the Kubernetes & Istio communities.
About John
John is a principal engineer at Cisco responsible for developing cloud infrastructure and solutions. As part of the Cloud CTO Office, John currently focuses on contributing to the Kubernetes & Istio communities. Previously, John was an active contributor to OpenStack. John has a long history contributing to various Cisco virtual and physical networking products.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
We're
here
to
show
you
how
you
can
enable
multi
cloud
with
STL
and
the
way
we're
gonna
do
that
is
use
like
stretch
the
SEO
mesh
across
the
multiple
clouds,
we're
gonna
use,
a
public
cloud
and
a
private
cloud
and
we'll
show
you
a
demo.
Quite
a
bit
of
this
talk
is
around
showing
you,
the
actual,
how
we
actually
implemented
the
work.
So
there's
a
few
slides
on
that.
My
name
is
John
Joyce
with
the
Cisco
cloud
CTO
computing
group.
A
This
talk,
we're
really
not
gonna,
go
into
use
cases
of
why
you
might
want
to
do
multi
cloud
or
which
applications
or
services
could
take
advantage,
multi
cloud,
that's
not
the
purpose
or
earlier
talks.
I
think
they
covered
that
this
is
more
about
how
you
do
it
and
showing
you
an
example
of
actually
doing
it
so
where
I
will
give
you
a
little
bit
of
an
introduction
of
SDO
and
a
service
mesh
or
most
people
familiar
with
sto
and
what
a
service
misha's
there's
anybody,
that's
not
really
familiar
with
that.
Okay!
A
Well,
we
have
a
few
slides,
so
I'll
try
to
go
through
them
quickly,
since
most
people
are
familiar
with
it.
But
then
we'll
talk
more
specifically
about
some
of
the
changes
we
did
to
enable
the
multi
service-
I'm,
sorry,
the
multi
cluster
in
sto,
and
then
then
we'll
get
into
the
deployment
details
and
then
the
actual
demo.
A
What
we
want
to
enable
is
that
those
micro
services
can
run
anywhere
on
any
cloud
in
any
environment,
and
you
can
do
that
safely
and
securely
and
not
have
to
worry
really
too
much
about
the
placement
and
the
way
we're
going
to
do.
That
is
with
this.
Do
because
this
deal
provides
some
of
the
that
that
security,
some
of
the
the
efficiency
some
of
the
programmability,
some
of
the
routing
rules
to
allow
you
to
achieve
that
separation
and
allow
you
to
not
be
as
worried
about
the
placement
of
your
microservices.
A
So
just
a
quick
bit
on
what
a
service
meshes
service
mesh
is
a
mesh
of
proxies
that
you
act
as
like
the
front
end
to
the
API
between
the
micro
services.
So
what
I'm,
showing
here
is
that
you
know
you
have
a
bunch
of
micro
services
or
it's
kind
of
a
bit
arbitrary,
what
they
may
be.
They
have
api's
between
themselves.
Those
ApS
could
be
various
protocols
different
formats
and
what
we,
what
the
mesh
does,
is,
allow
sort
of
an
infrastructure
that
provides
a
common
infrastructure
for
these
micro
services
to
communicate
securely
with
each
other.
A
So
what
we're
showing
in
this
demo
is
doing
that
with
this
do
and
we'll
talk
a
little
bit
about
the
details,
I'm
not
going
to
talk
about
all
the
advantages
some
of
them
are
listed
here,
but
since
most
people
are
familiar
with
the
service
mesh,
you
can
kind
of
just
read
that
in
the
in.
In
the
case
of
this,
do
the
the
proxies
or
sidecar
inject
it?
So
there's
a
there's,
a
nice
separation
there
between
the
application
act
and
the
actual
proxy
itself.
A
So
this
is
the
VCO
architecture.
It's
the
the
figures
borrowed
directly
from
isseo
I/o.
It's
a
bit
dated
with
some
of
the
naming.
There's
been
quite
a
few
naming
changes
in
0-8,
so
I
would
encourage
you
if
you
really
want
the
details
to
go
to
a
CIO
but
I'm
trying
to
convey
a
little
bit
of
an
architecture.
A
So
you
get
a
feel
for
what
a
SDO
is
and
how
it
runs
it
pilot
is
the
piece
of
this:
do
that
controls
the
proxies
and
creates
the
mesh
for
the
proxies
and
has
a
view
of
the
entire
topology
mixer
is
provides
telemetry.
It
also
provides
some
policy
checks
a
little
bit
higher
level
security
for
server
side.
When
the
request
comes
to
the
server
mixer
is
able
to
do
a
bit
more
authentication,
the
SDO
off
has
been
renamed.
A
A
So
we
we
borrowed
the
cig,
multi
cluster
cluster
registry
as
the
source
of
where
those
clusters
are
not
where
those
clusters
right,
but
which
clusters
we
want
to
connect
with.
So
we
we
used
an
early
form
of
that.
We
actually
don't
do
an
API
call.
It's
more
file
based
call
right
now,
but
we
are
planning
to
extend
that
in
the
future
to
take
full
advantage
of
the
cluster
registry
and
do
API
calls
over
to
the
cluster
registry
to
get
the
set
of
clusters.
That
are
part
should
be
part
of
this
multi
cluster
mesh.
A
And-
and
this
shows
what
we
do
with
it,
so
in
this
figure
the
the
on-prem
is
sort
of
the
left
hand,
side
the
right
hand
side
is
a
gke
based
cluster
and
we're
running
pilot
only
in
the
gke
based
cluster,
and
basically,
what
pilot
will
do
based
on
the
cluster
registry
information
we
push
to
it.
It
will
interact
with
all
the
coop
API
servers
on
all
the
clusters
that
will
go
to
the
service
and
endpoint
data.
A
It
will
also
get
config
data
relative
to
like
sto
route
rules
and
stuff
like
that,
and
it
combines
that
in
and
and
pushes
it
into
what's
what
we
call
pilot
discovery.
So
pilot
discovery
is
a
cache
that
represents
the
entire
XDS
database
for
Envoy.
So
when
Envoy
does
an
XDS
request
to
get
its
the
it's,
you
know
it's
CD
SLDS
RDS
its
XDS
information
pilot.
They
able
to
push
that
out
to
it.
A
Okay,
so,
alongside
of
the
actual
service
and
endpoint
discovery,
this
is
kind
of
explaining
what
we
do
to
have
envoy
be
able
to
talk
to
a
single
pilot
and
get
the
discovery
data.
So
what
we
do
there
is
the
way
envoy
is
configured
envoy
is
configured
with
just
a
generic
DNS
entry
on
I'm,
sorry,
a
generic
service
name
for
pilot
and
mixer.
So
what
will
happen
is
when
envoy
comes
up.
It's
does
a
local
DNS
query
of.
Where
is
my
pilot?
Where
is
my
mixer
that
ends
up
pointing
back
to
the
single
cluster?
A
In
addition,
what
we
have
to
make
sure
is
that
this,
the
this
asserts
that
both
the
Envoy
needs
at
the
data
plane
level
to
communicate
with
pilot,
as
well
as
the
certs
for
the
applications
communicate
with
each
other
are
available
and
the
way
we
do
that
is,
we
run
a
sto
citadel
in
cluster,
and
then
we
that
all
those
certs
are
chained
back
to
a
single
root
certificate.
This
just
like
sort
of
shows
the
procedure
we
use
to
achieve
that.
A
Okay,
so
now
a
little
bit
on
the
deployment
that
you're
gonna
see
so
a
couple
things
that,
for
this
particular
deployment
demonstration
some
of
the
environmental
requirements
yeah,
you
must
have
IP
reach
ability
between
the
clusters.
In
the
particular
demo
you'll
see,
we
actually
expose
the
pot
IPS
on
all
the
clusters,
so
you
have
pod
reach
ability
across
the
clusters,
and
we
take
advantage
of
that.
A
You
don't
have
to
use
the
pods
or
are
other
ways
you
could
do
this,
but
in
this
particular
demo
we
use
pot
IPS
and
have
reach
ability
about
across
those
IPs.
The
other
thing
is
that
your
micro
service
itself
is
going
to
take
advantage
of
dns
and
use
dns
to
resolve
its
peer
services.
So
if
you
have
a
service
that
doesn't
have
it
instantiation
on
a
particular
cluster,
you
you
need
to
do
something
in
dns
to
make
sure
that
that
service
name
is
represented
back
on
it
differently.
A
If
you
have
a
service
in
pod
a
and
a
service
in
pod
b,
that
wants
to
access
the
pod
a
service,
you
have
to
make
sure
there's
a
representation
in
pod
b
of
the
poppy
cluster
b
of
the
service
that
you
want
to
access.
So
we
do
that
again
with
headless
services
and
and
Robert
we'll
get
into
a
little
bit
more
detail
in
that
in
a
minute.
A
This
is
I
kind
of
showed
this
figure
a
little
bit
before
it's
just
a
little
bit
less
cluttered
in
what
you'll
see
here
is
we
will
have
a
bunch
of
control,
plane,
pods
and
sto.
Citadel
is
the
only
really
control
plate
element
running
on
both
the
the
gke
and
the
on-prem
side?
Just
one
little
note,
some
of
this
slides
say:
GCP
I,
hope
the
Google
guys
don't
get
mad
at
me,
this
is
all
gke
based
in
our
actual
demo,
so
a
little
bit
a
quick
detail
on
what
you'll
see
with
respect
to
the
application.
A
So
you
understand
the
flow
of
things.
The
applications
based
on,
what's
known
as
the
book
info
application-
that's
commonly
used
in
in
sto,
for
both
testing
and
and
to
display
the
power
of
Sto.
So
what
happens
is
that
the
user
makes
a
request
to
the
product
page,
but
the
the
actual
service
is
decomposed
in
a
couple.
Microservices
running
different
languages,
as
shown
here
and
in
the
particular
demo,
will
show
you
the
tan
all
the
tan
pods
are
running
on
gke
and
we
have
a
single
micro
service.
A
That's
running
on
Prem,
to
just
be
able
to
very
easily
see
the
routing
between
the
two
to
two
scenarios,
and
this
I
have
a
little
bit
of
an
animation
here,
showing
you
the
actual
flow
of
the
client
request
when
the
client
makes
it
when
an
external
client
makes
a
request
to
the
product
page.
This
is
going
to
show
you
how
the
micro
services
work
together
to
fulfill
the
final
response
back,
so
the
end
user
will
make
a
request.
The
product
page
itself
will
go
to
reviews
to
say
get
me
my
reviews
portion
for
that
request.
A
It
also
get
the
details
portion
from
the
details
pod
now,
the
more
interesting
part
there
will
be
exhibit
in
the
demo.
His
reviews
itself
needs
to
go
to
deep
rating
service
to
get
information
on
how
many
stars
it
should
depict
and
oops
and
then,
finally,
all
these
all
this
data
from
the
different
micro
services
is
aggregated
and
sent
back
to
the
to
the
end
user.
The
end
receiver,
so
at
this
point,
Robert
will
go
into
a
little
bit
of
details
and
show
you
some
okay.
B
So
John
just
talked
about
the
background
and
the
architecture
of
Steel
MIDI
cluster
and
also
the
booking
for
sample
application
deployment.
So
I'm
going
to
go
through
the
detail
of
the
department
for
each
steal
and
the
booking
for
application,
there's
not
enough
time
to
do
a
live
demo
here.
So
what
we
do
it
is
to
pre
deploy
and
we
took
some
screenshots
and
I'm
going
to
go
through
that
with
you.
So
you
can
see
on
the
screen.
B
B
There
is
a
documented
procedure
that
you
can
find
at
st
dot
io
site
for
multi-class
to
the
deployment
in
this
demo.
We
choose
to
use
this
epoch
import,
make
target
to
deploy,
sto
and
poke
info,
so
we
execute
this
command
in
the
primary
tiki
cluster
and,
as
a
result,
the
Institute
control
plan
will
be
deployed
over
there.
B
A
Earlier
I
mentioned
that
we're
using
a
preliminary
version
of
the
cluster
registry.
So
it's
it's
a
file
based.
That's
why
you
just
see
a
file
based
reference.
Ultimately,
that
will
probably
migrate
to
like
more
of
an
API
call,
but
at
the
time
we
did
this.
The
cluster
registry
stuff
was
still
quite
a
bit
in
flux,
so
we
we
use
the
file
based
approach.
B
B
B
You
can
also
find
that
the
book
info
application
is
deployed
over
the
GE
cluster
and
we
we
only
have
reviews
version,
1
and
version
2
are
running
there.
So
in
earlier
slides
you
have
seen
that
we
have
three
versions
of
review
micro
services,
so
we
we
only
deploy
the
two
versions
of
reviews
over
in
the
TK
cluster
on
the
bottom.
You
can
see
that
the
only
steel
control
component
that
we
deployed
is
citadel
and
all
the
other
components
are
not
running
over
there.
B
B
B
B
Now
we
are
ready
to
deploy
some
of
the
booking
for
micro
surfaces
in
the
unprimed
cluster,
so
we
we
only
deploy
the
reviews
version
3
in
prime
cluster.
In
the
same
time,
since
the
reviews
service
is
going
to
call
reading
service,
so
we
created
select
early
selection
list
service
readings
service
in
the
unprimed
cluster.
This
is
for
this
is
so
that
you
can.
The
reveal
service
can
discover
the
reading
service
in
the
prime
cluster.
B
B
B
A
A
C
C
B
A
A
C
A
C
A
A
Oh
I
get
v3,
so
the
idea
here
is
now
that
this
all
this
traffic,
this
could
be
like
a
canary,
perhaps
the
canary,
install
or
something.
But
all
the
traffic
for
Jason,
when
Jason
logs
in
will
be
routed
over
to
the
pod
on
Prem
and
we
actually
labeled
the
application
slightly
differently.
So
you
can
see.
C
C
A
D
A
D
A
Sure
so
they're
high
in
the
SEO
community
is
explored,
something
that
generally
we've
called
this
work,
Multi
cluster
and
generally
called
the
other
work
multi-cloud.
Although
we
sometimes
been
fuzzy
on
the
naming
and
the
idea,
there
would
be
you
to
run
pilot
in
multiple
instances
and
then
you'd
have
the
pilots
talking
to
each
other,
so
that
would
provide
you
know
more
resiliency
for
that
particular
failure
case.
Alright,.
A
A
So
so
so
just
so
you
all
know,
the
question
was,
if
you're
not
running
a
kubernetes
cluster,
on
your
other,
where
you
want
to
run
your
other
micro
services,
what
do
you
do?
Okay,
and
what
what
we
were
just
talking
about
everybody
could
hear
is
that
what
you
run
is
a
little
bit
of
pilot
on
the
on
the
the
the
example
scenario
in
SEO
is
what's
known
as
mesh
expansion,
where
it's
a
VM,
so
you
run
like
a
little
bit
of
pilot
over
there
on
the
VM.
A
Yeah,
so
within
the
SEO
community,
we've
talked
a
little
bit
about
the
service
broker.
Okay,
the
question
was:
have
we
taught
thought
about
kind
of
combining
this
work
with
the
service
broker?
So
I?
Don't
my
team,
you
know
the
team.
That's
worked
on
this
particular
work.
We
haven't
spent
a
lot
of
time
looking
at
that,
but
within
the
SEO
community.
That's
been
a
discussion
point.
A
A
So
here's
some
references,
it's
in
the
slide
deck-
that's
posted.
If
you
want
to
get
it,
get
it
I
think
the
only
thing
that
I
like
to
point
out
is
we'd
love
to
have
anybody
that
wants
to
contribute
to
this
work,
extend
it
to
other
environments,
extend
it
to
non
kubernetes
environments.
We've
tested
this
work
on
on
print
well,
in
an
on-prem
case,
we've
tested
this
with
OpenStack
based
VMs
with
vSphere
hbm's
people
are
testing
it
with
IBM
cloud
and
we're
going
to
try
to
plan
to
test
this
with
two
kubernetes
clusters.