►
From YouTube: Istio 1.7 improved VM support part 1
Description
A service mesh is only as valuable as the number of workloads it manages! In this video we see how to extend the service mesh to include VM based workloads and how Istio 1.7 brings new capabilities for bootstrapping identity and making the VM services a first-class citizen in the service mesh.
A
So
if
we
come
back
here
and
look
at
the
release
announcement
for
1.6,
we
can
see
that
there
was
this
workload
entry
resource
that
was
that
was
added
and
this
workload.
Entry
resource
allows
us
to
capture
the
details
about
a
specific
vm
and
treat
it
as
a
first-class
citizen
with
the
rest
of
the
services
in
the
mesh
that
might
run
in
kubernetes.
A
So
we're
going
to
build
on
that
and
what
we're
going
to
look
at
specifically
is
the
bootstrapping
process
of
getting
the
istio
sidecar
running
on
a
vm
and
using
some
of
the
new
features
in
istio
1.7.
Specifically,
here's
the
release,
notes
before
it's
actually
published
here,
how
we
can
bootstrap
the
identity
of
the
vm
from
a
service
account
that
runs
inside
of
kubernetes.
A
So
we
can
use
this
token.
It's
a
short-lived
token,
give
it
to
the
sidecar
basically
and
you
let
it
connect
up
to
the
istio
control
plane
and
use
that
identity
that
comes
from
a
service
account
in
kubernetes
to
ultimately
get
issued
its
certificates
and
and
connect
up
to
the
rest
of
the
service
mesh.
A
We
will
have
a
page
that
looks
like
this
and
that
will
walk
you
through
these
different
steps,
and
so
what
I'm
going
to
demo
to
you
is
based
on
the
the
steps
that
we
see
here
so
so,
for
example,
here
we're
getting
the
token
from
that
server
for
that
service
account
we're
grabbing
the
root
ca
for
sdod
and
and
setting
up
the
rest
of
it.
So
let's
go
ahead
and
take
a
look
at
our
demo
here.
A
First
thing:
we're
going
to
show
is
our
kubernetes
cluster,
so
we
do
have
sdo
1.7
running
here.
In
our
kubernetes
cluster,
we
also
have
services
that
are
injected
with
the
istio
sidecar
running
in
the
default
namespace
here
so
part
of
the
demo.
Getting
this,
the
vm
functionality
in
place
is
to
connect
up
to
a
vm
which
we'll
do
here
running
in
gke
and
start
to
go
through
the
steps
that
were
outlined
in
that
dock,
and
actually
we
have
a
tmux
session
here
right,
yeah,
all
right,
so
this
is
our
vm.
A
Now
what
we're
going
to
do
is
in
this
demo
we're
going
to
first
we're
going
to
prepare
the
namespaces
for
our
demo
here.
Let's
take
a
look
at
it.
Actually,
so
what
we're
doing
here
is
we're
going
to
create
the
namespace
where
we
want
to
store
the
record
of
the
the
vms
that
we're
using,
and
we
also
want
to
create
a
service
account
that
will
ultimately
be
the
source
of
identity
for
the
services
that
run
inside
of
the
vm.
So
we
created
this
namespace
created
this
service
account.
That's
all
good.
A
The
next
thing
that
we
want
to
do
is
create
the
bootstrapping
file,
so
this
includes
the
token.
This
includes
the
root
ca
and
some
of
the
environment
variables
that
we'll
we'll
need
here.
So
if
we
look
at
our
work
folder
here,
we
we
have
a
couple
of
helper
scripts
that
we'll
take
a
look
at
that
in
a
second.
But
what
we
have
here
in
that
we
that
we
generated
was
basically
like,
I
said,
the
root
search.
A
A
This
is
that
short-lived
token,
that
was
generated
from
the
token
review
api
in
kubernetes,
based
on
the
service
account,
and
we
have
a
few
other
environment
variable
based
things
here,
so
what
we
want
to
do
with
that
set
of
files.
If
we
look
at
it
again,
what
we
want
to
do
with
this
set
of
files
is
transfer
these
files
over
to
the
vm,
because
this
is
what's
going
to
be
used
to
bootstrap
the
the
environment
and
the
sidecar
and
onboard
proxy.
A
A
A
So
now
we
have
our
files
here
same
files
that
we
just
took
a
look
at
earlier.
The
first
thing
that
we're
going
to
do
is
we're
going
to
run
this
prep
vm
script
that
I
have
here
and
what
this
is
going
to
do
is
basically
put
the
certificate
and
the
token
in
the
correct
location
on
the
vm
so
that
the
proxy
sidecar
can
find
it
we'll
install
it
here.
We
can
see
we're
using
istio,
1.7
release
candidate,
3,
we'll
install
the
proxy
and
then
finish
setting
up
some
of
the
other
variables
again.
A
A
A
Give
that
a
second
all
right
that
looks
good
installed,
the
sidecar
installed
the
environment
variables
and
the
certificates
and
so
forth.
Okay,
that
looks
good
now.
If
we
look
in
our
list
of
services
that
are
running
on
or
available
to
run
on
this
particular
vm,
we
should
see
the
istio
service
here.
I'm
not
sure
why
it's
in
a
failed
state,
let's
continue
with
the
demo
and
see
if
that
sorts
itself
out.
A
A
If
we
want
to
tail
the
logs,
we
can
run
but
run
this
command,
and
we
see
some
things
have
happened.
The
logs
have
come
up.
We
can
even
take
a
look
at
the
error.
Log
and
take
a
look
to
see,
looks
like
we
had
some
trouble
connecting
to
the
xds
for
some
reason,
but
let's
continue
on
with
the
demo
we'll
see,
I
think
it
actually
did
connect.
I
think
it
either
just
from
a
previous
run
or
installed
for
a
second,
but
it
should.
A
If
I
look
at
the
dns
mask
file
here,
the
most
important
part
is
this:
where
we're
going
to
try
to
resolve
the
service,
the
cluster.local
domain
names
and
we'll
return
this
this
ip
address,
also
always
which
happens
to
be
the
the
sitter
range
for
the
kubernetes
services
that
get
created
so
just
to
verify
that
let's
come
over
here.
Let's
look
at
the
service.
A
These
are
10.44.
whatever
right.
So
that's
what
we
got
into
the
dns
mask
to
make
that
work,
and
so
that
should
be
good.
The
next
thing,
the
last
thing
that
we
want
to
see
is
that's
the
envoy
is
running
and
it
is
running
so
that
looks
good
and
then
part
of
the
magic
of
istio
and
the
running
side.
Car
is
redirecting
the
traffic,
whether
that's
inbound
or
outbound,
from
this
bm
through
the
proxy
right.
So
we
do
expect
tables,
look
at
the
nat
table.
A
So
it
means
the
proxy
was
able
to
connect
up
to
the
control
plane
that
if
we
take
a
look
at
bar
run
secrets,
it's
still,
I
believe
we
can
see
that
we
were
able
to
connect
up
to
the
control
plane.
We
were
able
to
get
configuration
dynamically.
So
we
can.
We
know
about
the
http
pin
services.
We
also
were
able
to
generate
keys
and
workload
certificate.
A
So
if
we
do
curl
localhost
search,
we
can
see
that
the
certs
were
all
set
up
correctly,
using
that
that
short
lived
token
and
things
look
to
be
as
though
they're
in
a
good
shape
here.
If
we
try
to
do
a
curl,
we'll
do
attach
v,
just
in
case
things
go
wrong,
you
should
be
band
dot,
the
default
service.cluster.
A
local,
I
believe
that's
on
8,
000
and
headers.
If
we
call
this
from
the
vm,
we
should
get
the
expected
response,
which
is
the
http
bin
response,
and
you
can
see
that
it
is
using
the
spiffy
identifier
of
this
vm,
which
we
set
up
once
the
sidecar
was
installed
and
communicated
with
the
pro
with
the
control
plane
got
it.
A
Now
this
videos
actually
got
a
little
longer
than
I
thought
it
would
so
we're
going
to
stop
here
and
in
the
next
video
we'll
take
a
look
at
running
a
service
on
the
vm
and
then
from
the
service
mesh.
The
rest
of
service
mesh,
we're
going
to
call
into
this
vm,
and
you
should
see
that
the
mechanism
of
the
you
know
making
calls
to
services
within
the
mesh
is
the
same,
and
it's
consistent,
whether
you're
on
the
vm
or
whether
you're
in
the
service
mesh
so
stay
tuned
to
the
next
video.