►
From YouTube: Multi-Cluster is Easier Than You Think with Linkerd and Ambassador - Thomas Rampelberg, Buoyant
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Multi-Cluster is Easier Than You Think with Linkerd and Ambassador - Thomas Rampelberg, Buoyant & Daniel Bryant, Datawire
Multicluster is becoming the new norm; practically everyone runs multiple dev and staging clusters, and running multiple cross-AZ/DC production clusters is a best practice for high availability. However, connecting multiple clusters is often seen as challenging. We’re here to convince you that it’s easy to get started with Linkerd and Ambassador. Join Thomas and Daniel to learn: - The motivations for cross-cluster communication - Key requirements for multi-cluster comms, including: providing a unified trust domain, separating failure domains, support heterogeneous networks, and providing a unified model with in-cluster comms. - An exploration of the “service mirror” pattern and how this is implemented within Linkerd - How to connect and manage an Ingress to a multi-cluster deployment using service mirroring (including live demo)
https://sched.co/ekD9
A
B
Thanks
thomas
hello,
everyone,
daniel
bryant
product
architects,
at
ambassador
labs
here,
working
on
the
ambassador,
api
gateway
project
for
the
past
three
or
so
years.
Loving
this
technology,
of
course,
loving
link
d,
loving
service
mesh
in
general
combination
of
ambassador
and
lincoln
deep
multicaster
are
super
interesting,
so
looking
forward
to
bringing
you
the
demo
today,.
A
And
my
name
is
thomas
rampelberg,
I'm
a
software
engineer
at
buoyant
the
creators
of
linker
d,
a
cncf
service
mesh
before
we
get
started,
let
me
introduce
the
two
projects
that
we're
going
to
be
using
to
build
out
our
multi-cluster
solution.
The
first
project
is
ambassador.
Ambassador
is
a
api
gateway
in
kubernetes.
You
need
to
have
an
ingress
controller
ambassador.
Does
that
and
quite
a
bit
more
in
fact
to
get
into
production?
You
need
a
lot
of
things
like
authentication
rate,
limiting
request
filters
and
ambassador
does
an
absolutely
fantastic
job
of
all
of
those.
A
It
is
open
source
and
I
would
recommend,
checking
out
their
website
to
go
and
kick
the
tires
on
that.
If
you've
been
looking
for
a
ingress
controller,
I
work
on
linker
d,
which
is
a
service
mesh.
In
fact,
it
is
a
ultra
light.
Ultra
fast
security
first
service
mesh
for
kubernetes,
you
get
observability
reliability
and
security
right
out
of
the
box,
which
is
kind
of
all
of
the
normal
service
mesh
check
boxes.
A
So,
let's
talk
a
little
bit
about
what
we're
going
to
go
over
to
do
multi-cluster
the
easy
way
you
really
need
to
have
four
separate
things.
You
need
to
understand
how
service
discovery
works
and
be
able
to
discover
services
across
clusters.
You
need
to
have
cross-cluster
access.
You
need
to
be
able
to
get
the
requests
from
one
cluster
to
the
other.
You
need
to
be
able
to
route
the
requests
in
an
intelligent
fashion
and
my
favorite
part
of
multicluster.
The
easy
way
is
profit
so
to
get
started
daniel.
B
So
welcome
to
the
demo.
Let
me
start
at
the
end.
This
is
actually
what
we're
going
to
end
up
here.
You
can
see
I've
got
a
command
line
terminal
showing
a
east
kubernetes
cluster.
This
is
a
gke
cluster
running
front,
end
and
pod
info
services,
and
you
can
see
I've
got
a
local
docker
desktop
cluster
down
here
on
the
context
of
west,
I'm
again
running
front
end
and
pod
info
here,
but
I'm
also
running
a
service
mirror
of
pod
info
east.
B
So
the
pod
info
east
service,
in
my
local
docker
desktop
cluster,
is
actually
pointing
to
the
gke
cluster.
It's
actually
pointing
to
the
mirrored
service
there
and
you
can
see
I've
exposed
using
ambassador
local
host
onto
the
front
end
service
running
in
my
docker
desktop
cluster,
and
because
I've
got
some
traffic
splits
set
up
using
smi,
which
I'll
show
you
at
the
end,
you
can
see
as
I'm
actually
making
the
request.
I've
got
some
refreshing
going
on
the
background
against
localhost
we're
hitting
west
and
east
versions
of
pod
info
service.
B
50
50.,
that's
what
the
traffic
split
is
set
up.
So,
although
I'm
always
hitting
the
ambassador
ingress
instance
running
in
my
docker
desktop
cluster,
sometimes
the
response
is
being
served
by
the
pod
info
service
running
in
dock
desktop,
but
sometimes
50
is
also
being
served
by
the
pod
info
service
running
in
gke
running
remotely,
and
that's
all
thanks
to
the
power
of
service
mirroring
and
it's
all
secure
traffic
between
the
two
clusters
and
we'll
now
run
you
through
how
you
can
actually
set
up
your
own.
B
So
for
today's
link
d
and
ambassador
multi-cluster
demo,
I'm
going
to
be
using
two
kubernetes
clusters:
I've
spun
up
one
already
to
save
time
in
gke,
using
the
gcloud
command
line
tool.
I
spun
that
up
in
the
u.s
east
region,
I'm
going
to
be
calling
that
cluster,
the
east
cluster.
That's
my
top
right
window
here.
B
I've
also
spun
up
a
local
docker,
desktop
a
cluster
that
one's
going
to
be
shown
in
the
bottom
right
window
here
and
I'm
going
to
be
running
my
commands
against
the
clusters
using
the
different
contexts
of
east
and
west,
and
I'm
going
to
be
running
all
the
link
d
commands
and
the
master
commands
in
my
console
on
the
left
here.
These
clusters
at
the
moment,
are
both
empty.
So,
let's
pop
along
to
the
kate's
initializer
and
use
this
to
bootstrap
the
clusters.
B
This
is
a
free
tool.
You
can
install
a
bunch
of
stuff
ambassador
for
ingress,
prometheus
monitoring,
jaeger,
key
cloak,
argo,
cd,
etc.
You
can
select
the
configuration
and
auto
generate
the
yaml
and
simply
apply
it
to
your
cluster
so
for
docker
desktop,
for
example,
my
west
cluster,
I
select
docker
desktop,
don't
want
to
terminate
tls
again.
This
is
a
toy
example.
You
do
want
to
look
at
tls
in
production,
but
once
I've
selected
my
config,
I
can
select
more
down
here.
If
I
want,
but
today,
let's
keep
it
nice
and
simple.
B
I
go
review
and
install,
and
I
will
I
get
some
coop
cattle
apply
commands.
I
can
run
against
my
cluster
now.
I've
got
some
pre-configured
commands
I've
done
already,
because
I
want
to
put
the
contexts
in.
So
I'm
not
going
to
be
copying
pasting
from
here,
but
this
is
exactly
what
I
would
you
know
would
do,
let's
go
back
and
I'll
show
you
with
the
gke
when
it's
exactly
the
same
select
gke,
I'm
going
to
be
using
an
l4
low
balancer.
B
B
B
B
B
B
B
Now
the
first
thing
we're
going
to
do
with
our
multi-cluster
setup
within
link
d
is
to
create
a
shared
trust,
anchor
public
private
keys
between
the
two
clusters
that
enables
them
to
communicate
securely.
I'm
going
to
use
the
step
cli
command.
You
could
use
open
sl,
whatever
you
like
and
generate
my
certificates
into
my
directory
here.
B
B
B
B
A
Thanks
daniel,
it
is
really
cool
to
see
what
it
takes
to
get
ambassador
up
running
on
not
one
cluster,
but
two
clusters,
as
well
as
linker
d,
all
set
up
and
ready
to
go
now
for
those
of
you
who
are
hopefully
going
to
be
trying
this
out
at
home.
I
would
like
to
note
that
while
it
was
it's
going
to
be
pretty
quick
for
you,
it
probably
will
be
a
little
bit
slower
on
your
own
clusters,
because
I
used
a
little
bit
of
movie
magic
there
and
sped
everything
up
great.
A
So
with
every
all
of
the
components
for
ambassador
in
liquidity
setup.
Let's
talk
a
little
bit
about
what's
required
and
what
all
those
components
do
so
to
get
multi-cluster
up
the
easy
way.
The
first
thing
to
dig
into
is
service
discovery
to
talk
a
little
bit
about
service
discovery,
though
first
let's
go
into
what
it
means
in
kubernetes,
so
in
kubernetes
I'm
going
to
be
using
the
pod
info
service.
Here.
As
a
example,
kubernetes
has
a
resource
type
called
services.
When
a
service
is
created
inside
that
namespace,
you
get
dns
for
it
automatically.
A
I've
got
that
up
here
on
the
slide.
It's
a
pod
info
test,
svc
cluster
local
and
the
front
end
app
that
I've
got
listed
here
can
address
pod
info
directly
when
it
does
that
the
dns
response
from
core
dns
returns
a
cluster
ip,
that
cluster
ip
gets
rewritten
through
the
magic
of
coop
proxy
and
ends
up
directly
at
the
pod.
This
is
great.
It
works
out
of
the
box.
Kubernetes
is
fantastic
on
service
discovery,
but
once
we
add
another
cluster,
there's
a
little
bit
of
a
problem
that
we
run
into.
A
A
Here's
your
answer.
Coop
ctl
contacts,
yeast
get
the
pot
info
yaml
and
pipe
it
into
the
west
cluster.
That's
pretty
much
all
you
really
need
to
do
now.
There's
a
couple
downsides
to
this,
and
is
we're
going
to
go
into
why
we've
installed
a
component
to
do
this,
but
that
moves
the
pod
info
service
over
to
the
west
cluster
from
the
east
cluster
and
now
there's
going
to
be
dns
that
can
be
addressed
for
front
end,
but,
as
I'm
sure
some
of
you
have
already
thought
through.
A
A
Kubernetes
has
a
controller
patterns,
deployments
are
managed
through
controllers,
services
are
managed
through
controllers,
and
those
controllers
basically
watch
the
api
server
for
resources
to
be
updated
and
then
do
something,
and
so
the
link
rd
service
mirror,
watches
the
east
clusters
api
server
and
when
it
sees
pod
info
created,
deleted,
updated.
It
goes
and
does
that
on
the
west
cluster,
that's
pretty
much
all
it
does.
The
one
important
thing
to
point
out
here,
though,
is
that
it
adds
the
east
cluster's
name
as
a
suffix
to
pod
info.
So
they
can.
A
You
can
directly
address
it
great,
so
all
we've
done
is
tackle
service
discovery,
we're
going
to
go
into
a
little
bit
about
how
the
cross
cluster
access
works
next,
but
before
we
do
that
daniel,
why
don't
you
give
us
a
little
bit
of
a
demo
on
what
it
takes
to
install
the
service
mirror
with
linker
d
on
a
cluster?
Let's.
B
A
With
service
discovery
set
up,
we
can
now
address
services
in
the
east
cluster,
but
how
do
we
actually
get
packets
to
go
over
there
to
figure
that
out?
Let's
talk
a
little
bit
about
a
resource
type
in
kubernetes
that
is
kind
of
under
the
covers.
Some
folks
don't
spend
very
much
time
chatting
about
it,
and
that
is
the
endpoint
resource.
A
The
endpoint
resource
in
kubernetes
is
kind
of
like
this
yaml
that
I've
got
up
here,
really
just
the
pod
ip
addresses
for
a
service,
so
the
endpoint
controller,
watches
services
and
takes
the
pod
selector
from
those
services
goes
and
looks
up
the
pods
and
adds
ip
addresses
to
an
endpoint
object.
For
that,
just
like
our
service
mirror
is
syncing
the
services
across.
We
could
just
stop
here
and
sync,
the
pod
or
the
endpoint
resource
across
the
clusters
attach
that
to
our
mirrored
service
and
let
everything
go
through.
Unfortunately,
that
presents
two
problems.
A
Problem
number
one
is
that
pod
ip
addresses
would
need
to
be
routable
between
cluster
west
and
cluster
east.
If
you
can
imagine
a
multi-cloud
scenario
where
you're
running
a
kubernetes
cluster
in
two
different
managed
providers,
that
would
be
pretty
difficult
possible
but
pretty
difficult
the
overlays
configuration
there
would
not
be
something
I
would
want
to
do.
A
A
It'll
get
synced
across
from
the
east
cluster
to
the
west
cluster.
Not
only
is
that
going
to
chew
up
a
bunch
of
bandwidth,
but
it
will
also
have
some
issues
around
keeping
everything
up
to
date.
Imagine
a
pod
ip
going
away
in
the
east
cluster
and
not
getting
updated
in
the
west
cluster.
You
potentially
could
have
some
lost
packets.
A
A
A
A
A
A
Linker
d
provides
mtls
out
of
the
box
for
both
sides,
because
there's
proxies
on
the
front
end
west
cluster
and
ambassador
east
cluster.
That
communication
across
the
internet
is
encrypted
because
it's
mtls
remember
it's
the
mutual
part.
It's
also
authenticated,
and
so
the
ambassador
only
allows
traffic
from
the
west
cluster
or
more
specifically,
signed
with
the
same
a
certificate
signed
with
the
same
trust
route
into
the
cluster
to
get
to
pod
info,
and
so
your
traffic
is
secure
and
access
is
also
secured.
So
you
don't
need
to
worry
about
the
security
there.
A
That
said,
security
is
a
amazingly
deep,
deep,
deep
dive
and
I've
added
a
link
to
this
slide
so
that
you
can
go
and
take
a
look
and
go
into
all
the
nitty
gritty
details.
If
that's
something
that
you're
interested
in
fantastic
daniel,
can
you
show
us
what
it
takes
to
get
ambassador
setup
as
a
gateway
for
all
of
this
traffic
in
a
multi-cluster
solution?.
B
B
B
B
I'll
now
just
get
all
the
linky
d
multitasker
config
everything
is
looking
good
everything's
up
and
running
here
and
now
I
can
link
the
two
clusters
with
this
command.
Here
you
can
see.
I
use
the
link
d
command
here
from
the
context
of
the
east
linking
in
the
west
and
actually
a
cube
cutting
apply
into
the
docker
desktop
cluster.
B
A
A
We
have
showed
how
to
get
packets
across
securely
and
now,
let's
talk
a
little
bit
about
request
routing
and
why
that
matters
being
able
to
address
services
in
other
clusters
is
cool
as
you'll
see
here
we're
directly
addressing
pod
info
east,
but
you
know
what
would
be
even
cooler
being
able
to
shift
the
traffic
over
without
needing
to
change
code
or
even
restarting
anything,
isn't
that
the
cloud
native
dream.
After
all.
A
So
far,
we
have
had
a
bit
of
a
theme
we
have
built
on
top
of
kubernetes
primitives
and
only
kubernetes
primitives,
and
the
reason
for
that
is
that
the
kubernetes
ecosystem
can
compose
and
build
on
top
of
those
very
easily
we've
used
services,
we've
used,
endpoints,
we've
used,
load,
balancers
and
we've
used
ingress
controllers.
All
of
those
are
standard,
off-the-shelf
components.
A
This
is
perhaps
the
first
non-standard
component,
though
it's
part
of
the
service
mesh
interface
spec
and
what
it
does
is,
allow
us
to
split
traffic
and
because
all
of
our
service
mirroring
is
using
services.
All
it
does
is
split
traffic
between
two
services.
So
here
in
our
spec,
we
have
said
that
any
traffic
addressed
to
pod
info
should
be
split.
A
B
B
Now
I'll
run
some
simple
script:
cfd
buoyant
team
to
go
to
the
linkerd
github
download
some
some
services,
and
example,
services,
some
of
them
based
on
pod
info
from
stefan
pradon
and
some
other
and
simple
apps
as
well,
which
we
can
use
to
demonstrate
the
service
mirroring
between
docker
desktop
cluster
and
their
remote
gke
cluster.
This
can
take
a
minute
to
install.
B
With
our
deployment
complete,
we
can
now
see
in
both
clusters.
We
have
the
front
end
service
and
the
pod
info
service
there
gke
class
at
the
top
here
and
then
the
docker
desktop
cluster
in
the
bottom.
Here,
let's
now
expose
a
very
simple
mapping
in
the
ambassador
gateway
just
to
map
the
prefix
of
slash,
I'm
exposing
docker
desktop
on
localhost,
so
localhost
slash.
The
root
will
now
map
to
the
front
end
service
running
in
the
test,
namespace
on
port
8080..
B
Let's
do
that
now
and
now,
if
I
pop
along
to
the
our
browser
and
do
localhost
slash,
we
are
now
looking
at
the
pod
info
or
the
front
end
and
pod
info
services
running
in
my
docker
desktop
west
local
cluster
all
looks
good.
Now,
let's
do
some
service
mirroring.
So
I
clear
my
terminal
and
I'll
copy
and
paste
in
this
command
here
I'll
use
the
linkid
multi-cluster
export
service
to
add
some
annotations
to
my
services.
B
You
can
see
I'm
configuring,
the
gateway
names
ambassador
and
the
gateway
namespaces
as
ambassador
2.
This
overriding
the
defaults
of
the
link
d
gateway,
but
that
is
nice
and
straightforward
hopefully,
and
we
should
see
in
my
docker
desktop
cluster
in
the
bottom
right
here.
We've
now
got
a
service
name
pod
info
east.
This
is
effectively
a
mirror
of
the
pod
info
running
remotely
in
the
east
cluster
in
gke.
B
If
we
want
more
info
on
that,
I
can
run
a
command
here.
I
can
basically
attempt
to
get
the
endpoints
for
the
pod
info
east
running
in
my
docker
desktop
cluster,
and
I
can
also
get
the
ambassador
at
global
loca,
a
global,
low,
balancer
ip
address
as
well
and
compare
them
and
there
you
go.
You
can
see
that
the
west
pod
info
east
service
endpoint
ip,
is
equal
to
the
gateway
ip
in
our
east
cluster.
So
basically
the
docker
desktop
pod
info
east
service
mirror
is
pointing
at
the
gateway
of
the
gke
cluster.
B
The
east
cluster.
Now
we're
running
some
traffic
generation
in
the
back
end
as
part
of
the
demo.
So
you
can
do
all
the
cool,
regular
stuff
you
can
with
link
d.
You
can
get
your
stats
to
see
what
kind
of
latency
and
requests
are
going
through.
You
can
also
look
at
the
actual.
You
can
do
a
tap
and
look
at
the
traffic
too,
which
is
quite
nice.
You
can
see
here
also
I'll
just
pause.
B
This
second
tls
true,
although
ambassadors,
are
not
running
tls
exposed
in
this
tour
example,
because
we've
got
our
shared
trust.
Anchor
we're
of
course,
encrypting
traffic
between
the
clusters,
courtesy
of
linker
d,
which
is
great
too
linkedin
command
line,
is
fantastic,
as
is
the
dashboard
for
debugging
poking
around
the
services.
Frequently
find
myself
in
there
looking
to
make
sure
I've
got
my
traffic
config
all
set
up
correctly.
B
Now
I
could
simply
expose
the
pod
info
east,
via
my
west
gateway
by
my
west
ambassador,
but
make
it
more
interesting
and
we're
going
to
be
using
the
smi,
the
service
mesh
interface
config,
to
do
some
traffic
splits.
So
if
you
can
see
here,
I'm
going
to
apply
in
my
docker
desktop
cluster,
a
traffic
split
on
pod
info
across
the
pod
info.
B
That's
running
in
the
docker
desktop
west
cluster
and
I'm
going
to
also
split
50
50
to
the
pod
info
east
service
and
that
is
going
to
mirror
into
the
east
based
the
gke
based
pod
in
pod
info
service.
Let's
apply
this
now
all
looks
good.
If
I
pop
back
to
my
browser
and
do
a
refresh,
oh
we're
already
seeing
east
perfect
and
there
we
go
with
some
west,
we
have
lucy.
Some
east
looks
good.
A
How
cool
is
that
we've
now
gone
through
getting
multi-cluster,
set
up
the
easy
way
and
that's
pretty
much
it.
We've
shown
what
you
need
to
do
to
get
service
discovery
so
that
you
can
see
services
from
one
cluster
in
another,
we've
outlined
what
it
takes
to
get
cross-cluster
access
and
make
it
secure,
and
we've
shown
everything
you
can
use
to
do
request
routing.
A
So
the
most
important
of
step
of
all
is
right
now,
profit
where
we
set
back
sit
back
in
our
chairs
and
talk
about
all
of
the
amazing
things
that
we've
enabled
with
this.
So
what
have
we
enabled?
Well,
one
of
the
most
interesting
use
cases
for
me
is
cluster
isolation.
Imagine
that
you're
managing
credit
card
numbers
and
that's
a
compliant
environment
that
you
need
to
have
audited
instead
of
having
one
big,
kubernetes
cluster
that
has
everything
in
it.
A
A
Another
use
case
for
this
is
disaster
recovery.
Imagine
a
very
important
service.
Failing
the
front
end
can
now
get
automatically
redirected
to
your
backup,
cluster
or
perhaps
more
interesting.
The
backup
cluster
can
be
tested
with
real
traffic
during
normal
operation.
So,
instead
of
having
to
hope
and
pray
that
your
backup
cluster
is
going
to
work,
you
can
go
and
test
your
disaster
recovery
during
the
day
at
any
time
that
you
want.
Perhaps
the
most
exciting
use
case.
For
me,
though,
is
development.
A
I
know
we're
virtual,
so
I
can't
see
anybody's
hands
raised,
but
I'm
going
to
raise
my
hand
how
many
of
us
have
worked
on
microservices
and
had
it
get
to
the
point
where
it
doesn't
fit
on
your
laptop
anymore.
I
sure
have
in
fact
I
hate
it
even
more
if
it
fits
it
slows
my
laptop
down
and
it's
a
pain
in
the
butt
to
use.
A
So
that's
everything
that
we've
got
for
multi-cluster.
Just
a
couple
more
slides
here
to
talk
about.
First
off
I'd
like
to
introduce
the
linker
d
community
anchor
program,
we
really
like
to
get
the
community
involved,
and
especially,
if
you're,
using
ambassador
in
linkerie,
we
would
love
to
know
about
it,
so
jump
onto
that
link
down
at
the
bottom
of
the
slide.
If
you're
interested
in
becoming
a
cloud
native
expert
and
getting
a
little
bit
of
help
from
us
to
tell
your
story
also
join
both
of
our
communities.
A
I've
got
links
to
our
github
and
slack
accounts.
Daniel
and
I
both
are
slack
junkies
and
are
sitting
around
waiting
for
your
questions
with
baited
breath.
So
please
dive
into
those
and
then
finally,
here
are
links
to
everything
that
we've
gone
through
so
far
today.
I
would
really
love
to
see
everyone
here,
go
through
the
tutorials,
deep
dives
and
get
up
and
running
with
multi-cluster
on
your
own
clusters.
Thank
you
so
much
and
have
a
great
rest
of
your
kubecon.