►
From YouTube: Life Outside the Cluster: Adding Virtual Machines to an Envoy Servic... Megan O'Keefe & Ameer Abbas,
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Life Outside the Cluster: Adding Virtual Machines to an Envoy Service Mesh - Megan O'Keefe & Ameer Abbas, Google
Service mesh tools add lots of functionality for Kubernetes-based applications, including policy automation and telemetry. But what if you're halfway through a migration to Kubernetes, and you still have applications running in virtual machines? In this talk, Megan O'Keefe and Ameer Abbas will demonstrate how to use Istio, an Envoy-based service mesh, to connect Kubernetes services with applications running in VMs. Demos will include: encrypting gRPC traffic between Pods and VMs, using Prometheus to view application metrics across both environments, and load balancing traffic between Kubernetes and VM instances. You will leave this talk understanding exactly how to integrate virtual machines with an Envoy-based service mesh.
https://sched.co/Uaap
A
Good
morning,
thank
you
so
much
for
making
it
out
to
this
talk.
You
know
it's
kind
of
the
last
day
powering
through,
so
we
really
appreciate
your
time.
Welcome
to
life
outside
the
cluster.
This
talk
will
be
all
of
all
about
virtual
machines
and
envoy
and
sto,
so,
hopefully
you're
in
the
right
place
just
to
quickly
introduce
ourselves.
My
name
is
Megan
and
my.
A
We
are
both
part
of
Google
cloud
working
closely
on
hybrid
cloud
service,
mesh
containers,
kubernetes
all
that
wonderful
stuff
and
we're
super
excited
to
be
here
just
a
quick
recap
of
what
we're
going
to
cover
today.
We're
gonna
try
to
fit
in
as
much
as
we
can.
This
talk
does
not
assume
any
prior
knowledge
of
SCO
or
Envoy.
So
we're
gonna
give
a
really
quick
introduction
to
sto
why
you
would
use
a
service
mesh,
then
we'll
talk
about
VMs.
A
Why
would
you
want
to
add
a
VM
to
a
service
mesh
then
we'll
hand
it
off
to
a
mirror.
You
will
give
a
rundown
of
exactly
how
this
is
going
to
work.
We're
gonna
run
through
some
demos
and
close
it
out
with
a
few
best
practices
on
how
to
make
all
this
work
in
a
seamless
way.
So
raise
your
hand
if
you've
heard
of
the
term
service
mesh.
A
Okay,
that
saves
me
a
few
sentences.
Raise
your
hand
if
you
have
10
micro
services
running
in
one
or
more
kubernetes
clusters
right
most
most
folks.
So
this
would
be
like
how
many
deployments
do
you
have
how
about
100?
Oh
ok,
200
500,
I'm,
just
gonna,
keep
saying
numbers.
Ok,
so
maybe
a
lot
of
us
know
in
this
room.
Adopting
containers
and
kubernetes
can
add
a
lot
of
benefits
right,
although
scaling
the
ability
to
easily
use
multiple
frameworks
and
programming
languages,
resource
efficiency,
there's
all
sorts
of
benefits
right,
but
what
those
benefits
comes
complexity.
A
If
you
can
use
multiple
programming
languages,
maybe
that
means
you
have
to
maintain
lots
of
different
client
libraries
to
do
simple
things
like
retry
logic
or
search
circuit
breaking.
You
also
have
more
services
to
monitor.
How
do
you
know
who's
talking
to
whom?
How
do
you
know
if
there's
a
latency
issue
going
from
a
kubernetes
cluster
in
one
region
to
another?
A
There's
a
whole
lot
of
questions
that
you
now
have
to
start
asking
yourself
and
what
this
means
is
there's
in
the
last
few
years,
I
think
there's
really
become
this
need
to
have
a
consistent
layer
not
only
for
four
metrics
and
logs
right,
aggregating,
all
of
what's
happening
on
in
all
of
your
pods,
but
also
at
the
policy
layer.
So
things
like
network
policies,
security
policies,
I'm
having
an
easy
way
to
manage
all
those
in
one
place,
and
that's
really
what
a
service
mesh
is
for.
What
is
the
definition
of
a
service
mesh?
A
A
What
I
think
any
service
mesh
tool
can
really
provide
you
anything
that
you
can
just
add
a
Yambol
to
and
a
service
mesh
can
take
care
of
logic
on
your
behalf,
what
that
lets
you
do
is
tap
into
best
practices
like
get
ops
like
declarative
policies
and
resources-
things
you
may
already
be
doing
with
kubernetes
service
mesh
can
really
help
you
kind
of
extend
this
platform
to
get
that
consistency
and
to
get
that
observability
that
you're
looking
for.
So
there's
a
lot
of
different
service
mesh
tools
out
there.
Several
are
open-source.
A
Today
we're
going
to
be
talking
about
two
pieces
in
our
toolkit.
The
first
has
to
do
with
the
data
plane.
So
envoy
is
part
of
the
CNC
F.
It
is
a
high-performance
configurable
proxy
written
in
C++.
It
speaks
its
own
API
called
the
XDS
ApS
and
the
service
mesh
tool
that
we're
going
to
be
talking
about
today
that
configures
those
envoy
proxies
is
Sto.
A
So
the
way
sto
works
is
you
hand
it.
A
Hamel
file
like
a
policy
and
sto
will
convert
all
of
that
logic
into
envoy,
speak
and
configure
all
those
proxies
on
your
behalf.
What
sto
will
also
do
is
help
you
aggregate
all
those
metrics
and
forward
them
to
whatever
back-end
sink
you're
using
so
before
we
get
into
VM
Lance.
It's
probably
a
good
idea
to
discuss
how
SCO
works
in
a
kubernetes
environment.
A
What
this
lets
you
do
is
envoy
keeps
track
of
all
the
metrics
and
can
also
enforce
that
policy
before
those
requests
leave
the
pod,
and
then
we
have
the
sto
control
plane,
which
is
also
running
inside
of
our
cluster.
This
control
plane
consists
of
multiple
parts.
The
key
thing
to
know
is:
there's
a
piece
called
pilot
for
traffic
management,
piece
called
Citadel
for
security
and
a
piece
called
mixer
for
metrics.
A
Really,
all
there
is
to
know
is
you
talk
to
the
sto
control
plane
with
all
of
your
rules
and
policies
and
those
get
forwarded
down
to
envoy
today
we
are
have
installed
Prometheus,
alongside
of
our
sto
installation
in
our
demo,
and
what
this
lets
us
do
is
use
key
Olle,
which
is
a
service
graph
tool
to
see
a
view
into
what's
happening
with
our
services.
So,
okay,
really
quick
recap
of
this.
A
Do
let's
stop
the
VMS
another
sort
of
poll
here,
raise
your
hand
if
you
are
operating
any
kind
of
staple
or
legacy
service
in
a
vm
outside
of
kubernetes.
If
you've
got
one
okay,
wow,
that's
everyone,
Oh
raise
your
hand.
If
you've
got
more
than
ten
of
these
services
Wow
a
hundred
holy
okay,
Wow
uhm-
so
that's
a
lot.
A
The
idea
here
and
if
you
kind
of
walk
away
with
anything
in
this
talk,
is
the
idea
that
it's
kind
of
a
myth,
I
think
that
everything
belongs
in
a
container
or
that
everything
belongs
in
kubernetes
I.
Don't
think,
that's
true,
whether
it's
a
staple
service
or
a
database
or
something
that
lives
on
a
mainframe
there's
always
going
to
be
a
service
that
doesn't
live
in
your
cluster.
A
In
some
cases
you
may
own
these
services,
which
is
the
situation
we're
going
to
talk
about
today,
where
you
can
actually
sudo
in
whatever
compute
is
running
that
service
and
install
stuff
on
it.
That's
great,
but
the
key
thing
here
is
consistency
in
the
perfect
world
whether
we
have
pods
or
whether
we
have
VMs,
we
can
have
aggregated
sort
of
metrics
and
observability
and
use
the
same
policy
objects
to
apply
to
both
to
both
two
pods
and
two
VMs
and
sto
can
make
that
possible.
B
Thanks
Megan
so
before
we
get
into
how
we
can
integrate
VMs
into
the
osteo
control,
plane,
I've
been
working
on
SEO
for
a
while,
and
it
took
me
a
while
to
kind
of
really
grasp
what
kind
of
the
service
mesh
thing
does,
and
I
kind
of
separated
out
into
two
things
right.
How
does
is
do
a
view,
a
service
or
any
service
mesh
Mewis
service
right,
we
think
of
services
as
something
that
runs
in
a
container
inside
of
kubernetes.
But
a
service
is
essentially
just
a
process,
that's
running
anywhere.
B
It
could
be
in
a
VM,
it
could
be
in
a
in
a
cluster
and
sto
makes
a
routing
decision
based
on
a
name
or
you
give
it
a
name,
and
it
decides
where
to
go
right.
So
that's
one
thing:
that's
kind
of
the
routing
aspect
of
this
do
and
then
the
next
aspect
of
sto
is
this
idea
of
giving
it
kind
of
declarative
way
of
configuring.
The
network
application
functions,
which
are
security
and
policy,
and
so
on.
B
There
are
two
types
of
services:
whether
they're,
whether
it's
sto
or
non
sto
services,
are
running
kind
of
everywhere
right.
So
first
thing
is
the
routing
piece
we
need
to
be
able
to
get
to
services,
whether
they're
inside
the
mesh
or
outside
the
mesh,
and
it's
to
use
those
services
as
the
same
right.
So
we
have
this
something
called
mesh
internal
services.
These
are
any.
This
is
any
process
running
anywhere
that
has
that
Istria
proxy
running
as
a
sidecar
right
next
to
it
right.
B
So
a
CEO
considers
that
as
part
of
its
mesh
or
its
control
plane,
it
can
configure
things
like
traffic
routing
traffic,
shaping
get
observability
and
so
on,
and
so
forth
inside
of
kubernetes
is
to
your
control
plan,
can
just
interrogate
the
cube,
API
server
and
discover
all
the
services,
all
the
endpoints,
all
the
pods
that
happens
implicitly
and
so
all
of
the
mesh.
All
of
the
services
inside
of
the
kubernetes
service
are
implicitly
mesh
internal
outside
of
the
cluster,
where
you
don't
have
kind
of
some
automated
way
of
doing
service
discovery.
B
This
is
where
we
need
to
kind
of
explicitly
define
whether
the
service
is
going
to
be
a
mesh
internal
service,
meaning
there's
an
sto
proxy
sitting
next
to
it
and
I
kind
of
control.
The
network
functionality
of
that
process
or
whether
it's
sitting
outside
of
the
service
mesh,
which
means
it's
being
owned
by
a
completely
different
team.
This
is
an
API,
a
partner
API
that
you
go
to
or
a
database
where
you
don't
have
the
means
to
put
that
SDO
thing
in
front
of
it
right,
and
that
is
a
mesh
external
service.
B
So
I
wanted
to
kind
of
separate
out
those
two
things
and
still
considered
services.
For
the
purpose
of
this
talk,
we
are,
of
course,
going
to
talk
about
kind
of
what
is
a
mesh
internal
service.
How
do
we
add
an
outside
of
the
cluster
thing,
a
process
into
our
sto
control
plane,
so
the
demo
and
it's
going
to
be
set
up
kind
of
the
same
way.
This
is
just
a
simple
single
V,
PC
setup.
We
on
the
left
hand
side.
B
We
see
a
cluster,
a
gke
cluster
in
this
particular
case,
but
some
services
running
and
the
history
of
control
plane
runs
inside
of
the
GK
cluster
and
then
we
also
have
a
GCE
instante
compute
engine
instance,
which
is
just
a
virtual
machine.
That's
running
in
the
same
same
VM.
So,
let's
start
kind
of
on
the
lower
stack
in
the
routing
stack.
So
the
first
thing
we
need
to
ensure
that
the
VMs
can
talk
to
the
pods
right
just
at
the
IP
layer,
just
at
layer,
3
and
there's
a
number
of
ways.
B
We
can
do
that
inside
of
GC
P.
We
have
something
called
BBC
native
clusters,
which
means
that
the
pod
IPS
are
first
class
V,
PC,
IPs
and
then
VMI
peas
are,
of
course,
the
first
class
BBC
IV.
So
now
we
can
just
go
into
the
V
PC
firewall
and
just
make
sure
that
the
right
firewall
rules
exist.
So
the
VMI
piece
can
talk
to
the
pod
IPS,
and
then
we
ensure
that
the
VMS
know
about
that
pod
IP
range.
B
The
next
thing
we
need
to
do
is
since
this
is
a
service
and
every
service
must
have
an
identity
inside
of
kubernetes.
That
is
just
kind
of
done
automatically.
We
need
to
give
it
an
identity
explicitly
right.
So
inside
of
kubernetes,
every
service
gets
an
identity
using
kubernetes
service
accounts.
With
that
our
scope
to
do
that
namespace.
So
the
first
thing
we
need
to
do
is
say:
where
which
namespace
do
we
want
to
put
this
service?
And
it
doesn't
matter,
we
can
put
it
in
the
default.
B
Namespace
take
a
service
account,
get
its
credentials
its
certificates
and
then
hand
them
over
to
the
VM
alright.
So
those
are
the
two
things
that
the
VM
needs.
Now
we
need
to
create
a
service
inside
of
the
kubernetes
cluster
again
inside
of
kubernetes
cluster.
Everything
is
done
kind
of
automatically
by
just
interrogating
the
cube
API,
but
in
this
particular
case
we
need
to
explicitly
add
that
service
right,
so
sto
gives
us
a
CLI
tool
called
sto
CTL
and
using
this
SEO
CTL
register
command.
B
All
we
need
to
do
is
give
it
a
service
name
and
IP,
a
name
and
a
port,
and
what
that
results
in
that
looks
very
suspiciously
like
a
kubernetes
service
resource
right.
So
it's
a
service,
it
has
a
name,
it
has
a
cluster
IP
and
it
is
a
selector
less
service,
because,
most
of
the
time
when
we
create
a
service
in
kubernetes,
we
have
a
deployment.
That's
backing
that
service
that
has
endpoints,
which
are
the
pod
IP
addresses
this
particular
service.
It's
just
a
named
load
balance,
sir
there's
no
back
ends
to
it.
B
Yet
all
right!
So
that's
the
next
thing
we
need
to
do.
We
need
to
give
it
some
back
ends
again
in
kubernetes.
This
is
kind
of
done
automatically.
We're
kind
of
taking
is
kind
of
the
hard
way
as
Kelsey
would
say
so.
Seo
comes
with
another
custom
resource
called
a
service
entry.
When
we
create
a
service
entry,
we
refer
to
the
service
that
we
just
created
using
sto
cuttle
register
command.
B
So
if
you
look
about
three-quarters
of
the
way
down,
you'll
see
a
host
field
and
that's
the
service
that
we
just
created,
that
is
the
named
load
balancer
in
this
case.
It's
product,
catalog
service,
it's
in
the
default,
namespace
dot,
SVC,
twister,
dot,
local.
Now,
that's
in
the
DNS
scope
of
that
cluster
and
right
above
that
is
the
endpoint
section,
and
that
points
to
where
is
that
process
running?
How
do
I
get
to
that
process?
B
What
is
the
IP
and
that
IP
address
just
happens
to
be
the
IP
of
your
virtual
machine
and
then
you've
got
the
name
and
the
port,
obviously
the
G
RPC
and
the
port
number
all
right.
So
now
we
have
a
service
created
and
we
have
the
endpoints
inside
of
kubernetes,
let's
hop
over
to
the
VM
and
let's
see
what's
running
in
there,
and
we
all
know
that
we
need
to
at
least
run
that
sto
proxy,
the
Envoy
proxy
that
runs
there.
B
Something
needs
to
configure
that
proxy
and
the
issue
of
control
plane
needs
to
configure
that
proxy
know.
The
history
of
control
plane
is
running
across
inside
of
the
cluster,
the
proxy
sitting
outside
of
the
cluster.
So
we
need
to
make
sure
that
there's
a
way
for
them
to
communicate
to
each
other
all
right.
So
the
first
thing
inside
of
the
VM.
We
need
to
make
sure
that
there's
a
dns
name
for
a
pilot
to
make
sure
that
it
resolves
to
some
IP
address.
Now
we
don't
expose
pilot
outside
of
the
cluster.
B
It's
just
a
cluster
type
cluster
IP
type
service.
That's
running
inside
of
the
cluster.
We
use
a
the
ISTE
of
ingress
gateway
and
create
a
gateway
for
pilot
to
expose
it
out
the
ingress
gateway,
so
that
DNS
name
is
essentially
pointing
to
the
ingress
gateway,
IP
address
or
a
great.
So
now
that
proxy
can
talk
back
to
the
Asteria
control
plan.
It
can
talk
back
to
Pilate
and
Pilate
can
configure
do
all
the
routing
rules
in
all
of
that.
Another
piece,
that's
running
in
the
VM
is
called
a
node
agent.
B
The
node
agent
is
responsible
for
creating
the
certificate
signing
request
and
sending
them
to
Citadel.
Citadel
is
kind
of
the
certificate
authority
that
sits
inside
of
the
gke
cluster
inside
of
the
Sto
control
plane,
and
that
is
responsible
for
creating
the
certificates,
rotating
them
and
so
on
and
so
forth.
It
hands
them
back
to
the
node
agent
and
the
node
agent
installs
them
inside
VM
in
the
Etsy
search
folder
and
then,
of
course,
the
last
thing
that's
running
is
your
actual
process.
That's
your
actual
service
and
that
could
be
running
as
a
binary.
B
It
could
be
running
as
a
daemon
could
be
running
as
a
container,
which
is
what
we're
going
to
do
in
this
particular
case.
So
now
this
looks
a
lot
like
the
picture
that
Megan
showed
at
the
beginning,
where
we
had
two
services
running
inside
of
kubernetes
cluster
with
proxies
friend,
ended
both
services,
so
everything
was
kind
of
flowing
through
the
proxy.
Now
we've
kind
of
bootstrapped,
the
VM,
with
the
exact
same
kind
of
thing,
and
just
make
sure
that
the
networking
works
and
everything
is
looking
good
again
from.
A
B
A
Sounds
good
thanks,
Mary,
okay,
so
we
just
kind
of
ran
through
how
to
get
all
the
set
up.
What
I'm
going
to
show
is
this
whole
situation
in
action?
So
what
we've
actually
done
before
this
talk
is
set
up
a
kubernetes
cluster
and
a
VM,
and
we
have
done
all
of
the
install
steps
that
Amir
just
went
through
the
idea.
There
is
to
kind
of
bootstrap
the
environment
so
that
we
can
show
the
sort
of
unified
functionality
that
we're
all
sort
of
trying
to
get
to
in
the
end.
A
So
this
is
the
sample
app
that
we've
installed
on
our
environment.
So
what
we
have
here
is
a
multi
service
application
designed
to
mimic
a
retail
web
app
there's
a
front
end
through
of
that
we've
exposed
through
the
sto
ingress
gateway,
so
we'll
open
it
up
in
just
a
moment
and
then
there's
various
backends.
And
what
we've
done
here
is.
We
have
taken
one
back-end
product
catalog
and
we
have
taken
it
out
of
the
cluster
and
we
have
put
it
into
a
VM.
A
So
we've
literally
just
taken
the
docker
image
that
we
were
running
in
a
pod
on
the
cluster
and
now
we're
just
running
that
inside
the
VM
with
docker
run
so
designs
is
kind
of
yeah,
make
it
as
simple
as
possible,
and
what
I'm
gonna
show
here
is
just
like
the
baseline
setup.
So
we
don't
have
any
policies
deployed
yet
no
rules.
So,
okay,
can
everyone
in
the
back
see
this?
Okay,
if
I
run
a
command,
can
you
read
the
text
or
should
I
make
it
bigger?
Okay,
I'm
seeing
thumbs
up
sweet
okay.
A
A
So
we've
installed
this
do.
This
is
just
three:
these
are
all
those
control
plane
components
we
were
talking
about,
so
we
have
pilot
for
traffic
and
we
have
Citadel
for
security
and
all
those
things
and
then
into
the
default
namespace.
We
have
setup
this
sample
application,
you'll
notice,
there's
a
bunch
of
services.
A
We
can
see
here
two
out
of
two
means
that
we
have
two
containers
running
in
the
pod,
and
one
of
them
is
the
app
one
of
them
is
Envoy
and
then
you'll
notice
that
project
catalog
is
missing
from
the
list.
That's
again
because
we've
taken
it
out
of
the
cluster
and
we've
put
it
in
the
VM
okay
yo.
So
this
is
pods.
If
we
run
get
services,
we
can
see
that
we
actually
do
have
product
catalog
in
the
list.
A
So
if
you
remember,
when
Amir
was
talking
about
that,
SD
of
CTL
register
command
and
the
selector
list
service
that
we've
got
that's
what
this
is
here.
So
we
have
a
cluster
IP
service.
Our
product
catalog
service
is
going
to
run
it's
a
G
RPC
service
on
port,
three
five,
five
zero
and
we
also
have
that
service
entry.
So
we
have
the
service
for
DNS
and
then
to
actually
resolve
to
the
IP
import
of
the
VM.
A
We
have
this
service
entry
called
product,
catalog
service,
corresponding
to
that
coop,
DNS
long
name
for
the
service
mesh
internal
and
what?
If
we
actually
look
at
the
yamo
file?
For
that?
What
we
can
see
is
yeah,
it's
called
product
catalog,
and
this
is
the
IP
address
of
the
VM.
So
again,
there's
kind
of
reviewing
that
the
setup
Amir
was
going
through
before
so
this
is
what's
happening
on
our
cluster.
If
we
go
over
here
to
the
other
tab,
we're
actually
SSH
into
the
VM.
This
is
just
a
compute
engine.
A
A
So
we
can
see
it's
active,
it's
running,
it's
running
with
system
D,
and
we
can
see
here
that
when,
when
the
proxy
starts
up,
there's
this
ISTE
of
start
script,
which
configures
the
IP
tables
in
this
case
here
to
intercept
all
inbound
traffic
coming
in
on
localhost,
and
if
we
exit
out
that
we
can
also
see
that
the
node
agent,
which
is
the
thing
that
renews
that
certificate
signing
request
with
Citadel,
that's
also
running
and
yeah.
It's
we're
kind
of
zoomed
in
here,
but
yeah
ideas.
A
This
is
going
to
be
what's
refreshing,
our
certificates,
okay
and
then.
Lastly,
we
have
our
actual
service
that
product
catalog,
docker
container
running
we've
exposed
the
port
and
yeah.
That's
that's
kind
of
what's
going
on
here.
The
last
thing
I'll
show
is
across
the
whole
mesh,
so
pods
and
VMs
I
have
enabled
envoy
access,
logging,
thristy,
oh,
and
so,
when
I
press
enter
here,
we're
gonna
see
a
whole
bunch
of
logs.
A
Hopefully-
and
this
is
actually
the
access
logs
coming
in
from
the
front
end
of
our
application
into
profit
catalog
this
10.40
2.7,
that's
actually
the
Pali
of
the
front
end.
So
that's
what
the
source
of
the
traffic
and
then
the
destination
is.
This
is
the
actual
IP
of
the
VM,
so
I
like
to
turn
on
access
logging,
because
it
lets
me
know
if
things
are
actually
working
and
going
through
the
proxy.
A
Sometimes
things
don't
if
I
have
not
set
it
up
correctly
and
then
the
last
thing
I'll
show
here
on
the
VM
is
the
Etsy
host.
So
Amir
was
talking
about
how
sorry
for
all
these
added
by
Google's.
Let's
grow
up,
so
Amir
was
talking
about
how
it's
probably
never
a
good
idea
to
directly
expose
pilot
or
Citadel
those
sto
control,
plant
components
outside
of
your
cluster
for
security
and
potentially
obvious
reasons.
A
So
what
we're
doing
here
is
we're
configuring,
Etsy
host
and
you
can
use
DNS
mask
or
some
other
tool
to
do
this,
but
so
that
when
the
Envoy
calls
a
co-pilot
that
resolves
to
the
ingress
gateway
of
our
kubernetes
cluster,
which
is
a
public
IP,
you
can
use
an
ilb
and
then
turn
a
load
balancer
to
do
this
if
you're
in
same
network.
This
is
a
public
IP
address
just
for
the
purposes
of
this
demo.
A
So
the
key
thing
to
note
here
is
that
traffic
that
has
to
go
from
envoy
in
the
VM
to
the
control
plane
on
the
cluster
is
going
to
go
through
the
ingress
gateway
running
on
the
cluster.
There
are
data
plane,
traffic,
so
traffic
that
goes
directly
from
the
front-end
to
product
catalog
that
can
go
direct
papi
directly
into
the
VM,
which
we
saw
on
the
access
log.
A
A
Actually,
ok,
here
the
front
end
running
and
serving
a
list
of
products
as
if
everything
we're
running
in
kubernetes,
just
by
default,
this
list
of
products
is
being
served
from
the
VM
and
that's
what's
generating
all
this
access
logs
we
just
saw,
and
then
we
also
have
the
key
le
service
graph,
showing
the
relationships
between
all
the
services
in
our
cluster
and
on
our
VM.
So
if
we
scroll
in
a
little
bit
here,
what
we
can
see
is
that
traffic
from
both
front
end
and
recommendation
service
is
going
into
product.
A
Catalog
service
triangles
in
key
ally,
represent
kubernetes
services
and
these
little
I
guess
it's
a
hexagon
is
that
six
sides
that
resent
that
represents
an
internal
service
entry.
If
we
click
on
that
this
is
that
same
yellow
file
we
were
showing
before
the
idea
here
is.
We
have
registered
a
VM
so
that
it's
part
of
our
mesh
just
like
a
pod,
that's
kind
of
the
key
thing
to
know.
We
can
see
metrics
for
it
again.
It's
this
consistency,
piece
for
observability
that
we
really
want
to
bring
home
here.
A
Ok,
so
we
just
went
through
the
process
of
install
and
seeing
what's
going
on
in
our
environment,
let's
actually
apply
some
rules
and
policies
across
our
pods
and
our
VMs
to
really
see
the
sto
functionality
in
place.
So
the
first
thing
I'm
going
to
do
here
is
encrypt
all
the
traffic,
so
mutual
TLS
is
a
way
to
you
know:
encrypt
traffic
between
services.
Sto
has
a
pretty
easy
way
to
do
this.
A
Using
a
mesh
policy
and
what
I'm
going
to
do
is
actually
enforce
em
TLS
across
the
entire
mesh
across
all
namespaces,
and
this
will
apply
because
we've
registered
our
VM
to
the
mesh.
This
will
apply
to
product
catalog
as
well.
Even
though
it's
running
in
the
VM
and
the
services
don't
know
because
the
envoys
handling
the
MT
LS
everything
with
the
services,
all
the
traffic
will
work
the
same
way.
Ok
demo,
so
SDF
CTL
is
actually
a
really
functional
tool.
It
has
a
ton
of
commands.
A
We
we
saw
it
being
used
to
register
the
VM
into
the
mesh.
What
we're
using
it
for
here
and
sorry
there's
a
whole
lot
of
output
is
we're
running
this
authentication
TLS
check
on
one
of
our
services
and
it's
printing
out,
all
of
them,
which
is
ok
and
we
can
see
here
in
the
output.
The
key
thing
to
note
is
that
on
the
client
side
and
this
Riverside,
all
of
our
traffic
to
start
is
plain
text.
It's
unencrypted
says
HTTP,
it's
here.
It's
actually
G
RPC
for
most
of
these,
but
you'll
know
here.
A
A
Luckily,
in
this
tio
1.4
and
in
the
future,
you
will
no
longer
need
two
resources.
You'll
just
need
one,
but
we
didn't
have
time
to
upgrade.
So,
let's
apply
these
gamma
files.
Great
now,
we
have
should
hopefully
have
MPLS
traffic
for
all
of
our
services
across
the
whole
mesh.
We're
gonna
run
that
same
TLS
check
command,
and
we
can
see
here,
MTL,
sm,
TLS,
client-side,
server
side
we're
all
set
to
go
if
we
open
up
backup
key
Olly
and
if
we
display
the
security
view.
Sometimes
it's
it'll
show.
So
this
is
time
windowed.
A
B
Awesome,
thank
you.
So
what
Megan
showed
you?
Actually?
Let
me
just
go
to
this
slide,
so
we
can
kind
of
have
a
picture
of
what
what
we
just
did
right
so
right
now,
one
of
the
services
is
completely
running
outside
of
the
cluster
100%
of
the
time.
This
is
great.
Another
thing
we're
starting
to
see
is
this
use
case
of
modernization
which
is
I
want
to
take
this
monolith
and
I
want
to
start
slowly
chipping
it
away
and
start
container
izing
everything
that
we've
heard
in
the
last
three
days
in
keynotes
and
stuff.
B
B
What
I
was
talking
about
at
the
very
beginning,
in
terms
of
how
is
Josie
is
a
service
service
is
just
a
DNS
name
and
it
decides
how
to
route
to
a
process
right
so
I'm
going
to
quickly
show
you
how
to
do
that.
So,
let's
go
back
to
the
CLI.
So
the
first
thing
I'm
going
to
do
is
I'm
just
going
to
run
another
product,
catalog
service
and
a
deployment
on
GK
cluster.
B
Alright,
so
all
I've
done
is
created
just
a
plain,
vanilla
deployment
and
a
service,
and
if
we
look
at
all
the
services
now
now
you'll
notice
that
we
have
two
product
catalog
services
running
the
first
one
is
the
original
one.
That's
the
one
that's
running
in
the
VM,
that's
been
up
since
for
nine
days,
and
it
has
a
cluster
IP
and
everything.
The
second
one
named
product
catalog
service,
GK
II,
is
running
on
the
GK
cluster,
and
that
was
created
seven
seconds
ago.
B
If
you
look
at
the
endpoints
of
these
services
again,
we
should
see
two
endpoints
now,
the
first
one,
the
product
catalog
service,
is
pointing
to
the
VM
IP
address,
but
nope
for
nine
days.
You've
seen
that
and
then
the
second
one
is
running
as
a
pod
or
as
a
deployment
inside
of
the
kubernetes
cluster,
and
that
has
a
pod
IP
here
as
well.
B
Now
history
provides
yet
another
custom
resource
called
a
virtual
service,
so
you
can
think
of
a
virtual
service
as
a
route
rule,
and
you
can
encapsulate
multiple
resources:
multiple
kubernetes
resources,
inside
of
a
virtual
service.
So
let's
quickly
apply
that
on,
shall
I
apply
it
first
and
then
I
can
we
can
inspect
what
that
is
doing.
So
here's
a
virtual
service,
it
picks
a
name
which
in
this
case,
is
product
catalog
service
and
then
decides
how
to
route
that
particular
service,
which
is
done
here
in
this
route
section.
B
In
this
case
we
have
given
it
to
destinations
the
first
one
is
product
catalog
service,
gke,
so
think
of
that
as
one
of
the
backends
to
that
DNS,
hostname
and
we've,
given
it
a
weight
of
90,
which
is
like
90%
of
the
traffic,
goes
to
that
and
then
the
second
one
is
our
original
product
catalog
service,
running
on
the
VM
and
we're
using
10%
of
the
traffic
to
that.
So
if
we
switch
back
to
our
service
graph
in
key
Ollie.
B
What
we
should
start
seeing,
I'm
just
going
to
zoom
in
on
the
product
catalog
service,
you
see
that
there
are
two
product
catalog
services.
This
is
the
the
Pentagon
one
is
the
original
product,
catalog
service,
that's
the
internal
service
entry
and
then
now
we
have
this
triangle,
one
which
is
running
inside
of
uber
Nettie's
as
just
a
service
as
well,
and
then
recommendation
service
is
one
of
the
services.
That's
sending
traffic
to
product
catalog
service,
and
you
can
see
the
split
is
almost
ninety
ten,
which
is
the
one
that
we
want,
is
to
kind
of.
B
Does
a
slow
move
to
that.
So
this
is
something
that
you
would
add
to
your
CD
pipeline.
If
you're
migrating
stuff
over,
you
can
slowly
start
to
migrate
at
certain
percentages,
you
can
start
measuring
the
metrics.
Make
sure
that
everything
is
running
good
before
you
kind
of
move
everything
over
so
another
good
use
case.
Everything
was
done.
Declaratively
we
didn't
have
to
do
anything
with
with
the
BMS,
so
I'm
gonna
hand
it
back
to
Megan
to
close
this
out.
A
So
the
real
power
of
a
virtual
service
rate
is
that
you
can
have
it
apply
to
different
kubernetes
host
names
and
in
our
case,
because
of
the
way
we've
rigged
up
our
vm
service
to
a
service
entry,
we
did
have
to
use
two
separate
services
for
our
pod
and
our
VM,
but
with
a
virtual
service
we
were
actually
able
to
really
quickly
do
a
migration
slowly
with
the
same
policy.
So
yeah,
that's
that's
one
best
practice.
The
other
was
the
order
in
which
we
took
the
demo,
so
you'll
notice
that
we
started
with
observability.
A
Then
we
did
security,
and
then
we
did
traffic
generally.
When
we
talked
to
you
users
a
lot
of
the
time,
it's
like
I
I
want
to
adopt
a
CEO.
Just
so
I
can
know
what's
happening
in
my
apps
and
the
moment
of
opening
up
that
key
Olly
service
graph
for
something
like
a
two
hundred
micro
service
application
can
really
kind
of
be
like
a
light
bulb
moment.
A
There
are
different
ways
you
can
do
it
with
an
ILB
or
an
ingress
gateway
which
we
showed
in
our
installation.
So
with
that
these
slides
and
the
demos
we
use
today
are
pushed
to
github
and
on
the
inter
Nets.
We
also
have
Docs
and
samples
for
you
to
use
and
yeah
I'll
pause
on
the
slide
for
just
a
second
one
thing
to
note
is
that
the
sto
community
is
really
working
hard
to
make
this
process
easier.
So
all
of
these
different
commands
we
were
talking
about
and
all
these
resources
that
you
need.
A
We
recognize
it's
not
zero
effort.
So
in
the
future,
this
process
is
probably
going
to
get
a
whole
lot
easier
so
that
you
can
really
automate
adding
a
lot
of
staple
services
to
your
mesh.
If
you're
interested
in
collaborating
on
that
whole
process
and
reporting
how
things
are
working
for
you,
we
would
love
it
if
you
could
join
the
SCO
environments
working
group.
Those
meetings
love
to
have
you.