►
From YouTube: Istio Beyond Kubernetes - Zack Butcher, Tetrate, Sven Mawson, Google & Pratima Nambiar, Salesforce
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Istio Beyond Kubernetes - Zack Butcher, Tetrate, Sven Mawson, Google & Pratima Nambiar, Salesforce
Istio can be used to build a service mesh spanning heterogeneous infrastructure. This presentation will describe three use cases that use Istio to power a mesh spanning a variety of infrastructures. We will start by covering two similar examples of Istio spanning kubernetes and VM infra (EKS-EC2 as well as EKS-on-prem), followed by the Salesforce Service Mesh that supports services running on bare metal, VMs and Kubernetes. We'll cover what those deployments achieve, and spend a lot of time describing how they work and the tradeoffs made to enable them.
A
A
It
has
has
kind
of
always
been
tied
to
kubernetes,
at
least
in
people's
minds,
and
but
that's
not
actually
the
case
in
production
right
and
what's
more
most
of
our
production
footprints
are
not
only
kubernetes
right
and
so
there's
a
real
need
for
for
taking
the
surface
mesh
beyond
just
kubernetes
itself,
and
today
I'm
really
excited.
We
have
a
phenomenal
crew
here
to
kind
of
talk
through
some
of
how
we
do
that
and
how
we've
seen
that
hands-on.
C
A
Yep,
awesome
and-
and
so
today,
I'm
gonna
start
off
and
I'm
gonna
talk
about
some
patterns
that
that
we've
seen
for
taking
issue
beyond
kubernetes,
for
these
actually
come
out
of
kind
of
two
customers
that
I've
worked
with
very
closely
to
help
achieve
these
the
plans
in
production
and
then
after
that,
we'll
dive
into
kind
of
two
more
excellent
case:
studies
from
both
salesforce
and
and
google.
That
really
are
applying
a
very
similar
set
of
patterns
here.
So
without
further
ado.
A
You
know
like
openshift,
that
you're
running
locally
right,
but
the
particular
customer
that
I
worked
with
through
through
this
scenario
of
bridging
eks
and
ec2
environments.
Kind
of
took
this
migrate.
Then
modernized
strategy
of
hey,
let's
get
everything
into
cloud,
so
we
can
shut
down
the
data
center
and
then
we're
going
to
work
incrementally
within
our
applications
to
modernize
them
piece
by
piece
right
and
as
they
were
looking
at
this
problem
set
for
them.
A
A
Those
two
kind
of
go
hand
in
hand
really
beyond
that.
They
needed
fine
grain
load
bouncing
and
I'll
talk
about
that
a
little
bit
and
then
one
of
the
other
big
use
cases-
and
this
is
one
that
I
see
all
the
time
in
in
this
idea
of
kind
of
bridging
heterogeneous
environments-
is
controlling
how
traffic
flows
to,
for
example,
the
legacy
monolith
and
the
newer
microservices
that
are
being
decomposed
out
of
that
monolith.
A
And
so,
if
we
look
here
at
this
at
this
picture,
to
start
with,
you
know,
maybe
we
have
eks
and
ec2
the
import.
One
of
the
important
kind
of
underpinnings
here
is
that
we
have
a
common
certificate
authority
and-
and
this
will
be
a
pretty
common,
I
think,
trend
across
all
three
of
ours.
We
need
that
common
ca
to
facilitate
communication
right
and
so
that'll
live
somewhere
kind
of
outside
the
mesh
in
general.
A
I
would
recommend
strongly
that
you
root
your
meshes
root
of
trust
in
your
existing
pki
and
we're
going
to
have
an
istio
deployed
and
it
is
going
to
be,
and
it's
going
to
manage
kind
of
all
the
envoys
nearby.
In
this
case
you
know.
Maybe
this
is
a
single
az,
for
example,
and
so
we
can.
Those
ec2
instances
are
close
enough
to
that
istio
that
they're
going
to
have
roughly
a
shared
bait.
We
want
to
align
our
failure
domains
here.
A
Right,
nsu
is
going
to
program
everything
like
normal,
with
the
exception
of
some
service
discovery,
information,
we'll
dig
into
a
little
bit
here,
and
so
now.
What
I
want
to
kind
of
start
to
pick
through
here
is
how
a
deployment
like
this
starts
to
facilitate
traffic
flow
and
achieve
kind
of
some
of
these
four
needs.
A
That
envoy
can
have
you
know
a
static,
dns
name,
a
static
ip
address,
for
example,
so
you
don't
necessarily
need
to
execute
service
discovery
on
it,
but
you
do
get
some
of
the
nice
kind
of
control
that
envoy
gives
as
traffic
flows
into
these
vms
and
in
particular,
one
of
the
big
things
that
this
lets
us
do
is
split
traffic
as
we're,
for
example,
decomposing
that
application.
That's
that's
on
a
vm
and
as
we
split
that
traffic,
you
know
that
can
go
to
different
places
that
can
go
maybe
to
a
different
cluster.
A
Maybe
that
can
go
all
the
way
to
a
different
site
or
a
different
region,
and
this
is
one
of
the
things
I
that
we'll
kind
of
talk
about
as
we
circle
back
at
the
end.
But
isio
gives
us
this
this
set
of
tools
for
solving
problems
and
we
can
reuse
them
to
solve
many
similar
problems,
so
controlling
traffic
split
across,
for
example,
a
vm
deployment
and
kubernetes
deployment
looks
very
similar
to
controlling
traffic
across,
for
example,
sites
as
failing
over
for
for
disaster
recovery,
and
so
this
is.
A
This
is
one
way
hey.
You
know
we
can
go
in
through
these
front
envoys,
but
there's
other
ways
that
we
can
start
to
wire
this
up
and
how
you
ultimately
choose
to
use
the
tools
that
seo
provides,
is
going
to
depend
on
your
site
and
so
for
this
particular
customer
that
I
worked
with.
They
actually
had
an
existing
legacy
service
discovery
system.
It
was
based
on
on
zookeeper,
I
think
actually
we'll
hear
about
salesforce,
and
then
they
have
a
very
similar
system.
A
A
You
know
we
had
to
do
this
kind
of
bespoke
in
their
sites
because
they
had
a
homegrown
service
discovery
system
as
you're
starting
to
use
like
different
cloud
providers
that
are
that
are
starting
to
provide
different
service
discovery
mechanisms.
Chances
are
pretty
decent
that
there
are
already
some
integrations
around
right,
so,
for
example,
ec2
populates,
a
cloud
map
registry
for
service
discovery
and
and
seo.
There
are
plugins,
for
example,
to
push
that
data
into
seo.
A
So
this
isn't
necessarily
something
you
have
to
build
yourself,
but
this
is
a
totally
valid
way
to
set
things
up
and
and
one
that
we
see
a
lot.
We
have
folks
running
in
production.
Doing
you
know
direct
pod
to
vm
connectivity
in
this
in
this
way
and
then,
of
course,
for
for
vms
that
we
might
actually
enroll
into
the
mesh
and
when
I
say
enroll
into
the
rest,
what
I
mean
is
deploy
a
sidecar
there
and
that's
another
important
idea.
A
I
want
people
to
understand
you,
don't
necessarily
have
to
have
a
sidecar
deployed
there,
it'll
change
your
security
model,
but
you
can
get
some
benefits
from
just
having
kind
of
this.
This
doorway
issio
ingress
gateway
as
well,
but
when
we
do
have
an
envoy
on
that
vm,
we
can
use
some
of
istio's
new,
auto
registration
capabilities.
A
I
think
some
of
them
will
talk
about
that
later
to
know
exactly
where
that
that
vm
is
where
it
lives
in
istio
and
enable
that
direct
communication
without
having
to
do
the
kind
of
life
cycle
events
off
to
the
side,
and
so
you
know
looking
at
these,
we
can
there's.
You
know
some
easy
ways
that
we
can
facilitate
traffic
flow.
We
might
pick
different
ones
based
on
our
requirements
and
they
give
us
these
other
capabilities.
A
They
have
legacy
data
centers
where
they
run
applications
and
they
run
those
in
a
mix
of
vms
and
and
kubernetes
as
well,
and
they
have
a
cloud
footprint
too,
and
their
first
two
requirements
were
identically.
The
same
I
need
to
encryption
and
transit.
I
need
consistent
access
policy
again
their
financial
services
company-
it's
it's
incredibly
important,
but
then
they
and
and
they
had
that
same
kubernetes
to
vm
within
a
single
site
right
that
right
side
picture
is,
is
identical
to
before.
A
However,
they
had
the
additional
requirement
that
they
needed
to
be
able
to
fail
across
sites,
for
example,
for
for
disaster
recovery,
as
well
as
the
need
to
to
burst
into
cloud
for
additional
compute
capacity
for
for
them.
They
have.
Very
you,
know,
time
of
day
driven
traffic
patterns,
for
example,
and
the
need
to,
and
so
you
know
for,
for
certain
events
like
market
open
market,
close
those
kinds
of
things,
there's
a
lot
more
traffic
and
so
the
ability
to
burst
into
and
not
run
over
provisioned.
A
All
the
time
is,
is
absolutely
massive,
and
if
we
look,
you
know
I'll
take
kind
of
that.
That
first
example
we
have.
You
know
we
have
or
I'll
take
one
of
the
examples
I
dove
into
before,
where
we
have
traffic
coming
in
and
we
want
to
control
how
that
flows
across,
for
example,
a
vm
and
a
kubernetes
cluster.
A
Today
there
are
some
different
deployment
topologies
you
can
use
with
less
sdods
here,
for
example,
and
and
things
like
that,
but
regardless
of
of
which
deployment
topology,
you
pick
you
are
going
to
have
to
solve
how
you
start
to
synchronize
configuration
across
different
clusters
and
there's
a
whole
bunch
of
different
options.
There.
B
Thank
you
zach.
If
you
can
move
on
to
the
next
slide,
yeah
salesforce
and
service
mesh
spans
multiple,
well
service,
spans
services
that
run
on
divers
infrastructure.
For
example,
in
our
first
party
data
centers,
we
support
services
that
run
on
bare
metal,
communicating
with
services
running
on
kubernetes.
B
Let's
take
a
closer
look
at
what
our
mesh
platform
with
istio
as
our
control
plane
looks
like
we
run
sgod
on
kubernetes,
which
is
the
control
plane
and
community
services
inject
sidecar
and
communicate
with
the
control
plane
for
config
updates
and
policy
updates.
We
have
a
config
webhook
that
generates
some
sdconfig
for
our
services
and
salesforce
requires
us
to
use
an
internal
ca
for
short-lived
certificates,
so
we
configure
both
our
control
plane
and
our
sidecar
to
use
these
certificates
generated
by
our
internal
ca
for
mtls.
B
B
We
also
configure
a
sidecar
resource.
It
is
a
custom
crd,
that's
available,
that's
provided
to
us
by
istio,
and
we
configure
ingress
and
egress
listeners
at
that
special
ip
via
that
sidecar
resource
and
then,
as
I
mentioned
before,
the
monolith
announces
to
zookeeper
and
that
gets
synchronized
to
kubernetes
as
service
entry
objects,
and
that
is
how
our
bare
metal
service
is
able
to
participate
in
the
mesh
as
if
it
were
running
on
kubernetes
the
next
slide.
Yeah.
B
For
example,
there
is
a
workload
group
crd
that
enables
you
to
specify
the
properties
of
a
workload
for
bootstrapping
it
and
as
a
template
for
workload
entries
it's
kind
of
similar
to
how
you
you
can
use
a
deployment
object
in
kubernetes
to
define
the
properties
of
workloads
via
a
pod
spec,
a
workload.
Entry
crd
represents
a
single
workload
similar
to
a
pod
in
kubernetes
and
and,
as
I
mentioned
before,
the
service
entry
is
similar
to
a
kubernetes
service
object
for
non-kubernetes
workloads.
B
B
Entry
object
that
we
talked
about
similar
to
how
a
pod
is
created
in
kubernetes,
and
then
you
can
choose
to
create
pre-create
the
service
entry
object,
but
we
create
that
service
entry
object
via
a
config
web
hook
which
listens
for
those
workload
entries,
so
we
don't
have
to
pre-create
it
and
that
is
kind
of
how
we
hope
to
adapt.
We're
in
the
process
of
adopting
the
auto
registration
feature
so
that
we
can
get
rid
of
that
zookeeper
that
we
run
today.
B
B
The
sidecar
can
be
used
to
resolve
dns
entries
of
any
mesh
service.
For
example,
a
non-kubernetes
workload
can
refer
to
a
kubernetes
workload
with
the
kubernetes
dns
name.
We
use
this
feature
today
to
resolve
services
running
on
different
kubernetes
clusters
as
part
of
our
multi-cluster
mesh
support,
and
we
will
be
using
that
for
non-kubernetes
workloads
as
well.
B
C
All
right,
thank
you,
pratima
and
thanks
zach
for
the
the
introduction
there,
so
I'm
gonna
just
really
briefly
touch
on.
Actually
a
lot
of
the
same
kind
of
stuff
you'll
see
a
lot
of
similar
patterns
here,
just
like
just
like
salesforce,
google
is
running
services
in
on-prem
data
centers,
as
well
as
in
cloud.
The
the
group
I'm
going
to
talk
about
here
really
is
google's
internal
corporate
engineering
team.
That
builds
and
runs
a
lot
of
our
internal
services.
C
B
C
All
this
pandemic
stuff
happened,
so
we
run
applications
these
corporate
applications,
both
on
cloud
and
on-prem
and,
in
both
cases
we're
using
the
service
mesh
for
kind
of
all
the
stuff
that
everyone
uses
service
mesh
for
right,
so
the
micro
segmentation
of
the
application
layer.
So
you
don't
need
to
do
network
firewalls
operations
management,
the
encryption
requirements.
You
know
that
zach
was
talking
about
for
financials.
Google
has
the
same
sort
of
encryption
requirements
on
everything
and
on
just.
C
C
B
C
Of
of
vms
and
containers
and
serverless,
we
kind
of
use
everything
and
we
want
them
all
to
be
able
to
talk
to
each
other
and
to
talk
to
the
services
running
either
on-prem
or
actually
in
our
production
environment.
Now.
So
we
sort
of
need
everything
to
be
able
to
talk
to
everything
and
and
istio
is
a
big
help
there.
C
So
for
our
our
on-prem
environment,
we
have
basically
the
same
stuff.
Actually,
so
we
have.
You
know
this
mix
of
vendor
applications
and
custom
built
internal
applications
here.
Actually
it's
mostly
bms
for
on-prem
there's
not
yet
a
lot
of
container
usage.
We
are
starting
to
experiment
with
google's
anthos
product
to
provide
on-prem
kubernetes
and
then
get
containers
there,
but
right
now
it's
pretty
much
just
vms
and
for
these
on-prem
data
centers
we
actually
connect
both
to
google
cloud
and
to
the
production
services
kind
of
through
the
front
doors
of
those
services.
C
So
there's
no
there's
no
backdoors.
Here
everything
goes
in
as
if
it
was
you
know
anyone
else
right.
So,
let's,
let's
take
a
look
at
what
this
actually
looks
like
again.
This
is
kind
of
at
a
at
a
high
level
here,
so
zach
was
talking
about
the
the
configuration
distribution
problem,
so
we
actually
already
have
a
whole
system
in
place
for
this.
That
is
set
up
to
distribute
sort
of
a
lot
of
that
lower
level.
C
Networking
configuration
things
like
the
the
network,
apples
and
and
firewalls
and
other
policies
on
projects,
and
things
like
that.
We're
just
reusing
that
system
and
you
know,
adding
a
plug-in
to
support
sending
out
the
the
istio
policies.
So
that
is
how
we
distribute
all
of
our
policies
to
to
all
the
api
servers
and
that
actually
provides
a
sort
of
paper
trail
if
you
will,
from
source
control
all
the
way
to
the
end
state.
C
We
we're
actually
running
istudi
here
as
a
separate
external
service,
using
the
support
that
was
added
for
external
sdod
forget
if
that
was
in
one
seven
or
one
eight,
but
it's
available
now
and
actually
we're
taking
advantage
of
it.
This
lets
you
run
an
sdod
that
is
not
actually
in
any
cluster.
You
can
run
it.
You
know,
however,
you
want,
you
can
run
on
vm.
You
can
run
it
in
a
separate
cluster
that
you
manage.
C
C
We
automatically
create
the
workload
groups
for
those
based
on
the
the
configuration
stored
in
the
policy
manager,
and
so
you
know
the
whole
system,
just
kind
of
works
and
everything
can
talk
to
each
other,
the
vm
vm
envoys
and
the
pod
envoys
all
just
connect
and
manage
onboard.
They
get
their
configuration,
and
you
know
everything
just
works.
So
it's
great
so.
B
A
Cool
awesome,
thank
you
all
so,
just
to
kind
of
to
come
back
and
and
summarize
right.
If,
if
we
look
through
and
look
at
like
some
of
the
high-level
topologies
here
that
we
kind
of
talk
through
across
these
four
use
cases-
and
we
squint,
you
know
fundamentally
we're
really
solving
the
same
set
of
problems
here
right
this.
This
cross-cluster
across
site
connectivity
and
isio
gives
us
this
really
powerful
set
of
tools
we
saw
across
these
disparate
organizations.