►
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
Istio Multi-Cluster Service Mesh Patterns Explained - Daniel Berg & Ram Vennam, IBM
This session will review the various multi-cluster service mesh deployment patterns that are available with Istio. We will explain the pros and cons of each approach to ensure that you have the information necessary to properly apply one or more of these patterns for your own needs. We will provide a demonstration to show how one would setup a multi-cluster Istio mesh using Kubernetes clusters. This session is a must see if you currently are, or considering, implementing a hybrid cloud solution. Even if you are not yet using a service mesh, this session will provide valuable information to help you on your own hybrid journey.
https://sched.co/MPf1
A
Hello:
everyone
there
we
go
we're
on
okay,
my
name
is
Dan
Burke
and
I'm.
Here
with
Ron
venom,
we
are
with
IBM
IBM
cloud,
we're
also
members
of
the
sto
project,
we're
part
of
the
steering
committee
as
well
as
the
TOC
itself,
and
what
we
want
to
do
is
we
want
to
take
you
through
some
information
about
sto
and
multi
cluster
service
mesh
patterns.
So
this
is
something
that
was
introduced
in
the
and
the
1.1
release
of
sto
and
we're
gonna.
A
A
A
Okay,
everybody
does,
because
everybody
does.
You
have
to
have
multiple
clusters.
At
the
very
least,
you
have
multiple
clusters
for
dev
test
and
production
right,
your
CI
CD
process
in
the
room
just
before
this
was
a
panel
about
get
ops.
You're,
not
gonna,
deliver
code
directly
to
production
without
going
through
some
development
and
testing
stage.
I,
don't
know
anyone
running
a
production
service
that
doesn't
so
you're
gonna
have
multiple
clusters.
For
that
reason,
but
you're
also
gonna
have
multiple
clusters
for
other
various
reasons.
For
example,
you
may
have
a
performance
requirement.
A
You
have
to
run
your
compute
close
to
your
data,
so
you
want
to
have
you
want
to
have
your
clusters
close
to
your
data?
You
might
need
workload
isolation,
so
you
might
separate
your
workloads
between
your
clusters
with
network
isolation,
compute
isolation,
even
access
isolation,
if
you're
in
the
room-
and
you
have
to
deal
with
compliance
and
auditability
cost-
is
another
factor,
especially
when
you're
looking
at
dev
and
production.
You
don't
want
to
set
up
a
massively
large
production,
quality,
dev
environment,
to
have
environments
or
should
be
a
lot
cheaper.
A
You
want
a
lot
more
of
them
and
the
products
are
generally
more
expensive.
So
you're
gonna
have
multiple
clusters
for
that,
and
then
lastly,
your
failover
and
redundancy
there
there's
gonna
be
a
point
at
which
things
fail,
but
the
service
fails.
The
environment
fails.
The
data
center
fails,
there's
always
certain
levels
of
failure.
You
got
to
have
multiple
clusters
for
high
availability
and
then,
of
course,
if
you
ever
have
a
disaster,
you've
got
to
have
that
dr
site
available
to
you.
A
Applications
can
kubernetes
help
me
how
many
clusters
am
I
going
to
need
to
do
that.
How
am
I
going
to
control
access
for
those
clusters
and
control
access
not
only
of
operators
accessing
it,
because
I
have
to
audit
it,
but
I
need
to
have
complete
control
of
all
public
traffic
in
and
out
of
my
cluster.
How
do
I
do
that?
How
do
I
do
that
effectively?
A
How
do
I
audit
all
of
that
traffic
so
that
I
can
be
assured
that
I
can
not
only
audit
my
operations
team
and
provide
that
information,
but
I
can
also
provide
it
to
compliance
officers
at
the
time
of
an
audit,
a
compliance
on
it.
Obviously
connection
back
to
on-premises
network.
That's
always
a
key
aspect.
If
you're
not
born
on
the
cloud
which
most
of
the
customers
that
we
deal
with
are
not
born
on
the
cloud.
A
Many
of
them
have
workloads
already
on-premises
and
you
want
to
be
able
to
connect
back
to
those
very
securely
and
in
controlled
fashion
and
then
another
one
is
just
secure.
Communication
of
your
data
data
in
transit,
both
between
clusters,
between
services
and
within
the
cluster
itself,
pod
to
pod.
How
am
I
going
to
ensure
secure
communication
encrypted
communication
between
all
my
pods
between
every
communication,
every
client,
every
destination
that
I
talk
to.
A
So
let's
take
a
look
at
a
very,
very
basic
view
of
a
problem
or
a
situation
that
we're
looking
at
with
a
customer.
So
they
have
a
situation
where
they
must
control
client
access
into
and
out
of
the
cluster,
but
they
they
have
very
strict
requirements,
and
in
this
requirement
they
have
two
separate
clusters
or
a
sets
of
clusters.
So
in
this
case
we
have
a
DM
Z
cluster,
as
well
as
multiple
back-office
clusters,
and
these
back-office
clusters
may
be
on
Prem.
A
They
may
be
out
in
the
cloud
that
it
doesn't
matter,
but
there's
multiple
of
these
back-office
clusters
now
I've
indicated
these
pools,
and
these
pools
are
basically
just
a
pool
of
worker
nodes.
Vms
bare-metal
doesn't
matter,
but
it's
a
set
of
worker
nodes
that
have
very
specific
use
cases
within
this
in
this
environment,
so
I
got
edge,
pools
and
private
only
pools,
and
you
can
see
those
across
both
of
the
clusters.
Now.
The
interesting
thing
about
this
architecture
with
kubernetes
is
that
those
edge
pools
are
the
only
ones
that
have
access
to
a
public
network.
A
There's
no
inward
traffic
coming
in
to
that
back
office
cluster,
and
that
was
a
key
requirement
of
this
customer-
is
that
traffic
from
the
public
could
not
go
into
that
cluster.
Not
only
that
public
internet
facing
traffic
cannot
emanate
from
that
club
those
clusters
either
they
all
have
to
be
controlled
through
the
DMZ
cluster.
So
that's.
A
This
is
the
reference
architecture
that
we
set
up
and
we're
gonna
go
back
through
this
as
we
go
through
this
talk
and
reference
that
again,
as
you
start
looking
at
the
various
multi
cluster
multi
cluster
service
mesh
patterns,
but
I
also
wanted
to
call
out
a
notion.
I
said
at
the
beginning,
those
back
office
clusters
could
be
on
Prem.
A
They
could
be
out
in
the
cloud
and
in
an
IBM
cloud
with
our
kubernetes
service,
we
have
the
ability
to
create
private
clusters
and
then
the
case
that
we're
working
with
the
customer
they're
going
straight
to
the
public
cloud.
They
want
to
be
very
strategic,
forward-looking
and
they
want
to
try
to
solve
these
problems
in
the
public
cloud,
and
one
of
the
key
technologies
is
we're
going
to
be
leveraging.
A
The
notion
of
these
private
clusters
that
are
available
to
us
and
the
private
cluster
basically
has
a
set
of
worker
nodes,
like
we
showed
before
that,
only
a
private
network
access,
but
also
the
master,
which
is
fully
managed
in
this
case,
but
that
master
also
does
not
have
public
facing
internet
access,
which
means
you
can't
access
the
master
or
the
workers
through
the
public
internet.
You
have
to
go
through
another
channel
to
get
access
to
them.
A
So
how
many
people
here
have
heard
of
this
do
is
awesome.
Okay,
a
fair
number
of
you.
Ok,
like
I,
said
at
the
beginning.
We
work
on
the
sto
project,
the
service
mesh
when
you
start
introducing
cloud
kubernetes
and
especially
all
the
requirements
that
I
mentioned
earlier.
You
have
to
start
looking
at
beyond
just
kubernetes.
It
was
even
stated
at
the
beginning
dan
indicated
at
the
beginning
of
the
the
talk
in
the
keynote
that
for
cloud
native,
it
goes
well
beyond
just
kubernetes
and
we're
at
that
point
now.
Your
you
need
additional
tools.
A
You
need
additional
capabilities
beyond
kubernetes
and
kubernetes
provides
a
lot
of
value
at
the
platform,
including
both
the
networking
and
network
isolation,
security,
but
there's
things
that
it
cannot
do
and
it
doesn't
do
today
and
that's
where
sto
and
the
service
mesh
comes
in
and
sto
provides.
Basically
for
me,
I've,
you
sto,
as
a
programmable
network,
is
fundamentally
the
way
I
see
it
with
these
key
value,
propositions
associated
with
it.
First
of
all,
the
ability
to
connect
your
services
in
a
very
efficient
and
flexible
manner.
If
everybody's
used
kubernetes
in
here.
A
That's
why
we're
all
here,
load,
balancing
and
kubernetes
is
round-robin,
and
that's
it
you
roll
out
a
new
version.
You
do
a
rolling
update.
You
really
don't
have
much
control
over
how
that
rolling,
updated
and
that
load
balancing
takes
place
with
this.
Do
you
can
do
the
connection
and
better
load
balancing
options
with
multiple
versions
of
a
service,
and
you
can
do
canary
and
a/b
testing,
because
you
have
greater
flexibility
of
routing
between
your
services.
A
A
Sto
is
definitely
one
of
those
technologies
that
you
have
to
look
at
in
order
to
achieve
that
goal,
because
it
provides
out-of-the-box,
secure
mutual
TLS
communication
between
your
pods,
as
well
as
services
outside
your
cluster,
that
it
can
all
be,
and
again
it's
programmed
into
the
network,
not
in
your
application,
the
observability.
Once
you
have
one
cluster
and
multiple
clusters,
2
3
10,
20
100.
It
becomes
very
difficult
to
understand.
A
What's
going
on
across
those
clusters,
you
need
a
way
to
be
able
to
observe
and
have
visibility
of
the
resources
in
those
clusters
and
the
communication
between
those
resources
and
sto,
with
the
service
mesh
built
into
the
networking,
provides
that
level
of
observability
and
lastly,
control
and
policy
enforcement.
Again
going
back
to
core
business
requirements,
you
have
a
number
of
policy
enforcement's
that
must
be
made
during
the
communication
flow
within
your
mesh
and
you're.
A
Gonna
want
to
be
able
to
control
that
not
only
within
individual
clusters,
but
you're
gonna
want
to
be
able
to
program
that
across
clusters
as
well
services
that
exist
in
multiple
clusters
in
your
production
deployments.
So
these
are
key
capabilities
that
STO
provides
and
now
what
we're
gonna
do,
I'm
going
to
switch
it
over
to
Rahm
and
he's
gonna.
Take
you
through
the
reference
architecture
for
ISTE,
oh,
and
that,
as
well
as
the
three
key
patterns
that
we
see
for
multi
mesh
great.
B
B
Most
of
this
is
not
there
and
you
just
have
those
two
services
at
the
top,
and
you
don't
have
this-
do
when
service
a
wants
to
talk
to
service
B
service,
a
we'll
just
do
a
like
a
cube,
DNS
lookup
get
the
cluster
IP
address
start
talking
to
it,
which
will
then
forward
to
the
to
the
pod
IPs.
Now,
if
you
want
more
visibility
and
insights
into
what
exactly
happened
with
this
communication,
you
don't
quite
get
out-of-the-box
with
kubernetes,
you
don't
know.
B
If
a
is
really
a
that's
talking
to
B
and
B
doesn't
know
who
exactly
is
talking
to
it,
so
you
don't
have
that
you're
not
able
to
authenticate
who
is
talking
to
who
and
you
don't
have
that
control
and
prevent
like
men
in
the
middle
attacks,
for
example.
So
the
way
sto
works
is
it
injects
envoy
proxies
inside
the
pod
running,
alongside
your
container.
So
inside
a
pod
now
you
have,
if
you
only
had
one
container
before
now.
B
You
have
two
containers:
okay
and
the
component,
that
the
the
pieces
at
the
top
is
called
sto
like
the
the
data
plane
and
that
all
the
stuff
on
the
bottom
is
a
control
plane
so
to
control.
All
of
these
Envoy
proxies
when
you
apply
your
sto
configuration
just
through
a
mo
and
the
sto
galley
component
will
receive
that
yeah
mordioux,
config
validation,
send
it
over
to
a
co-pilot
and
sto
pilot
will
take
that,
translate
it
and
send
that
config
to
each
one
of
the
necessary
on
voice.
B
So
what
this
gives
you
now
is
that
once
a
wants
to
talk
to
B,
it's
still
no
changes
in
your
application.
It
still
talks
to
be
I'm
using
just
the
DNS
and
then
the
DNS
lookup
happens,
and
in
this
case
it's
geo
is
configured
to
basically
replace
that
cluster
IP
addresses
and
it
will
direct
it
to
the
pod.
Ip
of
service
beat
so
there's
this
proxy
going
on
on
both
sides.
So
this
allows
you
to
do
things
like
routing
based
decisions.
B
You
know
have
checks
to
see
if
this
communication
is
allowed
and
after
this
communication
happens,
if
all
the
policies
pass
and
it's
able
to
do
is
communication,
it
will
then
do
an
out-of-band
communication
back
to
the
sto
mixer
component
to
to
tell
it
what
exactly
happened.
So
that's
what
gives
you
that
that
telemetry
type
of
information
about
the
service
now
the
most
important
feature
that
that
I
talk
to
customers
about
when
they're
adopting
a
CEO
is
not
this
like
weight
based,
routing,
canari
deployments
and
things
like
that.
B
But
it's
more
the
the
mutual
TLS
aspects
of
it
day,
one
encryption
from
pot
to
pot
and
to
do
that
inside
your
micro
service
to
handle
the
encryption
to
do
the
certificate
management
yourself
adds
a
lot
of
operational
overhead,
your
micro
services
and
your
cluster
management.
Sto.
Does
that
for
you?
So
it's
a
certificate
authority.
It's
able
to
generate
certificates
and
roll
it
out
to
each
one
of
the
the
envoys
so
that
the
communication
is
now
upgraded
and
encrypted
and
it
happens
kind
of
seamlessly
out
of
the
box.
B
Okay,
so
that's
kind
of
the
sto
architecture
flow.
The
one
last
piece
is
that
little
sidecar
injector
on
the
bottom,
this
proxy
injection
you
can
either
do
it
manually
with
like.
When
you
do
cube
cuddle
apply.
You
can
wrap
it
with
the
Sto
inject,
which
will
put
that
container
config
in
next
year.
Your
container
config
or
you
can
use
the
sidecar
injector,
which
will
do
it
for
you
automatically.
Don't.
B
Well,
we'll
definitely
cover
the
gateways
in
more
detail,
but
from
this
diagram,
its
control,
controlling
traffic,
that's
coming
into
your
network
and
you
can
also
control
traffic.
That's
going
out
of
the
network,
so
this
allows
you
not
only
control
but
also
to
limit
we
type
of
information.
So
you
have
more
kind
of
restriction
on
that.
B
So
this
pattern
is
kind
of
the
flat
network,
single
Network
single
control,
plain
flow
where
the
cluster
on
the
left
is
your
your
main
cluster
and
has
the
entire
hto
control
plane
installed
onto
it,
and
sometimes
this
cluster
is
called
the
local
cluster
and
the
docs
cluster
are
all
your
remote
clusters
and
in
this
cluster
there
are
no,
it's
not
a
full-blown
sto
install
it's
just
the
required
pieces.
So
in
this
case
it's
just
Citadel
and
maybe
also
your
sidecar
injector.
B
B
The
second
big,
but
actually
the
first
big
requirement
for
this
setup,
is
that
is
that
shared
Network,
and
that
means
that
the
the
pod
IP
ranges,
the
pod,
IP
IP
ranges
and
the
cluster
IP
ranges.
They
cannot
overlap,
and
not
only
can
they
not
overlap,
they
need
to
be
able
to
route
from
one
another
and
that's
because
traffic
is
being
routed
directly
from
one
cluster
to
another
cluster
without
gateways
of
any
kind.
It's
going
direct
communication,
it's.
A
B
Let's,
if
you've
walked
through
a
flow,
let's
say
pod
foo
running
in
cluster,
one
wants
to
talk
to
pod
bar
and
cluster.
Two
again,
it
will
just
do
a
DNS
lookup
for
a
bar
kubernetes
will
resolve
it
to
a
cluster
IP
and,
in
this
case
envoy,
will
basically
intercept
that
cluster
IP
to
the
pot
IP
of
of
where
it
knows
that
bar
is
running.
So
in
this
case
it
knows
bar
is
running
in
cluster.
Two
we'll
get
the
pod
IP
come
back
and
then
we'll
configure
envoy
to
direct
that
traffic
directly
to
do
pot
IP.
B
So
that's
kind
of
how
that
works.
It's
pretty
straightforward
to
use,
but
to
actually
set
this
up
does
require
more
and
more
of
a
complex
setup
and
there's
a
lot
of
moving
pieces,
especially
because,
if
you
think
about
things
like
telemetry
this,
the
Envoy
on
bar
side
now
needs
to
talk
to
back
to
the
pilot
on
cluster
one.
So
there's
a
lot
of
communication
going
on
back
and
forth
between
the
cluster.
So
if
your
IPS
are
changing
or
or
you
know,
your
secrets
for
your
cube,
API
change-
there
needs
to
be
this.
B
Like
management
plane
to
to
handle
this,
so
this
is
a
good
setup.
If
you
have
a
CI
CD
environment,
where
you
able
to
deploy
these
consistent
namespaces
across
the
to
ensure
it's
similar,
config
is
being
pushed
out
and
the
advantages
of
this
scenario
is
well
first
of
all,
the
requirement,
if
you
do
have
a
flat
network,
so
the
disadvantage
of
that
would
be
well
if
it's
not
really
good
for
isolation.
If
you
want
network
isolation
between
your
two
clusters.
Well,
this
is
not.
This
is
not
gonna
work,
because
all
they
just
basically
one
big
cluster.
B
B
So
this
next
plat
pattern
does
not
require
a
flat
network
so
by
default,
if
you
create
two
clusters
on
IBM
cloud,
kubernetes
service
they're
gonna
be
on
separate
networks,
they're
not
going
to
be
routable
within
one
cluster
to
another
cluster.
So
with
that
as
a
baseline
again,
the
installation
of
both
is
is
similar
and
that
you're,
your
main
cluster,
has
the
full-blown
Sto
your
remote
clusters
do
not.
They
have
separate
internal
IP
ranges
and
a
couple
of
new
pieces
involved
here
to
make
this
routing
happen.
B
All
services
that
are
in
the
remote
clusters
are
now
associated
behind
an
ingress
gateway,
miss
Keogh,
ingress
gateway
and
all
of
these
ingress
gateways
across
all
your
clusters
are
labeled
and
that
label
basically
represents
each
of
that
cluster.
So
your
main
cluster,
now
when
it
wants
to
route
to
a
pod
inside
of
a
different
cluster,
it
will
just
route
to
the
gateway
of
that
remote
cluster
and
have
that
gateway.
B
Do
the
forwarding
then,
inside
that
cluster,
a
few
key
technologies
to
outline
here
pilot
uses
this
new
feature
in
envoy,
API
split
horizon
EDS,
so
basically
that
means
that
it's
able
to
configure
the
routes
based
on
who's,
calling
it.
So
if
phoo
on
Cluster
ones
trying
to
talk
to
a
service,
that's
local,
then
it's
just
going
to
resolve
it.
B
It's
going
to
resolve
to
a
local
IP
address
and
if
it's
trying
to
talk
to
a
service
in
a
remote
cluster
in
this
case
and
it's
going
to
resolve
to
the
sto
gateway
address,
so
in
this
case
the
the
flow
would
be.
Food
food
talks
to
food
resolves
the
IP
to
a
cluster
IP
sto
replaces
that
cluster
IP
affords
it
to
the
ingress
gateway.
This
communication
is
obviously
encrypted.
There's
a
piece
of
sni
information
that
the
ingress
gateway
is
able
to
read
and
figure
out
where
needs
to
route
inside
of
it.
B
So
it
maintains
that
encryption
and
then
the
and
then
the
communication
is
follows
the
rest
of
the
path
and
goes
to
bar
again.
In
this
scenario,
it's
a
very
chatty
scenario,
with
a
little
bit
of
a
little
bit
of
a
complex
setup
and
I
think
doesn't
need
a
CI
CD.
It's
good
for
failover
scenarios,
but
not
the
greatest
for
isolation.
I
mean.
A
B
And
that's
actually
an
advantage
for
some
folks
that
want
that
single
control
plane,
so
you
can
enforce
all
of
your
sto
config
to
one
cluster
and
and
that
one
cluster
is
able
to
then
propagate
to
the
rest
of
them
right.
So
that's
some
single
control
plane
for
configuration
management
as
well
as
dashboard,
so
HT
o
comes
with
like
key
Olli,
go
fauna
and
Prometheus
dashboards
right.
So
in
this
case
you
just
have
that
one
dashboard
and
you're
able
to
see
your
traffic
flow
and
telemetry
information
across
all
of
your
clusters.
B
The
third
pattern
is
multiple
control
planes,
multiple
network,
so
I.
Essentially
these
are
completely
independent
clusters
and
every
cluster
has
full-blown
sto
running
on
it
and
not
much
is
needed
when
you're
doing
they
installed
this
installation.
There's
no
config
sharing
the
cluster
one
does
not
need
eight
access
to
the
API
of
cluster,
two
cetera,
so
it's
simpler
to
set
up
okay.
So
let's
talk
about
how
this
flow?
How
this
pattern
implements
this
similar
flow
in
this
case
sto
will
configure
the
DNS
of
cluster
1
and
adds
additional
like
endpoint
lookups,
so
by
default.
B
You
know
when,
when
when
it
asked,
when
foo
asked
for
to
resolve
boot
bar
and
resolves
like,
but
a
little
search
for
bar
bar
dot
service,
clustered
a
local
bar,
a
default
etc.
So
it's
got
a
few
things
that
will
look
up.
A
steel
will
add
another
entry
to
that
bar
dot
name
space
global,
so
this
tells
sto
that
you
know
when
it
does
resolve
to
this
bar
dot
global,
that's
when
it
needs
to
come
in
there
and
then
replace
it
with
the
ingress
gateway
of
the
remote
service.
B
So
in
this
case
you
need
to
create
a
service
entry
object
for
your
cluster
1
and
service
entries
away,
it's
SEO
terminology
to
add
additional
DNS
entries
or
it
or
additional,
like
service
registry
entry
entry
since
2
it
into
its
lookup.
So
it
adds
another
one
for
call
bar
dot
name
space
global
in
this
case,
border
globe
booking
photo
global
so
and
then
it
will
the
same
way
as
before.
I
will
route
it
to
the
ingress
gateway
on
the
remote
cluster
and
again
using
s
and
I.
Look
up.
B
It's
able
to
then
continue
on
with
the
flow.
The
advantages
of
this
is
that,
like
I
said
it's
simpler
to
setup,
it
provides
independence
to
each
one
of
your
applications,
so
each
one
of
your
clusters,
so
this
cluster
might
be
controlled
by
one
specific
dev
team
and
you
might
want
to
pick
and
choose
exactly
when
you
want
to
expose
a
particular
service
to
do
two
other
clusters
and
when
you
decide
you
don't
want
to
do
that
anymore.
B
You
can
just
stop
it
and
you
only
have
that
one
single
service
entry
basically
to
delete,
and
then
you
you
break
the
connection
between
the
two.
This
is
great
for,
like
canary
it
releases
across.
If
you
have
your
production
cluster,
you
don't
want
to
mess
with
it
and
you
have
your
production
to
or
staging
cluster,
and
you
want
to
Vout
1%
of
traffic
just
to
this
one
service.
You
can
do
that
this
way.
While
so
and
this
this
can
happen
even
with
your
micro
services
that
are
behind
not
externally
facing
micro
services.
B
A
The
other
thing-
that's
really
nice
about
this
pattern.
Besides
some
of
the
simplicity's
is
it
has
the
two
control
planes,
so
every
cluster
has
its
own
control
plane,
so
it
naturally
will
scale
better
than
the
previous
solutions
right,
because
you're,
basically
sharding
the
control
plane,
every
every
cluster
gets
its
own
control
plane
and
we're
basically
federating
the
communication
between
them.
A
You
do
need
a
common
root
CA,
so
you
can
do
mutual
TLS
between
them
and
you
can
still
program
all
that,
but
this
provides
that
level
of
isolation,
that's
required
in
multiple
scenarios,
but
also
better
scale.
Now
the
downside,
obviously,
is
that
there's
multiple
control
planes
and
you'd
have
to
manage
multiple
control
planes
versus
one.
So
there
is
a
higher
operational
cost
for
managing
the
control
platens
themselves.
Okay,.
B
So,
let's
go
back
to
our
our
customer
requirement
scenario
and
see
how
we
would
do
that
with
with
this
pattern,
we're
going
to
implement
this
using
pattern,
3
the
multiple
control
planes.
So
first
we
have
the
same
dmz
and
back
office
cluster
and
you
create
these
two
edged
poles
and
I'm
gonna.
Try
to
see
if
I
can
show
you
this
and
running
off
of
this
hotspot,
because
the
network
was
really
bad.
B
B
Really
big
geez,
okay,
okay!
So
here
the
worker
knows
here
all
the
list
of
worker
nodes
that
that
I've,
created
and
IKS
has
the
concept
of
a
worker
pool
where
you
can
kind
of
group
them
together.
So
we
have
three
of
the
worker
nudes
grouped
in
edge
pool
and
then
the
other
ones
in
private.
Only
and
then
going
back
to
my
slide.
B
And
then
you
create
your
ingress
and
egress
gateways
appropriately,
so
the
the
edge
pool
will
have
its
own
set
of
ingress
and
egress,
and
then
the
the
private
only
pool
will
have
its
own
ingress
and
egress,
and
this
is
needed,
for
you
know,
communication
basically
you're
hopping
between
the
public
VLAN
and
the
private
VLAN.
So
I'm
just
gonna
skip
the
animation
here
for
the
sake
of
time
and
kind
of
jump
forward.
B
B
Of
this
external
IP
and
that
external
IP
is
the
IP
of
this
ingress
gateway
this
one's
right
here,
okay
and
then
the
next
thing
we
need
to
do
is
be
able
to
forward
that
traffic
to
the
egress
gateway
and
then
on
to
the
ingress
gateway
of
the
back-office
cluster.
So
to
do
that,
we
just
use
a
service
entry
and.
A
While
he's
going
through
that
that
egress
gateway
on
the
first
cluster,
that's
optional,
it
wasn't
absolutely
necessary,
but
in
this
customer
scenario
they
wanted
the
they
wanted
to
keep
that
nice
pattern
of
inbound
is
ingress
gateway,
outbound,
egress
gateway
for
every
cluster,
so
they
wanted
to
control
both
inbound
outbound
even
for
east-west
traffic.
So
that's
the
reason
why
we
have
included
it
here
and.
B
We're
gonna
use
that
to
talk
to
out
out
down
traffic,
so
in
this
case,
like
so
I'm
still
trying
to
get
to
the
finance
service,
so
I
defined
that
finance
namespace
global
entry,
which
will
then
point
to
the
egress
gateway.
Okay
and
then
that's
how
that
communication
happens.
So
now,
if
I
want
to
connect
to
this
service,
I
just
find
my
NLB
address
and
then
go
to
that
and
then
that
points
to
my
fancy-
finance
application,
that's
running
in
cluster,
so
now
cluster
two
wants
to
be
able
to
talk
to
an
external
service.
B
So
let's
say,
but
we
want
to
control
that
right.
We
don't
want
our
containers
to
be
able
to
talk
to
any
outbound
traffic,
and
this
is
one
of
the
requirements
of
this
customer.
So
if
I,
if
I
wanted
to
ping
Google,
for
example,
if
I
hit
that
it
should,
it
should
not
allow
that
traffic.
So
you
know,
I'm
hitting
submit
and
nothing's
happening.
I
should
get
an
error,
but
I
think
it's
just
eventually.
Gonna
timeout
I
gotta.
B
Great
yeah,
but
we
what
we
do
want
to
do
is
want
to
talk
to
like
let's
say
this:
HTTP
bin
status,
endpoint,
okay.
So
now,
if
I
send
a
request
to
that,
please
work,
okay,
so
it's
able
to
talk
to
this
endpoint,
so
this
is
going
back
to
our
slides.
This
is
the
finance
service
being
able
to
talk
to
external
traffic,
and
throughout
this
you
know
we
have
to
go
through
this
whole
flow
again.
B
First,
you
know
you
create
a
service
entry
for
the
finance
object
and
then
you
have
it
forwarded
to
using
a
very
steel
virtual
service
to
the
SPO,
egress
gateway,
and
then
a
sea
of
egress
gateway
will
talk
to
the
private
pool
on
the
cluster
one.
And
then
you
create
a
regular
service
entry
object,
as
you
would
with
a
CEO
to
allow
outbound
traffic
and
I
can
show
you
that.
But
you
know
it's
just
basically
a
bunch
of
the
animals,
but
you
get
the
point
so
to
kind
of
wrap
up
here.
B
I
would
say
that
the
multi
cluster
of
patterns
are
they're.
Definitely
not
like
production
ready,
there's
a
lot
of
like
kinks
that
need
to
be
ironed
out,
and
this
was
more
meant
to
be
a
good
POC
to
kind
of
give
you
an
idea
of
where
the
hto
community
is
headed.
Well,
they
were
focused
on
especially
our
IBM
research
team.
Has.
This
has
been
one
of
their
main
interests,
so
we've
documented
the
three
patterns
that
I
just
talked
about
in
more
detail.
B
The
author
of
this
vlog
is
actually
sitting
in
this
room
right
here,
etai
and
then
this
demo
I
didn't
set
it
up
myself.
Another
member
on
our
team
of
a
team
I
know
helped
me
set
this
up,
but
these
guys
documented
this
in
much
more
detail
on
this
blog
post.
If
you
just
google
ways
to
do
multi
poster
cluster
patterns,
you'll
see
a
summary
of
this.
We
also
created
a
questionnaire
for
the
community,
the
hto
users
community,
because
we're
trying
to
learn
exactly
which
one
of
these
patterns
applies
to
your
scenario.
B
A
Your
feedback
is
important
for
us,
because
that'll
help
us
identify
we're
doing
which
pattern
do
we
want
to
put
more
development
focus
on
and
Harden
as
part
of
the
sto
project
itself?
We
may
do
all
three.
We
may
decide
to
do
one
or
just
two
of
them,
depending
on
how
the
feedback
that
we
get
from
the
community,
so
we
definitely
do
need
your
feedback.
So
definitely
take
a
look
at
the
the
patterns
there.
Take
a
look
at
the
questionnaire
hit
us
up
on
the
community
site.